I'm in doubt about how snapshot versions fit into the release process described in:
http://jakarta.apache.org/turbine/maven/development/release-process.html.
This document mentions meaningful versions like "3.0-dev", "3.0-b1", and "3.0-rc1". Are such versions meant to be used as a project's currentVersion, and the project can be deployed in a special snapshot way such the deployed artifact's version is "3.0-SNAPSHOT"? Or is "3.0-SNAPSHOT" meant to be used directly as currentVersion?
Another issue is how to manage dependencies in a production branch of a group of dependent maven projects. Obviously, versions in a production branch must be "real" (x.y.z). Most J2EE servers require dependencies to be listed in the manifest classpath. Consequently, if a utility is patched, all J2EE modules depending on this utility must be repackaged because of the changed jar name. But when a J2EE module is repackaged, it should (correct me if I'm wrong) also be redeployed to the remote repository and hence have a new version number assigned first. This means that all J2EE modules depending on the utility must be patched and released/deployed.
How do I come around this problem? One alternative, I could imagine, is to strip artifact versions from jar names in the manifest classpath and strip versions from files when included in EAR or WAR files. I admit that this stripping is a bit un-mavenish.
How do you see this?
What is, by the way, the benefit of having version numbers in artifact names? Of course, it is easy to see the version; on the other hand this information is already in the artifact's manifest file. In Maven, the artifact name is also used for ensuring unique referencing of the remote repository. If artifact names did not include the version number, then Maven repositories should be organized with an additional artifact version layer like e.g. "groupId - version - type".
Regards,
Christian
Brian Ewins wrote:
Christian Clausen wrote:Hi,
I have noticed the following behaviour concerning maven dependencies:
[...] The first time a goal of a project depending on D is attained, the artifact is downloaded to the local repository. Suppose now that a new version of D is deployed to the remote repository, [...] the new version of D
is NOT installed in the local repository. Consequently, we are still using the old version of D.
This is not the case with snapshot jars - they are always downloaded again if you are online.
The point of version numbers is to make a build repeatable. If people use a /real/ version number, then replace the artifact, they are shooting themselves in the foot - builds are no longer repeatable. The point of SNAPSHOTS is to be able to ask for something where the name stays the same but you are willing to sacrifice repeatability - ie during development of related projects.
...during development in a larger
project consisting of several maven projects, I think it is good to be able to share "newest deployed versions" without having to be explicit about the "z" in x.y.z.
Try building, and depending on, artifact-x.y-SNAPSHOT.jar. (ie version x.y-SNAPSHOT instead of x.y.z) This should work exactly as you want, in recent b8 builds. This even allows you to build multiple 'working versions' of a project, eg tomcat-3.3-SNAPSHOT.jar, tomcat-4.1-SNAPSHOT.jar can coexist.
I can see one circumstance where having an unique name instead of SNAPSHOT for non-release builds is useful - thats when you're doing nightly builds, or otherwise timestamping jars, and you want to keep (eg) the last 5 nights builds around (note that keeping builds with unique names is for repeatability again). In this case, why not copy the nightly to the SNAPSHOT name in a postGoal? That way you have a SNAPSHOT thats consistent with the nightly, but you can keep using the same name if you don't care.
The SNAPSHOT convention neatly avoids having to decide what the 'latest' version of an artifact is (eg I have tomcat 3.2 - is tomcat 3.3 or tomcat 4.1 the latest? Answering 4.1 might break your code, and timestamps won't help you), and avoids attempting to do wildcards over the repository-protocol-of-the-day (eg tomcat-3.* - which still leaves you having to make decisions on the meaning of version numbers.)
Cheers,
-Baz
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
