[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[wtp-dev] Re: Debugging the EE Module Dependencies property page
|
Just to support this with feedback from our users.
Setting up the J2EE dependencies in WTP is above *all* other issues when
it comes to questions, problems or bugs that our users ask about.
As soon as you start trying to do more than a simple war, i.e. add a
project as a jar dependency or utilize EAR's then you very soon end up
in a lot of trouble/quirkeness -
add in using 3rd party EJB3 jars and WTP starts behaving very erratic.
Note, the latest WTP 3.1 is better than 3.0 but we still have a lot of
problems using *standard* JEE
packaging because of these bugs.
btw. I sense that many seem to have used other Eclipse derivatives (WSAD
or BEA Studio) where some of these bugs are fixed, but apparently these
fixes never made it back to WTP core.
p.s. it is perfectly valid in J2EE to have directories with jar's in
them and refer to them from application.xml which is relevant if you
want to group your artifacts.
/max
Rob Stryker wrote:
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
