Maven 2.x Eclipse Plugin

Letting any interested maven dev assign himself... I'm working on some other stuff atm.

Sure, no problem, makes more sense. I just wanted to be sure you were notified about it (well, I could have sent you a message, sorry

As http://jira.codehaus.org/browse/MECLIPSE-19 was marked as a duplicate of this, I'll flesh out some details here.

1) My request about JAR projects is apparently incorrect, and the addition of the wtpversion attribute solves the real issue which was a desire not to have WTP builders for jar projects

2) For POM projects, there are two current behaviors.

a) When simply running eclipse:eclipse for a POM project, the project is skipped. I think this is incorrect behavior, and should instead create a .project file for an Eclipse "Simple Project" with no builders, etc. This is somewhat in contrast to the request here, as it sounds like Felipe wants to generate a Java Project. That could still be effectively done with specifying builders or something, but it may be that a more convenient mechanism is needed.

b) when running eclipse:eclipse -Declipse.workspace=/path/to/workspace, a project for the POM packaged artifact IS created, and it IS a java project. Again, in that case, I would like it to be changed to be a Simple Project (no builders or natures). That was what my original request was about.

Feel free to separate this back out into separate requests or re-open MECLIPSE-19 if this clarification indicates that they are not really duplicates...

Hi Stephen,

Independently of being duplicated issues, I think your reasoning makes more sense, i.e, always generate a simple eclipse project for a pom-packaging M2 project - and if it's necessary to set it as java, use the natures property (although it might be necessary to change the isJavaProject assignment to reflect that nature - I don't have the code available right now to answer for sure).

Regarding the -Declipse.workspace property, I guess that explain the eclipseProjectDir == null comparisson; anyway, I still think that's not enough, as it would require each developer to set a property in order to setup the project...

– Felipe

What happens in case of nested eclipse projects? Wouldn't that generate an overlapping project description (or something like that ) error when the user attempts to import them into a workspace?

Correct - you can't nest projects in eclipse. POM projects are grouping projects, they usually have a <modules> section.
Or rather, any pom that has a <modules> section must have packaging POM.

Since eclipse 3.2 however, it's possible to have nested projects (although they appear to be flat in the
package explorer).

POM projects are just metadata projects - they cannot contain any sources or tests.
So generating a Java project from a POM project is impossible as there are no sources. If there are sources,
Maven will ignore them (mvn install on a pom project will only install the pom; it doesn't create a .jar etc..).

So I'm inclined to say "won't fix", except for maybe the fact to add a simple .project for pom projects
for eclipse >= 3.2, although it's quite useless to have a pom project in eclipse.

Well, I generally have a POM project in eclipse to use for interacting with CVS or SVN for the top-level pom project. However, I generally check-out through Eclipse also, which creates the .project file for me. So this is no longer a major concern for me.

However, the original request seems to have to do with using "pom" packaging for an integration-test project. I can't really speak to that use case.

Hi Stephen,

Yes, you're right, the original request was based on how the M2Book defined an integration-test scenario. And to be honest, I don't remember how exactly the use case was, as we had gave up that integration-test project (for lack of time).

Anyway, by the time the issue was created, there wasn't yet a well-defined scenario for M2 integration tests; once such scenario is defined, this issue might be marked as won't fix (or not .

– Felipe

I don't think Kenny's remarks are quite right regarding the use of 'pom' projects.

There's at least a couple of scenarios where 'pom' projects are used where the generated artifact is not one of the traditional java archives.

1) Ch 6 of the bbwm book uses a pom project for a user guide module where the generated artifact is a web site.

2) The assembly plugin seems to require that the project type be 'pom' when the primary artifact of the module is an assembly.

I think it's quite reasonable for the eclipse plugin to generate a 'simple' .project for this kind of module.

The fact that we have to set the project type to 'pom' in these cases seems to be semantically wrong at least, but that is what we have to live with at present.

There's a patch in MECLIPSE-216 for a new property to generate .project in pom projects

http://jira.codehaus.org/secure/attachment/25262/MECLIPSE-216.patch

Build configuration == source code.
IDE == source code editing environment
pom.xml == build configuration
XML == source code

Therefore POM project == source code project and thus eclipse:eclipse must make Eclipse projects for POM projects.

The layout of a project structure (flat or nested) and its effect on Eclipse is another matter altogether and one that this should not obscure the correctness of the above (ie. I have a flat structure so I expect to be able to edit my source code in eclipse, if we had a nested structure I would only use an IDE that could handle such a structure).

So until this silly distinction between JAR/POM/EAR/WAR/FOO/BAR projects is removed we will create our own eclipse variant and apply the above mentioned patch.

Project files for POM project could be generated automatically at least for leaf projects (i.e. with no children).

As Vincent commented, generating a .project file for POM projects that do not have leaf projects is indeed quite useful.
I have several POM leaf project:

• documentation projects, i.e., they only contain sites.
• assembly projects, i.e. they package things into ZIP files via the maven-assembly-plugin

The boring thing is that these projects are not visible from within Eclipse right now.
For my documentation projects the simple workaround is to change the artifact type to JAR. This makes the project to generate an empty JAR but at least it's visible/editable from within Eclipse.
As for the assembly projects, there is no easy way around here... so I cannot access these easily from within Eclipse.

The patch MECLIPSE-94 allows for POM files to yield Eclipse project files in case the Maven project has no child projects itself.

Just to add another use case:

1) you check out the pom project and its nested modules (eclipse generates the parent .project file)
2) you run eclipse:eclipse to generate all needed files
3) you'd like to clean something up, so you call eclipse:clean
4) now eclipse doesn't recognize the project at all so you can't make any changes to the parent pom since the .project files is gone

This has happened quite often where I work. The work around is usually to comment out the modules section, change the type from "pom" to "jar", call eclipse:eclipse, and then undo the changes to the pom.xml file. That's pretty annoying.

It would be great (as many have suggested) to just create a simple .project for projects of type pom.

I use the following workaround in any 'pom' poms that I want .project files generated for.

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-eclipse-plugin</artifactId>
	<configuration>
		<!-- Workaround for http://jira.codehaus.org/browse/MECLIPSE-94 -->
		<eclipseProjectDir>..</eclipseProjectDir>
	</configuration>
</plugin>

It would be more consistent if "mvn eclipse:clean" would only delete files/directories that "mvn eclipse:eclipse" creates.

Then Jim Sellers' case would not exist.

Also consider a use case such as the integration builds module from "Better Builds.."

If I import such a module, m2eclipse generates a project with a layout like this:

This is a proper java project, with classpaths, builders, and all the rest of it configured. I can edit java in src/test/java as if it were a jar project.

I would expect an eclipse:m2eclipse to generate the same structure.

+1
pom.xml files are source files, which I would like to edit in Eclipse

@Florian:
Is there something in that you need an Eclipse project for? I can just drag my POM files into Eclipse and the m2eclipse plugin editor opens it up.

@KP:
Here's a scenario for you: You are fixing an issue which requires modifying your project's parent pom, in order to update the dependency management section with a later version of some open source package that you use. You want the change to the parent pom to be part of the same change set that the rest of the bug fix is in. So you want the parent pom.xml to be visible to Team->Synchronize operation, etc.

Further to the great points already made about source code; Maven while originally for java-projects now has many plugins and goes beyond the scope of Java projects. In fact, the nature of this plugin to create eclipse metadata is proof to the fact that maven goes beyond java. We are involved with a top-level Apache project, OFBiz, which is primarily a Java-project, but uses various languages, and has a vast structure.

I am working on converting this project to Maven. The root directory / project has no Java components, but has various shell & batch scripts, XML files, properties files, etc.

The eclipse maven plugin is already flexible enough to create the correct .project / .classpath file at the root, if this ticket was resolved (i.e. if POM packaging was not blocked). Silly to disallow it.

Building off James Olsen's suggestion, this work around works as well and is more direct:

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-eclipse-plugin</artifactId>
	<configuration>
		<!-- Workaround for http://jira.codehaus.org/browse/MECLIPSE-94 -->
		<eclipseProjectDir>.</eclipseProjectDir>
	</configuration>
</plugin>

Note the project dir is now "." instead of ".."

GAH! The above hack only works for the .project file, NOT the .classpath file.

Your root project should not be a java project.

Generally the structure I use is:
root

• module 1
• module N

Checkout project from version control.

Run mvn eclipse:eclipse at the root.

Refresh project.

In Eclipse Navigator delete .project file, then File > Import... > Browse to root and click ok.
All your projects should appear, select them, Ok.

You are now ready to start working.

Having your root project be complicated is asking for trouble, and Maven only allows module aggregation via packaging type of pom anyway.

Ok, because the will of the maven-eclipse-plugin should not determine the multi-module folder structure for all projects in the universe, I have created a complete patch {{MECLIPSE-94-lonbinder.patch}}. Also, I created this patch off the latest 2.8 code, so it's more up-to-date than previous patch.

Three new config options now available:

• includeModulesInClasspath - If true the classpath config writer will include the dependencies of sub-modules in the given project.
• alwaysWriteProjectConfig - Always create the .project configuration for Maven projects regardless of packaging type.
• forceTreatAsJavaProject - Forces project to be treated as if it was a Java project. Maven packaging type will therefore be ignored and behaviors will be as if Java. This includes always creating the .classpath configuration.

One potential flaw, my implementation of filtering using wildcards in the includes/excludes paths is immature.