2012/1/19 Konstantin Kolinko <knst.koli...@gmail.com>: > 2012/1/19 Bill Barker <billbar...@apache.org>: >> 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 >> > >> [checkstyle] >> /srv/gump/public/workspace/tomcat-trunk/modules/jdbc-pool/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/DefaultTestCase.java:186:19: >> 'static' modifier out of order with the JLS suggestions. > > > False alarm. Note "jdbc-pool/jdbc-pool" in the above path. > > It is stale code that should not be there. > > As I remember several months ago somebody was experimenting with > svn:externals on the modules folder of trunk. That nested jdbc-pool > must be a nested working copy created from such external. > > The svn 1.6 client (used at Gump) leaves stale nested working copy > generated from an external when external is unset. That is why those > files are still there. > > I'll add a command to delete those files to our build.xml, and will > revert the change once Gump is fixed.
The build.xml trick in r1233428 did not fix the issue. Now it is fixed thanks to Stefan Bodewig http://markmail.org/thread/6siq6ydqmexg3zxq Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
