Felix Meschberger wrote:
Maybe we will discover missing parts over time and can fix those as we
encounter them based on the concrete use case.
As for feeding the repository.xml file on our site: I assume this will
be one of the tasks to be done after a release has been voted. The
release manager should update the repository.xml file.
The easiest would be if we could run a maven plugin during release
creation which creates a repository.xml fragment, which we may simple
paste into the repository.xml file ?
I would prefer that we have some way of also automatically merging the
repo XML fragment too.
Related to this is that I assume we will keep our previous versions
available in our repo, right? If so, I will likely implement a few
changes in the command-line interface for OBR to make it work a little
better when we have lots of different versions of the same bundle.
-> richard
Regards
Felix
Regards,
Clement
-----Original Message-----
From: Richard S. Hall [mailto:[EMAIL PROTECTED] Sent: lundi 7
juillet 2008 04:57
To: dev@felix.apache.org
Subject: Re: OBR
Clement Escoffier wrote:
Hi,
I go on my investigations about an OBR for Felix. I'm working on
writing
descriptions for all released bundles. Indeed, Bindex generate
correctly
package capabilities and requirement in term of package, but is not
very
useful about services. The maven-bundle-plugin allows to customize /
improve
descriptions. So, my goal is to create these descriptions ASAP (and
to try
to discover these descriptions automatically). These descriptions will
greatly help the deployment process as service requirements will be
computed
as well as packages.
Yes, that would be a good idea.
However, this open new issues... we have one artifact
(web console) that requires the HTTP Service that was not released
(correct
me if I'm wrong). So, the generated repository is not
self-contained.
Hmm. We should probably just go ahead and release HTTP Service.
Another small issue is about bundles depending on SCR. The SCR runtime
deployment is not automatic as it's neither a service requirement nor a
package requirement. One solution is to add a specific capability to
SCR,
and to create a requirement targeting this capability in each bundles
requiring the SCR runtime. In fact, if we go further, this issue will
appear
for each extender model (when an extension is deployed before the
host).
Yes, this is an issue. As you say, the only way to resolve it
currently would be to add custom capability/requirements in the SCR
and client bundles. Not much else we can do. At best we can define
something to put in the manifest so that bindex can pick it up and
generate the appropriate dependency.
-> richard
Clement
-----Original Message-----
From: Felix Meschberger [mailto:[EMAIL PROTECTED] Sent: mercredi 2
juillet 2008 10:49
To: dev@felix.apache.org
Subject: Re: OBR
Hi,
Richard S. Hall schrieb:
Sounds good to me...we might quickly find, though, that we need to
revise how OBR reads the repository files, since currently it reads
them every time it starts...perhaps we could cache them for some
[configurable] time so that it doesn't have to go download
repository files all the time...still, I think it is a good idea..
Sounds good. We could that simply by leveraging the Caching headers
of the HTTP protocol, such as Last-Modified and ETag.
Now we just need to finish up with what Clement created to generate
our desired Felix OBR repo...
Yes.
Regards
Felix
-> richard
Felix Meschberger wrote:
Hi all,
After adding OBR referral support (with hop count) as per
FELIX-399 recently I started with prototyping a setup for this
functionality. I have created a "master repository" at [1] which
contains referrals to the Sling repository at [2] and Clement's
prototype at [3].
If you update your felix framework to the latest 1.1.0 SNAPSHOT
build of the bundlerepository project, which I just deployed to
[4], you can add the master repository, for example typing in the
Felix Shell
obr add-url http://people.apache.org/~fmeschbe/repository.xml
Listing the existing repository URLs should then give you all
three mentioned above.
Now, what does this help ? IMHO this proves the idea, that we can
have a single master repository referring to other repositories
without requiring to duplicate entries.
So we could provide such a master repository at our site, e.g.
http://felix.apache.org/repository.xml (this is not there yet ;-)
). And upon requests by projects we might add referrals of a
defined depth (I would say 1 by default, but not too big, either).
WDYT ?
Regards
Felix
[1] http://people.apache.org/~fmeschbe/repository.xml
[1] http://people.apache.org/~fmeschbe/sling-repository.xml
[3] http://oscar-osgi.sourceforge.net/obr-repo/releases.xml
[4]
http://people.apache.org/repo/m2-snapshot-repository/org/apache/felix/org.ap
ache.felix.bundlerepository/1.1.0-SNAPSHOT/org.apache.felix.bundlerepository
-1.1.0-20080627.095454-3.jar