On 25/04/07, Aggelos Mpimpoudis <[EMAIL PROTECTED]> wrote:
Stuart McCulloch wrote: > Basically, your Import-Packages are resolved against the Export-Packages > from other bundles. This doesn't mean you can't embed a jarfile inside > your > bundle, but if you do then you need to add it to your Bundle-ClassPath. > The benefit of wrapping a jar as a single bundle is that it can be > shared and > used by other bundles, but there are times when it makes sense to provide > a set of jarfiles as a single bundle, or if you want to hide an > implementation > dependency. This is exactly what I have understood and I will explain you later what is my problem. > Packages that you use inside your bundle must come from either another > bundle (via Import-Packages), your Bundle-ClassPath, or from the system > classpath (such as java.* packages). Well here we are, at the point that confuses me. I import a package at some source files of my bundle. The manifest-make plugin of Eclipse, reports that the manifest file has a problem. Ok...lets read the OSGi specifications. I read the specification and it makes clear that it needs the library, to be recorded in Bundle-Classpath manifest header. When I go at the relevant program in Eclipse it doesn't let me to edit the Bundle Class path and it keeps requesting to insert my 3rd party library as one more imported package.
if you're developing this as a PDE project then you can double-click on the MANIFEST.MF file, and either go to the MANIFEST.MF tab and edit the file directly, or go to the runtime tab and add the jarfile to the classpath panel. otherwise if you want to develop this as a plain Java project then you can use Peter Krien's Bnd tool as an Eclipse plugin, and add the jarfile to the Bundle-ClassPath in the bnd file for the project. (see http://www.aqute.biz/Code/Bnd#eclipse) another approach is shown at the end of the Pax Construct page: http://wiki.ops4j.org/confluence/display/ops4j/Pax+Construct
> > ( you can still access other classes dynamically, if you are given access > to the relevant classloader, for example via a service method > parameter ) > > BTW, if you export a package, it's good practice to also import it in > case > another bundle provides the same package. If you don't import then your > package may end up in a separate class space. > > ( > http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html > ) > >> somehow weird, on the contrary of what the specification reports! At the >> r3 book, look at page 588 at the Bundle-Classpath Section. Isn't this >> the section that describes this exact situation? Xmmm >> >> I am really sorry if I am asking nonsense..... :-[ :-[ :-[ :-[ >> >> There is always a starting point :-P > > I've provided some scripts + maven tools for quickly wrapping bundles, > etc. > available from > http://wiki.ops4j.org/confluence/display/ops4j/Pax+Construct > It uses the maven-bundle-plugin (which in turn uses Bnd) to do the > bundling. > -- Dept. of Informatics & Telecommunications, University of Athens Athens, Greece GSM +306942075153 / Msn: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
-- Cheers, Stuart _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
