Re: dom4j
Maarten Coene wrote: Hi, I have 3 questions regarding dom4j. 1. the project is failing because of this error: BUILD FAILED java.lang.NoClassDefFoundError: org/xml/sax/ext/Attributes2 at org.apache.xerces.parsers.AbstractSAXParser.init(Unknown Source) at org.apache.xerces.parsers.SAXParser.init(Unknown Source) at org.apache.xerces.parsers.SAXParser.init(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.init(Unknown Source) at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source) at org.apache.tools.ant.util.JAXPUtils.newSAXParser(JAXPUtils.java:212) at org.apache.tools.ant.util.JAXPUtils.getNamespaceXMLReader(JAXPUtils.java:169) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:187) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:140) at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:90) at org.apache.tools.ant.Main.runBuild(Main.java:645) at org.apache.tools.ant.Main.startAnt(Main.java:188) at org.apache.tools.ant.Main.start(Main.java:151) at org.apache.tools.ant.Main.main(Main.java:229) Any idea what's going wrong? 2. I will start working on a new major version of dom4j, this will probably cause a lot of build failures... I have created a branch in CVS for maintaining the current dom4j 1.x releases. I think it would be good if gump is using this branch (DOM4J_1_X_BRANCH) instead of the MAIN branch. Can the gump project descriptor of dom4j be changed to accomplish this? 3. I have also upgraded the pull-parser (xpp2) used by dom4j to a new version. I think this will cause problems as well with the current project descriptor because the jar name has been changed to pull-parser-2.1.10.jar. This has only be done in the DOM4J_1_X_BRANCH branch. regards, Maarten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/dom4j-tp57563p19264598.html Sent from the Gump mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
dom4j
Hi, I have 3 questions regarding dom4j. 1. the project is failing because of this error: BUILD FAILED java.lang.NoClassDefFoundError: org/xml/sax/ext/Attributes2 at org.apache.xerces.parsers.AbstractSAXParser.init(Unknown Source) at org.apache.xerces.parsers.SAXParser.init(Unknown Source) at org.apache.xerces.parsers.SAXParser.init(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.init(Unknown Source) at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source) at org.apache.tools.ant.util.JAXPUtils.newSAXParser(JAXPUtils.java:212) at org.apache.tools.ant.util.JAXPUtils.getNamespaceXMLReader(JAXPUtils.java:169) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:187) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:140) at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:90) at org.apache.tools.ant.Main.runBuild(Main.java:645) at org.apache.tools.ant.Main.startAnt(Main.java:188) at org.apache.tools.ant.Main.start(Main.java:151) at org.apache.tools.ant.Main.main(Main.java:229) Any idea what's going wrong? 2. I will start working on a new major version of dom4j, this will probably cause a lot of build failures... I have created a branch in CVS for maintaining the current dom4j 1.x releases. I think it would be good if gump is using this branch (DOM4J_1_X_BRANCH) instead of the MAIN branch. Can the gump project descriptor of dom4j be changed to accomplish this? 3. I have also upgraded the pull-parser (xpp2) used by dom4j to a new version. I think this will cause problems as well with the current project descriptor because the jar name has been changed to pull-parser-2.1.10.jar. This has only be done in the DOM4J_1_X_BRANCH branch. regards, Maarten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dom4j
On Fri, 20 May 2005, Maarten Coene [EMAIL PROTECTED] wrote: 1. the project is failing because of this error: Xerces has switched to the newer SAX version of JAXP 1.3. It probably works once Gump starts to build again since I added JAXP 1.3's sax.jar as a dependency to the dom4j build. 2. I will start working on a new major version of dom4j, this will probably cause a lot of build failures... I have created a branch in CVS for maintaining the current dom4j 1.x releases. I think it would be good if gump is using this branch (DOM4J_1_X_BRANCH) instead of the MAIN branch. Can the gump project descriptor of dom4j be changed to accomplish this? Sure. We could keep building HEAD in addition (but make all dependent projects use the stable branch), if you want to. 3. I have also upgraded the pull-parser (xpp2) used by dom4j to a new version. If there is a new version and Gump is using an old one, upgrading is absolutely in line with Gump's goals. We should probably pull the project definition from the dom4j descriptor completely and make xpp2 an installed package. Where do I find the latest release of it? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dom4j
Stefan Bodewig wrote: On Fri, 20 May 2005, Maarten Coene [EMAIL PROTECTED] wrote: 1. the project is failing because of this error: Xerces has switched to the newer SAX version of JAXP 1.3. It probably works once Gump starts to build again since I added JAXP 1.3's sax.jar as a dependency to the dom4j build. ok thanks! 2. I will start working on a new major version of dom4j, this will probably cause a lot of build failures... I have created a branch in CVS for maintaining the current dom4j 1.x releases. I think it would be good if gump is using this branch (DOM4J_1_X_BRANCH) instead of the MAIN branch. Can the gump project descriptor of dom4j be changed to accomplish this? Sure. We could keep building HEAD in addition (but make all dependent projects use the stable branch), if you want to. that sounds like a good idea. I hope this doesn't require a lot of work on your side? 3. I have also upgraded the pull-parser (xpp2) used by dom4j to a new version. If there is a new version and Gump is using an old one, upgrading is absolutely in line with Gump's goals. We should probably pull the project definition from the dom4j descriptor completely and make xpp2 an installed package. Where do I find the latest release of it? The home-page of this xpp2 project is http://www.extreme.indiana.edu/xgws/xsoap/xpp/xpp2/index.html where I can't find a link to some CVS system hosting the sources. But there seems to be a web-interface containing all the files (including build files, sources, required libs, etc): http://www.extreme.indiana.edu/xgws/xsoap/xpp/download/PullParser2/ thanks, Maarten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dom4j
On Fri, 20 May 2005, Maarten Coene [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: Sure. We could keep building HEAD in addition (but make all dependent projects use the stable branch), if you want to. that sounds like a good idea. Done. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dom4j and xpp3
On Fri, 10 Sep 2004, Maarten Coene [EMAIL PROTECTED] wrote: No, both xpp2 and xpp3 are required. OK, should be fixed now. We won't see any effect at all, though. XOM fails to build, probably because it now expects JDK 1.5 around, but I can't get it to build using JDK 1.5 either. Even if I did, Jaxen, which requires XOM, doesn't build using JDK 1.5 because of variables called enum. And through this chain we won't see any attempts to build dom4j anytime soon, sorry. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dom4j and xpp3
On Wed, 08 Sep 2004, Maarten Coene [EMAIL PROTECTED] wrote: dom4j now needs the xpp3 parser... Instead of xpp2, I'll assume. Will take care of it. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dom4j and xpp3
No, both xpp2 and xpp3 are required. thanks, Maarten Stefan Bodewig wrote: On Wed, 08 Sep 2004, Maarten Coene [EMAIL PROTECTED] wrote: dom4j now needs the xpp3 parser... Instead of xpp2, I'll assume. Will take care of it. Stefan - 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]
dom4j and xpp3
Hi, dom4j now needs the xpp3 parser... could someone please modify the project descriptor? thanks, Maarten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dom4j] add jaxme api to project descriptor
On Mon, 02 Aug 2004, Maarten Coene [EMAIL PROTECTED] wrote: I need the jaxme api to be added to the dom4j project descriptor. Done Stefan -- http://stefanbodewig.blogger.de/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
dom4j and jtidy
Hi, dom4j no longer depends on jtidy to run its junit tests. Could someone please remove that dependency from the project descriptor? thanks, Maarten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dom4j and jtidy
On Tue, 3 Aug 2004, Maarten Coene wrote: dom4j no longer depends on jtidy to run its junit tests. Could someone please remove that dependency from the project descriptor? Done, removed for both the build and the tests (since they are one project.) regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dom4j] add jaxme api to project descriptor
Hi, I need the jaxme api to be added to the dom4j project descriptor. Can someone do this for me? thanks, Maarten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Extra library for dom4j required
Hi, I've added a unit test to test some of the STAX functionality of dom4j. In order to really test this, I need a reference implementation of this STAX api. Can someone add the following line to the dom4j project descriptor: depend project=stax ids=ri/ (please verify this as I'm not very familiar with gump) thanks, Maarten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
dom4j project-descriptor clean up
Hi, I was taking a look at the dom4j gump descriptor and compared it to the maven project.xml descriptor of dom4j, and I noticed some old dependencies that are no longer required by dom4j. I think the following projects can be removed from the dom4j descriptor - xml-fop - xmldb - tranquilo (is this the same as the xsdlib project ) - msv (in fact, dom4j only need the xsdlib.jar, not msv.jar) - ant (or is this needed by gump to execute the build.xml file?) In addition, the following dependencies should be added to the project descriptor: - xsdlib - xml-apis regards, Maarten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dom4j project-descriptor clean up
On Thu, 24 Jun 2004, Maarten Coene [EMAIL PROTECTED] wrote: I was taking a look at the dom4j gump descriptor and compared it to the maven project.xml descriptor of dom4j, and I noticed some old dependencies that are no longer required by dom4j. I will look into it. Gump uses Ant to build dom4j, not Maven - so Ant really is required. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dom4j project-descriptor clean up
On Thu, 24 Jun 2004, Stefan Bodewig [EMAIL PROTECTED] wrote: I will look into it. Builds fine without them. Thanks Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
msv and dom4j (was Re: BATCH: Unable to send...)
On Wed, 23 Jun 2004, Maarten Coene [EMAIL PROTECTED] wrote: Yes, I noticed it too yesterday. I just downloaded these other ones from ibiblio ( http://www.ibiblio.org/maven/msv/jars/ ), but I'm not sure if they are official now since SUN doesn't list them ... Look at java.net, there seems to be some ongoing development. I've turned msv into a project Gump builds, which was more work than I had expected since msv's build process is, uhm, strange. dom4j builds successfully against the Gump built msv on my box. I'll see what I can do to make the tests run agains both versions. This is probably going to benefit your users anyway since they are likely to stick with the released official version as well. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
dom4j tests fail (was: BATCH: Unable to send...)
Hi, it seems that the following paths should be added to the classpath: ./build/classes and . The ./build/classes contains the dom4j class files and junit testfiles, the last path is needed for the unit tests to access the resources in the ./xml directory But, I don't know how to tell gump how to do this. What I don't understand is that these paths are added to the classpath in the test target of the Ant build.xml file, but gump doesn't seem to use them. Is this correct? I'm new to gump and I'm just trying to understand what's happening here. regards, Maarten Adam R. B. Jack wrote: A DOM4J fix would benefit 86 other projects, so thanks in advance... http://brutus.apache.org:8080/gump/project_todos.html http://brutus.apache.org:8080/gump/dom4j/dom4j/index.html#Project-level+Files Hmm, this show 'class not found'. I wonder if this is as simple as the test classes not being told to Gump in a work entry -- or some other classpath issues. http://brutus.apache.org:8080/gump/dom4j/dom4j/gump_file/TEST-org.dom4j.TestAddAttribute.xml.html error message=org.dom4j.TestAddAttribute type=java.lang.ClassNotFoundExceptionjava.lang.ClassNotFoundException: org.dom4j.TestAddAttribute at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) BTW: This is the classpath: http://brutus.apache.org:8080/gump/dom4j/dom4j/details.html#Classpath regards, Adam - 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]
Re: dom4j tests fail
On Tue, 22 Jun 2004, Maarten Coene [EMAIL PROTECTED] wrote: it seems that the following paths should be added to the classpath: ./build/classes and . The ./build/classes contains the dom4j class files and junit testfiles, the last path is needed for the unit tests to access the resources in the ./xml directory Already done - tests still fail for me, see my other mail (waiting in my mail queue since more than four hours now). What I don't understand is that these paths are added to the classpath in the test target of the Ant build.xml file, but gump doesn't seem to use them. Is this correct? Absolutely. Gump runs Ant in a special mode that makes Ant ignore all classpath constructs of the build file. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dom4j tests fail (was: BATCH: Unable to send...)
But, I don't know how to tell gump how to do this. http://gump.apache.org/metadata/project.html#work What I don't understand is that these paths are added to the classpath in the test target of the Ant build.xml file, but gump doesn't seem to use them. Is this correct? I'm new to gump and I'm just trying to understand what's happening here. We need to add this to an FAQ but basically Gump overrides the Ant build file so that no stray (non-Gumped) classes get in (unintentionally). Ant allows this. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DOM4J on Gump
http://brutus.apache.org:8080/gump/dom4j/dom4j/index.html shows a failure at: http://brutus.apache.org:8080/gump/dom4j/dom4j/gump_file/TEST-org.dom4j.datatype.TestDatatype2.xml.html regards Adam - Original Message - From: Maarten Coene [EMAIL PROTECTED] To: Gump code and data [EMAIL PROTECTED] Sent: Tuesday, June 22, 2004 8:27 AM Subject: Re: BATCH: Unable to send... I think the problem is that gump uses another msv version than dom4j does. If I take a look at the classpath I see: gump: msv-20030225/msv.jar;msv-20030225/xsdlib.jar dom4j: msv-20030807.jar;xsdlib-20030807.jar it seems that the gump jars are older versions, perhaps they could be upgraded? Maarten Stefan Bodewig wrote: On Mon, 21 Jun 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: Hmm, this show 'class not found'. I wonder if this is as simple as the test classes not being told to Gump in a work entry -- or some other classpath issues. Good catch. I also had to add . as a work entry since some tests try to load resources from /xml and those are not copied into build/classes or somewhere close to that. At least one test still fails on my machine, but it looks like a locale/timezone issue[1] so it may work on brutus. Stefan Footnotes: [1] In case a dom4j developer is listening, three failures all more or less looking the same as testcase classname=org.dom4j.datatype.TestDatatype2 name=testSchema time=0.665 error message=value mismatch in testDateElement:expected java.util.GregorianCalendar[time=100448640,areFieldsSet=false,areAllFiel dsSet=false,lenient=true,zone=java.util.SimpleTimeZone[id=XSD apos;Zapos; timezone,offset=0,dstSavings=360,useDaylight=false,startYear=0,startMode =0,startMonth=0,startDay=0,startDayOfWeek=0,startTime=0,startTimeMode=0,endM ode=0,endMonth=0,endDay=0,endDayOfWeek=0,endTime=0,endTimeMode=0],firstDayOf Week=2,minimalDaysInFirstWeek=4,ERA=?,YEAR=2001,MONTH=9,WEEK_OF_YEAR=?,WEEK_ OF_MONTH=?,DAY_OF_MONTH=31,DAY_OF_YEAR=?,DAY_OF_WEEK=?,DAY_OF_WEEK_IN_MONTH= ?,AM_PM=?,HOUR=?,HOUR_OF_DAY=?,MINUTE=?,SECOND=?,MILLISECOND=?,ZONE_OFFSET=? ,DST_OFFSET=?], retrieved java.util.GregorianCalendar[time=100448640,areFieldsSet=false,areAllFiel dsSet=false,lenient=true,zone=java.util.SimpleTimeZone[id=custom,offset=0,ds tSavings=360,useDaylight=false,startYear=0,startMode=0,startMonth=0,star tDay=0,startDayOfWeek=0,startTime=0,startTimeMode=0,endMode=0,endMonth=0,end Day=0,endDayOfWeek=0,endTime=0,endTimeMode=0],firstDayOfWeek=2,minimalDaysIn FirstWeek=4,ERA=?,YEAR=2001,MONTH=9,WEEK_OF_YEAR=?,WEEK_OF_MONTH=?,DAY_OF_MO NTH=31,DAY_OF_YEAR=?,DAY_OF_WEEK=?,DAY_OF_WEEK_IN_MONTH=?,AM_PM=?,HOUR=?,HOU R_OF_DAY=?,MINUTE=?,SECOND=?,MILLISECOND=?,ZONE_OFFSET=?,DST_OFFSET=?] type=java.lang.Exceptionjava.lang.Exception: value mismatch in testDateElement:expected java.util.GregorianCalendar[time=100448640,areFieldsSet=false,areAllFiel dsSet=false,lenient=true,zone=java.util.SimpleTimeZone[id=XSD apos;Zapos; timezone,offset=0,dstSavings=360,useDaylight=false,startYear=0,startMode =0,startMonth=0,startDay=0,startDayOfWeek=0,startTime=0,startTimeMode=0,endM ode=0,endMonth=0,endDay=0,endDayOfWeek=0,endTime=0,endTimeMode=0],firstDayOf Week=2,minimalDaysInFirstWeek=4,ERA=?,YEAR=2001,MONTH=9,WEEK_OF_YEAR=?,WEEK_ OF_MONTH=?,DAY_OF_MONTH=31,DAY_OF_YEAR=?,DAY_OF_WEEK=?,DAY_OF_WEEK_IN_MONTH= ?,AM_PM=?,HOUR=?,HOUR_OF_DAY=?,MINUTE=?,SECOND=?,MILLISECOND=?,ZONE_OFFSET=? ,DST_OFFSET=?], retrieved java.util.GregorianCa false,areAllFieldsSet=false,lenient=true,zone=java.util.SimpleTimeZone[id=cu stom,offset=0,dstSavings=360,useDaylight=false,startYear=0,startMode=0,s tartMonth=0,startDay=0,startDayOfWeek=0,startTime=0,startTimeMode=0,endMode= 0,endMonth=0,endDay=0,endDayOfWeek=0,endTime=0,endTimeMode=0],firstDayOfWeek =2,minimalDaysInFirstWeek=4,ERA=?,YEAR=2001,MONTH=9,WEEK_OF_YEAR=?,WEEK_OF_M ONTH=?,DAY_OF_MONTH=31,DAY_OF_YEAR=?,DAY_OF_WEEK=?,DAY_OF_WEEK_IN_MONTH=?,AM _PM=?,HOUR=?,HOUR_OF_DAY=?,MINUTE=?,SECOND=?,MILLISECOND=?,ZONE_OFFSET=?,DST _OFFSET=?] at org.dom4j.datatype.TestDatatype2.validateData(TestDatatype2.java:120) at org.dom4j.datatype.TestDatatype2.validateDateElement(TestDatatype2.java:98) at org.dom4j.datatype.TestDatatype2.validateDocumentWithSchema(TestDatatype2.ja va:78) at org.dom4j.datatype.TestDatatype2.testSchema(TestDatatype2.java:55) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) /error /testcase - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
[PATCH] nag email for dom4j project
Michael Davey wrote: Maarten Coene wrote: Hi, is it possible to send an email to the dom4j-dev emaillist everytime the build of dom4j fails? The address is [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] is the correct place for this request. I've copied this reply there. Will this do the trick? % snip Index: dom4j.xml === RCS file: /home/cvspublic/gump/project/dom4j.xml,v retrieving revision 1.37 diff -u -r1.37 dom4j.xml --- dom4j.xml 16 Jun 2004 07:56:04 - 1.37 +++ dom4j.xml 17 Jun 2004 13:41:38 - @@ -48,6 +48,7 @@ depend project=junitperf/ jar name=build/dom4j.jar id=dom4j/ license name=LICENSE.txt/ +nag from=Maarten Coene lt;[EMAIL PROTECTED]gt; to=[EMAIL PROTECTED] / /project project name=xpp --- % snip Index: dom4j.xml === RCS file: /home/cvspublic/gump/project/dom4j.xml,v retrieving revision 1.37 diff -u -r1.37 dom4j.xml --- dom4j.xml 16 Jun 2004 07:56:04 - 1.37 +++ dom4j.xml 17 Jun 2004 13:45:46 - @@ -48,6 +48,7 @@ depend project=junitperf/ jar name=build/dom4j.jar id=dom4j/ license name=LICENSE.txt/ +nag from=Maarten Coene lt;[EMAIL PROTECTED]gt; to=[EMAIL PROTECTED] / /project project name=xpp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nag email for dom4j project
oops, I just blindly copy-pasted the mailinglist address from the welcome message I've received after subscribing. Sorry for any inconvenience. Maarten This is part of the message I've received after subscribing to [EMAIL PROTECTED]: Welcome to [EMAIL PROTECTED] Please save this message so that you know the address you are subscribed under, in case you later want to unsubscribe or change your subscription address. perhaps it should be changed to contain the correct address ? Michael Davey wrote: Maarten Coene wrote: Hi, is it possible to send an email to the dom4j-dev emaillist everytime the build of dom4j fails? The address is [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] is the correct place for this request. I've copied this reply there. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nag email for dom4j project
Maarten Coene wrote: Hi, is it possible to send an email to the dom4j-dev emaillist everytime the build of dom4j fails? The address is [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] is the correct place for this request. I've copied this reply there. -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jaxen-interest] [GUMP@lsd]: jaxen/jaxen-from-packaged-dom4j failed
Looks like they may have made another change that is causing the XTags
taglib in Jakarta Taglibs to fail now... ;-(
--
Martin Cooper
Adam R. B. Jack [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
This patch was applied by Jaxen folk.
It was good of these guys to let us have an ant target that skips the
tests,
but builds a jar of compiled code. Hopefully we can get back to working on
Cocoon and above, and the others of the 88...
regards,
Adam
- Original Message -
From: Adam R. B. Jack [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, May 03, 2004 7:16 AM
Subject: Re: [jaxen-interest] [EMAIL PROTECTED]: jaxen/jaxen-from-packaged-dom4j
failed
Folks,
Could I make another request to get this small addition made to your
build.xml? I know the correct long term solution is to make the test
pass
but, for that, notification e-mails will still be delivered. Allowing us
to
split compilation from unit testing allows us to start work on interface
testing, and above, for 88 projects now.
We were seeing communities make significant progress with their nightly
Gumps, and had worked up to some projects (cocoon, others) not Gumped
for
a
long long time. We've lost some momentum due to this one failure, and
would
really like to see communities be able to get back to working on those
things.
I've attached a patch (generated by Eclipse) if it helps.
regards,
Adam
- Original Message -
From: Adam R. B. Jack [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, April 26, 2004 7:55 AM
Subject: Re: [jaxen-interest] [EMAIL PROTECTED]:
jaxen/jaxen-from-packaged-dom4j
failed
All,
It would be really helpful to these other 88 projects/communities if
we
could get passed the single test case failure, to allow a successful
build.
I think this is the one:
http://lsd.student.utwente.nl/gump/jaxen/jaxen-from-packaged-dom4j/gump_file/TEST-org.jaxen.dom4j.DocumentNavigatorTest.xml.html
If the test that is causing the build failure is valid, but not easily
be
fixed, could somebody create a 'gump' target in the build.xml that
allows
compile/jar without unit test? This would allow us to split the gump
work
into two, a compile and a separate test, so a 99.9% working Jaxen can
be
built upon by other projects.
Looking at the build file, this following isn't pretty, but seems
workable.
Clone the 'jar' target to one called 'jar-untested', and remove the
dependency on 'test' (so only upon compile). Then add a 'gump' target
to
depend upon that.
target name=jar-untested description=o Jar untested code
depends=compile
jar jarfile=target/${final.name}.jar
excludes=**/package.html
basedir=${classesdir} /
/target
target name=gump description=o Compile/Jar for Gump
Integration
depends=compile, jar-untested /
Thanks in advance for your consideration.
regards,
Adam
- Original Message -
From: Jaxen Gump [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, April 26, 2004 5:27 AM
Subject: [jaxen-interest] [EMAIL PROTECTED]: jaxen/jaxen-from-packaged-dom4j
failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For help
understanding the request please visit
http://gump.apache.org/nagged.html,
and/or contact [EMAIL PROTECTED]
Project jaxen-from-packaged-dom4j has an issue affecting its
community
integration.
This issue affects 88 projects, and has been outstanding for 12
runs.
The following are affected:
- ant-xdocs-proposal : Java based build tool
- cocoon : Java XML Framework
- cocoon-block-apples : Java XML Framework
- cocoon-block-asciiart : Java XML Framework
- cocoon-block-authentication-fw : Java XML Framework
- cocoon-block-axis : Java XML Framework
- cocoon-block-batik : Java XML Framework
- cocoon-block-bsf : Java XML Framework
- cocoon-block-chaperon : Java XML Framework
- cocoon-block-cron : Java XML Framework
- cocoon-block-databases : Java XML Framework
- cocoon-block-deli : Java XML Framework
- cocoon-block-eventcache : Java XML Framework
- cocoon-block-fop : Java XML Framework
- cocoon-block-forms : Java XML Framework
- cocoon-block-hsqldb : Java XML Framework
- cocoon-block-html : Java XML Framework
- cocoon-block-itext : Java XML Framework
- cocoon-block-javaflow : Java XML Framework
- cocoon-block-jfor : Java XML Framework
- cocoon-block-jms : Java XML Framework
- cocoon-block-jsp : Java XML Framework
- cocoon-block-linkrewriter : Java XML Framework
- cocoon-block-linotype : Java XML Framework
- cocoon-block-lucene : Java XML
Fw: [jaxen-interest] [GUMP@lsd]: jaxen/jaxen-from-packaged-dom4j failed
This patch was applied by Jaxen folk.
It was good of these guys to let us have an ant target that skips the tests,
but builds a jar of compiled code. Hopefully we can get back to working on
Cocoon and above, and the others of the 88...
regards,
Adam
- Original Message -
From: Adam R. B. Jack [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, May 03, 2004 7:16 AM
Subject: Re: [jaxen-interest] [EMAIL PROTECTED]: jaxen/jaxen-from-packaged-dom4j
failed
Folks,
Could I make another request to get this small addition made to your
build.xml? I know the correct long term solution is to make the test pass
but, for that, notification e-mails will still be delivered. Allowing us
to
split compilation from unit testing allows us to start work on interface
testing, and above, for 88 projects now.
We were seeing communities make significant progress with their nightly
Gumps, and had worked up to some projects (cocoon, others) not Gumped for
a
long long time. We've lost some momentum due to this one failure, and
would
really like to see communities be able to get back to working on those
things.
I've attached a patch (generated by Eclipse) if it helps.
regards,
Adam
- Original Message -
From: Adam R. B. Jack [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, April 26, 2004 7:55 AM
Subject: Re: [jaxen-interest] [EMAIL PROTECTED]: jaxen/jaxen-from-packaged-dom4j
failed
All,
It would be really helpful to these other 88 projects/communities if we
could get passed the single test case failure, to allow a successful
build.
I think this is the one:
http://lsd.student.utwente.nl/gump/jaxen/jaxen-from-packaged-dom4j/gump_file/TEST-org.jaxen.dom4j.DocumentNavigatorTest.xml.html
If the test that is causing the build failure is valid, but not easily
be
fixed, could somebody create a 'gump' target in the build.xml that
allows
compile/jar without unit test? This would allow us to split the gump
work
into two, a compile and a separate test, so a 99.9% working Jaxen can be
built upon by other projects.
Looking at the build file, this following isn't pretty, but seems
workable.
Clone the 'jar' target to one called 'jar-untested', and remove the
dependency on 'test' (so only upon compile). Then add a 'gump' target to
depend upon that.
target name=jar-untested description=o Jar untested code
depends=compile
jar jarfile=target/${final.name}.jar
excludes=**/package.html
basedir=${classesdir} /
/target
target name=gump description=o Compile/Jar for Gump Integration
depends=compile, jar-untested /
Thanks in advance for your consideration.
regards,
Adam
- Original Message -
From: Jaxen Gump [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, April 26, 2004 5:27 AM
Subject: [jaxen-interest] [EMAIL PROTECTED]: jaxen/jaxen-from-packaged-dom4j
failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For help
understanding the request please visit
http://gump.apache.org/nagged.html,
and/or contact [EMAIL PROTECTED]
Project jaxen-from-packaged-dom4j has an issue affecting its community
integration.
This issue affects 88 projects, and has been outstanding for 12 runs.
The following are affected:
- ant-xdocs-proposal : Java based build tool
- cocoon : Java XML Framework
- cocoon-block-apples : Java XML Framework
- cocoon-block-asciiart : Java XML Framework
- cocoon-block-authentication-fw : Java XML Framework
- cocoon-block-axis : Java XML Framework
- cocoon-block-batik : Java XML Framework
- cocoon-block-bsf : Java XML Framework
- cocoon-block-chaperon : Java XML Framework
- cocoon-block-cron : Java XML Framework
- cocoon-block-databases : Java XML Framework
- cocoon-block-deli : Java XML Framework
- cocoon-block-eventcache : Java XML Framework
- cocoon-block-fop : Java XML Framework
- cocoon-block-forms : Java XML Framework
- cocoon-block-hsqldb : Java XML Framework
- cocoon-block-html : Java XML Framework
- cocoon-block-itext : Java XML Framework
- cocoon-block-javaflow : Java XML Framework
- cocoon-block-jfor : Java XML Framework
- cocoon-block-jms : Java XML Framework
- cocoon-block-jsp : Java XML Framework
- cocoon-block-linkrewriter : Java XML Framework
- cocoon-block-linotype : Java XML Framework
- cocoon-block-lucene : Java XML Framework
- cocoon-block-mail : Java XML Framework
- cocoon-block-midi : Java XML Framework
- cocoon-block-naming : Java XML Framework
- cocoon-block-ojb : Java XML Framework
- cocoon-block-paranoid : Java XML Framework
- cocoon-block-petstore : Java XML Framework
- cocoon-block-php
