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. 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. 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. 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. 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. 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. 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? -- Mark H. Wood, Lead System Programmer [email protected] Friends don't let friends publish revisable-form documents.
pgprmWodHyWR2.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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
