[
https://jira.codehaus.org/browse/MECLIPSE-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lon Binder updated MECLIPSE-94:
-------------------------------
Attachment: MECLIPSE-94-lonbinder.patch
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}}.
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.
> Allow eclipse:eclipse to work on pom (and other) projects
> ---------------------------------------------------------
>
> Key: MECLIPSE-94
> URL: https://jira.codehaus.org/browse/MECLIPSE-94
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Improvement
> Affects Versions: 2.1
> Reporter: Felipe Leme
> Attachments: MECLIPSE-94-lonbinder.patch, MECLIPSE-94.patch
>
>
> I'm creating a Java EE project based on the m2book (which I was reviewing;
> it's not available yet...) and one of the projects is a pom-packaging project
> used for integration tests. According to Vincent, currently this project must
> be a pom (in fact, I tried to set it as jar, but then the test phase would be
> run anyway, which would cause the tests to fail), as it doesn't produces a
> jar. But as it has java files (on the src/main/it/java directory), I tried to
> call eclipse:eclipse but it fails, saying that "Not running eclipse plugin
> goal for pom project".
> For these scenarios, I think a propery would be enough. At first I thought
> something about a 'force' or 'forceGeneration' property, would enough, which
> the code change being from:
> if ( "pom".equals( packaging ) && eclipseProjectDir == null )
> to:
> if ( "pom".equals( packaging ) && eclipseProjectDir == null &&
> !forceGeneration )
> Then I realized there is other place where the pom nature is checked:
> if ( "pom".equals( packaging ) && eclipseProjectDir == null &&
> !forceGeneration )
> So, I think a better name for the property would be 'javaProject' and the
> change would be:
> final boolean isJavaProjectProperty = // read property; defaults to false...
> if ( "pom".equals( packaging ) && eclipseProjectDir == null &&
> !isJavaProjectProperty )
> isJavaProject = isJavaProjectProperty || !"ear".equals( packaging ) &&
> !"pom".equals( packaging );
> If nobody objects and someone is willing to apply the changes, I can provide
> such patch (with the proper test cases).
> -- Felipe
> PS: I'm assigning it to Vincent for now, as he 'dreamed' that such features
> already existed :-)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
