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
