Hi Mark,
On 10/7/2013 3:37 PM, Mark H. Wood wrote:
> <rant>
> Well, let me add the "why are we doing this?" view.
>
> Both by its name ("build.properties") and by its usage (by Maven) this
> file ought to contain only information that Maven needs to build the
> product. It should contain nothing which only matters during
> installation. Which is just about all of it. Taking a quick look, I
> don't see *any* properties which should have significance to Maven or
> our POMs.
>
> build.properties has the wrong name and is in the wrong place. It
> belongs to the installation process. It should be called
> "install.properties" and it should be used and/or applied by Ant, or
> whatever tool we use to drive installation. In that position it could
> be thought of as a saved-installer-answers file for replaying an
> installation (although you could hand-craft one beforehand, or edit as
> needed). We could even have a simple "wizard" to lead people through
> the questions and file the answers.
You bring up some good points which, generally speaking, I agree with.
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)
* 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)
* 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?
* 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 still will have questions around what configs are in this
install.properties (different institutions will likely still want
different fields)
Not sure if this is helpful either, but just thought I'd add to Mark's
interesting brainstorm. Please keep in mind this is still a brainstorm,
and I'm not implying we should change directions here, just want to look
at our options more closely.
- Tim
------------------------------------------------------------------------------
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
