You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Peter Kriens <Pe...@aQute.biz> on 2007/02/01 09:06:40 UTC
Re[2]: Improving integration between maven and osgi
CS> afaik the current status of the bundle plugin doesn't read pom
CS> dependencies to generate the import-packages but the imports in the
CS> classes. The only thing used from the pom if not explicitly configured
CS> is the Maven generated classpath, am I wrong?
The plugin uses the classpath as defined by the POM file. From this
classpath, you can define what you want to include (Private-Package
and Export-Package). This contained set of classes is then parsed for
references. References that can not be found in the Private/Export set
are then turned in imports.
This model significantly reduces the dependencies.
Kind regards,
Peter Kriens
CS> On 1/31/07, Richard S. Hall <he...@ungoverned.org> wrote:
>> Carlos Sanchez wrote:
>> > Hi all,
>> >
>> > I'm trying to make maven generate OSGi bundles based in the information
>> > of the pom as much as possible. That implies generating "Require-bundle"
>> > headers based on the dependencies section of the pom instead of
>> > autodiscovered "Import-packages".
>> >
>> > I'd take groupId.artifactId as bundle name and dependency version as
>> > bundle version.
>> >
>> > In the future this could be the standard for any jar generated by Maven.
>> >
>> > It will assume that dependencies are already available as OSGi bundles,
>> > although I'm working on a recursive mode that will generate
>> > one bundle for each dependency scanning the whole tree of transitive
>> > dependencies.
>> >
>> > Please let me know if this sounds right for the maven-bundle-plugin.
>> > Any comments appreciated ;)
>>
>> I'm of two minds on this...
>>
>> 1. I think that use of require-bundle should be discouraged as a
>> general mechanism, since it creates brittle systems and has odd
>> side effects.
CS> the reason i heard to discourage require-bundle was that only specific
CS> packages of a bundle may be needed. Maven encourages splitting big
CS> projects into reusable components so you usually end with few packages
CS> in each bundle, being pretty close to the import-packages is.
>> 2. I admit that if we want to support require-bundle at all,
>> maven-bundle-plugin is probably the place to put it.
>>
>> In general, I do not have a goal to get OSGi bundle developers
>> integrating more tightly with Maven, since Maven's dependency model is
>> not as sophisticated as OSGi's. I prefer to find ways to make it easier
>> to follow OSGi best practices, than Maven best practices.
CS> the point is to compliment both by easily generating OSGi bundles from
CS> any Maven project.
>>
>> Ultimately, except for split packages, you can mimic require-bundle
>> fairly nicely with the existing plugin by exporting all project packages
>> and importing everything else, which is essentially what Peter was
>> trying to work with Jason van Zyl on previously. This can be done to
>> achieve a similar level of integration with Maven as proposed without
>> any additional information other than what is in the pom too. So,
>> explicit support for require-bundle may not really be necessary.
CS> afaik the current status of the bundle plugin doesn't read pom
CS> dependencies to generate the import-packages but the imports in the
CS> classes. The only thing used from the pom if not explicitly configured
CS> is the Maven generated classpath, am I wrong?
>>
>> -> richard
>>
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Improving integration between maven and osgi
Posted by "John E. Conlon" <jc...@verticon.com>.
Carlos Sanchez wrote:
> the version needs to be had into account for sure to avoid conflicts.
Versions are a good thing. I will defer to Richard or Peter as to what
they would consider the best approach to autoset this value to.
> I know import-package syntax is like
> Import-Package: com.mypackage;version="1.0.0"
Yes, Import-Package can also take version ranges as well.
Import-Package: com.mypackage;version="[1,1.1)"
which means that versions 1.0.0 to versions less than 1.1 will match.
(In other words that import would just match any 1.0.x version export)
>
> do I need to explicitly set the version for export-package or will
> osgi take it from Bundle-Version?
Well sort of... Exported packages are associated with the
bundle-symbolic-name and the bundle-version by the framework. So imports
can also set these attributes for wiring. The value of the
bundle-version may or may not be the same as package's versions though.
John
>
> On 2/1/07, John E. Conlon <jc...@verticon.com> wrote:
>> Hi Carlos,
>>
>> So you will label a bundles exports with the version of the jar and
>> label the bundles import versions with the versions of the dep jars?
>>
>> John
>>
>> Carlos Sanchez wrote:
>> > A very important step that is not there yet is the version in the
>> > import-packages, it's very different to depend on commons-logging 1.0
>> > than 1.1
>> > It'd be easier to do it with Require-Bundle but as everybody seems to
>> > agree in using Import-Packages I'll try to generate them finding what
>> > Maven dependency provides that package and then get the version.
>> >
>> > On 2/1/07, Peter Kriens <Pe...@aqute.biz> wrote:
>> >> CS> afaik the current status of the bundle plugin doesn't read pom
>> >> CS> dependencies to generate the import-packages but the imports
>> in the
>> >> CS> classes. The only thing used from the pom if not explicitly
>> >> configured
>> >> CS> is the Maven generated classpath, am I wrong?
>> >> The plugin uses the classpath as defined by the POM file. From this
>> >> classpath, you can define what you want to include (Private-Package
>> >> and Export-Package). This contained set of classes is then parsed for
>> >> references. References that can not be found in the Private/Export
>> set
>> >> are then turned in imports.
>> >>
>> >> This model significantly reduces the dependencies.
>> >>
>> >> Kind regards,
>> >>
>> >> Peter Kriens
>> >>
>> >>
>> >> CS> On 1/31/07, Richard S. Hall <he...@ungoverned.org> wrote:
>> >> >> Carlos Sanchez wrote:
>> >> >> > Hi all,
>> >> >> >
>> >> >> > I'm trying to make maven generate OSGi bundles based in the
>> >> information
>> >> >> > of the pom as much as possible. That implies generating
>> >> "Require-bundle"
>> >> >> > headers based on the dependencies section of the pom instead of
>> >> >> > autodiscovered "Import-packages".
>> >> >> >
>> >> >> > I'd take groupId.artifactId as bundle name and dependency
>> >> version as
>> >> >> > bundle version.
>> >> >> >
>> >> >> > In the future this could be the standard for any jar generated
>> >> by Maven.
>> >> >> >
>> >> >> > It will assume that dependencies are already available as OSGi
>> >> bundles,
>> >> >> > although I'm working on a recursive mode that will generate
>> >> >> > one bundle for each dependency scanning the whole tree of
>> >> transitive
>> >> >> > dependencies.
>> >> >> >
>> >> >> > Please let me know if this sounds right for the
>> >> maven-bundle-plugin.
>> >> >> > Any comments appreciated ;)
>> >> >>
>> >> >> I'm of two minds on this...
>> >> >>
>> >> >> 1. I think that use of require-bundle should be discouraged
>> as a
>> >> >> general mechanism, since it creates brittle systems and
>> has odd
>> >> >> side effects.
>> >>
>> >> CS> the reason i heard to discourage require-bundle was that only
>> >> specific
>> >> CS> packages of a bundle may be needed. Maven encourages splitting
>> big
>> >> CS> projects into reusable components so you usually end with few
>> >> packages
>> >> CS> in each bundle, being pretty close to the import-packages is.
>> >>
>> >> >> 2. I admit that if we want to support require-bundle at all,
>> >> >> maven-bundle-plugin is probably the place to put it.
>> >> >>
>> >> >> In general, I do not have a goal to get OSGi bundle developers
>> >> >> integrating more tightly with Maven, since Maven's dependency
>> >> model is
>> >> >> not as sophisticated as OSGi's. I prefer to find ways to make it
>> >> easier
>> >> >> to follow OSGi best practices, than Maven best practices.
>> >>
>> >> CS> the point is to compliment both by easily generating OSGi bundles
>> >> from
>> >> CS> any Maven project.
>> >>
>> >> >>
>> >> >> Ultimately, except for split packages, you can mimic
>> require-bundle
>> >> >> fairly nicely with the existing plugin by exporting all project
>> >> packages
>> >> >> and importing everything else, which is essentially what Peter was
>> >> >> trying to work with Jason van Zyl on previously. This can be
>> done to
>> >> >> achieve a similar level of integration with Maven as proposed
>> without
>> >> >> any additional information other than what is in the pom too. So,
>> >> >> explicit support for require-bundle may not really be necessary.
>> >>
>> >> CS> afaik the current status of the bundle plugin doesn't read pom
>> >> CS> dependencies to generate the import-packages but the imports
>> in the
>> >> CS> classes. The only thing used from the pom if not explicitly
>> >> configured
>> >> CS> is the Maven generated classpath, am I wrong?
>> >>
>> >> >>
>> >> >> -> richard
>> >> >>
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Peter Kriens Tel +33467542167
>> >> 9C, Avenue St. Drézéry AOL,Yahoo: pkriens
>> >> 34160 Beaulieu, France ICQ 255570717
>> >> Skype pkriens Fax +1 8153772599
>> >>
>> >>
>> >
>> >
>>
>>
>
>
Re: Improving integration between maven and osgi
Posted by "John E. Conlon" <jc...@verticon.com>.
Hi Carlos,
So you will label a bundles exports with the version of the jar and
label the bundles import versions with the versions of the dep jars?
John
Carlos Sanchez wrote:
> A very important step that is not there yet is the version in the
> import-packages, it's very different to depend on commons-logging 1.0
> than 1.1
> It'd be easier to do it with Require-Bundle but as everybody seems to
> agree in using Import-Packages I'll try to generate them finding what
> Maven dependency provides that package and then get the version.
>
> On 2/1/07, Peter Kriens <Pe...@aqute.biz> wrote:
>> CS> afaik the current status of the bundle plugin doesn't read pom
>> CS> dependencies to generate the import-packages but the imports in the
>> CS> classes. The only thing used from the pom if not explicitly
>> configured
>> CS> is the Maven generated classpath, am I wrong?
>> The plugin uses the classpath as defined by the POM file. From this
>> classpath, you can define what you want to include (Private-Package
>> and Export-Package). This contained set of classes is then parsed for
>> references. References that can not be found in the Private/Export set
>> are then turned in imports.
>>
>> This model significantly reduces the dependencies.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>> CS> On 1/31/07, Richard S. Hall <he...@ungoverned.org> wrote:
>> >> Carlos Sanchez wrote:
>> >> > Hi all,
>> >> >
>> >> > I'm trying to make maven generate OSGi bundles based in the
>> information
>> >> > of the pom as much as possible. That implies generating
>> "Require-bundle"
>> >> > headers based on the dependencies section of the pom instead of
>> >> > autodiscovered "Import-packages".
>> >> >
>> >> > I'd take groupId.artifactId as bundle name and dependency
>> version as
>> >> > bundle version.
>> >> >
>> >> > In the future this could be the standard for any jar generated
>> by Maven.
>> >> >
>> >> > It will assume that dependencies are already available as OSGi
>> bundles,
>> >> > although I'm working on a recursive mode that will generate
>> >> > one bundle for each dependency scanning the whole tree of
>> transitive
>> >> > dependencies.
>> >> >
>> >> > Please let me know if this sounds right for the
>> maven-bundle-plugin.
>> >> > Any comments appreciated ;)
>> >>
>> >> I'm of two minds on this...
>> >>
>> >> 1. I think that use of require-bundle should be discouraged as a
>> >> general mechanism, since it creates brittle systems and has odd
>> >> side effects.
>>
>> CS> the reason i heard to discourage require-bundle was that only
>> specific
>> CS> packages of a bundle may be needed. Maven encourages splitting big
>> CS> projects into reusable components so you usually end with few
>> packages
>> CS> in each bundle, being pretty close to the import-packages is.
>>
>> >> 2. I admit that if we want to support require-bundle at all,
>> >> maven-bundle-plugin is probably the place to put it.
>> >>
>> >> In general, I do not have a goal to get OSGi bundle developers
>> >> integrating more tightly with Maven, since Maven's dependency
>> model is
>> >> not as sophisticated as OSGi's. I prefer to find ways to make it
>> easier
>> >> to follow OSGi best practices, than Maven best practices.
>>
>> CS> the point is to compliment both by easily generating OSGi bundles
>> from
>> CS> any Maven project.
>>
>> >>
>> >> Ultimately, except for split packages, you can mimic require-bundle
>> >> fairly nicely with the existing plugin by exporting all project
>> packages
>> >> and importing everything else, which is essentially what Peter was
>> >> trying to work with Jason van Zyl on previously. This can be done to
>> >> achieve a similar level of integration with Maven as proposed without
>> >> any additional information other than what is in the pom too. So,
>> >> explicit support for require-bundle may not really be necessary.
>>
>> CS> afaik the current status of the bundle plugin doesn't read pom
>> CS> dependencies to generate the import-packages but the imports in the
>> CS> classes. The only thing used from the pom if not explicitly
>> configured
>> CS> is the Maven generated classpath, am I wrong?
>>
>> >>
>> >> -> richard
>> >>
>>
>>
>>
>>
>> --
>> Peter Kriens Tel +33467542167
>> 9C, Avenue St. Drézéry AOL,Yahoo: pkriens
>> 34160 Beaulieu, France ICQ 255570717
>> Skype pkriens Fax +1 8153772599
>>
>>
>
>
Re: Re[2]: Improving integration between maven and osgi
Posted by Carlos Sanchez <ca...@apache.org>.
A very important step that is not there yet is the version in the
import-packages, it's very different to depend on commons-logging 1.0
than 1.1
It'd be easier to do it with Require-Bundle but as everybody seems to
agree in using Import-Packages I'll try to generate them finding what
Maven dependency provides that package and then get the version.
On 2/1/07, Peter Kriens <Pe...@aqute.biz> wrote:
> CS> afaik the current status of the bundle plugin doesn't read pom
> CS> dependencies to generate the import-packages but the imports in the
> CS> classes. The only thing used from the pom if not explicitly configured
> CS> is the Maven generated classpath, am I wrong?
> The plugin uses the classpath as defined by the POM file. From this
> classpath, you can define what you want to include (Private-Package
> and Export-Package). This contained set of classes is then parsed for
> references. References that can not be found in the Private/Export set
> are then turned in imports.
>
> This model significantly reduces the dependencies.
>
> Kind regards,
>
> Peter Kriens
>
>
> CS> On 1/31/07, Richard S. Hall <he...@ungoverned.org> wrote:
> >> Carlos Sanchez wrote:
> >> > Hi all,
> >> >
> >> > I'm trying to make maven generate OSGi bundles based in the information
> >> > of the pom as much as possible. That implies generating "Require-bundle"
> >> > headers based on the dependencies section of the pom instead of
> >> > autodiscovered "Import-packages".
> >> >
> >> > I'd take groupId.artifactId as bundle name and dependency version as
> >> > bundle version.
> >> >
> >> > In the future this could be the standard for any jar generated by Maven.
> >> >
> >> > It will assume that dependencies are already available as OSGi bundles,
> >> > although I'm working on a recursive mode that will generate
> >> > one bundle for each dependency scanning the whole tree of transitive
> >> > dependencies.
> >> >
> >> > Please let me know if this sounds right for the maven-bundle-plugin.
> >> > Any comments appreciated ;)
> >>
> >> I'm of two minds on this...
> >>
> >> 1. I think that use of require-bundle should be discouraged as a
> >> general mechanism, since it creates brittle systems and has odd
> >> side effects.
>
> CS> the reason i heard to discourage require-bundle was that only specific
> CS> packages of a bundle may be needed. Maven encourages splitting big
> CS> projects into reusable components so you usually end with few packages
> CS> in each bundle, being pretty close to the import-packages is.
>
> >> 2. I admit that if we want to support require-bundle at all,
> >> maven-bundle-plugin is probably the place to put it.
> >>
> >> In general, I do not have a goal to get OSGi bundle developers
> >> integrating more tightly with Maven, since Maven's dependency model is
> >> not as sophisticated as OSGi's. I prefer to find ways to make it easier
> >> to follow OSGi best practices, than Maven best practices.
>
> CS> the point is to compliment both by easily generating OSGi bundles from
> CS> any Maven project.
>
> >>
> >> Ultimately, except for split packages, you can mimic require-bundle
> >> fairly nicely with the existing plugin by exporting all project packages
> >> and importing everything else, which is essentially what Peter was
> >> trying to work with Jason van Zyl on previously. This can be done to
> >> achieve a similar level of integration with Maven as proposed without
> >> any additional information other than what is in the pom too. So,
> >> explicit support for require-bundle may not really be necessary.
>
> CS> afaik the current status of the bundle plugin doesn't read pom
> CS> dependencies to generate the import-packages but the imports in the
> CS> classes. The only thing used from the pom if not explicitly configured
> CS> is the Maven generated classpath, am I wrong?
>
> >>
> >> -> richard
> >>
>
>
>
>
> --
> Peter Kriens Tel +33467542167
> 9C, Avenue St. Drézéry AOL,Yahoo: pkriens
> 34160 Beaulieu, France ICQ 255570717
> Skype pkriens Fax +1 8153772599
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride