On 1 September 2011 22:11, Mark H. Wood <mw...@iupui.edu> wrote:
> Hmmm, no, if I understand that one, they are quite different: I want
> to build add-ons *outside of the DSpace source tree*, not scoop them
> in and rebuild the whole works. This requires planning when designing
> the bits that are added onto: what must be exposed to make it
> feasible to build a future add-on solely against the DSpace binary
> artifacts?
>
>
Which you can mostly do.
There is a fairly common misconception about the tools we use, and our
project setup, And imho, something that has been compounded by certain
choices that we've only very recently reversed. I think before we start
considering other technologies to introduce, we all really need to
understand what it is that we have now.
To quote the Maven page: "Apache Maven is a software project management and
comprehension tool". It is NOT a 'make' tool, although it does have plugins
that allow code to be built as part of managing a project.
This is a really, really, important distinction to understand. Because in
Maven, you are not defining a build, you are defining a project. A project
does not necessarily have anything that it builds - it could just be
producing a report, or copying/filtering some files, etc.
[This is where the dspace assembly has conflated the issue. In a 'binary'
release, the dspace assembly project simply populates a directory with some
scripts, configuration and the dependencies defined in the project. In
effect, it creates an installer for DSpace, based on the project definition.
With the 'source' release, the same project would detect and include the
dspace source projects, and build those artifacts as part of the same
'reactor'. But really, the point of that project was always to package the
installer, not to build all the source. For 1.8.0, this has now changed, and
executing Maven within the assembly project will only package the installer
from the normal dependency resolution. If you need to build the dependencies
as well as part of that same 'reactor', then you will need to run Maven
against a different project].
It's also important to understand how, or rather where, Maven resolves
dependencies that are declared in your project from:
a) The 'reactor' (the artifacts produced by the modules of the project being
executed)
b) The local repository (Maven establishes a repository on your filesystem,
largely used to cache artifacts and project descriptions retrieved from
remote repositories).
c) Remote repositories (Maven Central, Sonatype Snapshot repository, other
repositories that you define)
So, if I want to write some add-on code for DSpace, then I create a
stand-alone project, and declare a dependency on a particular version of
dspace-api. Although dspace-api is not being built when I build that add-on
code (there are no other modules in the reactor), it will use the
'dspace-api' artifact that is in my local Maven repository and build against
that. If there isn't a dspace-api in the local repository, then it will
retrieve it from a remote repository [and cache it].
Even if I have made my own modifications to the actual dspace-api which I
need to have access to when I build my add on, I still don't need to build
that dspace-api at the same time. I can do a 'mvn install' on my custom
version of dspace-api to build the artifact and place it in my local Maven
repository. Then, when I go to the add on, when building Maven will resolve
the dspace-api dependency to the custom artifact that I have installed in my
local repository (assuming that the groupId, artifactId and version agree in
both the dspace-api project, and my dependency).
With my add-on, I do the same. I run a 'mvn install'. It's been built
entirely separately of DSpace, but I now put the resulting artifact into my
local Maven repository. Going back to the DSpace [assembly] project, I
change the pom.xml to reference the artifact as a dependency. Running 'mvn
package' will prepare the installer directory, and if you look in the 'lib'
directory, it now includes my add-on code - it's not been built as part of
the packaging, just retrieved from the Maven local repository.
[Note that currently, you would probably also / rather need to edit
modules/pom.xml to add the dependency. By doing that, then your add on
artifact will be placed inside the 'WEB-INF/lib' directory of all the web
applications in the installer directory].
So now, you've got an add-on module that was built entirely 'outside' of
DSpace, and has been placed into the relevant area(s) within your DSpace
installer / installation without being built as part of the DSpace
build/assembly process either.
If you were creating an additional web application - e.g. some new web
services - then you would want to create a WAR artifact, and install that to
your local repository. Ideally, you would make it 'skinny' - that is, have
Maven exclude the dependencies from the WEB-INF/lib inside the WAR artifact.
You would then need to create an overlay project in 'modules' (just like
jspui, xmlui, etc.), and include it as a module in modules/pom.xml. When
assembling the installer directory, it will unpack the WAR from your local
repository, and insert any dependencies that have been defined - e.g. the
same dspace-api that is being used in the other applications. If a change to
the dependencies means that you need a different web.xml (for example), then
you can override any files coming from the add-on WAR by creating them in
the overlay project.
So not only can you create add-on code outside of the DSpace source tree,
you can create add-on [web] applications outside of the DSpace source tree -
and yet still have them use the actual DSpace code that you are using in
your installation.
What we have with the DSpace assembly (binary) project is a modular
definition to package an installer. We can inject add-on code by adding
dependency definitions, and applications by adding an [almost empty] module.
Those add-ons don't need to be built as part of the DSpace source tree, they
just need to be available in a remote repository, or installed into the
local Maven repository.
[You don't even need to be able to build the artifact to install it to a
local repository - you can simply use 'mvn install:install-file' with the
pre-built artifact, and possibly a pom.xml to describe any dependencies it
may have].
It's important to realise just how much power and flexibility there is with
the Maven setup we have, when you understand what project definitions
represent and how they are used.
G
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
