On Dec 11, 2007, at 4:23 AM, Richard Jones wrote:
Hi Mark,
Due to the current limitations of the maven build system, which does a
fine job of managing source code modularity, but cannot yet cope with
the more subtle angles of adding new modules, many existing modules
(sword included) cannot be trivially downloaded and installed. They
require modifications to the dspace pom.xml, additional configuration,
and files which are not dealt with by the build process must be
included, and so forth. Therefore, it makes sense that these be
released together ready-integrated, as it were, when stable
releases are
announced.
If all your referring to are additions to the config directory, these
"configuration" details should necessarily be the "obligation" of the
installer to put in place. I think a well written addon would report
the configuration parameters needed in dspace.cfg or files that
should be added to crosswalks etc on startup/installation somewhere
like dspace/config/dspace.cfg.<addon-name> with a simple copy into
place from a version in the jar somewhere.
I think A good Addon could easily be responsible for generating any
example files in dspace/config as necessary on startup or
"installation" of the application if we simply introduced an IoC or
reflection based solution that sought to complete these as tasks on
installation, rather than on packaging of the installation.
Richard Rodgers has been exploring something like this and looking
into secondary artifacts that could be passed through the maven
repository and deployed into config and etc on packaging. What your
referring to as a limitation in Maven is really a misperception about
its capability and actually a limitation in how DSpace configuration
was originally architected. It would be a pain point with any build
solution as you experienced in the first addon prototypes.
In summary, I don't mind where dspace-sword is versioned, but I do
think
it's important that it gets released in the same package as the main
DSpace. If this means putting it in trunk alongside other modules in
the same position such as the LNI (which wasn't in trunk for 1.4.2)
then
that has to be the interim solution.
Scotts comments on stability etc, suggest its an issue. I can't
really comment on that.
~~~~~~~~~~~~~
Mark R. Diggory - DSpace Systems Manager
MIT Libraries, Systems and Technology Services
Massachusetts Institute of Technology
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
