cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bozhong Lin" <bozhong....@gmail.com>
Subject Re: split manifest for jdk6 support
Date Tue, 08 Jan 2008 11:15:09 GMT
After making CXF to support JDK6, I wonder if there is a necessary to make
two different distributions for download, i.e., one for JDK5 and one for
JDK6.  The distribution for JDK6 can skip packaging those jars available in
JDK6.

What do you guys think on this?

Regards,
Bo

On Jan 7, 2008 10:25 AM, Jeff Zhang <jeff.zhang@iona.com> wrote:

> Thanks for your feedback.
>
> Jeff
>
> Glen Mazza wrote:
> > Another issue to keep in mind is that even if you are using JDK6, you
> > will probably someday need to override one of the JARs already in the
> > JDK6 with a newer version to fix some bug.  So make sure your solution
> > is flexible enough to handle these types of scenarios.
> >
> > Glen
> >
> >
> > Am Freitag, den 04.01.2008, 13:15 -0500 schrieb Daniel Kulp:
> >
> >> Out of curiosity, why does having that stuff in the manifest cause a
> >> problem?    The classloaders should, by default, grab the stuff from
> >> jre/lib first anyway.  Thus, the stuff in the manifest should be
> >> ignored.
> >>
> >> Dan
> >>
> >>
> >> On Friday 04 January 2008, Jeff Zhang wrote:
> >>
> >>> Hi,
> >>>
> >>> I work on CXF jdk6 support. My proposal is split
> >>> cxf-manifest-incubator.jar into 2 manifest jars, one includes all
> >>> javax jars embedded in JDK6, such as jaxws, jaxb, stax, jws,
> >>> annotation, etc..., we can call it cxf-specs-manifest.jar. And another
> >>> one contains the rest jars.
> >>>
> >>> If users use JDK5, they include both manifest jars in classpath, if
> >>> use JDK6, they can only include one manifest. For samples shipped with
> >>> CXF, we can define rule in common_build.xml, it get JDK version from
> >>> OS environment, and put right manifest jar into classpath.
> >>>
> >>> Do you think it reasonable?
> >>>
> >>> Thanks
> >>> Jeff
> >>>
> >>
> >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message