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 <[email protected]> To: "General discussion of project-wide or architectural issues." <[email protected]> Date: 05/22/2009 04:19 AM Subject: Re: [wtp-dev] Re: Debugging the EE Module Dependencies property page Sent by: [email protected] 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 <[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 _______________________________________________ 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
