You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Edwin Goei <ed...@sun.com> on 2001/07/30 18:34:28 UTC

Re: JAXP/Crimson timeplan

Stephane Bailliez wrote:
> 
> Hi Edwin,
> 
> We would like to update jaxp/crimson to the bugfix release so that we ship
> Ant 1.4 with something more stable.
> 
> I guess there is no problem for crimson 1.1.1, but Stefan was wondering if
> there was any problem in distributing jaxp.jar binary ?

I would just go do it.  After all, previous versions had the same kind
of code in it and it was allowed.  In my opinion, restricting
distribution would be a bad thing for Sun so I can't see why they would
ever want to do so.  But getting an official answer from legal would be
time consuming and possibly open up a can of worms.

> 
> Additionaly Costin said we'd better wait about a week or so to have a more
> stable code. Is it concerning both jaxp and crimson ? Is there on official
> release in the pipe ?

The crimson parser itself is pretty stable.  Version 1.1.1 went into
J2EE 1.3 and I just integrated a newer version into JDK 1.4 beta2. 
Costin may be thinking about the XSLT processing parts of JAXP which
uses Xalan-j.  We recently updated the code so that it uses the Xalan
DTM code for performance fixes and maintenance.

> 
> Would it be possible to give us post some more information on ant-dev ?

I'll try to post this to that email list.

-Edwin

Re: JAXP/Crimson timeplan

Posted by Edwin Goei <ed...@sun.com>.
Stefan Bodewig wrote:
> 
> On Tue, 31 Jul 2001, Edwin Goei <ed...@sun.com> wrote:
> 
> > The JAXP RI (Reference Implementation) is open sourced much like the
> > way the servlet RI is so the most up-to-date source code is at
> > apache.
> 
> Does that include the javax.xml classes itself?

That's a good question.  I believe upper management has lots of other
things to worry about so this issue gets very low priority.  These
classes are like the servlet API.  No one would benefit from keeping the
source code private because it would cause multiple implementations of
the same APIs and the inevitable incompatibilities because of
differences between implementations, not to mention unnecessary
duplication of work.  The reason for developing JAXP was to make it
easier to use XML and Java together and thus promote the use of Java
instead of creating a product that other companies would license.

> 
> >> Conor suggested, that we don't talk about the reference
> >> implementation of JAXP at all in our distribution, but state that
> >> we'd include Apache Crimson 1.1.1 and the jaxp.jar contained in
> >> Crimson's distribution - that way we'd push licensing problems (if
> >> any) to the Crimson distribution only.
> >
> > Sure, good idea.
> 
> So lets follow that path, let's take whatever is the latest released
> version of crimson and the jaxp.jar that is included in this crimson's
> distribution.

Actually, Costin requested the latest JAXP crimson code for Tomcat so I
will be creating a new distribution.  I'd recommend using that version
of crimson.

-Edwin

Re: JAXP/Crimson timeplan

Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 31 Jul 2001, Edwin Goei <ed...@sun.com> wrote:

> Stefan Bodewig wrote:
>> 
>> I cannot find any mention of a bugfix release in the XML section of
>> java.sun.com
> 
> Yup, unfortunately what is on java.sun.com is an old and buggy
> version but we're not allowed to update it for various reasons.

I love politics ...

> The JAXP RI (Reference Implementation) is open sourced much like the
> way the servlet RI is so the most up-to-date source code is at
> apache.

Does that include the javax.xml classes itself?

>> Conor suggested, that we don't talk about the reference
>> implementation of JAXP at all in our distribution, but state that
>> we'd include Apache Crimson 1.1.1 and the jaxp.jar contained in
>> Crimson's distribution - that way we'd push licensing problems (if
>> any) to the Crimson distribution only.
> 
> Sure, good idea.

So lets follow that path, let's take whatever is the latest released
version of crimson and the jaxp.jar that is included in this crimson's
distribution.

Thanks

        Stefan

Re: JAXP/Crimson timeplan

Posted by Edwin Goei <ed...@sun.com>.
Stefan Bodewig wrote:
> 
> On Mon, 30 Jul 2001, Edwin Goei <ed...@sun.com> wrote:
> 
> > Stephane Bailliez wrote:
> >
> >> I guess there is no problem for crimson 1.1.1, but Stefan was
> >> wondering if there was any problem in distributing jaxp.jar binary
> >> ?
> >
> > I would just go do it.  After all, previous versions had the same
> > kind of code in it and it was allowed.
> 
> But previous versions included the latest released JAXP code, while I
> cannot find any mention of a bugfix release in the XML section of
> java.sun.com - this is where I see room for legal problems, i.e. can
> we ship an unofficial version of the JAXP classes with Ant?

Yup, unfortunately what is on java.sun.com is an old and buggy version
but we're not allowed to update it for various reasons.  The JAXP RI
(Reference Implementation) is open
sourced much like the way the servlet RI is so the most up-to-date
source code is at apache.

> 
> > In my opinion, restricting distribution would be a bad thing for Sun
> > so I can't see why they would ever want to do so.
> 
> Sun restricts distribution of beta- and pre-releases, just look at the
> licenses for the early access downloads in the JDC.  And Sun does so
> for very good reasons IMHO - everything else would be a maintenance
> nightmare.

If you're refering to products such as J2SE then yes, I can see that
they want to minimize the number of versions to support.  But in this
case the JAXP RI on java.sun.com is not really a product.  It will go
into J2SE 1.4 and is part of J2EE 1.3, though, then it will be part of
those products and will be part of a supported product.

> 
> > But getting an official answer from legal would be time consuming
> > and possibly open up a can of worms.
> 
> Sure.
> 
> Conor suggested, that we don't talk about the reference implementation
> of JAXP at all in our distribution, but state that we'd include Apache
> Crimson 1.1.1 and the jaxp.jar contained in Crimson's distribution -
> that way we'd push licensing problems (if any) to the Crimson
> distribution only.

Sure, good idea.

> 
> >> Additionaly Costin said we'd better wait about a week or so to have
> >> a more stable code.
> >
> > The crimson parser itself is pretty stable.  Version 1.1.1 went into
> > J2EE 1.3 and I just integrated a newer version into JDK 1.4 beta2.
> > Costin may be thinking about the XSLT processing parts of JAXP which
> > uses Xalan-j.  We recently updated the code so that it uses the
> > Xalan DTM code for performance fixes and maintenance.
> 
> We don't really use the transformation part of JAXP (except for the
> <style> task) and don't ship an XSLT processor either, so we should
> probably stick with Crimson 1.1.1 and that's it.

Yup, that would work.

> 
> I don't really want to ship any unreleased code in a release of Ant.
> I'd even prefer to state that we included the latest released code,
> but know that there are bugs - and tell people where they could find
> fixes for them.

For JAXP RI, there has been newer released versions.  The version on
java.sun.com is an old and buggy version which I do not recommend
using.  If it were up to me, I would update the site with at least the
next released version.  Since then there have been these versions:

1) JAXP RI 1.1.1 went into J2EE 1.3
2) JAXP RI 1.1.2beta2 went into J2SE 1.4 beta2

The crimson parser itself is pretty stable right now so if you are only
interested in the parser, then #2 would have the latest bug fixes.  The
"beta2" part of the version is there because that is what will be
shipped for J2SE 1.4 beta2 and in case there will be future bug fixes to
JAXP RI that will need to go into J2SE 1.4 FCS (Final) before it ships. 
Let me know if you want #2 because right now there is only a prebuilt
version of #1.  

-Edwin

Re: JAXP/Crimson timeplan

Posted by Stefan Bodewig <bo...@apache.org>.
Hi Edwin,

thanks for your quick feedback.

On Mon, 30 Jul 2001, Edwin Goei <ed...@sun.com> wrote:

> Stephane Bailliez wrote:
>
>> I guess there is no problem for crimson 1.1.1, but Stefan was
>> wondering if there was any problem in distributing jaxp.jar binary
>> ?
> 
> I would just go do it.  After all, previous versions had the same
> kind of code in it and it was allowed.

But previous versions included the latest released JAXP code, while I
cannot find any mention of a bugfix release in the XML section of
java.sun.com - this is where I see room for legal problems, i.e. can
we ship an unofficial version of the JAXP classes with Ant?

> In my opinion, restricting distribution would be a bad thing for Sun
> so I can't see why they would ever want to do so.

Sun restricts distribution of beta- and pre-releases, just look at the
licenses for the early access downloads in the JDC.  And Sun does so
for very good reasons IMHO - everything else would be a maintenance
nightmare.

> But getting an official answer from legal would be time consuming
> and possibly open up a can of worms.

Sure.

Conor suggested, that we don't talk about the reference implementation
of JAXP at all in our distribution, but state that we'd include Apache
Crimson 1.1.1 and the jaxp.jar contained in Crimson's distribution -
that way we'd push licensing problems (if any) to the Crimson
distribution only.

>> Additionaly Costin said we'd better wait about a week or so to have
>> a more stable code.
> 
> The crimson parser itself is pretty stable.  Version 1.1.1 went into
> J2EE 1.3 and I just integrated a newer version into JDK 1.4 beta2.
> Costin may be thinking about the XSLT processing parts of JAXP which
> uses Xalan-j.  We recently updated the code so that it uses the
> Xalan DTM code for performance fixes and maintenance.

We don't really use the transformation part of JAXP (except for the
<style> task) and don't ship an XSLT processor either, so we should
probably stick with Crimson 1.1.1 and that's it.

I don't really want to ship any unreleased code in a release of Ant.
I'd even prefer to state that we included the latest released code,
but know that there are bugs - and tell people where they could find
fixes for them.

Thanks

        Stefan