Hi Graham, It sounds like we actually agree completely in this. I'm NOT wanting to create an entirely new (non-Maven) path for customizations/addons that we cannot support. I'm literally just playing around with Easy Installer options to see if there's something that will work for both situations (i.e. whether you are using Easy Installer or Maven, you can do similar things -- or, perhaps finding ways you can start via Easy Installer and then switch to a manual Maven-based build if you want more capabilities for customization via Overlays or similar).
My initial approach to *simplify* installation was actually to do so via embedding Maven & Ant (i.e. wrapping them) into the Easy Installer. This meant you could either choose whether to manually do things via Maven (as you currently do), or 'automate it' based on your needs. Unfortunately, I ran into Maven limitations around this with my "Easy Installer" (see bottom section of this wiki page for more: https://wiki.duraspace.org/display/DSPACE/InstallerPrototype ) Still may be ways around it, I really don't know. If others have feedback, it'd be great to get tracked in DS-802 or on the wiki page above: https://jira.duraspace.org/browse/DS-802 It's also entirely possible that my current Easy Installer implementation will prove to be a "failure" or get "scrapped". I'm also perfectly OK with that, as long as I've successfully pushed us into trying to *simplify* how we are handling install/upgrade procedures (which is the most important goal here). If we can 'streamline' things, that's all I'm really looking for. This project is really just to point out that currently things are still a bit 'complex', and it'd be great if we can streamline or automate parts of it for our users who don't want to jump immediately into that complexity (while still allowing advanced users who want all options to use that complexity to their advantage). So, although this discussion has been good, I do think we are in agreement here. We're just stating it in different ways. - Tim On 5/12/2011 11:06 AM, Graham Triggs wrote: > Hi, > > On 12 May 2011 15:30, Tim Donohue <tdono...@duraspace.org > <mailto:tdono...@duraspace.org>> wrote: > > IMHO Documentation should likely have (at least) two audiences: > * Novice User (never tried DSpace before, but wants to try it out > and get it running relatively quickly) > * Advanced User or System Admin (describes/explains all available > options in great detail) > > Currently, it seems like our docs are a bit more "Advanced User" > oriented (just my opinion), or a conglomeration of both Novice and > Sys Admin with no real rhyme or reason. Don't get me wrong, it's > gotten much better over time, but we can probably do more to try and > cater a bit better to both audiences. > > > There definitely is at least two audiences - the technical level of > managing the installation files, and the user level setting up content, > policies, etc. in the UI. > > We probably don't have a clear [enough] demarcation between these roles > in the documentation - if you look at other software, these are often > split into separate documents. And I guess we have a grey area over > 'slightly' technical modifications, such as setting values in > dspace.cfg, or changing the logo / css in the UI. > > You are right that the demo.dspace.org <http://demo.dspace.org> site > can be used for Demos. But, if people *truly* want to try out DSpace > completely (including doing their own configurations, and starting > to learn more about all the options, etc), then they still have to > install it locally. Demo.dspace.org <http://Demo.dspace.org> just > provides a place to "play" with the default interface & a few > enabled settings. But, it still won't give you a sense of how you > may want to truly use DSpace in your own local environment. To do > that, you need to install it locally and play with its > configurations/settings a bit. > > > Exactly. So now they've installed it locally, what do we tell them to do > to configure it? Our existing documentation centers around the Maven > overlays as a best practice for separating and managing your changes. > Are we happy to tell them to just alter files directly in their > installation directory? Mess around with the images / css / jsp / xsl > inside the web applications? What happens when they want to enable > another addon? > > Whilst the current installation steps are not easy, following them at > least gives someone a reasonably solid footing for anything they want to > do after that. If we make it easy to install in a completely different > way, not only may we (they) be back to square one fairly quickly, we > could be creating a bigger problem later on (customizations in the > installation directory, but now they need to switch to using the Maven > process). > > I honestly still feel strongly that there is a need for an easier > way to install DSpace. If others disagree, then so be it (we can > always start this conversation with some of our users at OR11 to see > what they think). > > > I'm certainly not disagreeing - but simply making it easier without > thinking about what they may want to do after they have it installed may > not be beneficial, and possibly even counter productive. > > I just lean towards having an easier way of working with the 'proper' > assembly project over doing something entirely different. With a wrapped > Maven / Ant process, we have the ability to include dealing with addons, > and possibly even being able to upgrade versions of Dspace relatively > simply (providing your changes don't conflict). I think the benefits > gained from that outweigh the implications of network connectivity and > execution time. > > And I'm not saying that should be the one-right-way either, but I would > encourage people to step back from thinking about what can be offered as > an easy installation, and think about the context of why someone is > installing it in the first place. > > G ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
