we have a change in already to have our custom task check the version of Ant. It'll be in the next release.
The issue with this particular change is that we rely on a change in behavior from 1.7 to 1.8, not on a new task or attribute that would fail on 1.7 :( On Fri, Dec 10, 2010 at 2:25 PM, Andreas <[email protected]> wrote: > Ok, I can confirm the bug is not happening with the latest ant > version. My bad. > However if using the wrong ant version is creating such strange > mistakes you might > consider making it mandatory or at least print a big fat warning. > -- > Andreas > > On Dec 10, 12:01 pm, Xavier Ducrohet <[email protected]> wrote: >> hmm if you use the proper version of Ant this should not be required. >> I double checked it a few days ago. >> you do need Ant 1.8 >> >> On Fri, Dec 10, 2010 at 11:52 AM, Matt Quigley >> >> >> >> <[email protected]> wrote: >> >> Andreas, >> >> I'm not sure where you added that line <path refid="jar.libs.ref" />. >> >> I need to make this fix in the build.xml file, not in the Android SDK >> >> Tools directory, because this change needs to work on all of my team's >> >> machines and the build machine. I'll try to find a solution and post >> >> it here. >> >> > I've found the problem. In the latest version of the Android SDK >> > Tools (v8), the ${sdk}/tools/ant/main_rules.xml contains the build >> > targets for regular Android projects built with Ant. In this file, >> > inside the <macrodef name="dex-helper"> element, there is a command >> > which calls the application dx which creates the classes.dex file for >> > you. It is missing the external libs when called from the -dex >> > target. Right now, the ERRONEOUS program is run like: >> >> > java -Xmx1024M -Djava.ext.dirs=lib\ -jar lib\dx.jar --dex --output=C: >> > \xxx\bin\classes.dex C:\xxx\bin\classes >> >> > However, it SHOULD be run including the external jar libraries as the >> > source, along with the java class files: >> >> > java -Xmx1024M -Djava.ext.dirs=lib\ -jar lib\dx.jar --dex --output=C: >> > \xxx\bin\classes.dex C:\xxx\bin\classes c:\xxx\lib\external_lib.jar >> >> > In order to fix this, you can do two things. One, is to change the $ >> > {sdk}/tools/ant/main_rules.xml file yourself by changing the -dex >> > target from: >> >> > <if condition="${manifest.hasCode}"> >> > <then> >> > <dex-helper /> >> > </then> >> > <else> >> > <echo>hasCode = false. Skipping...</echo> >> > </else> >> > </if> >> >> > to: >> >> > <if condition="${manifest.hasCode}"> >> > <then> >> > <dex-helper> >> > <external-libs> >> > <path refid="jar.libs.ref" /> >> > </external-libs> >> > </dex-helper> >> > </then> >> > <else> >> > <echo>hasCode = false. Skipping...</echo> >> > </else> >> > </if> >> >> > Although that solution will work for most developers, it will not work >> > if you need to propagate this fix across all team members working on >> > the project. As an alternative, you can fix it in your own project's >> > build file (build.xml) by ensuring that the external .jar files are >> > included in the input directory. You can do this by copying the .jar >> > files to the dex input directory before the dex target is called: >> >> > <target name="-pre-compile"> >> >> > <!-- To fix a bug in Android SDK Tools v8, we need to copy the >> > external >> > libraries to the binary output directory, so that the .jar >> > is >> > included by the DX compiler. This will be unnecessary in the >> > future >> > when the bug is fixed; see >> > http://code.google.com/p/android/issues/detail?id=13091. --> >> > <copy todir="${out.classes.absolute.dir}"> >> > <fileset dir="${jar.libs.absolute.dir}"/> >> > </copy> >> > </target> >> >> > If you fix it in your own build.xml file, then everyone who checks out >> > the project will be able to build the project correctly, without >> > having to change the SDK Tools local to their machine. >> >> > This is documented in the bug here: >> >http://code.google.com/p/android/issues/detail?id=13091 >> >> > -- >> > Matt Quigley >> >www.androidengineer.com >> >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Android Developers" group. >> > To post to this group, send email to [email protected] >> > To unsubscribe from this group, send email to >> > [email protected] >> > For more options, visit this group at >> >http://groups.google.com/group/android-developers?hl=en >> >> -- >> Xavier Ducrohet >> Android SDK Tech Lead >> Google Inc. >> >> Please do not send me questions directly. Thanks! > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Xavier Ducrohet Android SDK Tech Lead Google Inc. Please do not send me questions directly. Thanks! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
