Hi all, A quick followup to this thread.
Richard, Mark D & I just got off a Skype call. We were updating each other on the 'dspace-replicate' work that we're doing, etc. As part of that call, we also discussed this Domain Model Review thread. In the end, between the three of us, we came to a general consensus of the following: After more thought, there are some general concerns around making Domain Model changes this close to a Feature Freeze. Even if they *shouldn't* affect too much, there are worries that they could accidentally cause instability, etc. In addition, even for 'dspace-replicate' to be released asynchronously via these Domain Model changes, it would need it's own refactoring (to depend on dspace-core-api), which may end up being too significant to implement before Feature Freeze. (Sidenote: However, I, personally, still believe that some of this Domain Model work could be worthwhile *after* 1.8.0 (hopefully very soon afterwards). It's been a long time since we've refactored anything in dspace-api. It would also be good to rethink our implementations for some "messy" areas of 'dspace-api', like Packagers/Crosswalks/Plugins, etc. and investigate more Spring Configurations, etc.) In any case, this leaves us with two main options for releasing 'dspace-replicate': 1. Move 'dspace-replicate' to Trunk. All three of us were a little concerned with moving another module to an already crowded Trunk. But, this is still an option. 2. Release 'dspace-replicate' immediately after 1.8.0 as a "add-on". But, also investigate ways to more easily install/upgrade add-ons as part of DSpace 1.8.0. Essentially, we'd want to find a way to script this add-on installation process (if possible). Ideas included creating a Maven Plugin to install DSpace add-ons, or possibly some sort command-line script that auto-add the appropriate dependencies to your pom.xml (similar to what Graham suggested in his previous email)? Ideally, this would be scripted, so you'd just run something like "dspace install dspace-replicate" or "mvn dspace:addon-install dspace-replicate" or something similar. Richard said he'd investigate this work and report back. Hopefully this is something we can still fit into 1.8.0, to ease the installation/update of addons in general. Just wanted to send an update on some of these related discussions. Beyond that, the rest of our discussion centered on specific changes coming to dspace-replicate in time for 1.8.0 Feature Freeze. - Tim On 8/1/2011 11:17 AM, Tim Donohue wrote: > Hi Richard, > > A few responses inline... > > On 8/1/2011 10:44 AM, Richard Rodgers wrote: >> Hi all: >> >> I have a few remarks inline, but my bottom line: I think this whole >> area needs more analysis before leaping into any solution, esp. right >> before a release. >> The Domain Model work is interesting and creative, but I'm not >> convinced we understand our use-cases well enough yet to judge it's >> applicability. >> >> Richard >> On Jul 29, 2011, at 5:53 PM, Tim Donohue wrote: >> >>> Hi All, >>> >>> I have a few more background details to add to Mark's description, >>> followed by a few comments of my own. >>> >>> == A little more about the problems we are encountering == >>> >>> As Mark mentions, for 1.8.0, Richard R& I would like to release >>> 'dspace-replicate'. More info at: >>> https://jira.duraspace.org/browse/DS-876 >>> >>> Unfortunately, the reality here is that 'dspace-replicate' sits in SVN >>> Modules (svn/repo/modules) and also depends on 'dspace-api'. So, to >>> release 'dspace-replicate', we would need to *first* release >>> 'dspace-api'. But, at the same time, 'dspace-api' can only be released >>> if we perform the full packaged DSpace release from Trunk. >>> >>> What results is a chicken-or-egg issue, where 'dspace-replicate' cannot >>> be included in the full packaged DSpace release unless it's released >>> *first*, but it cannot be released first as it depends on dspace-api. >> >> I guess I don't really understand this point - I see no reason why the >> dependency here is of special concern, or why there is a problematic >> chicken-and-egg situation. >> You say "include replicate in full packaged release", but I see no >> requirement for this at all. Replicate is a good example of >> of a candidate for 'asynchronous' release, which means precisely *not* >> at the same time as the packaged release. Why is it a good idea to >> require that all add-ons be synchronized? >> I'm imagining this is the sort of thing (cloud replication) that one >> would not immediately decide on, but could elect to add to one's >> system later. > > True, you are correct. > > A third option is the asynchronously release the 'dspace-replicate' code > entirely separate from DSpace 1.8.0. There may be some advantages to > that. But, I also see several distinct disadvantages: > > 1. We need separate installation & upgrade docs (and general > documentation) for 'dspace-replicate'. Where do those docs sit? Do they > go in with 1.8.0's official docs, or are they totally separate? This > module would *not* be a part of 1.8.0 out-of-the-box, but is just > "compatible with 1.8.0". > > 2. We need to make it clear how to install 'dspace-replicate' both to > command-line (copy JARs to [dspace]/lib/) and also how to install it to > XMLUI (copy JARs to [dspace]/webapps/xmlui/WEB-INF/lib/) and JSPUI, etc. > (And also make it clear that all these installs are separate -- you > cannot simply pull the JARs into a single location & expect it to be > fully installed throughout all of DSpace.) Is this "user friendly" > enough for a tool that is meant to make things more "user friendly" by > bringing more backup & restore functionality to Admin UI? Or are we > accidentally adding an unnecessary barrier here (by not having an > easy-to-install option, or having it already bundled out-of-the-box)? > > Obviously, both of the above issues can be resolved (to some extent) > with better documentation. They could also be resolved better in the > future by perhaps creating a "module installer" which can auto-install > the JARs for you to all the proper locations. > > Also, remember, 'dspace-replicate' is *not* just for cloud-based > replication. It could also be used to perform on-demand, day-to-day > backups (to a local mounted drive, etc.), by making the AIP Backup & > Restore tools available to the Admin UI. > > So, I'd argue that 'dspace-replicate' is useful to *anyone* who wants to > be able to kick off backups or restores from the Admin UI (and not just > those wanting to do so via cloud storage). In other words, if > 'dspace-replicate' could be generally useful to most DSpace system & > repository administrators, do we really want to force everyone to do a > separate installation process in order to utilize it? > > >>> >>> So, the options for moving forward currently include: >> So I see a third option: do nothing (for the moment). I had no problem >> compiling the replicate code from the pom (including it's dependency >> on dspace-api, and 3rd party libraries), and deploying the jar artifacts, >> and configuration files to a DSpace installation. So I think we should >> be clear that not doing option 1 or 2 below will not *prevent* the use >> of the replication module. Of course, we could add scripting or other >> tooling to make it easier, but it is not a complicated process as is. > > "Do Nothing" is a third option. But, I'd argue it's not very beneficial > for 'dspace-replicate' module (for the reasons described above). I > honestly feel that 'dspace-replicate' could be a major feature of 1.8.0, > if we wanted it to be. Again, it's not all about "cloud storage" -- it > does enable cloud storage, but it's also useful to normal hard-disk > backups. > > As you can already probably tell, I feel rather strongly that > 'dspace-replicate' should be pre-installed in 1.8.0. (If we had an "easy > installer" for modules, I'd be willing to go that route. But, I'm not a > fan of the manual installation route of "copy these configs here, now > copy these JARS to these 2-3 places, then restart Tomcat -- if you did > this all correct, then you'll see it appear. Otherwise, you did > something wrong or copied the JARs to the wrong directory.") > > I would be interested to hear what others think here though. If I'm the > only one who thinks 'dspace-replicate' would make a nice out-of-the-box > feature, then I'm fine with being overruled. This is a democracy after > all :) > > - Tim ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
