Great to hear this Graham,
Actually, my goal in the Async release rearchitecture prototyping is I'm
trying to move us away from having a top level pom in the build directory
this will free the project to release different dspace-xxx modules
under different version numbers. My goal is that all assembly would be run
from the dspace directory, we actually take this approach now with many of
our clients and it works favorably. As well, the dspace-pom residing in a
separate location and released to the maven repository is used to convey the
dspace communities artifact deployment requirements to the sonatype oss
staging repo, our license header requirements and some details on the
version of Java that is preferred. But it excludes most of the stuff in the
dspace-parent as "too restrictive", using it forces many of our third
party dependencies to always be incorrect, and more often than not we end up
overriding these to assure our addons work properly.
http://scm.dspace.org/svn/repo/modules/dspace-pom/tags/dspace-pom-8/pom.xml
You may as then, how would we build the entire project for distribution if
there is no longer a "dspace-parent" pom. We would do so by moving most of
that code into the dspace project and running the assembly there.
So my request is that we place the activations into the dspace/pom.xml and
remove those from the dspace-parent.pom. In fact, if you are rummaging
around in here and doing re-architecting, I would totally welcome some
assistance in testing out the scenario further.
An alternative would be to place the modules in the dspace-parent under
profiles that are mututally exclusive in dspace-parent and dspace. Then set
it up so that when the build is executed from the parent a different
property is set than when it is executed from the dspace/pom.xml... But, IMO
this introduces complexity, my goal is to simplify the build further.
Mark
On Fri, Jan 14, 2011 at 2:38 PM, Graham Triggs <grahamtri...@gmail.com>wrote:
>
> 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
>
>
--
Mark R. Diggory
@mire - www.atmire.com
2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010
Technologielaan 9 - 3001 Heverlee - Belgium
------------------------------------------------------------------------------
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
