On May 10, 2011, at 9:19 AM, Tim Donohue wrote: > Mark, > > A few responses inline. > > On 5/10/2011 10:51 AM, Mark Diggory wrote: > >> Hmm, so you would favor a custom installer that we would have to put >> more resources into maintaining rather than a tried and true build >> tool thats got tons of documentation, tutorials and uptake? Doesn't >> this result in even more additional training and complexity? Do you >> not expect that there are more developers in the world with >> experience using Maven then there are in DSpace? >> >> I think you need to ask the question, "who" is saying they want a >> simple installer, is it a developer, a system admin or is it a >> curator/repository manager? What should the technical background be >> developing DSpace and what should there technical background be for >> installing DSpace. TBH, if you choose one approach you risk excluding >> the others and we should be cautious about that. I say this from >> experience because we do have much more complex cases than a simple >> installer will ever be able to support, we have cases where we have >> multi-stage, multi-tiered, multi-tenant dspace enterprise platforms >> with webui developers redeploying webapplications remotely, we will >> be very cautious of any solution that may impact this. In this >> regard, such an installer needs to be itself "one-off" or an separate >> module/tool from the default build process. > > Actually, if you look at the activity on 'dspace-tech' since 1.7.0 was > released, you'll see a large number of questions about problems > installing/compiling/setting up DSpace (especially revolving around Maven or > Ant frustrations -- either it's not building properly, or Ant isn't copying > files properly, etc). So, I'd actually say *many* people seem to be > experiencing frustration with the current install/compilation process, and > the more we ignore those frustrations the more DSpace will turn into a tool > that only knowledgeable Java Developers will understand and be able to > install easily. > > I think it's also worth pointing out that not all DSpace users are > *developers* or even have developers on staff. > > Suppose we compare our DSpace installation processes to that of Confluence, > which is another Java based web application using Maven. Confluence doesn't > require that you need to know/understand Maven or Java in order to *install* > it. However, if you want to *develop* plugins for Confluence, it does require > more Maven/Java knowledge (obviously).
Yes, but you need to realize that confluence has certain standards it maintains. 1.) Its just one webapplication and only one webapplication 2.) It packages a tomcat version in the distribution 3.) It uses a native java db out of the box 4.) All file references can be "relative" rather that absolute. I.E. CONFLUENCE_HOME can just be "..". But then for Plugins 5.) An OSGi implementation mounts a secondary directory to run plugins as OSGi Bundles and runs the OSGi container within the webapplication itself (unlike the way that DuraCloud runs it) 6.) Provides a UI and other tools to add/remove bundles from that OSGi container at runtime. So its important to note that technologically, they solved the development of plugins by smartly adopting a popular third party solution for modularity rather than creating their own. That you don't need to build "confluence nor your "plugins" to deploy them. Pretty smart folks there. > > We should be thinking about similar ways to ease usage of DSpace. To install > DSpace we shouldn't require Java or Maven (or Ant) knowledge. Obviously > though, if you want to develop plugins/addons or improve DSpace we may need > to still require that you understand Java, Maven, etc. So I'll bite... With very minimal effort (no code changes), we have done a standalone deployment of DSpace with an embedded tomcat instance such that all configuration was relative to the current working directory (meaning it doesn't care where its located in the file system). if someone were savvy enough to get a native java db fired up with a schema installed and available as the DataSource by default... we'd pretty much have accomplished a standalone DSpace that could be started just by unzipping it and navigating bin and calling "catalina.sh start". The problem is... its approaching 300Mb to download the package due to the replicated jars in all the webapps and lib So if you want to distribute in such a manner, something needs to happen to reduce the size of the application. Consolidating webapps, shared lib in tomcat, using webapp lib for cli lib, etc... If you want to go further and mess around with deploying your own addon to such a beast... well, it'd just be your [dspace.dir] and you'd checkout the source. If you built to it, your config, lib and webapps would get backed up and replaced with new versions... Mark -- Mark R. Diggory @mire - www.atmire.com 2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010 Technologielaan 9 - 3001 Heverlee - Belgium ------------------------------------------------------------------------------ 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
