Stuart McCulloch wrote:
2009/2/17 Sahoo <[email protected]>
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.
Thanks,
Sahoo
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
