Maven 2.x Eclipse Plugin

This is a patch against trunk to implement the feature described. The ability to generate m2eclipse-capable projects is turned on by the (shock!) m2eclipse variable. So, you'd add the following bit to enable it:

<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-eclipse-plugin</artifactId>
<configuration>
<m2eclipse>true</m2eclipse>
</configuration>
</plugin>
</plugins>
</build>

Whoops. When I was originally making the changes, I entirely commented out the part that wrote stuff to .classpath from M2_REPO. This version should only write that to .classpath if you don't enable m2eclipse compatibility.

Hi,

I'm not sure wheter this patch is needed at all - m2eclipse should be able to import existing projects just fine
(but probably not as a project tree, so this is a good intermediate solution).

Could you modify the patch in the following way:

1) use correct formatting (for instance: "{" on a new line, and a space after "(" and before ")" )
2) don't use expression="false", but rather expression="${eclipse.m2eclipse}":
a) Your expression doesn't do anything - you already defined the boolean as false (btw, false is the default
so you don't have to specify it as ' boolean ... = false')
b) we don't want users to specify eclipse config for something as simple as a commandline flag. You should NOT
specify in the POM wheter you'll be using m2eclipse or not - that's the developers choice.

If you do that, you can do 'mvn eclipse:eclipse -Declipse.m2eclipse=true', according to some other conventions.

Thanks!

Actually, this can be a big help for people who set up their projects with Maven. What happens today is that currently when you use the eclipse:eclipse goal to generate your project the .classpath has an entry for each dependency like this:

<classpathentry kind="var" path="M2_REPO/net/sf/ehcache/ehcache/1.2/ehcache-1.2.jar" sourcepath="M2_REPO/net/sf/ehcache/ehcache/1.2/ehcache-1.2-sources.jar"/>

In order to enable the project as a Maven 2 project in Eclipse you have to first select all of dependent libraries, remove them from the build path, then enable Maven support. This doesn't sound like much but when you start to have 8-10 or more projects this can be very painful. If you try to enable Maven 2 without removing these from the build path you get an error message stating "Can't enable nature Java Model Exception: Java Model Status [Build path contains duplicate entry:xxx" and it is not actually enabled.

I agree that it should use the -D option rather than an entry in the XML file.

Actually I take back what I said about the -D option. In this case the configuration is being attached to the Eclipse plugin (as in <artifactId>maven-eclipse-plugin</artifactId>) so this looks perfectly reasonable and is implemented in a similar manner to other configuration options as described in http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html. For me based on the current stuff out there I get the maven2Builder and maven2Nature in my .project file although I'm not entirely sure why so I need to check that out a bit more.

I'm taking a crack at redoing the patch since the last one was from over 6 months ago. I was able to get something tonight where I could enable Maven on a project without having to remove any JARs from the build path.

Ok, I think I may have seen the light! I figured out that the Maven nature and builders were NOT actually present. So the stuff in the patch was necessary. I also see why some people would want to use the -D when the team is loosely coupled and why others would want to use the pom configuration if they want the team to all work the same.

So I've gone ahead and set the m2eclipse setting up just like the wtpversion flag so that it can be used on the command line as -Dm2eclipse or in the pom inside the plugin as <m2eclipse>true</m2eclipse>.

Basically I did the same things as the previous patch. I think the EclipseWriterConfig class must have been added after the first patch. I've moved some things into there the same way that the wtpversion was done. I also added a message that the m2eclipse support was being added so the user has some feeback that they set the flag correctly.

I went ahead and built the patch file with Eclipse. Let me know if you see any problems with it. I'm willing to help however I can. Hopefully this can be added into the upcoming release.

Ok, added another version of the patch (based on latest code checked in as well). The previous version did not correctly handle the case where the projects should be configured as source dependencies. It turns out there are multiple places in the EclipseClasspathWriter class that reference M2_REPO that needed to be handled. Additionally I also found that the classpath container for the Maven dependencies can't be added into the current container list because the container needs to be after source references like this example below. Otherwise Eclipse first looks at things in the repository rather than using the projects which is incorrect when there is a project dependency defined in the pom.

<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<classpathentry kind="src" path="/cribbage-util"/>
<classpathentry kind="src" path="/cribbage-facade"/>
<classpathentry kind="src" path="/orchestration-framework"/>
<classpathentry kind="con" path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/>

Again I'm happy to help in whatever way I can.

I've attached a new version of the patch. Sorry about the last one as I did it with Eclipse and it used my entire directory structure rather than just going from the project base.

Also for anyone interested I'm attaching another patch file which is used during the eclipse:add-maven-repo goal to set the Eclipse plugin setting for the repository. I wasn't sure if the change should include any kind of flag to activate it so I left that out and it is always set.

Any chance of this getting into the 2.3 version? The current structure of a project with plenty of jar dependencies make it very hard to work with eclipse.

I am uploading a new version of both patches based on the 2.3 tag since this was released this month. The file names are MECLIPSE-78-tag-2.3.patch and m2eclipse-add-repo-tag-2.3.patch. I have applied them here and they are running successfully. I had to skip tests to do it though as for some reason the tests were not working. It must have something to do with my environment as I tried running them with no changes and they still failed.

Ok, one more time! We were playing with this some today and found that the Struts 2 Core was recently updated to include a system scope dependency to tools.jar from the Sun JDK. These dependencies had not been addressed in what I did so far so it put this out as a library and then the Eclipse M2 plugin included it in the Maven 2 dependency container. This led to Eclipse not being able to compile the project because the same library was in there more than once. Ive uploaded a patch file named MECLIPSE-78-tag-2.3-rev2.patch which does not include system scoped items when writing the classpath. I'm not sure if this is 100% correct but it seems better to have it removed so it can be added back in manually. If it was put in and then manually removed the next eclipse:eclipse goal would add it back. Also I'm not sure what other use cases there are for system scope so I'm not certain if there should be any other checks here. We could have chosen to change our POM to exclude this dependency but since we have multiple protects which use this library the change seemed worthwhile.

Thanks for the patch Rob

I've found two issues though:

1. The m2eclipse setting doesn't carry to subprojects (when invoked from the root project). Other settings do carry, so it must be something in the patch...

2. If the MAVEN2_CLASSPATH_CONTAINER is specified in the configuration, it will be included in .classpath twice.

I've temporarily fixed that for me by hardcoding the setting and removing the classpathContainers from the configuration. So don't feel pressured to fix that immediately

Martin,

1. Do you have an example of this? In the projects we have we do have subprojects and it carries to them so I'm not sure what your configuration is. We actually invoke eclipse:eclipse from the top and it generates all the way through. We have our m2eclipse setting in the POM but I wouldn't think it should differ any if using the -D option.

2. Sorry, but I'm unclear on what you mean here. When you mean included in the configuration are you saying it is in what you already have in Eclipse or it is somehow included in the POM? Given that the classpath container is only used in Eclipse I'm not sure how it would be set up.

So if you give me some more information I can take a look. Thanks!

Rob

Rob,

My original root pom looked something like this:

...
<modules>
<module>Commons</module>
<module>Server</module>
</modules>
...
<build>
...
</plugins>
...
<plugin>
<artifactId>maven-eclipse-plugin</artifactId>
<configuration>
<downloadSources>true</downloadSources>
<!-- TODO: De Maven plugin blijkt niet meer in alle gevallen te werken, wacht daarom op
de versie na 0.0.9, en hoop dat het dan opgelost is.
Tot die tijd kunnen in de probleem projecten de M2_REPO variabelen in de .classpath
bestanden blijven staan.
-->
<!-- Project namen moeten aangepast worden om duplicaten in Eclipse te voorkomen. -->
<!-- M2_REPO variabelen moeten uit de .classpath bestanden verwijderd worden om dubbele
referenties te voorkomen. -->
<buildcommands>
<java.lang.String>org.maven.ide.eclipse.maven2Builder</java.lang.String>
<java.lang.String>org.eclipse.jdt.core.javabuilder</java.lang.String>
</buildcommands>
<classpathContainers>
<java.lang.String>org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER</java.lang.String>
<java.lang.String>org.eclipse.jdt.launching.JRE_CONTAINER</java.lang.String>
</classpathContainers>
<projectnatures>
<java.lang.String>org.maven.ide.eclipse.maven2Nature</java.lang.String>
<java.lang.String>org.eclipse.jdt.core.javanature</java.lang.String>
</projectnatures>
</configuration>
</plugin>
</plugins>
</build>
...

My current root pom is something like this:

...
<modules>
<module>Commons</module>
<module>Server</module>
</modules>
...
<build>
...
</plugins>
...
<plugin>
<artifactId>maven-eclipse-plugin</artifactId>
<version>2.3-patch</version>
<!-- Gebruik de gepatchte versie in afwachting van http://63.246.20.114/browse/MECLIPSE-78 -->
<configuration>
<m2eclipse>true</m2eclipse>
<downloadSources>true</downloadSources>
</configuration>
</plugin>
</plugins>
</build>
...

As you can see I have removed the classPathContainer (used to be necessary). I refer to the patched plugin (obviously).
The plugin is only configured in the root pom. Sub-poms refer to their respective parents (by coordinates and relativePath).
The first level that contains an actual project is 2 levels deep (a sub-sub-pom if you will).

I call maven through a batch file which in turn will issue the following command:

mvn -D"stream.version=ap-JBoss4_Int" -D"stream.name=ap-JBoss4_Int" -D"view.name=Martin_ap-JBoss4_int" -D"view.dir=D:\cc\Martin_ap-JBoss4_int" eclipse:eclipse

If you cannot reproduce this behaviour, then I probably patched the plugin incorrectly. The only patch I've applied was MECLIPSE-78-tag-2.3-rev2.patch. If this was unsufficient then I'm sorry to have waisted your time.

L8r, MO

Martin, your setup looks correct to me and it looks like the same thing we have done. Do the child POMs reference back to the parent? They do for us and that is how the configuration is passed down. I think otherwise you would need to put the configuration in each.

I'm still not really clear on your point in #2. Your second configuration appears to be like what you have. I presume that this is better since now you don't have to specify all of those things. If your problem is that with the first configuration that it appears twice then that seems likely as I hadn't considered what happens if the config exists manually. What I'm not sure about is whether this is consistent with other items or not. Meaning for other configurations do they only should up once if entered manually and the m2eclipse flag is set.

I believe that what you have patched is the only thing I have done. No waste of my time. If it is working for you at some level then hopefully you can keep going like that until they decide to push this into the project at some point.

Rob,

Yes the child POMs reference back to their parent (by both groupId/artifactId/version and by relativePath).

Point 2 is not something I have a problem with. By removing the manual configuration of th classpath I effectively negated it's effect. I just thought you would want to know that it's there The other configuration items only showed up once, so no problem there.

The main problem I have is that the plugin sees the configured m2eclipse flag only at the root POM level. If I add a println of the value in the plugin where it is queried in the code, I can see its value being false for all child POMs. This is true wether I use the mvn command from the root POM directory or from a child POM directory. The downloadSources flag however is seen throughout the POM tree.
This is the reason I 'patched your patch' locally, so it's hardwired to true (the configuration item in my POM now only serves as a reminder).

I'm sure that by the time they they push this fix into the project someone will check the code and fix the configuration issue (I'm confused myself about how to fix that).

Thanks for the info Martin. I'm not sure why it is not working for you. We actually have a master project where we define the setting and that has 6 subprojects and then one of those has 2 subprojects and the setting is passed down to all of them. Everything is working fine in our case. I would try to add test cases to the patch but I am having a hard time getting the existing test cases to work due to what seem like dependency or environment problems so I haven't been able to add my own.

Based on the latest m2eclipse plugin (0.0.10) I have included a new patch file.

It seems to behave a bit differently in the following respects:

• It no longer needs the project dependencies included in the source path. It seems to handle these much better.
• The order of the nature and builds is such that Maven is now at the end.

I've gone ahead and tried to incorporate this into the patch. I suppose if necessary a version could be specified for the m2eclipse plugin like is done for WTP. I chose not to do that at this point since I don't know of any reason not to upgrade that plugin.

One thing I did find (unrelated to this plugin) is that if you (at least me) have a multi project setup I cannot access the source for debugging unless the projects are specified in the launch (Run) configuration to look at the projects. Its pretty easy though and it only needs to be done when you set up your webapp. Not sure if it happens in other cases.

Still hoping that one day folks will find this worthy enough to include in the plugin. Cheers!

This patch doesn't break any existing tests, but doesn't come with any new tests of it's own. Please create a patch with some IT tests or at a minimum, a test pom along with the expected .classpath and .project files.

The reason I have not provided any tests is that I cannot get the tests to run when I just take the base source code. I am running on a Windows machine and I get this:

Tests run: 63, Failures: 34, Errors: 3, Skipped: 0

Here is an example failure. It looks like the .classpath is in an "expected" directory under project-01 instead of being at the root as expected from this message.

testProject01(org.apache.maven.plugin.eclipse.EclipsePluginTest) Time elapsed: 1.515 sec <<< FAILURE!
junit.framework.AssertionFailedError: Expected file not found: C:\Documents and Settings\rbaily\My Documents\sandboxes\maven-eclipse-plugin-2.4\target\test-classes\projects\project-01\.classpath
at org.apache.maven.plugin.eclipse.AbstractEclipsePluginTestCase.compareDirectoryContent(AbstractEclipsePluginTestCase.java:373)
at org.apache.maven.plugin.eclipse.AbstractEclipsePluginTestCase.testProject(AbstractEclipsePluginTestCase.java:245)
at org.apache.maven.plugin.eclipse.AbstractEclipsePluginTestCase.testProject(AbstractEclipsePluginTestCase.java:188)
at org.apache.maven.plugin.eclipse.EclipsePluginTest.testProject01(EclipsePluginTest.java:39)

If anyone has an idea why this is I might be able to correct and then create my own tests.

I'll see if I can come up with a patch now for 2.4 and I'll see about attaching some kind of files that I used to try it and maybe someone else who has the tests running can put them in the project.

due to your working directory has space on its path?

The space problem is fixed in the trunk, so check that out and see if it's working for you. It was definately a problem in 2.4. See here MECLIPSE-291

Can you test eclipse:m2eclipse with the 2.4 or 2.5-SNAPSHOT ??

I've tested eclipse:m2eclipse with the 2.4 version on our project tree.
This version passes with flying colors.

I've tested both on separate projects and on branches of the project tree. The plugin copes with this nicely.
I see that there is no more need to set useProjectReferences to false as this is the default for eclipse:m2eclipse.
Additional project natures, build commands and config files also still work.

As far as I'm concerned, this issue is fixed

Thnx

ok Martin. Thank you for your feedback. I'll close this issue as resolved if nobody complains in incomming days.

This is already in the released plugin. Use eclipse:m2eclipse:
http://maven.apache.org/plugins/maven-eclipse-plugin/m2eclipse-mojo.html