You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall" <he...@ungoverned.org> on 2008/07/01 20:37:12 UTC
Re: OBR
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..
Now we just need to finish up with what Clement created to generate our
desired Felix OBR repo...
-> 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.apache.felix.bundlerepository/1.1.0-SNAPSHOT/org.apache.felix.bundlerepository-1.1.0-20080627.095454-3.jar
>
Re: OBR
Posted by Guillaume Sauthier <Gu...@objectweb.org>.
Clement Escoffier a écrit :
> Hi,
>
> Providing "automatic" OBR bundle descriptions is on the iPOJO roadmap (and
> is currently under development). It should describe service requirements /
> capabilities as well as provided and required handlers. The complex stuff
> comes from the differentiation between factories and instances (only
> instances require and provide services).
>
> Integrating these capacities inside Bindex or BND could be great.
>
Yeah, I like the pluggeable part :)
--G
> Clement
>
> -----Original Message-----
> From: Guillaume Sauthier [mailto:Guillaume.Sauthier@objectweb.org]
> Sent: lundi 7 juillet 2008 11:04
> To: dev@felix.apache.org
> Subject: Re: OBR
>
> Clement Escoffier a écrit :
>
>> 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).
>>
>
> Given the number of component models available with OSGi, I would
> like
> to have automatic discover of the services requirements/capabilities
>
> pluggable.
> I mean, bindex does a great job with packages, but when it comes to
> services, where can it find the data ?
> So It could be great to have a way to extend bindex with a pluggable
>
> "discovery mechanism":
> * one that know to look at the SCR xml files
> * another that knows iPOJO (metadata.xml as well as annotations)
> * support for service binder
> * ...
>
> WDYT ?
>
> --Guillaume
>
> BTW, Maybe the same idea could be applied for bnd ? Bnd knows how to
>
> look inside spring-dm xml files to discover needed imports, why not
> have
> the same for ipojo, scr and so on ?
>
>
>> These descriptions will
>> greatly help the deployment process as service requirements will be
>>
> computed
>
>> as well as packages. 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.
>>
>> 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).
>>
>> Clement
>>
>> -----Original Message-----
>> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
>> 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
>>
>>
>>
>>
>>
>>
>
>
>
RE: OBR
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
Providing "automatic" OBR bundle descriptions is on the iPOJO roadmap (and
is currently under development). It should describe service requirements /
capabilities as well as provided and required handlers. The complex stuff
comes from the differentiation between factories and instances (only
instances require and provide services).
Integrating these capacities inside Bindex or BND could be great.
Clement
-----Original Message-----
From: Guillaume Sauthier [mailto:Guillaume.Sauthier@objectweb.org]
Sent: lundi 7 juillet 2008 11:04
To: dev@felix.apache.org
Subject: Re: OBR
Clement Escoffier a écrit :
> 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).
Given the number of component models available with OSGi, I would
like
to have automatic discover of the services requirements/capabilities
pluggable.
I mean, bindex does a great job with packages, but when it comes to
services, where can it find the data ?
So It could be great to have a way to extend bindex with a pluggable
"discovery mechanism":
* one that know to look at the SCR xml files
* another that knows iPOJO (metadata.xml as well as annotations)
* support for service binder
* ...
WDYT ?
--Guillaume
BTW, Maybe the same idea could be applied for bnd ? Bnd knows how to
look inside spring-dm xml files to discover needed imports, why not
have
the same for ipojo, scr and so on ?
> These descriptions will
> greatly help the deployment process as service requirements will be
computed
> as well as packages. 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.
>
> 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).
>
> Clement
>
> -----Original Message-----
> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
> 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
>
>
>
>
>
Re: OBR
Posted by Guillaume Sauthier <Gu...@objectweb.org>.
Clement Escoffier a écrit :
> 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).
Given the number of component models available with OSGi, I would like
to have automatic discover of the services requirements/capabilities
pluggable.
I mean, bindex does a great job with packages, but when it comes to
services, where can it find the data ?
So It could be great to have a way to extend bindex with a pluggable
"discovery mechanism":
* one that know to look at the SCR xml files
* another that knows iPOJO (metadata.xml as well as annotations)
* support for service binder
* ...
WDYT ?
--Guillaume
BTW, Maybe the same idea could be applied for bnd ? Bnd knows how to
look inside spring-dm xml files to discover needed imports, why not have
the same for ipojo, scr and so on ?
> These descriptions will
> greatly help the deployment process as service requirements will be computed
> as well as packages. 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.
>
> 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).
>
> Clement
>
> -----Original Message-----
> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
> 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
>
>
>
>
>
Re: OBR
Posted by "Richard S. Hall" <he...@ungoverned.org>.
This is good. The report looks very nice.
What we need is to document how to edit and generate the repo file for
new updates. Then I think we should start generating this file for new
bundle releases to our site and making it the default for our OBR repo URL.
-> richard
Clement Escoffier wrote:
> Hi,
>
> I set up an OBR containing some released of Felix bundles (mostly latest
> version). This repository is available on
> http://oscar-osgi.sourceforge.net/obr-releases/releases.xml. The difference
> between the old one and this one is that this repository describes both
> packages capabilities/requirements and services capabilities/requirements.
> Moreover some custom capabilities are added to handle SCR bundles (requiring
> service.component.runtime), and iPOJO bundles requiring ipojo.handlers).
>
> The repository is mostly self-contained as described by
> http://oscar-osgi.sourceforge.net/obr-releases/releases.html. The web
> console bundle has a requirement on an HTTP service (which is not
> available).
>
> Feedbacks are welcome and more particularly on bundle descriptions as my
> tools detecting required and provided services are quiet new and can miss
> some stuff.
>
> Regards,
>
> Clement
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> 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:fmeschbe@gmail.com]
>> 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
>>
>>
>>
>>
>
>
Re: OBR
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Clement Escoffier schrieb:
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> 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.`
Definitely agreeing here.
> Updating the repository file is simple when the obr.xml file describing the
> bundle is created (this file contains provided and required services, but
> can be used to contain any description). To update the repository, the
> following maven command works with the latest maven-bundle-plugin:
>
>
>
> mvn clean install org.apache.felix:maven-bundle-plugin:deploy
> -Dprefix=http://repo1.maven.org/maven2/ -DremoteOBR=releases.xml
> -DaltDeploymentRepository=local::default::file:/Users/clement/Documents/work
> spaces/ipojo-dev/releases
Ah, this is of course a great method, which is a simple command we can
easily document on our release building page. Thanks.
Regards
Felix
RE: OBR
Posted by Clement Escoffier <cl...@gmail.com>.
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: mercredi 23 juillet 2008 17:18
To: dev@felix.apache.org
Subject: Re: OBR
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.`
Updating the repository file is simple when the obr.xml file describing the
bundle is created (this file contains provided and required services, but
can be used to contain any description). To update the repository, the
following maven command works with the latest maven-bundle-plugin:
mvn clean install org.apache.felix:maven-bundle-plugin:deploy
-Dprefix=http://repo1.maven.org/maven2/ -DremoteOBR=releases.xml
-DaltDeploymentRepository=local::default::file:/Users/clement/Documents/work
spaces/ipojo-dev/releases
Just change the deployment repository to use a non-local location. Remark
the prefix indicating the URL prefix to use for the deployed bundles. It
means that a repository can contain bundles from different maven
repositories. So this command update the OBR file and does not deploy the
bundle on a maven repository.
Once the repository is created, I have a simple checker (to improve)
checking the consistency of the generated OBR file. Basically, it checks the
self-consistency of the repository (see the generated HTML file).
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.
The described way just add or update the bundle description (an update
occurs only when the same symbolic-name/version is already present). If a
new version of the bundle is deployed, the description is added. So, we will
get several version of each bundles soon (I think it's already the case as I
deployed an old version of one bundle). I don't know if it's an issue right
now, but we'll be able to move older version to another repository file when
it'll become worthwhile.
Clement
>
> Regards
> Felix
>
>>
>> Regards,
>>
>> Clement
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org] 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:fmeschbe@gmail.com] 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
>>>
>>
>>
Re: OBR
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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:heavy@ungoverned.org] 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:fmeschbe@gmail.com] 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
>>>
>>
>>
Re: OBR
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Clement Escoffier schrieb:
> Hi,
>
> I set up an OBR containing some released of Felix bundles (mostly latest
> version). This repository is available on
> http://oscar-osgi.sourceforge.net/obr-releases/releases.xml. The difference
> between the old one and this one is that this repository describes both
> packages capabilities/requirements and services capabilities/requirements.
> Moreover some custom capabilities are added to handle SCR bundles (requiring
> service.component.runtime), and iPOJO bundles requiring ipojo.handlers).
Cool ! Great work.
>
> Feedbacks are welcome and more particularly on bundle descriptions as my
> tools detecting required and provided services are quiet new and can miss
> some stuff.
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 ?
Regards
Felix
>
> Regards,
>
> Clement
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> 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:fmeschbe@gmail.com]
>> 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
>>
>>
>>
>
>
RE: OBR
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
I set up an OBR containing some released of Felix bundles (mostly latest
version). This repository is available on
http://oscar-osgi.sourceforge.net/obr-releases/releases.xml. The difference
between the old one and this one is that this repository describes both
packages capabilities/requirements and services capabilities/requirements.
Moreover some custom capabilities are added to handle SCR bundles (requiring
service.component.runtime), and iPOJO bundles requiring ipojo.handlers).
The repository is mostly self-contained as described by
http://oscar-osgi.sourceforge.net/obr-releases/releases.html. The web
console bundle has a requirement on an HTTP service (which is not
available).
Feedbacks are welcome and more particularly on bundle descriptions as my
tools detecting required and provided services are quiet new and can miss
some stuff.
Regards,
Clement
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
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:fmeschbe@gmail.com]
> 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
>
>
>
Re: OBR
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Thanks for the update Niclas. Sounds like things are in motion.
Regarding a "thin" HTTP service...I am still looking for a volunteer. It
is one of the contribution ideas on the contributing page:
http://cwiki.apache.org/FELIX/contributing.html
:-)
-> richard
p.s. That reminds me, other community members should add their own
suggestions to the community page so we can build up a good set of ideas
for people looking to contribute.
Niclas Hedhman wrote:
> On Wednesday 23 July 2008 23:15, Richard S. Hall wrote:
>
>> Well, nothing stops us from releasing our HTTP Service too, but there is
>> an issue here with OPS4J as we try to foster more cooperation between
>> the two communities.
>>
>> I think PAX Web is under consideration as a collaboration point, but the
>> first collaboration attempt is around PAX Logging, if I understand
>> correctly. I am not sure where we are in this process right now, but we
>> have definitely started it. Perhaps Niclas has an update. Things can
>> slow down a little in the Summer...
>>
>
> Yes. I just came back from a Looooong trip in Europe. And I need the comfort
> of "home" to deal with community issues.
>
> Status Pax Logging;
>
> 1. The PMC voted Pax Logging in as a Felix project.
>
> 2. I have uploaded the TAR ball in question to Incubator, for IP Clearance.
> The IP Clearance paper work is pending.
>
> 3. Felix PMC voted in two new committers, Makas Lau and Edward Yakop, who
> have together with me written 99% of the codebase. ICLAs are on file
> with Secretary but I (or anyone on PMC) have not started the request
> for accounts with infra@.
>
> 4. I will try to obtain the ICLA from the remaining 15 contributors, or
> if not possible, then check with Incubator/Legal if the "one line here
> and there" that constitutes those contributions is still Ok, considering
> that OPS4J community is already Apache Licensed and even if that would
> not be enough, then I think it would still fall under "fair use".
>
> 5. Hopefully all the above sorted out this month.
>
>
> Status Pax Web;
>
> 1. There are dependencies in Pax Web on a couple of other very generic
> projects, which barely fit in Felix at all. We think they might as
> well remain in OPS4J as an external dependency.
>
> 2. For that to be useful, those must be published on Maven Central repo,
> and we are looking at doing final releases of those (OPS4J has
> mirror connection to Maven Central).
>
> 3. Once that has been done, we want to clean up Pax Web (incl the above)
> before going into a similar cycle as Pax Logging.
>
>
> In general, the folks have been fairly occupied with "real life projects",
> which has a spin off effect of a new "in container test" system (Pax Drone),
> but hopefully we can get some cycles over for the above in the near future.
> My guess is somewhere in Sept this should be completed.
>
>
> As for another "slim HTTP" service... Be my guest. Pax Web doesn't pretend to
> be small, uses Jetty under the hood, but is TCK compliant (and the TCK needs
> better tests, since too many existing HTTP services are passing although they
> are not spec compliant). I think Pax Web also requires Java 5 at the moment,
> so a Http Service for Foundation EE would be good for people in the embedded
> space.
>
>
> Cheers
>
Re: OBR
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 23 July 2008 23:15, Richard S. Hall wrote:
> Well, nothing stops us from releasing our HTTP Service too, but there is
> an issue here with OPS4J as we try to foster more cooperation between
> the two communities.
>
> I think PAX Web is under consideration as a collaboration point, but the
> first collaboration attempt is around PAX Logging, if I understand
> correctly. I am not sure where we are in this process right now, but we
> have definitely started it. Perhaps Niclas has an update. Things can
> slow down a little in the Summer...
Yes. I just came back from a Looooong trip in Europe. And I need the comfort
of "home" to deal with community issues.
Status Pax Logging;
1. The PMC voted Pax Logging in as a Felix project.
2. I have uploaded the TAR ball in question to Incubator, for IP Clearance.
The IP Clearance paper work is pending.
3. Felix PMC voted in two new committers, Makas Lau and Edward Yakop, who
have together with me written 99% of the codebase. ICLAs are on file
with Secretary but I (or anyone on PMC) have not started the request
for accounts with infra@.
4. I will try to obtain the ICLA from the remaining 15 contributors, or
if not possible, then check with Incubator/Legal if the "one line here
and there" that constitutes those contributions is still Ok, considering
that OPS4J community is already Apache Licensed and even if that would
not be enough, then I think it would still fall under "fair use".
5. Hopefully all the above sorted out this month.
Status Pax Web;
1. There are dependencies in Pax Web on a couple of other very generic
projects, which barely fit in Felix at all. We think they might as
well remain in OPS4J as an external dependency.
2. For that to be useful, those must be published on Maven Central repo,
and we are looking at doing final releases of those (OPS4J has
mirror connection to Maven Central).
3. Once that has been done, we want to clean up Pax Web (incl the above)
before going into a similar cycle as Pax Logging.
In general, the folks have been fairly occupied with "real life projects",
which has a spin off effect of a new "in container test" system (Pax Drone),
but hopefully we can get some cycles over for the above in the near future.
My guess is somewhere in Sept this should be completed.
As for another "slim HTTP" service... Be my guest. Pax Web doesn't pretend to
be small, uses Jetty under the hood, but is TCK compliant (and the TCK needs
better tests, since too many existing HTTP services are passing although they
are not spec compliant). I think Pax Web also requires Java 5 at the moment,
so a Http Service for Foundation EE would be good for people in the embedded
space.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
Re: OBR
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Felix Meschberger wrote:
> Hi,
>
> Richard S. Hall schrieb:
>> Clement Escoffier wrote:
>>> 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.
>
> Agreed. On the other hand, OPS4J has a released HTTP Service (PAX Web)
> ... (oops, did not want to open pandorra's box ;-) )
Well, nothing stops us from releasing our HTTP Service too, but there is
an issue here with OPS4J as we try to foster more cooperation between
the two communities.
I think PAX Web is under consideration as a collaboration point, but the
first collaboration attempt is around PAX Logging, if I understand
correctly. I am not sure where we are in this process right now, but we
have definitely started it. Perhaps Niclas has an update. Things can
slow down a little in the Summer...
-> richard
>
> Regards
> Felix
Re: OBR
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Richard S. Hall schrieb:
> Clement Escoffier wrote:
>> 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.
Agreed. On the other hand, OPS4J has a released HTTP Service (PAX Web)
... (oops, did not want to open pandorra's box ;-) )
Regards
Felix
Re: OBR
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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:fmeschbe@gmail.com]
> 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
>
>
>
RE: OBR
Posted by Clement Escoffier <cl...@gmail.com>.
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. 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.
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).
Clement
-----Original Message-----
From: Felix Meschberger [mailto:fmeschbe@gmail.com]
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
>>
>
Re: OBR
Posted by Felix Meschberger <fm...@gmail.com>.
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.apache.felix.bundlerepository/1.1.0-SNAPSHOT/org.apache.felix.bundlerepository-1.1.0-20080627.095454-3.jar
>>
>