Re: Time for Taglibs to be sent to the archive?
Do we have to do any bureaucratize to register as having passed the TCK? Or is it: * Generate release artifacts. * VOTE on release. * VOTE on Attic. * Publish. * Make project read-only. Hen On Mon, Dec 31, 2012 at 3:11 PM, Henri Yandell flame...@gmail.com wrote: What exactly is left to do the release? Not having a permissively licensed JSTL 1.2 is a shame when the code is there. Even if we put it in the Attic, I'd love to say And here is a 1.2 compliant version, good luck rather than sorry, get it from SVN. I'd be happy to put in the effort to do the votes/website. I'd need to hit the site anyway as a part of sending it to the Attic. Is it 100% good on the TCK, nothing more needed? Hen On Mon, Nov 26, 2012 at 4:44 PM, Jeremy Boynes jboy...@apache.org wrote: +0 It's perhaps not surprising that there is not much activity as there has been no update to the JSR in many years. The JSTL code in trunk does pass the 1.2 TCK and could be released if someone had the energy to fix the website and rustle up votes. On Oct 13, 2012, at 10:58 AM, Henri Yandell wrote: Hard to argue against it. I've no energy for Taglibs coding. I wish we'd got a JSTL 1.2 released, but c'est la vie. All the steps listed sound good except removing the website. Historically on the Attic side we've kept the websites up with a notice that the project is dead, rather than going dark on people. Hen On Mon, Oct 1, 2012 at 12:55 AM, Henri Gomez henri.go...@gmail.com wrote: If there is no activity, it make sense. +0 2012/10/1 Mark Thomas ma...@apache.org: In the two+ years since Taglibs moved to the Tomcat project there have been a few short bursts of activity totalling just over 200 commits but no releases. There has also been no progress towards a migration to svnpubsub for the taglibs part of the web site. Given the lack of progress I would propose that Taglibs is moved to our archive. This would mean: - removing the Taglibs link from tomcat.a.o - removing the Taglibs web pages - moving the tomcat/tagslibs svn tree to tomcat/archive/taglibs - making the Taglibs BZ project read-only - moving the Taglibs committers to emeritus status - removing the Taglibs from Gump There is nothing to remove from dist.a.o since there have been no releases Note: This is intended as a discussion topic - not a formal proposal/vote. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
2012/10/1 Mark Thomas ma...@apache.org: In the two+ years since Taglibs moved to the Tomcat project there have been a few short bursts of activity totalling just over 200 commits but no releases. (...) Note: This is intended as a discussion topic - not a formal proposal/vote. Regarding the two taglibs that are not yet in the attic, I have no interest in RDC taglib, but I am interested in JSTL one. I think once we make the first release, things should go easier after that. A few notes after quick review of the sources: 1. Can we go up from Java 5 and require/use at least Java 6 to build the project? I am even OK to be brave and go up to Java 7. I do not like Java 5, because a) It is outdated. It would be strange for a new project to use that if we are going to support it for long. b) It is not opensource. OpenJDK is since Java 6. The version of Java is important for this class, that implements javax.sql.DataSource: \standard\impl\src\main\java\org\apache\taglibs\standard\tag\common\sql\DataSourceWrapper.java Java 7 will allow us to support a later version of JDBC and will allow this project to build on Gump. 2. Apparently, there are two implementations for JSTL 1.0 tags: jstlel, compat. jstlel provides its own EL engine according to the old specification, compat.uses EL engine from the container. I think having two implementations is too many. Can we drop compat? I have not studied the history yet, but my copy of jakarta-taglibs-standard-1.1.2 does not have those compat tags neither in binary nor in source distributive. 3. The README_*.txt files in the root directory are outdated and need some tweaking. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
On 18/01/2013 08:48, Henri Yandell wrote: Do we have to do any bureaucratize to register as having passed the TCK? Or is it: * Generate release artifacts. * VOTE on release. * VOTE on Attic. * Publish. * Make project read-only. At most, it involves sending a couple of e-mails. I'm happy to handle that part. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54429] Apache is failing to restart
https://issues.apache.org/bugzilla/show_bug.cgi?id=54429 Rainer Jung rainer.j...@kippdata.de changed: What|Removed |Added Component|All |mod_jk Version|2.2.23 |1.2.37 Assignee|b...@httpd.apache.org |dev@tomcat.apache.org Product|Apache httpd-2 |Tomcat Connectors --- Comment #5 from Rainer Jung rainer.j...@kippdata.de --- Or add the flag --enable-api-compatibility to configure when compiling mod_jk. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54429] Apache is failing to restart
https://issues.apache.org/bugzilla/show_bug.cgi?id=54429 --- Comment #6 from Shashi shashi.kumar...@gmail.com --- (In reply to comment #5) Or add the flag --enable-api-compatibility to configure when compiling mod_jk. Thanks Everyone, I have fixed that issue. Issue was with mod_jk connector. Thanks, Shashi. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1435126 - in /tomcat/trunk: res/checkstyle/checkstyle.xml test/org/apache/catalina/core/TestAsyncContextImpl.java test/org/apache/coyote/http11/upgrade/TestUpgrade.java test/org/apache/to
Author: markt Date: Fri Jan 18 13:24:05 2013 New Revision: 1435126 URL: http://svn.apache.org/viewvc?rev=1435126view=rev Log: Make sure JUnit 4 imports are used Modified: tomcat/trunk/res/checkstyle/checkstyle.xml tomcat/trunk/test/org/apache/catalina/core/TestAsyncContextImpl.java tomcat/trunk/test/org/apache/coyote/http11/upgrade/TestUpgrade.java tomcat/trunk/test/org/apache/tomcat/util/http/parser/TestMediaType.java Modified: tomcat/trunk/res/checkstyle/checkstyle.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/res/checkstyle/checkstyle.xml?rev=1435126r1=1435125r2=1435126view=diff == --- tomcat/trunk/res/checkstyle/checkstyle.xml (original) +++ tomcat/trunk/res/checkstyle/checkstyle.xml Fri Jan 18 13:24:05 2013 @@ -57,7 +57,9 @@ value=org.apache.catalina.startup.SimpleHttpClient.CRLF/ property name=excludes value=org.junit.Assert.*/ /module -module name=IllegalImport/ +module name=IllegalImport +property name=illegalPkgs value=sun,junit.framework/ +/module module name=ImportOrder property name=groups value=java,javax,async,jsp2,junit,org.junit,org,util/ property name=ordered value=true/ Modified: tomcat/trunk/test/org/apache/catalina/core/TestAsyncContextImpl.java URL: http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/core/TestAsyncContextImpl.java?rev=1435126r1=1435125r2=1435126view=diff == --- tomcat/trunk/test/org/apache/catalina/core/TestAsyncContextImpl.java (original) +++ tomcat/trunk/test/org/apache/catalina/core/TestAsyncContextImpl.java Fri Jan 18 13:24:05 2013 @@ -39,13 +39,12 @@ import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; -import junit.framework.Assert; - import static org.junit.Assert.assertEquals; import static org.junit.Assert.assertNotNull; import static org.junit.Assert.assertTrue; import static org.junit.Assert.fail; +import org.junit.Assert; import org.junit.Test; import org.apache.catalina.Context; Modified: tomcat/trunk/test/org/apache/coyote/http11/upgrade/TestUpgrade.java URL: http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/coyote/http11/upgrade/TestUpgrade.java?rev=1435126r1=1435125r2=1435126view=diff == --- tomcat/trunk/test/org/apache/coyote/http11/upgrade/TestUpgrade.java (original) +++ tomcat/trunk/test/org/apache/coyote/http11/upgrade/TestUpgrade.java Fri Jan 18 13:24:05 2013 @@ -38,8 +38,7 @@ import javax.servlet.http.HttpServletRes import javax.servlet.http.ProtocolHandler; import javax.servlet.http.WebConnection; -import junit.framework.Assert; - +import org.junit.Assert; import org.junit.Test; import static org.apache.catalina.startup.SimpleHttpClient.CRLF; Modified: tomcat/trunk/test/org/apache/tomcat/util/http/parser/TestMediaType.java URL: http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/util/http/parser/TestMediaType.java?rev=1435126r1=1435125r2=1435126view=diff == --- tomcat/trunk/test/org/apache/tomcat/util/http/parser/TestMediaType.java (original) +++ tomcat/trunk/test/org/apache/tomcat/util/http/parser/TestMediaType.java Fri Jan 18 13:24:05 2013 @@ -19,12 +19,11 @@ package org.apache.tomcat.util.http.pars import java.io.IOException; import java.io.StringReader; -import junit.framework.Assert; - import static org.junit.Assert.assertEquals; import static org.junit.Assert.assertNull; import static org.junit.Assert.assertTrue; +import org.junit.Assert; import org.junit.Test; /** - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
On Jan 18, 2013, at 1:34 AM, Konstantin Kolinko wrote: Regarding the two taglibs that are not yet in the attic, I have no interest in RDC taglib, but I am interested in JSTL one. +1 I think once we make the first release, things should go easier after that. A few notes after quick review of the sources: 1. Can we go up from Java 5 and require/use at least Java 6 to build the project? I am even OK to be brave and go up to Java 7. I do not like Java 5, because a) It is outdated. It would be strange for a new project to use that if we are going to support it for long. b) It is not opensource. OpenJDK is since Java 6. The version of Java is important for this class, that implements javax.sql.DataSource: \standard\impl\src\main\java\org\apache\taglibs\standard\tag\common\sql\DataSourceWrapper.java Java 7 will allow us to support a later version of JDBC and will allow this project to build on Gump. There is also an issue with the I18N tags taking a long time to start on a Java6 platform due to changes in the way Locales are located by the JRE. I remember some discussion on fixing this but a requirement to stay on Java 5 meant having to build two implementations and switch between them which I'd planned to do once a release was out. If we pre-req 6 or 7 then the implementation can just be updated and this issue closed easier. 2. Apparently, there are two implementations for JSTL 1.0 tags: jstlel, compat. jstlel provides its own EL engine according to the old specification, compat.uses EL engine from the container. I think having two implementations is too many. Can we drop compat? I did this to ensure that applications using 1.0 would not be impacted by any new features added to later versions of EL (for example stricter rules on names), but also to allow users to switch to the container's if they did not want to ship/rely on the older implementation. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54450] New: Injection fails when part of the servlet properties uses @Resource and the other uses 'injection-target'
https://issues.apache.org/bugzilla/show_bug.cgi?id=54450 Bug ID: 54450 Summary: Injection fails when part of the servlet properties uses @Resource and the other uses 'injection-target' Product: Tomcat 7 Version: 7.0.35 Hardware: PC Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: violet...@apache.org Classification: Unclassified Hi, I have a servlet with: - annotated properties - and injection-target declarations in web.xml When I try to request this servlet I receive: javax.naming.NameNotFoundException: Name [envEntry1] is not bound in this Context. Unable to find [envEntry1]. at org.apache.naming.NamingContext.lookup(NamingContext.java:820) at org.apache.naming.NamingContext.lookup(NamingContext.java:154) at org.apache.naming.NamingContext.lookup(NamingContext.java:831) at org.apache.naming.NamingContext.lookup(NamingContext.java:168) at org.apache.catalina.core.DefaultInstanceManager.lookupMethodResource(DefaultInstanceManager.java:622) at org.apache.catalina.core.DefaultInstanceManager.processAnnotations(DefaultInstanceManager.java:466) at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:157) at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:138) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1137) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:858) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:136) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680) The problem is that when the application uses 'injection-target' declarations in org.apache.catalina.core.DefaultInstanceManager.populateAnnotationsCache(Class?, MapString, String) only the first setter method is evaluated and the rest are skipped. I would like to propose a patch and test case. I'm looking forward to your comments. Regards Violeta -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54450] Injection fails when part of the servlet properties uses @Resource and the other uses 'injection-target'
https://issues.apache.org/bugzilla/show_bug.cgi?id=54450 --- Comment #1 from Violeta Georgieva violet...@apache.org --- Created attachment 29867 -- https://issues.apache.org/bugzilla/attachment.cgi?id=29867action=edit patch proposal + test The test case extends the test case from https://issues.apache.org/bugzilla/show_bug.cgi?id=54448 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53871] java.lang.StackOverflowError on deploying a web application
https://issues.apache.org/bugzilla/show_bug.cgi?id=53871 --- Comment #8 from Fernando Kasten Peinado kas...@touchtec.com.br --- I'm having the same problem, but it is not constant, some times it happens, some time dont. But something that I observed was that it happens more frequently when I'm using x86_64 oracle jvm. java version 1.6.0_38 Java(TM) SE Runtime Environment (build 1.6.0_38-b05) Java HotSpot(TM) 64-Bit Server VM (build 20.13-b02, mixed mode) CATALINA_OPTS=-XX:MaxPermSize=256m -Xmx1g -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [RESULT] [VOTE] Release Apache Tomcat 7.0.35
On Wed, Jan 16, 2013 at 1:41 AM, Mark Thomas ma...@apache.org wrote: Votes were as follows: +1 (binding): kkolinko, rjung, yoavs, olamy, markt No other votes were cast. The vote therefore passes. I'll publish the binaries and announce later today once the mirrors have caught up. Given the regression with issue 54440, should this be withdrawn and a quick release of '36 be done? https://issues.apache.org/bugzilla/show_bug.cgi?id=54440 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [RESULT] [VOTE] Release Apache Tomcat 7.0.35
On 18/01/2013 19:32, Jeremy Boynes wrote: On Wed, Jan 16, 2013 at 1:41 AM, Mark Thomas ma...@apache.org wrote: Votes were as follows: +1 (binding): kkolinko, rjung, yoavs, olamy, markt No other votes were cast. The vote therefore passes. I'll publish the binaries and announce later today once the mirrors have caught up. Given the regression with issue 54440, should this be withdrawn and a quick release of '36 be done? https://issues.apache.org/bugzilla/show_bug.cgi?id=54440 I'm wasn't planning on it. If that bug is a showstopper then folks can stick on 7.0.34 for a few more weeks. It is less than 10 working days before I'd normally start the 7.0.36 release anyway and this month I am trying to keep more on top of the bugs so the release is closer to the start of Feb than the middle of Feb. A release isn't really that much work but I'd rather spend my time on the WebSocket implementation. If there is a real need for 7.0.36 we could pull it forward but I'm not seeing that right now. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [RESULT] [VOTE] Release Apache Tomcat 7.0.35
On 1/18/2013 3:13 PM, Mark Thomas wrote: On 18/01/2013 19:32, Jeremy Boynes wrote: On Wed, Jan 16, 2013 at 1:41 AM, Mark Thomas ma...@apache.org wrote: Votes were as follows: +1 (binding): kkolinko, rjung, yoavs, olamy, markt No other votes were cast. The vote therefore passes. I'll publish the binaries and announce later today once the mirrors have caught up. Given the regression with issue 54440, should this be withdrawn and a quick release of '36 be done? https://issues.apache.org/bugzilla/show_bug.cgi?id=54440 I'm wasn't planning on it. If that bug is a showstopper then folks can stick on 7.0.34 for a few more weeks. Nothing in 7.0.35 is really that critical. For myself I went to 7.0.35, swore furiously about the bug -- almost just dropped back to 7.0.34 but then applied the patch and moved on. I guess the real question is how many new to Tomcat folk are realistically going to pick up 7.0.35 *and* jump to doing JSP precompilation *and* do so before 7.0.36 is out. If they're /not /new to Tomcat, then they know it *did* work and will start looking for where it stopped, check the mailing lists, etc. If not and they hit this issue before 7.0.36 is announced, then they'll just assume Tomcat is no good -- but how many folk will really fall into that category? -- Jess Holle
[Bug 49686] Using an instance lock to protect static shared data in class SocketConnector
https://issues.apache.org/bugzilla/show_bug.cgi?id=49686 --- Comment #1 from Mohsen Vakilian reprogram...@gmail.com --- This issue is an instance of https://www.securecoding.cert.org/confluence/x/j4CBAg and is still not fixed http://svn.apache.org/repos/asf/!svn/bc/1435416/tomcat/trunk/modules/tomcat-lite/java/org/apache/tomcat/lite/io/SocketConnector.java. Has anyone reviewed this issue? Is there any reason for not fixing it? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 49686] Using an instance lock to protect static shared data in class SocketConnector
https://issues.apache.org/bugzilla/show_bug.cgi?id=49686 Mohsen Vakilian reprogram...@gmail.com changed: What|Removed |Added CC||reprogram...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Trivial Update of PoweredBy by Krzysztof Gil
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Tomcat Wiki for change
notification.
The PoweredBy page has been changed by Krzysztof Gil:
http://wiki.apache.org/tomcat/PoweredBy?action=diffrev1=452rev2=453
Comment:
added HostingInCanada
=== Hosting Habitat ===
{{http://statictwo.hostinghabitat.net/images/logo.png}}
[[http://hostinghabitat.com/vps-hosting.html|Hosting Habitat - VPS Hosting]]
Hosting Habitat is a company based in South Africa offering support for Apache
Tomcat on all VPS hosting plans.
+
+ === HostingInCanada - Java Hosting ===
+ [[http://hostingincanada.com|HostingInCanada.com]] has been providing Java
Hosting services based on Apache Tomcat since 1999. At that time only a few
companies offered JSP and Java Hosting services. HiC offer: Shared Java Hosting
(based on Apache Tomcat), Private Tomcat Hosting (dedicated Tomcat instance)
and JBoss. 14 days trial available (only for Shared and Private Tomcat
packages).
=== Hosting Planet Limited ===
{{http://www.planet-hosting.net/design/site/jhosting/image/logo.gif}}
http://www.planet-hosting.net Hosting Planet Limited is hosting company
offering Java hosting using private JVM. All hosting plans including Tomcat as
JSP/Servlet container.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump]: Project tomcat-trunk-validate (in module tomcat-trunk) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-trunk-validate has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-trunk-validate : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on checkstyle exists, no need to add for property checkstyle.jar. -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/gump_work/build_tomcat-trunk_tomcat-trunk-validate.html Work Name: build_tomcat-trunk_tomcat-trunk-validate (Type: Build) Work ended in a state of : Failed Elapsed: 42 secs Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dcheckstyle.jar=/srv/gump/public/workspace/checkstyle/target/checkstyle-5.7-SNAPSHOT.jar -Dexecute.validate=true validate [Working Directory: /srv/gump/public/workspace/tomcat-trunk] CLASSPATH: /usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-5.7-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-19012013.jar:/srv/gump/public/workspace/apache-commons/cli/target/commons-cli-1.3-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/exec/target/commons-exec-1.1.1-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/validator/dist/commons-validator-19012013.jar:/srv/gump/public/workspace/junit/dist/junit-19012013.jar:/srv/gump/ public/workspace/junit/dist/junit-dep-19012013.jar:/srv/gump/public/workspace/google-guava/guava/target/guava-14.0-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-19012013.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-19012013.jar:/srv/gump/public/workspace/commons-collections-3.x/target/commons-collections-3.3-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/jdom/build/jdom.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-19012013.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-19012013-dep.jar:/srv/gump/packages/javamail-1.4/mail.jar:/srv/gump/packages/javamail-1.4/lib/mailapi.jar:/srv/gump/packages/jaf-1.1ea/activation.jar - Buildfile: /srv/gump/public/workspace/tomcat-trunk/build.xml build-prepare: [delete] Deleting directory /srv/gump/public/workspace/tomcat-trunk/output/build/temp [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/temp compile-prepare: download-validate: proxyflags: setproxy: testexist: [echo] Testing for /srv/gump/public/workspace/checkstyle/target/checkstyle-5.7-SNAPSHOT.jar downloadzip: validate: [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/res/checkstyle [checkstyle] Running Checkstyle 5.7-SNAPSHOT on 2427 files [checkstyle] /srv/gump/public/workspace/tomcat-trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/DefaultTestCase.java:22:1: Import from illegal package - junit.framework.TestCase. [checkstyle] /srv/gump/public/workspace/tomcat-trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/TestAsyncQueue.java:24:1: Import from illegal package - junit.framework.TestCase. [checkstyle] /srv/gump/public/workspace/tomcat-trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/TestSizePreservation.java:22:1: Import from illegal package - junit.framework.TestCase. BUILD FAILED /srv/gump/public/workspace/tomcat-trunk/build.xml:478: Got 3 errors and 0 warnings. Total time: 42 seconds - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/rss.xml - Atom:
