Yes, their page/approach is very weird.
I think you should collect the usecases where it breaks and report it in
bugzilla and then post to wtp-dev with a highlevel summary and
see how they react. The same summary/bugreports we need to go forward
anyway and if that includes adding a "Working EE Modules Page by JBoss"
then that is what we should do.
I would really like to understand how IBM and BEA's eclipse based tools
handle this - do they have fixes that is not in WTP or do they live with
the same problems ?
Rob Stryker wrote:
The EE Modules page needs to be improved (IMO). I'm gonna list
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.
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
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
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?
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.
jbosstools-dev mailing list