Hi Andrea, Andrea Zoppello schrieb: > Hi Felix, > > I know the rules on versioning, btw i've some doubts about. Here my doubt: > > 1) The concept of version range applies only to import-package or also > to export-package. I i've understand well > this apply only to import package.. is this right??
Yes, the range only applies to imports. > > 2) What happen when an import-package in a client bundle could be > satisfied in different wasy??? > Which is the policy the framework choose?? Is this an implementation > detail?? The framework is expected to try hard to create consistent dependency trees and if possible to select a single export for all using (importing) bundles. The full details are described in the core spec in section 3.7, Resolving Process. > > Just to explain this problems arise to me using some feature of > javax.activation within javax.mail package. Oh, yeah. This is special ! ... and it is special drama by that matter. I suggest you create a bundle, which contains (and exports) both javax.activation and javax.mail. This helps alot. The reason for this is that a class from javax.activation tries to access resources from javax.mail. Regards Felix > > Andrea > Felix Meschberger ha scritto: >> Hi, >> >> If your other bundle is exporting the javax.* packages with an explicit >> version you might import-package the packages in your user bundle with >> the "same" version. >> >> E.g. the provider exports javax.servlet;version=2.5, so you may declare >> >> Import-Package: javax.servlet;version=2.5 >> >> and get the proper export. >> >> HTH >> >> Regards >> Felix >> >> Andrea Zoppello schrieb: >> >>> Hi all, >>> >>> I've the following problem: I'm starting my OSGi container ( Equinox ) >>> with jdk1.6, so as the result >>> i've the system bundle exporting the javax.* packages with version >>> "0.0.0" >>> >>> From a my client bundle i want that during the resolution my bundle will >>> not use the javax.* package exported >>> by the system bundle, but the ones exported by another one. >>> >>> One of the possible solution, could be to use the require bundle instead >>> of import package, but i'd still >>> prefer the import-package. >>> >>> Maybe i'm missing something, but i don't know how to solve that >>> problem... >>> >>> Is there any way to solve the general problem of having bundle "not >>> wired" with packages exported by >>> the system bundle??? >>> >>> Andrea >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >>> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
