You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Jim Ma <ma...@gmail.com> on 2011/12/16 03:20:38 UTC
Remove xml-resolver dependency
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.
Cheers,
Jim
Re: Remove xml-resolver dependency
Posted by Daniel Kulp <dk...@apache.org>.
On Monday, December 19, 2011 10:42:23 AM Jim Ma wrote:
> 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.
Yea. I think so. The only other option really is to define our own object
that uses some level of reflection to allow use of the sun version, the pure
Apache version, of the com.ibm version in the IBM jdk. Generally more work
than I think justifies the small jar.
Dan
> On Sat, Dec 17, 2011 at 6:21 AM, K Fung <kf...@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
> > > dkulp@apache.org - http://dankulp.com/blog
> > > Talend Community Coder - http://coders.talend.com
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Remove xml-resolver dependency
Posted by Jim Ma <ma...@gmail.com>.
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 <kf...@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
> > dkulp@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
>
Re: Remove xml-resolver dependency
Posted by K Fung <kf...@gmail.com>.
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
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
Re: Remove xml-resolver dependency
Posted by Daniel Kulp <dk...@apache.org>.
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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com