On Tue, Oct 08, 2013 at 10:22:21AM -0500, Tim Donohue wrote:
[snip]
> It is a bit odd to be using "build.properties" from Maven, since it 
> mostly is specifying installation configurations. As I understand it, 
> the two routes you mention would have differing pros/cons:
> 
> 
> Current Route (build.properties & filtering in Maven)
> ------------------------------------------------------
>    * Pros:
>       * Allows IDEs to "run" DSpace from 
> [src]/dspace/target/dspace-[version]-build/ (as dspace.cfg is fully 
> filtered there)

build.properties should not be needed for this.  See below.  ("Should
not be needed" here means "DSpace should not depend on configuration
before installation begins".  We may have to tweak the source kit
somewhat to achieve that.)

>       * Can maintain *.properties files separately (e.g. not in GitHub) 
> & can have multiple for differing environments.
>    * Cons:
>       * Requires a rebuild (mvn package) & redeploy (ant update) for any 
> changes
>       * As noted, most/all configs need not be specified during Maven build
>       * As noted, we have questions around what configs are in this 
> build.properties
> 
> 
> Installation Route (install.properties & filtering in Ant)
> -----------------------------------------------------
>    * Pros:
>       * Configs specified only at point of installation/update. Changes 
> just require a redeploy (ant update)
>       * Would potentially allow us to distribute a fully compiled DSpace 
> Installer (which only needs Ant to deploy -- no Maven needed if you 
> don't want to compile DSpace locally)

The installer can have Ant shaded into its jar, so you don't need to
install Ant, only install Java and provide a DBMS somewhere.  I have
gotten as far as doing the shading of Ant and Ivy (to fetch the
artifacts being installed) as a start on a proof of concept.

>       * Could still potentially maintain these *.properties files 
> separately.
>    * Cons:
>       * Where would the 'install.properties' reside?  It cannot be in 
> the /target directory as that is an ephemeral location. Perhaps it'd 
> need to be copied to the /target/ by Maven?

That sounds right.  It should be a simple matter.  It probably
requires only an exclusion and a new file group in the assembly
descriptor, or something like that.

>       * Is IDE integration made slightly more complex?  DSpace Configs 
> would not be filtered until Ant is run, so can IDEs still point at 
> /target webapps for debugging/testing?

We have a testing environment in the source package, including a
configuration directory tree which is customized for testing during
the build process.  If we need to extend it, let's do that.

>       * We still will have questions around what configs are in this 
> install.properties (different institutions will likely still want 
> different fields)

Yes.  We should analyze the set of configuration variables and see
which ones are absolutely required to stand up DSpace, and which could
be moved into the administrative UI.  I think the former boils down to
the location of [DSpace], optionally an alternate location for
dspace.cfg, and a DBMS connection.  The servlet container can supply
all of these in a standard way through Context parameters or
Environment objects.

That separation will require some attention to the code which depends
on those variables, so that (for example) asset access code can notice
that there is as yet no assetstore and politely point this out, rather
than (say) upchucking an NPE and stack dump.

-- 
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
Machines should not be friendly.  Machines should be obedient.

Attachment: signature.asc
Description: Digital signature

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel

Reply via email to