Hi guys, I think I found the problem, but since I cannot reproduce this behaviour I am clueless if this will work. I think the problem is here:
http://jira.codehaus.org/browse/SUREFIRE-98 I changed the version of the Surefire plugin we use to the latest one. I have commited it. Anything else before I make the RC-3 and cast the vote? Thanks again, Petar. On Tue, Jan 20, 2009 at 10:51 PM, Petar Tahchiev < paranoiabla.li...@gmail.com> wrote: > Hi Sebb, > > I removed the CDDL license and described the servlet-api as > an Apache 2.0 licensed. I also added the Apache license headers. > I also changed the version of AspectJ we are using. > > About the test failures that you mention I think they are different > from what Henry is getting. Anyways I am unable to reproduce them :-( > > What should I do? Do I need to make a RC-3 and call the vote on it? > > Thanks for the tips guys. > > > On Tue, Jan 20, 2009 at 9:42 PM, sebb <seb...@gmail.com> wrote: > >> On 20/01/2009, sebb <seb...@gmail.com> wrote: >> > On 20/01/2009, Petar Tahchiev <paranoiabla.li...@gmail.com> wrote: >> > > Hi all, >> > > >> > > maybe I am too impatient, but has anybody tried the artifacts? >> > >> > >> > 1 minor problem - the .asc files should be detached ascii signatures, >> > not signed archives. >> > No need to recreate the RC, just recreate the .asc files. >> > >> > We don't normally provide binary .sig files - they can be deleted. >> > >> > I'm still looking at other aspects of the RC. >> > >> >> The servlet-api-2.4.jar file is an Apache version, as Henri already >> mentioned. >> The cddl licence should be deleted, and the README updated. >> >> Like Henri, I also get test failures: >> >> [surefire] Tests run: 5, Failures: 3, Errors: 0, Time elapsed: 0.25 >> sec <<<<<<<< FAILURE !! >> [surefire] Running >> org.apache.cactus.integration.ant.deployment.webapp.TestWarArchive >> [surefire] Tests run: 3, Failures: 3, Errors: 0, Time elapsed: 0.031 >> sec <<<<<<<< FAILURE !! >> [surefire] Running >> org.apache.cactus.integration.ant.deployment.webapp.TestWebXml >> [surefire] Tests run: 54, Failures: 0, Errors: 0, Time elapsed: 2.359 sec >> [surefire] Running >> org.apache.cactus.integration.ant.deployment.webapp.TestWebXmlVersion >> [surefire] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.093 sec >> [surefire] Running org.apache.cactus.integration.ant.TestCactifyEarTask >> [surefire] Tests run: 3, Failures: 3, Errors: 0, Time elapsed: 0.031 >> sec <<<<<<<< FAILURE !! >> [surefire] Running org.apache.cactus.integration.ant.TestCactifyWarTask >> [surefire] Tests run: 21, Failures: 21, Errors: 0, Time elapsed: 0.281 >> sec <<<<<<<< FAILURE !! >> [surefire] Running org.apache.cactus.integration.ant.TestCactusTask >> [surefire] Tests run: 7, Failures: 7, Errors: 0, Time elapsed: 0.078 >> sec <<<<<<<< FAILURE !! >> [surefire] Running org.apache.cactus.integration.ant.TestCactusTestTask >> [surefire] Tests run: 7, Failures: 7, Errors: 0, Time elapsed: 0.094 >> sec <<<<<<<< FAILURE !! >> [surefire] Running >> org.apache.cactus.integration.ant.TestRunServerTestsTask >> [surefire] Tests run: 6, Failures: 6, Errors: 0, Time elapsed: 0.078 >> sec <<<<<<<< FAILURE !! >> >> I ran "mvn test", which failed when it could not find the cactus jars. >> It would be better if this worked without needing to do "mvn install" >> first. >> >> I then ran "mvn install" and got the errors shown above. >> >> It looks like these are all caused by >> >> junit.framework.AssertionFailedError: The system property >> 'testinput.dir' must point to an existing directory >> at junit.framework.Assert.fail(Assert.java:47) >> at junit.framework.Assert.assertTrue(Assert.java:20) >> at >> org.apache.cactus.integration.ant.AntTestCase.getBuildFile(AntTestCase.java:370) >> >> This is a bit odd, as the directory appears to be there. >> >> The assert() message ought to quote the directory name it is looking for. >> [I'll update SVN trunk.] >> >> Even odder, the problem does not occur when I reran the test. >> I've tried several times to recreate the error, but it only happened once. >> >> == >> >> There are various jetty files under >> >> samples/jetty/src >> >> which don't have AL headers. Are these Jetty sources? >> If so, then the source archive really needs to include the relevant >> license. >> If the samples were generated under the ASF, then they need the AL >> headers. >> >> There seem to be some oddities in the main pom.xml: >> >> <dependencies> >> <dependency> >> <groupId>aspectj</groupId> >> <artifactId>aspectjrt</artifactId> >> <version>1.5.3</version> >> </dependency> >> >> specifies version 1.5.3, whereas >> >> <dependencyManagement> >> <dependencies> >> ... >> <dependency> >> <groupId>aspectj</groupId> >> <artifactId>aspectjrt</artifactId> >> <version>1.2.1</version> >> </dependency> >> >> specifies version 1.2.1 - I would have expected the two to be the same? >> >> == >> >> There are several maven.xml and project.xml files in the directory >> tree - are these still current? >> >> > > >> > > What is your opinion expressed by any of the three numbers :-). >> > > >> > > >> > > On Mon, Jan 19, 2009 at 10:33 PM, Petar Tahchiev < >> > > paranoiabla.li...@gmail.com> wrote: >> > > >> > > > Hi guys, >> > > > >> > > > here comes the second attempt for >> > > > releasing cactus-1.8.1. >> > > > >> > > > The artifacts, hashes and signatures are here: >> > > >> > > > >> > http://people.apache.org/~ptahchiev/1.8.1-rc2/<http://people.apache.org/%7Eptahchiev/1.8.1-rc2/> >> <http://people.apache.org/%7Eptahchiev/1.8.1-rc2/> >> > > > >> > > > The tagged code-base is here: >> > > > http://svn.apache.org/repos/asf/jakarta/cactus/tags/1.8.1-rc2/ >> > > > >> > > > I think it is OK this time. >> > > > >> > > > Here is my +1 >> > > > >> > > > >> > > > Please vote. >> > > > >> > > > Thanks. >> > > > >> > > > -- >> > > > Regards, Petar! >> > > > Karlovo, Bulgaria. >> > > > >> > > > EOOXML objections >> > > > http://www.grokdoc.net/index.php/EOOXML_objections >> > > > >> > > > Public PGP Key at: >> > > > >> http://keyserver.linux.it/pks/lookup?op=get&search=0x1A15B53B761500F9 >> > > > Key Fingerprint: AA16 8004 AADD 9C76 EF5B 4210 1A15 B53B 7615 >> 00F9 >> > > > >> > > >> > > >> > > >> > > -- >> > > Regards, Petar! >> > > Karlovo, Bulgaria. >> > > >> > > EOOXML objections >> > > http://www.grokdoc.net/index.php/EOOXML_objections >> > > >> > > Public PGP Key at: >> > > >> http://keyserver.linux.it/pks/lookup?op=get&search=0x1A15B53B761500F9 >> > > Key Fingerprint: AA16 8004 AADD 9C76 EF5B 4210 1A15 B53B 7615 00F9 >> > > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org >> For additional commands, e-mail: general-h...@jakarta.apache.org >> >> > > > -- > Regards, Petar! > Karlovo, Bulgaria. > > EOOXML objections > http://www.grokdoc.net/index.php/EOOXML_objections > > Public PGP Key at: > http://keyserver.linux.it/pks/lookup?op=get&search=0x1A15B53B761500F9 > Key Fingerprint: AA16 8004 AADD 9C76 EF5B 4210 1A15 B53B 7615 00F9 > -- Regards, Petar! Karlovo, Bulgaria. EOOXML objections http://www.grokdoc.net/index.php/EOOXML_objections Public PGP Key at: http://keyserver.linux.it/pks/lookup?op=get&search=0x1A15B53B761500F9 Key Fingerprint: AA16 8004 AADD 9C76 EF5B 4210 1A15 B53B 7615 00F9
