felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart McCulloch <mccu...@gmail.com>
Subject Re: Default value for <Private-Package> while using maven bundle plugin
Date Tue, 17 Feb 2009 06:18:07 GMT
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.

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

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)


>  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

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

-- 
Cheers, Stuart

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message