Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #154165 +++ Tracking bug for WTP enhancements to support Maven2 integration
Adding in some comments from 154165: ------- Comment #4 From Robert Elliot 2006-08-17 11:59 [reply] ------- Yes. The M2Eclipse basically creates another classpath container (I think that's the term) containing all jars referenced in the POM and their dependencies (Maven2 does transitive dependencies). In physical terms these are located in your local Maven2 repository. The J2EE publish correctly publishes the contents of the defined webapp folder and sticks the compiled classes into WEB-INF/classes, as you'd expect - but it doesn't know anything about this Maven2 classpath container so it ignores it. Instead as you know it deals with the modules defined in the .component file. You can of course add the same modules to the .component file or physically copy them into the WEB-INF/lib folder, but this is a chore, results in duplicate classpath entries and is generally a nasty workaround. To do this properly you would need to do additional logic on the Maven2 classpath container; the Maven2 POM will define all jars needed in order to compile, including servlet.jar - it marks those that should not be included in the WEB-INF/lib folder as "compile" - and all of them are added to the Maven2 classpath container by the M2Eclipse plugin. So some work would be needed to work out which should be published by the J2EE plugin and which should not. I see two possibilities: 1) Explicit support for Maven2 in WTP. This would mean that WTP was aware of POMs and calculated what to publish direct from the POM. It would mean duplicating a lot of the work done by the M2Eclipse team (unless the M2Eclipse plugin was incorporated into Eclipse like Ant? I believe the M2Eclipse team were interested in that at one point...). It would also mean that if you used the M2Eclipse plugin and WTP at the same time you would get duplicate classpath entries as they both processed the POM and added entries in different places. 2) WTP decoupled from Maven2 but able to be linked together by a 3rd party plugin like M2Eclipse via appropriate extension points. This is essentially what's going on with the JDT. This currently works pretty well, since you can set the webapp and src folders to match those in the POM - it only fails on the publishing of Maven2 defined dependencies. ------- Comment #5 From Philip Dodds 2006-08-17 12:07 [reply] ------- I have recently been doing extension work on the M2 plugin to allow it to switch from a nature to a facet. Also as part of this work I implemented a MavenPublisher (generic publisher). I have been focussing on deploying new facet types to servers rather than fixing up the WTP web support though that might be the next obvious step - I was able to bypass this since a maven based publisher side-steps the WTP ANT based publisher and doesn't need to construct a deployable for ANT to pick up - since Maven can create the WAR (or whatever) itself. I have been looking next at the classpath container work - in order to try and determine if projects that are deps are already open and reference them etc. I would certainly be interested in seeing closer interaction between the Maven plugin and the core WTP tooling. ------- Comment #6 From Robert Elliot 2006-08-17 12:17 [reply] ------- Cool, sounds like it's on someone's radar anyway, which is primarily what I wanted to check. Do you have a JIRA open on the changes to the M2Eclipse plugin you are doing? If there's something an Eclipse novice can help out with I'd happily have a go (I have to confess I don't know the difference between a Nature and a Facet at the moment...). ------- Comment #7 From Philip Dodds 2006-08-17 12:21 [reply] ------- I currently don't have a specific JIRA and I'm working with Eugene on the M2Plugin to get the stuff back into the trunk on that plugin. Once I get in there I'll put an update back to this bug entry :)
I have been wondering if providing ClasspathContainer specific to the scope of dependencies would help in the integration and would be interested in any feedback. Currently there is only one classpath container for all dependencies - I have been wondering whether adding one for runtime, one for test, one for provided etc. In this sense it would be easier to exclude test libs from a run etc and also I'm wondering whether we could implement an interface on the container for WTP so that provided/test could be excluded at the container level?
Once a means of getting WTP talking to the M2Eclipse plugin exists, it would make it easier, as it could simply grab the relevant classpath containers and dump the jars they reference into the WEB-INF/lib folder, rather than having to recalculate which dependencies are appropriate.
Or more accurately, the FlexProjDeployable implementation can define its modules from the containers. So I guess that it's a bit of the work that can be done now on the M2Eclipse plugin without any decision needing to be made about WTP, and will speed things up if the WTP decision is to offer some means to allow plugins to over-ride the way it calculates project modules.
Yeah - I was thinking something on the classpath container such as deployment eligible - this would be false for everything but runtime and could also be used to exclude the JRE container.
A thought. Could a new property, "packageable" or something similar, be added to Classpath Container? And WTP check each classpath container for this property, and build the in memory module representation appropriately? This could continue to behave as is for WTP, the "Web App Libraries" container would be marked as packageable. And it would mean that any plugin could interact with WTP just by creating a classpath container marked ass packageable.
Snap... you win.
I am not opposed to implement multiple classpath containers, but the initial idea is to have a single classpath container in .classpath, so .classpath never changes when you change stuff in pom.xml. So I think that such property should be on jar entry. So, user can actually have any combination of regular jar entries and clsspath containers and WTP would just iterate trough all the jars in the project in order to find out wich ones to include. PS: I happens to be the author of m2eclipse plugin :-)
Even if we had multiple classpath containers - one for each scope type that would still be fixed as we wouldn't want to add remove containers dependent on their content?
(In reply to comment #9) > Even if we had multiple classpath containers - one for each scope type that > would still be fixed as we wouldn't want to add remove containers dependent on > their content? Then we'll need 4 containers (or more if Maven expand dependency mehanism). Most of them will be empty. So, it seems to me it is rather confusing to the user and harder to deal with in the plugin and in general look more like a hack. From other hand having markers on individual jars would allow better control that not necessary have to match to the classpath container boindaries. All classpath container entries allow to have unlimited number of attributes (including custom stuff), that is how javadoc attachment is implemented and m2 plugin already fill in some of those attributes from the pom. So, I do believe it will be more flexible and powerfull and actually eliminate need in having separate configuration data for the wpt's artifacts even without using m2 plugin.
true, though you can't remove say - testing dependencies - from a run since the Run dialog doesn't allow you to change the contents of a classpath container?
Also its worth noting that i believe this is how the NetBeans IDE represents the dependencies - http://mevenide.codehaus.org/m2-site/mevenide2-netbeans/features.html
(In reply to comment #12) > Also its worth noting that i believe this is how the NetBeans IDE represents > the dependencies Wich one you are referring to? From what I've seen it is also using single flat list. Anyways, I am not sure if it is relevant to the context of this issue.
You do all realize that ClasspathContainers are supported in JDT and making a change to add an attribute ("packageable") will be difficult to get approved? I am not convinced that this is the right approach. I've also seen comments about adding multiple containers to the classpath. This is dangerous because now you are running a much higher risk of having duplicate classpath entries which will cause the project to fail to compile. This can be overcome by trimming the calculated entries from the container but which container wins? This also means that containers would have to be aware of each other. It sounds like what you want is a way to add a "container" like element to the module definition of an EAR project or a Web project (in the case of Web libs). This container would dynamically calculate the contents that should be packaged with the parent and would be added to the classpath. This is easier done for Web libs than EARs. Within the EAR project and the other module projects there already exists the Module classpath container that calculates the module dependenies based on the Manifest and the .component files. I would break this support into two categories. 1) The ability to add a dynamic container to an EAR or Web project to calculate additional utility JARs to be included in the packaging (and on the classpath). 2) The ability to add a dynamic container to an EAR to calculate additional modules to be included in the EAR. The first category would be easier than the second. The problem with the second is that it overlaps with the current mechanism so much. As a final note. I would rather see the Maven support added as an extension to the current WTP functionality. Which means we explore what, if anything, would need to be changed in WTP to enable this functionality.
Daniel, please correct me if I am wrong, but JDT already allow to use custom attributes. See JavaCore.newClasspathAttribute(). So, you can attach any kind of metadata to the classpath entries, such as project, library or container. Now it is just a matter of standartizing those attributes between WTP and other tools. I think that putting this stuff into proprietory WTP structures would require from other tools to have unnecessary dependency on WTP and will be an extra work, which can be easily avoided if WTP would use regular Eclipse's mehanisms for dealing with dependencies.
So if the method of publishing in WTP was changed to specify the contract that any jar on the classpath with an IClasspathAttribute of name "deployable" value "true" or something like that would be included in the WEB-INF/lib folder on publish, then all the M2Eclipse plugin (or any other plugin that wanted to interact with WTP) would have to do to have that jar included in the publihs would be add that attribute to the jar entry in the classpath. How would that work with EAR projects?
(In reply to comment #16) > So if the method of publishing in WTP was changed to specify the contract that > any jar on the classpath with an IClasspathAttribute of name "deployable" value > "true" or something like that would be included in the WEB-INF/lib folder on > publish, then all the M2Eclipse plugin (or any other plugin that wanted to > interact with WTP) would have to do to have that jar included in the publihs > would be add that attribute to the jar entry in the classpath. > > How would that work with EAR projects? I would sggest to have markers for each deployment type. So, we'll have deployable.jar, deployable.war, deployable.rar, deployable.ear, etc... On Maven side those attributes can be collected based on information from Maven's POM (pom.xml), such as packaging, dependency scope, war/ear/etc plugins configurations. That would give us enough flexibiliy how to group things into various deployment modules/artifacts.
I've spent rather a lot of the last couple of weeks digging around in WTP and come up with a hack patch. Virtues: * low impact on WTP - operates essentially as normal * easy interface with other plugins - jars & java projects on the classpath of a war with the appropriate attribute are simply put (or packaged and put) in WEB-INF/lib Vices: * too many hacks like hard coding "WEB-INF/lib" * doesn't work with JST ear projects as they don't have a classpath * nothing clever about the packaging of project jars, all class files will be packaged The patch is to the R1_5_0 tagged version, though I think the changes should work on HEAD too. I've also attached a patch with the necessary changes to the M2Eclipse plugin to put things on the classpath with the attribute, if appropriate. The attribute I chose was: org.eclipse.jst.j2ee.deployableArtifact=true
Created attachment 49105 [details] Hack patch to JST to allow integration
Created attachment 49106 [details] Makes the M2Eclipse plugin add the deployable classpath attribute
(In reply to comment #20) > Created an attachment (id=49106) [edit] > Makes the M2Eclipse plugin add the deployable classpath attribute Robert, please attach this patch to issue MNGECLIPSE-107 in m2eclipse issue tracker. http://jira.codehaus.org/browse/MNGECLIPSE-107
Rather than trying to create a new facility via these classpath attribute, which is not consistent with how app packaging is architected in WTP, I would recommend that you take a look at the facilities provided by the IVirtualComponent api. The virtual component api provides various areas of extensibility and if existing hooks are not sufficient, extending the virtual component api would be far more consistent with WTP architecture.
Is there any documentation on the IVirtualComponent API, and the hooks it leaves open? I was under the impression that it was an in memory representation of the .component file for the various modules. I presume that adding new IVirtualComponents would mean that they showed up in the classpath containers as defined by WTP, so the M2Eclipse plugin would need to make a decision whether to add them to its classpath container or not. And generally it would make the M2Eclipse plugin dependent on the WTP, as it would have to use WTP classes to do this interaction.
I am not aware of any documentation oof the IVirtualComponent api beyond the javadoc, but Chuck can correct me if there is some. IVitualComponent is indeed the in memory representation of the .component file, but more specifically it functions as a spec for how to package the modules. Either way, it sounds like you will need to have a plugin that functions as a bridge between WTP and M2Eclipse. You cannot avoid refererences to WTP api and integrate with it in a decent way. Regarding the container question, from the WTP user perspective, I would expect all jars that will end up in my web app's WEB-INF/lib directory on deployment to be visible inside the Web App Libraries container regardless of whether they are coming from Maven or not. That would be the best level of integration.
Konstantin, can you please be more specific? How exactly plug can contribure custom implementation of this API? It is sad that other tools built on Eclipse have to have dependency on WTP. The attribute facility is provided by Eclipse platform and JDT and WTP could use it for the good stuff. I also have to pint out that IVirtualComponent API look very similar to the virtual file system API provided by platform.
Chuck, Could you or a delegate provide information about the extensibility hooks in the IVirtualComponent api since I am not as familiar with it? In particular, I am thinking that the ability to define custom component URIs and implementations might be of use here.
Ok, he haven't received requested info in regards to suggested API. I take that as either API actually does not exist (not public) or there is no documentation, hance impossible to use. I'd suggest to step back from that distraction and reconsider original suggestion based on JDT attributes that 3rd party tools can set for dependencies (such as jars) to mark those that need to be packaged into ejb, war, rar, ear, etc deployment modules. This would be less intrusive integration and will simplify implementation for all 3rd party tools (not only Maven plugin), so they just need to specify for each jar if it belong to certain deployment module type.
I have not been able to try and use the IVirtualComponent API yet, but I'm intending to give it a go over the next few days; I'm hopeful that it will prove possible to create a child plugin to the M2Eclipse plugin that will not require any changes to WTP, but will just create IVirtualComponent instances and add them to the projects as appropriate.
(In reply to comment #28) > I have not been able to try and use the IVirtualComponent API yet, but I'm > intending to give it a go over the next few days; I'm hopeful that it will > prove possible to create a child plugin to the M2Eclipse plugin that will not > require any changes to WTP, but will just create IVirtualComponent instances > and add them to the projects as appropriate. Robert, have you find any API or documentation about that?
No, I'll be working from the WTP code which I have checked out.
Created attachment 50575 [details] A plug-in project that provides a Maven facet and infrastructure to install the facet (also archetypes and WTP Publisher based on Maven for the GenericServers)
Rob, I've attached a WTP plugin that extends the M2 Eclipse plugin and provides a Maven facet etc - it could be used to provide you with a clean facet based integration with WTP - since the facet install will provide you with the component. And it is already an external plugin - not there is a patch the Eugene is reviewing that I'll attach which is needed to provide the Maven2 WTP plugin access to the M2Eclipse functionality
Created attachment 50576 [details] A patch for the trunk of the M2Eclipse plugin that is needed for the org.maven.eclipse.ide.wtp plugin
Thanks, I'll have a play when I get a moment.
Philip, I understand your intent to push your stuff out to the public. However I also need to make sure that contributed patches are in line with general roadmap for Maven plugin. As you already know that there are gaps between your code and the plugin and this report is not really the best place to discuss these issues.
(In reply to comment #27) > Ok, he haven't received requested info in regards to suggested API. I take that > as either API actually does not exist (not public) or there is no > documentation, hance impossible to use. > Hi, I apologize for not replying earlier, but I would like to work with you integrating into our exiting infrastructure, rather than using alternate methods for identifying deployable artifacts. You are correct that the existing docs are out of date, and need to be refreshed: http://www.eclipse.org/webtools/jst/components/j2ee/api/module_core_api.html, http://www.eclipse.org/webtools/jst/components/j2ee/api/flexibleProjectApiAndUsage.html But reading back on the history of this request... It seems the integration required is a collection of jar's (or java containers) and folders/files to be published in a specific location - (WEB-INF/lib for example). As Kosta mentioned earlier... We have existing Java Containers that calculate their contents using different methods... The Web libraries container will include any jars/projects that are physically contained in WEB-INF/lib, or mapped to this folder via the .components file. The EAR libraries container primarily uses the MANIFEST to populate the dependent modules, and will also include the <dep module> entries from .component Both of these containers should be "aware" of existing classpath entries outside of these containers and will not duplicate. We currently have several adopters that contribute classpath info via facets, and add new folder/classpath/.component entries as needed. If participating in these containers still doesn't make sense, can you forward more requirements/details? We do want to make any developing API open as possible, and welcome your feedback.
Chuck, the primary goal of Maven integration with Eclipse is to use metadata information maintained in Maven's project object model (POM, pom.xml). Ideally we are trying to avoid duplication of any of those data in other descriptors. For instance, for JDT integration we created custom classpath container and dynamically resolve its entries from Maven's pom.xml. Since pom.xml also has information about module packaging (war, ear, etc) and what jars should be included into the package, we need to use that info and somehow make WTP about it. As I mentioned above, all that stuff should be transparently updated when pom.xml is edited (inside or outside Eclipse), so it would be really nice to avoid synchronization with .components or manifest files. I hope it does make sense. Please let me know if you need more details.
One important thing to bear in mind is how maven and WTP would deal with web resource filtering. Many web projects I have worked on require ${xxx} placeholders to be filtered and replaced with values from a property file, e.g. in web.xml, context.xml etc. For such projects, it fails when WTP points the servlet container directly at the source WEB-INF, which may contain any number of unfiltered config files, JSPs, property files, i18n resources etc. There is an Eclipse plugin written by another maven user which automatically copies edited web resources on save across to the target directory where maven has compiled an exploded war structure. His plugin and its src is at http://www.bigheadco.com/mavenwarplugin Similar code could be incorporated into M2Eclipse or WTP to allow maven web-resource-filtered projects to be developed in WTP.
(In reply to comment #38) > There is an Eclipse plugin written by another maven user which automatically > copies edited web resources on save across to the target directory where maven > has compiled an exploded war structure. Or that can be already done by hooking up Maven as a builder for given project. That would also resolve more complicated cases, when web.xml is entirely generated by something like XDoclet...
Note that tooling for web content (and ear content and ejb content) resource filtering is a highly desirable enhancement request that is independent of maven support. I know Rob entered a JDT request at some point that the java source path widget/model be factored out of the JDT (or be made reusable). But we should probably have a WTP bugzilla specifically tracking the WTP enhancement request. I couldn't find one in a quick search, if others know of one (or it's already in plan for 2.0), let us know.
That JDT bugzilla request was https://bugs.eclipse.org/bugs/show_bug.cgi?id=103213 (that has been quiet for some time - just made another inquiry)
As noted by Konstantin, "container" support in the component file would be very helpful for this use case (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=128851) This could work as either direct support for references to JDT classpath containers (i.e. the functionality that is currently used to support references to workspace classpath variables in the component file could be extended to support references to cp containers) or as support for a classpath container-like construct in the component file (i.e. an entry that would resolve to multiple resources at deploy time via a call to a container class) I believe the later is the preferrable approach (i.e. it has broader application and you really don't want one cp container exposing a bunch of jars and then have to rely on duplicate detection/cp container resolution order to avoid duplicate entries on the classpath when those entries are mapped to WEB-INF/lib and exposed by the WTP web app libraries container) (note: this is all WTP 2.0 timeframe)
I'm struggling on this one. My intention had been to use the M2EclipsePlugin to insert IVirtualComponents and IVirtualReferences into a WAR or JAR project's in memory representation as I parsed the POM, thereby allowing WTP and M2Eclipse to work seamlessly together - as far as WTP was concerned, it would be as if the dependencies were declared in the .component file. However, I'm not doing too well on working out how to do that with the API; it seems heavily tied to resources loaded from the .component file's XML. Perhaps further investigation will get me there. I found this link: http://www.eclipse.org/webtools/jst/components/j2ee/api/module_core_api.html rather unhelpful; no package names, and I couldn't find any of the classes when checking out WTP and searching the workspace. Perhaps I'm being stupid. If the .component file could reference Eclipse classpath containers, it would indeed simplify things - M2Eclipse could, instead of creating a single Maven2 cp container, create one for each dependency type Maven2 permits. Then the user could manually map the appropriate containers to the .component file (or the M2Eclipse plugin could do it for them).
Konstantin, are you still incist that this API is the way to go? It doesn't sound like it is friendly enough to the external extensions...
Yes. I don't mean to sound harsh, but whether you like the IVirtualComponent api is besides the point here. It happens to be the api that WTP uses to specify how a web app is to be assembled. As such, it would not be appropriate to create another facility for doing something similar. That would be detrimental to everyone. The right approach is to evolve the existing api so that it can meet everyone's usecases and needs. Note that what Robert Elliot is trying to do based on his Comment #43 is not supported. You cannot modify internal model behind IVirtualComponent without affecting the .component file. The better approach would be to enable an entry to be placed into the .component file that would trigger dynamic resolution. That is tracked by https://bugs.eclipse.org/bugs/show_bug.cgi?id=128851 as Rob Frost mentioned.
(In reply to comment #45) Konstantin, I am not suggesting to introduce new API, but rather change the implementation this internal API work. I have to remind you that primary goal of m2 integration excercise is to avoid any synchronization between m2 artifacts and wtp's own artfacts. With that, any requirements to modify any WPT-specific configuration files, including .component file, is simply not acceptable. So, WTP should provide pluggable facility to substitute configuration details that could come from somewhere else withoug going into .component. On the other hand I still believe that attribute-based approach would be a better idea. So, WTP could just use JDT's build path. Then WTP's packaging UI could just editing those attributes, but they may as well came from outside (e.g. populated by maven or other classpath containers). Basically you can store all the information needed to assemble jee artifacts within .project and .classpath.
Eugene, WTP tries to be responsive to the needs of downstream components, but you have to keep in mind that we need to keep our internal architecture consistent and not break it when it is convenient for one scenario. The IVirtualComponent api spans way beyound classpath entries, so it would not be possible to replace the implementation with one based on classpath attributes as you suggest. Regarding the M2 integration exercise, I can certainly understand that you may not want base M2 plugins to have a dependency on WTP. However, that problem is easily solved by having a separate plugin that deals with M2<->WTP integration.
> Note that what Robert Elliot is trying to do based on his Comment #43 is not > supported. You cannot modify internal model behind IVirtualComponent without > affecting the .component file. So my investigations led me to discover, after rather a lot of time and effort going through the code. Perhaps the documentation that would have told me this is out there but I missed it; it wasn't mentioned earlier in the discussion, though perhaps my comment #28 was not explicit enough about my intentions. Eugene - I think Rob Frost's comment #42 gives a good approach, if WTP in future allows the .component file to specify classpath containers. As Konstantin says, we can then have a sub-plugin to M2Eclipse that simply adds the relevant classpath containers to the .component file. As I said in #43, this would require the current Maven classpath container to be split up into different classpath containers depending on the dependency type - would that be a severe problem from your perspective? When it came to a Maven ear project with war dependencies, the M2Eclipse<->WTP plugin would just have to add the war to the .component file in the same way that WTP does when adding a war to an ear, I guess.
(In reply to comment #47) > Regarding the M2 integration exercise, I can certainly understand that you may > not want base M2 plugins to have a dependency on WTP. However, that problem is > easily solved by having a separate plugin that deals with M2<->WTP integration. I would definetely prefer if strong dependency can be avoided but I haven't said that I am against this if there are no other options (or WTP is not willing to open up) and well aware how such dependency can be resolved on my side. Even if attributes only useful for managing jars it is still very beneficial for many tools external to WTP and this is way beyond one scenario and would make integration way easier then digging trough IVirtualComponent (which, is once again, almost the same as standard virtual fs API). Anyways, it would be ok if WTP API would allow to plug custom implementation that would provide *everything* that now comes from .settings. In case of Maven plugin it would came from Maven's pom.xml. Solution that you suggesting won't work well, because if .component changed externally it will be necessary to merge it back to pom.xml and it it is unclear if this can be even done automatically. That is why I am trying so hard to completely avoid this case.
(In reply to comment #48) > Eugene - I think Rob Frost's comment #42 gives a good approach, if WTP in > future allows the .component file to specify classpath containers. As > Konstantin says, we can then have a sub-plugin to M2Eclipse that simply adds > the relevant classpath containers to the .component file. As I said in #43, > this would require the current Maven classpath container to be split up into > different classpath containers depending on the dependency type - would that be > a severe problem from your perspective? > > When it came to a Maven ear project with war dependencies, the M2Eclipse<->WTP > plugin would just have to add the war to the .component file in the same way > that WTP does when adding a war to an ear, I guess. I am afraid that we'll have to make way too much assumptions this way. For instance, what if I have Maven reactor project with ear, war, rar, jar and some test modules as a single Eclipse project? Then each of those submodules would need a separate classpath container, and maybe even separate classpath containers per scope (test, runtime, etc). It sounds like way to inflexible to me and would also require syncronization step between these submodules and JDT .classpath, which we managed to avoid so far... Then on any change in maven projects (new modules, new jars, etc) .component will have to be updated, which is another trouble. I maybe missing something, but attribute-based approach just don't have any of those limitations...
> I am afraid that we'll have to make way too much assumptions this way. For > instance, what if I have Maven reactor project with ear, war, rar, jar and some > test modules as a single Eclipse project? Then each of those submodules would > need a separate classpath container, and maybe even separate classpath > containers per scope (test, runtime, etc). I'm not sure I've delved deep enough into Maven's possibilities to understand this use case; generally I reckon that a Maven module = an Eclipe project. If it's not too much to ask, perhaps you could attach an example of a complex eclipse/maven project like this?
(In reply to comment #51) > I'm not sure I've delved deep enough into Maven's possibilities to understand > this use case; generally I reckon that a Maven module = an Eclipe project. If > it's not too much to ask, perhaps you could attach an example of a complex > eclipse/maven project like this? You may create your layout like that, but it is not mandatory. Look, for example at xcommonj-work project at https://xcommonj-work.projects.dev2dev.bea.com/ At some point (before Maven Embedder got broken) it was even possible to take root of the Maven's own code and have all the modules under single Eclipse project. There probably about 50 of them, so it just faster to setup/import them all this way. And with Mylar it is quite convenient to deal with such gigantic codebase...
Note that WTP only supports one J2EE module per Eclipse project. Multiple modules per project has been tried in prior releases, but that effort has been abandoned. One reason is that JDT only supports one classpath per project, but there were a lot of other complications.
(In reply to comment #53) > Note that WTP only supports one J2EE module per Eclipse project. Multiple > modules per project has been tried in prior releases, but that effort has been > abandoned. One reason is that JDT only supports one classpath per project, but > there were a lot of other complications. Single module from WTP point of view could be represented by several modules in maven... Those could be mapped as multiple source folders from JDT point of view.
Stalemate?
Assigning to Kiril for evaluation
See latest posts on the topic in the WTP newsgroups: http://www.eclipse.org/newsportal/article.php?id=17218&group=eclipse.webtools#17218
