Re: maven-surefire-plugin does not fail build if TestNG and JUnit47 are used
Hi, 2.10 is rather old. Could you try it with a more recent version such as 2.17? Am Donnerstag, 11. September 2014 schrieb David Hoffer : I have a module where maven-surefire-plugin (2.10) is configured to use TestNG and JUnit47. The former has several tests that all succeed and the later has two tests that fail. However the build succeeds. How can I configure surefire so the build fails if either have failures which is the expected behavior?
Releasing Maven Plugins
Hi, I'm currently releasing a new version of Flexmojos. While I sort of found a procedure for releasing that maven plugin, it's still sort of a PITA. The main problem is that the project contains the plugin as well as some modules that use the plugin. Now in order to build, I have a minimal profile which builds only the plugin and after that I'm good to go with normal building. Now when doing a release, I usually do this: - mvn release:prepare (will fail as the plugin doesn't exist in the release version) - mvn -Pminimal install (Which installs the release version) - mvn release:rollback - mvn release:prepare - mvn release:perform (will fail as the new SNAPSHOT version of the plugin doesn't exist yet) - mvn -Pminimal install (Which installs the SNAPSHOT version) - mvn release:perform But to say that's ideal would be a lie ;-) Using version:set to update to the release version and the new SNAPSHOT version and doing a minimal build of each prior to the actual release, sort of doesn't sound ideal either :-( How do you guys do this when releasing maven plugins? Chris
Re: Releasing Maven Plugins
HI, I'm currently releasing a new version of Flexmojos. While I sort of found a procedure for releasing that maven plugin, it's still sort of a PITA. The main problem is that the project contains the plugin as well as some modules that use the plugin. This is the basic mistake in this scenario. If you build a maven-plugin make a separate project from it and do the release etc. only from the maven-plugin and afterwards you have the release available and can continue with the rest which uses the release... Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: Releasing Maven Plugins
But if I create a plugin using the official maven-plugin archetype the setup is almost the same so it can't be that off-track. Chris Von: Karl Heinz Marbaise khmarba...@gmx.de Gesendet: Freitag, 12. September 2014 14:46 An: Maven Users List Betreff: Re: Releasing Maven Plugins HI, I'm currently releasing a new version of Flexmojos. While I sort of found a procedure for releasing that maven plugin, it's still sort of a PITA. The main problem is that the project contains the plugin as well as some modules that use the plugin. This is the basic mistake in this scenario. If you build a maven-plugin make a separate project from it and do the release etc. only from the maven-plugin and afterwards you have the release available and can continue with the rest which uses the release... Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Releasing Maven Plugins
The main problem is that the project contains the plugin as well as some modules that use the plugin. This is the basic mistake in this scenario. If you build a maven-plugin make a separate project from it and do the release etc. only from the maven-plugin and afterwards you have the release available and can continue with the rest which uses the release... Although I haven't tried it myself, my understanding is that it should be possible to use a plugin built within a multi-module project in some of the other modules when using Maven 3.x. This is not possible with Maven 2.x though. However, it requires the plugin to be built before the modules that uses it (which the reactor should be able to calculate, unless there are some circular module dependencies). /Anders Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin does not fail build if TestNG and JUnit47 are used
I did try 2.17 to see if it would fix the problem but got an additional error (I forget what it was) so I reverted it back to 2.10. I ended up just converting the TestNG tests to use JUnit and all works fine now. -Dave On Fri, Sep 12, 2014 at 12:38 AM, Andreas Gudian andreas.gud...@gmail.com wrote: Hi, 2.10 is rather old. Could you try it with a more recent version such as 2.17? Am Donnerstag, 11. September 2014 schrieb David Hoffer : I have a module where maven-surefire-plugin (2.10) is configured to use TestNG and JUnit47. The former has several tests that all succeed and the later has two tests that fail. However the build succeeds. How can I configure surefire so the build fails if either have failures which is the expected behavior?
Re: How to get a dependency tree view of plugin dependencies used in the build
Yeah I did try dependency:resolve-plugins but that just shows the first level dependencies not what I needed. Seems like this would be a very useful goal to add to dependency plugin. -Dave On Wed, Sep 10, 2014 at 1:13 PM, Baptiste Mathus m...@batmat.net wrote: Found that, seems to match your question: http://stackoverflow.com/a/7079876/345845. Karl-Heinz is everywhere :-). 2014-09-10 16:50 GMT+02:00 David Hoffer dhoff...@gmail.com: Similar to dependency:tree for project dependencies how can I get a similar list of plugin dependencies used in the build? -Dave -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;!
AW: Releasing Maven Plugins
Unfortunately not. To me it seems as if the reactor checks if everything is available and if it's missing the build fails. The strange thing is that it only checks if something is there ... during the build the freshly built version of the plugin is used ... it's just that maven gives up before even starting :-| Chris Von: anders.g.ham...@gmail.com anders.g.ham...@gmail.com im Auftrag von Anders Hammar and...@hammar.net Gesendet: Freitag, 12. September 2014 15:07 An: Maven Users List Betreff: Re: Releasing Maven Plugins The main problem is that the project contains the plugin as well as some modules that use the plugin. This is the basic mistake in this scenario. If you build a maven-plugin make a separate project from it and do the release etc. only from the maven-plugin and afterwards you have the release available and can continue with the rest which uses the release... Although I haven't tried it myself, my understanding is that it should be possible to use a plugin built within a multi-module project in some of the other modules when using Maven 3.x. This is not possible with Maven 2.x though. However, it requires the plugin to be built before the modules that uses it (which the reactor should be able to calculate, unless there are some circular module dependencies). /Anders Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: AW: Releasing Maven Plugins
No I can't build with an empty local repo. I have to build the plugin first using the minimal profile. As i said in the other post, Maven gives up before starting to build. You can have a look ... the project is publicly available. Unfortunately I didn't create it ... I took over development 2 Years ago. https://github.com/chrisdutz/flexmojos Chris Von: Karl Heinz Marbaise khmarba...@gmx.de Gesendet: Freitag, 12. September 2014 15:17 An: Maven Users List Betreff: Re: AW: Releasing Maven Plugins Hi Chris, But if I create a plugin using the official maven-plugin archetype the setup is almost the same so it can't be that off-track. Which exactly have you used to do the setup... Furhtermore i would separate build tools for the build itself from using them... Apart from that what Anders is saying it is working but on the other hand you seemed to be having some problems so there must be problems in your build... Can you build on command line with a cleaned local repository without an issue just by using: mvn clean package ? Chris Von: Karl Heinz Marbaise khmarba...@gmx.de Gesendet: Freitag, 12. September 2014 14:46 An: Maven Users List Betreff: Re: Releasing Maven Plugins HI, I'm currently releasing a new version of Flexmojos. While I sort of found a procedure for releasing that maven plugin, it's still sort of a PITA. The main problem is that the project contains the plugin as well as some modules that use the plugin. This is the basic mistake in this scenario. If you build a maven-plugin make a separate project from it and do the release etc. only from the maven-plugin and afterwards you have the release available and can continue with the rest which uses the release... Kind regards - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: AW: Releasing Maven Plugins
Are you sure it's not pulled from the local repository? To check, remove that SNAPSHOT and run 'mvn verify' and NEVER 'mvn install'. Robert Op Fri, 12 Sep 2014 16:56:05 +0200 schreef Christofer Dutz christofer.d...@c-ware.de: Unfortunately not. To me it seems as if the reactor checks if everything is available and if it's missing the build fails. The strange thing is that it only checks if something is there ... during the build the freshly built version of the plugin is used ... it's just that maven gives up before even starting :-| Chris Von: anders.g.ham...@gmail.com anders.g.ham...@gmail.com im Auftrag von Anders Hammar and...@hammar.net Gesendet: Freitag, 12. September 2014 15:07 An: Maven Users List Betreff: Re: Releasing Maven Plugins The main problem is that the project contains the plugin as well as some modules that use the plugin. This is the basic mistake in this scenario. If you build a maven-plugin make a separate project from it and do the release etc. only from the maven-plugin and afterwards you have the release available and can continue with the rest which uses the release... Although I haven't tried it myself, my understanding is that it should be possible to use a plugin built within a multi-module project in some of the other modules when using Maven 3.x. This is not possible with Maven 2.x though. However, it requires the plugin to be built before the modules that uses it (which the reactor should be able to calculate, unless there are some circular module dependencies). /Anders Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: AW: Releasing Maven Plugins
Unfortunately I've tried that :-( I can't start the build at all if the plugin is not already in the repo as soon as a module intending on using the plugin is in reactor. Chris Von: Robert Scholte rfscho...@apache.org Gesendet: Freitag, 12. September 2014 17:08 An: Maven Users List Betreff: Re: AW: Releasing Maven Plugins Are you sure it's not pulled from the local repository? To check, remove that SNAPSHOT and run 'mvn verify' and NEVER 'mvn install'. Robert Op Fri, 12 Sep 2014 16:56:05 +0200 schreef Christofer Dutz christofer.d...@c-ware.de: Unfortunately not. To me it seems as if the reactor checks if everything is available and if it's missing the build fails. The strange thing is that it only checks if something is there ... during the build the freshly built version of the plugin is used ... it's just that maven gives up before even starting :-| Chris Von: anders.g.ham...@gmail.com anders.g.ham...@gmail.com im Auftrag von Anders Hammar and...@hammar.net Gesendet: Freitag, 12. September 2014 15:07 An: Maven Users List Betreff: Re: Releasing Maven Plugins The main problem is that the project contains the plugin as well as some modules that use the plugin. This is the basic mistake in this scenario. If you build a maven-plugin make a separate project from it and do the release etc. only from the maven-plugin and afterwards you have the release available and can continue with the rest which uses the release... Although I haven't tried it myself, my understanding is that it should be possible to use a plugin built within a multi-module project in some of the other modules when using Maven 3.x. This is not possible with Maven 2.x though. However, it requires the plugin to be built before the modules that uses it (which the reactor should be able to calculate, unless there are some circular module dependencies). /Anders Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Tell maven to not have the parent pom as a dependency?
The problem I have here is that this would definitely fix my problem. Breaking it out into another OSS project would be sweet… BUT… it would introduce its own set of problems. Now I have two projects to maintain. And the number is increasing… From an IDE perspective, I have to have N windows and switch between them, and remember which file is in which project. I find it’s 100x easier to just keep everything in one project. I could use git-submodules… but IDEA breaks on them and they have a few gotchas. … but perhaps there’s no perfect solution. Just a few solutions that are less horrible than my current solution. Kevin On Thu, Sep 11, 2014 at 10:53 PM, Barrie Treloar baerr...@gmail.com wrote: On 12 September 2014 12:55, Kevin Burton bur...@spinn3r.com wrote: I have an OSS module in a multi-module maven project. I want to post this to a public repo… it’s open source. The problem is that the parent module is not OSS. When I setup a dependency it pulls in my OSS module just fine, but then it tries to pull down the parent module, which isn’t in the repo, and breaks. The parent pom isn’t really a dependency… so I’d like it to not need it is this possible? As Dan says, make it a stand alone project. i.e. Dont make it a module. Being a module has a special meaning - treat this as part of a bigger whole. It also help with syntatic sugar by allowing you to run one command at the top and have it propogate into all the modules. To be complete a module has nothing to do with dependencies or dependency management. The reason your OSS module is pulling in the parent is not because of dependency, but because of inheritance of the parent hierarchy. Usually all modules are released together and will share version identifiers. If they are released independently then you normally wont make them modules, and their version identifiers can do their own thing. There is a recent post Maintaining versions in a multi-module project that Stephen answers, you might also want to search the archives on this topic as well. A parent pom can be used in two ways; 1) to share common information i.e. inheritance 2) keep related artifacts together to make working on a bug that traverses artifacts easier i.e aggregation In your case I dont think you need to use aggregation, you just need to pull out the OSS artifact into its own stand alone location and then include it as a normal dependency in your non-OSS project. If you find that you are also fixing bugs in the OSS project at the same time you are working on the non-OSS one, then you might want to create an aggregate pom that has two modules (one OSS, the other non-OSS) so that you can run maven commands in one place against both projects. Stephen Connolly has some stuff somewhere about that I think. The freely availble Maven books might also go into this in more detail, but it tends to be a more advanced feature not well described. Cheers Barrie -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com
Re: Tell maven to not have the parent pom as a dependency?
I think you can use an dummy aggregation project to host both of your internal and OSS and make IDE like eclipse happy root aggregate-proj pom.xml your-oss pom.xml your-internal -D pom.xml On Fri, Sep 12, 2014 at 8:58 AM, Kevin Burton bur...@spinn3r.com wrote: The problem I have here is that this would definitely fix my problem. Breaking it out into another OSS project would be sweet… BUT… it would introduce its own set of problems. Now I have two projects to maintain. And the number is increasing… From an IDE perspective, I have to have N windows and switch between them, and remember which file is in which project. I find it’s 100x easier to just keep everything in one project. I could use git-submodules… but IDEA breaks on them and they have a few gotchas. … but perhaps there’s no perfect solution. Just a few solutions that are less horrible than my current solution. Kevin On Thu, Sep 11, 2014 at 10:53 PM, Barrie Treloar baerr...@gmail.com wrote: On 12 September 2014 12:55, Kevin Burton bur...@spinn3r.com wrote: I have an OSS module in a multi-module maven project. I want to post this to a public repo… it’s open source. The problem is that the parent module is not OSS. When I setup a dependency it pulls in my OSS module just fine, but then it tries to pull down the parent module, which isn’t in the repo, and breaks. The parent pom isn’t really a dependency… so I’d like it to not need it is this possible? As Dan says, make it a stand alone project. i.e. Dont make it a module. Being a module has a special meaning - treat this as part of a bigger whole. It also help with syntatic sugar by allowing you to run one command at the top and have it propogate into all the modules. To be complete a module has nothing to do with dependencies or dependency management. The reason your OSS module is pulling in the parent is not because of dependency, but because of inheritance of the parent hierarchy. Usually all modules are released together and will share version identifiers. If they are released independently then you normally wont make them modules, and their version identifiers can do their own thing. There is a recent post Maintaining versions in a multi-module project that Stephen answers, you might also want to search the archives on this topic as well. A parent pom can be used in two ways; 1) to share common information i.e. inheritance 2) keep related artifacts together to make working on a bug that traverses artifacts easier i.e aggregation In your case I dont think you need to use aggregation, you just need to pull out the OSS artifact into its own stand alone location and then include it as a normal dependency in your non-OSS project. If you find that you are also fixing bugs in the OSS project at the same time you are working on the non-OSS one, then you might want to create an aggregate pom that has two modules (one OSS, the other non-OSS) so that you can run maven commands in one place against both projects. Stephen Connolly has some stuff somewhere about that I think. The freely availble Maven books might also go into this in more detail, but it tends to be a more advanced feature not well described. Cheers Barrie -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com
Re: Tell maven to not have the parent pom as a dependency?
Hi Kevin, I want to post this to a public repo… it’s open source. The problem is that the parent module is not OSS. Child modules of a multi-module build do not need to use the toplevel module as parent. In other words, you can keep using your toplevel pom.xml as an _aggregator_ without it being the _parent_ of your OSS module. http://rostislav-matl.blogspot.com/2011/12/maven-aggregator-vs-parent.html Regards, Curtis On Thu, Sep 11, 2014 at 10:25 PM, Kevin Burton bur...@spinn3r.com wrote: I have an OSS module in a multi-module maven project. I want to post this to a public repo… it’s open source. The problem is that the parent module is not OSS. When I setup a dependency it pulls in my OSS module just fine, but then it tries to pull down the parent module, which isn’t in the repo, and breaks. The parent pom isn’t really a dependency… so I’d like it to not need it is this possible? -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com
Re: Tell maven to not have the parent pom as a dependency?
In other words, you can keep using your toplevel pom.xml as an _aggregator_ without it being the _parent_ of your OSS module. Ha. That works. But the versions plugin now won’t update the version of the sub-module… This is super fun! :) On Fri, Sep 12, 2014 at 9:33 AM, Curtis Rueden ctrue...@wisc.edu wrote: Hi Kevin, I want to post this to a public repo… it’s open source. The problem is that the parent module is not OSS. Child modules of a multi-module build do not need to use the toplevel module as parent. In other words, you can keep using your toplevel pom.xml as an _aggregator_ without it being the _parent_ of your OSS module. http://rostislav-matl.blogspot.com/2011/12/maven-aggregator-vs-parent.html Regards, Curtis On Thu, Sep 11, 2014 at 10:25 PM, Kevin Burton bur...@spinn3r.com wrote: I have an OSS module in a multi-module maven project. I want to post this to a public repo… it’s open source. The problem is that the parent module is not OSS. When I setup a dependency it pulls in my OSS module just fine, but then it tries to pull down the parent module, which isn’t in the repo, and breaks. The parent pom isn’t really a dependency… so I’d like it to not need it is this possible? -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com
Re: Tell maven to not have the parent pom as a dependency?
OK… so this definitely works and the aggregation model compiles my module. But I need a way to bump the version number because I have complex dependencies and updating 10 places every time I change the project version isn’t going to be fun. On Fri, Sep 12, 2014 at 10:03 AM, Kevin Burton bur...@spinn3r.com wrote: In other words, you can keep using your toplevel pom.xml as an _aggregator_ without it being the _parent_ of your OSS module. Ha. That works. But the versions plugin now won’t update the version of the sub-module… This is super fun! :) On Fri, Sep 12, 2014 at 9:33 AM, Curtis Rueden ctrue...@wisc.edu wrote: Hi Kevin, I want to post this to a public repo… it’s open source. The problem is that the parent module is not OSS. Child modules of a multi-module build do not need to use the toplevel module as parent. In other words, you can keep using your toplevel pom.xml as an _aggregator_ without it being the _parent_ of your OSS module. http://rostislav-matl.blogspot.com/2011/12/maven-aggregator-vs-parent.html Regards, Curtis On Thu, Sep 11, 2014 at 10:25 PM, Kevin Burton bur...@spinn3r.com wrote: I have an OSS module in a multi-module maven project. I want to post this to a public repo… it’s open source. The problem is that the parent module is not OSS. When I setup a dependency it pulls in my OSS module just fine, but then it tries to pull down the parent module, which isn’t in the repo, and breaks. The parent pom isn’t really a dependency… so I’d like it to not need it is this possible? -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com
Re: Tell maven to not have the parent pom as a dependency?
You mentioned you were using the versions plugin and it wasn¹t working- did you use it before? Can you describe your use case in terms of the command line you are using, and what versions you want to upgrade? On 9/12/14, 10:16 AM, Kevin Burton bur...@spinn3r.com wrote: OKŠ so this definitely works and the aggregation model compiles my module. But I need a way to bump the version number because I have complex dependencies and updating 10 places every time I change the project version isn¹t going to be fun. On Fri, Sep 12, 2014 at 10:03 AM, Kevin Burton bur...@spinn3r.com wrote: In other words, you can keep using your toplevel pom.xml as an _aggregator_ without it being the _parent_ of your OSS module. Ha. That works. But the versions plugin now won¹t update the version of the sub-moduleŠ This is super fun! :) On Fri, Sep 12, 2014 at 9:33 AM, Curtis Rueden ctrue...@wisc.edu wrote: Hi Kevin, I want to post this to a public repoŠ it¹s open source. The problem is that the parent module is not OSS. Child modules of a multi-module build do not need to use the toplevel module as parent. In other words, you can keep using your toplevel pom.xml as an _aggregator_ without it being the _parent_ of your OSS module. http://rostislav-matl.blogspot.com/2011/12/maven-aggregator-vs-parent.ht ml Regards, Curtis On Thu, Sep 11, 2014 at 10:25 PM, Kevin Burton bur...@spinn3r.com wrote: I have an OSS module in a multi-module maven project. I want to post this to a public repoŠ it¹s open source. The problem is that the parent module is not OSS. When I setup a dependency it pulls in my OSS module just fine, but then it tries to pull down the parent module, which isn¹t in the repo, and breaks. The parent pom isn¹t really a dependencyŠ so I¹d like it to not need it is this possible? -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com Š or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com Š or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com Š or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Tell maven to not have the parent pom as a dependency?
Thanks… I just want to bump the version number on the release. I was using the auto increment fork of the versions number to make it easier… but I can use the versions plugin manually. I mean the general use case is I have about 20 modules and mildly complex inheritance and I don’t want to have to update 30-40 places when I bump a version number :-( On Fri, Sep 12, 2014 at 10:22 AM, Puncel, Robert (393J) robert.pun...@jpl.nasa.gov wrote: You mentioned you were using the versions plugin and it wasn¹t working- did you use it before? Can you describe your use case in terms of the command line you are using, and what versions you want to upgrade? On 9/12/14, 10:16 AM, Kevin Burton bur...@spinn3r.com wrote: OKŠ so this definitely works and the aggregation model compiles my module. But I need a way to bump the version number because I have complex dependencies and updating 10 places every time I change the project version isn¹t going to be fun. On Fri, Sep 12, 2014 at 10:03 AM, Kevin Burton bur...@spinn3r.com wrote: In other words, you can keep using your toplevel pom.xml as an _aggregator_ without it being the _parent_ of your OSS module. Ha. That works. But the versions plugin now won¹t update the version of the sub-moduleŠ This is super fun! :) On Fri, Sep 12, 2014 at 9:33 AM, Curtis Rueden ctrue...@wisc.edu wrote: Hi Kevin, I want to post this to a public repoŠ it¹s open source. The problem is that the parent module is not OSS. Child modules of a multi-module build do not need to use the toplevel module as parent. In other words, you can keep using your toplevel pom.xml as an _aggregator_ without it being the _parent_ of your OSS module. http://rostislav-matl.blogspot.com/2011/12/maven-aggregator-vs-parent.ht ml Regards, Curtis On Thu, Sep 11, 2014 at 10:25 PM, Kevin Burton bur...@spinn3r.com wrote: I have an OSS module in a multi-module maven project. I want to post this to a public repoŠ it¹s open source. The problem is that the parent module is not OSS. When I setup a dependency it pulls in my OSS module just fine, but then it tries to pull down the parent module, which isn¹t in the repo, and breaks. The parent pom isn¹t really a dependencyŠ so I¹d like it to not need it is this possible? -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com Š or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com Š or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com Š or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com
Improving the speed of ‘deploy’ ?
mvn package” on my code , without tests, is actually pretty fast. Takes about one minute. (I don’t need the tests btw as I’m using continuous integration and the code is already tested). One minute is pretty darn good… The problem is that ‘deploy’ takes about 7 minutes. That’s kind of not fun. I think the issue is that I”m using scpexe for my distributionManagement repository. Any options for improving the performance here? I think the issue is creating new SSH connections each time. I could use ControlPersist I think… which is an SSH feature to keep the SSH connection in the background and re-use it. Downside: This will require me to use a custom SSH config everywhere. Another option is to use a file:// repository which is local and then rsync the binaries over in one pass. Downside: kind of jacky and requires an additional step. Any other options ? -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com
forking plugin execution?
Is it possible to fork plugin execution so that it executes in a separate process? I think doxia+markdown has a threading bug with peg down. I get the attached exception. Works fine with default options but -T 8 breaks it. I assume if I just have the site plugin in a separate proc that it will probably work since I won’t have two site builds stepping on each other. java.lang.ClassCastException: java.lang.Integer cannot be cast to org.pegdown.ast.SuperNode at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:353) at org.parboiled.matchers.SequenceMatcher.match(SequenceMatcher.java:46) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) at org.parboiled.matchers.OneOrMoreMatcher.match(OneOrMoreMatcher.java:38) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) at org.parboiled.matchers.SequenceMatcher.match(SequenceMatcher.java:46) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) at org.parboiled.matchers.FirstOfMatcher.match(FirstOfMatcher.java:41) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) at org.parboiled.matchers.SequenceMatcher.match(SequenceMatcher.java:46) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) at org.parboiled.matchers.FirstOfMatcher.match(FirstOfMatcher.java:41) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) at org.parboiled.matchers.SequenceMatcher.match(SequenceMatcher.java:46) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) at org.parboiled.matchers.SequenceMatcher.match(SequenceMatcher.java:46) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) at org.parboiled.matchers.ZeroOrMoreMatcher.match(ZeroOrMoreMatcher.java:39) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) at org.parboiled.matchers.SequenceMatcher.match(SequenceMatcher.java:46) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) at org.parboiled.matchers.SequenceMatcher.match(SequenceMatcher.java:46) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) at org.parboiled.parserunners.BasicParseRunner.run(BasicParseRunner.java:72) at org.parboiled.parserunners.ReportingParseRunner.runBasicMatch(ReportingParseRunner.java:86) at org.parboiled.parserunners.ReportingParseRunner.run(ReportingParseRunner.java:66) at org.parboiled.parserunners.AbstractParseRunner.run(AbstractParseRunner.java:81) at org.pegdown.Parser.parseToParsingResult(Parser.java:1329) at org.pegdown.Parser.parseInternal(Parser.java:1316) at org.pegdown.Parser.parse(Parser.java:78) at org.pegdown.PegDownProcessor.parseMarkdown(PegDownProcessor.java:137) at org.apache.maven.doxia.module.markdown.MarkdownParser.parse(MarkdownParser.java:170) at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:398) at org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:51) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:311) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:129) at org.apache.maven.plugins.site.render.SiteMojo.renderDoxiaDocuments(SiteMojo.java:261) at org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:172) at org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:141) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132) ... 14 more Caused by: java.lang.ClassCastException: java.lang.Integer cannot be cast to org.pegdown.ast.SuperNode at org.pegdown.Parser.addAsChild(Parser.java:1251) at org.pegdown.Action$mNyPdk1ujbVDZrIU.run(Unknown Source) at org.parboiled.matchers.ActionMatcher.match(ActionMatcher.java:96) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) ... 65 more -- Founder/CEO Spinn3r.com Location: *San
Re: forking plugin execution?
On Sep 12, 2014, at 2:22 PM, Kevin Burton bur...@spinn3r.com wrote: Is it possible to fork plugin execution so that it executes in a separate process? No. Not unless the plugin supports forked execution. I'm not sure we'd ever want to support this anyway. Looks like it's loading two copies of the classes, or the thread context classloader is getting confused. If you can make a small self-contained project that reproduces the problem I can take a look. I think doxia+markdown has a threading bug with peg down. I get the attached exception. Works fine with default options but -T 8 breaks it. I assume if I just have the site plugin in a separate proc that it will probably work since I won’t have two site builds stepping on each other. java.lang.ClassCastException: java.lang.Integer cannot be cast to org.pegdown.ast.SuperNode at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:353) at org.parboiled.matchers.SequenceMatcher.match(SequenceMatcher.java:46) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) at org.parboiled.matchers.OneOrMoreMatcher.match(OneOrMoreMatcher.java:38) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) at org.parboiled.matchers.SequenceMatcher.match(SequenceMatcher.java:46) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) at org.parboiled.matchers.FirstOfMatcher.match(FirstOfMatcher.java:41) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) at org.parboiled.matchers.SequenceMatcher.match(SequenceMatcher.java:46) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) at org.parboiled.matchers.FirstOfMatcher.match(FirstOfMatcher.java:41) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) at org.parboiled.matchers.SequenceMatcher.match(SequenceMatcher.java:46) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) at org.parboiled.matchers.SequenceMatcher.match(SequenceMatcher.java:46) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) at org.parboiled.matchers.ZeroOrMoreMatcher.match(ZeroOrMoreMatcher.java:39) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) at org.parboiled.matchers.SequenceMatcher.match(SequenceMatcher.java:46) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) at org.parboiled.matchers.SequenceMatcher.match(SequenceMatcher.java:46) at org.parboiled.parserunners.BasicParseRunner.match(BasicParseRunner.java:77) at org.parboiled.MatcherContext.runMatcher(MatcherContext.java:338) at org.parboiled.parserunners.BasicParseRunner.run(BasicParseRunner.java:72) at org.parboiled.parserunners.ReportingParseRunner.runBasicMatch(ReportingParseRunner.java:86) at org.parboiled.parserunners.ReportingParseRunner.run(ReportingParseRunner.java:66) at org.parboiled.parserunners.AbstractParseRunner.run(AbstractParseRunner.java:81) at org.pegdown.Parser.parseToParsingResult(Parser.java:1329) at org.pegdown.Parser.parseInternal(Parser.java:1316) at org.pegdown.Parser.parse(Parser.java:78) at org.pegdown.PegDownProcessor.parseMarkdown(PegDownProcessor.java:137) at org.apache.maven.doxia.module.markdown.MarkdownParser.parse(MarkdownParser.java:170) at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:398) at org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:51) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:311) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:129) at org.apache.maven.plugins.site.render.SiteMojo.renderDoxiaDocuments(SiteMojo.java:261) at org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:172) at org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:141) at
Re: Improving the speed of ‘deploy’ ?
Hi Kevin, I think the issue is that I”m using scpexe for my distributionManagement repository. Is there some reason you can't just use wagon-ssh? http://stackoverflow.com/a/14404990 Regards, Curtis On Fri, Sep 12, 2014 at 1:11 PM, Kevin Burton bur...@spinn3r.com wrote: mvn package” on my code , without tests, is actually pretty fast. Takes about one minute. (I don’t need the tests btw as I’m using continuous integration and the code is already tested). One minute is pretty darn good… The problem is that ‘deploy’ takes about 7 minutes. That’s kind of not fun. I think the issue is that I”m using scpexe for my distributionManagement repository. Any options for improving the performance here? I think the issue is creating new SSH connections each time. I could use ControlPersist I think… which is an SSH feature to keep the SSH connection in the background and re-use it. Downside: This will require me to use a custom SSH config everywhere. Another option is to use a file:// repository which is local and then rsync the binaries over in one pass. Downside: kind of jacky and requires an additional step. Any other options ? -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com
Re: Improving the speed of ‘deploy’ ?
What about using https .. does that compare in speed or is it faster? If faster.. why not use it? manfred Curtis Rueden wrote on 12.09.2014 11:31: Hi Kevin, I think the issue is that I”m using scpexe for my distributionManagement repository. Is there some reason you can't just use wagon-ssh? http://stackoverflow.com/a/14404990 Regards, Curtis On Fri, Sep 12, 2014 at 1:11 PM, Kevin Burton bur...@spinn3r.com wrote: mvn package” on my code , without tests, is actually pretty fast. Takes about one minute. (I don’t need the tests btw as I’m using continuous integration and the code is already tested). One minute is pretty darn good… The problem is that ‘deploy’ takes about 7 minutes. That’s kind of not fun. I think the issue is that I”m using scpexe for my distributionManagement repository. Any options for improving the performance here? I think the issue is creating new SSH connections each time. I could use ControlPersist I think… which is an SSH feature to keep the SSH connection in the background and re-use it. Downside: This will require me to use a custom SSH config everywhere. Another option is to use a file:// repository which is local and then rsync the binaries over in one pass. Downside: kind of jacky and requires an additional step. Any other options ? -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Improving the speed of ‘deploy’ ?
Worth a shot.. I’m using scpexe which forks OpenSSH as it’s easier to use when I forward SSH auth… this way I’m not constantly entering passwords for machines I’ve already authenticated to... On Fri, Sep 12, 2014 at 11:31 AM, Curtis Rueden ctrue...@wisc.edu wrote: Hi Kevin, I think the issue is that I”m using scpexe for my distributionManagement repository. Is there some reason you can't just use wagon-ssh? http://stackoverflow.com/a/14404990 Regards, Curtis On Fri, Sep 12, 2014 at 1:11 PM, Kevin Burton bur...@spinn3r.com wrote: mvn package” on my code , without tests, is actually pretty fast. Takes about one minute. (I don’t need the tests btw as I’m using continuous integration and the code is already tested). One minute is pretty darn good… The problem is that ‘deploy’ takes about 7 minutes. That’s kind of not fun. I think the issue is that I”m using scpexe for my distributionManagement repository. Any options for improving the performance here? I think the issue is creating new SSH connections each time. I could use ControlPersist I think… which is an SSH feature to keep the SSH connection in the background and re-use it. Downside: This will require me to use a custom SSH config everywhere. Another option is to use a file:// repository which is local and then rsync the binaries over in one pass. Downside: kind of jacky and requires an additional step. Any other options ? -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com
How to modify version used by plugin transitive dependency?
I have a case where I to modify the version used by a transitive plugin
dependency and I'm not sure the best way to do this.
In my use case I have maven-antrun-plugin which has a dependency on
fmpp-maven-plugin which has a dependency on fmpp which uses version ranges
to specify its 4 dependencies one of those being freemarker. I need to fix
the version of freemarker (and maybe the other 3), how best can I do this?
I'm assuming I can't use my top level pluginManagement section because it's
not a plugin that I need to mange the version of. And I'm assuming I can't
use dependencyManagement for this because it's not a project dependency
that I need to mange either.
So what I have so far is exclude and then re-include in the plugin config.
Is this the right/best way to do this?
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
dependencies
dependency
groupIdant-contrib/groupId
artifactIdant-contrib/artifactId
version${ant-contrib.version}/version
exclusions
exclusion
groupIdant/groupId
artifactIdant/artifactId
/exclusion
/exclusions
/dependency
dependency
groupIdorg.apache.ant/groupId
artifactIdant-nodeps/artifactId
version${ant-nodeps.version}/version
/dependency
dependency
groupIdcom.googlecode.fmpp-maven-plugin/groupId
artifactIdfmpp-maven-plugin/artifactId
version${fmpp-maven-plugin.version}/version
exclusions
exclusion
groupIdorg.freemarker/groupId
artifactIdfreemarker/artifactId
/exclusion
/exclusions
/dependency
dependency
groupIdorg.freemarker/groupId
artifactIdfreemarker/artifactId
version${freemarker.version}/version
/dependency
/dependencies
-Dave
Re: Tell maven to not have the parent pom as a dependency?
On 13 September 2014 02:46, Kevin Burton bur...@spinn3r.com wrote:
OK… so this definitely works and the aggregation model compiles my module.
But I need a way to bump the version number because I have complex
dependencies and updating 10 places every time I change the project version
isn’t going to be fun.
If you have 10 places where the dependencies need changing you are doing it
wrong.
You should have zero version definitions in your modules.
All version definitions are in the topmost parent pom in the
dependencyManagement section.
If you have a bunch of things that share versions, you can also create a
property and then use something like ${mygroup.version} so that you only
need to update the property section once.
Have you read the freely available Maven books?
It's been long while since I've read them but I think this advice is in
there.
