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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>>
>>
>
>
