Brian Ewins wrote:
Christian Clausen wrote:
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?
The instructions on that page are not current, but are advocating
developing with a SNAPSHOT most of the time. It should read '-SNAPSHOT'
everywhere it currently says '-dev'. You can set a projects version to
include 'SNAPSHOT' by editing the project.xml, or by running 'maven
jar:install-snapshot', or 'maven jar:deploy-snapshot', the
recommendation is to do it by changing the project.xml.
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). [... if you change a utility
version ...]
all J2EE modules depending on the utility must be patched and
released/deployed.
That's exactly right, and with good reason. If you change the version of
a utility, how do you know that the things which depended upon the
previous version still work? Being explicit about dependencies does mean
more work, but it pays off in the long run.
OK, so being forced to update all dependencies can be seen as a "patch
certification procedure". Is there a way to get a single overview of a
potentially large dependency tree? (I mean, in case module A depends on
module B which depends on the changed utility, the certification
procedure must begin with module B and then A.)
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?
Maven should write the Class-Path: entry for you, but you should be
explicit in your project.xml about the things you depend upon. In other
words, maven is making it easier for you to follow a disciplined
approach that would otherwise be a right royal pain in the bahookie.
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.
- its better for support. Support teams and customers don't understand
manifests, but ask them what the file name is and you'll get a straight
answer.
- most manifests created without maven don't include this information.
That's why the fingerprint.jsp that I wrote in apache axis prints file
sizes instead of dipping into the jars to check versions - the
information was useless.
- most tools used during the build process know about files, not jar
manifests. E.g. a tool to copy a file from one place to another. By
putting version info into the filename, you let these tools help you
check if your build is consistent.
- it makes errors easy to spot just looking at a directory listing.
>
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".
Yes, the repository would be better with a metadata layer, but there
isn't one as yet. Lots of people (including myself) have suggested this,
and other changes to the repository design, but the response from the
maven team is quite rightly 'send us the patches'. The current repo
design is about the simplest thing that gets the job done, anything else
is gravy.
Cheers,
Baz
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Christian Clausen, M.Sc.
TietoEnator Financial Solutions A/S
Ved Lunden 12
DK-8230 �byh�j
Denmark
Phone: +45 7027 6400
Direct: +45 8746 6460
Fax: +45 7027 6440
Email: [EMAIL PROTECTED]
Internet: www.tietoenator.com
--
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
