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
Re: Lightweight maven-releases, or an alternative to the maven-release-plugin
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 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 -- smime.p7s Description: S/MIME cryptographic signature
allowMajorUpdates for mvn versions:update-properties
Hi, I have a number of dependency versions defined as properties. For good reason. The version properties are used in both the dependencies and rpm build section of the pom.xml So, as part of a release I only want to update to the next minor version for this property. For example, use-latest-versions allows this with: mvn versions:use-latest-versions -DallowSnapshots -DallowMajorUpdates=false update-properties doesn'tt seem to support this: http://mojo.codehaus.org/versions-maven-plugin/update-properties-mojo.html Any other option? -- View this message in context: http://maven.40175.n5.nabble.com/allowMajorUpdates-for-mvn-versions-update-properties-tp5754676.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
Another Maven 1 to 2 upgrade issue.
I 'inherited' responsibility for an application that has several jars compiled in Maven 1. The main application itself is using Maven 2. While I want to upgrade everything, my client hasn't yet given me time to do that sort of work between minor fixes and adding capability - I know, a common complaint. So I upgraded one of the supporting jars to Maven 2 and it seemed to work OK, until I integrated it into the main app. Suddenly the main app is using dependencies from the supporting jar and several of its dependencies are using older jars (ehcache .07 vs 1.2 and so on). While upgrading the supporting jar to the newer dependencies seems to fix the problem, I have a long road of testing to make sure the upgrade doesn't break anything in the functionality. Time is, of course, the immediate issue. My question is there a way of compiling the supporting jar or the main app dependency so the main app won't use an older dependency. For example the maven 1 compiled jar shows no dependencies when looking at the dependency hierarchy in the main app. Yet once I point the main app POM to the newly compiled supporting jar, it's dependency hierarchy is loaded with the older jars and I have a long list of errors. Any ideas? Hope it's making sense, Ted -- View this message in context: http://maven.40175.n5.nabble.com/Another-Maven-1-to-2-upgrade-issue-tp5754681.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: Another Maven 1 to 2 upgrade issue.
So I upgraded one of the supporting jars to Maven 2 and it seemed to work What does this mean? How did you upgrade the jar to Maven 2? Hope it's making sense, We need more concrete details to be helpful. You should be able to manage your dependencies via the various pom files. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Another Maven 1 to 2 upgrade issue.
Make all the dependencies of the supporting jar scopeprovided/scope Ensure your app brings these dependencies and all *theirj transitive ones in the correct version. provided basically cuts off transitive dependencies. Am 01.05.2013 17:15 schrieb tedhohio tedho...@gmail.com: I 'inherited' responsibility for an application that has several jars compiled in Maven 1. The main application itself is using Maven 2. While I want to upgrade everything, my client hasn't yet given me time to do that sort of work between minor fixes and adding capability - I know, a common complaint. So I upgraded one of the supporting jars to Maven 2 and it seemed to work OK, until I integrated it into the main app. Suddenly the main app is using dependencies from the supporting jar and several of its dependencies are using older jars (ehcache .07 vs 1.2 and so on). While upgrading the supporting jar to the newer dependencies seems to fix the problem, I have a long road of testing to make sure the upgrade doesn't break anything in the functionality. Time is, of course, the immediate issue. My question is there a way of compiling the supporting jar or the main app dependency so the main app won't use an older dependency. For example the maven 1 compiled jar shows no dependencies when looking at the dependency hierarchy in the main app. Yet once I point the main app POM to the newly compiled supporting jar, it's dependency hierarchy is loaded with the older jars and I have a long list of errors. Any ideas? Hope it's making sense, Ted -- View this message in context: http://maven.40175.n5.nabble.com/Another-Maven-1-to-2-upgrade-issue-tp5754681.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: Another Maven 1 to 2 upgrade issue.
Wayne Fay wrote So I upgraded one of the supporting jars to Maven 2 and it seemed to work What does this mean? How did you upgrade the jar to Maven 2? Hope it's making sense, We need more concrete details to be helpful. You should be able to manage your dependencies via the various pom files. Wayne - To unsubscribe, e-mail: users-unsubscribe@.apache For additional commands, e-mail: users-help@.apache I converted using the convert plug-in, it produced the POM and compiling using Maven 2 worked fine. No errors -- at least not until I hit the transitive dependencies when I updated the main app POM. I 'assumed' that having the newer dependency in the main app jar would override any dependency from the supporting jar, but it's not. Better example Spring. The SpringFramework jar (1.2.8) contains a org.springframework.util package with a class StringUtils. I import that into several class files and use several of the trim functions, part of cleaning up user input. With the maven2 compiled jar, the import is using the SpringFramework from a different dependency which also have a org.springframework.util and a StringUtils class, but the trim method I want to use isn't in that one -- even though my main app has the dependency in the POM. It took me a while to realize that the dependency hierarchy was pulling from other jars. Frustrating! -- View this message in context: http://maven.40175.n5.nabble.com/Another-Maven-1-to-2-upgrade-issue-tp5754681p5754686.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: Another Maven 1 to 2 upgrade issue.
Thanks! That appears to have solved my immediate problem. Once the latest round of new functionality is over, I will be walking through more carefully and looking to shift everything over to Maven 3 and hopefully end my time-driven issues . . . well at least this one. Wasn't it Napolean who said something like Ask me for anything but time! Thanks again, Ted -- View this message in context: http://maven.40175.n5.nabble.com/Another-Maven-1-to-2-upgrade-issue-tp5754681p5754687.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
Maven deploy plugin
Hi, when using the maven deploy plugin, can I change the name of the file being uploaded to Nexus. ?? Like the maven-ear-plugin has the finalName. Now the file just gets the name artifactId
Re: Another Maven 1 to 2 upgrade issue.
On 01/05/2013 12:03 PM, tedhohio wrote: Wayne Fay wrote So I upgraded one of the supporting jars to Maven 2 and it seemed to work What does this mean? How did you upgrade the jar to Maven 2? Hope it's making sense, We need more concrete details to be helpful. You should be able to manage your dependencies via the various pom files. Wayne - To unsubscribe, e-mail: users-unsubscribe@.apache For additional commands, e-mail: users-help@.apache I converted using the convert plug-in, it produced the POM and compiling using Maven 2 worked fine. No errors -- at least not until I hit the transitive dependencies when I updated the main app POM. I 'assumed' that having the newer dependency in the main app jar would override any dependency from the supporting jar, but it's not. Better example Spring. The SpringFramework jar (1.2.8) contains a org.springframework.util package with a class StringUtils. I import that into several class files and use several of the trim functions, part of cleaning up user input. With the maven2 compiled jar, the import is using the SpringFramework from a different dependency which also have a org.springframework.util and a StringUtils class, but the trim method I want to use isn't in that one -- even though my main app has the dependency in the POM. It took me a while to realize that the dependency hierarchy was pulling from other jars. Frustrating! Not really a Maven problem. Maven can not select dependencies for you. You need to fix up your dependencies and then test to make sure that the latest version of spring does the same thing as 1.2.8 which is pretty old. When the application is running, you will get only one version of each library and it is best to specify the one you want. The nicest way is to remove all version numbers and have a parent pom that includes a dependency management section whose only job is to specify versions. Then you are sure that all your code is compiled with the same version of Spring or whatever. When you are ready to move to a new version, just change it in the parent and when you recompile your child modules, they will all be compiled with the right version. -- View this message in context: http://maven.40175.n5.nabble.com/Another-Maven-1-to-2-upgrade-issue-tp5754681p5754686.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 -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven deploy plugin
The Maven Deploy Plugin has one function: deploying artifacts to a Maven
repository.
A Maven repository has a strict layout:
URL +
groupId.replaceAll('.','/')+/+artifactId+/+version.replace(-\d{8}\.\d{6}-\d+$,-SNAPSHOT)+/+artifactId+-+version+(classifier
== null ? : -+classifier) + . + type
If you want to deploy with a different pattern, you need to use a different
plugin
On 1 May 2013 17:06, Kristian Lind klpc...@gmail.com wrote:
Hi, when using the maven deploy plugin, can I change the name of the file
being uploaded to Nexus. ??
Like the maven-ear-plugin has the finalName.
Now the file just gets the name artifactId
Re: Maven deploy plugin
Hi, when using the maven deploy plugin, can I change the name of the file being uploaded to Nexus. ?? No. Wayne - To unsubscribe, e-mail: 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
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 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-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
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.**4https://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.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
