Mark, getting back to this topic, the proposal did not argue for SNAPSHOTS vs.
timestamped releases. I want to try and keep the goal clear here. I am
suggesting that we use the Release repository as the default configuration for
fetching DSpace artifacts during build. So in official tags and packages of
e.g. DSpace 1.7 would refer in dependency references and parent POM references,
to <version>1.7.0</version> and not <version>1.7.0-SNAPSHOT</version>.
To enforce the non-use of potentially volatile/changing dependencies, the
repositories declaration should:
A.) Disable the SNAPSHOT repository to avoid using any volatile dependencies.
...
<snapshots>
<enabled>false</enabled>
<updatePolicy>daily</updatePolicy>
<checksumPolicy>fail</checksumPolicy>
</snapshots>
</repository>
B.) Enable the Release repository, in order to be confident the build is only
using unchanging, released artifacts, e.g. dspace-api-1.7.0.
<repository>
<releases>
<enabled>true</enabled>
<checksumPolicy>fail</checksumPolicy>
</releases>
...
C.) Be removed from any POMs and sub-POMs except for the Parent POM(s), and
possibly the main "dspace" project POM, to allow for easy switching between the
Maven RELEASE repository and the SNAPSHOT (for instance, when a developer wants
to easily switch to a development mode where she/he wants the latest artifacts).
--
sands fish
Software Engineer
MIT Libraries
Technology Research & Development
sa...@mit.edu<mailto:sa...@mit.edu>
E25-131
On Aug 26, 2010, at 10:38 AM, Mark Diggory wrote:
two reasons for using the "SNAPSHOT" rather than timestamp releases.
1.) with timestamped releases you will always need to run "mvn clean
..." during the build process because the assembly portion does not do
complete transitive dependency analysis. You may end up seeing
different versions of the same jar showing if you do not
2.) Using SNAPSHOT limits the number of release jars showing in the
snapshot repository s that space used for these releases is fairly
static. Keeping all releases around will create a larger snapshot
repo.
Some comments about the release process...
a.) We should be doing more integration snapshot build releases of
modules and trunk projects.
b.) These should be on a shorter cycle than the scheduled release process.
c.) Versions should change whenever a major customization is completed
(AIP, Rest, etc).
d.) We need Bamboo, it would alleviate a lack of automation for
scheduling new snapshot and fixed release builds to only occur in
concert with changes to the svn repository.
I'm not against using timestamped snapshot releases, I just want to
clarify the caveats.
Finally, a slight tangent... I'd recommend since we are on the topic
of maven... reviewing the poms also lead to an experiment to do async
releases on the existing dspace svn trunk. a copy of the whole trunk,
placed into the sandbox with version changes to be unique for each pom
module under dspace/trunk and an attempt to show how/where async
releases would end up in branches/tags. Finally, some adjustments to
the maven build and assembly protocol to show how assembly happens
once you have async releases and no longer distribute the source for
the individual modules in the release installation zip.
Mark
On Wed, Aug 25, 2010 at 1:30 PM, Sands Alden Fish
<sa...@mit.edu<mailto:sa...@mit.edu>> wrote:
I have outlined some adjustments to the way DSpace is released concerning
POM configuration and which Maven artifacts are used by default when
building. I would appreciate it if anyone had time to review the proposal
for possible inclusion in the 1.7 release. It is located in the Development
Proposals section here:
https://wiki.duraspace.org/display/DSPACE/Proposals
--
sands fish
Software Engineer
MIT Libraries
Technology Research & Development
sa...@mit.edu<mailto:sa...@mit.edu>
E25-131
------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net<mailto:Dspace-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/dspace-devel
--
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
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
