felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kriens <peter.kri...@aqute.biz>
Subject Re: [DISCUSS] Default osgi manifest for maven-bundle-plugin
Date Tue, 16 Nov 2010 12:40:58 GMT
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 <mcculls@gmail.com> wrote:
>> On 16 November 2010 11:07, Guillaume Nodet <gnodet@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.offermans@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 <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
>>>>>>> actually create good bundles for people that have had limited
>>>>>>> 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
>>> to
>>>>>> 0.0.0, since it is about as meaningful. The bundle-version attribute
>>>>>> 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
>>>>>>> activate different profiles if people think this should not be
>>>>>>> overall defaults.  I haven't given much thoughts about the technical
>>>>>>> aspect yet, but I do think we should make it easier to package
>>>>>>> bundles.
>>>>>> I agree that we should generate better bundles by default. The new
>>> 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

View raw message