Yes, I've started down that road. The issue is this will require manual maintenance of a significant list of packages.
It'd be nice of there was some form of convenience around this. I'd really like something like what happens with the `java.*` packages. It seemed that the documentation for `org.osgi.framework.bootdelegation` suggests it works like this, but either I'm not using it correctly OR it does not support a package glob OR such a package should never appear in an import package statement (which might force the framework to handle it outside of bootdelegation) - Ray On Tue, Aug 5, 2014 at 8:51 PM, Matt Sicker <[email protected]> wrote: > If you're talking about Xerces (JAXP), then you could do like Karaf does > and extend the system export packages to include Xerces. It helps with > finding a JAXP provider that much faster, too. I can't find where I found > more info about this (I thought it was on Karaf's website, but I can't find > it), but the default config.properties that comes with Karaf lists them all > out. > > > On 5 August 2014 19:24, Raymond Auge <[email protected]> wrote: > >> An example of a osgi bundle which requires such packages is: >> >> javax.servlet.jsp.jstl [1] >> >> While I can certainly export all these packages from the system bundle by >> hand, I'm wondering there's any mechanism which might simplify the task, >> and the maintenance of such over time. >> >> [1] http://search.maven.org/#browse%7C-1002239558 >> >> >> >> On Tue, Aug 5, 2014 at 5:16 PM, Raymond Auge <[email protected]> >> wrote: >> >>> Is it wrong to use >>> >>> org.osgi.framework.bootdelegation=com.sun.org.apache.* >>> >>> - Ray >>> >>> >>> On Tue, Aug 5, 2014 at 5:08 PM, Raymond Auge <[email protected]> >>> wrote: >>> >>>> Specifically, I'm talking about >>>> >>>> com.sun.org.apache.* >>>> >>>> >>>> On Tue, Aug 5, 2014 at 5:03 PM, Raymond Auge <[email protected]> >>>> wrote: >>>> >>>>> What's the best approach to allowing use of the com.sun.* xml packages >>>>> provided by Java SE? >>>>> >>>>> There's a huge number of packages there and listing them out is >>>>> tedious! >>>>> >>>>> Note that the problem is not direct use of container classes, but >>>>> because the way the XML factories/providers handle creating impls. >>>>> >>>>> Someone must have tackled this before. >>>>> >>>>> Thoughts? >>>>> >>>>> -- >>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>>>> (@rotty3000) >>>>> Senior Software Architect >>>>> *Liferay, Inc.* <http://www.liferay.com> (@Liferay) >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>>> (@rotty3000) >>>> Senior Software Architect >>>> *Liferay, Inc.* <http://www.liferay.com> (@Liferay) >>>> >>>> >>> >>> >>> -- >>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>> (@rotty3000) >>> Senior Software Architect >>> *Liferay, Inc.* <http://www.liferay.com> (@Liferay) >>> >>> >> >> >> -- >> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >> (@rotty3000) >> Senior Software Architect >> *Liferay, Inc.* <http://www.liferay.com> (@Liferay) >> >> >> _______________________________________________ >> 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 > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
