Hi, Chris -- I was just talking to one of my coworkers about the issue of Fedora and backwards-compatibility with older versions, and then I opened my email and read your post.
In general, I'd say that as Fedora moves forward, and the old architecture gets replaced with newer, more streamlined pieces, this problem is only going to get worse, not better. At some point I think we need to bite the bullet and accept that certain legacy APIs will no longer be supported in future versions. The sooner that decision is taken, the easier it will be in the long run, I believe, as developers will not need to spend so much time making sure their new functions work with older code, and plugin maintainers will not need to refactor so much of their code to conform to new APIs when they do get around to making the switch. I personally would much prefer you spent your time working on the new Spring framework, and as a module developer out in the world, I'd be willing to rewrite my pluggable modules to work with the new system so that the Fedora committers can devote their energies to bug fixes and new features. I haven't looked at the roadmap in a while, so I don't know what the targets are for Fedora 4. But a major release seems like a good place to cut bait. -- Scott Steve Bayliss wrote: > Hi Chris > > It sounds like there's probably not a clean way (at least without a > substantial amount of work) to resolve this, and that ultimately third-party > plugins will need to be updated to be compatible with this and future > releases. An inevitable consequence of the package renaming that we perhaps > didn't foresee at this level of detail at the time. > > So long as we make it clear in the release notes that this is the case > people will be aware and can do the necessary work to update their plugins > for this (and future releases). > > Steve > >> -----Original Message----- >> From: Chris Wilper [mailto:[email protected]] >> Sent: 16 August 2010 08:00 >> To: fcrepo-dev >> Subject: [fcrepo-dev] Legacy llstore plugin difficulty >> >> >> Hi all, >> >> One of my tasks for the 3.4 release, which I'd hoped to complete last >> week, was a "legacy llstore adapter". Since package names have >> changed since 3.3 (from fedora.server to org.fcrepo.server), and the >> LLStore interface itself has changed a bit, the goal of this work was >> to allow legacy plugins written against the old interface >> (non-Akubra-based) to work with 3.4 without requiring code changes to >> them. >> >> It didn't work out so well :( >> >> My goal was to put together an adapter module that spoke the new >> interface, but wrapped instances conforming to the old interface. >> Originally I thought I could just use the 3.3 jars that included the >> old lowlevel package classes. I started going down this road last >> week, and quickly discovered that in order for the adapter to work, it >> would have to depend on a lot more than the legacy lowlevel classes. >> But I held out hope, thinking I could put together a huge jar with all >> the dependent classes and libraries. This turned out more challenging >> than I expected; I still felt it was doable...just ugly. >> >> But that wasn't the big problem. No, the main problem I ran into, and >> something that looks insurmountable at this stage, is the old modules' >> dependency on a working Server instance to be provided to their >> constructors. In order to give them what they expect without >> requiring their code to change, I'd have to provide a >> fedora.server.Server instance that wraps the org.fcrepo.server.Server >> instance that is available. Worse, they may actually want to use that >> Server instance...and call getModule("old-module-interface-name"). I >> can't see a way around that maze of twisty passages... >> >> Unfortunately, this means old versions of third-party llstore plugins >> that are not Akubra-based aren't going to work with this release. >> Right now, trunk has two options: >> >> akubra-fs (the default option, this is the akubra impl that goes >> against a plain old filesystem) >> legacy-fs (the legacy, default filesystem-based llstore >> implementation, non-Akubra-based) >> >> Thoughts/ideas? >> >> Thanks, >> Chris >> >> -------------------------------------------------------------- >> ---------------- >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> Fedora-commons-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers >> > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Fedora-commons-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers -- Scott Prater Library, Instructional, and Research Applications (LIRA) Division of Information Technology (DoIT) University of Wisconsin - Madison [email protected] ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
