----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, September 30, 2001 5:24 PM Subject: cvs commit: jakarta-alexandria/proposal/gump/site/xdocs status.xml
> rubys 01/09/30 17:24:36 > > Modified: proposal/gump/site/xdocs status.xml > Log: > add openejb and xml-fop (again) failures. Add jakarta-velocity-test, > but commented out. > > Revision Changes Path > 1.7 +102 -78 jakarta-alexandria/proposal/gump/site/xdocs/status.xml > > Index: status.xml > =================================================================== > RCS file: /home/cvs/jakarta-alexandria/proposal/gump/site/xdocs/status.xml,v > retrieving revision 1.6 > retrieving revision 1.7 > diff -u -r1.6 -r1.7 > --- status.xml 2001/09/26 20:53:35 1.6 > +++ status.xml 2001/10/01 00:24:36 1.7 > @@ -1,78 +1,102 @@ > -<?xml version="1.0"?> > -<document> > - > - <properties> > - <author email="[EMAIL PROTECTED]">Sam Ruby</author> > - <title>Gump</title> > - </properties> > - > -<body> > - > - <section name="Recurring build problems"> > - <p>These represent "known problems". In some cases, they represent a > - temporary problem that will be synched up at the point of the next > - release, in other cases they may represent an abject failure to > - communicate.</p> > - > - <subsection name="commons-latka"> > - <p>Latka depends on function which was subsequently rolled back from > - httpclient. Latka development continues with a snapshot of an > - httpclient jar which does not correspond to any release of httpclient or > - the current cvs head.</p> > - </subsection> > - > - <subsection name="dbxml"> > - <p>The Xalan team is in the process of changing an API that dbxml uses. > - The reason for the change is to support DTM, however the change is > - apparently not being made in a backwards compatbile manner.</p> > - </subsection> > - </section> > - > - <section name="Other Issues"> > - <p>These represent versioning issues that will not show up in any > - gump run, but you may need to be aware.</p> > - > - <subsection name="jakarta-avalon"> > - <p>Despite the relatively recent release of Ant, most Avalon projects > - will not build with that version of Ant. They require a small but > - important change in the jar task. Of course, they build with the version > - of Ant checked into their respective cvs's, but the question is: do we > - really want or need a separate version of Ant for every component?</p> > - </subsection> > - > - <subsection name="jakarta-tomcat-4.0"> > - <p>Tomcat4 integration with tyrex depends on interfaces which tyrex > - removed over six months ago.</p> > - </subsection> > - > - <subsection name="jakarta-turbine"> > - <p>Based on inspection, I don't believe that turbine-2 and turbine-3 can > - coexist in a classpath. The jakarta-jetspeed, jakarta-turbine-jyve, and > - jakarta-turbine-orgami projects depend on turbine-2. The > - jakarta-turbine-flux project depends on turbine-3.</p> > - </subsection> > - </section> > - > - <section name="Recent success stories"> > - <p>This section describes cross project compatibility issues which were: > - </p> > - > - <ul> > - <li>detected by gump</li> > - <li>the changes would likely have otherwise gone undetected until > - release</li> > - <li>involved changes to one or both products</li> > - <li>the changes were done prior to release.</li> > - </ul> > - > - <subsection name="jakarta-log4j"> > - <p>September 2001: in order to more closely resemble the JSR 47 API, > - the Level class replaced the Priority class, and the Logger class > - replaced the Category class. This was originally done in a manner which > - was thought to be backwards compatible, but there was subtle reasons why > - this was not the case.</p> > - </subsection> > - </section> > - > -</body> > -</document> > +<?xml version="1.0"?> > +<document> > + > + <properties> > + <author email="[EMAIL PROTECTED]">Sam Ruby</author> > + <title>Gump</title> > + </properties> > + > +<body> > + > + <section name="Recurring build problems"> > + <p>These represent "known problems". In some cases, they represent a > + temporary problem that will be synched up at the point of the next > + release, in other cases they may represent an abject failure to > + communicate.</p> > + > + <subsection name="commons-latka"> > + <p>Latka depends on function which was subsequently rolled back from > + httpclient. Latka development continues with a snapshot of an > + httpclient jar which does not correspond to any release of httpclient or > + the current cvs head.</p> > + </subsection> > + > + <subsection name="dbxml"> > + <p>The Xalan team is in the process of changing an API that dbxml uses. > + The reason for the change is to support DTM, however the change is > + apparently not being made in a backwards compatbile manner.</p> > + </subsection> > + > + <subsection name="openejb"> > + <p>In Junit 3.7, a previously protected method was made public, > + impacting extenders of junit.textui.TestRunner.</p> > + </subsection> > + > +<!-- > + <subsection name="jakarta-velocity-test"> > + <p><a href="http://cvs.apache.org/viewcvs/jakarta-velocity/src/java/org/apache/vel ocity/texen/ant/TexenTask.java.diff?r1=1.31&r2=1.32">This</a> > + change apparently is not compatible with Velocity being multiple times > + from the classpath with Ant 1.4.</p> > + </subsection> > +--> > + > + <subsection name="xml-fop"> > + <p>Batik is in the process of correcting what they have described as > + a fairly fundamental design error. This should only affect a small > + minority of batik users. Unfortunately, xml-fop is one of the users > + affected.</p> > + <p>At the present time, there is a good line of communication between > + the two projects, and the fop team understands and agrees to this change. > + They have already resynched once, and will try to track to the > + release.</p> > + </subsection> > + </section> > + > + <section name="Other Issues"> > + <p>These represent versioning issues that will not show up in any > + gump run, but you may need to be aware.</p> > + > + <subsection name="jakarta-avalon"> > + <p>Despite the relatively recent release of Ant, most Avalon projects > + will not build with that version of Ant. They require a small but > + important change in the jar task. Of course, they build with the version > + of Ant checked into their respective cvs's, but the question is: do we > + really want or need a separate version of Ant for every component?</p> > + </subsection> > + > + <subsection name="jakarta-tomcat-4.0"> > + <p>Tomcat4 integration with tyrex depends on interfaces which tyrex > + removed over six months ago.</p> > + </subsection> > + > + <subsection name="jakarta-turbine"> > + <p>Based on inspection, I don't believe that turbine-2 and turbine-3 can > + coexist in a classpath. The jakarta-jetspeed, jakarta-turbine-jyve, and > + jakarta-turbine-orgami projects depend on turbine-2. The > + jakarta-turbine-flux project depends on turbine-3.</p> > + </subsection> > + </section> > + > + <section name="Recent success stories"> > + <p>This section describes cross project compatibility issues which were: > + </p> > + > + <ul> > + <li>detected by gump</li> > + <li>the changes would likely have otherwise gone undetected until > + release</li> > + <li>involved changes to one or both products</li> > + <li>the changes were done prior to release.</li> > + </ul> > + > + <subsection name="jakarta-log4j"> > + <p>September 2001: in order to more closely resemble the JSR 47 API, > + the Level class replaced the Priority class, and the Logger class > + replaced the Category class. This was originally done in a manner which > + was thought to be backwards compatible, but there was subtle reasons why > + this was not the case.</p> > + </subsection> > + </section> > + > +</body> > +</document> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
