Tim, I was thinking the same thing. I'll start working on a patch from the trunk that mirrors what we did locally.
-- sands On Sep 27, 2010, at 1:29 PM, Tim Donohue wrote: > 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
