JEE Status Meetings/2009-06-11

Attendees

• Chuck Bridgham
• Jason Sholl
• Carl Anderson
• Max Rydahl Andersen
• Rob Stryker
• Kaloyan Raev
• Dimitar Giormov

Agenda

A. 277482 Java EE module classpath - Placeholder Issues

1) Visibility of Ear contents within Project Explorer (binary modules that are not deployed are not shown)

2) Java EE Module Dependencies page - 276463 - doesn't show (or allow user to edit) the deploy path (lib folder check box is insufficient)

3) Add jar - does it do anything?

4) Add external jar - only says it suffers from 2)

5) Classpath variable entries - 279360 - doesn't allow specification of the deploy path, doesn't seem to work for publish (but kind of works for export)

6) The second checkbox that appears first appears in the left column, then moves itself over after 2 seconds to column 3.

7) Scenario: Create a source folder in a project that has test code (which should not be deployed) - need a way to exclude folders from deployment in component file

8) 279386 - Modules in EAR's lib directory should not be unselectable, even with "deselect all"

B. 267018 [hotbug] EAR Libraries does not refresh nor pickup jar's from JEE 5 library

JBoss: Needs fixing to provide a real simple JEE 5 project + Would like to know what are the usecases that has been used until now to understand the current reasoning to understand how the current functionality is meant to work.

Minutes

Max's first cut on a mockup based on the discussion:

Carl's write up of the discussion:

Rob - tools are restrictive & focused towards Java EE

Chuck - Java EE Module dependencies was originally not for EAR, but evolved

Rob - Java EE Module dependencies seems to just be a UI for the .component file - could we create a base (extendable) class, and extend it for other module types?

Jason - #5 - is that for a variable? Or something within the .classpath

Rob - set up a variable w/ a group of jars, and then include it in the classpath

Chuck - let's identify what scenarios there are, which are broken, and what needs work

Rob - what are the intentions of this dialog?

Jason - There's the .component part, and then there is the EAR libraries classpath container part. If we can get the EAR page working properly and understandable, it is just a small hop to get the EAR lib classpath working. The EAR libraries page should: Allow you to select projects Allow you to select jars inside & outside of the workspace Edit the deployment path (unless it is in the EAR lib) When you exit the page, deploy works, export works, classpath works

Next focus would be the classpath entries.

Rob - has a patch that allows you to edit the deploy path. This page should update the component file and then a listener should update the classpath

Jason - Exactly. That's the way the architecture is set up, but the iterations of development have made us vary from that architecture.

Chuck - When you say "updating the classpath", from an EAR perspective, what do you mean?

Jason - adding/removing a jar from the EAR's classpath container should automatically update that in the classpath of all children modules.

Rob - the classpath updates come from 3 sources - OK on the Java EE Module dependencies page, data model operation changes, and a resource listener. It seems like these may be redundant. (Doing the same thing three times?)

Max - we want the EAR lib dir working, and be allowed to modify/set the deploy path, and get deploy/export to work

Jason - EAR lib dir conversation

Kaloyan - discussion of some of the reasoning behind "in lib dir"

Max - don't show EAR content "content"

Jason - show the EAR content "content", but flag it as non-modifiable

Rob - the one I coded up has an "add project" button right next to add jar & add external jar - if you have your own module type, then you can restrict it to show only modules that adhere to that module type

Max - get rid of the select and deselect button, and add a Remove button

Jason - "Project" column header is confusing if what you are adding is not a project - perhaps it should be "location"

Jason - JAR module should just show the name of the jar

Rob - and the third column would show the deploy location at runtime

Jason - the user is just thinking in terms of "I want to add this lib, or this jar", and doesn't need to know that under the covers there are VARs and all that

Max - Columns: what it is, icon for type, location, deploy path

Jason - icon is good - if it is in the lib dir, we could add a decorator to the icon. Let's move the icon to the first column.

Rob - variable could be distinguised by its icon

Jason - that scares me, because a variable could point to a folder w/ a bunch of jars- almost need a sub-tree to show the contents of the variable

Chuck - variable was originally intended to point to one file. All of these things used to work (2-3 years ago)

Rob - one of these seems to work, but it removes the suffix. The underlying code is a bit of a mess- for instance, that scenario removes the suffix

Chuck - we need to identify a few scenarios and make sure they work, and then set up tests to make sure they do work

Rob - that's one of my big gripes- this is almost always tested with export, but rarely tested w/ deployment. (One more reason to unify the models for export and deployment)

Jason - the component file allows for specification of the (ReferencedComponent) archiveName - you could map a jar to be a zip

Max - the left column should be where it comes from, then archive name, then deployment path

Jason - or put where it comes from last, since it is the longest. User can edit archive name & deploy path... the source is selected via the buttons to add something new. So icon, archive name, deployment path, where it comes from

Chuck - Rob, I'd like to see your changes

Rob - I need to tweak it & do the remove button stuff we just discussed

Jason - why is the "Change Library Directory" button on the Java EE Modules dependency page?

Rob - it renames the dir & moves the current lib dir contents there, and then updates the .component, the classpath, and the application.xml

Jason - if we keep that on this page, we should reorganize it- it isn't really associated w/ those buttons

Kaloyan - it was put there because there was no deployment descriptor tree for EAR 5 projects when it was developed. Now we can move it out to be a refactor action for EAR 5

Rob - or it could be in Java EE Tools, right under Update EAR libraries

Chuck - if we remove the checkbox column, add a deploy path... how are we showing the intention

Jason - you are refactoring the application.xml and the component file, cleaning up the mappings from the old lib dir to the new one

Chuck - but during the refactor operation, the user can choose whether or not to do that

Max - we should hook into the rename of the folder - F2 - so that it does the refactoring, as well

Rob - the files that are manually in your project, I can't get the table that shows the deploy path to actually show exactly where they are deployed- the API always returns root.

Jason - the page will display everything (jars, wars, rars, and zips) in EAR content, but in a way that is non-editable

Rob & Chuck - you can make this extensible to show any kind of component

Rob - let's not restrict it

Chuck - let's make it an overrideable validation to open it up

Max - 2 use cases. 1) ESB 2) Adding an ESB to a Java EE EAR (not possible today - the Java EE spec is too restrictive for servers)

Jason - what about just one add & one remove, with another page that comes up to list what can be added, and allow that page to be extensible to define other types

Rob - Add project is quite generic. My goal is, to at an abstract level, to have this page be as generic as possible, not even Java EE specific- to handle module references

Max - it makes sense to have the most common buttons there- add jar, add external jar. The Launch Configuration's Classpath properties page has an Advanced button that allows you to specify (extend) other types - we should do something like that- we put the three default ones there, and then add an Advanced for extension. We don't pollute w/ other buttons, we just allow them to use the Advanced.

Jason - we still need to discuss the classpath container part of this

Chuck - we are targetting these changes for WTP 3.2