I've just been playing with Maven 3 to build the current trunk. Aside from
one small complaint about a missing relativePath (which I've corrected,
tested in both Maven 2 & 3, and committed), and warnings about missing
plugin versions (which I've not corrected), there are some interesting
issues around duplicate projects.
In the current configuration, all the artefact modules (dspace-api,
dspace-jspui, etc.) are declared in the top level pom.xml, along with the
assembly project, dspace.
The assembly project also has activations for the artefact modules
(dspace-api, etc.) if they appear in the file system - which obviously they
do in a standard checkout.
If [with Maven 3] I execute a maven goal from the top level project / pom,
then it gives an error that the artefact projects have been declared more
than once. Executing the goal from the assembly subproject correctly parses
all the artefacts, as well as the assembly project.
Removing the declaration of the modules (except the assembly project,
dspace) from the default profile of the top level pom, then executing goals
in Maven 3 will work correctly when run at the top level - including the
artefacts, as it picks them up from the activations in the dspace assembly.
However, Maven 2 doesn't pick up the artefacts in the same situation, and so
doesn't build correctly. OK, so that's not going to work in the general
case.
If I go the other way round, and remove the activations for the artefact
projects from the pom of the dspace assembly project, then both Maven 2 and
Maven 3 execute correctly when run from the top level. Of course, this means
that the artefacts won't automatically be included if you go execute a goal
from the assembly project.
Personally, I don't have a problem with this - if you want/need to build
artefacts and the assembly as one, then you run it from the top level. And
there are certainly times when it useful to repackage the assembly /
overlays without rebuilding the other artefacts.
Ultimately, it would be good to have DSpace usable with either Maven 2 or 3,
so I would recommend removing the profile activations that include the
artefact modules from the dspace assembly project (which is the only case
that works for both).
Does anyone have any comments?
G
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
