On 11/16/10 4:47, Guillaume Nodet wrote:
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.
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 ?
