|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Vincent Massol - 04/Apr/06 08:07 AM
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 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 POM projects are just metadata projects - they cannot contain any sources or tests. So I'm inclined to say "won't fix", except for maybe the fact to add a simple .project for pom projects 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
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:
The boring thing is that these projects are not visible from within Eclipse right now. 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) 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. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
Allow eclipse:eclipse to work on pom (and other) projects
