On Fri, Sep 02, 2011 at 01:04:40AM +0100, Graham Triggs wrote: > 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).
All clear so far, and that's what I've been doing for the task that prompted my tangent thread. > 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. So far, so good. > 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. Exactly. Why do we do this? DSpace doesn't care whether my add-on exists or not -- that's part of what "add-on" means. Why should DSpace have to be rebuilt? it hasn't changed. What does this buy us, and why is it worth the not inconsiderable expense? After the rebuild, DSpace still doesn't know that my add-on is there; I have to configure it in anyway. Isn't the rebuild just 99% wasted motion, to get Maven and Ant to do a simple 'cp' for me? [thinks for a while] I may be using the wrong terms to denote my issue. One can divide add-ons into classes by how intrusive they are, and what I'm thinking of is a plugin add-on. A plugin implements an interface defined by DSpace. DSpace doesn't know or care about the existence of a plugin until it's told to by configuration, and even then it still knows nothing about implementations; they're all just instances of some interface, and out of the box it knows everything it will ever know or need to know about that interface. The plugin manager instantiates the classes it was told to, and the plugin-point code just uses the methods defined by the interface. A plugin makes 0 changes to the code it plugs into. The problem I'm looking at is that, while Java is very good at facilitating that sort of thing, there are bits of DSpace which are not Java and, to make a plugin that plugs in the way a table lamp plugs in, we need to design the non-Java bits for similar easy extensibility. The non-Java bits are resources that are just copied straight through, so the build/assemble/install procedure isn't going to help us. I don't see how e.g. OSGi is going to help us: does it somehow know that this fragment of sitemap here must be textually inserted (at the right place!) into that bit over there? (I suppose that I got sloppy in my terminology because I feel that, if we've done our job well, every add-on will be a plugin.) -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart.
pgpRFm7xXWS3X.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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
