[
https://jira.duraspace.org/browse/DS-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21197#action_21197
]
Tim Donohue commented on DS-791:
--------------------------------
Any objections to committing this for 1.8.0?
Essentially, the attached patch just "wraps" each <module> definitions into
separate <profile> definitions in the /dspace/modules/pom.xml
However, by this simple change, individual developers can then better control
which DSpace modules are actually being built each time they call 'mvn
package'.
As an example, calling 'mvn package -P !dspace-lni,!dspace-oai' will build
everything *except* for LNI & OAI. By default, 'mvn package' would still build
all modules.
I'll leave this open for any final comments/suggestions until at least the end
of this week. After that point, I'll assume the +2 votes via JIRA are an
indication that this can be committed to Trunk for 1.8.0.
> Add ability to disable the building of particular DSpace modules/interfaces
> from source code
> --------------------------------------------------------------------------------------------
>
> Key: DS-791
> URL: https://jira.duraspace.org/browse/DS-791
> Project: DSpace
> Issue Type: Improvement
> Components: DSpace API
> Affects Versions: 1.7.0
> Reporter: Tim Donohue
> Assignee: Tim Donohue
> Fix For: 1.8.0
>
> Attachments: dspace-modules-pom.patch
>
>
> For developers (and anyone who frequently rebuilds DSpace), it would be nice
> to have the ability to *disable* the building of DSpace modules which you are
> not currently using.
> For example, an institution may only be actively using the XMLUI, Discovery
> and SWORD. But, when they run 'mvn package', it will *always* rebuild all
> modules/interfaces (even those which they don't really care about).
> A simple way to allow institutions to disable the building of specific
> modules is to provide consistent "module profiles" across all our POMs, which
> can then be disabled from the command-line using Maven's "-P" option along
> with the "!" option (requires Maven 2.0.10 or above, see
> http://maven.apache.org/guides/introduction/introduction-to-profiles.html).
> For example, if you have profiles with IDs of "dspace-lni" and "dspace-oai",
> you can disable them by calling Maven as follows:
> mvn package -P !dspace-lni,!dspace-oai
> We currently already provide various interface-based profiles in the
> [dspace-src]/dspace/pom.xml. However, the
> [dspace-src]/dspace/modules/pom.xml *always* defaults to building/installing
> all modules.
> Simply put, with a small tweak to [dspace-src]/dspace/modules/pom.xml to add
> matching profiles (with the same IDs as in [dspace-src]/dspace/pom.xml), we
> can make things a lot easier on developers. See the attached patch for
> more details of the changes. This patch was built against current Trunk
> (r5997).
> With the patch applied, here's what build options are available:
> * By default, all DSpace modules are still built when running 'mvn package'
> on the full source code
> * If a developer chooses, he/she can disable the building of specific DSpace
> modules using the Maven "-P" option. He/She just needs to provide a listing
> of the modules to disable (see example above). The full list of modules is
> currently:
> * dspace-xmlui
> * dspace-lni
> * dspace-oai
> * dspace-jspui
> * dspace-sword
> * dspace-solr
> Please note that disabling the building of a webapp module also means it is
> not built/copied into [dspace-src]/dspace/target/dspace-[version]/webapps/
> (which means it also would not be installed via 'ant update').
> Suggestions & comments are welcome. If others agree that this is a useful
> tweak to our current build process, I will commit it to Trunk for the 1.8.0
> release.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.duraspace.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
