felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sahoo <Sa...@Sun.COM>
Subject Re: Default value for <Private-Package> while using maven bundle plugin
Date Tue, 17 Feb 2009 07:52:21 GMT
Stuart McCulloch wrote:
> 2009/2/17 Sahoo <Sahoo@sun.com>
>> Stuart McCulloch wrote:
>>> The latest 1.5.0-SNAPSHOT now sets the default Export-Package /
>>> Private-Package based on the actual project source (if you set _either_
>>> Export-Package or Private-Package then these defaults are not used).
>>> The distribution of packages is as follows: all packages with source files
>>> (ie. *.java) in the current project are exported, except for packages with
>>> "impl" or "internal" or the default package (".") which are kept as
>>> private.
>> I think it will be better not to have any default value for Export-Package.
>> If we can't break backward compatibility, then let's just retain the default
>> value of Export-Package and introduce a new rule for Private-Package which
>> would be that everything in the project source that's not already part of
>> Export-Package.
> the next release of the bundleplugin (which I've decided will be 2.0.0)
> will not be 100% backward compatible, because we're now passing
> the complete classpath to the Bnd Tool - we're also adjusting some
> defaults to make it easier for non-OSGi projects to migrate to OSGi.
OK, point noted about compatibility.
> having no default value for Export-Package in the bundleplugin means
> Bnd would use its own default ("*") - ALL classes on the classpath would
> then be sucked into the bundle, which I don't think is what people expect
> as they'd end up with huge bundles containing every single dependency
> picked up by Maven (even if some are actually already bundles)
> defaulting to "*" would make it difficult to split an application into
> bundles
Yes, I agree "*" is unacceptable based on your above argument.
> similarly the current default (based on the Bundle-SymbolicName) isn't
> great because it doesn't always match the package, and can contain
> attributes (so we need to do a lot of processing to fix it)
> since we're scanning the code for packages to put in Private-Package
> why not use this data to provide a better default for Export-Package?
> When someone starts out with OSGi it is better to export their classes
> to begin with than keep everything private, as it means they can use
> their bundle immediately (this is how Bnd wraps existing JARs)
Then make that the default instead of relying on any naming convention. 
More on this below.
>>  The one remaining question is what to do if only Export-Package is set...
>>> we
>>> could set Private-Package based on the actual project source which would
>>> guarantee all your local classes will be in the bundle, but what if you
>>> don't actually want these packages included...
>>> Any thoughts on this last point?
>> In this case, user has to use empty value for Private-Package if they don't
>> like our default. BTW, I don't see why someone would compile some code if
>> they don't want it to be part of the bundle. Do you have a use case for
>> this? Since I don't think this is a typical case, IMO, it is fair for the
>> default rule to not be applicable for them.
> no, because if a given package is in both Export-Package and Private-Package
> then Export-Package wins and the package will be exported. This means we can
> use the following defaults:
>    if Private-Package is not set it defaults to the packages in the local
> Java source
>    if Export-Package is not set it defaults to the packages in the local
> Java source
>    [ except the default package (".") and any packages with ".impl" or
> ".internal" ]
> this provides a good compromise
Naming convention varies from project to project, so  I don't like to 
define any rule that depend on them. Although I prefer everything as 
private-package to everything as exported by default, I am actually fine 
if you say everything is exported by default in order to ease migration 
to OSGi. But, I definitely don't like the idea of relying on any naming 
convention to decide what to export or not.

If we want to delay the decision of making what should be the default, 
is there any advantage in defining a variable or a macro (whatever fits 
the nomenclature of the plugin) that denotes everything found in source 
dir? Let user specify that as value of Export-Package or Private-Package.


To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

View raw message