You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by David Jencks <da...@yahoo.com> on 2009/04/06 23:19:11 UTC
Philosophical question on osgi vs maven
Lets suppose we were in an alternate reality in which every artifact
in maven repos was a correctly configured osgi bundle, using imports
and exports rather than require-bundle.
Now suppose I've downloaded all the bundles locally and have fired up
osgi so it can see all of them.
Now I try to load a bundle that imports some classes that are
available from several bundles, say the geronimo, sun, and tomcat
servlet 2.5 spec jars, or perhaps the slf4j interface classes.
What facilities does osgi or felix provide to help decide which bundle
will be selected to provide these classes?
-background--
We're looking at using osgi in Geronimo. Currently we have a
classloading system with most of the capabilities of the osgi
classloading model but oriented more towards maven metadata. Each
geronimo specific artifact has some dependency metadata like maven
dependencies that specify most of the classloader, and you can tweak
it with filters to emulate the import/export conditions in osgi.
Since the (multiple parents) of an artifact are specified as other
artifacts, its easy, starting with a particular artifact, to pull in
all its dependencies by artifact name and obtain all the pieces that
are needed to run the artifact you are interested in. This is just
like maven: you specify a dependency in your pom and it and all its
transitive dependencies are automatically downloaded and made
available to your build.
Btoh Geronimo and Maven have ways to override the original
dependencies of an artifact and substitute something else.
IIUC in osgi one can use require-bundle to specify dependencies in a
similar way but again IIUC this is highly frowned upon from a
theoretical perspective and I don't know of any way of overriding
require-bundle specifications.
So.... is there anything in osgi or felix that provides this kind of
dependency specification that can be used with import/exports to
specify specific bundles to satisfy import requirements?
many thanks
david jencks
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Philosophical question on osgi vs maven
Posted by Neil Bartlett <nj...@gmail.com>.
Well, this approach is marginally better than Require-Bundle, because
you don't delegate your import list to another bundle, therefore you
can refactor the contents of the exporting bundle without triggering
NoClassDefFoundErrors in the importer (it will fail to resolve
instead).
But aside from that I agree with what Stuart and Richard are saying.
Neil
On Wed, Apr 8, 2009 at 10:22 AM, Richard S. Hall <he...@ungoverned.org> wrote:
> Perhaps I misunderstood your question, but I thought you were simply asking
> for a way to explicitly specify from which bundles your imported packages
> come. If that is all you want to do, then simple import them using the
> desired bundle symbolic name and version range, e.g.:
>
> Import-Package: org.foo.bar; bundle-symbolic-name="my.desired.bundle";
> bundle-version="[1.0.0,1.1.0)"
>
> These bundle attributes are added implicitly to every exported package for
> the exporting bundle.
>
> Of course, I agree with what Stuart says below, if you are going to do this,
> you are defeating the whole purpose. You might as well stick with
> Require-Bundle.
>
> -> richard
>
> On 4/7/09 12:43 AM, Stuart McCulloch wrote:
>>
>> 2009/4/7 David Jencks<da...@yahoo.com>
>>
>>
>>>
>>> Thanks for the response.... could you clarify a couple things inline?
>>> On Apr 6, 2009, at 2:47 PM, Karl Pauls wrote:
>>>
>>> Well, there is OBR which allows you to resolve a given bundle together
>>>
>>>>
>>>> with the transitive closure over its dependencies based on import and
>>>> export packages
>>>> (
>>>>
>>>> http://www.osgi.org/Download/File?url=/download/rfc-0112_BundleRepository.pdf
>>>> ).
>>>> You can tell the maven bundle plugin to generate an obr repository for
>>>> you (
>>>> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html)
>>>> or use bindex from the OSGi in case you want to create a repository
>>>> for a set of bundles (http://www.osgi.org/Repository/BIndex).
>>>>
>>>>
>>>
>>> IIUC a particular OBR repository file is a list of a set of bundles with
>>> some additional info. There is no requirement that the bundles be
>>> related
>>> in any way or that there is any kind of transitive closure.
>>>
>>> The bundle plugin makes it look like the normal relationship between an
>>> OBR
>>> repo file and a maven repo is a single OBR repo file describing
>>> everything
>>> in the repo. So, assuming we had one of these OBR repo files for my
>>> hypothetical worldwide maven repo, it would do us no good, as would
>>> include
>>> all the bundles that happen to provide some required imports.
>>>
>>
>>
>> but this is the point about the import/export approach - you shouldn't
>> mind
>> who provides
>> the imported package(s), as long as they meet the constraints specified by
>> your bundle.
>>
>> so in an OBR repository it may well be several bundles can provide the
>> same
>> package,
>> in that case it's up to your OBR resolver to decide which bundle to pull
>> in
>> - this might be
>> simplistic (ie. take the first match, like in the Felix bundlerepository)
>> or
>> more complicated
>> (ie. prefer Apache bundles, or small bundles) - the point is that the OBR
>> metadata has
>> all the right information to allow you to decide how to pick'n'choose,
>> without depending
>> on a specific named artifact
>>
>> to see how useful this is, consider extending your application - this
>> might
>> introduce a new
>> constraint that conflicts with one of your original "preferred" bundles,
>> and
>> it might be that
>> another bundle in the OBR can satisfy both your original and updated
>> constraints, so this
>> new bundle gets pulled in and the old one swapped out - this would not be
>> possible with
>> named dependencies
>>
>> (FYI, P2 can also do this and there is an ongoing process to standardize
>> both approaches)
>>
>>
>>
>>>
>>> On the other hand it would be theoretically possible to come up with an
>>> OBR
>>> repo file that only had one bundle for each import and then there would
>>> be
>>> no more ambiguity. On the other hand this is not automatically
>>> extensible:
>>> since a new artifact doesn't come with its own preferred dependencies,
>>> any
>>> time you add a new artifact you need to update the OBR repo file to
>>> mention
>>> it and any new dependencies it might require.
>>>
>>> However, it looks like it would also be possible to turn each maven pom
>>> into an obr repo file and store it next to the maven artifact. Starting
>>> with one particular bundle you could look at its repo file, find the
>>> repo
>>> files for each bundle mentioned therein, and come up with the transitive
>>> closure. This seems like the same process maven uses for transitive
>>> dependencies. As with maven, it's extensible. Since there are a lot of
>>> unrelated trees glued together it would be pretty easy to come up with 2
>>> bundles specified as providing the same package. However it would be
>>> pretty
>>> easy to use something like a "prefer closer to root" policy to resolve
>>> these
>>> conflicts and provide a way to override or correct ancestor's choices.
>>>
>>>
>>
>> this would effectively be the same as Require-Bundle, and just as fragile
>> imho
>>
>> if you wanted a "prefer closer to root" policy then that would probably be
>> possible
>> with a single OBR file, you'd just have to find a way to encode that
>> information in
>> the additional metadata included alongside each bundle entry (OBR is
>> extensible
>> and can support additional capabilities/details)
>>
>> Is this reasonably accurate?
>>
>>>
>>> many thanks
>>> david jencks
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> In your alternate reality you could turn your maven repos in one big
>>>> federated OSGi repository and then point the obr bundle to it to
>>>> discover and deploy bundles (the obr bundle comes with the default
>>>> felix zip - try the obr command in the felix shell).
>>>>
>>>> Furthermore, we are just proposing a new project to the incubator
>>>> which is targeting provisioning:
>>>> http://wiki.apache.org/incubator/AceProposal (just in case your
>>>> interested).
>>>>
>>>> Finally, there is a provisioning solution from eclipse as well. Called
>>>> p2 (http://wiki.eclipse.org/Equinox_p2_Getting_Started).
>>>>
>>>> regards,
>>>>
>>>> Karl
>>>>
>>>> On Mon, Apr 6, 2009 at 11:19 PM, David Jencks<da...@yahoo.com>
>>>> wrote:
>>>>
>>>>
>>>>>
>>>>> Lets suppose we were in an alternate reality in which every artifact in
>>>>> maven repos was a correctly configured osgi bundle, using imports and
>>>>> exports rather than require-bundle.
>>>>>
>>>>> Now suppose I've downloaded all the bundles locally and have fired up
>>>>> osgi
>>>>> so it can see all of them.
>>>>>
>>>>> Now I try to load a bundle that imports some classes that are available
>>>>> from
>>>>> several bundles, say the geronimo, sun, and tomcat servlet 2.5 spec
>>>>> jars,
>>>>> or
>>>>> perhaps the slf4j interface classes.
>>>>>
>>>>> What facilities does osgi or felix provide to help decide which bundle
>>>>> will
>>>>> be selected to provide these classes?
>>>>>
>>>>>
>>>>> -background--
>>>>>
>>>>> We're looking at using osgi in Geronimo. Currently we have a
>>>>> classloading
>>>>> system with most of the capabilities of the osgi classloading model but
>>>>> oriented more towards maven metadata. Each geronimo specific artifact
>>>>> has
>>>>> some dependency metadata like maven dependencies that specify most of
>>>>> the
>>>>> classloader, and you can tweak it with filters to emulate the
>>>>> import/export
>>>>> conditions in osgi.
>>>>>
>>>>> Since the (multiple parents) of an artifact are specified as other
>>>>> artifacts, its easy, starting with a particular artifact, to pull in
>>>>> all
>>>>> its
>>>>> dependencies by artifact name and obtain all the pieces that are needed
>>>>> to
>>>>> run the artifact you are interested in. This is just like maven: you
>>>>> specify a dependency in your pom and it and all its transitive
>>>>> dependencies
>>>>> are automatically downloaded and made available to your build.
>>>>>
>>>>> Btoh Geronimo and Maven have ways to override the original dependencies
>>>>> of
>>>>> an artifact and substitute something else.
>>>>>
>>>>> IIUC in osgi one can use require-bundle to specify dependencies in a
>>>>> similar
>>>>> way but again IIUC this is highly frowned upon from a theoretical
>>>>> perspective and I don't know of any way of overriding require-bundle
>>>>> specifications.
>>>>>
>>>>> So.... is there anything in osgi or felix that provides this kind of
>>>>> dependency specification that can be used with import/exports to
>>>>> specify
>>>>> specific bundles to satisfy import requirements?
>>>>>
>>>>> many thanks
>>>>> david jencks
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Karl Pauls
>>>> karlpauls@gmail.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: Philosophical question on osgi vs maven
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/8/09 12:14 PM, David Jencks wrote:
>
> On Apr 8, 2009, at 2:22 AM, Richard S. Hall wrote:
>
>> Perhaps I misunderstood your question, but I thought you were simply
>> asking for a way to explicitly specify from which bundles your
>> imported packages come. If that is all you want to do, then simple
>> import them using the desired bundle symbolic name and version range,
>> e.g.:
>>
>> Import-Package: org.foo.bar;
>> bundle-symbolic-name="my.desired.bundle"; bundle-version="[1.0.0,1.1.0)"
>>
>> These bundle attributes are added implicitly to every exported
>> package for the exporting bundle.
>>
>> Of course, I agree with what Stuart says below, if you are going to
>> do this, you are defeating the whole purpose. You might as well stick
>> with Require-Bundle.
>
> My conclusion at this point is.... if I want to use osgi without
> require-bundle (or the above more complicated equivalent) I have to
> make sure, through some non-standard mechanism, that only the bundles
> I will accept are accessible to the osgi runtime. There's a little
> bit of support in OBR in that I can write my own resolver, but there
> are no well known useful strategies.
>
> Is this correct?
I am confused, since it seems like we are talking about two different
things potentially, so I will reiterate in hopes of being clear.
If you use Require-Bundle or the Import-Package approach from above,
then you do not need to worry about making only "acceptable" bundles
available, since the OSGi framework will only be able to resolve your
bundles if the "acceptable" bundles are available.
Both of these approaches tie your bundle explicitly to the "acceptable"
providers. So, even in the face of other providers, only the
"acceptable" providers will be chosen no matter what, which is why these
approaches are brittle.
At run time, you have to make sure all bundles needed to resolve your
bundles (i.e., transitive dependencies) are installed into the OSGi
framework so the resolve can succeed, but this is the normal situation
no matter which approach you are using (flexible or brittle).
For this second part, you need to use some non-standard mechanism, like
OBR, but if you adopted a brittle approach, then you don't need to worry
about whether or not multiple providers exist.
-> richard
>
> thanks
> david jencks
>
>>
>>
>> -> richard
>>
>> On 4/7/09 12:43 AM, Stuart McCulloch wrote:
>>> 2009/4/7 David Jencks<da...@yahoo.com>
>>>
>>>
>>>> Thanks for the response.... could you clarify a couple things inline?
>>>> On Apr 6, 2009, at 2:47 PM, Karl Pauls wrote:
>>>>
>>>> Well, there is OBR which allows you to resolve a given bundle
>>>> together
>>>>
>>>>> with the transitive closure over its dependencies based on import and
>>>>> export packages
>>>>> (
>>>>> http://www.osgi.org/Download/File?url=/download/rfc-0112_BundleRepository.pdf
>>>>>
>>>>> ).
>>>>> You can tell the maven bundle plugin to generate an obr repository
>>>>> for
>>>>> you (
>>>>> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html)
>>>>>
>>>>> or use bindex from the OSGi in case you want to create a repository
>>>>> for a set of bundles (http://www.osgi.org/Repository/BIndex).
>>>>>
>>>>>
>>>> IIUC a particular OBR repository file is a list of a set of bundles
>>>> with
>>>> some additional info. There is no requirement that the bundles be
>>>> related
>>>> in any way or that there is any kind of transitive closure.
>>>>
>>>> The bundle plugin makes it look like the normal relationship
>>>> between an OBR
>>>> repo file and a maven repo is a single OBR repo file describing
>>>> everything
>>>> in the repo. So, assuming we had one of these OBR repo files for my
>>>> hypothetical worldwide maven repo, it would do us no good, as would
>>>> include
>>>> all the bundles that happen to provide some required imports.
>>>>
>>>
>>>
>>> but this is the point about the import/export approach - you
>>> shouldn't mind
>>> who provides
>>> the imported package(s), as long as they meet the constraints
>>> specified by
>>> your bundle.
>>>
>>> so in an OBR repository it may well be several bundles can provide
>>> the same
>>> package,
>>> in that case it's up to your OBR resolver to decide which bundle to
>>> pull in
>>> - this might be
>>> simplistic (ie. take the first match, like in the Felix
>>> bundlerepository) or
>>> more complicated
>>> (ie. prefer Apache bundles, or small bundles) - the point is that
>>> the OBR
>>> metadata has
>>> all the right information to allow you to decide how to pick'n'choose,
>>> without depending
>>> on a specific named artifact
>>>
>>> to see how useful this is, consider extending your application -
>>> this might
>>> introduce a new
>>> constraint that conflicts with one of your original "preferred"
>>> bundles, and
>>> it might be that
>>> another bundle in the OBR can satisfy both your original and updated
>>> constraints, so this
>>> new bundle gets pulled in and the old one swapped out - this would
>>> not be
>>> possible with
>>> named dependencies
>>>
>>> (FYI, P2 can also do this and there is an ongoing process to
>>> standardize
>>> both approaches)
>>>
>>>
>>>
>>>> On the other hand it would be theoretically possible to come up
>>>> with an OBR
>>>> repo file that only had one bundle for each import and then there
>>>> would be
>>>> no more ambiguity. On the other hand this is not automatically
>>>> extensible:
>>>> since a new artifact doesn't come with its own preferred
>>>> dependencies, any
>>>> time you add a new artifact you need to update the OBR repo file to
>>>> mention
>>>> it and any new dependencies it might require.
>>>>
>>>> However, it looks like it would also be possible to turn each maven
>>>> pom
>>>> into an obr repo file and store it next to the maven artifact.
>>>> Starting
>>>> with one particular bundle you could look at its repo file, find
>>>> the repo
>>>> files for each bundle mentioned therein, and come up with the
>>>> transitive
>>>> closure. This seems like the same process maven uses for transitive
>>>> dependencies. As with maven, it's extensible. Since there are a
>>>> lot of
>>>> unrelated trees glued together it would be pretty easy to come up
>>>> with 2
>>>> bundles specified as providing the same package. However it would
>>>> be pretty
>>>> easy to use something like a "prefer closer to root" policy to
>>>> resolve these
>>>> conflicts and provide a way to override or correct ancestor's choices.
>>>>
>>>>
>>>
>>> this would effectively be the same as Require-Bundle, and just as
>>> fragile
>>> imho
>>>
>>> if you wanted a "prefer closer to root" policy then that would
>>> probably be
>>> possible
>>> with a single OBR file, you'd just have to find a way to encode that
>>> information in
>>> the additional metadata included alongside each bundle entry (OBR is
>>> extensible
>>> and can support additional capabilities/details)
>>>
>>> Is this reasonably accurate?
>>>
>>>> many thanks
>>>> david jencks
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> In your alternate reality you could turn your maven repos in one big
>>>>> federated OSGi repository and then point the obr bundle to it to
>>>>> discover and deploy bundles (the obr bundle comes with the default
>>>>> felix zip - try the obr command in the felix shell).
>>>>>
>>>>> Furthermore, we are just proposing a new project to the incubator
>>>>> which is targeting provisioning:
>>>>> http://wiki.apache.org/incubator/AceProposal (just in case your
>>>>> interested).
>>>>>
>>>>> Finally, there is a provisioning solution from eclipse as well.
>>>>> Called
>>>>> p2 (http://wiki.eclipse.org/Equinox_p2_Getting_Started).
>>>>>
>>>>> regards,
>>>>>
>>>>> Karl
>>>>>
>>>>> On Mon, Apr 6, 2009 at 11:19 PM, David Jencks<da...@yahoo.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>> Lets suppose we were in an alternate reality in which every
>>>>>> artifact in
>>>>>> maven repos was a correctly configured osgi bundle, using imports
>>>>>> and
>>>>>> exports rather than require-bundle.
>>>>>>
>>>>>> Now suppose I've downloaded all the bundles locally and have
>>>>>> fired up
>>>>>> osgi
>>>>>> so it can see all of them.
>>>>>>
>>>>>> Now I try to load a bundle that imports some classes that are
>>>>>> available
>>>>>> from
>>>>>> several bundles, say the geronimo, sun, and tomcat servlet 2.5
>>>>>> spec jars,
>>>>>> or
>>>>>> perhaps the slf4j interface classes.
>>>>>>
>>>>>> What facilities does osgi or felix provide to help decide which
>>>>>> bundle
>>>>>> will
>>>>>> be selected to provide these classes?
>>>>>>
>>>>>>
>>>>>> -background--
>>>>>>
>>>>>> We're looking at using osgi in Geronimo. Currently we have a
>>>>>> classloading
>>>>>> system with most of the capabilities of the osgi classloading
>>>>>> model but
>>>>>> oriented more towards maven metadata. Each geronimo specific
>>>>>> artifact
>>>>>> has
>>>>>> some dependency metadata like maven dependencies that specify
>>>>>> most of the
>>>>>> classloader, and you can tweak it with filters to emulate the
>>>>>> import/export
>>>>>> conditions in osgi.
>>>>>>
>>>>>> Since the (multiple parents) of an artifact are specified as other
>>>>>> artifacts, its easy, starting with a particular artifact, to pull
>>>>>> in all
>>>>>> its
>>>>>> dependencies by artifact name and obtain all the pieces that are
>>>>>> needed
>>>>>> to
>>>>>> run the artifact you are interested in. This is just like maven:
>>>>>> you
>>>>>> specify a dependency in your pom and it and all its transitive
>>>>>> dependencies
>>>>>> are automatically downloaded and made available to your build.
>>>>>>
>>>>>> Btoh Geronimo and Maven have ways to override the original
>>>>>> dependencies
>>>>>> of
>>>>>> an artifact and substitute something else.
>>>>>>
>>>>>> IIUC in osgi one can use require-bundle to specify dependencies in a
>>>>>> similar
>>>>>> way but again IIUC this is highly frowned upon from a theoretical
>>>>>> perspective and I don't know of any way of overriding require-bundle
>>>>>> specifications.
>>>>>>
>>>>>> So.... is there anything in osgi or felix that provides this kind of
>>>>>> dependency specification that can be used with import/exports to
>>>>>> specify
>>>>>> specific bundles to satisfy import requirements?
>>>>>>
>>>>>> many thanks
>>>>>> david jencks
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> Karl Pauls
>>>>> karlpauls@gmail.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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Philosophical question on osgi vs maven
Posted by Karl Pauls <ka...@gmail.com>.
In case you are talking more about something like feature sets (i.e.,
collections of bundles that should be installed together) you could
have a look at the deployment admin service (its described in the
compendium spec).
regards,
Karl
On Wed, Apr 8, 2009 at 7:06 PM, Stuart McCulloch <mc...@gmail.com> wrote:
> 2009/4/9 David Jencks <da...@yahoo.com>
>
>>
>> On Apr 8, 2009, at 2:22 AM, Richard S. Hall wrote:
>>
>> Perhaps I misunderstood your question, but I thought you were simply
>>> asking for a way to explicitly specify from which bundles your imported
>>> packages come. If that is all you want to do, then simple import them using
>>> the desired bundle symbolic name and version range, e.g.:
>>>
>>> Import-Package: org.foo.bar; bundle-symbolic-name="my.desired.bundle";
>>> bundle-version="[1.0.0,1.1.0)"
>>>
>>> These bundle attributes are added implicitly to every exported package for
>>> the exporting bundle.
>>>
>>> Of course, I agree with what Stuart says below, if you are going to do
>>> this, you are defeating the whole purpose. You might as well stick with
>>> Require-Bundle.
>>>
>>
>> My conclusion at this point is.... if I want to use osgi without
>> require-bundle (or the above more complicated equivalent) I have to make
>> sure, through some non-standard mechanism, that only the bundles I will
>> accept are accessible to the osgi runtime. There's a little bit of support
>> in OBR in that I can write my own resolver, but there are no well known
>> useful strategies.
>>
>
> well, if you already know what bundles you will accept then you can use the
> standard OSGi APIs
> for installing those bundles - or something like FileInstall which installs
> bundles from a directory.
>
> OBR in this sense is probably overkill, as one of the aims of OBR is to help
> resolve a consistent
> set of bundles from a potentially large space of possible permutations,
> based on a given criteria.
>
> BTW, given your maven example you might want to look at the Pax tools over
> at OPS4J
>
> you can use the maven-pax-plugin to provision bundles based on a Maven
> project: it traverses
> the Maven dependency graph looking for bundles and then uses Pax-Runner to
> deploy them
>
> Is this correct?
>>
>> thanks
>> david jencks
>>
>> -> richard
>>>
>>> On 4/7/09 12:43 AM, Stuart McCulloch wrote:
>>>
>>>> 2009/4/7 David Jencks<da...@yahoo.com>
>>>>
>>>>
>>>> Thanks for the response.... could you clarify a couple things inline?
>>>>> On Apr 6, 2009, at 2:47 PM, Karl Pauls wrote:
>>>>>
>>>>> Well, there is OBR which allows you to resolve a given bundle together
>>>>>
>>>>> with the transitive closure over its dependencies based on import and
>>>>>> export packages
>>>>>> (
>>>>>>
>>>>>> http://www.osgi.org/Download/File?url=/download/rfc-0112_BundleRepository.pdf
>>>>>> ).
>>>>>> You can tell the maven bundle plugin to generate an obr repository for
>>>>>> you (
>>>>>> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
>>>>>> )
>>>>>> or use bindex from the OSGi in case you want to create a repository
>>>>>> for a set of bundles (http://www.osgi.org/Repository/BIndex).
>>>>>>
>>>>>>
>>>>>> IIUC a particular OBR repository file is a list of a set of bundles
>>>>> with
>>>>> some additional info. There is no requirement that the bundles be
>>>>> related
>>>>> in any way or that there is any kind of transitive closure.
>>>>>
>>>>> The bundle plugin makes it look like the normal relationship between an
>>>>> OBR
>>>>> repo file and a maven repo is a single OBR repo file describing
>>>>> everything
>>>>> in the repo. So, assuming we had one of these OBR repo files for my
>>>>> hypothetical worldwide maven repo, it would do us no good, as would
>>>>> include
>>>>> all the bundles that happen to provide some required imports.
>>>>>
>>>>>
>>>>
>>>> but this is the point about the import/export approach - you shouldn't
>>>> mind
>>>> who provides
>>>> the imported package(s), as long as they meet the constraints specified
>>>> by
>>>> your bundle.
>>>>
>>>> so in an OBR repository it may well be several bundles can provide the
>>>> same
>>>> package,
>>>> in that case it's up to your OBR resolver to decide which bundle to pull
>>>> in
>>>> - this might be
>>>> simplistic (ie. take the first match, like in the Felix bundlerepository)
>>>> or
>>>> more complicated
>>>> (ie. prefer Apache bundles, or small bundles) - the point is that the OBR
>>>> metadata has
>>>> all the right information to allow you to decide how to pick'n'choose,
>>>> without depending
>>>> on a specific named artifact
>>>>
>>>> to see how useful this is, consider extending your application - this
>>>> might
>>>> introduce a new
>>>> constraint that conflicts with one of your original "preferred" bundles,
>>>> and
>>>> it might be that
>>>> another bundle in the OBR can satisfy both your original and updated
>>>> constraints, so this
>>>> new bundle gets pulled in and the old one swapped out - this would not be
>>>> possible with
>>>> named dependencies
>>>>
>>>> (FYI, P2 can also do this and there is an ongoing process to standardize
>>>> both approaches)
>>>>
>>>>
>>>>
>>>> On the other hand it would be theoretically possible to come up with an
>>>>> OBR
>>>>> repo file that only had one bundle for each import and then there would
>>>>> be
>>>>> no more ambiguity. On the other hand this is not automatically
>>>>> extensible:
>>>>> since a new artifact doesn't come with its own preferred dependencies,
>>>>> any
>>>>> time you add a new artifact you need to update the OBR repo file to
>>>>> mention
>>>>> it and any new dependencies it might require.
>>>>>
>>>>> However, it looks like it would also be possible to turn each maven pom
>>>>> into an obr repo file and store it next to the maven artifact. Starting
>>>>> with one particular bundle you could look at its repo file, find the
>>>>> repo
>>>>> files for each bundle mentioned therein, and come up with the transitive
>>>>> closure. This seems like the same process maven uses for transitive
>>>>> dependencies. As with maven, it's extensible. Since there are a lot of
>>>>> unrelated trees glued together it would be pretty easy to come up with 2
>>>>> bundles specified as providing the same package. However it would be
>>>>> pretty
>>>>> easy to use something like a "prefer closer to root" policy to resolve
>>>>> these
>>>>> conflicts and provide a way to override or correct ancestor's choices.
>>>>>
>>>>>
>>>>>
>>>> this would effectively be the same as Require-Bundle, and just as fragile
>>>> imho
>>>>
>>>> if you wanted a "prefer closer to root" policy then that would probably
>>>> be
>>>> possible
>>>> with a single OBR file, you'd just have to find a way to encode that
>>>> information in
>>>> the additional metadata included alongside each bundle entry (OBR is
>>>> extensible
>>>> and can support additional capabilities/details)
>>>>
>>>> Is this reasonably accurate?
>>>>
>>>> many thanks
>>>>> david jencks
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> In your alternate reality you could turn your maven repos in one big
>>>>>> federated OSGi repository and then point the obr bundle to it to
>>>>>> discover and deploy bundles (the obr bundle comes with the default
>>>>>> felix zip - try the obr command in the felix shell).
>>>>>>
>>>>>> Furthermore, we are just proposing a new project to the incubator
>>>>>> which is targeting provisioning:
>>>>>> http://wiki.apache.org/incubator/AceProposal (just in case your
>>>>>> interested).
>>>>>>
>>>>>> Finally, there is a provisioning solution from eclipse as well. Called
>>>>>> p2 (http://wiki.eclipse.org/Equinox_p2_Getting_Started).
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> Karl
>>>>>>
>>>>>> On Mon, Apr 6, 2009 at 11:19 PM, David Jencks<da...@yahoo.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Lets suppose we were in an alternate reality in which every artifact
>>>>>>> in
>>>>>>> maven repos was a correctly configured osgi bundle, using imports and
>>>>>>> exports rather than require-bundle.
>>>>>>>
>>>>>>> Now suppose I've downloaded all the bundles locally and have fired up
>>>>>>> osgi
>>>>>>> so it can see all of them.
>>>>>>>
>>>>>>> Now I try to load a bundle that imports some classes that are
>>>>>>> available
>>>>>>> from
>>>>>>> several bundles, say the geronimo, sun, and tomcat servlet 2.5 spec
>>>>>>> jars,
>>>>>>> or
>>>>>>> perhaps the slf4j interface classes.
>>>>>>>
>>>>>>> What facilities does osgi or felix provide to help decide which bundle
>>>>>>> will
>>>>>>> be selected to provide these classes?
>>>>>>>
>>>>>>>
>>>>>>> -background--
>>>>>>>
>>>>>>> We're looking at using osgi in Geronimo. Currently we have a
>>>>>>> classloading
>>>>>>> system with most of the capabilities of the osgi classloading model
>>>>>>> but
>>>>>>> oriented more towards maven metadata. Each geronimo specific artifact
>>>>>>> has
>>>>>>> some dependency metadata like maven dependencies that specify most of
>>>>>>> the
>>>>>>> classloader, and you can tweak it with filters to emulate the
>>>>>>> import/export
>>>>>>> conditions in osgi.
>>>>>>>
>>>>>>> Since the (multiple parents) of an artifact are specified as other
>>>>>>> artifacts, its easy, starting with a particular artifact, to pull in
>>>>>>> all
>>>>>>> its
>>>>>>> dependencies by artifact name and obtain all the pieces that are
>>>>>>> needed
>>>>>>> to
>>>>>>> run the artifact you are interested in. This is just like maven: you
>>>>>>> specify a dependency in your pom and it and all its transitive
>>>>>>> dependencies
>>>>>>> are automatically downloaded and made available to your build.
>>>>>>>
>>>>>>> Btoh Geronimo and Maven have ways to override the original
>>>>>>> dependencies
>>>>>>> of
>>>>>>> an artifact and substitute something else.
>>>>>>>
>>>>>>> IIUC in osgi one can use require-bundle to specify dependencies in a
>>>>>>> similar
>>>>>>> way but again IIUC this is highly frowned upon from a theoretical
>>>>>>> perspective and I don't know of any way of overriding require-bundle
>>>>>>> specifications.
>>>>>>>
>>>>>>> So.... is there anything in osgi or felix that provides this kind of
>>>>>>> dependency specification that can be used with import/exports to
>>>>>>> specify
>>>>>>> specific bundles to satisfy import requirements?
>>>>>>>
>>>>>>> many thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>> Karl Pauls
>>>>>> karlpauls@gmail.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
>>
>>
>
>
> --
> Cheers, Stuart
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Philosophical question on osgi vs maven
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/4/9 David Jencks <da...@yahoo.com>
>
> On Apr 8, 2009, at 2:22 AM, Richard S. Hall wrote:
>
> Perhaps I misunderstood your question, but I thought you were simply
>> asking for a way to explicitly specify from which bundles your imported
>> packages come. If that is all you want to do, then simple import them using
>> the desired bundle symbolic name and version range, e.g.:
>>
>> Import-Package: org.foo.bar; bundle-symbolic-name="my.desired.bundle";
>> bundle-version="[1.0.0,1.1.0)"
>>
>> These bundle attributes are added implicitly to every exported package for
>> the exporting bundle.
>>
>> Of course, I agree with what Stuart says below, if you are going to do
>> this, you are defeating the whole purpose. You might as well stick with
>> Require-Bundle.
>>
>
> My conclusion at this point is.... if I want to use osgi without
> require-bundle (or the above more complicated equivalent) I have to make
> sure, through some non-standard mechanism, that only the bundles I will
> accept are accessible to the osgi runtime. There's a little bit of support
> in OBR in that I can write my own resolver, but there are no well known
> useful strategies.
>
well, if you already know what bundles you will accept then you can use the
standard OSGi APIs
for installing those bundles - or something like FileInstall which installs
bundles from a directory.
OBR in this sense is probably overkill, as one of the aims of OBR is to help
resolve a consistent
set of bundles from a potentially large space of possible permutations,
based on a given criteria.
BTW, given your maven example you might want to look at the Pax tools over
at OPS4J
you can use the maven-pax-plugin to provision bundles based on a Maven
project: it traverses
the Maven dependency graph looking for bundles and then uses Pax-Runner to
deploy them
Is this correct?
>
> thanks
> david jencks
>
> -> richard
>>
>> On 4/7/09 12:43 AM, Stuart McCulloch wrote:
>>
>>> 2009/4/7 David Jencks<da...@yahoo.com>
>>>
>>>
>>> Thanks for the response.... could you clarify a couple things inline?
>>>> On Apr 6, 2009, at 2:47 PM, Karl Pauls wrote:
>>>>
>>>> Well, there is OBR which allows you to resolve a given bundle together
>>>>
>>>> with the transitive closure over its dependencies based on import and
>>>>> export packages
>>>>> (
>>>>>
>>>>> http://www.osgi.org/Download/File?url=/download/rfc-0112_BundleRepository.pdf
>>>>> ).
>>>>> You can tell the maven bundle plugin to generate an obr repository for
>>>>> you (
>>>>> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
>>>>> )
>>>>> or use bindex from the OSGi in case you want to create a repository
>>>>> for a set of bundles (http://www.osgi.org/Repository/BIndex).
>>>>>
>>>>>
>>>>> IIUC a particular OBR repository file is a list of a set of bundles
>>>> with
>>>> some additional info. There is no requirement that the bundles be
>>>> related
>>>> in any way or that there is any kind of transitive closure.
>>>>
>>>> The bundle plugin makes it look like the normal relationship between an
>>>> OBR
>>>> repo file and a maven repo is a single OBR repo file describing
>>>> everything
>>>> in the repo. So, assuming we had one of these OBR repo files for my
>>>> hypothetical worldwide maven repo, it would do us no good, as would
>>>> include
>>>> all the bundles that happen to provide some required imports.
>>>>
>>>>
>>>
>>> but this is the point about the import/export approach - you shouldn't
>>> mind
>>> who provides
>>> the imported package(s), as long as they meet the constraints specified
>>> by
>>> your bundle.
>>>
>>> so in an OBR repository it may well be several bundles can provide the
>>> same
>>> package,
>>> in that case it's up to your OBR resolver to decide which bundle to pull
>>> in
>>> - this might be
>>> simplistic (ie. take the first match, like in the Felix bundlerepository)
>>> or
>>> more complicated
>>> (ie. prefer Apache bundles, or small bundles) - the point is that the OBR
>>> metadata has
>>> all the right information to allow you to decide how to pick'n'choose,
>>> without depending
>>> on a specific named artifact
>>>
>>> to see how useful this is, consider extending your application - this
>>> might
>>> introduce a new
>>> constraint that conflicts with one of your original "preferred" bundles,
>>> and
>>> it might be that
>>> another bundle in the OBR can satisfy both your original and updated
>>> constraints, so this
>>> new bundle gets pulled in and the old one swapped out - this would not be
>>> possible with
>>> named dependencies
>>>
>>> (FYI, P2 can also do this and there is an ongoing process to standardize
>>> both approaches)
>>>
>>>
>>>
>>> On the other hand it would be theoretically possible to come up with an
>>>> OBR
>>>> repo file that only had one bundle for each import and then there would
>>>> be
>>>> no more ambiguity. On the other hand this is not automatically
>>>> extensible:
>>>> since a new artifact doesn't come with its own preferred dependencies,
>>>> any
>>>> time you add a new artifact you need to update the OBR repo file to
>>>> mention
>>>> it and any new dependencies it might require.
>>>>
>>>> However, it looks like it would also be possible to turn each maven pom
>>>> into an obr repo file and store it next to the maven artifact. Starting
>>>> with one particular bundle you could look at its repo file, find the
>>>> repo
>>>> files for each bundle mentioned therein, and come up with the transitive
>>>> closure. This seems like the same process maven uses for transitive
>>>> dependencies. As with maven, it's extensible. Since there are a lot of
>>>> unrelated trees glued together it would be pretty easy to come up with 2
>>>> bundles specified as providing the same package. However it would be
>>>> pretty
>>>> easy to use something like a "prefer closer to root" policy to resolve
>>>> these
>>>> conflicts and provide a way to override or correct ancestor's choices.
>>>>
>>>>
>>>>
>>> this would effectively be the same as Require-Bundle, and just as fragile
>>> imho
>>>
>>> if you wanted a "prefer closer to root" policy then that would probably
>>> be
>>> possible
>>> with a single OBR file, you'd just have to find a way to encode that
>>> information in
>>> the additional metadata included alongside each bundle entry (OBR is
>>> extensible
>>> and can support additional capabilities/details)
>>>
>>> Is this reasonably accurate?
>>>
>>> many thanks
>>>> david jencks
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> In your alternate reality you could turn your maven repos in one big
>>>>> federated OSGi repository and then point the obr bundle to it to
>>>>> discover and deploy bundles (the obr bundle comes with the default
>>>>> felix zip - try the obr command in the felix shell).
>>>>>
>>>>> Furthermore, we are just proposing a new project to the incubator
>>>>> which is targeting provisioning:
>>>>> http://wiki.apache.org/incubator/AceProposal (just in case your
>>>>> interested).
>>>>>
>>>>> Finally, there is a provisioning solution from eclipse as well. Called
>>>>> p2 (http://wiki.eclipse.org/Equinox_p2_Getting_Started).
>>>>>
>>>>> regards,
>>>>>
>>>>> Karl
>>>>>
>>>>> On Mon, Apr 6, 2009 at 11:19 PM, David Jencks<da...@yahoo.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>> Lets suppose we were in an alternate reality in which every artifact
>>>>>> in
>>>>>> maven repos was a correctly configured osgi bundle, using imports and
>>>>>> exports rather than require-bundle.
>>>>>>
>>>>>> Now suppose I've downloaded all the bundles locally and have fired up
>>>>>> osgi
>>>>>> so it can see all of them.
>>>>>>
>>>>>> Now I try to load a bundle that imports some classes that are
>>>>>> available
>>>>>> from
>>>>>> several bundles, say the geronimo, sun, and tomcat servlet 2.5 spec
>>>>>> jars,
>>>>>> or
>>>>>> perhaps the slf4j interface classes.
>>>>>>
>>>>>> What facilities does osgi or felix provide to help decide which bundle
>>>>>> will
>>>>>> be selected to provide these classes?
>>>>>>
>>>>>>
>>>>>> -background--
>>>>>>
>>>>>> We're looking at using osgi in Geronimo. Currently we have a
>>>>>> classloading
>>>>>> system with most of the capabilities of the osgi classloading model
>>>>>> but
>>>>>> oriented more towards maven metadata. Each geronimo specific artifact
>>>>>> has
>>>>>> some dependency metadata like maven dependencies that specify most of
>>>>>> the
>>>>>> classloader, and you can tweak it with filters to emulate the
>>>>>> import/export
>>>>>> conditions in osgi.
>>>>>>
>>>>>> Since the (multiple parents) of an artifact are specified as other
>>>>>> artifacts, its easy, starting with a particular artifact, to pull in
>>>>>> all
>>>>>> its
>>>>>> dependencies by artifact name and obtain all the pieces that are
>>>>>> needed
>>>>>> to
>>>>>> run the artifact you are interested in. This is just like maven: you
>>>>>> specify a dependency in your pom and it and all its transitive
>>>>>> dependencies
>>>>>> are automatically downloaded and made available to your build.
>>>>>>
>>>>>> Btoh Geronimo and Maven have ways to override the original
>>>>>> dependencies
>>>>>> of
>>>>>> an artifact and substitute something else.
>>>>>>
>>>>>> IIUC in osgi one can use require-bundle to specify dependencies in a
>>>>>> similar
>>>>>> way but again IIUC this is highly frowned upon from a theoretical
>>>>>> perspective and I don't know of any way of overriding require-bundle
>>>>>> specifications.
>>>>>>
>>>>>> So.... is there anything in osgi or felix that provides this kind of
>>>>>> dependency specification that can be used with import/exports to
>>>>>> specify
>>>>>> specific bundles to satisfy import requirements?
>>>>>>
>>>>>> many thanks
>>>>>> david jencks
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>> Karl Pauls
>>>>> karlpauls@gmail.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
>
>
--
Cheers, Stuart
Re: Philosophical question on osgi vs maven
Posted by David Jencks <da...@yahoo.com>.
On Apr 8, 2009, at 2:22 AM, Richard S. Hall wrote:
> Perhaps I misunderstood your question, but I thought you were simply
> asking for a way to explicitly specify from which bundles your
> imported packages come. If that is all you want to do, then simple
> import them using the desired bundle symbolic name and version
> range, e.g.:
>
> Import-Package: org.foo.bar; bundle-symbolic-
> name="my.desired.bundle"; bundle-version="[1.0.0,1.1.0)"
>
> These bundle attributes are added implicitly to every exported
> package for the exporting bundle.
>
> Of course, I agree with what Stuart says below, if you are going to
> do this, you are defeating the whole purpose. You might as well
> stick with Require-Bundle.
My conclusion at this point is.... if I want to use osgi without
require-bundle (or the above more complicated equivalent) I have to
make sure, through some non-standard mechanism, that only the bundles
I will accept are accessible to the osgi runtime. There's a little
bit of support in OBR in that I can write my own resolver, but there
are no well known useful strategies.
Is this correct?
thanks
david jencks
>
>
> -> richard
>
> On 4/7/09 12:43 AM, Stuart McCulloch wrote:
>> 2009/4/7 David Jencks<da...@yahoo.com>
>>
>>
>>> Thanks for the response.... could you clarify a couple things
>>> inline?
>>> On Apr 6, 2009, at 2:47 PM, Karl Pauls wrote:
>>>
>>> Well, there is OBR which allows you to resolve a given bundle
>>> together
>>>
>>>> with the transitive closure over its dependencies based on import
>>>> and
>>>> export packages
>>>> (
>>>> http://www.osgi.org/Download/File?url=/download/rfc-0112_BundleRepository.pdf
>>>> ).
>>>> You can tell the maven bundle plugin to generate an obr
>>>> repository for
>>>> you (
>>>> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html)
>>>> or use bindex from the OSGi in case you want to create a repository
>>>> for a set of bundles (http://www.osgi.org/Repository/BIndex).
>>>>
>>>>
>>> IIUC a particular OBR repository file is a list of a set of
>>> bundles with
>>> some additional info. There is no requirement that the bundles be
>>> related
>>> in any way or that there is any kind of transitive closure.
>>>
>>> The bundle plugin makes it look like the normal relationship
>>> between an OBR
>>> repo file and a maven repo is a single OBR repo file describing
>>> everything
>>> in the repo. So, assuming we had one of these OBR repo files for my
>>> hypothetical worldwide maven repo, it would do us no good, as
>>> would include
>>> all the bundles that happen to provide some required imports.
>>>
>>
>>
>> but this is the point about the import/export approach - you
>> shouldn't mind
>> who provides
>> the imported package(s), as long as they meet the constraints
>> specified by
>> your bundle.
>>
>> so in an OBR repository it may well be several bundles can provide
>> the same
>> package,
>> in that case it's up to your OBR resolver to decide which bundle to
>> pull in
>> - this might be
>> simplistic (ie. take the first match, like in the Felix
>> bundlerepository) or
>> more complicated
>> (ie. prefer Apache bundles, or small bundles) - the point is that
>> the OBR
>> metadata has
>> all the right information to allow you to decide how to
>> pick'n'choose,
>> without depending
>> on a specific named artifact
>>
>> to see how useful this is, consider extending your application -
>> this might
>> introduce a new
>> constraint that conflicts with one of your original "preferred"
>> bundles, and
>> it might be that
>> another bundle in the OBR can satisfy both your original and updated
>> constraints, so this
>> new bundle gets pulled in and the old one swapped out - this would
>> not be
>> possible with
>> named dependencies
>>
>> (FYI, P2 can also do this and there is an ongoing process to
>> standardize
>> both approaches)
>>
>>
>>
>>> On the other hand it would be theoretically possible to come up
>>> with an OBR
>>> repo file that only had one bundle for each import and then there
>>> would be
>>> no more ambiguity. On the other hand this is not automatically
>>> extensible:
>>> since a new artifact doesn't come with its own preferred
>>> dependencies, any
>>> time you add a new artifact you need to update the OBR repo file
>>> to mention
>>> it and any new dependencies it might require.
>>>
>>> However, it looks like it would also be possible to turn each
>>> maven pom
>>> into an obr repo file and store it next to the maven artifact.
>>> Starting
>>> with one particular bundle you could look at its repo file, find
>>> the repo
>>> files for each bundle mentioned therein, and come up with the
>>> transitive
>>> closure. This seems like the same process maven uses for transitive
>>> dependencies. As with maven, it's extensible. Since there are a
>>> lot of
>>> unrelated trees glued together it would be pretty easy to come up
>>> with 2
>>> bundles specified as providing the same package. However it would
>>> be pretty
>>> easy to use something like a "prefer closer to root" policy to
>>> resolve these
>>> conflicts and provide a way to override or correct ancestor's
>>> choices.
>>>
>>>
>>
>> this would effectively be the same as Require-Bundle, and just as
>> fragile
>> imho
>>
>> if you wanted a "prefer closer to root" policy then that would
>> probably be
>> possible
>> with a single OBR file, you'd just have to find a way to encode that
>> information in
>> the additional metadata included alongside each bundle entry (OBR is
>> extensible
>> and can support additional capabilities/details)
>>
>> Is this reasonably accurate?
>>
>>> many thanks
>>> david jencks
>>>
>>>
>>>
>>>
>>>
>>>> In your alternate reality you could turn your maven repos in one
>>>> big
>>>> federated OSGi repository and then point the obr bundle to it to
>>>> discover and deploy bundles (the obr bundle comes with the default
>>>> felix zip - try the obr command in the felix shell).
>>>>
>>>> Furthermore, we are just proposing a new project to the incubator
>>>> which is targeting provisioning:
>>>> http://wiki.apache.org/incubator/AceProposal (just in case your
>>>> interested).
>>>>
>>>> Finally, there is a provisioning solution from eclipse as well.
>>>> Called
>>>> p2 (http://wiki.eclipse.org/Equinox_p2_Getting_Started).
>>>>
>>>> regards,
>>>>
>>>> Karl
>>>>
>>>> On Mon, Apr 6, 2009 at 11:19 PM, David Jencks<david_jencks@yahoo.com
>>>> >
>>>> wrote:
>>>>
>>>>
>>>>> Lets suppose we were in an alternate reality in which every
>>>>> artifact in
>>>>> maven repos was a correctly configured osgi bundle, using
>>>>> imports and
>>>>> exports rather than require-bundle.
>>>>>
>>>>> Now suppose I've downloaded all the bundles locally and have
>>>>> fired up
>>>>> osgi
>>>>> so it can see all of them.
>>>>>
>>>>> Now I try to load a bundle that imports some classes that are
>>>>> available
>>>>> from
>>>>> several bundles, say the geronimo, sun, and tomcat servlet 2.5
>>>>> spec jars,
>>>>> or
>>>>> perhaps the slf4j interface classes.
>>>>>
>>>>> What facilities does osgi or felix provide to help decide which
>>>>> bundle
>>>>> will
>>>>> be selected to provide these classes?
>>>>>
>>>>>
>>>>> -background--
>>>>>
>>>>> We're looking at using osgi in Geronimo. Currently we have a
>>>>> classloading
>>>>> system with most of the capabilities of the osgi classloading
>>>>> model but
>>>>> oriented more towards maven metadata. Each geronimo specific
>>>>> artifact
>>>>> has
>>>>> some dependency metadata like maven dependencies that specify
>>>>> most of the
>>>>> classloader, and you can tweak it with filters to emulate the
>>>>> import/export
>>>>> conditions in osgi.
>>>>>
>>>>> Since the (multiple parents) of an artifact are specified as other
>>>>> artifacts, its easy, starting with a particular artifact, to
>>>>> pull in all
>>>>> its
>>>>> dependencies by artifact name and obtain all the pieces that are
>>>>> needed
>>>>> to
>>>>> run the artifact you are interested in. This is just like
>>>>> maven: you
>>>>> specify a dependency in your pom and it and all its transitive
>>>>> dependencies
>>>>> are automatically downloaded and made available to your build.
>>>>>
>>>>> Btoh Geronimo and Maven have ways to override the original
>>>>> dependencies
>>>>> of
>>>>> an artifact and substitute something else.
>>>>>
>>>>> IIUC in osgi one can use require-bundle to specify dependencies
>>>>> in a
>>>>> similar
>>>>> way but again IIUC this is highly frowned upon from a theoretical
>>>>> perspective and I don't know of any way of overriding require-
>>>>> bundle
>>>>> specifications.
>>>>>
>>>>> So.... is there anything in osgi or felix that provides this
>>>>> kind of
>>>>> dependency specification that can be used with import/exports to
>>>>> specify
>>>>> specific bundles to satisfy import requirements?
>>>>>
>>>>> many thanks
>>>>> david jencks
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Karl Pauls
>>>> karlpauls@gmail.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: Philosophical question on osgi vs maven
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Perhaps I misunderstood your question, but I thought you were simply
asking for a way to explicitly specify from which bundles your imported
packages come. If that is all you want to do, then simple import them
using the desired bundle symbolic name and version range, e.g.:
Import-Package: org.foo.bar;
bundle-symbolic-name="my.desired.bundle"; bundle-version="[1.0.0,1.1.0)"
These bundle attributes are added implicitly to every exported package
for the exporting bundle.
Of course, I agree with what Stuart says below, if you are going to do
this, you are defeating the whole purpose. You might as well stick with
Require-Bundle.
-> richard
On 4/7/09 12:43 AM, Stuart McCulloch wrote:
> 2009/4/7 David Jencks<da...@yahoo.com>
>
>
>> Thanks for the response.... could you clarify a couple things inline?
>> On Apr 6, 2009, at 2:47 PM, Karl Pauls wrote:
>>
>> Well, there is OBR which allows you to resolve a given bundle together
>>
>>> with the transitive closure over its dependencies based on import and
>>> export packages
>>> (
>>> http://www.osgi.org/Download/File?url=/download/rfc-0112_BundleRepository.pdf
>>> ).
>>> You can tell the maven bundle plugin to generate an obr repository for
>>> you (
>>> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html)
>>> or use bindex from the OSGi in case you want to create a repository
>>> for a set of bundles (http://www.osgi.org/Repository/BIndex).
>>>
>>>
>> IIUC a particular OBR repository file is a list of a set of bundles with
>> some additional info. There is no requirement that the bundles be related
>> in any way or that there is any kind of transitive closure.
>>
>> The bundle plugin makes it look like the normal relationship between an OBR
>> repo file and a maven repo is a single OBR repo file describing everything
>> in the repo. So, assuming we had one of these OBR repo files for my
>> hypothetical worldwide maven repo, it would do us no good, as would include
>> all the bundles that happen to provide some required imports.
>>
>
>
> but this is the point about the import/export approach - you shouldn't mind
> who provides
> the imported package(s), as long as they meet the constraints specified by
> your bundle.
>
> so in an OBR repository it may well be several bundles can provide the same
> package,
> in that case it's up to your OBR resolver to decide which bundle to pull in
> - this might be
> simplistic (ie. take the first match, like in the Felix bundlerepository) or
> more complicated
> (ie. prefer Apache bundles, or small bundles) - the point is that the OBR
> metadata has
> all the right information to allow you to decide how to pick'n'choose,
> without depending
> on a specific named artifact
>
> to see how useful this is, consider extending your application - this might
> introduce a new
> constraint that conflicts with one of your original "preferred" bundles, and
> it might be that
> another bundle in the OBR can satisfy both your original and updated
> constraints, so this
> new bundle gets pulled in and the old one swapped out - this would not be
> possible with
> named dependencies
>
> (FYI, P2 can also do this and there is an ongoing process to standardize
> both approaches)
>
>
>
>> On the other hand it would be theoretically possible to come up with an OBR
>> repo file that only had one bundle for each import and then there would be
>> no more ambiguity. On the other hand this is not automatically extensible:
>> since a new artifact doesn't come with its own preferred dependencies, any
>> time you add a new artifact you need to update the OBR repo file to mention
>> it and any new dependencies it might require.
>>
>> However, it looks like it would also be possible to turn each maven pom
>> into an obr repo file and store it next to the maven artifact. Starting
>> with one particular bundle you could look at its repo file, find the repo
>> files for each bundle mentioned therein, and come up with the transitive
>> closure. This seems like the same process maven uses for transitive
>> dependencies. As with maven, it's extensible. Since there are a lot of
>> unrelated trees glued together it would be pretty easy to come up with 2
>> bundles specified as providing the same package. However it would be pretty
>> easy to use something like a "prefer closer to root" policy to resolve these
>> conflicts and provide a way to override or correct ancestor's choices.
>>
>>
>
> this would effectively be the same as Require-Bundle, and just as fragile
> imho
>
> if you wanted a "prefer closer to root" policy then that would probably be
> possible
> with a single OBR file, you'd just have to find a way to encode that
> information in
> the additional metadata included alongside each bundle entry (OBR is
> extensible
> and can support additional capabilities/details)
>
> Is this reasonably accurate?
>
>> many thanks
>> david jencks
>>
>>
>>
>>
>>
>>> In your alternate reality you could turn your maven repos in one big
>>> federated OSGi repository and then point the obr bundle to it to
>>> discover and deploy bundles (the obr bundle comes with the default
>>> felix zip - try the obr command in the felix shell).
>>>
>>> Furthermore, we are just proposing a new project to the incubator
>>> which is targeting provisioning:
>>> http://wiki.apache.org/incubator/AceProposal (just in case your
>>> interested).
>>>
>>> Finally, there is a provisioning solution from eclipse as well. Called
>>> p2 (http://wiki.eclipse.org/Equinox_p2_Getting_Started).
>>>
>>> regards,
>>>
>>> Karl
>>>
>>> On Mon, Apr 6, 2009 at 11:19 PM, David Jencks<da...@yahoo.com>
>>> wrote:
>>>
>>>
>>>> Lets suppose we were in an alternate reality in which every artifact in
>>>> maven repos was a correctly configured osgi bundle, using imports and
>>>> exports rather than require-bundle.
>>>>
>>>> Now suppose I've downloaded all the bundles locally and have fired up
>>>> osgi
>>>> so it can see all of them.
>>>>
>>>> Now I try to load a bundle that imports some classes that are available
>>>> from
>>>> several bundles, say the geronimo, sun, and tomcat servlet 2.5 spec jars,
>>>> or
>>>> perhaps the slf4j interface classes.
>>>>
>>>> What facilities does osgi or felix provide to help decide which bundle
>>>> will
>>>> be selected to provide these classes?
>>>>
>>>>
>>>> -background--
>>>>
>>>> We're looking at using osgi in Geronimo. Currently we have a
>>>> classloading
>>>> system with most of the capabilities of the osgi classloading model but
>>>> oriented more towards maven metadata. Each geronimo specific artifact
>>>> has
>>>> some dependency metadata like maven dependencies that specify most of the
>>>> classloader, and you can tweak it with filters to emulate the
>>>> import/export
>>>> conditions in osgi.
>>>>
>>>> Since the (multiple parents) of an artifact are specified as other
>>>> artifacts, its easy, starting with a particular artifact, to pull in all
>>>> its
>>>> dependencies by artifact name and obtain all the pieces that are needed
>>>> to
>>>> run the artifact you are interested in. This is just like maven: you
>>>> specify a dependency in your pom and it and all its transitive
>>>> dependencies
>>>> are automatically downloaded and made available to your build.
>>>>
>>>> Btoh Geronimo and Maven have ways to override the original dependencies
>>>> of
>>>> an artifact and substitute something else.
>>>>
>>>> IIUC in osgi one can use require-bundle to specify dependencies in a
>>>> similar
>>>> way but again IIUC this is highly frowned upon from a theoretical
>>>> perspective and I don't know of any way of overriding require-bundle
>>>> specifications.
>>>>
>>>> So.... is there anything in osgi or felix that provides this kind of
>>>> dependency specification that can be used with import/exports to specify
>>>> specific bundles to satisfy import requirements?
>>>>
>>>> many thanks
>>>> david jencks
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>>>
>>> --
>>> Karl Pauls
>>> karlpauls@gmail.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: Philosophical question on osgi vs maven
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/4/7 David Jencks <da...@yahoo.com>
> Thanks for the response.... could you clarify a couple things inline?
> On Apr 6, 2009, at 2:47 PM, Karl Pauls wrote:
>
> Well, there is OBR which allows you to resolve a given bundle together
>> with the transitive closure over its dependencies based on import and
>> export packages
>> (
>> http://www.osgi.org/Download/File?url=/download/rfc-0112_BundleRepository.pdf
>> ).
>> You can tell the maven bundle plugin to generate an obr repository for
>> you (
>> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html)
>> or use bindex from the OSGi in case you want to create a repository
>> for a set of bundles (http://www.osgi.org/Repository/BIndex).
>>
>
> IIUC a particular OBR repository file is a list of a set of bundles with
> some additional info. There is no requirement that the bundles be related
> in any way or that there is any kind of transitive closure.
>
> The bundle plugin makes it look like the normal relationship between an OBR
> repo file and a maven repo is a single OBR repo file describing everything
> in the repo. So, assuming we had one of these OBR repo files for my
> hypothetical worldwide maven repo, it would do us no good, as would include
> all the bundles that happen to provide some required imports.
but this is the point about the import/export approach - you shouldn't mind
who provides
the imported package(s), as long as they meet the constraints specified by
your bundle.
so in an OBR repository it may well be several bundles can provide the same
package,
in that case it's up to your OBR resolver to decide which bundle to pull in
- this might be
simplistic (ie. take the first match, like in the Felix bundlerepository) or
more complicated
(ie. prefer Apache bundles, or small bundles) - the point is that the OBR
metadata has
all the right information to allow you to decide how to pick'n'choose,
without depending
on a specific named artifact
to see how useful this is, consider extending your application - this might
introduce a new
constraint that conflicts with one of your original "preferred" bundles, and
it might be that
another bundle in the OBR can satisfy both your original and updated
constraints, so this
new bundle gets pulled in and the old one swapped out - this would not be
possible with
named dependencies
(FYI, P2 can also do this and there is an ongoing process to standardize
both approaches)
> On the other hand it would be theoretically possible to come up with an OBR
> repo file that only had one bundle for each import and then there would be
> no more ambiguity. On the other hand this is not automatically extensible:
> since a new artifact doesn't come with its own preferred dependencies, any
> time you add a new artifact you need to update the OBR repo file to mention
> it and any new dependencies it might require.
>
> However, it looks like it would also be possible to turn each maven pom
> into an obr repo file and store it next to the maven artifact. Starting
> with one particular bundle you could look at its repo file, find the repo
> files for each bundle mentioned therein, and come up with the transitive
> closure. This seems like the same process maven uses for transitive
> dependencies. As with maven, it's extensible. Since there are a lot of
> unrelated trees glued together it would be pretty easy to come up with 2
> bundles specified as providing the same package. However it would be pretty
> easy to use something like a "prefer closer to root" policy to resolve these
> conflicts and provide a way to override or correct ancestor's choices.
>
this would effectively be the same as Require-Bundle, and just as fragile
imho
if you wanted a "prefer closer to root" policy then that would probably be
possible
with a single OBR file, you'd just have to find a way to encode that
information in
the additional metadata included alongside each bundle entry (OBR is
extensible
and can support additional capabilities/details)
Is this reasonably accurate?
>
> many thanks
> david jencks
>
>
>
>
>>
>> In your alternate reality you could turn your maven repos in one big
>> federated OSGi repository and then point the obr bundle to it to
>> discover and deploy bundles (the obr bundle comes with the default
>> felix zip - try the obr command in the felix shell).
>>
>> Furthermore, we are just proposing a new project to the incubator
>> which is targeting provisioning:
>> http://wiki.apache.org/incubator/AceProposal (just in case your
>> interested).
>>
>> Finally, there is a provisioning solution from eclipse as well. Called
>> p2 (http://wiki.eclipse.org/Equinox_p2_Getting_Started).
>>
>> regards,
>>
>> Karl
>>
>> On Mon, Apr 6, 2009 at 11:19 PM, David Jencks <da...@yahoo.com>
>> wrote:
>>
>>> Lets suppose we were in an alternate reality in which every artifact in
>>> maven repos was a correctly configured osgi bundle, using imports and
>>> exports rather than require-bundle.
>>>
>>> Now suppose I've downloaded all the bundles locally and have fired up
>>> osgi
>>> so it can see all of them.
>>>
>>> Now I try to load a bundle that imports some classes that are available
>>> from
>>> several bundles, say the geronimo, sun, and tomcat servlet 2.5 spec jars,
>>> or
>>> perhaps the slf4j interface classes.
>>>
>>> What facilities does osgi or felix provide to help decide which bundle
>>> will
>>> be selected to provide these classes?
>>>
>>>
>>> -background--
>>>
>>> We're looking at using osgi in Geronimo. Currently we have a
>>> classloading
>>> system with most of the capabilities of the osgi classloading model but
>>> oriented more towards maven metadata. Each geronimo specific artifact
>>> has
>>> some dependency metadata like maven dependencies that specify most of the
>>> classloader, and you can tweak it with filters to emulate the
>>> import/export
>>> conditions in osgi.
>>>
>>> Since the (multiple parents) of an artifact are specified as other
>>> artifacts, its easy, starting with a particular artifact, to pull in all
>>> its
>>> dependencies by artifact name and obtain all the pieces that are needed
>>> to
>>> run the artifact you are interested in. This is just like maven: you
>>> specify a dependency in your pom and it and all its transitive
>>> dependencies
>>> are automatically downloaded and made available to your build.
>>>
>>> Btoh Geronimo and Maven have ways to override the original dependencies
>>> of
>>> an artifact and substitute something else.
>>>
>>> IIUC in osgi one can use require-bundle to specify dependencies in a
>>> similar
>>> way but again IIUC this is highly frowned upon from a theoretical
>>> perspective and I don't know of any way of overriding require-bundle
>>> specifications.
>>>
>>> So.... is there anything in osgi or felix that provides this kind of
>>> dependency specification that can be used with import/exports to specify
>>> specific bundles to satisfy import requirements?
>>>
>>> many thanks
>>> david jencks
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.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
>
>
--
Cheers, Stuart
Re: Philosophical question on osgi vs maven
Posted by David Jencks <da...@yahoo.com>.
Thanks for the response.... could you clarify a couple things inline?
On Apr 6, 2009, at 2:47 PM, Karl Pauls wrote:
> Well, there is OBR which allows you to resolve a given bundle together
> with the transitive closure over its dependencies based on import and
> export packages
> (http://www.osgi.org/Download/File?url=/download/rfc-0112_BundleRepository.pdf
> ).
> You can tell the maven bundle plugin to generate an obr repository for
> you (
> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-
> bnd.html)
> or use bindex from the OSGi in case you want to create a repository
> for a set of bundles (http://www.osgi.org/Repository/BIndex).
IIUC a particular OBR repository file is a list of a set of bundles
with some additional info. There is no requirement that the bundles
be related in any way or that there is any kind of transitive closure.
The bundle plugin makes it look like the normal relationship between
an OBR repo file and a maven repo is a single OBR repo file describing
everything in the repo. So, assuming we had one of these OBR repo
files for my hypothetical worldwide maven repo, it would do us no
good, as would include all the bundles that happen to provide some
required imports. On the other hand it would be theoretically
possible to come up with an OBR repo file that only had one bundle for
each import and then there would be no more ambiguity. On the other
hand this is not automatically extensible: since a new artifact
doesn't come with its own preferred dependencies, any time you add a
new artifact you need to update the OBR repo file to mention it and
any new dependencies it might require.
However, it looks like it would also be possible to turn each maven
pom into an obr repo file and store it next to the maven artifact.
Starting with one particular bundle you could look at its repo file,
find the repo files for each bundle mentioned therein, and come up
with the transitive closure. This seems like the same process maven
uses for transitive dependencies. As with maven, it's extensible.
Since there are a lot of unrelated trees glued together it would be
pretty easy to come up with 2 bundles specified as providing the same
package. However it would be pretty easy to use something like a
"prefer closer to root" policy to resolve these conflicts and provide
a way to override or correct ancestor's choices.
Is this reasonably accurate?
many thanks
david jencks
>
>
> In your alternate reality you could turn your maven repos in one big
> federated OSGi repository and then point the obr bundle to it to
> discover and deploy bundles (the obr bundle comes with the default
> felix zip - try the obr command in the felix shell).
>
> Furthermore, we are just proposing a new project to the incubator
> which is targeting provisioning:
> http://wiki.apache.org/incubator/AceProposal (just in case your
> interested).
>
> Finally, there is a provisioning solution from eclipse as well. Called
> p2 (http://wiki.eclipse.org/Equinox_p2_Getting_Started).
>
> regards,
>
> Karl
>
> On Mon, Apr 6, 2009 at 11:19 PM, David Jencks
> <da...@yahoo.com> wrote:
>> Lets suppose we were in an alternate reality in which every
>> artifact in
>> maven repos was a correctly configured osgi bundle, using imports and
>> exports rather than require-bundle.
>>
>> Now suppose I've downloaded all the bundles locally and have fired
>> up osgi
>> so it can see all of them.
>>
>> Now I try to load a bundle that imports some classes that are
>> available from
>> several bundles, say the geronimo, sun, and tomcat servlet 2.5 spec
>> jars, or
>> perhaps the slf4j interface classes.
>>
>> What facilities does osgi or felix provide to help decide which
>> bundle will
>> be selected to provide these classes?
>>
>>
>> -background--
>>
>> We're looking at using osgi in Geronimo. Currently we have a
>> classloading
>> system with most of the capabilities of the osgi classloading model
>> but
>> oriented more towards maven metadata. Each geronimo specific
>> artifact has
>> some dependency metadata like maven dependencies that specify most
>> of the
>> classloader, and you can tweak it with filters to emulate the
>> import/export
>> conditions in osgi.
>>
>> Since the (multiple parents) of an artifact are specified as other
>> artifacts, its easy, starting with a particular artifact, to pull
>> in all its
>> dependencies by artifact name and obtain all the pieces that are
>> needed to
>> run the artifact you are interested in. This is just like maven: you
>> specify a dependency in your pom and it and all its transitive
>> dependencies
>> are automatically downloaded and made available to your build.
>>
>> Btoh Geronimo and Maven have ways to override the original
>> dependencies of
>> an artifact and substitute something else.
>>
>> IIUC in osgi one can use require-bundle to specify dependencies in
>> a similar
>> way but again IIUC this is highly frowned upon from a theoretical
>> perspective and I don't know of any way of overriding require-bundle
>> specifications.
>>
>> So.... is there anything in osgi or felix that provides this kind of
>> dependency specification that can be used with import/exports to
>> specify
>> specific bundles to satisfy import requirements?
>>
>> many thanks
>> david jencks
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.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: Philosophical question on osgi vs maven
Posted by Karl Pauls <ka...@gmail.com>.
Well, there is OBR which allows you to resolve a given bundle together
with the transitive closure over its dependencies based on import and
export packages
(http://www.osgi.org/Download/File?url=/download/rfc-0112_BundleRepository.pdf).
You can tell the maven bundle plugin to generate an obr repository for
you (
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html)
or use bindex from the OSGi in case you want to create a repository
for a set of bundles (http://www.osgi.org/Repository/BIndex).
In your alternate reality you could turn your maven repos in one big
federated OSGi repository and then point the obr bundle to it to
discover and deploy bundles (the obr bundle comes with the default
felix zip - try the obr command in the felix shell).
Furthermore, we are just proposing a new project to the incubator
which is targeting provisioning:
http://wiki.apache.org/incubator/AceProposal (just in case your
interested).
Finally, there is a provisioning solution from eclipse as well. Called
p2 (http://wiki.eclipse.org/Equinox_p2_Getting_Started).
regards,
Karl
On Mon, Apr 6, 2009 at 11:19 PM, David Jencks <da...@yahoo.com> wrote:
> Lets suppose we were in an alternate reality in which every artifact in
> maven repos was a correctly configured osgi bundle, using imports and
> exports rather than require-bundle.
>
> Now suppose I've downloaded all the bundles locally and have fired up osgi
> so it can see all of them.
>
> Now I try to load a bundle that imports some classes that are available from
> several bundles, say the geronimo, sun, and tomcat servlet 2.5 spec jars, or
> perhaps the slf4j interface classes.
>
> What facilities does osgi or felix provide to help decide which bundle will
> be selected to provide these classes?
>
>
> -background--
>
> We're looking at using osgi in Geronimo. Currently we have a classloading
> system with most of the capabilities of the osgi classloading model but
> oriented more towards maven metadata. Each geronimo specific artifact has
> some dependency metadata like maven dependencies that specify most of the
> classloader, and you can tweak it with filters to emulate the import/export
> conditions in osgi.
>
> Since the (multiple parents) of an artifact are specified as other
> artifacts, its easy, starting with a particular artifact, to pull in all its
> dependencies by artifact name and obtain all the pieces that are needed to
> run the artifact you are interested in. This is just like maven: you
> specify a dependency in your pom and it and all its transitive dependencies
> are automatically downloaded and made available to your build.
>
> Btoh Geronimo and Maven have ways to override the original dependencies of
> an artifact and substitute something else.
>
> IIUC in osgi one can use require-bundle to specify dependencies in a similar
> way but again IIUC this is highly frowned upon from a theoretical
> perspective and I don't know of any way of overriding require-bundle
> specifications.
>
> So.... is there anything in osgi or felix that provides this kind of
> dependency specification that can be used with import/exports to specify
> specific bundles to satisfy import requirements?
>
> many thanks
> david jencks
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Philosophical question on osgi vs maven
Posted by Alin Dreghiciu <ad...@gmail.com>.
I guess that OBR using an repository xml (metadata about bundles)
generated out of the maven artifacts from a maven repo (or more
federated repositories) can satisfy your requirements. And Jason van
Zyl (Sonatype) was talking lately about OBR repository support in
Nexus = automatically generate the metadata regarding OSGi artifacts
out of artifacts available in a repository.
On Tue, Apr 7, 2009 at 12:19 AM, David Jencks <da...@yahoo.com> wrote:
> Lets suppose we were in an alternate reality in which every artifact in
> maven repos was a correctly configured osgi bundle, using imports and
> exports rather than require-bundle.
>
> Now suppose I've downloaded all the bundles locally and have fired up osgi
> so it can see all of them.
>
> Now I try to load a bundle that imports some classes that are available from
> several bundles, say the geronimo, sun, and tomcat servlet 2.5 spec jars, or
> perhaps the slf4j interface classes.
>
> What facilities does osgi or felix provide to help decide which bundle will
> be selected to provide these classes?
>
>
> -background--
>
> We're looking at using osgi in Geronimo. Currently we have a classloading
> system with most of the capabilities of the osgi classloading model but
> oriented more towards maven metadata. Each geronimo specific artifact has
> some dependency metadata like maven dependencies that specify most of the
> classloader, and you can tweak it with filters to emulate the import/export
> conditions in osgi.
>
> Since the (multiple parents) of an artifact are specified as other
> artifacts, its easy, starting with a particular artifact, to pull in all its
> dependencies by artifact name and obtain all the pieces that are needed to
> run the artifact you are interested in. This is just like maven: you
> specify a dependency in your pom and it and all its transitive dependencies
> are automatically downloaded and made available to your build.
>
> Btoh Geronimo and Maven have ways to override the original dependencies of
> an artifact and substitute something else.
>
> IIUC in osgi one can use require-bundle to specify dependencies in a similar
> way but again IIUC this is highly frowned upon from a theoretical
> perspective and I don't know of any way of overriding require-bundle
> specifications.
>
> So.... is there anything in osgi or felix that provides this kind of
> dependency specification that can be used with import/exports to specify
> specific bundles to satisfy import requirements?
>
> many thanks
> david jencks
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Alin Dreghiciu
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.
Looking for a job.
Sent from Cluj-Napoca, CJ, Romania
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org