Noob question. I'm considering to learn Maven. I understand what it does in general. Let's say I have a Maven Eclipse project. Then I create an executable JAR, and wrap it with launch4j.
Now I have TestProgram.exe file. Will Maven reload the dependencies, whenever there is a there is a new version available? Will the inner structure of the TestProgram.exe change over time as new versions of dependencies are loaded? Or does Maven update dependencies only during the development stage?
Maven is a build tool. One of it's key benefits is that it yields a repeatable build process. It does not become part of your application.
The artefacts that are included in your build are fixed by the dependency versions that you specify in your project object model (aka pom.xml file).
If you need a newer version of one of these dependencies then you must update your pom.xml file and release a new version of your product.
I've written a Maven plugin which we're using as part of our release process - as well as the usual release basically does some extra admin. I'd like to use this plugin for releasing the plugin itself but I'm not sure this is possible.
If I include the plugin in its own POM, using ${version} as the version number then I can't release because before deploying the release build it can't find the release build in the Nexus repo. If I use an earlier version, I get a clash (I don't think Maven likes two versions of the same project at once) and I'm not having any luck using a 'provided' scope as the plugin tag doesn't support this.
Is what I'm trying to do possible or should I resign myself to having a different release procedure for the plugin itself?
Thanks,
-Dave
In my current maven project I have a lot of submodules. I need to build a release and deploy it to my nexus...
Now I am facing the challange that I need for some of the modules differing version numbers. How can I handle this by usage of the release & deploy plugin? Or do I need some other maven plugins??? I configured the release plugin inside the parant pom. Is there a possibility to disable for example the "autoVersionSubmodules" for some of the submodules? Any ideas???
If you have a multi-module build than all modules should have the same version number otherwise it's an indicator that the multi-module build is not the right choice.
I am trying to define a release process for our project.
I was able to use the maven release plugin to accomplish the release but I had to manually update all of our internal SNAPSHOT dependencies to release versions prior to the prepare and then again back to SNAPSHOT versions after the release.
I have used the maven versions plugin and it detects my corporate dependencies that are SNAPSHOT builds and lists the correct release build to use.
I tried the maven release plugin, prepare goal, and complains about the SNAPSHOT versions in my dependencies.
Is there a way to do a release that updates the SNAPSHOT depenedencies to latest released versions and then back to SNAPSHOT versions after the release? Or maybe this is just not the way you are supposed to be using maven with releases and SNAPSHOTS.
When you create a realease with maven: it must be definitive. i.e. once it is created it cannot change anymore (i.e. the sources cannot change and the dependencies cannot change).
So when you create a release of moduleA and moduleA having a dependency on moduleB. moduleB must be released before moduleA is released, and moduleA MUST depends on a released version of moduleB.
One important thing is that you shouldn't go back to SNAPSHOT version. At least as I understand it means :
create moduleB-1.0.0 release
changing dependency to moduleB-1.0.0
create moduleA-1.0.0 release
then change the dependency back to moduleB-1.0.0-SNAPSHOT
It must be clear that once moduleB-1.0.0 exists (i.e. is released): the artifact moduleB-1.0.0-SNAPSHOT shouldn't be used anymore.
Instead of go back to SNAPSHOT should update dependency to next SNAPSHOT version (for instance moduleB-SNAPSHOT-1.0.1)
That being said, releasing a module depending on many SNAPSHOT artifacts is not an easy process, since every dependency must be released prior to releasing your main artifact.
What we have, most of the time, is a main artifact depending on many other artifacts (let's call them the corporate-modules) having the same versionning strategy. And so you can define a property corporate-module-version holding the version used by many dependencies in one place.
The release process is the following:
release every snapshot dependency with version number 1.0.0 (using the maven-release-plugin: after this step all pom.xml of your corporate-module in SCM are 1.0.1-SNAPSHOT) (see important remark at the end of this post to facilitate this step)
manually changing the corporate-module-version property to "1.0.0" in the main artifact (so that all SNAPSHOT dependencies are replaced by just released versions)
commit the modified pom.xml holding the corporate-module-version
with maven-release-plugin: releasing the main artifact (and after that, the new version in the SCM will be something like 1.0.1-SNAPSHOT)
manually changing the corporate-module-version property to "1.0.1-SNAPSHOT" in the main artifact (so that all dependencies are replaced by latest snapshot versions)
Important remark: having a multi-module parent project holding all your corporate modules is a must to perform at once the release of of all corporate modules. To not having too much trouble with the maven-release-plugin and the multi-module parent project be sure to put your parent pom.xml one directory upper all your child pom.xml (it's the designed recommend by maven, but unfortunately, sometimes, eclipse users don't follow it because eclipse don't like hierarchical projects)
I'm working on a rapid project, of which, I'm directly working on a module that is continuously changing. Others have a direct dependency on the module, and as such, I stubbed out the public interface and deployed it to our local Nexus repository as 0.0-SNAPSHOT for use.
Now that I've almost completed my first iteration of the module, I've attempted to redeploy the updated artifact. Reading about snapshots, others claim that a snapshot should represent the current head trunk. Is this true?
Maven automatically increments my snapshot version upon redeploy - so, going from 0.0-SNAPSHOT, I'm still at 0.0-SNAPSHOT, only, it's iteration 3 or 4 of the same snapshot. When should I roll over to 0.1-SNAPSHOT? Is there a plugin I can use to automate the version change, instead of manually editing my pom?
After integration testing and the deployment of our first system release, 1.0-RELEASE, how should my module progress? Should I move my module to 1.0-SNAPSHOT and continue thereon? Is there a methodology one should follow, or is it left to the discretion of the developer?
The X.Y.Z-SNAPSHOT notation identifies temporary versions leading up to release X.Y.Z, so you usually do not move from X.Y.Z-SNAPSHOT to X.Y.Z+1-SNAPSHOT unless you release X.Y.Z. If you adhere to this convention the maven-release-plugin may help you with the full release process.
Note that the most common Maven convention uses 3-number release identifiers without any suffix (i.e. no -RELEASE). Suffixes are usually used to distinguish variants of the same release.
Maven is all about conventions, so there's little chance you'll go very far without reading about it: This book is a good starting point.
For updating your POM version without manually updating, you may take a look at Maven Release plugin (Although I wrote myself a little script to do the POM update as I find Release plugin don't fit that good in my work flow)
It then come to your version number issue. It is more a release procedure issue. Normally a planned release is denoted by increment of Major or Minor version in the version number. SNAPSHOT version denote that certain release is in progress. For example, I will prefer doing something like this for your case:
Assume I am planning to release first iteration as 0.1, then I will make my head trunk in SCM (e.g. trunk in SVN) with 0.1-SNAPSHOT as version. Which denotes that all development is in fact contributing to release of version 0.1. Upon finish, I'll update the POM version from 0.1-SNAPSHOT to 0.1, perform an actual release of version 0.1 (including release branching, tagging, deploying the artifact), and then change the POM version to SNAPSHOT of next planned release (for example, 0.2-SNAPSHOT).
Similarly, after releasing 1.0 (or 1.0-RELEASE in your example), POM version in head trunk should then be updated to snapshot of your next release version, for example, 1.1-SNAPSHOT.
Just bear in mind that there should no longer be SNAPSHOTs of certain version, if that version is actually released.
Understand the way maven interprets SNAPSHOTS is to clear any doubt you can have.
Extract from http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-syntax.html
For example, if your project has a version of “1.0-SNAPSHOT” and you deploy this project’s artifacts to a Maven repository, Maven would expand this version to “1.0-20080207-230803-1” if you were to deploy a release at 11:08 PM on February 7th, 2008 UTC
First, Let me suggest to stick on maven conventions and change your version to 0.1 as maven archetype:generate propose.
So SNAPSHOT helps others to stay up-to-date easily with your active project. On every compilation, their projects will check new releases of SNAPSHOTS dependencies (based on that pseudo-datetime-version they have on its .m2 directory).
When you finish work on 0.1-SNAPSHOT you deploy an 0.1 and start a 0.2-SNAPSHOT or 1.0-SNAPSHOT