Re: the simplest possible maven plugin, sort of
On Tue, Sep 11, 2012 at 3:19 AM, Anders Hammar and...@hammar.net wrote: Switch to Maven 3 and this should work. Try it and report back! I did and it did. /Anders On Mon, Sep 10, 2012 at 11:22 PM, David Jencks david_jen...@yahoo.com wrote: Our experience in geronimo has always been that maven does not support this, and I thought for maven 3 it was announced that it never ever would. We have a proflie to build up through the plugin, then you can do the full build. Releasing is a pain as you have to do the manual profile build with the release-version code to get the plugin available in the local maven repo before running the actual release. If I'm wrong for any version of maven I'd love to know how :-) thanks david jencks On Sep 10, 2012, at 1:45 PM, Daniel Kulp wrote: Interesting… I wonder how I've managed to do CXF releases for all these years then. :-) Seriously, for CXF =2.5.x, I use Maven 2.2.1 and it just works. Parts of the build certainly do use the plugins that are built as part of the reactor. That said, we use install as the default target and not test or anything. I'm fairly certain it wouldn't work if we didn't use install as the target, but I'm not sure if that would work with 3.x either. The clean target doesn't work if the plugin is part of the reactor and not in .m2/repository. I'll give you that. Dan On Sep 10, 2012, at 2:59 PM, Anders Hammar and...@hammar.net wrote: I'm fairly sure this didn't work in Maven 2.x. It was one of the unsolvable Maven 2.x bugs which was fixed in Maven 3. The workaround would be to use an older released version of the plugin. Don't think running a build twice is/was a workable workaround as I can't see how that would work in a release process. /Anders On Mon, Sep 10, 2012 at 8:11 PM, Arnaud Héritier aherit...@gmail.com wrote: On Mon, Sep 10, 2012 at 5:30 PM, Benson Margulies bimargul...@gmail.comwrote: On Mon, Sep 10, 2012 at 11:25 AM, Daniel Kulp dk...@apache.org wrote: On Sep 10, 2012, at 11:14 AM, Benson Margulies bimargul...@gmail.com wrote: In Maven 2.x, the following was true; the reactor could not apply a plugin it had just built. So, if a particular problem required a plugin (e.g., for generating code), the plugin has to be an independent project that is built in advance. Is this still true in 3.x? I don't think this is/was true. CXF has always used it's own codegen plugins within its reactor build, even with Maven 2.x. Dan, I'll try it again, but I could have sworn that this only works by running 'mvn' twice, so that there's a SNAPSHOT in ~/.m2/repository. I'm almost sure I had the same experience like Benson. It doesn't work in one step because maven reads all projects in the reactor, then tries to resolve the plugin where you are using it and cannot because it was built. Arnaud - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
AW: the simplest possible maven plugin, sort of
In Flexmojos you have to run the build twice (The first with minimal profile turned on), because otherwise maven will complain about the plugin not being available. As soon as there is any artifact with that name I am able to build with only one run, because the build replaces/updates the plugin in my repo and from then on the updated plugin is used. So I think you are all right. Chris -Ursprüngliche Nachricht- Von: Benson Margulies [mailto:bimargul...@gmail.com] Gesendet: Dienstag, 11. September 2012 12:17 An: Maven Developers List Betreff: Re: the simplest possible maven plugin, sort of On Tue, Sep 11, 2012 at 3:19 AM, Anders Hammar and...@hammar.net wrote: Switch to Maven 3 and this should work. Try it and report back! I did and it did. /Anders On Mon, Sep 10, 2012 at 11:22 PM, David Jencks david_jen...@yahoo.com wrote: Our experience in geronimo has always been that maven does not support this, and I thought for maven 3 it was announced that it never ever would. We have a proflie to build up through the plugin, then you can do the full build. Releasing is a pain as you have to do the manual profile build with the release-version code to get the plugin available in the local maven repo before running the actual release. If I'm wrong for any version of maven I'd love to know how :-) thanks david jencks On Sep 10, 2012, at 1:45 PM, Daniel Kulp wrote: Interesting… I wonder how I've managed to do CXF releases for all these years then. :-) Seriously, for CXF =2.5.x, I use Maven 2.2.1 and it just works. Parts of the build certainly do use the plugins that are built as part of the reactor. That said, we use install as the default target and not test or anything. I'm fairly certain it wouldn't work if we didn't use install as the target, but I'm not sure if that would work with 3.x either. The clean target doesn't work if the plugin is part of the reactor and not in .m2/repository. I'll give you that. Dan On Sep 10, 2012, at 2:59 PM, Anders Hammar and...@hammar.net wrote: I'm fairly sure this didn't work in Maven 2.x. It was one of the unsolvable Maven 2.x bugs which was fixed in Maven 3. The workaround would be to use an older released version of the plugin. Don't think running a build twice is/was a workable workaround as I can't see how that would work in a release process. /Anders On Mon, Sep 10, 2012 at 8:11 PM, Arnaud Héritier aherit...@gmail.com wrote: On Mon, Sep 10, 2012 at 5:30 PM, Benson Margulies bimargul...@gmail.comwrote: On Mon, Sep 10, 2012 at 11:25 AM, Daniel Kulp dk...@apache.org wrote: On Sep 10, 2012, at 11:14 AM, Benson Margulies bimargul...@gmail.com wrote: In Maven 2.x, the following was true; the reactor could not apply a plugin it had just built. So, if a particular problem required a plugin (e.g., for generating code), the plugin has to be an independent project that is built in advance. Is this still true in 3.x? I don't think this is/was true. CXF has always used it's own codegen plugins within its reactor build, even with Maven 2.x. Dan, I'll try it again, but I could have sworn that this only works by running 'mvn' twice, so that there's a SNAPSHOT in ~/.m2/repository. I'm almost sure I had the same experience like Benson. It doesn't work in one step because maven reads all projects in the reactor, then tries to resolve the plugin where you are using it and cannot because it was built. Arnaud --- -- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
the simplest possible maven plugin, sort of
In Maven 2.x, the following was true; the reactor could not apply a plugin it had just built. So, if a particular problem required a plugin (e.g., for generating code), the plugin has to be an independent project that is built in advance. Is this still true in 3.x? On a related front, have any readers used any of the 'not in java' plugin development support, such as bsh? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: the simplest possible maven plugin, sort of
On Sep 10, 2012, at 11:14 AM, Benson Margulies bimargul...@gmail.com wrote: In Maven 2.x, the following was true; the reactor could not apply a plugin it had just built. So, if a particular problem required a plugin (e.g., for generating code), the plugin has to be an independent project that is built in advance. Is this still true in 3.x? I don't think this is/was true. CXF has always used it's own codegen plugins within its reactor build, even with Maven 2.x. Dan On a related front, have any readers used any of the 'not in java' plugin development support, such as bsh? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: the simplest possible maven plugin, sort of
On Mon, Sep 10, 2012 at 11:25 AM, Daniel Kulp dk...@apache.org wrote: On Sep 10, 2012, at 11:14 AM, Benson Margulies bimargul...@gmail.com wrote: In Maven 2.x, the following was true; the reactor could not apply a plugin it had just built. So, if a particular problem required a plugin (e.g., for generating code), the plugin has to be an independent project that is built in advance. Is this still true in 3.x? I don't think this is/was true. CXF has always used it's own codegen plugins within its reactor build, even with Maven 2.x. Dan, I'll try it again, but I could have sworn that this only works by running 'mvn' twice, so that there's a SNAPSHOT in ~/.m2/repository. Dan On a related front, have any readers used any of the 'not in java' plugin development support, such as bsh? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - 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
Re: the simplest possible maven plugin, sort of
On Mon, Sep 10, 2012 at 5:30 PM, Benson Margulies bimargul...@gmail.comwrote: On Mon, Sep 10, 2012 at 11:25 AM, Daniel Kulp dk...@apache.org wrote: On Sep 10, 2012, at 11:14 AM, Benson Margulies bimargul...@gmail.com wrote: In Maven 2.x, the following was true; the reactor could not apply a plugin it had just built. So, if a particular problem required a plugin (e.g., for generating code), the plugin has to be an independent project that is built in advance. Is this still true in 3.x? I don't think this is/was true. CXF has always used it's own codegen plugins within its reactor build, even with Maven 2.x. Dan, I'll try it again, but I could have sworn that this only works by running 'mvn' twice, so that there's a SNAPSHOT in ~/.m2/repository. I'm almost sure I had the same experience like Benson. It doesn't work in one step because maven reads all projects in the reactor, then tries to resolve the plugin where you are using it and cannot because it was built. Arnaud
Re: the simplest possible maven plugin, sort of
I'm fairly sure this didn't work in Maven 2.x. It was one of the unsolvable Maven 2.x bugs which was fixed in Maven 3. The workaround would be to use an older released version of the plugin. Don't think running a build twice is/was a workable workaround as I can't see how that would work in a release process. /Anders On Mon, Sep 10, 2012 at 8:11 PM, Arnaud Héritier aherit...@gmail.com wrote: On Mon, Sep 10, 2012 at 5:30 PM, Benson Margulies bimargul...@gmail.comwrote: On Mon, Sep 10, 2012 at 11:25 AM, Daniel Kulp dk...@apache.org wrote: On Sep 10, 2012, at 11:14 AM, Benson Margulies bimargul...@gmail.com wrote: In Maven 2.x, the following was true; the reactor could not apply a plugin it had just built. So, if a particular problem required a plugin (e.g., for generating code), the plugin has to be an independent project that is built in advance. Is this still true in 3.x? I don't think this is/was true. CXF has always used it's own codegen plugins within its reactor build, even with Maven 2.x. Dan, I'll try it again, but I could have sworn that this only works by running 'mvn' twice, so that there's a SNAPSHOT in ~/.m2/repository. I'm almost sure I had the same experience like Benson. It doesn't work in one step because maven reads all projects in the reactor, then tries to resolve the plugin where you are using it and cannot because it was built. Arnaud - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: the simplest possible maven plugin, sort of
Interesting… I wonder how I've managed to do CXF releases for all these years then. :-) Seriously, for CXF =2.5.x, I use Maven 2.2.1 and it just works. Parts of the build certainly do use the plugins that are built as part of the reactor. That said, we use install as the default target and not test or anything. I'm fairly certain it wouldn't work if we didn't use install as the target, but I'm not sure if that would work with 3.x either. The clean target doesn't work if the plugin is part of the reactor and not in .m2/repository. I'll give you that. Dan On Sep 10, 2012, at 2:59 PM, Anders Hammar and...@hammar.net wrote: I'm fairly sure this didn't work in Maven 2.x. It was one of the unsolvable Maven 2.x bugs which was fixed in Maven 3. The workaround would be to use an older released version of the plugin. Don't think running a build twice is/was a workable workaround as I can't see how that would work in a release process. /Anders On Mon, Sep 10, 2012 at 8:11 PM, Arnaud Héritier aherit...@gmail.com wrote: On Mon, Sep 10, 2012 at 5:30 PM, Benson Margulies bimargul...@gmail.comwrote: On Mon, Sep 10, 2012 at 11:25 AM, Daniel Kulp dk...@apache.org wrote: On Sep 10, 2012, at 11:14 AM, Benson Margulies bimargul...@gmail.com wrote: In Maven 2.x, the following was true; the reactor could not apply a plugin it had just built. So, if a particular problem required a plugin (e.g., for generating code), the plugin has to be an independent project that is built in advance. Is this still true in 3.x? I don't think this is/was true. CXF has always used it's own codegen plugins within its reactor build, even with Maven 2.x. Dan, I'll try it again, but I could have sworn that this only works by running 'mvn' twice, so that there's a SNAPSHOT in ~/.m2/repository. I'm almost sure I had the same experience like Benson. It doesn't work in one step because maven reads all projects in the reactor, then tries to resolve the plugin where you are using it and cannot because it was built. Arnaud - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: the simplest possible maven plugin, sort of
Our experience in geronimo has always been that maven does not support this, and I thought for maven 3 it was announced that it never ever would. We have a proflie to build up through the plugin, then you can do the full build. Releasing is a pain as you have to do the manual profile build with the release-version code to get the plugin available in the local maven repo before running the actual release. If I'm wrong for any version of maven I'd love to know how :-) thanks david jencks On Sep 10, 2012, at 1:45 PM, Daniel Kulp wrote: Interesting… I wonder how I've managed to do CXF releases for all these years then. :-) Seriously, for CXF =2.5.x, I use Maven 2.2.1 and it just works. Parts of the build certainly do use the plugins that are built as part of the reactor. That said, we use install as the default target and not test or anything. I'm fairly certain it wouldn't work if we didn't use install as the target, but I'm not sure if that would work with 3.x either. The clean target doesn't work if the plugin is part of the reactor and not in .m2/repository. I'll give you that. Dan On Sep 10, 2012, at 2:59 PM, Anders Hammar and...@hammar.net wrote: I'm fairly sure this didn't work in Maven 2.x. It was one of the unsolvable Maven 2.x bugs which was fixed in Maven 3. The workaround would be to use an older released version of the plugin. Don't think running a build twice is/was a workable workaround as I can't see how that would work in a release process. /Anders On Mon, Sep 10, 2012 at 8:11 PM, Arnaud Héritier aherit...@gmail.com wrote: On Mon, Sep 10, 2012 at 5:30 PM, Benson Margulies bimargul...@gmail.comwrote: On Mon, Sep 10, 2012 at 11:25 AM, Daniel Kulp dk...@apache.org wrote: On Sep 10, 2012, at 11:14 AM, Benson Margulies bimargul...@gmail.com wrote: In Maven 2.x, the following was true; the reactor could not apply a plugin it had just built. So, if a particular problem required a plugin (e.g., for generating code), the plugin has to be an independent project that is built in advance. Is this still true in 3.x? I don't think this is/was true. CXF has always used it's own codegen plugins within its reactor build, even with Maven 2.x. Dan, I'll try it again, but I could have sworn that this only works by running 'mvn' twice, so that there's a SNAPSHOT in ~/.m2/repository. I'm almost sure I had the same experience like Benson. It doesn't work in one step because maven reads all projects in the reactor, then tries to resolve the plugin where you are using it and cannot because it was built. Arnaud - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - 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
