Rob, Max, all
First off, I thank you for taking your time to clarify these issues,
as many related bugs have been opened, but a coordinated response
hasn't been formed.
I do agree this area needs a clear definition, as it has been
augmented over the years, and the base WTP implementation has various
issues you have raised below.
I opened a bugzilla:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=277482 that contains
your initial post, which we can use as the parent of all related defects
- as well as a place to comment on the issues/enhancements. ( My
comments are forthcoming)
I welcome your assistant in this area, and we could setup a call next
week inviting interested parties to discuss. (My initial thought is
targeting this work for 3.2).
Thanks - Chuck
From: Rob Stryker <rob.stryker@xxxxxxxxxx>
To: "General discussion of project-wide or architectural issues."
<wtp-dev@xxxxxxxxxxx>
Date: 05/22/2009 04:19 AM
Subject: Re: [wtp-dev] Re: Debugging the EE Module Dependencies
property page
Sent by: wtp-dev-bounces@xxxxxxxxxxx
------------------------------------------------------------------------
I probably still need to make a lot of bug reports for those issues... I
think oonly one of them has a bugzilla ID.
My intention was to ask whether I should file separate bugs or if at
this point a complete rewriting of the class is in order.,... perhaps
with a clearer definition of which jars should show up in the list, and
allowing modules to be put in different places in the resultant ear.
Max Rydahl Andersen wrote:
> note, my point is not that WSAD/Bea weblogic is applying patches -
> that is fine by me.
>
> Just saying that WTP core dependency management have been broken for a
> long time (years) and we have been
> trying and are trying to to get to the bottom of howto fix this.
>
> But it seems there are multiple "architectural differences"
> implemented in ui, core and code that uses the virtual component model.
>
> I assume that is because of the removal of "sub projects" feature
> since WTP 0.7 that is causing the differences and no-one
> have had the full picture ever since when it comes to export and
> publishing of WTP projects. If someone does we would love
> to get their attention on the bug reports Rob Stryker is referring to
> below.
>
> /max
>
> Max Rydahl Andersen wrote:
>> Jacek Pospychala wrote:
>>> hi Max,
>>> afaik RAD/WSAD requires patches fixed in WTP (or any other
>>> component) first, before including in their fixpacks.
>> Ok, just weird that we got customers saying they can use
>> components.xml that has a deploy destination
>> other than / and lib in WSAD but when importing into "plain" WTP then
>> it fails.
>>
>> But since I don't have access to WSAD I can't verify - just passing
>> on the message.
>>
>> /max
>>
>>> 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
>> _______________________________________________
>> 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
_______________________________________________
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
