On 2 September 2011 14:33, Mark H. Wood <mw...@iupui.edu> wrote:
> > 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.
If DSpace doesn't care about whether the add-on exists, then it can't use
the add-on. You can't register a [synchronous] listener, without DSpace
caring that it can locate the code you are referring to.
If we had a distributed messaging queue, then yes, DSpace could fire an
event into the ether, and not care if anything responds to it. But that's a
different (and specific) level of discussion.
Adopting something like OSGi would not stop DSpace caring about whether the
add-on exists, making it a runtime install at best just moves where / when
it starts caring.
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?
>
Sorry, but I have to reiterate this point. Not withstanding the issue of
project/module activations I pointed out before, when you run Maven in the
dspace assembly project, you are NOT rebuilding DSpace.You are packaging an
installer to update your repository installation.
And why should you do it? Well, not withstanding that your DSpace project
should be under version control, and that you should have created it using
verndor drops - meaning that you have management of the changes occurring to
your installation, and the vendor drop mechanism aids merging your local
configuration and customizations with upgrades of DSpace.
There is a very good reason why you should do it this way - look at what you
are specifying in the pom.xml for your new dependency:
<dependency>
<groupId>my.edu</groupId>
<aritfactId>add-on</artifactId>
<version>1.0</version>
</dependency>
Now, your add-on may well have other dependencies of it's own, which aren't
necessarily part of DSpace normally. You don't have to specify those
manually - when you install your add-on into the Maven repository, you
install a pom.xml that describes its dependencies. Maven can then include
all those other dependencies transitively.
What's more, you may have dependencies on specific revisions, that differ
from DSpace's default. Maven will evaluate all of your dependencies as a
whole, choosing the most appropriate version of each artifact, ensuring that
there is only one version of the artifact in the resulting system. It will
also tell you if there is an unresolvable conflict in the dependencies.
All of which is quite preferable to ensuring that you don't make mistake in
all the various things that you are meant to be copying and deleting
manually.
>
> 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.
But the system still needs to be able to find the plugin that you are
referencing. And it needs to be able to find any dependencies that the
plugin may have. And it needs the right versions - and only the right
versions - of those dependencies.
And, you should still have change management procedures for those changes.
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.
>
It makes 0 changes to the code, but then when you are packaging the DSpace
install script via the assembly project, you are NOT building or changing
that code.
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
I can see why in a running system, there is a desire to simplify some
operations and lower some barriers. But it can also be a rather
short-sighted view. You also need to look at what the implications are when
you need to debug a problem, or upgrade to a new version of DSpace.
In the long run, you may be incurring more costs than you are saving by
bypassing change control / packaging procedures.
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
