Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 300970

Summary: dev-java/ant sets wrong ANT_HOME
Product: Gentoo Linux Reporter: Janos Pasztor <pasztor.janos>
Component: Current packagesAssignee: Java team <java>
Status: CONFIRMED ---    
Severity: major CC: jstein, rini17, yvan.royon
Priority: High    
Version: unspecified   
Hardware: All   
OS: All   
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
/usr/bin/ant sets ANT_HOME to /usr/share/ant-core in dev-java/ant whereas it should not override the variable in the environment. The system wide ANT_HOME variable should be set to /usr/share/ant in the profile to enable proper use of the ${ant.home} variable in build.xml files.

Reproducible: Always

Steps to Reproduce:
1. Use ${ant.home}/lib as a fileset reference
2. See, that only the core .jar files are used

Actual Results:  
build.xml fails to load non-core modules.

Expected Results:  
The build.xml should be able to use all installed ant modules.
Comment 1 Petteri Räty (RETIRED) gentoo-dev 2010-01-16 09:40:23 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.
Comment 2 Petteri Räty (RETIRED) gentoo-dev 2010-01-16 09:41:38 UTC
To see how ant works on Gentoo see:
Comment 3 Tuomo Pieniluoma 2011-12-20 23:01:21 UTC
Created attachment 296495 [details, diff]
Forces ant wrapper to honour the ANT_HOME environment variable.
Comment 4 Tuomo Pieniluoma 2011-12-20 23:03:03 UTC
Created attachment 296497 [details, diff]
Changes needed for the current ant-core ebuild to enable that other patch with almost the same name.
Comment 5 Tuomo Pieniluoma 2011-12-20 23:16:55 UTC
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.
Comment 6 Vlastimil Babka (Caster) (RETIRED) gentoo-dev 2012-07-11 23:02:50 UTC
*** Bug 342925 has been marked as a duplicate of this bug. ***
Comment 7 Ralph Sennhauser (RETIRED) gentoo-dev 2012-07-12 11:07:17 UTC
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.
Comment 8 Juraj Variny 2015-02-24 00:11:39 UTC
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.xml:117: Problem: failed to create task or type junit
Cause: the class was not found.
        This looks like one of Ant's optional components.
Action: Check that the appropriate optional JAR exists in
        -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
Comment 9 Jeremi Piotrowski 2015-03-06 23:49:32 UTC
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?