felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: [DISCUSS] Default osgi manifest for maven-bundle-plugin
Date Tue, 16 Nov 2010 10:35:58 GMT
On 11/16/10 4:47, Guillaume Nodet wrote:
> On Tue, Nov 16, 2010 at 10:22, Richard S. Hall<heavy@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.

A version that changes for no apparent reason isn't really a version either.

> 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.

You can do that using bundle-version too.

> 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.

We do support it, but you are talking about making it the default. That 
is promoting it.

> 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.

Well, if the prereq assumption is that package version == bundle 
version, then yeah it might not be good. But it seems it could be 
independent of that.

>>> 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.

As far as auto-generated versions, I agree, but bundle-version can be 
used for all packages. Maybe we just need an option to automatically add 
bundle-version for people who want to use this approach.

>>> 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.

I'm fine for devising a mechanism to make it easier to use such an 
approach. But the reality is you are abusing package version to be 
bundle version. As I said above, it seems like the mechanism we need is 
to auto-generate import metadata to include bundle-version instead of 
version, then you have what you want and people wanting this approach 
don't have to worry about package versions at all.

> 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.

Yeah, I don't have an issue with that.

-> richard

>>> Also maybe a different profile to package an existing jar into a
>>> bundle more easily would be good too.
>> Possibly.
>> ->  richard
>>> THoughts ?

View raw message