Summary: | dev-java/ant sets wrong ANT_HOME | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Janos Pasztor <pasztor.janos> |
Component: | Current packages | Assignee: | Java team <java> |
Status: | RESOLVED OBSOLETE | ||
Severity: | major | CC: | jstein, rini17, yvan.royon |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Forces ant wrapper to honour the ANT_HOME environment variable.
Changes needed for the current ant-core ebuild to enable that other patch with almost the same name. |
Description
Janos Pasztor
2010-01-14 12:12:02 UTC
Take a look at: ant --execdebug You will see that we add all the installed tasks to classpath by default. I can't figure out why you would need to know the location of the jars in build.xml. To see how ant works on Gentoo see: http://www.gentoo.org/proj/en/java/ant-guide.xml Created attachment 296495 [details, diff]
Forces ant wrapper to honour the ANT_HOME environment variable.
Created attachment 296497 [details, diff]
Changes needed for the current ant-core ebuild to enable that other patch with almost the same name.
Apparently the file names do not stick when posting patches here. :D Anyway, those two patches should go hand-in-hand. The first, i.e. "attachment 296495 [details, diff]" should go into the ebuild's ${FILESDIR} as "honour_env_ant_home.patch" for the second, i.e. "attachment 296497 [details, diff]" to work. Using those two, you should be able to stitch a working ebuild that produces a copy of ant-core that actually honours the ANT_HOME environment variable... or alternatively you can of course just use the first patch to knife the ant wrapper directly in /usr/bin. And I think bug #342925 is a duplicate of this one. *** Bug 342925 has been marked as a duplicate of this bug. *** The launcher sets also ${ant.library.dir} which would by all means be the better property to reference ${ant.home}/lib. But even then it's unreliable. Think about IDEs or applications built upon ant which won't use the launcher script at all. So if portability is desired stay away from both ${ant.library.dir} and ${ant.home}. Like there is ANT_RESPECT_JAVA_HOME there could be ANT_RESPECT_ANT_HOME or we just set ${ant.library.dir} properly if not invoked through portage, however, unlike for the former we still lack a single example where this is desired or in other words an example where the same can't be achieved in a more sane way. Sorry for bumping, but why this still isn't fixed? It prevents user from build anything which uses extensions like junit. The error is (just to add keywords for future victims to search by): BUILD FAILED build.xml:117: Problem: failed to create task or type junit Cause: the class org.apache.tools.ant.taskdefs.optional.junit.JUnitTask was not found. This looks like one of Ant's optional components. Action: Check that the appropriate optional JAR exists in -/usr/share/ant-core/lib -/home/user/.ant/lib -a directory added on the command line with the -lib argument Do not panic, this is a common problem. The commonest cause is a missing JAR. This is not a bug; it is a configuration problem I have found this same problem/bug, but in my case I have also identified a cause: I have dev-java/ant-core-1.9.2 installed, but in the launcher script `/usr/bin/ant` only the folders `/usr/share/ant/tasks` and `/usr/share/ant/tasks-1.8.2` are checked for tasks when `ANT_TASKS` is set to "all". The second folder (`tasks-1.8.2`) doesn't even exist. After creating a symlink from `tasks-1.8.2` to `tasks-1.9.2` everything works. Could it be that `ant-core` is updated the launcher script doesn't modified to reflect the new version? Affected versions (1.9.2) are gone. Closing. |