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 <[email protected]> To: "General discussion of project-wide or architectural issues." <[email protected]> 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 <[email protected]> > To: Rob Stryker <[email protected]> > Cc: "General discussion of project-wide or architectural issues." > <[email protected]> > 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 > [email protected] > https://dev.eclipse.org/mailman/listinfo/wtp-dev > > > ------------------------------------------------------------------------ > > _______________________________________________ > wtp-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/wtp-dev > _______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
