Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search

JEE Status Meetings/2009-06-18


  • Carl Anderson
  • Jason Sholl
  • Angel Rivera
  • Rob Stryker
  • Max Rydahl Andersen
  • Kaloyan Raev
  • Dimitar Giormov
  • Konstantin Komissarchik


Proposed Scenarios

  • Select projects (add/remove)
  • Select jars (or other resources) inside the workspace (add/remove)
  • Select jars (or other resources) outside the workspace (add/remove)
  • Editing the deployment path

Content of the Module Dependency Page

  • Cosmetic
    • Two column vs three column
      • 2 column would be [icon] Identifier, Deploy Path
      • 3 column would be [icon] Identifier, Deploy Path, More Info (full path)
    • Getting acceptable strings for column 0 276825
      • This could require functionally similar results from the API for all virtual components?
    • Same requirements for column 2 (right-side)
      • The goal here would be so that the UI doesn't have to check a million conditions to see if it's an archive, if it's binary, etc, before getting a String to display
    • Icons on the left, but how many types of component are there?
      • How many different types of virtual component are there? Not how many classes, as anyone can make their own component type, but how many TYPES? From what I can see there's only lib, var, classpath, and project type. Are there any more?
        • Must identify the API's that tell us what these types are
    • Do we even show unmovable jars?
      • If this page is meant to be a component xml file editor of sorts, physically added files do not belong (since they are not referenced in the xml file)
    • Ironing out the buttons
      • Option A: just 2
        • Add Entry...  : Remove Entry
          • Add Entry... opens a multi-page wizard (extendable via points)
          • Remove Entry offers to remove the entry
      • Option B: Three
        • Add Project..., Advanced..., Remove Entry
      • Option C: More than 3
        • Add Project... Add Jar... Add External Jar... Advanced... Remove Entry, Kitchen Sink...
  • Content
    • Currently (Rob's) page only holds IVirtualComponent objects inside the viewer. (Rob) assumes anything returned from Advanced... or a button must be an IVirtualComponent. The references are created at the end during performOK.
  • Functionality
    • Can the advanced button multi-page wizard also perform operations relevent to the module and return null to signify no addition is needed? For example, changing library directory? ;)
    • Should the table (first column) be able modify the archiveName attribute in the component.xml? See 280411
      • If yes, this makes the issue of having the first column not just show some identifier but rather some actual jar / ear / war name (see 276825 )
  • Classpath entries
    • Leveraging the JDT UI (is it possible yet?)
  • Tangential Topics
    • What is single root structure? 279360


Carl read through the scenarios

Rob: Editing the archive name could be another scenario

Jason: The archive name is part of the deployment path, giving the user two ways to update that could be confusing

Rob: There are two different items in the component, should we have different ways to set them?

Max: with the scenarios, what about adding/editing VARs?

Konstantin: Is that something that should go with the JDT support? That seems to be more of an effect of the classpath. Let's try to keep this separate from the Java stuff. That keeps the framework generic enough to use for static web projects

Rob: We ask because there are three types: module resource, lib, var (and CPE) - what are all of the types available?

Konstantin: The variable can't be as flexible as the JDT one- it really needs to resolve to one resource/JAR. There may be some generalization that needs to happen at the model level.

Rob: we can still go in steps- update the UI first, make a generic level, then update the underlying model, and add on to the more specific UIs (buttons, etc)

Konstantin & Rob: discussion of ways to improve the VARs & extend it in the future (extension points, more UI support)

Jason: The external jars support that we have right now often hurts the user more than it helps them. Perhaps we should restrict/hide the UI to do this

Rob & Konstantin: We don't want to restrict the user- we should warn them.

Rob: Once they pick the resource, offer them choices: Link to it, pull it into the workspace, or other options to make it safer

The UI:

Rob: Two columns vs. three: which is preferred

Konstantin: Deploy path vs. name should just be deploy path

Rob: The debate is that the first column is the archive name, the second the deploy path, the third the full location which could be extremely long

Konstantin: The deploy path column includes the name

Jason: There are cases where there is no name. (VAR, or if we open it up to include a folder) The deploy path is really what the user is interested in

Konstantin: We need to tag items that are not as obvious, for example VARs or CPEs. Perhaps a better name than location. (Something more generic... stuff? resource?)

Rob: Getting acceptable names- one big problem is binary virtual components- no easy way to get the name

Max: My mock up was quite generic. We realized that the V* is something we can't do right now since VARs need to resolve to a resource, not a folder

Rob: How many different types of VirtualComponents are there?

Jason: There's the basic VirtualComponent, EarVirtualComponent, J2EEModuleVirtualComponent- these two subclasses were necessary because there are dynamic module references- then there are VirtualArchiveComponents, which are binary forms that can be represented as components w/ API that can dig into those components. Those are the three main components I am aware of.

Rob: So if I was to create a RobVirtualComponent, can I create that on the fly and have references to my own type of virtual component?

Jason: Yes

Rob: Does ComponentCore keep track of all of them, or does it just give back a handle.

Jason: ComponentCore looks up what factory should load the component, and then it gives you an IVirtualComponent back. There is also some API there to give you an ArchiveComponent back.

Rob: So if I was to create a factory and generate my own custom component, would an EARVirtualComponent be able to understand it?

Jason: Yes. The IVirtualComponent has API such that the EARVirtualComponent would be able to understand it.

Max: In the end, it is only the references that we need to worry about. If we add it to the model, then the model will load up the extension points when it is needed.

Jason: Let's focus on the contents of the component file itself, rather than what ... is returning.

Max: Other than the classpath references. We have dynamic injection of contents into the classpath- the user has no way to modify those. That's why we don't want to show them here.

Jason: Maybe we do want to show them, but give the user some way to know where these come from and how to go there to modify them

Rob: If we have 20 different types of components, we would have to have 20 different directions to send people to.

Konstantin: If we are going to allow editing in the table, it should only be of the deployment path. Outside of that, we need to allow extension of the Add buttons. For instance, at the JST level, we need to add the Add Classpath Entry button. If we figure out how to support that, we should have enough extensibility for other VirtualComponent types. Classpath Entry is deployed to one deploy path, whereas there could be multiple contents within the container. The user should be able to edit the deploy path, but not the contents of the container here. We may need to fix/add some API to be able to do this properly. (You currently have to access some internal code to do this today.)

Jason: What if we made all of the fields non-editable, and instead relied on the Edit button, thus allowing a way to edit different types

Rob: At the moment, the viewer holds just the IVirtualComponents, and then finds/tweaks the references at the end. Should it hold onto (and modify) the references, or should it continue as is? (It is currently a reflection of the Java EE Module Dependencies, which did it that way.)

Konstantin: We need something more "raw" than what the IVirtualComponent API exposes to really do what we need at this level

Jason: If we could go back a second, the dependencies page was a way to assemble the external dependency of this component. We never expose the contents of this component

Konstantin: This was "boxed in" originally that way. One of the things I have considered is "unboxing" it.

Jason: I think it would be kind of confusing if we had this page try to have both the contents of this component and references from this component both in the same table. If we had separate tabs...

Konstantin: What is confusing is the classpath management that was included in this page. If we remove this, so that this page only shows things that have a deploy path (since a lot of that stuff doesn't have a deploy path)...

Jason: This is originally what we were talking about last week- this page was originally designed around an EAR, which has no MANIFEST.MF itself.

Konstantin: EAR project is interesting. For example from that perspective, this is all just assembly. Physical path to deploy path mappings is all that we are setting up. Once we get into the module projects, we have other considerations to handle.

Jason: Before we start honing in all of the other modules and their problems, do we have anything else to cover about the EAR?

Rob: When we have the advanced button, is that only to add some other type of references? Or are there other things?

Jason: I think that advanced is really where anything that is extended- doesn't come from the core- should show up.

Rob: There are other things that could be added through the Advanced button- is it any type of virtual reference that can be added?

Konstantin: We need to back off on that. We need a seperate way to handle things that are virtual references.

Jason: The advanced button could return one of these, even though it is not returning a virtual reference within the component file.

Konstantin: So there are two models- the assembly record model (for the component file) - every thing returned by that model is a derivative of the assembly record. And then we will rebuild the virtual component over this new model.

Jason: We don't need a new model.

Konstantin: There are two aspects of the virtual component 1) ... and 2) resource mappings. (Which are useful when you try to put together the jar, but not here.)

Rob: Perhaps we chain up a bunch of operations, and when they click apply all of these things happen. For instance, you can't do virtual references for projects that are not java projects- there is no way to make them into virtual components.

Konstantin: If you go to write a smart publisher that follows smart links that the server can understand, it would be extremely useful for those publishers to have another model that they can load up, instead of having to open the component file with the DOM editor. (Virtual component is too abstract- the API isn't there to do what we need)

Konstantin: Should we still try to resolve the 2/3 column issue and their column headers?

Jason: 2 columns

Angel: I can see what we want with the two columns, but I can see advantages to the three columns, if the entries are really long. Have we even considered the way that JDT does it for the Java Build Path? (The way that they organize it in a tree view- the library tab)

Konstantin: The situation there is a little different- there you care about the content that is nested. We care about the mapping, so a table is moreso what we need. If we have the three columns, what would we put for the name of a folder in the first column?

General discussion about the way to generate/fill in names for resources & folders

Konstantin: We can make the three columns work, and there are situations where it makes a lot more sense to just have two.

Back to the top