custom lifecycle without inheritance
Hello, I am trying to invoke a single goal before another (ant-based) Mojo executes. Due to http://jira.codehaus.org/browse/MNG-5405 I cannot just do exeecutiongoalfoo:bar/goal/execution in the mojo.xml for the plugin. So instead, I've defined a lifecycle.xml, with only one goal in it. This works fine as a workaround for now, except that the forked lifecycle inherits the goals from the lifecycle of the project that is running the mojo in the first place. In some of our projects, we have a lot of custom mojos running, even in the initialize phase. So...is there a way to: a) define a new phase name (I don't think so) or b) make it so that the lifecycle.xml only runs what is defined there and does not inherit the project's lifecycle? -- Ben Tatham Software Developer Nanometrics Inc. +1 613-592-6776 x254 http://www.nanometrics.ca
components.xml in maven-plugin-plugin 3.1
Before I report a bug, I thought I'd ask if I'm doing something wrong. I have a plugin that has a bunch of mojo's as well as defines components.xml to set up a new lifecycle. I recently converted it from maven-plugin-plugin 2.9 to 3.1 and used java5 annotations. Note that the mojo's are in groovy. I also upgraded the maven version from 2.2.1 to 3.0.4 (which, on our small team, we can enforce that everyone is using). I believe most of that should be irrelevant, but I am unclear on the details of Maven determines the lifecycle based on the packaging declaration and plugins. I did not change my components.xml at all.But now, the projects the use the packaging get an Unknown packaging error. The components.xml is still in the plugin's jar in my maven repository in the same location. Has anyone else run into this issue? When running maven on the projects that use the defined lifecycle, does maven require any other information about the new lifecycle other than the components.xml being in the plugin's jar? I don't see it, but it there something in the plugin.xml (plugin descriptor) that perhaps has changed? If this warrants a bug, let me know and I'll create one with relevant files, etc. Thanks, Ben -- Ben Tatham Software Developer Nanometrics Inc. +1 613-592-6776 x254 http://www.nanometrics.ca
Re: components.xml in maven-plugin-plugin 3.1
Sorry everyone. Yet again, it's my fault. Please ignore this thread. Apparently, I inadverntently moved the src/main/resources/META-INF/plexus directory out if META-INF and right into src/main/resources and my eyes didn't catch that part of the diff. -Ben On Thu, Aug 30, 2012 at 1:06 PM, Ben Tatham bentat...@nanometrics.cawrote: Before I report a bug, I thought I'd ask if I'm doing something wrong. I have a plugin that has a bunch of mojo's as well as defines components.xml to set up a new lifecycle. I recently converted it from maven-plugin-plugin 2.9 to 3.1 and used java5 annotations. Note that the mojo's are in groovy. I also upgraded the maven version from 2.2.1 to 3.0.4 (which, on our small team, we can enforce that everyone is using). I believe most of that should be irrelevant, but I am unclear on the details of Maven determines the lifecycle based on the packaging declaration and plugins. I did not change my components.xml at all.But now, the projects the use the packaging get an Unknown packaging error. The components.xml is still in the plugin's jar in my maven repository in the same location. Has anyone else run into this issue? When running maven on the projects that use the defined lifecycle, does maven require any other information about the new lifecycle other than the components.xml being in the plugin's jar? I don't see it, but it there something in the plugin.xml (plugin descriptor) that perhaps has changed? If this warrants a bug, let me know and I'll create one with relevant files, etc. Thanks, Ben -- Ben Tatham Software Developer Nanometrics Inc. +1 613-592-6776 x254 http://www.nanometrics.ca -- Ben Tatham Software Developer Nanometrics Inc. +1 613-592-6776 x254 http://www.nanometrics.ca
Re: java-annotations with groovy
Thanks - maven-plugin-plugin 2.4 didn't have java5 annotations, so it wouldn't work there regardless. The issue seems to be the groovy compiler since it works sometimes (when greclipse generates the class files, but not when gmaven-plugin generates them). For now, I'll (unfortunately) stick with javadoc annotations. -Ben On Thu, Aug 23, 2012 at 5:40 PM, Hervé BOUTEMY herve.bout...@free.frwrote: ok, I didn't know this one IIUC, it's based on groovy-maven-plugin, which does woodoo to transform Groovy to java plugin without maven-plugin-plugin being aware of it If you open a Jira issue with a testcase working with maven-plugin-plugin 2.4, I can have a look to find why it stops working with 3.1. Regards, Hervé Le jeudi 23 août 2012 13:45:14 Manfred Moser a écrit : It at least was possible to write a plugin in Groovy without annotations though. See http://www.sonatype.com/books/mcookbook/reference/writing-plugins-alternativ e-sect-writing-groovy.html Not sure what happened.. manfred On Thu, August 23, 2012 1:18 pm, Hervé BOUTEMY wrote: Groovy isn't actually supported: see maven-script part of http://maven.apache.org/plugin-tools/ There isn't even anybody who opened a Jira issue about this. Regards, Hervé Le mercredi 22 août 2012 14:07:39 Ben Tatham a écrit : I am trying to use java-annotations (not javadoc) on a Mojo written in groovy, as per [1]. (I need them so I can subclass the mojo in other, multiple plugins, as annotations are, in theory, much easier than the Maven 2 ways of doing plugin extension). However, the maven-plugin-plugin 3.1 does not find any of the mojo definitions when building. I have tried various versions of gmaven and groovy-runtime with different failure conditions, but none of which work. Has anyone else tried this before? Thanks, Ben [1] http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-a nno tations.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Ben Tatham Software Developer Nanometrics Inc. +1 613-592-6776 x254 http://www.nanometrics.ca
java-annotations with groovy
I am trying to use java-annotations (not javadoc) on a Mojo written in groovy, as per [1]. (I need them so I can subclass the mojo in other, multiple plugins, as annotations are, in theory, much easier than the Maven 2 ways of doing plugin extension). However, the maven-plugin-plugin 3.1 does not find any of the mojo definitions when building. I have tried various versions of gmaven and groovy-runtime with different failure conditions, but none of which work. Has anyone else tried this before? Thanks, Ben [1] http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html -- Ben Tatham Software Developer Nanometrics Inc. +1 613-592-6776 x254 http://www.nanometrics.ca
plugin should run on all modules
I have a custom plugin that I run on all our projects as part of the release:perform goal. We are just starting to use multi-module builds, and I notice that my plugin only runs at the top module. What do I have to do to my plugin to make it run on all the modules individually at the end of the release? Do I have to iterate through them in the plugin code itself? If so, is there an example of doing that, because from what I see, MavenProject.getModules() just returns a list of String names of those modules. I've tried with and without @aggregator, but that doesn't change anything with respect to my problem. I'm assuming this is the same case as running the plugin directly (not tied to a phase) from CLI, which also only runs on the top-level of the project, and reports SKIPPED for all the sub-modules. Any advice on this issue would be very helpful... Thanks, -- Ben Tatham Software Developer Nanometrics Inc. +1 613-592-6776 x254 http://www.nanometrics.ca
Re: [VOTE] Release Apache Maven 3.0-beta-2
+1 Works well on our complex projects too. -Ben On Sat, Aug 7, 2010 at 7:16 AM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Hi, We solved 28 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=16090 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500status=1 Staging repo: https://repository.apache.org/content/repositories/maven-069/ Staged source and binary distros: https://repository.apache.org/content/repositories/maven-069/org/apache/maven/apache-maven/3.0-beta-2/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 +1 from me Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
modify surefire in place via a plugin
Is it possible to modify the run of the surefire plugin from another plugin? I would like to be able to set some systemProperties and argLine from another plugin, but I don't want to have to run the tests a second time. (I want to set the -javaagent, etc). Ideally, I would like to be able to do this from a plugin so the dependcies (the javaagent jar) can be available, and my plugin takes care of all the setup, and post-processing for a report. -Ben PS In case you are interested, it is to wrap JCarder (http://jcarder.org) into a maven plugin, and eventually into Hudson and Sonar plugins. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven-source-plugin
Hello, I am new to this list, but I thought I would see what it takes to join a project as a committer, or at least be a suggester. My issue is that the maven-source-plugin mojos have @execute phase=generate-sources. This is great for the command line, but when using the plugin from a pom, its kind of annoying. In my case, xdoclet gets run multiple times. According to this, http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html there is no way around this. In any case, I like what the assembly plugin does...they have assembly:assembly and assembly:attached in order to distinguish the two. Makes perfect sense. All we need is a subclass of the Mojos to get rid of the @execute. Easy, peasy... I am happy to do the work, but I need to learn how to join projects...I guess sending this email is the first step? -Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
