Re: Build failure
Sylvain Wallez wrote : > Olivier Billard wrote: > > >Salut Sylvain ! > > > >Seems that you won the jackpot ! > >A build from Eclipse doesn't work, but a build from command line works well. > >But it didn't worked with an old CVS... I didn't tried the second time. > > > >I think you're right : it may come from an other version of Xerces in > >Eclipse... Damned ! But I don't have any endorsed folder in my jdk or jre, > >and the other version of xerces is in another Eclipse project... It built > >well some days ago ! If only I hadn't go in hollyday... (or hadn't come back > >;) ) > > > > Golden rule number one : if something weird happens related to XML > handling (either parsing or XSLT), inspect (or suspect) the various > libraries that consitute the classpath ;-) Do you think that Eclipse projects could not be well separated, classpath-spoken ? My Cocoon CVS project contains only libs of the distrib... Bizarre... But I think you're right. If not, I don't know where the problem would come from. Thanks a lot, and have a good we ! (Nice weather, in Toulouse ?) -- Olivier
Re: Build failure
Olivier Billard wrote: Salut Sylvain ! Seems that you won the jackpot ! A build from Eclipse doesn't work, but a build from command line works well. But it didn't worked with an old CVS... I didn't tried the second time. I think you're right : it may come from an other version of Xerces in Eclipse... Damned ! But I don't have any endorsed folder in my jdk or jre, and the other version of xerces is in another Eclipse project... It built well some days ago ! If only I hadn't go in hollyday... (or hadn't come back ;) ) Golden rule number one : if something weird happens related to XML handling (either parsing or XSLT), inspect (or suspect) the various libraries that consitute the classpath ;-) Cheers, Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Build failure
Salut Sylvain ! Seems that you won the jackpot ! A build from Eclipse doesn't work, but a build from command line works well. But it didn't worked with an old CVS... I didn't tried the second time. I think you're right : it may come from an other version of Xerces in Eclipse... Damned ! But I don't have any endorsed folder in my jdk or jre, and the other version of xerces is in another Eclipse project... It built well some days ago ! If only I hadn't go in hollyday... (or hadn't come back ;) ) - Original Message - From: "Sylvain Wallez" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 19, 2003 3:22 PM Subject: Re: Build failure > Olivier Billard wrote: > > Salut Olivier ;-) > > >Is there any chance that it would come from my side ? > >Does it works for you ? > > > > > > Yep. Works fine here... > > What's your config and do you have a local.build.properties ? Do you > build from command line or from an IDE ? > > And more important, do you have a special version of Xerces in your > system classpath (best thing is to keep it empty) or the endorsed dir of > your JDK ? > > Sylvain > > -- > Sylvain Wallez Anyware Technologies > http://www.apache.org/~sylvain http://www.anyware-tech.com > { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } > Orixo, the opensource XML business alliance - http://www.orixo.com > > >
Re: Build failure
Olivier Billard wrote: Salut Olivier ;-) Is there any chance that it would come from my side ? Does it works for you ? Yep. Works fine here... What's your config and do you have a local.build.properties ? Do you build from command line or from an IDE ? And more important, do you have a special version of Xerces in your system classpath (best thing is to keep it empty) or the endorsed dir of your JDK ? Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Build failure
Is there any chance that it would come from my side ? Does it works for you ? Thanks in advance ! - Original Message - From: "Olivier Billard" <[EMAIL PROTECTED]> To: "Cocoon Dev" <[EMAIL PROTECTED]> Sent: Thursday, June 19, 2003 11:38 AM Subject: Build failure > Hi all, > > For several days, my "out of the box" Cocoon CVS doesn't build : > > compile-core: > > [copy] Copying 41 files to > E:\Dev\Jakarta\cocoon-2.1-dev\build\cocoon-2.1m3-dev\classes > > [copy] Copied 31 empty directories to > E:\Dev\Jakarta\cocoon-2.1-dev\build\cocoon-2.1m3-dev\classes > > [mkdir] Created dir: > E:\Dev\Jakarta\cocoon-2.1-dev\build\cocoon-2.1m3-dev\mocks > > [javac] Compiling 1 source file to > E:\Dev\Jakarta\cocoon-2.1-dev\build\cocoon-2.1m3-dev\mocks > > [javac] Compiling 520 source files to > E:\Dev\Jakarta\cocoon-2.1-dev\build\cocoon-2.1m3-dev\classes > > compile-scratchpad: > > [mkdir] Created dir: > E:\Dev\Jakarta\cocoon-2.1-dev\build\cocoon-2.1m3-dev\scratchpad\dest > > [copy] Copying 2 files to > E:\Dev\Jakarta\cocoon-2.1-dev\build\cocoon-2.1m3-dev\scratchpad\dest > > [copy] Copied 17 empty directories to > E:\Dev\Jakarta\cocoon-2.1-dev\build\cocoon-2.1m3-dev\scratchpad\dest > > [javac] Compiling 3 source files to > E:\Dev\Jakarta\cocoon-2.1-dev\build\cocoon-2.1m3-dev\mocks > > [javac] Compiling 60 source files to > E:\Dev\Jakarta\cocoon-2.1-dev\build\cocoon-2.1m3-dev\scratchpad\dest > > [javac] Note: > E:\Dev\Jakarta\cocoon-2.1-dev\src\scratchpad\src\org\apache\cocoon\ant\Cocoo > nTask.java uses or overrides a deprecated API. > > [javac] Note: Recompile with -deprecation for details. > > compile-deprecated: > > [mkdir] Created dir: > E:\Dev\Jakarta\cocoon-2.1-dev\build\cocoon-2.1m3-dev\deprecated > > [xpatch] BUILD FAILED: java.lang.IllegalArgumentException: No attributes are > implemented > > > >
Antwort: Re: Build Failure - SlideSource
The problem is in slide-webdavlib.jar in the Class org.apache.webdav.lib.WebdavSession public abstract class WebdavSession implements ConnectionInterceptor { . . . } This class implements org.apache.commons.httpclient.ConnectionInterceptor which is not available in commons-httpclient.jar. Volker |+---> || Ivelin Ivanov| || | || | || 02.07.2002 | || 04:52| || Bitte| || antworten an | || cocoon-dev | || | |+---> >| || | An: [EMAIL PROTECTED]| | Kopie: (Blindkopie: Volker Schmitt/BASF-AG/BASF)| | Thema: Re: Build Failure - SlideSource | >| You were right. Thanks. Stephan Michels wrote: > On Fri, 28 Jun 2002, Ivelin Ivanov wrote: > > >>Just tried a new build and got: >> >> [javac] >>C:\ivo\cvs\xml-cocoon2\build\cocoon\scratchpad\src\org\apache\cocoon >>\components\source\SlideSource.java:121: >>org.apache.cocoon.components.source.Sli >>deSource should be declared abstract; it does not define >>getContentLength() in org.apache.cocoon.components.source.SlideSource >> [javac] public class SlideSource implements Source, WriteableSource >> [javac]^ >> [javac] Note: Some input files use or override a deprecated API. >> [javac] Note: Recompile with -deprecation for details. >> [javac] 1 error >> >>BUILD FAILED >> >> >>Help! > > > The current CVS HEAD compile for me fine. The SlideSource also > implements the method getContentLength. Perhaps you have an old > snapshot? Or forget to make a ant clean? > > /** > * Return the content length of the content or -1 if the length is > * unknown > */ > public long getContentLength() > { > if (revisionDescriptor!=null) > return revisionDescriptor.getContentLength(); > > return -1; > } > > ___ > Stephan Michels EMail: [EMAIL PROTECTED] > ICQ: 115535699Tel: +49-030-314-21583 > +|+|+|+|+|+|+|-| > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > -- -= Ivelin =- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Build Failure - SlideSource
You were right. Thanks. Stephan Michels wrote: > On Fri, 28 Jun 2002, Ivelin Ivanov wrote: > > >>Just tried a new build and got: >> >> [javac] >>C:\ivo\cvs\xml-cocoon2\build\cocoon\scratchpad\src\org\apache\cocoon >>\components\source\SlideSource.java:121: >>org.apache.cocoon.components.source.Sli >>deSource should be declared abstract; it does not define >>getContentLength() in org.apache.cocoon.components.source.SlideSource >> [javac] public class SlideSource implements Source, WriteableSource >> [javac]^ >> [javac] Note: Some input files use or override a deprecated API. >> [javac] Note: Recompile with -deprecation for details. >> [javac] 1 error >> >>BUILD FAILED >> >> >>Help! > > > The current CVS HEAD compile for me fine. The SlideSource also > implements the method getContentLength. Perhaps you have an old > snapshot? Or forget to make a ant clean? > > /** > * Return the content length of the content or -1 if the length is > * unknown > */ > public long getContentLength() > { > if (revisionDescriptor!=null) > return revisionDescriptor.getContentLength(); > > return -1; > } > > ___ > Stephan Michels EMail: [EMAIL PROTECTED] > ICQ: 115535699Tel: +49-030-314-21583 > +|+|+|+|+|+|+|-| > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > -- -= Ivelin =- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Build failure
Thanks for reporting, Andrew. It's fixed now. Carsten > -Original Message- > From: Andrew Timberlake [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 05, 2002 1:47 PM > To: [EMAIL PROTECTED] > Subject: Build failure > > > The emacs project file was moved and has left the build broken > Here is a patch: > > > Index: build.xml > === > RCS file: /home/cvspublic/xml-cocoon2/build.xml,v > retrieving revision 1.225 > diff -u -r1.225 build.xml > --- build.xml 5 Jun 2002 11:29:30 - 1.225 > +++ build.xml 5 Jun 2002 11:46:22 - > @@ -198,7 +198,7 @@ > > > > - > + > value="${src.dir}/documentation/xdocs"/> > value="${src.dir}/documentation/images"/> > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: build failure HEAD: DatabaseSelectAction.java
Thanks David, Everything matches up correctly in cvs. I wonder if anyone will actually take advantage of that change. I know some people would have liked it six months ago. Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: build failure HEAD: DatabaseSelectAction.java
OK Tim, i have added the missing patch to 2.1 HEAD for acting/AbstractComplementaryConfigurableAction.java Please cross-check. --David Tim Myers wrote: > the last patch for AbstractComplementaryConfigurableAction is necessary to make any of it work. > > context:// has never worked in subsitemaps to get to the subsitemap's context. > > now file:file_in_subsitemap_directory.xml can be used as a configuration file in the directory. > > This is consistent with using file: for generators in the sitemap. > > It's probably not the cleanest approach to do the checking in AbstractComplementaryConfigurableAction, but atleast it's simple. > > Thanks for doing it to Christian's modular database stuff too. I didn't notice that until last night. > > Tim > > David Crossley wrote: > > Tim Myers wrote: > > > that's my fault. > > > Add the variable resolver as the second argument. > > > I have a patch to the patch that screwed that up posted > > > on this list... but it's buried in a thread. > > > Tim > > > > Hi Tim, i presume that you mean this thread ... > > > Re: [PATCH] "file: fix" for head > > > Date: Sun, 2 Dec 2001 19:55:05 -0500 > > > From: Tim Myers <[EMAIL PROTECTED]> > > > > I applied your patch to acting/DatabaseSelectAction.java > > However, it also needed a similar patch to > > scratchpad/./acting/ModularDatabaseAction.java > > HEAD will build now ... please cross-check. > > > > Your posting had another patch to > > acting/AbstractComplementaryConfigurableAction.java > > Does that still need to be applied to HEAD as well? > > --David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: build failure HEAD: DatabaseSelectAction.java
the last patch for AbstractComplementaryConfigurableAction is necessary to make any of it work. context:// has never worked in subsitemaps to get to the subsitemap's context. now file:file_in_subsitemap_directory.xml can be used as a configuration file in the directory. This is consistent with using file: for generators in the sitemap. It's probably not the cleanest approach to do the checking in AbstractComplementaryConfigurableAction, but atleast it's simple. Thanks for doing it to Christian's modular database stuff too. I didn't notice that until last night. Tim On Tue, Dec 04, 2001 at 03:35:52PM +1100, David Crossley wrote: > Tim Myers wrote: > > that's my fault. > > Add the variable resolver as the second argument. > > I have a patch to the patch that screwed that up posted > > on this list... but it's buried in a thread. > > Tim > > Hi Tim, i presume that you mean this thread ... > > Re: [PATCH] "file: fix" for head > > Date: Sun, 2 Dec 2001 19:55:05 -0500 > > From: Tim Myers <[EMAIL PROTECTED]> > > I applied your patch to acting/DatabaseSelectAction.java > However, it also needed a similar patch to > scratchpad/./acting/ModularDatabaseAction.java > HEAD will build now ... please cross-check. > > Your posting had another patch to > acting/AbstractComplementaryConfigurableAction.java > Does that still need to be applied to HEAD as well? > --David > > - > > David Crossley wrote: > > > I have been getting a build failure for HEAD for the last > > > couple of days. Build is OK for cocoon_20_branch - but then > > > 2.0 does not contain acting/DatabaseSelectAction.java > > > I see from CVSview that recent commits were done to some > > > classes in cocoon/acting/ > > > > > > --- > > > [crossley@igacer xml-cocoon2]$ ./build.sh -Dinclude.webapp.libs=yes > > > -Dinstall.war=$TOMCAT_HOME/webapps install > > > ... > > > ... > > > /usr/local/cvs/xml-cocoon2/build/cocoon/src/org/apache/coc > > > oon/acting/DatabaseSelectAction.java:58: > > > Wrong number of arguments in method. > > > this.getConfiguration(param.getParameter("descriptor", > > > (String) this.settings.get("descriptor")), > > > param.getParameterAsBoolean("reloadable",reloadable)); > > > --- > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: build failure HEAD: DatabaseSelectAction.java
Tim Myers wrote: > that's my fault. > Add the variable resolver as the second argument. > I have a patch to the patch that screwed that up posted > on this list... but it's buried in a thread. > Tim Hi Tim, i presume that you mean this thread ... > Re: [PATCH] "file: fix" for head > Date: Sun, 2 Dec 2001 19:55:05 -0500 > From: Tim Myers <[EMAIL PROTECTED]> I applied your patch to acting/DatabaseSelectAction.java However, it also needed a similar patch to scratchpad/./acting/ModularDatabaseAction.java HEAD will build now ... please cross-check. Your posting had another patch to acting/AbstractComplementaryConfigurableAction.java Does that still need to be applied to HEAD as well? --David - > David Crossley wrote: > > I have been getting a build failure for HEAD for the last > > couple of days. Build is OK for cocoon_20_branch - but then > > 2.0 does not contain acting/DatabaseSelectAction.java > > I see from CVSview that recent commits were done to some > > classes in cocoon/acting/ > > > > --- > > [crossley@igacer xml-cocoon2]$ ./build.sh -Dinclude.webapp.libs=yes > > -Dinstall.war=$TOMCAT_HOME/webapps install > > ... > > ... > > /usr/local/cvs/xml-cocoon2/build/cocoon/src/org/apache/coc > > oon/acting/DatabaseSelectAction.java:58: > > Wrong number of arguments in method. > > this.getConfiguration(param.getParameter("descriptor", > > (String) this.settings.get("descriptor")), > > param.getParameterAsBoolean("reloadable",reloadable)); > > --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: build failure HEAD: DatabaseSelectAction.java
that's my fault. Add the variable resolver as the second argument. I have a patch to the patch that screwed that up posted on this list... but it's buried in a thread. Tim On Tue, Dec 04, 2001 at 01:31:50PM +1100, David Crossley wrote: > I have been getting a build failure for HEAD for the last > couple of days. Build is OK for cocoon_20_branch - but then > 2.0 does not contain acting/DatabaseSelectAction.java > I see from CVSview that recent commits were done to some > classes in cocoon/acting/ > > --- > [crossley@igacer xml-cocoon2]$ ./build.sh -Dinclude.webapp.libs=yes > -Dinstall.war=$TOMCAT_HOME/webapps install > ... > ... > /usr/local/cvs/xml-cocoon2/build/cocoon/src/org/apache/coc > oon/acting/DatabaseSelectAction.java:58: > Wrong number of arguments in method. > this.getConfiguration(param.getParameter("descriptor", > (String) this.settings.get("descriptor")), > param.getParameterAsBoolean("reloadable",reloadable)); > --- > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: build failure (no Php) after latest changes build.xml
> > Yes, use the task depend: In this example classes in the ${build.classes} directory will be removed if they depend on out-of-date classes. Classes are considered out of date with respect to the source in the ${java.dir} directory using the same mechanism as the javac task. In this instance the depend task caches its dependency information in the depcache directory. bye bernhard > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]