Henri Yandell wrote:
On Sat, 27 Sep 2003, Mark R. Diggory wrote:
Hi everyone,
We [math] have been trying to figure out the best proactice for setting up our Maven dependencies for the math project. currently we've been using both SNAPSHOT and release jars as dependencies.
Two possible paths:
1.) set dependencies to SNAPSHOT, always resolve errors that may arise as dependencies are developed in real time.
I'd recommend against ever linking to SNAPSHOT outside of a development environment. ie) one rule for releasing should be no SNAPSHOT dependencies.
I am referring to development versioning vs release versioning here, this is a feature of maven that is not being taken advantage of. One can tolerate some references to SNAPSHOT in the project.xml if they are resolved to version numbers during the construction of the release version by Maven (see further below).
2.) set dependencies to a specific version number, track all dependency projects and update as new releases arise, resolve bugs against new release prior to commiting dependency on that release.
At release time, this is how it should be.
Finally,
From my understanding, Maven will resolve SNAPSHOTS to thier proper build number when creating the distribution, so when the distribution is produced it will resolve to the versioned jar properly. But I'm not sure if this is even usefull for a commons component where the real product is the actual jar file and not the distribution tar ball.
? You'll get: commons-math-SNAPSHOT.jar. For the build, there is no version to resolve to, so how would it know what version to choose?
First note, not the project jar - the dependency jars in the maven repository, specifically the behavior I'm refering to is in these to sections of the maven user manual:
http://maven.apache.org/reference/user-guide.html#Using%20SNAPSHOT%20Dependencies
http://maven.apache.org/reference/user-guide.html#Resolving%20SNAPSHOT%20Dependencies
When the release/nightly build/snapshot jars are published in the repository, from my understanding, the snapshot is really just a symlink to the the lastest nightly build. This symlink is somehow resolved when the distribution is created and the original nightly build is used.
> Hen
The issues that seem to arise have to do with not getting too far ahead of, or behind of, the present development state of our dependences.
Any recommendations and opinions would be greatly appreciated.
Mainly, use SNAPSHOT for loose development, basically when you want to run against HEAD. We ought to have the nightly gump build pushing a SNAPSHOT version out for every build.
When release time comes, mandate choice of a version for each dep.
Subsequentally you can either wait for someone to want an upgrade to change a dependency, or at the start of each development phase, you upgrade the dependencies to the latest and consider any breaks in the build to be bugs to fix for the next release.
I quite like the latter option.
I'm still not sure which I like better. In theory the first would seem to alleviate much of the work surrounding tracking dependency versions that would be associated with the second. Yet, the whole thing pushes the state dependencies in the "development stage" up to the "bleeding edge" side of the scale. This has both benefits and hinderances.
-- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
