You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Benson Margulies <be...@basistech.com> on 2015/07/07 22:25:55 UTC
Talking to an OBR repo
Reading org.apache.felix.gogo.command.OBR, I see that it uses a
felix-specific service which in turn talks to
org.osgi.service.repository.Repository. I'm hoping to write some
container-independent code to look for things in an OBR repo; can
anyone advise? Should I just learn from
org.apache.felix.bundlerepository.impl.OSGiRepositoryImpl?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Talking to an OBR repo
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Karaf can work with Felix or Equinox: it's very flexible as you don't
care about the framework that you use.
To change from Felix to Equinox (or vice versa), you just have to change
in etc/config.properties:
karaf.framework=felix
to use felix
karaf.framework=equinox
to use equinox.
Regards
JB
On 07/08/2015 04:48 PM, Benson Margulies wrote:
> On Wed, Jul 8, 2015 at 10:32 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> Hi Benson,
>
> Hi Jean-Baptiste, thanks for giving my situation some thought!
>
>>
>> What you are doing looks like a container: why not using Karaf and features
>
> Well, I started out with plain Felix. We've ended up with Equinox. I'm
> assuming that Karaf needs Felix as opposed to Equinox, I'm sure you'll
> correct me if I'm wrong. Here's why we ended up on Equinox:
>
> We deliver a very large amount of read-only data to our users; it's
> statistical models and dictionaries. We don't want them to have to
> make copies. This data is mapped into memory, not just read from
> streams.
>
> I created a mechanism in which our bundles contain (via a fragment)
> this data as a compressed tar archive. The Activators call
> BundleContext.getDataFile(), and unpack the data into there. This
> works great in Felix, so long as only one process is using the
> container. However, a user with multiple processes needs multiple
> containers and multiple copies, because Felix disables getDataFile()
> entirely for shared containers.
>
> Equinox, on the other hand, allows for shared, read-only, data. I can
> load my bundles into a container, tell them to unpack their data, and
> then treat the resulting container as a read-only, shared, resource,
> complete with all the data.
>
> If we wanted to make use of Karaf, I'd have to give up on keeping the
> data seamlessly inside the container, or find out that I can, in fact,
> run Karaf atop of Equinox, or find out that Karaf has some other
> solution to the shared data problem. I confess that, until this email,
> I hadn't considered Karaf, so I didn't do any research on the question
> of Karaf's feelings about the framework implementation.
>
>
>> ?
>>
>> Karaf features are an interesting way to do provisioning, and with profiles
>> it allows you to do runtime provisioning and custom distribution
>> provisioning.
>>
>> For testing, allow me to disagree about pax-exam: it's not so complex, and
>> it runs fine by itself.
>
> I ran into a number of potholes, and some of my co-workers took one
> look at a typical configuration setup in a test class and needed a
> beer.
>
> An example pothole: the 'Parameterized test' feature appears /
> appeared to be completely broken.
>
> However, we're still using it.
>
>
>
>
>
>>
>> Regards
>> JB
>>
>>
>> On 07/08/2015 04:22 PM, Benson Margulies wrote:
>>>
>>> To expand on what I'm doing, in case of useful advice:
>>>
>>> Here I am, part of a team that builds and maintains a large body of
>>> Java code. Until recently, no OSGi at all. Maven is our build tool.
>>> IntelliJ is our predominant IDE.
>>>
>>> Recently, we decided to introduce OSGi into the picture. However, we
>>> can't just wipe out the past; we have many users who would have
>>> kittens if asked to use OSGi. And we would like to avoid radical
>>> changes in tooling. So we want to build bundles, and we want to test
>>> bundles, and we want to deliver a device that uses OSGi 'behind the
>>> application's back' for those who don't want to deal with it. That
>>> amounts to launching the framework via the API, and adding some
>>> packages to the system bundle to allow communication between 'inside'
>>> and 'outside'.
>>>
>>> We added Maven modules that use the bundle plugin to our major
>>> components. Where possible, we are using the existing OSGi status of
>>> common open source facilities (commons-io, Jackson, etc). We arranged
>>> things so that almost all communications are via services, not
>>> exported packages. Where there are exported packages, the bundles are
>>> simple in their structure (no packages exported from embedded jars),
>>> so that we could retain relatively plain processes for Java
>>> compilation.
>>>
>>> For testing, we pulled in pax-exam. I'm not especially thrilled with
>>> pax-exam; it seems complex and fragile to me.
>>>
>>> Now, I'm looking at provisioning; when the time comes to set up a
>>> container with the right set of components, how do we assemble all the
>>> dependencies without a bunch of manual metadata maintenance?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Talking to an OBR repo
Posted by Benson Margulies <be...@basistech.com>.
And, of course, 10 seconds of google answers the question about Karaf
and Equinox, so it's off to do some reading on containers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Talking to an OBR repo
Posted by Guillaume Nodet <gn...@apache.org>.
I suppose you refer to https://issues.apache.org/jira/browse/FELIX-4885.
Not sure what you tried, but if you set your cache directory to be
read-only using a chmod ogua-w data/cache (in Karaf), I've been able to run
a read-only karaf without too much problem. I had to turn off the felix
locking by adding felix.cache.locking = false to etc/config.properties, but
apart from that, things seems to work well enough.
2015-07-08 17:18 GMT+02:00 Benson Margulies <be...@basistech.com>:
> On Wed, Jul 8, 2015 at 10:54 AM, Guillaume Nodet <gn...@apache.org>
> wrote:
> > 2015-07-08 16:48 GMT+02:00 Benson Margulies <be...@basistech.com>:
> >
> >> On Wed, Jul 8, 2015 at 10:32 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
> >> wrote:
> >> > Hi Benson,
> >>
> >> Hi Jean-Baptiste, thanks for giving my situation some thought!
> >>
> >> >
> >> > What you are doing looks like a container: why not using Karaf and
> >> features
> >>
> >> Well, I started out with plain Felix. We've ended up with Equinox. I'm
> >> assuming that Karaf needs Felix as opposed to Equinox, I'm sure you'll
> >> correct me if I'm wrong.
> >
> >
> > That has already been answered ... ;-)
> >
> >
> >> Here's why we ended up on Equinox:
> >>
> >> We deliver a very large amount of read-only data to our users; it's
> >> statistical models and dictionaries. We don't want them to have to
> >> make copies. This data is mapped into memory, not just read from
> >> streams.
> >>
> >> I created a mechanism in which our bundles contain (via a fragment)
> >> this data as a compressed tar archive. The Activators call
> >> BundleContext.getDataFile(), and unpack the data into there. This
> >> works great in Felix, so long as only one process is using the
> >> container. However, a user with multiple processes needs multiple
> >> containers and multiple copies, because Felix disables getDataFile()
> >> entirely for shared containers.
> >>
> >> Equinox, on the other hand, allows for shared, read-only, data. I can
> >> load my bundles into a container, tell them to unpack their data, and
> >> then treat the resulting container as a read-only, shared, resource,
> >> complete with all the data.
> >>
> >> If we wanted to make use of Karaf, I'd have to give up on keeping the
> >> data seamlessly inside the container, or find out that I can, in fact,
> >> run Karaf atop of Equinox, or find out that Karaf has some other
> >> solution to the shared data problem. I confess that, until this email,
> >> I hadn't considered Karaf, so I didn't do any research on the question
> >> of Karaf's feelings about the framework implementation.
> >>
> >
> > What's your configuration for shared containers ?
> > We may be able to enhance felix to fix that if needed if that's the only
> > problem.
>
> Here are the Equinox-specific options that we set. If Felix supported
> the equivalent, we'd be happy Felix users.
>
> if (readOnly) {
> // in spite of the seemingly standard names, these are
> Equinox-specific.
> configProps.put("osgi.configuration.area.readOnly", "true");
> configProps.put("osgi.sharedConfiguration.area.readOnly", "true");
> configProps.put("osgi.instance.area.readOnly", "true");
> configProps.put("osgi.user.area.readOnly", "true");
> }
>
> I think that I tried and failed to convince the Felix community that
> this was a valuable feature once before, but I'm happy to try again.
>
> The crucial phenomenon here is that BundleContext.getDataFile() will
> return non-null values when you set these.
>
>
> >
> >
> >>
> >>
> >> > ?
> >> >
> >> > Karaf features are an interesting way to do provisioning, and with
> >> profiles
> >> > it allows you to do runtime provisioning and custom distribution
> >> > provisioning.
> >> >
> >> > For testing, allow me to disagree about pax-exam: it's not so complex,
> >> and
> >> > it runs fine by itself.
> >>
> >> I ran into a number of potholes, and some of my co-workers took one
> >> look at a typical configuration setup in a test class and needed a
> >> beer.
> >>
> >> An example pothole: the 'Parameterized test' feature appears /
> >> appeared to be completely broken.
> >>
> >> However, we're still using it.
> >>
> >>
> >>
> >>
> >>
> >> >
> >> > Regards
> >> > JB
> >> >
> >> >
> >> > On 07/08/2015 04:22 PM, Benson Margulies wrote:
> >> >>
> >> >> To expand on what I'm doing, in case of useful advice:
> >> >>
> >> >> Here I am, part of a team that builds and maintains a large body of
> >> >> Java code. Until recently, no OSGi at all. Maven is our build tool.
> >> >> IntelliJ is our predominant IDE.
> >> >>
> >> >> Recently, we decided to introduce OSGi into the picture. However, we
> >> >> can't just wipe out the past; we have many users who would have
> >> >> kittens if asked to use OSGi. And we would like to avoid radical
> >> >> changes in tooling. So we want to build bundles, and we want to test
> >> >> bundles, and we want to deliver a device that uses OSGi 'behind the
> >> >> application's back' for those who don't want to deal with it. That
> >> >> amounts to launching the framework via the API, and adding some
> >> >> packages to the system bundle to allow communication between 'inside'
> >> >> and 'outside'.
> >> >>
> >> >> We added Maven modules that use the bundle plugin to our major
> >> >> components. Where possible, we are using the existing OSGi status of
> >> >> common open source facilities (commons-io, Jackson, etc). We arranged
> >> >> things so that almost all communications are via services, not
> >> >> exported packages. Where there are exported packages, the bundles are
> >> >> simple in their structure (no packages exported from embedded jars),
> >> >> so that we could retain relatively plain processes for Java
> >> >> compilation.
> >> >>
> >> >> For testing, we pulled in pax-exam. I'm not especially thrilled with
> >> >> pax-exam; it seems complex and fragile to me.
> >> >>
> >> >> Now, I'm looking at provisioning; when the time comes to set up a
> >> >> container with the right set of components, how do we assemble all
> the
> >> >> dependencies without a bunch of manual metadata maintenance?
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> >> For additional commands, e-mail: users-help@felix.apache.org
> >> >>
> >> >
> >> > --
> >> > Jean-Baptiste Onofré
> >> > jbonofre@apache.org
> >> > http://blog.nanthrax.net
> >> > Talend - http://www.talend.com
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> > For additional commands, e-mail: users-help@felix.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Talking to an OBR repo
Posted by Benson Margulies <be...@basistech.com>.
On Wed, Jul 8, 2015 at 10:54 AM, Guillaume Nodet <gn...@apache.org> wrote:
> 2015-07-08 16:48 GMT+02:00 Benson Margulies <be...@basistech.com>:
>
>> On Wed, Jul 8, 2015 at 10:32 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>> > Hi Benson,
>>
>> Hi Jean-Baptiste, thanks for giving my situation some thought!
>>
>> >
>> > What you are doing looks like a container: why not using Karaf and
>> features
>>
>> Well, I started out with plain Felix. We've ended up with Equinox. I'm
>> assuming that Karaf needs Felix as opposed to Equinox, I'm sure you'll
>> correct me if I'm wrong.
>
>
> That has already been answered ... ;-)
>
>
>> Here's why we ended up on Equinox:
>>
>> We deliver a very large amount of read-only data to our users; it's
>> statistical models and dictionaries. We don't want them to have to
>> make copies. This data is mapped into memory, not just read from
>> streams.
>>
>> I created a mechanism in which our bundles contain (via a fragment)
>> this data as a compressed tar archive. The Activators call
>> BundleContext.getDataFile(), and unpack the data into there. This
>> works great in Felix, so long as only one process is using the
>> container. However, a user with multiple processes needs multiple
>> containers and multiple copies, because Felix disables getDataFile()
>> entirely for shared containers.
>>
>> Equinox, on the other hand, allows for shared, read-only, data. I can
>> load my bundles into a container, tell them to unpack their data, and
>> then treat the resulting container as a read-only, shared, resource,
>> complete with all the data.
>>
>> If we wanted to make use of Karaf, I'd have to give up on keeping the
>> data seamlessly inside the container, or find out that I can, in fact,
>> run Karaf atop of Equinox, or find out that Karaf has some other
>> solution to the shared data problem. I confess that, until this email,
>> I hadn't considered Karaf, so I didn't do any research on the question
>> of Karaf's feelings about the framework implementation.
>>
>
> What's your configuration for shared containers ?
> We may be able to enhance felix to fix that if needed if that's the only
> problem.
Here are the Equinox-specific options that we set. If Felix supported
the equivalent, we'd be happy Felix users.
if (readOnly) {
// in spite of the seemingly standard names, these are Equinox-specific.
configProps.put("osgi.configuration.area.readOnly", "true");
configProps.put("osgi.sharedConfiguration.area.readOnly", "true");
configProps.put("osgi.instance.area.readOnly", "true");
configProps.put("osgi.user.area.readOnly", "true");
}
I think that I tried and failed to convince the Felix community that
this was a valuable feature once before, but I'm happy to try again.
The crucial phenomenon here is that BundleContext.getDataFile() will
return non-null values when you set these.
>
>
>>
>>
>> > ?
>> >
>> > Karaf features are an interesting way to do provisioning, and with
>> profiles
>> > it allows you to do runtime provisioning and custom distribution
>> > provisioning.
>> >
>> > For testing, allow me to disagree about pax-exam: it's not so complex,
>> and
>> > it runs fine by itself.
>>
>> I ran into a number of potholes, and some of my co-workers took one
>> look at a typical configuration setup in a test class and needed a
>> beer.
>>
>> An example pothole: the 'Parameterized test' feature appears /
>> appeared to be completely broken.
>>
>> However, we're still using it.
>>
>>
>>
>>
>>
>> >
>> > Regards
>> > JB
>> >
>> >
>> > On 07/08/2015 04:22 PM, Benson Margulies wrote:
>> >>
>> >> To expand on what I'm doing, in case of useful advice:
>> >>
>> >> Here I am, part of a team that builds and maintains a large body of
>> >> Java code. Until recently, no OSGi at all. Maven is our build tool.
>> >> IntelliJ is our predominant IDE.
>> >>
>> >> Recently, we decided to introduce OSGi into the picture. However, we
>> >> can't just wipe out the past; we have many users who would have
>> >> kittens if asked to use OSGi. And we would like to avoid radical
>> >> changes in tooling. So we want to build bundles, and we want to test
>> >> bundles, and we want to deliver a device that uses OSGi 'behind the
>> >> application's back' for those who don't want to deal with it. That
>> >> amounts to launching the framework via the API, and adding some
>> >> packages to the system bundle to allow communication between 'inside'
>> >> and 'outside'.
>> >>
>> >> We added Maven modules that use the bundle plugin to our major
>> >> components. Where possible, we are using the existing OSGi status of
>> >> common open source facilities (commons-io, Jackson, etc). We arranged
>> >> things so that almost all communications are via services, not
>> >> exported packages. Where there are exported packages, the bundles are
>> >> simple in their structure (no packages exported from embedded jars),
>> >> so that we could retain relatively plain processes for Java
>> >> compilation.
>> >>
>> >> For testing, we pulled in pax-exam. I'm not especially thrilled with
>> >> pax-exam; it seems complex and fragile to me.
>> >>
>> >> Now, I'm looking at provisioning; when the time comes to set up a
>> >> container with the right set of components, how do we assemble all the
>> >> dependencies without a bunch of manual metadata maintenance?
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >> For additional commands, e-mail: users-help@felix.apache.org
>> >>
>> >
>> > --
>> > Jean-Baptiste Onofré
>> > jbonofre@apache.org
>> > http://blog.nanthrax.net
>> > Talend - http://www.talend.com
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> > For additional commands, e-mail: users-help@felix.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Talking to an OBR repo
Posted by Guillaume Nodet <gn...@apache.org>.
2015-07-08 16:48 GMT+02:00 Benson Margulies <be...@basistech.com>:
> On Wed, Jul 8, 2015 at 10:32 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
> > Hi Benson,
>
> Hi Jean-Baptiste, thanks for giving my situation some thought!
>
> >
> > What you are doing looks like a container: why not using Karaf and
> features
>
> Well, I started out with plain Felix. We've ended up with Equinox. I'm
> assuming that Karaf needs Felix as opposed to Equinox, I'm sure you'll
> correct me if I'm wrong.
That has already been answered ... ;-)
> Here's why we ended up on Equinox:
>
> We deliver a very large amount of read-only data to our users; it's
> statistical models and dictionaries. We don't want them to have to
> make copies. This data is mapped into memory, not just read from
> streams.
>
> I created a mechanism in which our bundles contain (via a fragment)
> this data as a compressed tar archive. The Activators call
> BundleContext.getDataFile(), and unpack the data into there. This
> works great in Felix, so long as only one process is using the
> container. However, a user with multiple processes needs multiple
> containers and multiple copies, because Felix disables getDataFile()
> entirely for shared containers.
>
> Equinox, on the other hand, allows for shared, read-only, data. I can
> load my bundles into a container, tell them to unpack their data, and
> then treat the resulting container as a read-only, shared, resource,
> complete with all the data.
>
> If we wanted to make use of Karaf, I'd have to give up on keeping the
> data seamlessly inside the container, or find out that I can, in fact,
> run Karaf atop of Equinox, or find out that Karaf has some other
> solution to the shared data problem. I confess that, until this email,
> I hadn't considered Karaf, so I didn't do any research on the question
> of Karaf's feelings about the framework implementation.
>
What's your configuration for shared containers ?
We may be able to enhance felix to fix that if needed if that's the only
problem.
>
>
> > ?
> >
> > Karaf features are an interesting way to do provisioning, and with
> profiles
> > it allows you to do runtime provisioning and custom distribution
> > provisioning.
> >
> > For testing, allow me to disagree about pax-exam: it's not so complex,
> and
> > it runs fine by itself.
>
> I ran into a number of potholes, and some of my co-workers took one
> look at a typical configuration setup in a test class and needed a
> beer.
>
> An example pothole: the 'Parameterized test' feature appears /
> appeared to be completely broken.
>
> However, we're still using it.
>
>
>
>
>
> >
> > Regards
> > JB
> >
> >
> > On 07/08/2015 04:22 PM, Benson Margulies wrote:
> >>
> >> To expand on what I'm doing, in case of useful advice:
> >>
> >> Here I am, part of a team that builds and maintains a large body of
> >> Java code. Until recently, no OSGi at all. Maven is our build tool.
> >> IntelliJ is our predominant IDE.
> >>
> >> Recently, we decided to introduce OSGi into the picture. However, we
> >> can't just wipe out the past; we have many users who would have
> >> kittens if asked to use OSGi. And we would like to avoid radical
> >> changes in tooling. So we want to build bundles, and we want to test
> >> bundles, and we want to deliver a device that uses OSGi 'behind the
> >> application's back' for those who don't want to deal with it. That
> >> amounts to launching the framework via the API, and adding some
> >> packages to the system bundle to allow communication between 'inside'
> >> and 'outside'.
> >>
> >> We added Maven modules that use the bundle plugin to our major
> >> components. Where possible, we are using the existing OSGi status of
> >> common open source facilities (commons-io, Jackson, etc). We arranged
> >> things so that almost all communications are via services, not
> >> exported packages. Where there are exported packages, the bundles are
> >> simple in their structure (no packages exported from embedded jars),
> >> so that we could retain relatively plain processes for Java
> >> compilation.
> >>
> >> For testing, we pulled in pax-exam. I'm not especially thrilled with
> >> pax-exam; it seems complex and fragile to me.
> >>
> >> Now, I'm looking at provisioning; when the time comes to set up a
> >> container with the right set of components, how do we assemble all the
> >> dependencies without a bunch of manual metadata maintenance?
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Talking to an OBR repo
Posted by Benson Margulies <be...@basistech.com>.
On Wed, Jul 8, 2015 at 10:32 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Benson,
Hi Jean-Baptiste, thanks for giving my situation some thought!
>
> What you are doing looks like a container: why not using Karaf and features
Well, I started out with plain Felix. We've ended up with Equinox. I'm
assuming that Karaf needs Felix as opposed to Equinox, I'm sure you'll
correct me if I'm wrong. Here's why we ended up on Equinox:
We deliver a very large amount of read-only data to our users; it's
statistical models and dictionaries. We don't want them to have to
make copies. This data is mapped into memory, not just read from
streams.
I created a mechanism in which our bundles contain (via a fragment)
this data as a compressed tar archive. The Activators call
BundleContext.getDataFile(), and unpack the data into there. This
works great in Felix, so long as only one process is using the
container. However, a user with multiple processes needs multiple
containers and multiple copies, because Felix disables getDataFile()
entirely for shared containers.
Equinox, on the other hand, allows for shared, read-only, data. I can
load my bundles into a container, tell them to unpack their data, and
then treat the resulting container as a read-only, shared, resource,
complete with all the data.
If we wanted to make use of Karaf, I'd have to give up on keeping the
data seamlessly inside the container, or find out that I can, in fact,
run Karaf atop of Equinox, or find out that Karaf has some other
solution to the shared data problem. I confess that, until this email,
I hadn't considered Karaf, so I didn't do any research on the question
of Karaf's feelings about the framework implementation.
> ?
>
> Karaf features are an interesting way to do provisioning, and with profiles
> it allows you to do runtime provisioning and custom distribution
> provisioning.
>
> For testing, allow me to disagree about pax-exam: it's not so complex, and
> it runs fine by itself.
I ran into a number of potholes, and some of my co-workers took one
look at a typical configuration setup in a test class and needed a
beer.
An example pothole: the 'Parameterized test' feature appears /
appeared to be completely broken.
However, we're still using it.
>
> Regards
> JB
>
>
> On 07/08/2015 04:22 PM, Benson Margulies wrote:
>>
>> To expand on what I'm doing, in case of useful advice:
>>
>> Here I am, part of a team that builds and maintains a large body of
>> Java code. Until recently, no OSGi at all. Maven is our build tool.
>> IntelliJ is our predominant IDE.
>>
>> Recently, we decided to introduce OSGi into the picture. However, we
>> can't just wipe out the past; we have many users who would have
>> kittens if asked to use OSGi. And we would like to avoid radical
>> changes in tooling. So we want to build bundles, and we want to test
>> bundles, and we want to deliver a device that uses OSGi 'behind the
>> application's back' for those who don't want to deal with it. That
>> amounts to launching the framework via the API, and adding some
>> packages to the system bundle to allow communication between 'inside'
>> and 'outside'.
>>
>> We added Maven modules that use the bundle plugin to our major
>> components. Where possible, we are using the existing OSGi status of
>> common open source facilities (commons-io, Jackson, etc). We arranged
>> things so that almost all communications are via services, not
>> exported packages. Where there are exported packages, the bundles are
>> simple in their structure (no packages exported from embedded jars),
>> so that we could retain relatively plain processes for Java
>> compilation.
>>
>> For testing, we pulled in pax-exam. I'm not especially thrilled with
>> pax-exam; it seems complex and fragile to me.
>>
>> Now, I'm looking at provisioning; when the time comes to set up a
>> container with the right set of components, how do we assemble all the
>> dependencies without a bunch of manual metadata maintenance?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Talking to an OBR repo
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Benson,
What you are doing looks like a container: why not using Karaf and
features ?
Karaf features are an interesting way to do provisioning, and with
profiles it allows you to do runtime provisioning and custom
distribution provisioning.
For testing, allow me to disagree about pax-exam: it's not so complex,
and it runs fine by itself.
Regards
JB
On 07/08/2015 04:22 PM, Benson Margulies wrote:
> To expand on what I'm doing, in case of useful advice:
>
> Here I am, part of a team that builds and maintains a large body of
> Java code. Until recently, no OSGi at all. Maven is our build tool.
> IntelliJ is our predominant IDE.
>
> Recently, we decided to introduce OSGi into the picture. However, we
> can't just wipe out the past; we have many users who would have
> kittens if asked to use OSGi. And we would like to avoid radical
> changes in tooling. So we want to build bundles, and we want to test
> bundles, and we want to deliver a device that uses OSGi 'behind the
> application's back' for those who don't want to deal with it. That
> amounts to launching the framework via the API, and adding some
> packages to the system bundle to allow communication between 'inside'
> and 'outside'.
>
> We added Maven modules that use the bundle plugin to our major
> components. Where possible, we are using the existing OSGi status of
> common open source facilities (commons-io, Jackson, etc). We arranged
> things so that almost all communications are via services, not
> exported packages. Where there are exported packages, the bundles are
> simple in their structure (no packages exported from embedded jars),
> so that we could retain relatively plain processes for Java
> compilation.
>
> For testing, we pulled in pax-exam. I'm not especially thrilled with
> pax-exam; it seems complex and fragile to me.
>
> Now, I'm looking at provisioning; when the time comes to set up a
> container with the right set of components, how do we assemble all the
> dependencies without a bunch of manual metadata maintenance?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Talking to an OBR repo
Posted by Benson Margulies <be...@basistech.com>.
To expand on what I'm doing, in case of useful advice:
Here I am, part of a team that builds and maintains a large body of
Java code. Until recently, no OSGi at all. Maven is our build tool.
IntelliJ is our predominant IDE.
Recently, we decided to introduce OSGi into the picture. However, we
can't just wipe out the past; we have many users who would have
kittens if asked to use OSGi. And we would like to avoid radical
changes in tooling. So we want to build bundles, and we want to test
bundles, and we want to deliver a device that uses OSGi 'behind the
application's back' for those who don't want to deal with it. That
amounts to launching the framework via the API, and adding some
packages to the system bundle to allow communication between 'inside'
and 'outside'.
We added Maven modules that use the bundle plugin to our major
components. Where possible, we are using the existing OSGi status of
common open source facilities (commons-io, Jackson, etc). We arranged
things so that almost all communications are via services, not
exported packages. Where there are exported packages, the bundles are
simple in their structure (no packages exported from embedded jars),
so that we could retain relatively plain processes for Java
compilation.
For testing, we pulled in pax-exam. I'm not especially thrilled with
pax-exam; it seems complex and fragile to me.
Now, I'm looking at provisioning; when the time comes to set up a
container with the right set of components, how do we assemble all the
dependencies without a bunch of manual metadata maintenance?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Talking to an OBR repo
Posted by Guillaume Nodet <gn...@apache.org>.
Note that the Karaf 4 resolver can't really use OBR, it only supports the
R5/Repository spec.
The client code is located inside the features-core bundle and supports xml
repositories as defined in the spec, but also JSON based repositories
(where the bundle headers are transferred instead of the parsed
capabilities / requirements).
2015-07-08 16:04 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> Ahhh ok, understood.
>
> As you have Nexus Pro, you have OBR support (Nexus already provides the
> repository.xml). In Karaf, you can install directly the OBR support (using
> feature:install obr): it provides obr:url-add to add the OBR server,
> obr:deploy, etc:
>
> http://karaf.apache.org/manual/latest-3.0.x/users-guide/obr.html
>
> Directly in felix, you can install org.apache.felix/org.osgi.service.obr
> bundle: it will provide OBR "client".
>
> Regards
> JB
>
>
> On 07/08/2015 04:00 PM, Benson Margulies wrote:
>
>> I'm sorry to be unclear, you all answered my question, so I'll clarify
>> what question I was asking.
>>
>> I have built some internal maven-centric tooling that can locate
>> dependencies; it works by incorporating metadata in my bundles that
>> lists the maven coordinates of the bundles that supply the imported
>> packages.
>>
>> I'm considering replacing this tooling with code that searches for
>> bundles using R5/OBR Repository. I already have Nexus Pro doing OBR,
>> so I don't think I need Cave. I just need the client side
>> implementation of the repository spec so that I can communicate with a
>> repo and locate dependencies. I'm looking for some example code to
>> learn from; the fact that the gogo shell talks to the Felix-specific
>> service means it's not a great example, so I'm searching elsewhere.
>>
>>
>> On Wed, Jul 8, 2015 at 9:44 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>
>>> Not sure to follow you, but Cave expose the repository XML and Karaf
>>> features resolver can use it as remote resources repository (or OBR can
>>> do
>>> that as well).
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 07/08/2015 03:38 PM, Benson Margulies wrote:
>>>
>>>>
>>>> I am beginning to become less dense on this subject. To use the
>>>> Repository service, I need someone's implementation that reads the XML
>>>> over the network and does the work.
>>>>
>>>> On Tue, Jul 7, 2015 at 4:30 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>> wrote:
>>>>
>>>>>
>>>>> FYI, Apache Karaf Cave provides an implementation of OSGi Repository R5
>>>>> (with additional features like Maven repo, REST API, etc).
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>> On 07/07/2015 10:28 PM, Neil Bartlett wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Benson,
>>>>>>
>>>>>> First, why not read the Repository Service Specification? OSGi
>>>>>> compendium
>>>>>> R5, chapter 132.
>>>>>>
>>>>>> Regards,
>>>>>> Neil
>>>>>>
>>>>>> On 7 Jul 2015, at 21:25, Benson Margulies <be...@basistech.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Reading org.apache.felix.gogo.command.OBR, I see that it uses a
>>>>>>> felix-specific service which in turn talks to
>>>>>>> org.osgi.service.repository.Repository. I'm hoping to write some
>>>>>>> container-independent code to look for things in an OBR repo; can
>>>>>>> anyone advise? Should I just learn from
>>>>>>> org.apache.felix.bundlerepository.impl.OSGiRepositoryImpl?
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>> --
>>>>> Jean-Baptiste Onofré
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Talking to an OBR repo
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Ahhh ok, understood.
As you have Nexus Pro, you have OBR support (Nexus already provides the
repository.xml). In Karaf, you can install directly the OBR support
(using feature:install obr): it provides obr:url-add to add the OBR
server, obr:deploy, etc:
http://karaf.apache.org/manual/latest-3.0.x/users-guide/obr.html
Directly in felix, you can install org.apache.felix/org.osgi.service.obr
bundle: it will provide OBR "client".
Regards
JB
On 07/08/2015 04:00 PM, Benson Margulies wrote:
> I'm sorry to be unclear, you all answered my question, so I'll clarify
> what question I was asking.
>
> I have built some internal maven-centric tooling that can locate
> dependencies; it works by incorporating metadata in my bundles that
> lists the maven coordinates of the bundles that supply the imported
> packages.
>
> I'm considering replacing this tooling with code that searches for
> bundles using R5/OBR Repository. I already have Nexus Pro doing OBR,
> so I don't think I need Cave. I just need the client side
> implementation of the repository spec so that I can communicate with a
> repo and locate dependencies. I'm looking for some example code to
> learn from; the fact that the gogo shell talks to the Felix-specific
> service means it's not a great example, so I'm searching elsewhere.
>
>
> On Wed, Jul 8, 2015 at 9:44 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> Not sure to follow you, but Cave expose the repository XML and Karaf
>> features resolver can use it as remote resources repository (or OBR can do
>> that as well).
>>
>> Regards
>> JB
>>
>>
>> On 07/08/2015 03:38 PM, Benson Margulies wrote:
>>>
>>> I am beginning to become less dense on this subject. To use the
>>> Repository service, I need someone's implementation that reads the XML
>>> over the network and does the work.
>>>
>>> On Tue, Jul 7, 2015 at 4:30 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>>> wrote:
>>>>
>>>> FYI, Apache Karaf Cave provides an implementation of OSGi Repository R5
>>>> (with additional features like Maven repo, REST API, etc).
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 07/07/2015 10:28 PM, Neil Bartlett wrote:
>>>>>
>>>>>
>>>>> Hi Benson,
>>>>>
>>>>> First, why not read the Repository Service Specification? OSGi
>>>>> compendium
>>>>> R5, chapter 132.
>>>>>
>>>>> Regards,
>>>>> Neil
>>>>>
>>>>>> On 7 Jul 2015, at 21:25, Benson Margulies <be...@basistech.com> wrote:
>>>>>>
>>>>>> Reading org.apache.felix.gogo.command.OBR, I see that it uses a
>>>>>> felix-specific service which in turn talks to
>>>>>> org.osgi.service.repository.Repository. I'm hoping to write some
>>>>>> container-independent code to look for things in an OBR repo; can
>>>>>> anyone advise? Should I just learn from
>>>>>> org.apache.felix.bundlerepository.impl.OSGiRepositoryImpl?
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Talking to an OBR repo
Posted by Benson Margulies <be...@basistech.com>.
I'm sorry to be unclear, you all answered my question, so I'll clarify
what question I was asking.
I have built some internal maven-centric tooling that can locate
dependencies; it works by incorporating metadata in my bundles that
lists the maven coordinates of the bundles that supply the imported
packages.
I'm considering replacing this tooling with code that searches for
bundles using R5/OBR Repository. I already have Nexus Pro doing OBR,
so I don't think I need Cave. I just need the client side
implementation of the repository spec so that I can communicate with a
repo and locate dependencies. I'm looking for some example code to
learn from; the fact that the gogo shell talks to the Felix-specific
service means it's not a great example, so I'm searching elsewhere.
On Wed, Jul 8, 2015 at 9:44 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Not sure to follow you, but Cave expose the repository XML and Karaf
> features resolver can use it as remote resources repository (or OBR can do
> that as well).
>
> Regards
> JB
>
>
> On 07/08/2015 03:38 PM, Benson Margulies wrote:
>>
>> I am beginning to become less dense on this subject. To use the
>> Repository service, I need someone's implementation that reads the XML
>> over the network and does the work.
>>
>> On Tue, Jul 7, 2015 at 4:30 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>>
>>> FYI, Apache Karaf Cave provides an implementation of OSGi Repository R5
>>> (with additional features like Maven repo, REST API, etc).
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 07/07/2015 10:28 PM, Neil Bartlett wrote:
>>>>
>>>>
>>>> Hi Benson,
>>>>
>>>> First, why not read the Repository Service Specification? OSGi
>>>> compendium
>>>> R5, chapter 132.
>>>>
>>>> Regards,
>>>> Neil
>>>>
>>>>> On 7 Jul 2015, at 21:25, Benson Margulies <be...@basistech.com> wrote:
>>>>>
>>>>> Reading org.apache.felix.gogo.command.OBR, I see that it uses a
>>>>> felix-specific service which in turn talks to
>>>>> org.osgi.service.repository.Repository. I'm hoping to write some
>>>>> container-independent code to look for things in an OBR repo; can
>>>>> anyone advise? Should I just learn from
>>>>> org.apache.felix.bundlerepository.impl.OSGiRepositoryImpl?
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Talking to an OBR repo
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Not sure to follow you, but Cave expose the repository XML and Karaf
features resolver can use it as remote resources repository (or OBR can
do that as well).
Regards
JB
On 07/08/2015 03:38 PM, Benson Margulies wrote:
> I am beginning to become less dense on this subject. To use the
> Repository service, I need someone's implementation that reads the XML
> over the network and does the work.
>
> On Tue, Jul 7, 2015 at 4:30 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> FYI, Apache Karaf Cave provides an implementation of OSGi Repository R5
>> (with additional features like Maven repo, REST API, etc).
>>
>> Regards
>> JB
>>
>>
>> On 07/07/2015 10:28 PM, Neil Bartlett wrote:
>>>
>>> Hi Benson,
>>>
>>> First, why not read the Repository Service Specification? OSGi compendium
>>> R5, chapter 132.
>>>
>>> Regards,
>>> Neil
>>>
>>>> On 7 Jul 2015, at 21:25, Benson Margulies <be...@basistech.com> wrote:
>>>>
>>>> Reading org.apache.felix.gogo.command.OBR, I see that it uses a
>>>> felix-specific service which in turn talks to
>>>> org.osgi.service.repository.Repository. I'm hoping to write some
>>>> container-independent code to look for things in an OBR repo; can
>>>> anyone advise? Should I just learn from
>>>> org.apache.felix.bundlerepository.impl.OSGiRepositoryImpl?
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Talking to an OBR repo
Posted by Benson Margulies <be...@basistech.com>.
I am beginning to become less dense on this subject. To use the
Repository service, I need someone's implementation that reads the XML
over the network and does the work.
On Tue, Jul 7, 2015 at 4:30 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> FYI, Apache Karaf Cave provides an implementation of OSGi Repository R5
> (with additional features like Maven repo, REST API, etc).
>
> Regards
> JB
>
>
> On 07/07/2015 10:28 PM, Neil Bartlett wrote:
>>
>> Hi Benson,
>>
>> First, why not read the Repository Service Specification? OSGi compendium
>> R5, chapter 132.
>>
>> Regards,
>> Neil
>>
>>> On 7 Jul 2015, at 21:25, Benson Margulies <be...@basistech.com> wrote:
>>>
>>> Reading org.apache.felix.gogo.command.OBR, I see that it uses a
>>> felix-specific service which in turn talks to
>>> org.osgi.service.repository.Repository. I'm hoping to write some
>>> container-independent code to look for things in an OBR repo; can
>>> anyone advise? Should I just learn from
>>> org.apache.felix.bundlerepository.impl.OSGiRepositoryImpl?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Talking to an OBR repo
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
FYI, Apache Karaf Cave provides an implementation of OSGi Repository R5
(with additional features like Maven repo, REST API, etc).
Regards
JB
On 07/07/2015 10:28 PM, Neil Bartlett wrote:
> Hi Benson,
>
> First, why not read the Repository Service Specification? OSGi compendium R5, chapter 132.
>
> Regards,
> Neil
>
>> On 7 Jul 2015, at 21:25, Benson Margulies <be...@basistech.com> wrote:
>>
>> Reading org.apache.felix.gogo.command.OBR, I see that it uses a
>> felix-specific service which in turn talks to
>> org.osgi.service.repository.Repository. I'm hoping to write some
>> container-independent code to look for things in an OBR repo; can
>> anyone advise? Should I just learn from
>> org.apache.felix.bundlerepository.impl.OSGiRepositoryImpl?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Talking to an OBR repo
Posted by Neil Bartlett <nj...@gmail.com>.
Hi Benson,
First, why not read the Repository Service Specification? OSGi compendium R5, chapter 132.
Regards,
Neil
> On 7 Jul 2015, at 21:25, Benson Margulies <be...@basistech.com> wrote:
>
> Reading org.apache.felix.gogo.command.OBR, I see that it uses a
> felix-specific service which in turn talks to
> org.osgi.service.repository.Repository. I'm hoping to write some
> container-independent code to look for things in an OBR repo; can
> anyone advise? Should I just learn from
> org.apache.felix.bundlerepository.impl.OSGiRepositoryImpl?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org