>> 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?
After creating the content of the JAR, bnd will calculate all the
referred classes from this content. It will then remove any private
packages and will then create an import statement for the remainder.
So you will -not- get any automatic includes of imports. However, if
you find that you have an unwanted imported, just add it to your
Private-Package list.
Kind regards,
Peter Kriens
RSH> 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?
>>
RSH> Good question, I don't know how BND handles that, but I am sure Peter
RSH> 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?
>>
RSH> That is why you have testing, etc. It doesn't make sense that you would
RSH> do this and just release it without any understanding of what the
RSH> requirements and constraints are for the packages you are borrowing.
RSH> Since the stuff we are talking about here is open source, you can easily
RSH> look at see what you should be getting or ask the community around the
RSH> project what is necessary.
RSH> The plugin enables this type of approach, but it doesn't require it
RSH> anyway. So, you are still free to use the same old method. However, for
RSH> me it doesn't make sense, for example, to have a dependency on the
RSH> entire OSGi compendium for our simple Log Service bundle, since we can
RSH> easily include the log package in the bundle itself. The plugin makes
RSH> this approach easy and doesn't require that I re-package the log package
RSH> separately or copy the source files into the Log Service project.
RSH> So, follow whichever approach that makes you feel comfortable.
->> richard
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
