Dependency question

[Jamie Bisotti <jb...@gmail.com>]

Just want to make sure I've got this straight.

- 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

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.
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.

-- 
Jamie Bisotti
Software Engineer
Lexmark International, Inc.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Dependency question

[Brett Porter <br...@gmail.com>]

Craig is spot on here - you use nextVersion-SNAPSHOT in both
currentVersion ad dependency versions until it is released.

Some extra things to note:
- jar:deploy-snapshot is deprecated. In the latest artifact plugin,
jar:deploy will behave that way if the version contains SNAPSHOT, or
behave like a release otherwise

- you can avoid multiple updates to dependencies by using inheritence.
For dependencies used everywhere, you can inherit the actual
dependency. For deps that just want the same version wherever used,
use a jar override with a version. If you use this feature, be sure to
use the latest Artifact plugin available for your version of Maven -
it will make better POMs in the repo that will help if converting to
m2 later.

- you also don't need to synchronize versions - there is no harm in
keeping to the minimum version required, and just updating to the
SNAPSHOT where used, or in assemblies such as WAR or executable
distributions (as they must meet the requirements of all dependencies)

- if you use the latter approach, the multiproject report will show
you what versions are out of sync.

- finally, scm:prepare-release eases the process of releasing a
component - however it doesn't look after SNAPSHOTs (something that is
improved in m2, just like all of the above :)

Hope this helps!

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Dependency question

["Craig S. Cottingham" <cr...@cottingham.net>]

-----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
craig@cottingham.net
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org