Jacek Pospychala
Technical Support Engineer
Eclipse Support Center
IBM Software Group
From: Max Rydahl Andersen <max.andersen@xxxxxxxxxx>
To: Rob Stryker <rstryker@xxxxxxxxxx>
Cc: "General discussion of project-wide or architectural issues."
<wtp-dev@xxxxxxxxxxx>
Date: 2009-05-22 08:50
Subject: [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
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
------------------------------------------------------------------------
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev