JEE Status Meetings/2009-06-11
- Chuck Bridgham
- Jason Sholl
- Carl Anderson
- Max Rydahl Andersen
- Rob Stryker
- Kaloyan Raev
- Dimitar Giormov
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.
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