Mark, Great. I had thought to include an initial offer for a time for this call in my original email, but it looks like I forgot. Mark will next tuesday work with your schedule?
Tuesday, May 5th: 10PM (Pacific) / 12noon (Central) / 1PM (Eastern) / 17:00 GMT For anyone else who would like to join, send me your skype username to be added to the call. Scott-- On Apr 30, 2009, at 11:15 AM, Mark Diggory wrote: > 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 <mw...@iupui.edu> 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 > dspace-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel ------------------------------------------------------------------------------ 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-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
