You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@archiva.apache.org by de...@gmail.com on 2009/03/01 13:38:39 UTC

Re: OSGi Bundle Repository support for Archiva

Hi guys,
   We also need something like this and we were going to write the consumer
ourselves, but if a official one would be released that will be great. I had
some thoughts on this already, although I do not have much experience with
OSGi (and Felix OBR), but as Maven user I would say that having to maintain
a single XML file for a thousands of bundles (or even more) would not be a
good idea. We noticed already that generating repository XML from existing
bundles with really huge manifests (using BIndex) produces a very large
repository file.
And if we relate this to Maven - in Maven the metadata files are separate
and hierarchically related, if I declare a dependency to lets say Axis2, my
Maven will only download and parse its dependent poms, where in the case of
OSGi, Felix OBR will need to parse the whole XML file. Also, whenever the
repository XML is updated, Felix OBR will need to parse it again.
AFAIK the Felix bundle repository is keeping the parsed resources in memory,
in that case would not be more reasonable to extract the Felix Resolver API
as a standalone one (not requiring to run in an OSGI env) and move it to the
OSGi Consumer to run in Archiva. Then it would not need to parse the XML
each time it gets updated, but can be notified for changes from the
consumer. This would mean that the whole resolution logic will take place on
the Archiva server, the clients (OSGi runtimes) can request that and just
get the resolved bundle with its dependencies. If an appropriate protocol
for bundle resolution is invented, multiple Archiva (or whatever servers)
can work together in the resolution process.
I know this may not sound good enough, the Maven style resolution seems
superior because it all happens on the client side, but it has the advantage
that pom files are linked together in a tree and the resolution logic needs
to parse that tree instead of the whole list of poms on the server.
Regards,
    Detelin