You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by David Crossley <cr...@indexgeo.com.au> on 2001/08/07 04:23:21 UTC
weird build problem - seems to be dependent on jar name
We have successfully added some new functionality into
our copy of the public release of Apache Cocoon 2.0b2
This involved some tweaks to core code to hook in another
Java package. All went smoothly (adding our jar file
into $COCOON_HOME/lib and edits to src/org/...). Re-build
is fine and our new functionality works as expected.
However, then i CVS checkout the whole cocoon_20_branch
and try to verify that our changes work with the most
recent code. The initial build is fine. Then i make the
exact same mods and try to re-build. Ant bombs with the
following obscure error and does not even get through
init phase. ant -v or ant -debug do not shed any light.
A workaround solution is to rename our jar file so that
it begins with "z" i.e. zcatalog.jar
Now re-build runs perfectly. Why is that hack needed?
Linux RedHat 7.1
java.vm.version=Blackdown-1.3.1-FCS
jakarta-tomcat-3.2.2
Help please, days have been wasted trying to get past this.
thanks, David Crossley
=================================================
Apache Cocoon 2 Build System
----------------------------
Buildfile: build.xml
BUILD FAILED
java.lang.NoSuchMethodError
at org.xml.sax.helpers.XMLReaderAdapter$AttributesAdapter.getName(XMLReaderAdapter.java:470)
at org.apache.tools.ant.ProjectHelper$ProjectHandler.init(ProjectHelper.java:288)
at org.apache.tools.ant.ProjectHelper$RootHandler.startElement(ProjectHelper.java:262)
at org.xml.sax.helpers.XMLReaderAdapter.startElement(XMLReaderAdapter.java:329)
at org.apache.xerces.parsers.SAXParser.startElement(SAXParser.java:1376)
at
org.apache.xerces.validators.common.XMLValidator.callStartElement(XMLValidator.java:1191)
at
org.apache.xerces.framework.XMLDocumentScanner.scanElement(XMLDocumentScanner.java:1862)
at
org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1005)
at
org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:381)
at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1081)
at org.xml.sax.helpers.XMLReaderAdapter.parse(XMLReaderAdapter.java:223)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:345)
at org.apache.tools.ant.ProjectHelper.parse(ProjectHelper.java:117)
at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:85)
at org.apache.tools.ant.Main.runBuild(Main.java:403)
at org.apache.tools.ant.Main.main(Main.java:149)
=================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: weird build problem - seems to be dependent on jar name
Posted by Michael Hartle <mh...@hartle-klug.com>.
David Crossley wrote:
>A workaround solution is to rename our jar file so that
>it begins with "z" i.e. zcatalog.jar
>Now re-build runs perfectly. Why is that hack needed?
>
>Linux RedHat 7.1
>java.vm.version=Blackdown-1.3.1-FCS
>jakarta-tomcat-3.2.2
>
>Help please, days have been wasted trying to get past this.
>thanks, David Crossley
>
In the installation guide, there is a similar example regarding how
ordering of jar files in a classpath is important regarding XML parsers;
I guess your catalog.jar contains (only potions / an alternative
implementation / an old implementation) of the same package that Ant
itself is needing to step through the build.xml file. The workaround
just allows the original package to be used for Ant instead of what is
contained in your catalog.jar. BTW, this means that while you are trying
to re-build the first time with Ant when it bombs, your classpath
contains catalog.jar, right ?
Could you give some more details which classes are in your package thats
in catalog.jar ?
Best regards,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: weird build problem - seems to be dependent on jar name
Posted by David Crossley <cr...@indexgeo.com.au>.
Thanks Carsten,
The jar name is catalog.jar to add entity resolver
support. It does not contain DOM stuff. However, it
certainly does have SAX-based classes - i mean it
does "import org.xml.sax.EntityResolver" etc.
Note that everything works beautifully with the public
release of c2b2. There were no such build problems.
I have almost finished a documentation page to give
background, examples, and development notes, and i was
just about to start discussing adding entity resolver
support with the dev list.
regards, David
--------------------------------------
> Date: Tue, 7 Aug 2001 09:39:39 +0200
> From: "Carsten Ziegeler" <cz...@sundn.de>
> To: <co...@xml.apache.org>, <cr...@indexgeo.com.au>
>
> What was the original name of your jar file and which
> classes (packages) did it contain (any sax or dom
> package?)
>
> Carsten
>
> > -----Urspr�ngliche Nachricht-----
> > Von: David Crossley [mailto:crossley@indexgeo.com.au]
> > Gesendet: Dienstag, 7. August 2001 04:23
> > An: cocoon-dev@xml.apache.org
> > Betreff: weird build problem - seems to be dependent on jar name
> >
> > We have successfully added some new functionality into
> > our copy of the public release of Apache Cocoon 2.0b2
> > This involved some tweaks to core code to hook in another
> > Java package. All went smoothly (adding our jar file
> > into $COCOON_HOME/lib and edits to src/org/...). Re-build
> > is fine and our new functionality works as expected.
> >
> > However, then i CVS checkout the whole cocoon_20_branch
> > and try to verify that our changes work with the most
> > recent code. The initial build is fine. Then i make the
> > exact same mods and try to re-build. Ant bombs with the
> > following obscure error and does not even get through
> > init phase. ant -v or ant -debug do not shed any light.
> >
> > A workaround solution is to rename our jar file so that
> > it begins with "z" i.e. zcatalog.jar
> > Now re-build runs perfectly. Why is that hack needed?
> >
> > Linux RedHat 7.1
> > java.vm.version=Blackdown-1.3.1-FCS
> > jakarta-tomcat-3.2.2
> >
> > Help please, days have been wasted trying to get past this.
> > thanks, David Crossley
> >
> > =================================================
> > Apache Cocoon 2 Build System
> > ----------------------------
> > Buildfile: build.xml
> >
> > BUILD FAILED
> >
> > java.lang.NoSuchMethodError
> > at
> > org.xml.sax.helpers.XMLReaderAdapter$AttributesAdapter.getName(XML
> ReaderAdapter.java:470)
> > at
> > org.apache.tools.ant.ProjectHelper$ProjectHandler.init(ProjectHelp
> > er.java:288)
> > at
> > org.apache.tools.ant.ProjectHelper$RootHandler.startElement(Projec
> > tHelper.java:262)
> > at
> > org.xml.sax.helpers.XMLReaderAdapter.startElement(XMLReaderAdapter
> > .java:329)
> > at org.apache.xerces.parsers.SAXParser.startElement(SAXParser.java:1376)
> > at
> > org.apache.xerces.validators.common.XMLValidator.callStartElement(
> > XMLValidator.java:1191)
> > at
> > org.apache.xerces.framework.XMLDocumentScanner.scanElement(XMLDocu
> > mentScanner.java:1862)
> > at
> > org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.d
> > ispatch(XMLDocumentScanner.java:1005)
> > at
> > org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocume
> > ntScanner.java:381)
> > at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1081)
> > at org.xml.sax.helpers.XMLReaderAdapter.parse(XMLReaderAdapter.java:223)
> > at javax.xml.parsers.SAXParser.parse(SAXParser.java:345)
> > at org.apache.tools.ant.ProjectHelper.parse(ProjectHelper.java:117)
> > at
> > org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.
> > java:85)
> > at org.apache.tools.ant.Main.runBuild(Main.java:403)
> > at org.apache.tools.ant.Main.main(Main.java:149)
> > =================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: weird build problem - seems to be dependent on jar name
Posted by Carsten Ziegeler <cz...@sundn.de>.
What was the original name of your jar file and which
classes (packages) did it contain (any sax or dom
package?)
Carsten
> -----Ursprüngliche Nachricht-----
> Von: David Crossley [mailto:crossley@indexgeo.com.au]
> Gesendet: Dienstag, 7. August 2001 04:23
> An: cocoon-dev@xml.apache.org
> Betreff: weird build problem - seems to be dependent on jar name
>
>
> We have successfully added some new functionality into
> our copy of the public release of Apache Cocoon 2.0b2
> This involved some tweaks to core code to hook in another
> Java package. All went smoothly (adding our jar file
> into $COCOON_HOME/lib and edits to src/org/...). Re-build
> is fine and our new functionality works as expected.
>
> However, then i CVS checkout the whole cocoon_20_branch
> and try to verify that our changes work with the most
> recent code. The initial build is fine. Then i make the
> exact same mods and try to re-build. Ant bombs with the
> following obscure error and does not even get through
> init phase. ant -v or ant -debug do not shed any light.
>
> A workaround solution is to rename our jar file so that
> it begins with "z" i.e. zcatalog.jar
> Now re-build runs perfectly. Why is that hack needed?
>
> Linux RedHat 7.1
> java.vm.version=Blackdown-1.3.1-FCS
> jakarta-tomcat-3.2.2
>
> Help please, days have been wasted trying to get past this.
> thanks, David Crossley
>
> =================================================
> Apache Cocoon 2 Build System
> ----------------------------
> Buildfile: build.xml
>
> BUILD FAILED
>
> java.lang.NoSuchMethodError
> at
> org.xml.sax.helpers.XMLReaderAdapter$AttributesAdapter.getName(XML
ReaderAdapter.java:470)
> at
> org.apache.tools.ant.ProjectHelper$ProjectHandler.init(ProjectHelp
> er.java:288)
> at
> org.apache.tools.ant.ProjectHelper$RootHandler.startElement(Projec
> tHelper.java:262)
> at
> org.xml.sax.helpers.XMLReaderAdapter.startElement(XMLReaderAdapter
> .java:329)
> at org.apache.xerces.parsers.SAXParser.startElement(SAXParser.java:1376)
> at
> org.apache.xerces.validators.common.XMLValidator.callStartElement(
> XMLValidator.java:1191)
> at
> org.apache.xerces.framework.XMLDocumentScanner.scanElement(XMLDocu
> mentScanner.java:1862)
> at
> org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.d
> ispatch(XMLDocumentScanner.java:1005)
> at
> org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocume
> ntScanner.java:381)
> at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1081)
> at org.xml.sax.helpers.XMLReaderAdapter.parse(XMLReaderAdapter.java:223)
> at javax.xml.parsers.SAXParser.parse(SAXParser.java:345)
> at org.apache.tools.ant.ProjectHelper.parse(ProjectHelper.java:117)
> at
> org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.
> java:85)
> at org.apache.tools.ant.Main.runBuild(Main.java:403)
> at org.apache.tools.ant.Main.main(Main.java:149)
> =================================================
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org