These are answered in my presentation... Scott, I will welcome a conference call or meeting to discuss how we spearhead how to appropriately package addon's to DSpace. Let's try to plan something in the next week if possible. I will also consider if some of this can fit into my presentation as an example.
On Thu, Apr 30, 2009 at 7:07 AM, Mark H. Wood <[email protected]> wrote: > On Wed, Apr 29, 2009 at 03:47:12PM -0500, Scott Phillips wrote: >> You make some good points here about the patch. I think it may be >> possible to find some time to refactor the patch in the ways you are >> suggesting. The problem is similar to a chicken and an egg, which came >> first. There are challenges to developing addons like you suggest with >> the current state of DSpace 1.5.x. 1) Where does their code live, 2) >> how is an addon installed without modifying POM files, 3) how can >> addons interject into the administrative interface?, 4) and what do we >> do about the JSPUI? > > I'd like to expand (and expound) a bit. > > 1) "Where does [addon] code live?" > > The modular build system works great if you are adding a new > webapp. I don't see how it helps if what you are adding is not a > webapp, and apparently I am not the only one. There's probably a > way to organize a project that augments one or more of the existing > webapps so that it isn't intermingled with said apps' code, but we > need to work it out and provide an example. Actually, it works fine for both jars and webapps, we use dspace/modules" for both when the customizations are specific to a DSpace instance and we place them next to the other dspace-xxx projects when we will be reusing them across instances. > > One also should consider whether a given addon might not be better > laid out as an entirely separate collection of artifacts with > "provided"-type dependencies on DSpace artifacts. This might have > to be combined with some patches to DSpace to permit the addon to > plug in at the right places, but any such plugin points should be > designed to be generally useful so that such patches will be few > and will increase modularity. I tried to shy away from doing this, specifically because I did not want to identify dspace addons as anything more specific than maven jar/war projects (meaning any maven artifact could be added to dspace and treated as an add-on regardless of its name/classification) For instance, I recently picked up solr and started treating it as an addon in the dspace build process and I can see more than one way of integrating such a webapp/service into DSpace (either as a seperate war project or as a Cocoon Block added. > An example of the separate-artifacts approach is Larry Stone's > external PDF extractor package. It can be integrated with the > DSpace source, but the nature of the code allows it to be built as > a separate JAR, dropped into an existing instance, and configured > in. In the case that there is no intention to have it part of dspace-api (and theres a lot of stuff in dspace-api that really should be separate) then it should be a separate maven project that one just adds as a dependency in dspace/pom.xml or dspace/modules/xxx/pom.xml > > 2) "How is an addon installed without modifying POM files?" > > Well, if it introduces no new dependencies into existing modules, > then you don't need to modify existing POMs. But that's a pretty > strong condition, because even adding a new module introduces a new > dependency to dspace/modules/. It seems that we need some way to > tell Maven to "just build any modules you find in this location, > whatever they may be named". Given that, we wouldn't have to > modify dspace/modules/pom.xml just because we added a new module > within dspace/modules/, which makes the above constraint a lot less > constraining. Modifying pom files "is the way to manage your build configuration". I agree we can do things to improve having developers working with overly complex pom xml files. For instance, we may begin to use "pom dependencies" (a feature of maven 2.0.9 or greater) to provide a pom strictly for managing your addons to be included into the dspace/lib, currently the modules/xxx/pom.xml are simple enough that this would just be added complexity there. > > 3) "How can addons interject into the administrative interface?" > > Well, in DSpace 2.0 we'll have Spring underneath it all (as I > understand it), and may be able to do dependency-injection tricks > to cram new administrative UI into the existing structure. But how > do we accomplish this in 1.x? We need a way to configure > additional choices into the admin. pages. And if we build that > now, we may not have to work DI magic later. DSpace 1.5.2/1.6.x has Spring in the XMLUI and the Cocoon 2.2 Blocks allow you direct usage of this functionality. So, all this is there, and available for use in managing the deployment of new services. Cocoon 2.2 Blocks eliminate the need to alter the xmlui/WEB-INF/sitemap.xmap to add new paths for services that are not aspects (i.e. feeds, servlets, rest services) and finish solving the modularity problem of DSpace. > Come to think of it, maybe we ought to look at decomposing the > existing admin. UI into features which *all* worm their way into a > blank framework DSpace 2.0 XMLUI starts to do this, we can talk much more about what features should be separate projects into and start doing it in 1.6 as well. dspace-xmlui-feed, dspace-xmlui-sitemap, dspace-xmlui-bitstream, dspace-xmlui-admin-xxx. > 4) "And what do we do about the JSPUI?" > > 'tis a puzzlement. There are folk who know a lot more about JSP > than I do, but I can't see any easy way forward to the modular, > decentralized future of DSpace for JSPUI. It's just a page > template language with lots of hair. Any ideas? There was some talk about adding support for this in JSPUI in the IRC chat yesterday, I can't find my log for it again however. TBH, I'm not interested in working on JSPUI beyond anything but maintenance. I feel the community can't afford having two separate UI's right now, but thats just my personal opinion. Mark -- Mark R. Diggory http://purl.org/net/mdiggory/homepage - Bio ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
