Okay. Then we should keep it as it was. I just saw these common classes to handle the same thing in different places : jaxb-xjc.jar , Sun's JDK, xml-resolver.jar. Looks like current way is the better option.
On Sat, Dec 17, 2011 at 6:21 AM, K Fung <kfung4...@gmail.com> wrote: > I would be inclined to disagree as well due to the following... > > 1) Complications in an OSGI world. The OSGI runtime is unlikely to export > com.sun.org.apache.xml.internal.resolver.* for usage. > 2) Not all JVMs could have this package. In particular, I'm thinking about > the IBM JDK. > > -kl > > On Thu, Dec 15, 2011 at 6:36 PM, Daniel Kulp <dk...@apache.org> wrote: > > > On Friday, December 16, 2011 10:20:38 AM Jim Ma wrote: > > > Hi , > > > Since all the equivalent classes in xml-resolver.jar are all packaged > in > > > jaxb-xjc.jar. We can change the org.apache.cxf.catalog.CataLogManager > to > > > use com.sun.org.apache.xml.internal.resolver.* class to decrease 82k > > > distribution size. If there is no objection, I am going to commit the > > > change. > > > > Yes. I object. jaxb-xjc is not needed at runtime. Other than the > > DynamicClient, nothing uses it at runtime. If you are just using pure > > jaxws, > > you don't need jaxb-xjc. > > > > Thus, you may be decreasing the distribution by 82K, but you are then > > adding a > > 3.1M to the runtime requirements. I'm not really willing to do that. > > > > Plus, the idea of depending on something in an "internal" package > > fundamentally bothers me. > > > > > > -- > > Daniel Kulp > > dk...@apache.org - http://dankulp.com/blog > > Talend Community Coder - http://coders.talend.com > > >
