[
https://jira.duraspace.org/browse/DS-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25444#comment-25444
]
Steve Swinsburg edited comment on DS-921 at 7/9/12 6:10 AM:
------------------------------------------------------------
Why don't you just use the standard Maven build filtering? The support is
already half there in that dspace.cfg has placeholders for a lot of the
properties, however those could just come from a properties file and the POM
setup to insert the values for the placeholders at build time.
Each system then has its own properties file.
was (Author: steve.swinsburg):
Why don't you just use the standard Maven build filtering? The support is
already half there in that dspace.cfg has placeholders for a lot of the
properties, however those could just come from a properties file and the POM
setup to insert those placeholders at build time.
> Build script supporting multi-developer config, automatic container launching
> and code coverage
> -----------------------------------------------------------------------------------------------
>
> Key: DS-921
> URL: https://jira.duraspace.org/browse/DS-921
> Project: DSpace
> Issue Type: New Feature
> Reporter: Gareth Waller
> Attachments: dspace_buildframework_180112.tar.gz
>
>
> The current DSpace configuration and build process makes modification
> difficult in a multiple developer environment e.g. a project with a couple of
> engineers.
> Consider the following scenario:
> - A project wishes to make significant modifications to the DSpace codebase
> - The project consists of multiple developers (potentially on different OS's
> and varying install paths for binaries e.g. maven)
> - Each developer wants their DSpace to be stored in potentially a different
> location to another developer e.g. their home dir
> - Each developer wanted a one step process to build, deploy and launch DSpace
> within a container (to make development and testing quicker)
> - Code coverage analysis was required to see how effective system tests were
> - The project doesn't want to commit their entire DSpace codebase to their
> own internal source code management system e.g. svn
> - The project needs to know exactly at any point in time which DSpace files
> were modified (and what those modifications were)
> - An easy way to generate a patch is required in order to raise a Jira and
> submit the code back to DSpace
> - An easy way to perform automated web testing was required for a nightly
> build
> The scenario described above was encountered on the UK Jorum project and we
> created a build script to facilitate the above.
> See http://developer.edina.ac.uk/projects/jorumdspace/wiki/Build_Framework
> The build script used in the Jorum project might be a useful AddOn to DSpace.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
