Re: Fully automated building from Source Control
Hi, You could use Maven SCM plugin for bootstrapping the project with minimal pom. http://maven.apache.org/scm/maven-scm-plugin/examples/bootstrapping-with-pom.html rgds, Markku On 3.4.2010 0:09, Steve Cohen wrote: Ok, your needs are probably more extreme than mine. I HAPPEN at present to be the only developer actively engaged on this project so I can get away with non-holy-grail stuff - which explains why I stayed so long with the Eclipse setup, but I would still like to get to the single-command-line total rebuild from scratch. I have less need for CI and as the only developer I can even get away with a local repository (for now) but I would still like to move this ball down the field so it would be easier to extend should things get more complicated. Are you saying then, that managing of builds at this level must depend on something outside of Maven? I'm not likely to find funding for anything more sophisticated than that (I work for a budget-strapped small team inside a large corporation that is off to the side), so I am interested in a solution that depends on nothing beyond Maven itself. We have and use Subversion, and that's about it. David Hoffer wrote: That holy grail is the only way to use maven, imho. I don't know about a single documentation source but there is lots of info available on the web to achieve this. In short we use TeamCity for CI, Artifactory for corporate maven repo, SVN Maven. -Dave On Fri, Apr 2, 2010 at 2:48 PM, Steve Cohensco...@javactivity.org wrote: Over the past few months I have slowly and, on the whole successfully, migrated a project that was based on Eclipse to one that is based on maven (and m2eclipse), in the process, learning much about Maven and I'm generally quite happy with it. It's a nice improvement. The one step I haven't taken yet is generating a fully automated build starting with pristine sources, checking everything it needs out from Source Control and then building it. That has always seemed to me to be the holy grail of automated building, going back to the make days. You nuke all the source, get a fresh copy from the source control (tied to a given tag) and build from scratch. We don't want anything from a developer's working copy involved in any way. I haven't done this with Maven yet and to be fair, I also hadn't done it with the earlier Eclipse-based system in use here but I still want to do it. And yes, I understand that there is a bit of a chicken-egg problem here - where is this definition of everything to be version controlled and how do you avoid nuking that? So there has to be something of a two-tier setup. I know this and accept it. I hadn't spent much time looking at the Maven SCM plugin, but now that I have, I don't really see what I'm looking for there. The examples tend to be very sparse, and Maven - The Definitive Guide doesn't even touch the SCM plugin. Can someone point me at documentation directed toward achieving this holy grail with Maven? Thanks. - 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: Fully automated building from Source Control
mvn scm:bootstrap -DconnectionUrl=maven-scm-url-to-your-soruce -Dgoals=-B release:prepare release:perform will checkout your project, tag it, build from the tag, and finally deploy your artifact to your maven repo. (please look up for the precise syntax) mvn scm:bootstrap -DconnectionUrl=maven-scm-url-to-your-soruce -Dgoals=install will check out your project and built it On Fri, Apr 2, 2010 at 11:28 PM, Markku Saarela markku.saar...@iki.fi wrote: Hi, You could use Maven SCM plugin for bootstrapping the project with minimal pom. http://maven.apache.org/scm/maven-scm-plugin/examples/bootstrapping-with-pom.html rgds, Markku On 3.4.2010 0:09, Steve Cohen wrote: Ok, your needs are probably more extreme than mine. I HAPPEN at present to be the only developer actively engaged on this project so I can get away with non-holy-grail stuff - which explains why I stayed so long with the Eclipse setup, but I would still like to get to the single-command-line total rebuild from scratch. I have less need for CI and as the only developer I can even get away with a local repository (for now) but I would still like to move this ball down the field so it would be easier to extend should things get more complicated. Are you saying then, that managing of builds at this level must depend on something outside of Maven? I'm not likely to find funding for anything more sophisticated than that (I work for a budget-strapped small team inside a large corporation that is off to the side), so I am interested in a solution that depends on nothing beyond Maven itself. We have and use Subversion, and that's about it. David Hoffer wrote: That holy grail is the only way to use maven, imho. I don't know about a single documentation source but there is lots of info available on the web to achieve this. In short we use TeamCity for CI, Artifactory for corporate maven repo, SVN Maven. -Dave On Fri, Apr 2, 2010 at 2:48 PM, Steve Cohensco...@javactivity.org wrote: Over the past few months I have slowly and, on the whole successfully, migrated a project that was based on Eclipse to one that is based on maven (and m2eclipse), in the process, learning much about Maven and I'm generally quite happy with it. It's a nice improvement. The one step I haven't taken yet is generating a fully automated build starting with pristine sources, checking everything it needs out from Source Control and then building it. That has always seemed to me to be the holy grail of automated building, going back to the make days. You nuke all the source, get a fresh copy from the source control (tied to a given tag) and build from scratch. We don't want anything from a developer's working copy involved in any way. I haven't done this with Maven yet and to be fair, I also hadn't done it with the earlier Eclipse-based system in use here but I still want to do it. And yes, I understand that there is a bit of a chicken-egg problem here - where is this definition of everything to be version controlled and how do you avoid nuking that? So there has to be something of a two-tier setup. I know this and accept it. I hadn't spent much time looking at the Maven SCM plugin, but now that I have, I don't really see what I'm looking for there. The examples tend to be very sparse, and Maven - The Definitive Guide doesn't even touch the SCM plugin. Can someone point me at documentation directed toward achieving this holy grail with Maven? Thanks. - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Fully automated building from Source Control
But those for for demo only to show off the holygrail maven commands :-) Use a CI server to do you checkout and cut your release. On Sat, Apr 3, 2010 at 12:10 AM, Dan Tran dant...@gmail.com wrote: mvn scm:bootstrap -DconnectionUrl=maven-scm-url-to-your-soruce -Dgoals=-B release:prepare release:perform will checkout your project, tag it, build from the tag, and finally deploy your artifact to your maven repo. (please look up for the precise syntax) mvn scm:bootstrap -DconnectionUrl=maven-scm-url-to-your-soruce -Dgoals=install will check out your project and built it On Fri, Apr 2, 2010 at 11:28 PM, Markku Saarela markku.saar...@iki.fi wrote: Hi, You could use Maven SCM plugin for bootstrapping the project with minimal pom. http://maven.apache.org/scm/maven-scm-plugin/examples/bootstrapping-with-pom.html rgds, Markku On 3.4.2010 0:09, Steve Cohen wrote: Ok, your needs are probably more extreme than mine. I HAPPEN at present to be the only developer actively engaged on this project so I can get away with non-holy-grail stuff - which explains why I stayed so long with the Eclipse setup, but I would still like to get to the single-command-line total rebuild from scratch. I have less need for CI and as the only developer I can even get away with a local repository (for now) but I would still like to move this ball down the field so it would be easier to extend should things get more complicated. Are you saying then, that managing of builds at this level must depend on something outside of Maven? I'm not likely to find funding for anything more sophisticated than that (I work for a budget-strapped small team inside a large corporation that is off to the side), so I am interested in a solution that depends on nothing beyond Maven itself. We have and use Subversion, and that's about it. David Hoffer wrote: That holy grail is the only way to use maven, imho. I don't know about a single documentation source but there is lots of info available on the web to achieve this. In short we use TeamCity for CI, Artifactory for corporate maven repo, SVN Maven. -Dave On Fri, Apr 2, 2010 at 2:48 PM, Steve Cohensco...@javactivity.org wrote: Over the past few months I have slowly and, on the whole successfully, migrated a project that was based on Eclipse to one that is based on maven (and m2eclipse), in the process, learning much about Maven and I'm generally quite happy with it. It's a nice improvement. The one step I haven't taken yet is generating a fully automated build starting with pristine sources, checking everything it needs out from Source Control and then building it. That has always seemed to me to be the holy grail of automated building, going back to the make days. You nuke all the source, get a fresh copy from the source control (tied to a given tag) and build from scratch. We don't want anything from a developer's working copy involved in any way. I haven't done this with Maven yet and to be fair, I also hadn't done it with the earlier Eclipse-based system in use here but I still want to do it. And yes, I understand that there is a bit of a chicken-egg problem here - where is this definition of everything to be version controlled and how do you avoid nuking that? So there has to be something of a two-tier setup. I know this and accept it. I hadn't spent much time looking at the Maven SCM plugin, but now that I have, I don't really see what I'm looking for there. The examples tend to be very sparse, and Maven - The Definitive Guide doesn't even touch the SCM plugin. Can someone point me at documentation directed toward achieving this holy grail with Maven? Thanks. - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Fully automated building from Source Control
+1 CI server is the best way to support such process with full automation 2010/4/3 Dan Tran dant...@gmail.com But those for for demo only to show off the holygrail maven commands :-) Use a CI server to do you checkout and cut your release. On Sat, Apr 3, 2010 at 12:10 AM, Dan Tran dant...@gmail.com wrote: mvn scm:bootstrap -DconnectionUrl=maven-scm-url-to-your-soruce -Dgoals=-B release:prepare release:perform will checkout your project, tag it, build from the tag, and finally deploy your artifact to your maven repo. (please look up for the precise syntax) mvn scm:bootstrap -DconnectionUrl=maven-scm-url-to-your-soruce -Dgoals=install will check out your project and built it On Fri, Apr 2, 2010 at 11:28 PM, Markku Saarela markku.saar...@iki.fi wrote: Hi, You could use Maven SCM plugin for bootstrapping the project with minimal pom. http://maven.apache.org/scm/maven-scm-plugin/examples/bootstrapping-with-pom.html rgds, Markku On 3.4.2010 0:09, Steve Cohen wrote: Ok, your needs are probably more extreme than mine. I HAPPEN at present to be the only developer actively engaged on this project so I can get away with non-holy-grail stuff - which explains why I stayed so long with the Eclipse setup, but I would still like to get to the single-command-line total rebuild from scratch. I have less need for CI and as the only developer I can even get away with a local repository (for now) but I would still like to move this ball down the field so it would be easier to extend should things get more complicated. Are you saying then, that managing of builds at this level must depend on something outside of Maven? I'm not likely to find funding for anything more sophisticated than that (I work for a budget-strapped small team inside a large corporation that is off to the side), so I am interested in a solution that depends on nothing beyond Maven itself. We have and use Subversion, and that's about it. David Hoffer wrote: That holy grail is the only way to use maven, imho. I don't know about a single documentation source but there is lots of info available on the web to achieve this. In short we use TeamCity for CI, Artifactory for corporate maven repo, SVN Maven. -Dave On Fri, Apr 2, 2010 at 2:48 PM, Steve Cohensco...@javactivity.org wrote: Over the past few months I have slowly and, on the whole successfully, migrated a project that was based on Eclipse to one that is based on maven (and m2eclipse), in the process, learning much about Maven and I'm generally quite happy with it. It's a nice improvement. The one step I haven't taken yet is generating a fully automated build starting with pristine sources, checking everything it needs out from Source Control and then building it. That has always seemed to me to be the holy grail of automated building, going back to the make days. You nuke all the source, get a fresh copy from the source control (tied to a given tag) and build from scratch. We don't want anything from a developer's working copy involved in any way. I haven't done this with Maven yet and to be fair, I also hadn't done it with the earlier Eclipse-based system in use here but I still want to do it. And yes, I understand that there is a bit of a chicken-egg problem here - where is this definition of everything to be version controlled and how do you avoid nuking that? So there has to be something of a two-tier setup. I know this and accept it. I hadn't spent much time looking at the Maven SCM plugin, but now that I have, I don't really see what I'm looking for there. The examples tend to be very sparse, and Maven - The Definitive Guide doesn't even touch the SCM plugin. Can someone point me at documentation directed toward achieving this holy grail with Maven? Thanks. - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: release:perform makes a bigger war file than release:prepare
Hi, Please create a small test project and file an issue in the maven bug tracker (jira). Cheers 2010/4/1 KALLURI, RAJESH K [AG/2001] rajesh.k.kall...@monsanto.com Hi, I am trying to package a war file for a webstart application that does not need the jars in WEB-INF\lib folder. Here is the snippet from my POM for maven-war-plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId version2.1-beta-1/version configuration packagingExcludesWEB-INF/lib/*.jar/packagingExcludes useCachefalse/useCache /configuration /plugin Release:prepare works fine and packages a war without the jars in the lib as I want. Release:perform includes the war and bloats it up. Anybody has ideas on what I can do to fix this. Thanks Raj - This e-mail message may contain privileged and/or confidential information, and is intended to be received only by persons entitled to receive such information. If you have received this e-mail in error, please notify the sender immediately. Please delete it and all attachments from any servers, hard drives or any other media. Other use of this e-mail by you is strictly prohibited. All e-mails and attachments sent and received are subject to monitoring, reading and archival by Monsanto, including its subsidiaries. The recipient of this e-mail is solely responsible for checking for the presence of Viruses or other Malware. Monsanto, along with its subsidiaries, accepts no liability for any damage caused by any such code transmitted by or accompanying this e-mail or any attachment. - -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: Executing with Maven
Hi Benoît, Answers inline. Le 2 avril 2010 23:37, Benoît Thiébault thieba...@artenum.com a écrit : With Maven, I now successfully manage dependencies, generate the code and the javadoc (and even the site). It's a real improvement for me. There are still the packaging and the running aspects that I am wondering how to deal with. Well, what do you call packaging? Since mvn package is the packaging command. Maybe you the maven assembly plugin. You might be speaking of some tar/zip that contains documentation, and so on. About running, please see if the maven exec plugin could suit your needs. Should I keep an Ant script to perform these tasks ? How would my Ant script know how to set the classpath ? Including everything under taget/dependency (after the execution of the command mvn dependency:copy-dependencies) in the classpath doesn't look very clean to me... With the maven antrun plugin, it's possible to propagate the right classpath for the ant execution. So if maven-exec-plugin doesn't fit you, then you should read the maven-antrun-plugin doc part about classpath handling ( http://maven.apache.org/plugins/maven-antrun-plugin/examples/classpaths.html ). HTH Cheers. -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: Executing with Maven
Hi Baptiste, Thank you for your answer. By packaging, I indeed thought about a tar/zip file containing not only the jar produced my the mvn package command but as well a set of other files (documentations, sample data, etc. depending on the project). I will have a look at maven assembly, exec and antrun plugins. Thank you for the tip Ben Le 3 avr. 2010 à 09:45, Baptiste MATHUS a écrit : Hi Benoît, Answers inline. Le 2 avril 2010 23:37, Benoît Thiébault thieba...@artenum.com a écrit : With Maven, I now successfully manage dependencies, generate the code and the javadoc (and even the site). It's a real improvement for me. There are still the packaging and the running aspects that I am wondering how to deal with. Well, what do you call packaging? Since mvn package is the packaging command. Maybe you the maven assembly plugin. You might be speaking of some tar/zip that contains documentation, and so on. About running, please see if the maven exec plugin could suit your needs. Should I keep an Ant script to perform these tasks ? How would my Ant script know how to set the classpath ? Including everything under taget/dependency (after the execution of the command mvn dependency:copy-dependencies) in the classpath doesn't look very clean to me... With the maven antrun plugin, it's possible to propagate the right classpath for the ant execution. So if maven-exec-plugin doesn't fit you, then you should read the maven-antrun-plugin doc part about classpath handling ( http://maven.apache.org/plugins/maven-antrun-plugin/examples/classpaths.html ). HTH Cheers. -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can a site wagon deploy its own site docs?
In general, a project cannot consume any maven plugins that it produces (as the plugins which have not been built yet could have an unknown effect on the build plan) I wonder if the same applies to extensions and wagons -Stephen On 3 April 2010 04:54, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: So I've deployed this crude hack of wagon-scm to http://github.com/khuxtable/wagon-gitsite and I thought it would be cool if it deployed its own documentation there. So I added the extensions to the POM and generated the site and did a site:deploy and got: [ERROR] BUILD ERROR [INFO] [INFO] Unsupported protocol: 'gitsite' Embedded error: Cannot find wagon which supports the requested protocol: gitsite Component descriptor cannot be found in the component repository: org.apache.maven.wagon.Wagongitsite. The wagon-gitsite artifact build and installed successfully. It works in my test project. What gives? And what's the org.apache.maven.wagon.Wagongitsite reference doing there? The artifact coordinates are org.kathrynhuxtable.maven:wagon.wagon-gitsite:0.1-SNAPSHOT Any ideas? -K, who deployed the site manually.
Re: Fully automated building from Source Control
On Sat, Apr 3, 2010 at 09:30, nicolas de loof nicolas.del...@gmail.com wrote: +1 CI server is the best way to support such process with full automation +1 I could argue the using a CI server is the only reasonable solution. There are many free alternatives out there. Take a look at http://en.wikipedia.org/wiki/Continuous_integration#Software for some options. My personal favorite is Hudson. /Thomas 2010/4/3 Dan Tran dant...@gmail.com But those for for demo only to show off the holygrail maven commands :-) Use a CI server to do you checkout and cut your release. On Sat, Apr 3, 2010 at 12:10 AM, Dan Tran dant...@gmail.com wrote: mvn scm:bootstrap -DconnectionUrl=maven-scm-url-to-your-soruce -Dgoals=-B release:prepare release:perform will checkout your project, tag it, build from the tag, and finally deploy your artifact to your maven repo. (please look up for the precise syntax) mvn scm:bootstrap -DconnectionUrl=maven-scm-url-to-your-soruce -Dgoals=install will check out your project and built it On Fri, Apr 2, 2010 at 11:28 PM, Markku Saarela markku.saar...@iki.fi wrote: Hi, You could use Maven SCM plugin for bootstrapping the project with minimal pom. http://maven.apache.org/scm/maven-scm-plugin/examples/bootstrapping-with-pom.html rgds, Markku On 3.4.2010 0:09, Steve Cohen wrote: Ok, your needs are probably more extreme than mine. I HAPPEN at present to be the only developer actively engaged on this project so I can get away with non-holy-grail stuff - which explains why I stayed so long with the Eclipse setup, but I would still like to get to the single-command-line total rebuild from scratch. I have less need for CI and as the only developer I can even get away with a local repository (for now) but I would still like to move this ball down the field so it would be easier to extend should things get more complicated. Are you saying then, that managing of builds at this level must depend on something outside of Maven? I'm not likely to find funding for anything more sophisticated than that (I work for a budget-strapped small team inside a large corporation that is off to the side), so I am interested in a solution that depends on nothing beyond Maven itself. We have and use Subversion, and that's about it. David Hoffer wrote: That holy grail is the only way to use maven, imho. I don't know about a single documentation source but there is lots of info available on the web to achieve this. In short we use TeamCity for CI, Artifactory for corporate maven repo, SVN Maven. -Dave On Fri, Apr 2, 2010 at 2:48 PM, Steve Cohensco...@javactivity.org wrote: Over the past few months I have slowly and, on the whole successfully, migrated a project that was based on Eclipse to one that is based on maven (and m2eclipse), in the process, learning much about Maven and I'm generally quite happy with it. It's a nice improvement. The one step I haven't taken yet is generating a fully automated build starting with pristine sources, checking everything it needs out from Source Control and then building it. That has always seemed to me to be the holy grail of automated building, going back to the make days. You nuke all the source, get a fresh copy from the source control (tied to a given tag) and build from scratch. We don't want anything from a developer's working copy involved in any way. I haven't done this with Maven yet and to be fair, I also hadn't done it with the earlier Eclipse-based system in use here but I still want to do it. And yes, I understand that there is a bit of a chicken-egg problem here - where is this definition of everything to be version controlled and how do you avoid nuking that? So there has to be something of a two-tier setup. I know this and accept it. I hadn't spent much time looking at the Maven SCM plugin, but now that I have, I don't really see what I'm looking for there. The examples tend to be very sparse, and Maven - The Definitive Guide doesn't even touch the SCM plugin. Can someone point me at documentation directed toward achieving this holy grail with Maven? Thanks. - 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
Re: Can a site wagon deploy its own site docs?
Well, the site plugin uses the previous version of itself for its own site plugin. I've seen another site-related plugin use its own version. It noted in the comments that it needed to be installed before the site could be built. I'll investigate further. -K On Apr 3, 2010, at 3:38 AM, Stephen Connolly wrote: In general, a project cannot consume any maven plugins that it produces (as the plugins which have not been built yet could have an unknown effect on the build plan) I wonder if the same applies to extensions and wagons -Stephen On 3 April 2010 04:54, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: So I've deployed this crude hack of wagon-scm to http://github.com/khuxtable/wagon-gitsite and I thought it would be cool if it deployed its own documentation there. So I added the extensions to the POM and generated the site and did a site:deploy and got: [ERROR] BUILD ERROR [INFO] [INFO] Unsupported protocol: 'gitsite' Embedded error: Cannot find wagon which supports the requested protocol: gitsite Component descriptor cannot be found in the component repository: org.apache.maven.wagon.Wagongitsite. The wagon-gitsite artifact build and installed successfully. It works in my test project. What gives? And what's the org.apache.maven.wagon.Wagongitsite reference doing there? The artifact coordinates are org.kathrynhuxtable.maven:wagon.wagon-gitsite:0.1-SNAPSHOT Any ideas? -K, who deployed the site manually. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can a site wagon deploy its own site docs?
Also, my own htmlfilter-site-maven-plugin uses itself. It puts the plugin management in a site profile. But a wagon isn't a plugin and has no mojos. -K On Apr 3, 2010, at 6:22 AM, Kathryn Huxtable wrote: Well, the site plugin uses the previous version of itself for its own site plugin. I've seen another site-related plugin use its own version. It noted in the comments that it needed to be installed before the site could be built. I'll investigate further. -K On Apr 3, 2010, at 3:38 AM, Stephen Connolly wrote: In general, a project cannot consume any maven plugins that it produces (as the plugins which have not been built yet could have an unknown effect on the build plan) I wonder if the same applies to extensions and wagons -Stephen On 3 April 2010 04:54, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: So I've deployed this crude hack of wagon-scm to http://github.com/khuxtable/wagon-gitsite and I thought it would be cool if it deployed its own documentation there. So I added the extensions to the POM and generated the site and did a site:deploy and got: [ERROR] BUILD ERROR [INFO] [INFO] Unsupported protocol: 'gitsite' Embedded error: Cannot find wagon which supports the requested protocol: gitsite Component descriptor cannot be found in the component repository: org.apache.maven.wagon.Wagongitsite. The wagon-gitsite artifact build and installed successfully. It works in my test project. What gives? And what's the org.apache.maven.wagon.Wagongitsite reference doing there? The artifact coordinates are org.kathrynhuxtable.maven:wagon.wagon-gitsite:0.1-SNAPSHOT Any ideas? -K, who deployed the site manually. - 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: Using variables in POM's version field
Would I be right in thinking that the entire purpose of a SNAPSHOT artifact is
so that dependent modules don't have to be edited every time a new artifact is
produced. This makes the developer's job easier as long as they are willing to
accept the risk of having the dependee artifact change at any time.
If so, what would be reason for making an artifact with a build number in the
artifact version string that changes every time the artifact is deployed and
calling it a SNAPSHOT? The dependent developers would have to adjust their
dependencies each time a new dependee artifact is generated. But, that is the
way a release artifact works. Any advantage gained by deploying as a SNAPSHOT
is eliminated by having a different version string each time.
Have I made it clear why doing this is misguided? Just go ahead and deploy a
release artifact with the build number in the version. The result is the same.
One artifact per version string.
Also, the unresolved build number doesn't occur if you create the new build
number before starting Maven and pass it into the build as a property on the
command line. All build systems will support this need. I noticed everyone has
mentioned their favorite build system so I will mention mine, QuickBuild2. A
free version is available that will support a limited number of projects.
Includes a promotion model and configuration inheritance as part of its design.
No plugins needed.
!-- Frank Gorham-Engard →
It is a misnomer to label any practice 'a best practice';
a practice is only best in the specific context in which it performs well.
-Original Message-
From: Kathryn Huxtable [mailto:kath...@kathrynhuxtable.org]
Sent: Friday, April 02, 2010 7:39 PM
To: Maven Users List
Subject: Re: Using variables in POM's version field
Correct, and it's a bad idea. -K
On Apr 2, 2010, at 6:15 PM, Scott Susslin wrote:
I figured something like this was why it wasn't working. So sounds like,
given Maven 2, it can't work. True?
- Original Message
From: Justin Edelson justinedel...@gmail.com
To: Maven Users List users@maven.apache.org
Sent: Fri, April 2, 2010 4:05:10 PM
Subject: Re: Using variables in POM's version field
Amongst other reasons, allowing runtime variable interpolation in the
coordinates would prevent the reactor from properly calculating a
multi-module build plan. The coordinates at the start of the build
must remain the coordinates throughout the build.
On Apr 2, 2010, at 5:14 PM, Scott Susslin goi...@yahoo.com wrote:
Why?
Also, is it possible?
- Original Message
From: Justin Edelson justinedel...@gmail.com
To: Maven Users List users@maven.apache.org
Sent: Fri, April 2, 2010 12:05:32 PM
Subject: Re: Using variables in POM's version field
This is a bad idea. Don't do it.
On Apr 2, 2010, at 2:21 PM, Scott Susslin goi...@yahoo.com wrote:
I'm trying to use the buildnumber plugin to control the version
field of a POM.
version1.0.${buildNumber}-SNAPSHOT/version
The package phase works fine, creating a file with the parsed
value in the filename. The install and deploy don't seem to
parse the variable. When they run, I get something like the
following:
[INFO] Installing PROJECT/artifact-0.1.334-SNAPSHOT.swc to ~.m2/
repository/PROJECT/artifact/0.1.${buildNumber}-SNAPSHOT/
artifact-0.1.${buildNumber}-SNAPSHOT.swc
Anyone have any experience with this?
Thanks
- Scott
-
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
-
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: Using variables in POM's version field
We're using Hudson to do our builds and Archiva to host our Maven remote repo,
which I'm quite happy with.
The only resolution we can put on these version numbers is either once every
three weeks, or once a day. Once every 3 weeks versioning is already
happening; once a day is too much to saddle a person with (hence my attempt
to automate).
BUT, not only does it look like it's not possible to do this, I can always
incorporate this build number into a display in the software, as opposed to
changing the artifact version. That should definitely suffice, and will keep
Archiva from getting overloaded with artifacts unnecessarily.
Thanks everyone! I've been convinced to let it go. :-p
- Scott
- Original Message
From: Gorham-Engard, Frank frank_gorham-eng...@cable.comcast.com
To: Maven Users List users@maven.apache.org
Sent: Sat, April 3, 2010 7:26:39 AM
Subject: RE: Using variables in POM's version field
Would I be right in thinking that the entire purpose of a SNAPSHOT artifact is
so that dependent modules don't have to be edited every time a new artifact is
produced. This makes the developer's job easier as long as they are willing to
accept the risk of having the dependee artifact change at any time.
If so, what would be reason for making an artifact with a build number in the
artifact version string that changes every time the artifact is deployed and
calling it a SNAPSHOT? The dependent developers would have to adjust their
dependencies each time a new dependee artifact is generated. But, that is the
way a release artifact works. Any advantage gained by deploying as a SNAPSHOT
is eliminated by having a different version string each time.
Have I made it clear why doing this is misguided? Just go ahead and deploy a
release artifact with the build number in the version. The result is the same.
One artifact per version string.
Also, the unresolved build number doesn't occur if you create the new build
number before starting Maven and pass it into the build as a property on the
command line. All build systems will support this need. I noticed everyone has
mentioned their favorite build system so I will mention mine, QuickBuild2. A
free version is available that will support a limited number of projects.
Includes a promotion model and configuration inheritance as part of its design.
No plugins needed.
!-- Frank Gorham-Engard →
It is a misnomer to label any practice 'a best practice';
a practice is only best in the specific context in which it performs well.
-Original Message-
From: Kathryn Huxtable [mailto:kath...@kathrynhuxtable.org]
Sent: Friday, April 02, 2010 7:39 PM
To: Maven Users List
Subject: Re: Using variables in POM's version field
Correct, and it's a bad idea. -K
On Apr 2, 2010, at 6:15 PM, Scott Susslin wrote:
I figured something like this was why it wasn't working. So sounds like,
given Maven 2, it can't work. True?
- Original Message
From: Justin Edelson justinedel...@gmail.com
To: Maven Users List users@maven.apache.org
Sent: Fri, April 2, 2010 4:05:10 PM
Subject: Re: Using variables in POM's version field
Amongst other reasons, allowing runtime variable interpolation in the
coordinates would prevent the reactor from properly calculating a
multi-module build plan. The coordinates at the start of the build
must remain the coordinates throughout the build.
On Apr 2, 2010, at 5:14 PM, Scott Susslin goi...@yahoo.com wrote:
Why?
Also, is it possible?
- Original Message
From: Justin Edelson justinedel...@gmail.com
To: Maven Users List users@maven.apache.org
Sent: Fri, April 2, 2010 12:05:32 PM
Subject: Re: Using variables in POM's version field
This is a bad idea. Don't do it.
On Apr 2, 2010, at 2:21 PM, Scott Susslin goi...@yahoo.com wrote:
I'm trying to use the buildnumber plugin to control the version
field of a POM.
version1.0.${buildNumber}-SNAPSHOT/version
The package phase works fine, creating a file with the parsed
value in the filename. The install and deploy don't seem to
parse the variable. When they run, I get something like the
following:
[INFO] Installing PROJECT/artifact-0.1.334-SNAPSHOT.swc to ~.m2/
repository/PROJECT/artifact/0.1.${buildNumber}-SNAPSHOT/
artifact-0.1.${buildNumber}-SNAPSHOT.swc
Anyone have any experience with this?
Thanks
- Scott
-
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:
Re: Using variables in POM's version field
There is nothing stopping you from rolling a release but keeping the next
version number the same as the current
1.0-SNAPSHOT - 1.0-build-56 - 1.0-SNAPSHOT - 1.0-build-57 - 1.0-SNAPSHOT
that way developers don't have to worry, QA get their named builds and
everyone is happy
(Might take two steps, but IIRC last time I used the release plugin you
could have the old dev version = new dev version as long as the release
version was non-SNAPSHOT)
-STephen
On 3 April 2010 17:59, Scott Susslin goi...@yahoo.com wrote:
We're using Hudson to do our builds and Archiva to host our Maven remote
repo, which I'm quite happy with.
The only resolution we can put on these version numbers is either once
every three weeks, or once a day. Once every 3 weeks versioning is already
happening; once a day is too much to saddle a person with (hence my
attempt to automate).
BUT, not only does it look like it's not possible to do this, I can always
incorporate this build number into a display in the software, as opposed to
changing the artifact version. That should definitely suffice, and will keep
Archiva from getting overloaded with artifacts unnecessarily.
Thanks everyone! I've been convinced to let it go. :-p
- Scott
- Original Message
From: Gorham-Engard, Frank frank_gorham-eng...@cable.comcast.com
To: Maven Users List users@maven.apache.org
Sent: Sat, April 3, 2010 7:26:39 AM
Subject: RE: Using variables in POM's version field
Would I be right in thinking that the entire purpose of a SNAPSHOT artifact
is so that dependent modules don't have to be edited every time a new
artifact is produced. This makes the developer's job easier as long as they
are willing to accept the risk of having the dependee artifact change at any
time.
If so, what would be reason for making an artifact with a build number in
the artifact version string that changes every time the artifact is deployed
and calling it a SNAPSHOT? The dependent developers would have to adjust
their dependencies each time a new dependee artifact is generated. But, that
is the way a release artifact works. Any advantage gained by deploying as a
SNAPSHOT is eliminated by having a different version string each time.
Have I made it clear why doing this is misguided? Just go ahead and deploy
a release artifact with the build number in the version. The result is the
same. One artifact per version string.
Also, the unresolved build number doesn't occur if you create the new build
number before starting Maven and pass it into the build as a property on the
command line. All build systems will support this need. I noticed everyone
has mentioned their favorite build system so I will mention mine,
QuickBuild2. A free version is available that will support a limited number
of projects. Includes a promotion model and configuration inheritance as
part of its design. No plugins needed.
!-- Frank Gorham-Engard →
It is a misnomer to label any practice 'a best practice';
a practice is only best in the specific context in which it performs
well.
-Original Message-
From: Kathryn Huxtable [mailto:kath...@kathrynhuxtable.org]
Sent: Friday, April 02, 2010 7:39 PM
To: Maven Users List
Subject: Re: Using variables in POM's version field
Correct, and it's a bad idea. -K
On Apr 2, 2010, at 6:15 PM, Scott Susslin wrote:
I figured something like this was why it wasn't working. So sounds like,
given Maven 2, it can't work. True?
- Original Message
From: Justin Edelson justinedel...@gmail.com
To: Maven Users List users@maven.apache.org
Sent: Fri, April 2, 2010 4:05:10 PM
Subject: Re: Using variables in POM's version field
Amongst other reasons, allowing runtime variable interpolation in the
coordinates would prevent the reactor from properly calculating a
multi-module build plan. The coordinates at the start of the build
must remain the coordinates throughout the build.
On Apr 2, 2010, at 5:14 PM, Scott Susslin goi...@yahoo.com wrote:
Why?
Also, is it possible?
- Original Message
From: Justin Edelson justinedel...@gmail.com
To: Maven Users List users@maven.apache.org
Sent: Fri, April 2, 2010 12:05:32 PM
Subject: Re: Using variables in POM's version field
This is a bad idea. Don't do it.
On Apr 2, 2010, at 2:21 PM, Scott Susslin goi...@yahoo.com wrote:
I'm trying to use the buildnumber plugin to control the version
field of a POM.
version1.0.${buildNumber}-SNAPSHOT/version
The package phase works fine, creating a file with the parsed
value in the filename. The install and deploy don't seem to
parse the variable. When they run, I get something like the
following:
[INFO] Installing PROJECT/artifact-0.1.334-SNAPSHOT.swc to ~.m2/
repository/PROJECT/artifact/0.1.${buildNumber}-SNAPSHOT/
artifact-0.1.${buildNumber}-SNAPSHOT.swc
Anyone have any experience with this?
Thanks
- Scott
Re: Using variables in POM's version field
though if you are putting build numbers in a label and you plan on having
more than 10 builds between minor version increments, left pad with zero's
or else you will have to use crazy counting...
1 2 3 4 5 6 7 8 90 91 92 93 94 95 96 97 98 990 991 992 993 994 995 996 997
998 9990, etc
On 3 April 2010 18:02, Stephen Connolly stephen.alan.conno...@gmail.comwrote:
There is nothing stopping you from rolling a release but keeping the next
version number the same as the current
1.0-SNAPSHOT - 1.0-build-56 - 1.0-SNAPSHOT - 1.0-build-57 -
1.0-SNAPSHOT
that way developers don't have to worry, QA get their named builds and
everyone is happy
(Might take two steps, but IIRC last time I used the release plugin you
could have the old dev version = new dev version as long as the release
version was non-SNAPSHOT)
-STephen
On 3 April 2010 17:59, Scott Susslin goi...@yahoo.com wrote:
We're using Hudson to do our builds and Archiva to host our Maven remote
repo, which I'm quite happy with.
The only resolution we can put on these version numbers is either once
every three weeks, or once a day. Once every 3 weeks versioning is already
happening; once a day is too much to saddle a person with (hence my
attempt to automate).
BUT, not only does it look like it's not possible to do this, I can always
incorporate this build number into a display in the software, as opposed to
changing the artifact version. That should definitely suffice, and will keep
Archiva from getting overloaded with artifacts unnecessarily.
Thanks everyone! I've been convinced to let it go. :-p
- Scott
- Original Message
From: Gorham-Engard, Frank frank_gorham-eng...@cable.comcast.com
To: Maven Users List users@maven.apache.org
Sent: Sat, April 3, 2010 7:26:39 AM
Subject: RE: Using variables in POM's version field
Would I be right in thinking that the entire purpose of a SNAPSHOT
artifact is so that dependent modules don't have to be edited every time a
new artifact is produced. This makes the developer's job easier as long as
they are willing to accept the risk of having the dependee artifact change
at any time.
If so, what would be reason for making an artifact with a build number in
the artifact version string that changes every time the artifact is deployed
and calling it a SNAPSHOT? The dependent developers would have to adjust
their dependencies each time a new dependee artifact is generated. But, that
is the way a release artifact works. Any advantage gained by deploying as a
SNAPSHOT is eliminated by having a different version string each time.
Have I made it clear why doing this is misguided? Just go ahead and deploy
a release artifact with the build number in the version. The result is the
same. One artifact per version string.
Also, the unresolved build number doesn't occur if you create the new
build number before starting Maven and pass it into the build as a property
on the command line. All build systems will support this need. I noticed
everyone has mentioned their favorite build system so I will mention mine,
QuickBuild2. A free version is available that will support a limited number
of projects. Includes a promotion model and configuration inheritance as
part of its design. No plugins needed.
!-- Frank Gorham-Engard →
It is a misnomer to label any practice 'a best practice';
a practice is only best in the specific context in which it performs
well.
-Original Message-
From: Kathryn Huxtable [mailto:kath...@kathrynhuxtable.org]
Sent: Friday, April 02, 2010 7:39 PM
To: Maven Users List
Subject: Re: Using variables in POM's version field
Correct, and it's a bad idea. -K
On Apr 2, 2010, at 6:15 PM, Scott Susslin wrote:
I figured something like this was why it wasn't working. So sounds like,
given Maven 2, it can't work. True?
- Original Message
From: Justin Edelson justinedel...@gmail.com
To: Maven Users List users@maven.apache.org
Sent: Fri, April 2, 2010 4:05:10 PM
Subject: Re: Using variables in POM's version field
Amongst other reasons, allowing runtime variable interpolation in the
coordinates would prevent the reactor from properly calculating a
multi-module build plan. The coordinates at the start of the build
must remain the coordinates throughout the build.
On Apr 2, 2010, at 5:14 PM, Scott Susslin goi...@yahoo.com wrote:
Why?
Also, is it possible?
- Original Message
From: Justin Edelson justinedel...@gmail.com
To: Maven Users List users@maven.apache.org
Sent: Fri, April 2, 2010 12:05:32 PM
Subject: Re: Using variables in POM's version field
This is a bad idea. Don't do it.
On Apr 2, 2010, at 2:21 PM, Scott Susslin goi...@yahoo.com wrote:
I'm trying to use the buildnumber plugin to control the version
field of a POM.
version1.0.${buildNumber}-SNAPSHOT/version
The package phase works fine, creating a file with the parsed
value in the
does maven support multiple parents (multiple inheritance) ?
I see this doc [1] says there is support in maven internally for multiple parents, including both parents parent.../parent/parents and mixinsmixin.../mixinmixins. But the document implies that the maven model would need to be updated to support this. I tried using parents in a pom in both maven 2.2.1 and 3.0 alpha 6, and both said it wasn't recognized. I found this post [2] mentioning that Maven 3 will introduce the mixin concept, but that it's not ready as of Feb 16th... Any idea when it will be ready? -Marshall [1] http://svn.apache.org/repos/asf/maven/components/branches/maven-3.0-mercury-763966/maven-project-spec.pdf [2] http://stackoverflow.com/questions/2271082/is-it-possible-to-split-maven-pom-files/2271118#2271118 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: does maven support multiple parents (multiple inheritance) ?
I see this doc [1] says there is support in maven internally for multiple parents, including both parents Any particular reason you can't use multiple levels of parents... pom (grandparent) + pom (parent) ++ pom (child) Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: does maven support multiple parents (multiple inheritance) ?
Any idea when it will be ready? Requires a pom model change so 3.1+ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Inheritance hierachy of a Maven project ...
My search returned nothing, hence the post. Hopefully, this is a simple question. Is it reasonable to expect mvn help:effective-pom to return the hierarchy of a POM (e.g. project-a - parent-a - parent-b - super-POM)? It does not seem to be doing it as of 2.2.1. Is there another way to know the inheritance hierarchy of a project? Thanks! -- View this message in context: http://n2.nabble.com/Inheritance-hierachy-of-a-Maven-project-tp4848549p4848549.html Sent from the maven users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Inheritance hierachy of a Maven project ...
On Apr 3, 2010, at 6:25 PM, Kedar Mhaswade kedar.mhasw...@gmail.com wrote: My search returned nothing, hence the post. Hopefully, this is a simple question. Is it reasonable to expect mvn help:effective-pom to return the hierarchy of a POM (e.g. project-a - parent-a - parent-b - super-POM)? No. The parent of the effective pom is the same as the parent of the declared pom. It does not seem to be doing it as of 2.2.1. Is there another way to know the inheritance hierarchy of a project? Aside from looking at it? Not that I know of. You should have all the ancestors in your local repo. I seem to remember m2eclipse having an 'Open Parent' feature in the POM editor, but this got replaced with an effective pom viewer at some point AFAIK. Justin Thanks! -- View this message in context: http://n2.nabble.com/Inheritance-hierachy-of-a-Maven-project-tp4848549p4848549.html Sent from the maven users mailing list archive at Nabble.com. - 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
Making a gitsite wagon for GitHub pages
Justin, My initial versions were basically fixes with some minor changes to wagon-scm. Once I get some codehaus login issues worked out, I'll post Jira issues for gitexe and for wagon-scm, and send in patches for wagon-scm. At the moment I am having great success with implementing my mechanism using the scripty commands I posted. I'm not actually using scripts, I'm using gitexe. I want to tag the site release with the version number, more or less the way the release plugin does. I'd say I'm halfway done, and then I'll push my changes. Then I'll clean the code and post. -K On Apr 2, 2010, at 7:13 PM, Justin Edelson wrote: Kathryn- I'm very curious to see your code. Please do let me know when it's posted somewhere (presumably github). Justin On Apr 2, 2010, at 7:08 PM, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: On Apr 2, 2010, at 2:22 PM, Kathryn Huxtable wrote: On Apr 2, 2010, at 2:03 PM, Justin Edelson wrote: IMHO, you should be writing your own wagon implementation and avoid using wagon-scm. This use case is very specific to github. This way, you're free to define your own URL syntax. Well, that's what I was thinking about doing. It looks to me as if the wagon-scm is in pretty early stages and really only works with svn. I'm still boggled that wagons don't seem to be configurable. Okay, I see that wagons are configurable in the settings.xml file. Bleah. I've taken a chainsaw and hacked away at wagon-scm and have something that works to deploy to GitHub. I'll clean it up a bit and deploy it. Others who use GitHub may find it useful. Of course, I gather that things are changing quite a bit with Maven 3.0, but I haven't looked at it yet. -K - 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
