Re: How to script the downloading of the latest snapshot of an artifact?
To get the snapshots I'd use the maven dependecy plugin (e.g. dependency:copy), if maven is an option at all. Cheers, Roger 2013/11/20 Laird Nelson ljnel...@gmail.com Have a look at this: http://stackoverflow.com/questions/7911620/using-the-nexus-rest-api-to-get-latest-artifact-version-for-given-groupid-artfic Basically unless you want the pain of digging into yet another undocumented overly verbose alpha API to do this programmatically, use the (documented, stable, reasonably intuitive) Nexus REST API to do it for you. Best, Laird On Tue, Nov 19, 2013 at 6:09 PM, KARR, DAVID dk0...@att.com wrote: Someone I work with needs to build an automated solution to get the latest version of a snapshot jar from our nexus server. They've tried the simplistic wget/curl solution, but that requires hardcoding the verbose snapshot jar url. What are cleaner ways to do this? This could be automated either from the destination end or from the source end. We have an automated build that produces the artifact he needs, so I could script something on our build server that just scps the artifact to a remote server (this would be the source end). Alternatively, we would do something on the destination end that downloads the artifact. However it works, we need a way to just specify the artifact coordinates, not the verbose snapshot jar path. Is this something that the Wagon plugin can do? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- http://about.me/lairdnelson
[ANNOUNCE] version.override feature (lightweight maven releases)
Dear Maven users, I improved the version.override feature so that the whole maven build life cycle is now properly supported: With *mvn clean deploy -Dversion.override* a build with an unique version is created without committing anything to your version control or making your workspace dirty. For more information read here: http://diplingfh.blogspot.ch/2013/09/lightweight-release-builds-with-apache.html Best regards, Roger
Re: using a plugin twice?
And in case of the assembly-plugin you could configure multiple descriptors to generate different artifacts with one pom.xml. 2013/9/4 Richard Sand rs...@idfconnect.com Ah, too easy! I was hoping for a more difficult solution :-) -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Tuesday, September 03, 2013 6:09 PM To: Maven Users List Subject: Re: using a plugin twice? Just add the second execution with a different id On Tuesday, 3 September 2013, Richard Sand wrote: I've a feeling I know the answer at this point, but: Is it possible to use the same plugin twice in the same maven session? E.g. if I want to use maven-assembly-plugin to create two different assemblies? Or if I wanted the maven-shade-plugin to create a zip and a tarball but with slightly different contents? Or is this another case of just use two poms? Best regards, Richard - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: users-h...@maven.apache.orgjavascript:; -- Sent from my phone - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
Hi Nestor
The version.override feature is not a plugin it's an extension to the maven
base installation. So,
http://search.maven.org/#artifactdetails|ch.rotscher.maven.core|maven-core-extensions|0.2.0|jarhas
to be installed to your
*MAVEN_HOME/lib/ext*.
The extension is then activated with *-Dversion.override* on the command
line. It changes the version on the fly but only for the current build and
without changing the pom file. There are several strategies on how the
version is generated.
Beware, that the groupId of the root pom is taken into account whether the
version of a module or dependency should be changed to ${version.override}.
E.g. groupId is *com.foo.bar* then all modules/dependencies with
com.foo.bar and com.foo.bar.* are included. In other words the extension
assumes all modules/dependencies with the same base groupId to be in the
same reactor.
Cheers,
Rotsch
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
don't know exactly how your project setup is, but maybe this approach could help: https://github.com/rotscher/emerging/tree/version.override-with_maven_install-2.4 We use it for an automated continuous delivery process. Please note, that there is a release 0.2.0 available despite what the documentation says. 2013/7/31 Ron Wheeler rwhee...@artifact-software.com On 30/07/2013 4:46 PM, Nestor Urquiza wrote: Ron, Thanks for your feedback. I have been using Maven the same way like you since 2007. However things have changed in our current shop. We want continuous releasing and for that we desperately need to automate versioning. Can you explain how this affects version numbers. We do not need to maintain it manually anymore, any commit is a potential release for us. I am not sure what this means. It is true for some cases depending on what you mean by a commit. We commit a lot of projects to Subversion that are just a set of classes/packages that one programmer has finished but the project may require some more work to complete the changes that need to be done to satisfy all of thegoals of the release. Anybody else? I am trying really hard to stick to Maven as I have been doing for so many years since I departed from ant. This two plugins could resolve the continuous delivery support while still keeping maven as the tool for organizing the project. Perhaps you can add more details about what you are looking for and what alternative solutions would get you back on the road again. Perhaps you can explain how Maven could identify all the projects that need changing if the company is developing or supporting multiple applications. At any time we have 4 or 5 applications that are active in one sense or another and I am sure that big organizations might have 50+ applications under active support or development. Identifying which ones you want to have the same version will require a list somewhere. I hope that these comments help. Ron Thanks! - Nestor -- View this message in context: http://maven.40175.n5.nabble.** com/continuous-releasing-**versions-set-and-or-release-** update-version-to-release-an-**aggregator-project-** tp5766275p5766321.htmlhttp://maven.40175.n5.nabble.com/continuous-releasing-versions-set-and-or-release-update-version-to-release-an-aggregator-project-tp5766275p5766321.html Sent from the Maven - Users mailing list archive at Nabble.com. --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven assembly single goal not works.
when calling assembly:single only, the package phase and all its attached plugins are not executed. Especially, the maven-jar-plugin is not executed, so no jar file is generated and attached. Hence the error message. mvn package single:assembly (which is needless with your configuration if you don't remove the executions part) Cheers, Rotsch 2013/7/31 Tim Wu T tim.t...@ericsson.com HI there, I try to use the assembly single goal to generate a jar with dependencies, my config looks like this: plugin artifactIdmaven-assembly-plugin/artifactId version2.3/version configuration archive manifest mainClassorg.testng.TestNG/mainClass /manifest /archive descriptorRefs descriptorRefjar-with-dependencies/descriptorRef /descriptorRefs /configuration executions execution idmake-assembly/id !-- this is used for inheritance merges -- phasepackage/phase !-- bind to the packaging phase -- goals goalsingle/goal /goals /execution /executions /plugin I can use the mvn clean install to generate jar with dependnecies well, but if I want to try assembly:single, than it will show me Cannot include project artifact: xx; it doesn't have an associated file or directory. Any comments for this? Br, Tim
Re: Maven assembly single goal not works.
you configured *assembly:single* to be executed during the package phase, so calling *mvn package* also executes *assembly:single*. When you remove the *executions* part from your configuration, then you must call *mvn package single:assembly*. Cheers, Rotsch 2013/7/31 Tim Wu T tim.t...@ericsson.com Hi, Really thanks for your suggestion. More clear now :) Just one small question, not so clear about this: (which is needless with your configuration if you don't remove the executions part) Thanks in advance. Br, Tim -Original Message- From: Roger Brechbühl [mailto:rotscher...@gmail.com] Sent: Wednesday, July 31, 2013 4:52 PM To: Maven Users List Subject: Re: Maven assembly single goal not works. when calling assembly:single only, the package phase and all its attached plugins are not executed. Especially, the maven-jar-plugin is not executed, so no jar file is generated and attached. Hence the error message. mvn package single:assembly (which is needless with your configuration if you don't remove the executions part) Cheers, Rotsch 2013/7/31 Tim Wu T tim.t...@ericsson.com HI there, I try to use the assembly single goal to generate a jar with dependencies, my config looks like this: plugin artifactIdmaven-assembly-plugin/artifactId version2.3/version configuration archive manifest mainClassorg.testng.TestNG/mainClass /manifest /archive descriptorRefs descriptorRefjar-with-dependencies/descriptorRef /descriptorRefs /configuration executions execution idmake-assembly/id !-- this is used for inheritance merges -- phasepackage/phase !-- bind to the packaging phase -- goals goalsingle/goal /goals /execution /executions /plugin I can use the mvn clean install to generate jar with dependnecies well, but if I want to try assembly:single, than it will show me Cannot include project artifact: xx; it doesn't have an associated file or directory. Any comments for this? Br, Tim - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deploy using version override
Have you seen the two additional branches apart from master? There I resolved the mentioned drawback (and added another version number generation strategy) but not yet released them. I'd be interested if it works. Cheers, Roger Am 23.05.2013 17:39 schrieb Andy andy.gumbre...@orprovision.com: OK, So it's along the lines of what I'd like to do, but for the one drawback mentioned in the blog http://diplingfh.blogspot.ch/** 2013/02/how-has-our-release-**process-matured.htmlhttp://diplingfh.blogspot.ch/2013/02/how-has-our-release-process-matured.htmlthat is *the *drawback. Our project uses several of the dependent modules, and so the version override has to be consistent across all the snapshot child poms uploaded to the network repo. BTW, to answer Anders, 5.9.OV.1 is our own versioning (i.e, 5.9.OV.2 would be our next iteration), this is done on a 5.9 snapshot copy using versions-maven-plugin 1.3.1 - Which works just fine, but requires several steps that I will just have to automate in some other way. Still, many thanks Roger - I'm pretty sure you also seem to want to do what I am outlining here. On 23.05.2013 14:44, Andy wrote: Thanks Roger, I'll give it a go and let you know. Andy. On 22.05.2013 17:47, Roger Brechbühl wrote: Hi Andy Have a look here: https://github.com/rotscher/**emerginghttps://github.com/rotscher/emerging On the branches there is the latest version. Should work but is not yet released. --**--** --**-- --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deploy using version override
Have you seen the two additional branches apart from master? There I resolved the mentioned drawback (and added another version number generation strategy) but not yet released them. I'd be interested if it works. Cheers, Roger Am 23.05.2013 17:39 schrieb Andy andy.gumbre...@orprovision.com: OK, So it's along the lines of what I'd like to do, but for the one drawback mentioned in the blog http://diplingfh.blogspot.ch/** 2013/02/how-has-our-release-**process-matured.htmlhttp://diplingfh.blogspot.ch/2013/02/how-has-our-release-process-matured.htmlthat is *the *drawback. Our project uses several of the dependent modules, and so the version override has to be consistent across all the snapshot child poms uploaded to the network repo. BTW, to answer Anders, 5.9.OV.1 is our own versioning (i.e, 5.9.OV.2 would be our next iteration), this is done on a 5.9 snapshot copy using versions-maven-plugin 1.3.1 - Which works just fine, but requires several steps that I will just have to automate in some other way. Still, many thanks Roger - I'm pretty sure you also seem to want to do what I am outlining here. On 23.05.2013 14:44, Andy wrote: Thanks Roger, I'll give it a go and let you know. Andy. On 22.05.2013 17:47, Roger Brechbühl wrote: Hi Andy Have a look here: https://github.com/rotscher/**emerginghttps://github.com/rotscher/emerging On the branches there is the latest version. Should work but is not yet released. --**--** --**-- --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deploy using version override
Was on my mobile phone before, so here some more information and links: Check https://github.com/rotscher/emerging/tree/version.override-with_maven_install-2.4where the overridden version is replaced in a copy of the pom.xml which then gets installed to the local maven repo. I never checked how the deploy to the remote repo works, I mean which file is deployed. I expect the one going to the local repo should be deployed to the remote... Actually, I'd like to wait until maven-install-plugin is released in version 2.5 (current is 2.4) as the 2.5 implementation is much easier to extend. Cheers, Roger 2013/5/23 Roger Brechbühl rotscher...@gmail.com Have you seen the two additional branches apart from master? There I resolved the mentioned drawback (and added another version number generation strategy) but not yet released them. I'd be interested if it works. Cheers, Roger Am 23.05.2013 17:39 schrieb Andy andy.gumbre...@orprovision.com: OK, So it's along the lines of what I'd like to do, but for the one drawback mentioned in the blog http://diplingfh.blogspot.ch/** 2013/02/how-has-our-release-**process-matured.htmlhttp://diplingfh.blogspot.ch/2013/02/how-has-our-release-process-matured.htmlthat is *the *drawback. Our project uses several of the dependent modules, and so the version override has to be consistent across all the snapshot child poms uploaded to the network repo. BTW, to answer Anders, 5.9.OV.1 is our own versioning (i.e, 5.9.OV.2 would be our next iteration), this is done on a 5.9 snapshot copy using versions-maven-plugin 1.3.1 - Which works just fine, but requires several steps that I will just have to automate in some other way. Still, many thanks Roger - I'm pretty sure you also seem to want to do what I am outlining here. On 23.05.2013 14:44, Andy wrote: Thanks Roger, I'll give it a go and let you know. Andy. On 22.05.2013 17:47, Roger Brechbühl wrote: Hi Andy Have a look here: https://github.com/rotscher/**emerginghttps://github.com/rotscher/emerging On the branches there is the latest version. Should work but is not yet released. --**--** --**-- --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deploy using version override
Hi Andy Have a look here: https://github.com/rotscher/emerging On the branches there is the latest version. Should work but is not yet released. Let me know when you need support. Cheers, Roger Am 21.05.2013 15:32 schrieb Andy andy.gumbre...@orprovision.com: Hi List, I'll try and keep this short: I regularly build a known stable (thoroughly tested) ActiveMQ snapshot off the trunk for use in a local project - 5.9-SNAPSHOT at the time of writing. I am trying to find an efficient way of deploying this multi-module snapshot to our network repository using an internal version, e.g. 5.9.OV.1 Is there a way to do this without changing any poms, i.e. from the the command line using an override property. Currently I copy the snapshot, reversion it and then deploy. This just feels like it is too much work. Any advice? Andy. --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Lightweight maven-releases, or an alternative to the maven-release-plugin
- when speaking about SNAPSHOTs we should distinguish between
dependencies and what we produce. With a build we produce an artifact which
is either a SNAPSHOT or release according to the version in the pom.xml. A
dependency resolves either to a SNAPSHOT or a released version of another
library. The dependency might be internal (modules built within the same
reactor) or external.
- an external dependency should never be a SNAPSHOT (it makes life easier
anyway ;-), should only be allowed temporarily.
- all modules in our multi module project always have the same version
(e.g. 0.1.0-SNAPSHOT) and dependencies are defined with ${project.version}
When produce artifacts we deploy them to our target environment (e.g.
war-file to app-server, db scripts to database...) and make some tests. All
this stuff is done during the night in an automated way. We have other
stages where we have to deploy a build which has passed this first tests
but normally, this happens some days later. That's why a SNAPSHOT is not
enough as it's hard to track down which SNAPSHOT we can deliver.
In other words: It's important what we produce and less important what's in
it (e.g. SNAPSHOT or not) as we test if it works or not. Don't get me
wrong: we avoid having SNAPSHOT deps and when it goes to production we
don't have SNAPSHOT libs anymore! But during development this is ok.
And that's what we do all the time: during the day we do continuous builds
(mvn clean install) in the night we create an ad-hoc release with mvn
clean install -Dversion.override=x.y-n which is virtually changing the
${project.version} in all our pom.xml but not changing anything in our
version control. And if something fails we don't repeat we start a new one.
By the way: The version.override feature has options to let a build fail or
issue a warning when it detects SNAPSHOT deps. This is not documented but
it's there.
Cheers,
Rotsch
2013/5/2 Mirko Friedenhagen mfriedenha...@gmail.com
Hello there,
I. find prepare and perform quite heavyweight my self. After prepare did
build everything successfully, it throws away everything, just tags the
source and starts over again during perform.
prepare already checks with scm means, that there are no modifications and
in my experience tagging is the most harmless operation in the whole
process (well, would I still use CVS that could be different).
So running prepare with prepareGoals set to -DperformRelease=true clean
deploy does what *I* want.
- checks I have everything in SCM
- does modify POMs for release.
- deploys to staging
- only on success of this tags the sources
- go back to SNAPSHOT.
git and svn (when not doing the strange remoteTagging) are capable of
tagging always.
Worst thing that might happen: bad stuff in staging for a short time.
Regards Mirko
--
Sent from my mobile
On May 1, 2013 9:15 PM, Robert Scholte rfscho...@apache.org wrote:
Graham, well said.
Although the pom.xml is the easiest way to discover the version, it is
not
the best location, since it would require a commit.
The solution must be found in a generated file which will be added to the
artifact during packaging. Here you could add a timestamp or revision.
Robert
Op Wed, 01 May 2013 12:44:19 +0200 schreef Graham Leggett
minf...@sharp.fm:
On 30 Apr 2013, at 11:21 PM, Roger Brechbühl rotscher...@gmail.com
wrote:
Maybe somebody is interested in how a release could be built in a more
lightweight and safe way than with the maven-release-plugin. Especially
recommended for nightly releases.
It's not yet released, but basically fully working:
*mvn clean install -Dversion.override=1.2.3-S-5*
https://github.com/rotscher/**emerging/tree/version.**
override-with_maven_install-2.**4
https://github.com/rotscher/emerging/tree/version.override-with_maven_install-2.4
Maven has a very clear definition of a release, being an artefact that
can traced back to the precise code via a tag, and a build that can be
repeated. This is as opposed to a snapshot, which has no well defined
origin.
You might approach this two ways, you might create nightly snapshots
and have them deployed somewhere suitable, using mvn deploy.
Alternatively if you want to create proper nightly releases (in the
maven sense), you could feed a custom version number into the release
plugin to represent your release, but this starts to smell like that's
what a snapshot is for.
Regards,
Graham
--
--**--**-
To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org
users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Lightweight maven-releases, or an alternative to the maven-release-plugin
Hi Nambi 1. Why does the jar need to be part of maven installation? Why not a plugin? The version given on the command line is passed into the model when it's loaded (model.setVersion(version)). And this is done for all modules when the model is read. When having a plugin I would change the version when the module is built. And I guess, it's not possible at that time. And as there is a different install-plugin for the install phase, I'll change that in the lifecycle mapper (which is also part of the maven installation). 2. Can it generate a version based on some strategy? Looks like the version needs to be supplied through CLI parameter. With Release 0.2.0 there are more possibilites to generate a unique version number: when the feature is active but no version is provided then the pom version is taken and a buildnumber is appended. The buildnumber is either taken from jenkins/hudson (env.BUILD_NUMBER) or its an incremented integer stored in a file named .buildnumber Of course, it would be possible to think about different version generation strategies. 3. Some releases need a TAG in SCM while some releases don't require a TAG. Is there a possibility of having this functionality? I guess this would be possible. To me storing the revision number into the manifest files is more important. With this information you can always tag and/or branch from a specific revision. 4. What happens if the release is trying to overwrite an already existing version on the repository? This should be configured in your central maven repo (e.g. Nexus/Archiva) where you configure a repository to not allow releases to be overwritten. 5. What kind of formats are supported? jar, war etc. I don't get this question... Actually all generated artifacts are handled the same way. Cheers, Rotsch 2013/5/1 Sankaran, Nambi nsanka...@ebay.com Hi Rotch This sounds quite interesting and I feel it would be useful to a lot of projects. The release-plugin as it is, is not very flexible. Questions 1. Why does the jar need to be part of maven installation? Why not a plugin? 2. Can it generate a version based on some strategy? Looks like the version needs to be supplied through CLI parameter. 3. Some releases need a TAG in SCM while some releases don't require a TAG. Is there a possibility of having this functionality? 4. What happens if the release is trying to overwrite an already existing version on the repository? 5. What kind of formats are supported? jar, war etc. Thanks nambi -Original Message- From: Roger Brechbühl [mailto:rotscher...@gmail.com] Sent: Tuesday, April 30, 2013 2:22 PM To: users@maven.apache.org Subject: Lightweight maven-releases, or an alternative to the maven-release-plugin Hi all Maybe somebody is interested in how a release could be built in a more lightweight and safe way than with the maven-release-plugin. Especially recommended for nightly releases. It's not yet released, but basically fully working: *mvn clean install -Dversion.override=1.2.3-S-5* https://github.com/rotscher/emerging/tree/version.override-with_maven_install-2.4 . Have fun. Rotsch - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Lightweight maven-releases, or an alternative to the maven-release-plugin
Hi all Maybe somebody is interested in how a release could be built in a more lightweight and safe way than with the maven-release-plugin. Especially recommended for nightly releases. It's not yet released, but basically fully working: *mvn clean install -Dversion.override=1.2.3-S-5* https://github.com/rotscher/emerging/tree/version.override-with_maven_install-2.4 . Have fun. Rotsch
