On Tue, Nov 16, 2010 at 10:22, Richard S. Hall <he...@ungoverned.org> wrote:
> On 11/16/10 4:07, Guillaume Nodet wrote:
>>
>> I'd like to improve the maven bundle plugin to make it very easy to
>> actually create good bundles for people that have had limited exposure
>> to OSGi.
>> I think in such cases, we should have something like the following:
>> * export all the packages from the src/main/java (this is done by
>> default by the plugin if nothing is specified, but there's no way to
>> add things without having to list all the packages again)
>
> Not sure what you are proposing here, since it already is the default as you
> mention. Are you proposing some sort of macro to specify "export all" ?
>
>> * use the pom version for the version of the exported packages
>
> I don't think this is a good idea. You might as well just set them all to
> 0.0.0, since it is about as meaningful. The bundle-version attribute is
> already added implicitly, so if someone wants to use the bundle version they
> already can.
I disagree. A version that never chagnes is not really a version. At
least, if you put the bundle version, you can use version ranges and
make sure you have some idea about what you're importing. Most of the
projects i've seen, or all the re-packaged jars, use the bundle
version as the package version, so, even if it's not the best way of
doing versioning, that's something that people use and which is much
better than nothing at all. I think we should support them if they
want to use that.
Actually, I think sling is the only project i've seen where the
package version is not the bundle version, not to say, that everyone's
right, but that's the way people use it now, and in all the projects
i've seen, people are not osgi experts and they do not necessarily
want to spend much time on it, so having to specify a different
version for each package is not something they'll do.
>
>> * do not import exported packages by default (most of the projects
>> i've worked with do not use api + impl in the same bundle)
>
> You should experiment with the snapshot, since I integrated the latest bnd
> that attempts to do a better job at figuring this out.
I'll try that and see how it works.
>
>> * use default version ranges for third party libraries
>> * use a stricter version range for packages imported from the same
>> build (i.e. if you have two bundles build in the same build, they will
>> import packages using a stricter version range)
>
> I'm not sure one way or the other...maybe need some examples.
I'm sure you'll disagree, because it's related to package versioning.
Let's assume that the project uses package version = bundle version.
Packages in a big multi-bundle project are usually a bit more tied than
when you use a third party library, so having a tighter version range
makes sense.
But that's not really a problem as it can be done already, just not as
easily as I think it should.
>> Before you try to shoot me down, I do understand this is not the best
>> way to create bundles, and ideally, the version of the packages would
>> be different than the overall version of the system, but I think a lot
>> of projects aren't prepared to have OSGi have such a big impact on
>> their code (as OSGi is for them a side thing). So for those, I'd
>> still like to have a set of defaults that works better than the
>> current default (which has no version on the packages, does not use
>> version ranges, etc...).
>
> As I said above, they already have the bundle version, so I don't really see
> the value in adding the bundle version again, but as the package version.
That's because when you import a package, you specify the package
version, not the bundle version, and that's also what bnd uses to
compute the version range from maven dependencies. So if all the
package versions are 0, there's no versioning at all.
>
>> I'm not sure how to do that yet, maybe having a simple option that
>> activate different profiles if people think this should not be the
>> overall defaults. I haven't given much thoughts about the technical
>> aspect yet, but I do think we should make it easier to package OSGi
>> bundles.
>
> I agree that we should generate better bundles by default. The new bnd helps
> in some cases. I think the most controversial aspect is the default package
> version, which I'd argue against.
Then, we should let the user decide and have an easy option to turn
that the way the user want. I'm talking here about making users life
easier, not enforcing best practices.
The problems comes from the fact that the bundle plugin has no simple
way to specify defaults.
For example, if you specify don't specify the <Export-Packages>
instruction, all the local packages will be imported / exported.
If you want to not import them, you can't use
<Export-Pacakge>*;-noimport:=true</Export-Package>
as this will then export all the packages, not only the local ones.
Same for the version.
At least, something like
<Export-Pacakge>{local};-noimport:=true</Export-Pacakge>
would help a lot, as this would avoid having to list all the packages
in each pom.
>
>> Also maybe a different profile to package an existing jar into a
>> bundle more easily would be good too.
>
> Possibly.
>
> -> richard
>
>> THoughts ?
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
