I've been wanting to add a feature to bnd for a long time that does something
like this. This would be a selector for the export-package/private-package.
Like:
Export-Package: classes:*;version=...
Because target/main/classes is on the class path, this will match and only do
the export packages relative to the classes directory.
Alternatively, this also achieves the same goal today:
Include-Resource: target/main/classes
-exportcontents: *; version=...;-noimport:=true
Kind regards,
Peter Kriens
On 16 nov 2010, at 13:26, Guillaume Nodet wrote:
> {local-packages} looks good to me.
> I'll try to add that asap.
>
> On Tue, Nov 16, 2010 at 12:30, Stuart McCulloch <mccu...@gmail.com> wrote:
>> On 16 November 2010 11:07, Guillaume Nodet <gno...@gmail.com> wrote:
>>
>>> I'll reiterate the goal I had in mind here.
>>>
>>> The goal is to make an existing non-osgi project produce the best
>>> possible osgi bundles instead of jars without any change in the
>>> packaging or the versioning of the jars themselves (as those will
>>> still be used in non-osgi environement). I'm just in the process of
>>> doing that once again for another project (abdera). So anything that
>>> require changing the code is ruled out at this point, so things like
>>> cleanly separating the api from the implementation is not a
>>> possibility here.
>>>
>>> The goal is to make the project being able to be consumed in OSGi.
>>> Additional refactoring could be done after that to start following
>>> best practices, but that's not my point. So that's really my goal:
>>> do not touch a single line of code and make things easy for people to
>>> use, this means the maven bundle plugin should mostly figure out
>>> everything using defaults.
>>>
>>> Actually, I think the {local} thing should be sufficient as I could
>>> specifiy the defaults I want in the root pom and have it inherited,
>>>
>>
>> yes, once the local set of packages is available in a property then you
>> could always use:
>>
>>
>>
>> <Export-Package>{local-packages};version="${project.version}"</Export-Package>
>>
>> although the code to expand {local-packages} in the plugin would need to be
>> intelligent
>> enough to add all the attached attributes to each clause in the expanded
>> package list
>>
>> PS. using {local-packages} is imho a more descriptive name than just {local}
>>
>> --
>> Cheers, Stuart
>>
>>
>>> but then, those defaults could be available using a single maven
>>> bundle switch to help people. That would mean turning plain jars into
>>> (not completely screwed) osgi bundles would require mostly no osgi
>>> knowledge and only adding a snippet of code in the root pom and change
>>> the packaging to bundle (even maybe that's not required).
>>>
>>> That's really my goal, help non-osgi aware projects produce osgi
>>> bundles to avoid having to repackage all the jars as we do in
>>> servicemix or as spring-source does.
>>>
>>> That said, comments below...
>>>
>>> On Tue, Nov 16, 2010 at 11:41, Marcel Offermans
>>> <marcel.offerm...@luminis.nl> wrote:
>>>> 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.
>>>
>>> As I said, you gain the ability to use that project in an osgi
>>> environment, that's already a lot.
>>>
>>>>
>>>>>>> * 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.
>>>
>>> The thing is the bundle-version is hardly used at all. And yeah,
>>> option 2 is close to monolithic deployment, when that's not really a
>>> problem. A workaround is what i tried to explain earlier: use a
>>> stricter version range for the import package within such a
>>> deployment. That allows deploying bug fix bundles.
>>> Again, it's not best practices, but that's something that non osgi
>>> people can deal with easily.
>>>
>>>>
>>>>> 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.
>>>
>>> That's exactly my point. Most of the projects i've been involved in
>>> are not OSGi centric, meaning the team there don't know much about
>>> OSGi. They need something that's easy to use and maintain (meaning
>>> mostly no maintenance). So it's just here about enabling downstream
>>> users to use the project in osgi.
>>> Over time, osgi things can kick in and refactoring can be done in
>>> major versions, but that's a slow process.
>>>
>>>>
>>>>>>> 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.
>>>
>>> Again, it would be easy to document that those are not best practices,
>>> but a simple way to have usable osgi bundles. That's why I proposed
>>> having maybe some kind of profile in the maven bundle plugin to have a
>>> different set of defaults that could suit that needs.
>>>
>>>>> 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
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
