Re: MECLIPSE-37 creating a new custom lifecycle for m-eclipse-p
Did you get my most recent response? (wasn't sure if it went awol or you were just looking for other alternatives) On 20/12/2008, at 7:42 AM, Barrie Treloar wrote: Anyone else with suggestions? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MECLIPSE-37 creating a new custom lifecycle for m-eclipse-p
On Sat, Dec 20, 2008 at 10:15 PM, Brett Porter br...@apache.org wrote: Did you get my most recent response? (wasn't sure if it went awol or you The packaging binding to do a new phase generate? I'm reluctant to go down this path because it requires a change to the pom to get ide support working. (Which shouldn't be needed) However if its the only way to restrict phase/plugins being run then perhaps its worth looking at. were just looking for other alternatives) I was also just poking for other peoples ideas. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MECLIPSE-37 creating a new custom lifecycle for m-eclipse-p
Anyone else with suggestions? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MECLIPSE-37 creating a new custom lifecycle for m-eclipse-p
baerrach wrote: See http://jira.codehaus.org/browse/MECLIPSE-37 There doesn't seem to be anything on the mailing lists to help with this problem. This is an interesting problem. I don't see any way to fix this other than changing Maven itself, unfortunately, but I think Arnaud's idea about the lifecycle is a good one. What about a generate lifecycle that just does all the generation phases (ie, the ones you've listed), and ends with a generate phase. Someone could bind eclipse/idea/whatever to that, and run mvn generate from the command line. We might need to hash out the details, but I think it's worth trying it to see if it works for your use case first to see if it is worthwhile pursuing further - you could do this on the maven-2.1.x branch and add it to the maven-core components.xml file. Cheers, Brett -- View this message in context: http://www.nabble.com/MECLIPSE-37-creating-a-new-custom-lifecycle-for-m-eclipse-p-tp20846234p20958158.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MECLIPSE-37 creating a new custom lifecycle for m-eclipse-p
See http://jira.codehaus.org/browse/MECLIPSE-37 There doesn't seem to be anything on the mailing lists to help with this problem. This is an interesting problem. I don't see any way to fix this other than changing Maven itself, unfortunately, but I think Arnaud's idea about the lifecycle is a good one. What about a generate lifecycle that just does all the generation phases (ie, the ones you've listed), and ends with a generate phase. Someone could bind eclipse/idea/whatever to that, and run mvn generate from the command line. We might need to hash out the details, but I think it's worth trying it to see if it works for your use case first to see if it is worthwhile pursuing further - you could do this on the maven-2.1.x branch and add it to the maven-core components.xml file. Thats fine and I think I can see how you would create it, but the binding to this phase is done via the pom's packaging. But the eclipse plugin (or any ide plugin) should not be changing the pom's packaging, i.e it will still be jar, war, etc. The @execute lifecycle=XXX syntax doesn't allow you to specify a builtin lifecycle. It only allows you to specify the one in your lifecycle.xml file. At least that is what my limited understanding obtained by fiddling has shown. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MECLIPSE-37 creating a new custom lifecycle for m-eclipse-p
On 12/12/2008, at 6:55 AM, Barrie Treloar wrote: See http://jira.codehaus.org/browse/MECLIPSE-37 There doesn't seem to be anything on the mailing lists to help with this problem. This is an interesting problem. I don't see any way to fix this other than changing Maven itself, unfortunately, but I think Arnaud's idea about the lifecycle is a good one. What about a generate lifecycle that just does all the generation phases (ie, the ones you've listed), and ends with a generate phase. Someone could bind eclipse/idea/whatever to that, and run mvn generate from the command line. We might need to hash out the details, but I think it's worth trying it to see if it works for your use case first to see if it is worthwhile pursuing further - you could do this on the maven-2.1.x branch and add it to the maven-core components.xml file. Thats fine and I think I can see how you would create it, but the binding to this phase is done via the pom's packaging. But the eclipse plugin (or any ide plugin) should not be changing the pom's packaging, i.e it will still be jar, war, etc. Not quite what I meant... if you had a new lifecycle, each packaging would need to declare their bindings for that. So it has the upside of being more general and a lower impact change to Maven's internals, but the downside that non-core packagings would need to add a definition to support it. I was thinking along the lines that you'd then start adding this to the pom: plugin artifactIdmaven-eclipse-plugin/artifactId executions execution goals goalgenerate/goal /goals /execution /executions /plugin then run mvn generate instead of eclipse:eclipse (though that would still work). This let's the one eclipse plugin work across both versions of maven. This is a lifecycle the IDE integration could later use much more happily I think as well. Still thinking it through - but it seems worth prototyping to try. The @execute lifecycle=XXX syntax doesn't allow you to specify a builtin lifecycle. It only allows you to specify the one in your lifecycle.xml file. At least that is what my limited understanding obtained by fiddling has shown. Yep, but phase= will use a built-in lifecycle. The problem is that to add a built-in lifecycle, you need to incr. the version of Maven, and the Eclipse plugin then won't work on older ones. Hope this is making some sense. -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MECLIPSE-37 creating a new custom lifecycle for m-eclipse-p
No suggestions to help Barrie ? Arnaud On Fri, Dec 5, 2008 at 2:35 AM, Barrie Treloar [EMAIL PROTECTED] wrote: See http://jira.codehaus.org/browse/MECLIPSE-37 There doesn't seem to be anything on the mailing lists to help with this problem. There is one person on the mailing list wanting to create a new custom lifecycle (which is what I think is needed) and not configuring an overlay of an existing lifecycle. The discussion is around not using the default build lifecycle and to create a new lifecycle with the following phases: phases phasegenerate-sources/phase phasegenerate-resources/phase phasegenerate-test-sources/phase phasegenerate-test-resources/phase /phases So that compilation, etc is not needed in order to create the eclipse project files. My investigation has lead me to the following conclusions: META-INF/maven/lifecycle.xml Is used to hook the current Mojo into an existing lifecycle (the one bound to the packaging). The id in the lifecycle.xml is only used for lookup and the phases are overlaid on the existing lifecycle. It is not used to define your own lifecycle (with custom phases - or dropping existing phases) META-INF/plexus/components.xml When the packaging is eclipse-plugin (for creating eclipse pde project files) then this defines a new org.apache.maven.lifecycle.mapping.LifecycleMapping and org.apache.maven.artifact.handler.ArtifactHandler. Giving it a completely new and independent lifecycle. However, the eclipse plugin needs its own lifecycle regardless of the packaging type of the pom. I can use @execute phase=generate-resources lifecycle=eclipse-plugin But this only works if the plugin has been configured with extensionstrue/extensions Which needs the plugin to be defined with this option in the pom.xml I'd like to see extensions turned on by default for any command line invoked plugin. The http://maven.apache.org/developers/mojo-api-specification.html indicates that it should be running the alternative lifecycle, but I am finding that it runs the default lifecycle. e.g. if I change the phase to verify (which does not exist in my lifecycle above) then I can see in the build-output logs that it is running the default lifecycle, with whatever plugins are attached to those phases for that packaging. i.e for packaging eclipse-plugin it is using the lifecycle defined in components.xml and only running those four phases. But for other packaging it is using the lifecycle for that packaging and whatever additional bindings that have been defined in lifecycle.xml. Also trying to use a different built-in lifecycle like site fails with Lifecycle 'site' not found in plugin, so no go hacking through that route. maven-lifecycle/src/main/mdo/maven-lifecycle.mdo (https://svn.apache.org/repos/asf/maven/components/trunk/maven-lifecycle) This defines the lifecyles in maven. There doesn't appear to be any way to add to this list at runtime via a plugin. I've tried adding a new org.apache.maven.lifecycle.LifecycleExecutor similar to http://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/maven-core/src/main/resources/META-INF/plexus/components.xml in the plugin's META-INF/plexus/components.xml file in the hope that this one will be picked up by Maven instead of the one in maven-core but that was just wishful thinking (my lack of Plexus knowledge is showing). Anyone have suggestions? Thanks Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER 12 guidelines to boost your productivity with a Java software factory - http://tinyurl.com/56s9tw .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...
