| Debugging the EE Module Dependencies property page [message #231711] |
Thu, 21 May 2009 21:35 |
|
Originally posted by: rstryker.redhat.com
The EE Modules page needs to be improved (IMO). I'll list some of the
problems with it first, and then ask for feedback as to how (or even if)
time needs to be spent fixing this page. For the duration of the email,
let's assume I'm speaking entirely about this page for EAR projects.
Possible conclusions could be any one (or more) of the following:
1) This is simply a series of small bugs and each should have their
own bugzilla
2) The code is a bit complex and could use a general cleanup
3) Perhaps the page is too focussed and could be generalized while
still retaining all of its charm ;)
One of the first things I notice about jee tools is that it's basically
a semi-thick wrapper around the Virtual Component Framework. The virtual
component framework at its raw level provides a lot of functionality for
both related / nested projects, but this property page doesn't. It seems
to be pretty limited to Java EE (and judging by its name, with good
reason).
Let's address a few specific issues.
1) The very first issue is what shows up in the viewer.
a) For binary modules inside this project, they *only* show up if:
1) they are in the EarContent folder, or
2) they are inside the designated lib folder.
If they are anywhere else (such as EarContent/my/brother) they do
not show up.
(Some of this logic is inside
AvailableJ2EEComponentForEarContentProvider.shouldShow(etc), where it
So we're showing binary inner modules, but only if they're in
EarContent, or EarContent/lib. Perhaps we should either
a) show all inner binary modules added directly via FS, or
b) show no inner binary modules added directly via FS
2) On a raw XML level, org.eclipse.wst.common.component can set a
"deploy-path" for any dependent module. So you can deploy that dependent
utility jar to /foo/bar if you want.
<dependent-module
archiveName="Util2.jar"
deploy-path="/somewhere"
handle="module:/resource/Util2/Util2">
The current page does not show that this utility jar will be published
in /somewhere. The current page only shows a checkbox stating whether
this deploy-path is in the designated lib folder or not. And often times
this checkbox is wrong. In the above example, despite "/somewhere" *not*
being "/lib" (and also not being the designated lib folder in the
application.xml), the checkbox is still checked. The method at fault
this time is AddModulesToEarPropertiesPage.isInLibDir(etc)
Basically, if the file is sitting inside EarContent, it says it's not in
the lib dir. If it's sitting anywhere else (EarContent/my/brother/bob)
it says it *is* in the lib dir. It never checks the libDir string to
compare.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=276463
3) "Add Jar" allows you to select a binary Jar that's already inside the
project, and when you press OK nothing seems to happen. Publish and
export of all other added jars works fine. This jar still suffers from
problem [2]
4) Selecting "Add an external jar" does modify the components xml file
when applied, and publish and export work fine. This jar still suffers
from problem [2]
5) You can add classpath variable entries.... however if I made a
variable that pointed directly to /home/rob/tmp/some2.jar, and apply the
change, the following gets added to the component xml file:
<dependent-module deploy-path="/"
handle="module:/classpath/var/some2">
<dependency-type>uses</dependency-type>
But upon a publish this file is not included. Upon an export, this file
*is* included, but it's name is "some2" and it lacks a file extension.
6) The second checkbox that appears first appears in the left column,
then moves itself over after 2 seconds to column 3. This is kinda jarring.
--
So aside from the publish / export issues, which I'm concerned about in
the long run but for this particular email I'm focussing on UI... and
specifically the existence of column 3, "Is in Lib Directory". I think
that because the raw component xml file allows you to set an actual
deploy path, adding this to column 3 could be a much better choice,
rather than having an often-innacurate checkbox that moves around and
doesn't convey all the information of the underlying xml file.
I've been thinking of making a patch primarily to remove this checkbox
and replace it with a modifiable text box, but the current code is a bit
messy so I was wondering if, assuming all button-logic and interaction
with the underlying xml file remained constant, if this would be a patch
WTP would be interested in. The patch would likely be large but touch
only one or two files; the reason for it being large is that much of the
code would be re-written and cleaned up.
Is this something WTP would be interested in, or do they genuinely
believe limiting a user to the LIB folder for the purposes of staying
within the boundaries of JEE is a better idea? My solution would be more
versatile (you could have 10 utility jars all being put in different
places in the resultant EAR) which is already supported by the component
xml, but your argument may be "why would anyone *WANT* to do that?"
If I were given permission for this, or told my patch would be welcomed,
I could probably fix bugs [1], [2] and [3] in the process, however the
export operation / publish operation bugs would be beyond the scope at
the moment.
Thoughts?
- Rob Stryker
|
|
|
Powered by
FUDForum. Page generated in 0.06826 seconds
] 
Search
Help
Register
Login
Home
