HI,
I was wondering how the general best-practice method for the following scenario is:
We have codefreeze in our company. So for that we like to release a release candidate for our maven projects. After testing this candidate shall be released.
So how can I create a "release" in maven so that it is handeled like a snapshot ? Maven should download always a newer/patched version of the RC version.
Only after the testing and final release to a full version it should not...
So how can I make a release of a RC ?
Thanks
It's not possible to make a release which is handled as a snapshot, because it's released. The best practice is to give the artifact an appropriate version. For example 1.0.0-RC1 and after fixing some problems 1.0.0-RC2 and finally 1.0.0...
Related
Here is my current understand of how Maven handles dependencies.
When a dependency is being actively worked on Maven attaches the "-SNAPSHOT" to the end of the version. ex) 1.1.1-SNAPSHOT. These snapshots are uploaded to a remote repository that is specifically responsible for snapshots. The same remote repository has a section for released versions of the packages. Now when a project has the dependencies updated, Maven pulls the most recent version of a package into the local repository. ONLY SNAPSHOTS are updated depending on the time stamp on the the snapshot. If Maven pulls down a release version (ex: 1.1.0) it will never look for another package with the current version.
Now my questions are:
What are the flaws in my understanding? Am I missing a conceptual piece?
When a package moves from a SNAPSHOT to a release version, how do the pom.xml get updated to reflect the released version of the package? Is this a manual process?
Lastly, if a package is released, we'll use the example from above, 1.1.1 is released. Is 1.1.2-SNAPSHOT created or 1.2.0-SNAPSHOT created, and is this the version that will be updated in the poms?
Snapshots are currently in development versions and could be not stable.
We are old fashioned company which still use svn:
The development is going in the trunk and version in pom files are snapshots (we have dependencies to some opensource libraries that have fixed version, and we update them as soon as new release happens and we are confident about switching)
As soon as we are going to release we are branching trunk and changing versions in pom to corresponded fixed one (some companies could mark them with suffix -rc)
Release (Companies that use -rc will change version in pom to fixed one)
Please take a look to release maven plugin to skip manual version changes.
I hope this answers some of your questions.
About the versioning answer - it depends. Please read about it more here:
http://en.wikipedia.org/wiki/Software_versioning
Best Practice: Software Versioning
I am using maven and Jenkins, for some reason my Snapshot version is different than my Release versions in nexus. I expect them both to be same.
Any ideas
How are the versions different?
A release version will be typically formatted ".." for instance; 1.0.4, whereas SNAPSHOT artifacts will be versioned as 1.0.4-SNAPSHOT.
If the x.y.z values are significantly different, check the local poms for the projects and make sure the versions are correct.
Try clearing out the workspace for the Jenkins job as there may be an incorrect POM left around from another build, are you using the maven release plugin? That may leave "relics" of changes after a build failure which could throw things out.
Our project has a dependency like
<dependency>
<groupId>apollo.components.cots</groupId>
<artifactId>cots-wfs</artifactId>
</dependency>
And as far as I understand, maven2 will get the latest artifact for cots-wfs, say <version>2.3-20101111.000000-13</version>
The problem is, when we branch the project, the dependency stays the same, and when other developers release a new cots-wfs say <version>2.3-20101222.000000-13</version> which is not backward compatible, the build is broken.
I am trying to avoid merging the code into the branch, which is painful.
So what do I need to do to "freeze" all the dependencies when I branch the project ?
Is there any easy way to do this?
And as far as I understand, maven2 will get the latest artifact for cots-wfs, say <version>2.3-20101111.000000-13</version>
It looks like you are using a SNAPSHOT dependency for cots-wfs (2.3-SNAPSHOT), probably declared in the dependencyManagement section.
The problem is, when we branch the project, the dependency stays the same, and when other developers release a new cots-wfs (...) which is not backward compatible, the build is broken.
Indeed, which is why you should simply not branch an artifact with SNAPSHOT dependencies, the build of released artifacts should be reproducible, for ever, and using SNAPSHOT dependencies defeats this. The maven release plugin actually forbids releasing a POM having SNAPSHOT dependencies.
It is however possible to "lock" SNAPSHOT dependencies using versions:lock-snapshots or, even better, to use the corresponding released version using versions:use-releases. This is actually the way to go.
By the way, the Maven Release Plugin might help to automate the whole process.
When you branch means in a sense you are creating a new version of it. Promoting the version number should solve it.
Yeah just add the version tag to the dependency. If your unsure what the current version number is than run "mvn help:effective-pom" to see the pom with all current version numbers.
New to Maven.
Ok so I used Maven to package up my project, but one of the files had some test information in it. I would like to change that file but I'm at a standstill as keeping the same version number of the project.
I don't know what to do! Are these my options and what's the best way to do this?
Change the file and do a new build of the project which would increment the build by one.
Example: Build is at 2.0, it would move to 2.0.1 or 2.1
Remove the project from Maven and do a rebuild of the last project but with the new changes.
This is what I want to do but don't know how to remove the project from Maven and reset everything to do a rebuild
Open to suggestions???
Thanks
What exactly do you mean by "remove a project from Maven"? You mean from a public Maven repository?
You should probably bump up the version, as most projects do, when there's an "oops" moment like that. The release notes would ideally state why there's been a new version. Ideally a public notice as well.
Otherwise, you risk people getting the wrong version, or something that they have the fixed version, or whatever. For example, I use the Maven offline option (i.e., -o) pretty regularly so I don't grab the latest snapshots.
I used Maven to package up my project, but one of the files had some test information in it. I would like to change that file but I'm at a standstill as keeping the same version number of the project.
Maven never re-downloads released artifacts with a fixed version (as opposed to a SNAPSHOT version) once they have been downloaded (unless you delete an artifact from your local repository of course but you obviously can't rely on that). This is the only way to guarantee reproducibility (if I rebuild later, I get the same behavior). And in the same spirit, you actually can't re-release an artifact with a fixed version. This is the only way to guarantee consistency (everybody gets the same stuff).
So you'll have to change the version if you want to re-release your project.
Note that if your project is under active development, you should use a SNAPSHOT version. Here is what the Maven: Definitive guide writes about them:
3.3.1.2. SNAPSHOT Versions
Maven versions can contain a string
literal to signify that a project is
currently under active development. If
a version contains the string
“SNAPSHOT,” then Maven will expand
this token to a date and time value
converted to UTC (Coordinated
Universal Time) when you install or
release this component. 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. In other
words, when you deploy a snapshot, you
are not making a release of a software
component; you are releasing a
snapshot of a component at a specific
time.
Why would you use this? SNAPSHOT
versions are used for projects under
active development. If your project
depends on a software component that
is under active development, you can
depend on a SNAPSHOT release, and
Maven will periodically attempt to
download the latest snapshot from a
repository when you run a build.
Similarly, if the next release of your
system is going to have a version
"1.4", your project would have a
version "1.4-SNAPSHOT" until it was
formally released.
As a default setting, Maven will not
check for SNAPSHOT releases on remote
repositories. To depend on SNAPSHOT
releases, users must explicitly enable
the ability to download snapshots
using a repository or pluginRepository
element in the POM.
When releasing a project, you should
resolve all dependencies on SNAPSHOT
versions to dependencies on released
versions. If a project depends on a
SNAPSHOT, it is not stable as the
dependencies may change over time.
Artifacts published to non-snapshot
Maven repositories such as
http://repo1.maven.org/maven2 cannot
depend on SNAPSHOT versions, as
Maven's Super POM has snapshot's
disabled from the Central repository.
SNAPSHOT versions are for development
only.
I am developing code actively, with my developing team. When we release to our customers, I would like to provide jars without the -SNAPSHOT so they only need to update when a new dot version is created.
This there a maven plugin that provides this functionality. I know there is because everyone else must do it some how. I doubt it is manually.
I would appreciate answers to be explicit as possible.
Please and thank you.
Some plugins can help here, as already mentioned in this answer and in the comments of this one: the Maven Release Plugin if you want to fully automate the release and/or the Maven Versions Plugin.
With the Maven Release Plugin
Releasing a project with the Maven Release Plugin is done in two steps: prepare and perform and here is what the documentation writes about the release:prepare goal:
Preparing a release goes through the
following release phases:
Check that there are no uncommitted changes in the sources
Check that there are no SNAPSHOT dependencies
Change the version in the POMs from x-SNAPSHOT to a new version (you
will be prompted for the versions to
use)
Transform the SCM information in the POM to include the final
destination of the tag
Run the project tests against the modified POMs to confirm everything is
in working order
Commit the modified POMs
Tag the code in the SCM with a version name (this will be prompted
for)
Bump the version in the POMs to a new value y-SNAPSHOT (these values
will also be prompted for)
Commit the modified POMs
In other words, the Maven Release Plugin is exactly doing what you're asking for.
With the Maven Versions Plugin
If you don't use the Maven Release Plugin, the Maven Versions Plugin can be helpful. In particular, the following goals:
versions:update-parent updates the parent section of a
project so that it references the
newest available version. For example,
if you use a corporate root POM, this
goal can be helpful if you need to
ensure you are using the latest
version of the corporate root POM.
versions:update-child-modules
updates the parent section of the child modules of a project so the
version matches the version of the
current project. For example, if you
have an aggregator pom that is also
the parent for the projects that it
aggregates and the children and parent
versions get out of sync, this mojo
can help fix the versions of the child
modules. (Note you may need to invoke
Maven with the -N option in order to
run this goal if your project is
broken so badly that it cannot build
because of the version mis-match).
versions:set can be used to set the project version from the
command line.
versions:commit removes the pom.xml.versionsBackup files. Forms
one half of the built-in "Poor Man's
SCM".
versions:revert restores the pom.xml files from the
pom.xml.versionsBackup files. Forms
one half of the built-in "Poor Man's
SCM".
I mentioned several goals but the "most" interesting is probably versions:update-child-modules here. It would allow to change the version in the top parent pom and then to automate the update of the child. See Fixing a multi-module build for an example.
Can't help more, you need to experiment yourself now. Good luck!
References
The Maven Release Plugin
The Maven Versions Plugin