Robin, Thank you for a great introduction. I'll inject just a few comments inline.
On Thu, Jul 14, 2011 at 2:22 AM, Robin Taylor <robin.tay...@ed.ac.uk> wrote: > Hi all, > > A large portion of yesterdays meeting ended up being a discussion on > async releases. Mark (Diggory) has for some time been strongly > advocating this approach and has written extensively on the subject both > on the wiki and in Jira. I think it is incumbent on us all to consider > his arguments and comment thereon. So to give him a rest I'll chip in, > albeit from a different angle. Thanks, I thought my vacation would leave me well rested. But alas, traipsing across the US with 6 yr old and a 11 month old turned out to be as exhausting as it sounds. > > Some background - DSpace can currently be downloaded from Sourceforge > either as a source code or binary release. > > The proposition (as I understand it) - Allow for releases of individual > DSpace Maven modules outwith the normal 'complete' release that > currently takes place roughly once a year. By a release I mean copying > the DSpace Maven artifacts (jars and wars) to the DSpace Maven > repository space to be publicly available. This is the maven portion of the release, there are two "distributions" that are released as well (a) dspace-release-x.x.x : just the dspace "assembly" project that brings together all jars/wars to build ones distro (b) dspace-src-release-x.x.x : the above assembly + all maven projects in trunk in source form, requires building all jars and wars needed for DSpace. If course, (a) requires more bandwidth to download officially released binary jars of dspace and (b) packages local versions of those jars/wars that I would describe as "unofficial local binary variants". At this time there are two approachs to customize your DSpace build. (1) use the source distro and change all the files you want and rebuild the entire sourcetree Pro: you can navigate to exactly the source that is being used and override it directly. Cons: Maintenance and Tracking of customizations across DSpace versions requires a developer with extensive knowledge of version control systems, changes will often conflict with work ongoing in DSpace releases. Local institutional developers altering DSpace internals introduce a conservative viewpoint into the community limiting the advancement of the codebase because they actually prefer these customized parts of DSpace to not change rather than see benefit of new development come into the Community. DSpace source release build process is too long for iterative development (2) use an overlay (works with all webapp projects (xmlui, jspui, oai, sword, lni, solr) and copy the source files you want to alter/override into separate dspace/modules/xxx projects, building only those changes you want. Pros: Only the code that you've changed need to be rebuilt Build Process is shorter Models how to extend DSpace via Addons, resulting in less customization of DSpace internals and greater ease in upgrading a DSpace instance (of course, this depends on the the local developer not adopting the practice of overriding existing DSpace classes and instead applying a process of implementing their own "Service Based" approach to implement a solution. Works well IDE's that use maven source artifacts to resolve the source for a specific java class. (m2eclipse and Intellij IDEA) You can Check out separate modules and via the maven profiles in the dspace/pom.xml you can build only the source components you want. Cons: Its not my opinion, but some in the community seem to think that it is a hinderance if you either need to use an IDE or separately checkout the code for the module you want to get source from (when doing the bad practice of overriding classes directly, which we suggest trying to avoid doing to ease maintenance of your customizations. > > So why do async releases ? There are a number of reasons, for example... > 1. To fix a bug in module dspace-xxx we could just release that module. > 2. Or make available new features without waiting for the annual > release. > 3. Or release entire new modules > etc etc. > > So how would this work ? The important thing to note is that it is > dependant on people using the binary release. If they wanted to pick up > a newly released version of a module they would just need to change the > version number of that module in the appropriate pom and rebuild their > local version of DSpace. Not explicitly, as i've said above, you can checkout or export the source for a module into your build and have the dspace-release-x.x.x build only that portion for your build. > Even better, we could distribute the binary > release with ranges of version numbers (Maven allows for <version>1.7.1, > 1.7.2, etc) and then all they would have to do would be to rebuild and > it would automatically pick up the latest version. It is worth noting > that this is exactly what we already do for the language packs so this > is not new. I don't really recommend this, it works for language pack because they are optional. > > The problem (as I see it) - this all falls down if people have the > source code release. If people have the source code for a module in > their local installation then that is what they should be deploying. > Whilst it would be possible for them to change the dependencies in their > poms to pick up newly released artifacts from the Maven central repo I > don't think anyone would argue that it would be a good idea to have one > version of the source code in your installation, but actually deploy a > different one, too messy. I agree, but this wasn't a recommendation in the new build process. > > So, if you are a fan of the XMLUI and Maven overlays, a binary release > might well be sufficient for you. You can of course still check out the > code for any module that interests you from the DSpace SVN site. > > However, if you are a JSPUI user and/or want or need to see the source > code in general, then you probably want a source code release. That way > you don't have to familiarise yourself with the DSpace SVN site. Not, this approach works with all webapps, not just XMLUI/aspects. Overlays will be a powerful tool even in the new WebMVC and REST projects. > > Could we continue to do both a source and binary release as we do at > present ? Yes. Many of the modules that currently reside in trunk in SVN > would be moved into the modules directory so that they could be released > independently of one and other, and the assembly of the source code > release would pick up the source code from there rather than from trunk. Yes, a maven assembly can create something that looks a lot like dspace-src-release-x.x.x > The downside of continuing with a source code release is that it > prevents us from unifying behind one approach and being able to make > announcements relating to new releases (async or otherwise) that apply > to everyone. No, we can still have an officially sanction release, it would just contain separately versioned submodules rather than all residing on one version tree. Maven's release plugin will even mediate assuring that an aggregated release of all separately managed modules happens and a build with complete and compatible release numbers can occur. > > Personally, I am still in favour of source code releases. I don't see > DSpace as a framework on which people build their local customisations, > I see it as a complete implementation which people take and do what they > want with it. I'd be curious about the statistics around this last topic, we actually recommend dspace as a framework on which people build their local customizations. Depending on the degree of complexity of those changes, we recommend working within specific "levels" of customization of DSpace. (1) CSS Theming and branding (2) XSLT/HTML alteration (3) Customization and Creation of new XMLUI Aspects (4) Creation of Custom DSpace "Services" to support new functionality. (5) Alteration of core DSpace Code. Each Leads to progressively greater complexity and maintenance of the codebase and a need to merge local changes. We advocate starting and trying to stay at the levels 1 - 4 and avoid doing (5). When doing (5), we recommend the the developer community be consulted to determine if there is an opportunity for such changes to be contributed to the next version of DSpace, thus reducing the organizations maintenance burden. > > Phew! I'm knackered. I'm just getting started ;-) Best, Mark -- Mark R. Diggory @mire - www.atmire.com 2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010 Esperantolaan 4 - Heverlee 3001 - Belgium ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
