Steven E. Harris wrote:
"Steven E. Harris" <[EMAIL PROTECTED]> writes:
Would this mean creating a Maven project in my own source tree and
pointing it at the tracker code, requesting the appropriate packages
for export?
I figured it out. It's explained in the "Real-World Example" section
of the "Bundle Plugin for Maven" documentation.¹ What's not obvious is
whether the plugin automatically includes any dependencies of the
exported "borrowed" package. That is, when I write
<Export-Package>org.osgi.util.tracker[,...]</Export-Package>
in my pom.xml file, I see that all of the org.osgi.util.tracker
package gets copied into my bundle.² But what if this package makes
use of other packages for implementation that would normally be
specified in a Private-Package declaration? Will the Bundle Plugin
know to include these in my bundle?
Good question, I don't know how BND handles that, but I am sure Peter
knows... :-)
I must say this whole approach of borrowing parts of other bundles
makes me uneasy. Isn't it possible that these individual class files
may rely on other resources being present in the bundle? Is a package
name really sufficient to capture the cohesive set of resources?
That is why you have testing, etc. It doesn't make sense that you would
do this and just release it without any understanding of what the
requirements and constraints are for the packages you are borrowing.
Since the stuff we are talking about here is open source, you can easily
look at see what you should be getting or ask the community around the
project what is necessary.
The plugin enables this type of approach, but it doesn't require it
anyway. So, you are still free to use the same old method. However, for
me it doesn't make sense, for example, to have a dependency on the
entire OSGi compendium for our simple Log Service bundle, since we can
easily include the log package in the bundle itself. The plugin makes
this approach easy and doesn't require that I re-package the log package
separately or copy the source files into the Log Service project.
So, follow whichever approach that makes you feel comfortable.
-> richard