On May 10, 2011, at 10:11 AM, Mark H. Wood wrote:
> On Tue, May 10, 2011 at 08:56:04AM -0700, Mark Diggory wrote:
>>
>> On May 10, 2011, at 7:23 AM, Mark H. Wood wrote:
>>
>>> On Tue, May 10, 2011 at 01:38:52PM +0100, Robin Taylor wrote:
>>> [snip]
>>>> Whilst editing a pom is an option for developers who are familiar with
>>>> the DSpace Maven infrastructure I think we need to come up something
>>>> much more user friendly. In the UK at least most sites do not have a
>>>> dedicated repo developer. I also suspect most sites take the code from
>>>> the downloadable zip and never go near SVN. There is already a Jira
>>>> issue from the DCAT group asking for an install process that doesn't
>>>> require the installer to get involved with Maven and Ant. I think we
>>>> risk alienating a section of the community if we don't provide an easy
>>>> mechanism to add modules and/or find the source code. This is not an
>>>> insurmountable problem, we just need to figure out some good solutions.
>>>> I'm looking forward to seeing Tim's Installer, it might spark off some
>>>> good discussions.
>>>
>>> Yes. Sites that don't want to alter DSpace shouldn't need to even
>>> *have* Maven or Ant:
>>>
>>> 0. install servlet container and DBMS if you don't already have them
>>> 1. cd DSPACE_HOME
>>> 2. unzip /path/to/DSPACE-CORE-PACKAGE
>>> 3. unzip /path/to/SOME-ADDON-PACKAGE
>>
>> Addons have dependencies that need to be "Resolved" and
>> "prioritized/selected" so it has to be more than an "unzip". MAven does this
>> transitive analysis for us, thus its important.
>
> Addons are *built* against the code the add onto, so won't this happen
> at build time? At install time they just drop in, if properly
> organized. We can document the meaning of "properly organized".
Maven modules produce artifacts that have dependencies on other artifacts which
have further dependencies. Even in the Confluence Plugin OSGi container this
is the case (albeit the artifact in this case is a bundle) In OSGi the
container enforces that the dependencies need to be met on deployment or the
bundle cannot start. Without maven or OSGi how would we even attempt to this
"very real" problem? A problem I'll add that we solved by adoption of maven.
>
>>> ...
>>> 4. ./bin/dspace create-administrator
>>> 5. tell your servlet container to look in DSPACE_HOME/webapps/YOUR-CHOICE
>>> 6. login to the repo. as administrator and configure
>>> 7. kick the servlet container to restart the repo. (if necessary)
>>
>> I actually think we can do away witht he above by carrying the container
>> inside the dspace installation. We have a case in CSU where we do this, you
>> can put the container+dspace anywhere you want to without having to alter
>> dspace.cfg to run it because we set everything as relative paths to the JAVA
>> working directory (in this case [dspace.dir]/bin
>
> Eww. I *hate* finding there's a whole web server inside some thing I
> wanted to plug into the web server that I already had running. While
> an all-inclusive package may appeal to some, I would choose another
> packaging.
Its a valid solution, theres very little that is special about it having to
"Be" in this or another container The topic of dialog was providing a
distribution that would be quick to deploy/start, packaging a servlet container
eliminates significant complexity in attaining such a solution.
>
>>> Step 5 might include specifying the DBMS connection, since either that
>>> or the value of DSPACE_HOME will have to be provided to the webapp(s)
>>> from the outside.
>>
>> This is the tough one... but combined with my previous comment, running a
>> native or in-memory java rdbms would make the configuration of a database
>> not a requirement for install.
>
> This part is ridiculously simple in Tomcat:
>
> $ cat /etc/tomcat-6/Catalina/localhost/mhw#trunk-1.7#xmlui.xml
> <Context
> docBase='/home/mwood/dspaces/trunk-1.7/webapps/xmlui'>
>
> <Parameter
> description='Path to the DSpace configuration file.'
> override='false'
> name='dspace-config'
> value='/home/mwood/dspaces/trunk-1.7/config/dspace.cfg'
> />
>
> <Resource
> name='jdbc/dspace'
> description="DBMS connection pool for DSpace's database"
> type='javax.sql.DataSource'
> factory='org.apache.commons.dbcp.BasicDataSourceFactory'
> auth='Container'
> username='foo'
> password='baz'
> driverClassName='org.postgresql.Driver'
> url='jdbc:postgresql://localhost:5432/mhw-trunk-1.7'
> maxActive='30'
> maxIdle='-1'
> maxWait='5000'
> />
>
> </Context>
>
> The above is running right now (except that those aren't the real DBMS
> credentials). It provides everything DSpace needs to know to find itself.
>
> Okay, it doesn't *look* simple, but most of it is boilerplate. A
> path, two class names, a database name, a user name, and a password
> are all that need vary until you know your way around the product.
> Tell the installer program which DBMS you use and it supplies the
> class names, which are the only bits you might not know.
>
> Drop one of those where Catalina looks for them, and it starts.
> 'touch' it and the app. restarts.
Yes, and Grahams work on the configurable DataSource in DSpace would allow
something like this to be used, even if it were the oracle "flavor" of the h2
configuration.
# Database name ("oracle", or "postgres")
# We have to treat H2 as Oracle so the column names are converted to uppercase
db.name = oracle
# URL for connecting to database
db.url = jdbc:h2:mem:test;MODE=Oracle
# JDBC Driver
db.driver = org.h2.Driver
# Database username and password
db.username = sa
db.password = sa
but that doesn't resolve initialization of the database (see our test suite for
an example, where it sets up the database and initializes the necessary schema.
In theory, with a similar configuration it should be possible to create the
in-place java rdbms so that you can run such a distribution out of the box
without configuration changes. Its effectively a demo platform that gets the
basic enduser with a demo system for trying out dspace, Then when you are ready
to setup production, yes, you need to create the postgres or oracle database
and configure it yourself.
To be clear the point of the exercise wasn't that you would get an installer
that did every task a seasoned system admin would want out of the box, but that
one could produce a deployment similar to Confluence with DSpace simply by
creating an assembly of some resources and adjustment of the default
configuration to be relative and predefined. The only work that would be left
to run that dspace instance would be the deployment of a native java database
like we use for testing, otherwise configure a real rdbms for production.
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
