Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Re: Debugging the EE Module Dependencies property page

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


Back to the top