[
https://jira.duraspace.org/browse/DS-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Donohue updated DS-791:
---------------------------
Description:
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.
was:
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.1 or above). 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
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.
> 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
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
