|Summary:||dev-util/checkstyle should install an ant task|
|Product:||Gentoo Linux||Reporter:||Sven <sven.koehler>|
|Component:||[OLD] Java||Assignee:||Java team <java>|
|Package list:||Runtime testing required:||---|
Description Sven 2012-09-25 16:06:51 UTC
The checkstyle package includes an ant task. Shouldn't the package install a file /usr/share/ant/tasks/checkstyle? I'm currently using checkstyle 5.5. Reproducible: Always Steps to Reproduce: 1. emerge checksytle ant-core Actual Results: Observe that <taskdef resource="checkstyletask.properties"> doesn't work. Also checkstyle is not part of the "java.class.path" variable printed by <echoproperties/> Expected Results: checkstyle ant tasks is available.
Comment 1 Ralph Sennhauser (RETIRED) 2012-09-26 08:35:33 UTC
'ANT_TASKS="checkstyle" ant -f build.xml' will work, the issue with registering ant tasks which aren't part of ant itself, ie. ant-* ant tasks is they will be available by default (if unset ANT_TASKS is populated with all of them) if you develop your own project and so your build.xml might not work on others machines due to missing tasks or maybe more importantly, if there are multiply slots installed, it's not clear which will be used. I talked about this with ali_bush maybe a year ago and he was clearly of the opinion to only register ant-* ant tasks and I agree by now. The only issue with this is that setting ANT_TASKS removes the ant-* ant tasks from the list of available tasks so they need to be listed again. As the build.xml should take care of extra ant tasks this is mostly a non issue though. <taskdef/> should work, either use 'ant -lib checkstyle.jar' or make sure the taskdef sets an appropriate classpath itself. The latter is preferable actually.
Comment 2 Sven 2012-09-26 10:14:51 UTC
(In reply to comment #1) > 'ANT_TASKS="checkstyle" ant -f build.xml' will work, the issue with > registering ant tasks which aren't part of ant itself, ie. ant-* ant tasks > is they will be available by default (if unset ANT_TASKS is populated with > all of them) if you develop your own project and so your build.xml might not > work on others machines due to missing tasks or maybe more importantly, if > there are multiply slots installed, it's not clear which will be used. I am aware of that. Now consider this: my current ant build files (which apparently run fine on other machines) don't run on my gentoo machine, because checkstyle (the binary build available from the checkstyle homepage) seems to conflict with the is already in the classpath of ant. Anyhow, I get a ClassCastException somewhere and basically checkstype doesn't run. Now with ANT_TASKS=checkstyle, it does run. Also, if your statement is true, why do so many packages (like cpptasks) make their ant tasks available by default? Ant files using cpptasks also won't run on other machines, unless I write them carefully. For that argument it doesn't matter, whether checkstyle is a standalone program or not. Either no ant task is available by default, or everyone is. Having some available by default and others not is a strange thing. Now there are several issues with making ant tasks available by default. One is about versions. Even if I tell ant where to find checkstyle 5.6, it will still use checkstyle 5.5 if that is emerged. But again, the same issue exists with cpptasks. So beside the general discussion, the bottom line for me is: checkstyle doesn't work, unless I emerge it. The usual way (<taskdef> with classpath to checkstyle-5.6-all.jar or even the inidivual JARS, excluding the antlr.jar that comes with checkstyle) result in weired ClassCastExceptions.