Premek, Sorry for the delayed response =)
Yes, that will be necessary. Not only to support this break out, but also for a requirement I have to support more than one OBR instance on the provider (one of them actually being an archiva instance once I get an OBR interface into archiva as Brett and I discussed at ApacheCon). I'll submit an issue to formally solicit opinions from the project members =). With hope, and a bit of time, I'll have my provisioning server interfacing with Archiva as the OBR by the end of the weekend (fingers crossed =). Thanks! Steve On Tue, Nov 9, 2010 at 9:10 AM, Premek Brada <[email protected]> wrote: > On 5.11.2010 12:20, Steven Siebert wrote: > > Sounds right. Was thinking about moving at the interfaces for the OBR > Store and Metadata into its own bundle(s) to keep the API and existing > implementation separate. This may be overkill, though =) > > > Actually, things are not as clean. Looking at the OBR Metadata activator, > my student noted that it creates the "default" implementation of the > file-based indexer as a service, which then (inadvertedly) gets inserted > into any managed service depending on the MetadataGenerator. So creating > and providing a different indexer will be a bit difficult. > > That could be a reason to splitting the two bundles into API and > implementation bundles. How would such a split fit within the overall ACE > design? > > Premek > > > > > I see the export now...Netbeans 6.9 apparently doesn't understand bnd! > (seriously?!?!) Not good....I'll need to check if there is already a plugin > or look at quickly hack one together. At the mercy of tooling again! =) > > S > > On Fri, Nov 5, 2010 at 6:54 AM, Premek Brada <[email protected]> wrote: > >> Hi Steven, >> >> >> On 5.11.2010 10:11, Steven Siebert wrote: >> >> Hi Premek, >> >> After reading Marcel's response, moving that code out into its own >> bundle was pretty much my first thought. +1 =) >> >> >> Nice to hear, thanks :) >> >> >> After diving into the code last night, I noticed the OBR stuff is >> encapsulated quite well in the the modules OBR Metadata (where the indexer >> is), OBR Store, and OBR Servlet. If we would be able to pull this code out >> and export the API for the store backend, I can create an adapter to deal >> with the pluggable nature of Apache Jackrabbits FileStore. Once we do >> this...I think we'll be in business. >> >> >> The OBR storage module contains the OBR API (BundleStore iface) + its >> file-based implementation, and the OBR metadata is able to generate OBR >> repository index file for a given directory. It actually exposes the indexer >> as a service. Is the BundleStore what you meant by the "store backend API"? >> >> So, if I understand it correctly, providing for another store would mean >> creating its implementation (the adapter) of the BundleStore + another >> indexer operating on top of that implementation, which the BundleStore impl >> uses to generate the index file. >> >> Actually, looking at it, it seems there should be no need to pull any code >> out. We could just have two separate bundles with new code and dependencies >> on the OBR Storage and OBR Metadata bundles, to access the interfaces they >> define. >> >> Not sure I haven't missed something. Does this look ok? >> >> Premek >> >> >> >> >> Thoughts? >> >> Thanks! >> >> Steve >> >> >> On Fri, Nov 5, 2010 at 4:07 AM, Premek Brada <[email protected]> wrote: >> >>> Hello all, >>> >>> >>> On 4.11.2010 22:18, Marcel Offermans wrote: >>> >>>> Hello Steve, >>>> >>>> On 4 Nov 2010, at 17:08 , Steven Siebert wrote: >>>> >>>> In previous discussions with Brett Porter (CC'ed) he I and I discussed >>>>> working together on exposing the archiva jackrabbit-based maven repo >>>>> through >>>>> an OBR interface. In what we discussed this afternoon, I think there >>>>> could >>>>> be an opportunity to cross-pollinate across the projects, just based on >>>>> the >>>>> commonality (without looking at the code yet). I just spoke again to >>>>> Brett, >>>>> and before I forget, I figured I would send an email out on the >>>>> subject. =) >>>>> >>>> That definitely sounds interesting. The "OBR" that is included in ACE >>>> consists of a couple of bundles. By default we include these as part of the >>>> ACE server. They can also be deployed in a stand-alone OSGi framework. >>>> Option number three is not using them at all but instead hooking up to an >>>> external repository that exposes the same OBR metadata. >>>> >>>> ACE actually contains code that scans a directory and (re)generates OBR >>>> metadata based on its contents. Maybe that code could be used to do the >>>> same >>>> for the archiva jackrabbit-based maven repository? >>>> >>> >>> Coincidentally, I had a discussion yesterday with a student of mine who >>> is working on a diploma project using ACE OBR, which for our purposes would >>> need the indexer core (that re-generates OBR metadata) to be extended. We >>> thus thought of factoring the indexer code out into a separate >>> bundle/service. >>> >>> Would such a refactoring help to use OBR interface with the archiva repo? >>> If yes, we could offer some help. >>> >>> Premek >>> >>> >>> >>> -- >>> Premek Brada (Ing et MSc, PhD) >>> Lecturer in Software enginering, Webmaster >>> Department of Computer Science and Engineering >>> University of West Bohemia, Pilsen, CZ >>> << brada at kiv.zcu.cz | >>> www.kiv.zcu.cz/~brada/<http://www.kiv.zcu.cz/%7Ebrada/>| +420-377-63-2435>> >>> >>> >> >> >> -- >> Premek Brada (Ing et MSc, PhD) >> Lecturer in Software enginering, Webmaster >> Department of Computer Science and Engineering >> University of West Bohemia, Pilsen, CZ >> << brada at kiv.zcu.cz | www.kiv.zcu.cz/~brada/ >> <http://www.kiv.zcu.cz/%7Ebrada/> | +420-377-63-2435 >> >> >> >> > > > -- > Premek Brada (Ing et MSc, PhD) > Lecturer in Software enginering, Webmaster > Department of Computer Science and Engineering > University of West Bohemia, Pilsen, CZ > << brada at kiv.zcu.cz | www.kiv.zcu.cz/~brada/ | +420-377-63-2435 >> > > >
