Sands, Getting back to this issue again -- I think it might be helpful to post a patch in JIRA for review. Seems like a logical fix to me, but it may clarify things and help us to resolve this for 1.7.
Thanks! - Tim On 9/2/2010 10:52 AM, Sands Alden Fish wrote: > 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 ------------------------------------------------------------------------------ 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
