Sands,
I think your overlooking that theres no need to even configure the "release
repository", as its maven central. And this is why the current repo listing
is only the snapshot repository. (Note eventually we want to attian "no"
third party or snapshot repository entries in our POM so we can utilize the
sonatype repository hosting for our releases.
Your logic is in error because those switches your referring to are will
actually do the oposite of the goal you are seeking. IE they will cause the
snapshot repo to be included into the transitive analysis of release
artifacts (something we surely do not want).
The snapshot repository has snapshots enable on it because that is what it
is for in the first place. Your disabling it will disrupt the development
process on the trunk, forcing us to use some sort of profile or other option
to enable it.
There are never release artifacts issued into the snapshot repository, only
snapshots, if there are, we need to remove them (Ideally, we may want to
consider that the snapshot repo should probably be purged of snapshot builds
after every release).
A full release of DSpace does not look to resolve SNAPSHOTS because the
"maven release process" removes them from the dependencies and forces you to
choose full fledged releases. In maven, a release will always be chosen
over a snapshot when "snapshot" is not designated in the dependency version.
Please read:
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
Incorporating SNAPSHOT versions into the specification
Resolution of dependency ranges should not resolve to a snapshot
> (development version) unless it is included as an explicit boundary. There
> is no need to compile against development code unless you are explicitly
> using a new feature, under which the snapshot will become the lower bound of
> your version specification. As releases are considered newer than the
> snapshot they belong to, they will be chosen over an old snapshot if found.
I would request that you produce a script or something that replicates the
behavior that your describing because building a release version of dspace
should never ever pickup snapshots in its build process. If you are getting
them, then something else has been done in your environment that is
gathering the wrong artifacts or leaving behind stale builds (ie are you
properly running "mvn clean package" or just "mvn package").
It is not my experience that what your suggesting will give you the holy
grail you seek. The more appropriate approach would require us to change
our dependency management policy to force dependencies to always point at a
specific version of the artifact by using "[ ]" around it, this would assure
your build did not seek out a newer version of a dependency. We need to
spend more time doing dependency analysis and fine tuning before each
release. Tim I would put a place holder where we discuss the maven
dependency plugin and analysis at the next meeting.
Mark
--
Mark R. Diggory
Head of U.S. Operations - @mire
http://www.atmire.com - Institutional Repository Solutions
http://www.togather.eu - Before getting together, get t...@ther
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
