First, just want to say, this is a very interesting discussion. I'm really enjoying reading this! My own brainstorms inline below...
On 9/2/2011 8:33 AM, Mark H. Wood 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. 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? MarkW, I really like where you are going here! It sounds like one extra area that may be of help here would be moving configuration to the Admin UI. That might help get rid of those "bits which are not Java" (by letting you drop in your Java plugin, and then configure it from the Admin UI). I can think of a few examples that parallel this concept. Web Browsers Plugins. Think about how Firefox & Chrome handle their plugins/extensions. * Essentially the extension/plugin is downloaded or copied to a specific directory. The browser then notices it and installs it. * With Chrome, the extension is actually loaded dynamically (no restart needed). But, with Firefox, you still need to restart your browser to complete the installation. * Even after installation, some extensions/plugins need configuration. But, luckily both browsers give you an easy way to tweak configuration from the UI, rather than needing to dig around to find a config file on your filesystem. Relating DSpace plugins back to how browsers work, it seems like we could get 90% of the way there if we had: (1) a place where we could "drop in" a JAR plugin (or perhaps pull down via Maven). DSpace could pick them up & auto install them (including auto installing a default configuration file for the plugin). (2) a way to configure the plugin's configuration file from the Admin UI, so that you didn't need to search for it in your DSpace folder If we want DSpace to work more like Chrome (dynamically install plugins without a restart), we really should be looking more towards existing frameworks like OSGi (as MarkD has rightly pointed out). If we want DSpace to work more like Firefox (install plugin, but require a restart to do so), we may be able to implement that without OSGi (but, we still would want to avoid reinventing wheels which already exist elsewhere). I'm not saying either is "better", I'm just noting some options here. In the repository world, EPrints has already gone a similar route with both their Bazaar & Admin UI. Although many of their configuration files are still text files on the file system, you can edit most/many from their Admin UI (via a simple UI for manipulating & saving text files). Those who have seen the EPrints Bazaar feature may also know they can also install plugins right from the UI (for EPrints these are dynamically loaded). Maybe this is something that could inspire us towards a similar direction? We do seem to be "stuck" on where to go next in terms of repository plugins/addons, even though this is a feature we all want. I think this is an area where we really need to work together as a community towards a common solution (prototypes, ideas, brainstorms are necessary & welcome!). DuraSpace (or any other single institution) shouldn't force DSpace in a particular direction. The decision really needs to come from all of us. DSpace is community-built software, and this is an area where the developer community needs to help us decide our path forward. So, I'm looking forward to this discussion/brainstorm (and hopefully seeing some prototypes/ideas come out of it soon). :) - Tim ------------------------------------------------------------------------------ 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
