You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Thomas Watson <tj...@us.ibm.com> on 2006/06/02 15:47:09 UTC
Automatic generation of Import-Package statements
Niclas Hedhman <he...@gmail.com> wrote on 05/31/2006 04:11:30 AM:
>
> Hi,
> <not sure if I should put this to Equinox list or here, but since
> bot Jeff and
> BJ are present here I thought it made more sense...>
>
> After Peter Kriens automatic generation of Import-Package statements and
the
> additional generated "uses:" clauses in Export-Package, we see an
extreme
> difference in speed for resolving the packages.
>
> It essentially went from "instantenous" to "many seconds" (~10-15 onmy
fairly
> fast machine here). I don't understand why.
>
> It seems that it executes (see stack frame attached) a recursive call to
> org.eclipse.osgi.internal.module.GroupingChecker.
> addInitialGroupingConstraints(GroupingChecker.java:292)
>
> which I think is where the time is spent (the depth varies during the
start
> period).
>
> Any takers on what is happening, and what we should do about it?
>
Niclas, thanks for pointing this out to us. I'm sure the Felix team
(Richard) is loving this ;-)
I found several areas in the (Equinox) resolver to greatly improve
performance when large sets of "uses:=" directives are used.
While investigating this it dawned on me that you are importing
every package which you export. I now realize that is a result
of running the automatic manifest generation tool (is this mangen?).
This only happens if you have the "Bundle-ManifestVersion: 2"
header to indicate you are using OSGi R4 bundle manifest syntax.
This seems a bit problematic if it is the default setting for the
tool. This is the old OSGi R3 way of doing things. In OSGi R3
every export also had a implicit import. While this is
good in some scenarios it does prevent many important scenarios
which OSGi R4 allows. In OSGi R4 exported packages are no longer
implicitly imported. This allowed OSGi to greatly enhance to
Framework to allow multiple versions of the same package to be
exported at the same time by multiple bundles.
If you always import every package you export then you will
prevent multiple versions of the same package from being available
in the system. For example, imagine you must support two versions
of the junit library in your system at the same time. One junit
bundle version 3.8.1 exports all of its junit packages at version
3.8.1. Another junit bundle version 4.1.0 exports all of its junit
packages at version 4.1.0. Both of these bundles can be installed
and resolved at the same time. Now if the 3.8.1 junit bundle
imports every package it exports then the resolver can resolve
its imports to the 4.1.0 versions of the junit packages. This will
drop the exported packages from the 3.8.1 version of the bundle and
make them unavailable to the rest of the bundles in the Framework.
This also puts a much greater burden on the developer when they
decide to export a package. If every exported package is also
imported then the developer must be prepared to handle when their
own exported package is substituted with another version of the
package from a different bundle. This means you cannot have
any internal implementation dependencies on the packages you
export. In your example manifest you have over 100 exports.
Are you prepared for any one of those exports being replaced with
a package from another bundle? Are there no internal
implementation dependencies between your packages. With such a
large set of packages it seems likely you would have some
internal implementation dependancies.
One last nit. The tool seems to add packages to the uses clause
which either do not exist or are internal packages to your bundle.
For example search for org.ops4j.pax.wicket.service.internal in
your uses clause. It states that exported package
org.ops4j.pax.wicket.service uses this internal package. Is
the tool being to aggressive? Or do you have an unintentional
internal dependency?
Tom
Re: Automatic generation of Import-Package statements
Posted by Rob Walker <ro...@ascert.com>.
> While investigating this it dawned on me that you are importing
> every package which you export. I now realize that is a result
> of running the automatic manifest generation tool (is this mangen?).
> This only happens if you have the "Bundle-ManifestVersion: 2"
> header to indicate you are using OSGi R4 bundle manifest syntax.
>
>
Haven't followed the thread fully, so not sure whether mangen is in use
here - and whether this is the case.
But if so, you can add a mangen rule to suppress this behaviour either
globally or locally on a per-JAR basis:
DontImportOwnExports
*Usable globally* |yes|
*Usable locally* |yes|
*Standard options*
*Rule specific options*
In many application cases it's not necessary for a bundle JAR to
import it' own exports. This rule may be used locally or globally to
remove from a bundle's import list any package which it also exports.
> One last nit. The tool seems to add packages to the uses clause
> which either do not exist or are internal packages to your bundle.
> For example search for org.ops4j.pax.wicket.service.internal in
> your uses clause. It states that exported package
> org.ops4j.pax.wicket.service uses this internal package. Is
> the tool being to aggressive? Or do you have an unintentional
> internal dependency?
>
I'm reading this part and actually thinking maybe this isn't mangen
related - since as I recall, we didn't get as far as having mangen
create uses clauses.
If it is though - there are also ways to generation "Ignore" rules to
prune out unwanted imports or exports which have been automatically
detected but are not actually needed.
Regards
-- Rob
Re: Automatic generation of Import-Package statements
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Niclas Hedhman wrote:
> On Tuesday 06 June 2006 20:07, Richard S. Hall wrote:
>
>> Niclas Hedhman wrote:
>>
>>> And I am still stunned by the statement that the framework will not
>>> deliver q-1.0 to my BundleC if the exporter of q-1.0 imports q, which is
>>> resolved to q-1.1 exported by someone else...
>>> Can't find it in the spec to neither confirm nor contardict it either,
>>> and Richard's reply is also vague on the point...
>>>
>> Standard imports cannot be split, thus if a bundle both imports/exports
>> a given package and import is selected at resolve time (i.e., the bundle
>> ends up importing it from another bundle rather than using its own),
>> then it is not possible for it to ask its fragment for a class in that
>> package, since it will error after asking the exporter it is wired to if
>> the class is not found in the exported package.
>>
>
> Sorry, does not compute;
> Let's try this with code;
>
> Bundle A
> Export-Package: org.hedhman; version=1.0
> Import-Package: org.hedhman
>
> Bundle B
> Export-Package: org.hedhman; version=1.1
>
> Bundle C
> Import-Package: org.hedhman; version="[1.0, 1.0]"
>
>
> Is everyone now saying that Bundle C can not be resolved, although there are
> no technical reasons for that being the case??
>
Sorry, I misread your message that I responded to originally. I read
"framework" as "fragment", which is why I responded talking about
fragments. My bad.
In your example above, it depends on the framework implementation.
However, if Bundle A is resolved to the import from Bundle B, then it
will not be possible to resolve Bundle C.
> If so, then the whole point of version ranges are practically useless, as
> undeterministic behavior will result due to later installations of newer
> versions.
Not really. If you follow a practice of packaging your libraries in
separate bundles, then you don't ever have to import/export the same
package (i.e., library bundles should only export), then you don't
experience this issue at all.
The point of being able to import/export the same package allows the
bundle to be able to explicitly say that it wants its export to be
substitutable, which is import for interoperability purposes. It has
been considered good practice in the past to package your interfaces
inside of the bundle of your service implementation, which makes the
need for substitutability greater. The ability in R4 to both
import/export the same package supports this common use case.
This really has nothing to do with the value of version ranges. If you
don't want version 1.0 to be substituted for version 1.1, then don't
import it too.
-> richard
Re: Automatic generation of Import-Package statements
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 06 June 2006 20:07, Richard S. Hall wrote:
> Niclas Hedhman wrote:
> > And I am still stunned by the statement that the framework will not
> > deliver q-1.0 to my BundleC if the exporter of q-1.0 imports q, which is
> > resolved to q-1.1 exported by someone else...
> > Can't find it in the spec to neither confirm nor contardict it either,
> > and Richard's reply is also vague on the point...
>
> Standard imports cannot be split, thus if a bundle both imports/exports
> a given package and import is selected at resolve time (i.e., the bundle
> ends up importing it from another bundle rather than using its own),
> then it is not possible for it to ask its fragment for a class in that
> package, since it will error after asking the exporter it is wired to if
> the class is not found in the exported package.
Sorry, does not compute;
Let's try this with code;
Bundle A
Export-Package: org.hedhman; version=1.0
Import-Package: org.hedhman
Bundle B
Export-Package: org.hedhman; version=1.1
Bundle C
Import-Package: org.hedhman; version="[1.0, 1.0]"
Is everyone now saying that Bundle C can not be resolved, although there are
no technical reasons for that being the case??
If so, then the whole point of version ranges are practically useless, as
undeterministic behavior will result due to later installations of newer
versions.
Cheers
Niclas
Re: Automatic generation of Import-Package statements
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Niclas Hedhman wrote:
> And I am still stunned by the statement that the framework will not deliver
> q-1.0 to my BundleC if the exporter of q-1.0 imports q, which is resolved to
> q-1.1 exported by someone else...
> Can't find it in the spec to neither confirm nor contardict it either, and
> Richard's reply is also vague on the point...
Standard imports cannot be split, thus if a bundle both imports/exports
a given package and import is selected at resolve time (i.e., the bundle
ends up importing it from another bundle rather than using its own),
then it is not possible for it to ask its fragment for a class in that
package, since it will error after asking the exporter it is wired to if
the class is not found in the exported package.
-> richard
Re: Automatic generation of Import-Package statements
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 05 June 2006 21:29, Thomas Watson wrote:
> If I follow you correctly, you are stating that you are not willing to get
>
> the wicket packages from another bundle. If that is the case then I would
>
> suggest you not explicitly import the wicket packages. Or is this just
> a temporary issue that you hope to allow for in the final version of your
> bundle?
ATM, it is not totally clear whether we have covered the cases and are willing
to receive the packages from another bundle. I think it will work, and sooner
or later we are going to have that sorted out...
> I'm picking on your particular example because of the various issues that
> need to be considered while using automated tools. If the tools have
> unreasonable defaults then many developers will fall into the same issues.
Sure.
> I think it is vitally important that a developer carefully considers every
> package they import because of the ramifications of such a decision.
> For example, how does the tool know what version of the package you need?
> This becomes even more important if you export that package. Maybe you
> export the package at version 2.1 but you can actually use version 2.0 if
> it is already available on the framework. I'm not sure an automated tool
> will be able to make such developer orientated decisions.
Well, computers are dumb. But I am also dumb. Example; how many times have one
deployed a system with a missing classpath entry which doesn't trigger until
some sysop decides to enable a runtime feature? Classic example; Mail
delivery of Log Events. "Oops, mail.jar was not on classpath. Need to take
the system down."
I'd rather be given an exhaustive list of things that *may* be required, and
remove stuff from it, than creating a list from scratch. Maybe that is just
me. Perhaps other OSGi veterans can provide some opinion...
And I am still stunned by the statement that the framework will not deliver
q-1.0 to my BundleC if the exporter of q-1.0 imports q, which is resolved to
q-1.1 exported by someone else...
Can't find it in the spec to neither confirm nor contardict it either, and
Richard's reply is also vague on the point...
Cheers
Niclas
Re: Automatic generation of Import-Package statements
Posted by Thomas Watson <tj...@us.ibm.com>.
"Richard S. Hall" <he...@ungoverned.org> wrote on 06/06/2006 04:23:37 AM:
> I think Tom's description of the situation is slightly inaccurate (or at
> least confusing to me).
If I confused Richard then I'm sure everyone else is confused also ;-)
My main point is that automatically importing every package you export can
cause you unexpected results.
- If you import every package you export without specifying a version
range to only includes the version you are exporting (i.e.
version="[1.0,1.0]") then you can prevent multiple versions of that
package from existing in the Framework.
- In many cases a bundle just wants to export a package but is unwilling
to substitute another implementation of that package. There is a much
greater burden on the developer when they decide to export a package if
you automatically generate an import for that package. They will have to
be prepared if their own package is replaced.
- Importing any packages which contain your implementation classes can be
dangerous. For example, exporting/importing the package with your
BundleActivator can allow someone to replace your activator implementation
with another implementation. If you have a service component (Declarative
Services) and you export/import the package with your DS service component
implementations then another bundle can replace your service component
implementation classes.
Tom
Re: Automatic generation of Import-Package statements
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I think Tom's description of the situation is slightly inaccurate (or at
least confusing to me).
In R4, if bundle A both exports and imports package foo, then bundle A
is specifically saying that it is willing to have its version of foo
substituted for a different version at resolve time. Why does bundle A
want to do this? To be interoperable with other bundles that might being
using a different version of foo. This substitutability was the default
in R3 for interoperability purposes and by and large should be the
default way to generate your metadata in R4 too.
Further, there is no direct connection between having explicit
exports/imports for a given package and the framework only allowing one
version of that package.
Even with explicit exports/imports for a given package, it is still
possible to have multiple versions of a given package because it is
possible to specify the precise versions allowed for substitutability on
the import declaration. So, this is really the improvement from R3, R4
does not impose 100% backwards compatibility. It allows the bundle to
say, "I can accept substitutability within this version range," which is
much more realistic.
However, after having said all of that. This is really only important
for bundles that export packages and actually do something with those
packages themselves, i.e., have a bundle activator. If a bundle is
purely just a library bundle that simply just exports some packages,
then it does not need to explicitly import the packages too, since this
will potentially hide its version of the packages (unless it specifies
its precise version on the import).
-> richard
Thomas Watson wrote:
> Niclas Hedhman <he...@gmail.com> wrote on 06/04/2006 03:02:34 AM:
>
>>> If you always import every package you export then you will
>>> prevent multiple versions of the same package from being available
>>> in the system.
>>>
>> I don't follow this argument. IIRC, the multiple versions of the
>> same packages
>> has been with OSGi since the early days, and not anything new in R4.
>>
>>
>>> For example, imagine you must support two versions
>>> of the junit library in your system at the same time. One junit
>>> bundle version 3.8.1 exports all of its junit packages at version
>>> 3.8.1. Another junit bundle version 4.1.0 exports all of its junit
>>> packages at version 4.1.0. Both of these bundles can be installed
>>> and resolved at the same time. Now if the 3.8.1 junit bundle
>>> imports every package it exports then the resolver can resolve
>>> its imports to the 4.1.0 versions of the junit packages. This will
>>> drop the exported packages from the 3.8.1 version of the bundle and
>>> make them unavailable to the rest of the bundles in the Framework.
>>>
>> Huh? No. That depends on the version directives.
>> And the way I interpret the spec (but I can have missed something) is
>>
> that;
>
>> If Bundle A exports q-1.0 and imports q, and Bundle B exports q-1.1 and
>>
> the
>
>> framework resolves A's import to B's export, A will still provide the
>>
> export
>
>> of q-1.0 for, for instance, Bundle C that imports q-1.0 (restricted).
>>
>> So that albeit Bundle A doesn't use its own exported packages, it will
>>
> still
>
>> have to provide it for those who depends on them.
>>
>>
>
> This is not how it works. In R3 if multiple bundles (X and Y) exported
> the
> same package (foo) then the framework will choose only one bundle (X) to
> be
> the exporter and every other bundle (Y) would import the package (foo).
> This is called implicitly importing a package. A bundle can only import
> OR
> export a package but it cannot do both at the same time. If the framework
>
> chooses another bundle (X) to export the package (foo) then the other
> bundle (Y) becomes an importer of the package and the export of (foo)
> is not available from bundle (Y).
>
> In OSGi R4 the specification changed such that multiple bundles can offer
> to export the same package. In R4 if a bundle exports a package it no
> longer implicitly imports the package. If two bundles export the same
> package AND do not explicitly import the package then there will be two
> "versions" of that package available in the framework. But R4 still
> uses the same rules if a bundle explicitly imports a package. If a bundle
>
> imports a package and that import did not resolve to its own export of
> that
> package then the export is dropped from that bundle and is not available
> in the framework.
>
>
>>> This also puts a much greater burden on the developer when they
>>> decide to export a package. If every exported package is also
>>> imported then the developer must be prepared to handle when their
>>> own exported package is substituted with another version of the
>>> package from a different bundle. This means you cannot have
>>> any internal implementation dependencies on the packages you
>>> export.
>>>
>> This is an accurate note, which I "hope" the Maven plugin will detect
>>
> and
>
>> report, if not now then it should be added.
>>
>>
>>> In your example manifest you have over 100 exports.
>>> Are you prepared for any one of those exports being replaced with
>>> a package from another bundle? Are there no internal
>>> implementation dependencies between your packages. With such a
>>> large set of packages it seems likely you would have some
>>> internal implementation dependancies.
>>>
>> In my case, I am 'suffering' the "legacy syndrom". The majority of
>>
> packages
>
>> are "Wicket", a web framework outside the OSGi domain, which I am OSGi
>> enabling with dynamic components, replacable pages, and other OSGi
>>
> tricks.
>
>> Since
>> a) the Wicket components and pages will sit in their own bundles,
>> b) I want aviod limiting what you can do in Wicket,
>> c) Wicket was not designed for OSGi,
>> I have not much choice than export all their packages.
>>
>> The interesting case, however, is what are the implications if Wicket is
>>
>
>
>> imported from somewhere else? For the time being I have said, "not
>>
> allowed"
>
>> as I think there are still a couple of classloader issues involved, but
>>
> that
>
>> is a totally different story.
>>
>
> If I follow you correctly, you are stating that you are not willing to get
>
> the wicket packages from another bundle. If that is the case then I would
>
> suggest you not explicitly import the wicket packages. Or is this just
> a temporary issue that you hope to allow for in the final version of your
> bundle?
>
> I'm picking on your particular example because of the various issues that
> need to be considered while using automated tools. If the tools have
> unreasonable defaults then many developers will fall into the same issues.
>
> I think it is vitally important that a developer carefully considers every
>
> package they import because of the ramifications of such a decision.
> For example, how does the tool know what version of the package you need?
> This becomes even more important if you export that package. Maybe you
> export the package at version 2.1 but you can actually use version 2.0 if
> it is already available on the framework. I'm not sure an automated tool
> will be able to make such developer orientated decisions.
>
> Tom
>
>
>
Re: Automatic generation of Import-Package statements
Posted by Thomas Watson <tj...@us.ibm.com>.
Niclas Hedhman <he...@gmail.com> wrote on 06/04/2006 03:02:34 AM:
> > If you always import every package you export then you will
> > prevent multiple versions of the same package from being available
> > in the system.
>
> I don't follow this argument. IIRC, the multiple versions of the
> same packages
> has been with OSGi since the early days, and not anything new in R4.
>
> > For example, imagine you must support two versions
> > of the junit library in your system at the same time. One junit
> > bundle version 3.8.1 exports all of its junit packages at version
> > 3.8.1. Another junit bundle version 4.1.0 exports all of its junit
> > packages at version 4.1.0. Both of these bundles can be installed
> > and resolved at the same time. Now if the 3.8.1 junit bundle
> > imports every package it exports then the resolver can resolve
> > its imports to the 4.1.0 versions of the junit packages. This will
> > drop the exported packages from the 3.8.1 version of the bundle and
> > make them unavailable to the rest of the bundles in the Framework.
>
> Huh? No. That depends on the version directives.
> And the way I interpret the spec (but I can have missed something) is
that;
>
> If Bundle A exports q-1.0 and imports q, and Bundle B exports q-1.1 and
the
> framework resolves A's import to B's export, A will still provide the
export
> of q-1.0 for, for instance, Bundle C that imports q-1.0 (restricted).
>
> So that albeit Bundle A doesn't use its own exported packages, it will
still
> have to provide it for those who depends on them.
>
This is not how it works. In R3 if multiple bundles (X and Y) exported
the
same package (foo) then the framework will choose only one bundle (X) to
be
the exporter and every other bundle (Y) would import the package (foo).
This is called implicitly importing a package. A bundle can only import
OR
export a package but it cannot do both at the same time. If the framework
chooses another bundle (X) to export the package (foo) then the other
bundle (Y) becomes an importer of the package and the export of (foo)
is not available from bundle (Y).
In OSGi R4 the specification changed such that multiple bundles can offer
to export the same package. In R4 if a bundle exports a package it no
longer implicitly imports the package. If two bundles export the same
package AND do not explicitly import the package then there will be two
"versions" of that package available in the framework. But R4 still
uses the same rules if a bundle explicitly imports a package. If a bundle
imports a package and that import did not resolve to its own export of
that
package then the export is dropped from that bundle and is not available
in the framework.
> > This also puts a much greater burden on the developer when they
> > decide to export a package. If every exported package is also
> > imported then the developer must be prepared to handle when their
> > own exported package is substituted with another version of the
> > package from a different bundle. This means you cannot have
> > any internal implementation dependencies on the packages you
> > export.
>
> This is an accurate note, which I "hope" the Maven plugin will detect
and
> report, if not now then it should be added.
>
> > In your example manifest you have over 100 exports.
> > Are you prepared for any one of those exports being replaced with
> > a package from another bundle? Are there no internal
> > implementation dependencies between your packages. With such a
> > large set of packages it seems likely you would have some
> > internal implementation dependancies.
>
> In my case, I am 'suffering' the "legacy syndrom". The majority of
packages
> are "Wicket", a web framework outside the OSGi domain, which I am OSGi
> enabling with dynamic components, replacable pages, and other OSGi
tricks.
>
> Since
> a) the Wicket components and pages will sit in their own bundles,
> b) I want aviod limiting what you can do in Wicket,
> c) Wicket was not designed for OSGi,
> I have not much choice than export all their packages.
>
> The interesting case, however, is what are the implications if Wicket is
> imported from somewhere else? For the time being I have said, "not
allowed"
> as I think there are still a couple of classloader issues involved, but
that
> is a totally different story.
If I follow you correctly, you are stating that you are not willing to get
the wicket packages from another bundle. If that is the case then I would
suggest you not explicitly import the wicket packages. Or is this just
a temporary issue that you hope to allow for in the final version of your
bundle?
I'm picking on your particular example because of the various issues that
need to be considered while using automated tools. If the tools have
unreasonable defaults then many developers will fall into the same issues.
I think it is vitally important that a developer carefully considers every
package they import because of the ramifications of such a decision.
For example, how does the tool know what version of the package you need?
This becomes even more important if you export that package. Maybe you
export the package at version 2.1 but you can actually use version 2.0 if
it is already available on the framework. I'm not sure an automated tool
will be able to make such developer orientated decisions.
Tom
Re: Automatic generation of Import-Package statements
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 02 June 2006 21:47, Thomas Watson wrote:
> Niclas, thanks for pointing this out to us. I'm sure the Felix team
> (Richard) is loving this ;-)
>
> I found several areas in the (Equinox) resolver to greatly improve
> performance when large sets of "uses:=" directives are used.
Cool. I got the notification from Bugzilla.
> While investigating this it dawned on me that you are importing
> every package which you export. I now realize that is a result
> of running the automatic manifest generation tool (is this mangen?).
No, I'm running the Maven plugin that Peter Kriens has donated to Felix.
> This only happens if you have the "Bundle-ManifestVersion: 2"
> header to indicate you are using OSGi R4 bundle manifest syntax.
Yes, I have added to the said plugin that it defaults to ManifestVersion 2. I
am not fond of undefined versions.
> If you always import every package you export then you will
> prevent multiple versions of the same package from being available
> in the system.
I don't follow this argument. IIRC, the multiple versions of the same packages
has been with OSGi since the early days, and not anything new in R4.
> For example, imagine you must support two versions
> of the junit library in your system at the same time. One junit
> bundle version 3.8.1 exports all of its junit packages at version
> 3.8.1. Another junit bundle version 4.1.0 exports all of its junit
> packages at version 4.1.0. Both of these bundles can be installed
> and resolved at the same time. Now if the 3.8.1 junit bundle
> imports every package it exports then the resolver can resolve
> its imports to the 4.1.0 versions of the junit packages. This will
> drop the exported packages from the 3.8.1 version of the bundle and
> make them unavailable to the rest of the bundles in the Framework.
Huh? No. That depends on the version directives.
And the way I interpret the spec (but I can have missed something) is that;
If Bundle A exports q-1.0 and imports q, and Bundle B exports q-1.1 and the
framework resolves A's import to B's export, A will still provide the export
of q-1.0 for, for instance, Bundle C that imports q-1.0 (restricted).
So that albeit Bundle A doesn't use its own exported packages, it will still
have to provide it for those who depends on them.
> This also puts a much greater burden on the developer when they
> decide to export a package. If every exported package is also
> imported then the developer must be prepared to handle when their
> own exported package is substituted with another version of the
> package from a different bundle. This means you cannot have
> any internal implementation dependencies on the packages you
> export.
This is an accurate note, which I "hope" the Maven plugin will detect and
report, if not now then it should be added.
> In your example manifest you have over 100 exports.
> Are you prepared for any one of those exports being replaced with
> a package from another bundle? Are there no internal
> implementation dependencies between your packages. With such a
> large set of packages it seems likely you would have some
> internal implementation dependancies.
In my case, I am 'suffering' the "legacy syndrom". The majority of packages
are "Wicket", a web framework outside the OSGi domain, which I am OSGi
enabling with dynamic components, replacable pages, and other OSGi tricks.
Since
a) the Wicket components and pages will sit in their own bundles,
b) I want aviod limiting what you can do in Wicket,
c) Wicket was not designed for OSGi,
I have not much choice than export all their packages.
The interesting case, however, is what are the implications if Wicket is
imported from somewhere else? For the time being I have said, "not allowed"
as I think there are still a couple of classloader issues involved, but that
is a totally different story.
> One last nit. The tool seems to add packages to the uses clause
> which either do not exist or are internal packages to your bundle.
> For example search for org.ops4j.pax.wicket.service.internal in
> your uses clause. It states that exported package
> org.ops4j.pax.wicket.service uses this internal package.
> Is the tool being to aggressive?
> Or do you have an unintentional internal dependency?
I think the answer to those are both "Yes". Peter Kriens have to provide more
info on how he perceives an automated tool should work. I added the
possibility to "ignore" packages, i.e. exclude them from the auto import.
However, Peter's tool have also discovered "uses" of classes that I would have
never thought of importing and that would have cause runtime problems very
"late"... So, I think the "aggressive" is probably good, but that the
developer need to scrutinize the list actively and add the "ignores".
But thanks a lot for your attention.
Cheers
Niclas