Re: [wtp-dev] Re: Debugging the EE Module Dependencies property page

[Chuck Bridgham <cbridgha@xxxxxxxxxx>]

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