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

[Jacek Pospychala <jacek.pospychala@xxxxxxxxxx>]

You can get RAD trial at http://www-01.ibm.com/software/awdtools/developer/application/

Jacek Pospychala                
                     
          
Technical Support Engineer              
                     
  
Eclipse Support Center              
                     
      
IBM Software Group

From:	Max Rydahl Andersen <max.andersen@xxxxxxxxxx>
To:	"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
Date:	2009-05-22 09:43
Subject:	Re: [wtp-dev] Re: Debugging the EE Module Dependencies property page

---

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