[
https://jira.duraspace.org/browse/DS-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22138#comment-22138
]
Mark Diggory commented on DS-881:
---------------------------------
So we have a few new caveats/options here.
1.) We can support the following in Maven 3.0
in dspace/pom.xml
<profile>
<id>dspace-api</id>
<activation>
<file>
<exists>${basedir}/../dspace-api/pom.xml</exists>
</file>
</activation>
<modules>
<module>../dspace-api</module>
</modules>
</profile>
We would not be able to use this with Maven 2.2.1 and likewise, while all the
modules are activated based on this criteria, we can no longer manually disable
them in Intellij IDEA (we can however use !profile to disable them from the
commandline maven client and if we create IDEA "build configurations" for our
maven builds, we can use !profile there successfully in both IDEA combined with
Maven 2.2.1 and 3.0)
2.) If we use activeByDefault, we can then disable them again in both 2.2.1 and
3.0
<profile>
<id>dspace-api</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<modules>
<module>../dspace-api</module>
</modules>
</profile>
However this defeats the purpose of putting the profiles into dspace/pom.xml in
the original manner we did, the goal of such was to allow one to put the source
modules into place that they needed (checkout from svn or otherwise) without
altering the pom directly, allowing for both release and src-release
distributions to use the same pom regardless. (likewise one could maintain
their addons in separate svn trees from the dspace project and add them via a
custom local dspace-parent pom of their own)
3.) If we move the profiles into dspace-parent pom.xml and leave it out of the
release zip, then it will resolve from the maven repository appropriately. Then
we can use the same dspace/pom.xml in both releases, the result of the non-src
release would be to get all from the maven repo as usual. Caveat is that those
using the source release will need to be informed to build from [dspace-src]
and not [dspace-src]/dspace any longer.
polling a few folks on (3) they've said they think this would be cleaner and
more intuitive even if it requires changing some of the build documentation
> DSpace doesn't build properly with Maven 3
> ------------------------------------------
>
> Key: DS-881
> URL: https://jira.duraspace.org/browse/DS-881
> Project: DSpace
> Issue Type: Bug
> Components: DSpace API
> Affects Versions: 1.7.0, 1.7.1
> Reporter: Tim Donohue
> Assignee: Mark Diggory
> Fix For: 1.8.0
>
>
> DSpace currently has issues building with Maven 3.x
> This has been noted in the DSpace Documentation at:
> https://wiki.duraspace.org/display/DSDOC/Installation#Installation-ApacheMaven2.2.x%28Javabuildtool%29
> However, during the Developers Meeting on April 20, 2011, the DSpace
> Developers decided that we should resolve these Maven 3 issues for the DSpace
> 1.8.0 release.
> More information about Maven 3 issues is available in this email thread from
> dspace-devel:
> http://www.mail-archive.com/[email protected]/msg05222.html
> A similar thread about Maven 3 issues also appeared on dspace-tech:
> http://www.mail-archive.com/[email protected]/msg13610.html
--
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
------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
