Martin,

I think there is a misunderstanding here. ART as well as Dalvik both are 
runtimes on the devices. You error message comes from the build when dex is 
processing the Java jar files with Java bytecode to produce Android bytecode 
with dex. The issue is probably some specific old jar that uses pre Java 5 .... 
if you find the specific dependency you will be able to check it out in more 
details. Maybe try by managing the asm dependency to a newer version than what 
is your resolved dependency or at least check out what that version is .. 

manfred 



Martin Gainty wrote on 24.12.2014 05:13:

> the line from Sound of Music that seems applicable for this situtation
> 
> when I run the dx Utility from maven-android-plugin as:
> java -Xmx5120M -jar $ANDROID_HOME/lib/dx.jar --dex
> --output=$ANDROID_HOME/target/classes.dex 
> ${user.home}/.m2/repository/org/apache/maven/maven-plugin-descriptor/2.0.5/maven-plugin-descriptor-2.0.5.jar
>  
> ${user.home}/.m2/repository/com/android/tools/lint/lint-api/22.4.2/lint-api-22.4.2.jar
> ...space delimited list of 1000 assorted jars to be converted to DEX
> fubars with the following friendly message:
> UNEXPECTED TOP-LEVEL EXCEPTION:
> java.lang.IllegalArgumentException: already added:
> Lorg/objectweb/asm/tree/AbstractInsnNode;
>    at com.android.dx.dex.file.ClassDefsSection.add(ClassDefsSection.java:122)
>    at com.android.dx.dex.file.DexFile.add(DexFile.java:161)
>    at com.android.dx.command.dexer.Main.processClass(Main.java:685)
>    at com.android.dx.command.dexer.Main.processFileBytes(Main.java:634)
>    at com.android.dx.command.dexer.Main.access$600(Main.java:78)
>    at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:572)
>    at
>    
> com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284)
>    at
>    
> com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166)
>    at
>    com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:144)
>    at com.android.dx.command.dexer.Main.processOne(Main.java:596)
>    at com.android.dx.command.dexer.Main.processAllFiles(Main.java:498)
>    at com.android.dx.command.dexer.Main.runMonoDex(Main.java:264)
>    at com.android.dx.command.dexer.Main.run(Main.java:230)
>    at com.android.dx.command.dexer.Main.main(Main.java:199)
>    at com.android.dx.command.Main.main(Main.java:103)
> 1149 errors; aborting
> warning: Ignoring InnerClasses attribute for an anonymous inner class
> (org.apache.commons.jxpath.JXPathBasicBeanInfo$1) that doesn't come with an
> associated EnclosingMethod attribute. This class was probably produced by a
> compiler that did not target the modern .class file format. The recommended
> solution is to recompile the class from source, using an up-to-date compiler
> and without specifying any "-target" type options. The consequence of ignoring
> this warning is that reflective operations on this class will incorrectly
> indicate that it is *not* an inner class.
> 
> Apparently Androids com.android.dx.cf.direct.ClassPathOpener is expecting a
> specific format of Class  for reflection magic so apparently I would need to
> recompile ALL of  the maven jars in my local repo to at least 1.7.0_45 before
> attempting ..i have 1000 at last count and this effort would be too time
> consuming so I am seeking advice on how to mitigate
> 
> Google has decided to shy away from Androids Dalvik VM to create Googles own 
> VM
> for Android Lollipop called ART here are some conversion pointers..The long
> winded explanation for this paradigm shift involves lawsuits in US Courts
> 
> Moving from DALVIK to ART
> 
> Enabling ART in Android Build
> 
> Device Runtime(s)
> Two runtimes are now available, the existing Dalvik runtime (libdvm.so) and 
> the
> ART runtime (libart.so).
> A device can be built using either or both runtimes. (You can dual boot from
> Developer options if both runtimes are installed.) 
> See runtime_common.mk. That is included from
> build/target/product/runtime_libdvm.mk or
> build/target/product/runtime_libdvm.mk or both.
> 
> To maintain backward compatibility, ART uses the same input bytecode as 
> Dalvik,
> supplied through standard .dex files as part of APK files,
> 
> DEX to ART ELF Conversion:
> Once an application is compiled by using ART's on-device dex2oat utility, it 
> is
> run solely from the compiled ELF executable
> the Dalvik .odex files are replaced with Executable and Linkable Format (ELF)
> executables output from dex2oat
> 
> These helpful hints should be sanitised and posted somewhere but I dont know
> where this should go?
> 
> Looks like we have some interesting work to look forward to 2015
> 
> Happy Channukah/Merry Christmas
> Martin 
> ______________________________________________ 
>                                                                               
>                      
>                                         


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to