[jbosstools-dev] Re-thinking the EE Modules Page

[Rob Stryker]

The EE Modules page needs to be improved (IMO). I'm gonna list some of 
the problems here with it, and then ask for feedback as to how (or even 
if) I should spend time on this patch. I've spent a bit of time today 
familiarizing myself with the code.

Some details:
 1) Every EAR project has a designated "lib" folder. This is stored in 
the application.xml (if one exists) or just defaults to "lib".

 2) On a raw xml file level, each child project (utility projects, web 
projects) can designate it's deploy directory inside the EAR by using 
the "deploy-path" attribute in the components xml file. The current page 
doesn't show this.
    a) In fact, the current page only has is a checkbox as to whether 
it's in the designated lib folder or not... and this checkbox is often wrong
    b) And the checkbox uses really weird logic to initialize itself 
(ugly code) and there's a delay before it appears, and when it does 
appear it appears on the left, and then 2 seconds later moves itself 
over to column 3. Really odd.

 3) Binary child modules are treated... oddly.
    a) If the binary module is in the EarContent folder, it's listed in 
the viewer (but cannot be relocated in this prop. page).
    b) If the binary module is in the lib folder (EarContent/lib or 
whatever application.xml says is right), it's listed in the viewer (but 
cannot be relocated in this prop page)
    c) If the binary module is... anywhere else in the project, it's not 
even listed, even if it should be. I've traced through. It gets filtered 
out. Odd.

4) When on this property page, if I select "Add Jar", It lets me browse 
the workspace for jars (in any project) that I want to be in this 
project (I think? Not sure if it's just for classpath or not)... however 
if I select a jar that's already in the ear project, nothing happens.
     a) Adding jars from other projects does add a line to the 
components xml file, but not quite sure it's behaviour yet (bundle or 
just CP entry)

5) Adding an external jar seems to work fine. The only difference 
between adding a workspace jar and external jar seems to be absolute or 
relative path.

6) You can add classpath variable entries. Still have not yet 
investigated how exactly they work.

7) You can change the Library directory in the application xml. Any 
reference that has the current lib directory as its deploy path will be 
re-assigned the newly-typed value as the new one.

Now, I can clearly use whatever logic they need done on performFinish 
and clean up the UI at the same time if I need to. My question is, is 
this worth pushing, and considering the breadth of problems, is it 
better if I just try to clean up the entire class and send them a new 
one for their consideration rather than try to isolate specific 
complaints and have to bicker over all of them?

Also:

  I believe I know why their UI is so limited. They're trying 
specifically to limit the possibilities to that which is supported by 
JEE. For example, having all sorts of random utility projects / jars 
being deployed to whatever folder you want clearly isn't EE supported, 
but I believe it's more humane. WTP wants to reduce this choice to only 
a "lib folder" or "root" choice, (or if you place the file directly in 
the project, then it lands "wherever you put it").

If I were to recode it and keep all the functionality while actually 
making it work, which jars in the project SHOULD show up? Currently it's 
only root / lib folder jars. All others are ignored. Should they be 
ignored on this page or not? Would a text box work better than a 
checkbox? Obviously it'd be more configurable, but perhaps their usecase 
of limiting complexity is good?

Thoughts / comments please. thanks.