-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
All my answers assume you're using Maven 1.0.2.
On Aug 4, 2005, at 10:22, Jamie Bisotti wrote:
- I have two active, rapidly changing, projects, A & B, I'm going to
build and deploy to an in-house remote repository.
- B depends on A.
- Currently, A's <currentVersion> is 1.0
- Currently, B's dependency for A uses a <version> of 1.0
- A will get built and deployed with the 'jar:deploy" goal, which will
place A-1.0.jar in the in-house remote repository.
- The first time B gets built, A-1.0.jar will get pulled from the
in-house remote repository to the users local repository.
- Each time thereafter, when B gets built, it will use that original
version of A-1.0.jar in the local repository, even though A-1.0.jar
have changed multiple times in the in-house remote repository.
To get around this, I need to:
- Change B's dependency on A to use a <version> of SNAPSHOT
While I think this will work, there's a better way to do it, at least
in my opinion. See below.
Questions:
1. Do I need to use jar:deploy-snapshot when building A? Or, is Maven
smart enough to just check the timestamp of A-1.0.jar in the local
repository against the one in the in-house remote repository and
download it again if it is newer? I think the answers are "Yes" and
"No", respectively.
"No" and "No". If the version given for a dependency does not contain
the word "SNAPSHOT", Maven will not check the remote repository to see
if it has been updated. The assumption is that version 1.0 is version
1.0 is version 1.0, regardless of the timestamp. If the contents are
different, the version string should be different -- with one
exception. See below.
2. Do I need to change A's <currentVersion> to 1.0-SNAPSHOT? Or is
jar:deploy-snapshot smart enough to name the snapshot JAR
appropriately? I think the answers are "No" and "Yes", respectively.
My personal for the first one is "Yes". The second one is "No".
What we do (this is just one possible way of doing things, but I can
personally vouch that it works fairly well):
While project A is in active development, we set the currentVersion to
the version it will be when it's released, appended with "-SNAPSHOT".
So, for instance, a brand-new project would likely have a
currentVersion of "1.0-SNAPSHOT".
For any projects that depend on it, the version in the dependency is
the same, e.g. "1.0-SNAPSHOT".
To deploy a new build of project A, use "jar:deploy".
When building project B, Maven sees that the version string for A
contains "SNAPSHOT", so it downloads a new copy of A. (I think it does
this regardless of timestamp, but I'm not sure of it.)
When we release project A, we remove "-SNAPSHOT" from currentVersion
and deploy using "jar:deploy" again. Then, after tagging the release in
our version control system, we usually bump currentVersion and append
"-SNAPSHOT" again (e.g. from "1.0" to "1.0.1-SNAPSHOT") to safeguard
against accidentally overwriting the released version.
Now, the tedious and unfortunate part: We have to go in to all of the
dependent projects and remove "-SNAPSHOT" from the version strings for
the dependency declarations for A to start using the released version.
Similarly, we have to add "-SNAPSHOT" when we want to start using a
development version again.
Keeping track of the most current versions of all of our projects, and
the dependencies on them, can quickly get out of hand. I finally wrote
a Ruby script to scan a POM and report if any of the dependencies are
out of date, or are snapshots. I run this right before building a final
release of a project, to ensure that it doesn't depend on any code
still in development. It has the added benefit of making it easy to
keep third-party dependencies up to date. For instance, if I see
there's a new version of Spring available, I update my Ruby script and
run it against all of our POMs to see which dependencies to update.
Hope this helps.
- --
Craig S. Cottingham
[EMAIL PROTECTED]
OpenPGP key available from:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7977F79C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFC8j06EJLQ3Hl395wRAlmhAJwMypVWEJUd5tooEXBo41/M2okPfwCeJFJR
mvxyY0nw6RXzv12e/KMv44w=
=/6ZV
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
