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.