I'm not a committer on commons, but I've diagnosed the issue we had in ServiceMix with the commons-pool bundles. I can confirm that the patch is the right way to go. If a bundle acting as a library imports its own exported packages, you're bound to a lot of problems.
This problem applies to all releases of commons-pool and maybe to other commons-xxx components. I need to try if, but a better way might be to change the commons-parent pom with something like: <commons.osgi.export>org.apache.commons.*;version=${pom.version};-noimport</commons.osgi.export> This should work the same (i.e. not import our own exports), but be applicable to all modules. On Thu, Feb 25, 2010 at 12:31, Phil Steitz <phil.ste...@gmail.com> wrote: > Can someone knowledgeable in OSGi header construction please have a > look at POOL-160. IIUC, this applies to all recently released > commons components (unless [pool] is somehow individually borked). > > Thanks! > > Phil > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org