Hello Guillaume, On 16 Nov 2010, at 10: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" ?
Actually I think it is a really horrible default to export all packages in a bundle, as it does not promote modularity at all: if all your bundles simply export all their packages, then what did you gain by using OSGi at all? Very little. >>> * 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. So this is really about how to do versioning packages, and basically there are three ways to do it: 1) never bump the version automatically, so you'll stay at 0.0.0 2) always bump the version, regardless of any real changes 3) properly version, only bumping the appropriate part of the version when a change is made I would strongly advise against both 1 and 2, as neither makes much sense to me. Option 1 is obvious, if you do not version your packages and start doing updates of bundles, any non-compatible change in any package will probably break your deployment. Option 2 just means that you are very close to doing monolithic deployments, because if a bundle A gets a new version, and other bundles depend on a package of A, they all need a new version as well. This effect will pretty soon ripple through the whole system. That leaves option 3, which is more work but the only way to go if you really care about modularity and updating only parts of your application at runtime. > 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. I think we might work in different types of projects. All projects I have done did explicitly choose OSGi because of its benefits, and they make an effort to properly use it. Of course all of this does not come for free, but I am wondering if the projects you're involved in really care about the benefits that OSGi brings. If not, why is it being used at all? Yes, properly versioning packages and bundles is not the easiest thing in the world, but it's a crucial part of designing modular applications. Tooling can help (both Eclipse and BndTools already support bytecode analysis tools that help you decide what has changed and what consequences those changes have for your package and bundle versions) but in the end, both exporting and versioning are things you design and that have semantics and will therefore always need some human involvement. >>> 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. Maybe that's what this whole discussion is about: do we promote best practices? You are advocating not to promote them, but instead make versioning as easy as possible. The downside is that you end up with a set of bundles that is tightly coupled and not particularly well designed. Of course the requirements of particular projects will dictate if this is a problem or not, but since Felix is an OSGi implementation we should definitely promote best practices. If users want to use different settings for their projects, I'm sure it's not hard to do, as defaults can always be overridden with other defaults. To deviate from best practices then becomes a conscious choice, which sounds a lot better than the other way round. > The problems comes from the fact that the bundle plugin has no simple > way to specify defaults. That is a valid point, one should be able to override the built-in defaults. Greetings, Marcel
