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]
<mailto:[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 <http://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>>
