|Summary:||dev-java/javatoolkit and/or java-ant-2.eclass xml rewriter inconsistencies|
|Product:||Gentoo Linux||Reporter:||Vlastimil Babka (Caster) (RETIRED) <caster>|
|Component:||[OLD] Java||Assignee:||Java team <java>|
|Package list:||Runtime testing required:||---|
Description Vlastimil Babka (Caster) (RETIRED) 2009-05-02 16:30:18 UTC
I tried solving bug 268252 by using JAVA_ANT_ENCODING="UTF-8" variable. This causes the cElementTree rewriter to be used instead of 3rd generation rewriter. The problem is it does not append gentoo.classpath to <java> calls, so the build fails. I tried setting JAVA_ANT_CLASSPATH_TAGS="javac java" but it did not help, the cElementTree rewriter ignores that. Moreover, since default JAVA_ANT_CLASSPATH_TAGS is "javac xjavac" I start to wonder why 3rd-gen rewriter changes <java> calls as well? Couldn't find the reason.
Comment 1 Vlastimil Babka (Caster) (RETIRED) 2009-05-02 16:33:36 UTC
The state of rewriters is quite messy IMHO, there are too many of them and it makes the eclass complex. Maybe we could get rid of all pre-gen3 since the version of javatoolkit that's pulled guarantees gen3? And then define and document properly all supported JAVA_ANT_ parameters and make sure they work in the remaining rewriters...
Comment 2 Petteri Räty (RETIRED) 2009-05-02 16:35:36 UTC
Well I was thinking that instead of messing with the current bloated eclasses any further I should just write them better from scratch.