|
I've just solved all the issues with WTP 2.0 for a project in my workspace. It involved a lot of clicking around in J2EE module dependencies and something with jaxb-2.0.api. Next time I encounter this, I'll try to document all the issues in detail. What changed with WTP 2.0 IMHO is the way J2EE module dependencies are declared. They no longer are declared inside .settings/org.eclipse.wst.common.component, but as a classpath entry attribute in .classpath instead. So, currently (for WTP 1.5) there is an entry in .settings/org.eclipse.wst.common.component created, like <dependent-module deploy-path="/WEB-INF/lib" handle="module:/classpath/var/M2_REPO/org/springframework/spring-core/2.0.5/spring-core-2.0.5.jar"> For WST 2.0 the following entry must be created in .classpath instead: <classpathentry kind="var" path="M2_REPO/org/springframework/spring-core/2.0.5/spring-core-2.0.5.jar"> The issue of supporting classpath entry attributes is also relevant for Currently after an "mvn eclipse:eclipse" when using WTP 2.0 I have to manually: 1. Drop the dependency entries from .settings/org.eclipse.wst.common.component (either by unchecking them via Eclipse "J2EE Moduie" GUI, or by editing the file directly). 2. Add the "org.eclipse.jst.component.dependency" attribute to the classpath entries in .classpath (again by checking them via Eclipse "J2EE Moduie" GUI, or by editing the file directly). 3. ( Can this get a bump up? WTP 2.0 has been out for quite a while, rendering this plugin basically useless for those of us using Europa. Considering WTP 1.5 wasn't the most stable WTP ever, that needless to say accounts for more than a few of us Attached, please find a patch for this issue. This introduces a new includeJ2eeDeps config entry that is automatically set based on the WTP version. I decided against making it a config option, as I can see no cases where it would be set outside of the WTP version at this time. Also note that I introcuced a new flag to check whether or not the attributes entry has been opened. If more attributes are added (see The new EclipseWtpComponent20Writer suppresses the output of all non-project dependencies in the component file. I think this is the correct behavior for any use cases, though it does work for the several I tested with. I just checked using 2.5-SNAPSHOT of the plugin and this patch does not seem to be applied. Are there any plans to merge this anytime soon? This patch was actually broken in 2.5-SNAPSHOT by the application of another patch (which I can't remember off the top of my head). I'd be happy to recreate the patch but have been waiting to because none of the committers seem to be available for this issue, despite it being the most popular open issue in Jira. I will check for a mailing list or something for this plugin to see if I can't get an idea of what is going on. Sorry that I did not spend any attention to this bug for some time now (been busy in another project). Cris, thank you for that patch. I checked out and applied against the exact revision (572678) mentioned in the patch file, compiled, installed and updated my project to using the just locally installed maven-eclipse-plugin "2.5-SNAPSHOT" and setting WTP-Version to "2.0". Then a "mvn eclipse:clean" and "eclipse:eclipse" from the modules root, and ... drumroll ... The generated eclipse projects work "out of the box" now (with the patch, and after adjusting AspectJ Path (see So, thumbs up from me to merge patch 264. And if general attributes could be addressed, too (like you already denoted in GOOD WORK! Thanks for taking a look at it! Do you need me to rebuild the patch to work with the latest revision? One of the recently applied patches broke it a bit. Cris, sorry, but I am not a dev with commit rights here, so I can not merge that patch myself ;-( The subversion report (see http://jira.codehaus.org/browse/MECLIPSE?report=com.atlassian.jira.plugin.ext.subversion:subversion-project-tab I do monitor the two bugs now (just saw I have to explictily request notification here even for bugs I commented on But I would really like to see this merged into the official sources, as managing patched "unofficial" plugin versions internally is a pain, and completely defeats Mavens "build everywhere" approach. Currently there seem to be quite a few Unassigned/UNRESOLVED issues and very little progress, so perhaps a 2.5 release is still far away. Does anybody know whether this is simply due to lack of resources, or is the eclipse plugin being phased-out in favour of http://m2eclipse.codehaus.org I'm really happy to see something to get moving with this issue! It'd be great to see this patch getting into 2.5-SNAPSHOT at least before the patch gets obsolete again.. Michael, I believe m2eclipse doesn't have much momentum either, but there is 'Q for Eclipse' rolling out (but these two acting as eclipse's maven support don't really compete with maven's eclipse support, if you know what I mean.. I can try to apply it before the end of the next week (I also need it). But in the patch attached it seems that there's no update of the doc and more important no test.... I can put together some tests. I wasn't really interested in going the extra mile if it wasn't going to be applied As far as doc... where should some be added? I didn't really see any anywhere to update, but would be happy to. In fact this the problem of the chicken and the egg. Committers don't spent time to look at patches without docs/tests and users don't want to loose the time to create tests and update doc if they aren't sure that the patch will be applied Would this be the correct SVN target: http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-eclipse-plugin/src/site/apt/wtp.apt It looks like that is the correct site module for this one. By the way, I hope this project isn't going away because of m2eclipse. I personally far prefer this plugin. yes, this is this one. No never !!! this is the only one supporting WTP Great. I'll probably get to redoing the patch for the latest revision later on in the week. I'll include some tests in that patch and a separate patch for docs. That page actually could use some more info on configuring the plugin via the POM, etc as well. I will open a separate issue to improve that page and include docs for this in that. ok, thanks a lot. I'll review and apply them ASAP. I think that there is a bit more to supporting wtp 2.0 than is dealt with in the maven-264.patch file referenced above, including updating the org.eclipse.wst.common.project.facet.core.xml file within referenced projects in a multi-project build. I am just finalizing a patch for wtp 2.0 support including this. I have a basic test case which passes, but have yet to write the test for the multi-project part, although it works for the multi-project build for the project I am currently working with. If I don't get the time to look at the test in the next few days I'll post the patch 'as is' for review.
Sample configuration: <plugin> <groupId>org.apache.maven.plugins</groupId> new patch with tests, documentation, other bug-fixes and some extra functionality like context root detection is available here -> Richard, I've applied your patch locally against the current svn trunk and it seem to work great. I had to skip the tests run though as some of them fail. the test will work when you add the (partly binary) data from the tar. We have to check how these 2 issues can be fixed. I will open a branch to add the support of WTP-2.0 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Now WTP 2.0 is final, so I think that it deserves some supporting...