dex fails because a BuildConfig class from an aar lib is there twice #326
Comments
|
I see 2 ways to fix the problem. A. Removing the following code in generateBuildConfig method. (Non backwards compatible) // Generate the BuildConfig for any APKLIB and AAR dependencies.
// Need to generate for AAR, because some old AARs like ActionBarSherlock do not have BuildConfig (or R)
for ( Artifact artifact : getTransitiveDependencyArtifacts( APKLIB, AAR ) )
{
final File manifest = new File( getUnpackedLibFolder( artifact ), "AndroidManifest.xml" );
final String depPackageName = extractPackageNameFromAndroidManifest( manifest );
generateBuildConfigForPackage( depPackageName );
}And also include the BuildConfig.class in the aar B. Making the code in generateBuildConfig to generate BuildConfig only if it's not present in the classes.jar (backwards compatible) So the first way isn't backwards compatible but is the proper way to do it. |
Do not generate BuildConfig for aar libs See simpligility#326 Solution 1
|
#328 implement solution 1. I will look into solution 2 to ensure backwards compatibility |
|
Merged -> closing |
Do not generate BuildConfig for aar libs See simpligility#326 Solution 1
|
Hey, when I compile with version 3.8.2 I get the reported error: [INFO] UNEXPECTED TOP-LEVEL EXCEPTION: But when using 3.9.0-rc.2 I'll get the following error in my library project: With 3.8.2 all my library projects build successful. Is this a new bug or a misconfiguration on my site? |
|
It's another problem: |
|
The manifest entry is set. The app project and all libraries build successfully in Eclipse. The library projects also build successfully with Maven 3.8.2. But the app project fails with 3.8.2. |
|
Post a link to a cut down project that fails. On Thu, Jun 12, 2014 at 3:49 AM, gabriel01 notifications@github.com wrote:
|
|
I've spent a couple of hours on his now as well. Plugin def: The error: Good instructions regarding how to use the plugin OR how to craft the right dependency type (.aar, .apklib) and wire it all up are hard to come by. |
|
Why are you providing a dependency on the apklib AND the jar? A dep on the apklib should be sufficient. And again, without a link to a project that is failing it becomes just guesswork for us to try and diagnose. |
|
I've cobbled together this much from the web. Like I said the docs are not clear. If I take out the library then I get all kinds of errors it can't find anything. BUT, your question makes me think the apklib is bundled improperly. There were 2 sets of instructions: deploy the .aar file, google provides in the extras, as is, declaring it an apklib; and the "zip the project" version. I need to go back and verify this. (but I must sleep first.) The project is not in github yet. |
|
Try aar instead of apklib. it's better anyway. |
|
Using just the .aar: |
|
Updated android build tools to 19.1.0 and got the same error. |
|
OK, my bad: It suddenly started working. Turns out that it was a transient memory resource problem. On another invocation I went to run maven and got: |
|
I meant to say, it started working with just the .aar dependency. So, now all I'm using is: without the "support-v4" dependency or the "appcompat-v7" .jar dependency. |
|
Apparently. Though it did take a while to sort out the details that the new plugin required a maven update, and the docs are not clear on exactly how to setup the dependencies. You've still got that apklib page off your site https://code.google.com/p/maven-android-plugin/wiki/ApkLib. |
|
What Maven update? It will run fine with any version of Maven 3.0+, which is the same as 3.8.2. I have updated the ApkLib page with a deprecation warning in favour of AAR. It would be good to create a page explaining AR creation/consumption. It's pretty trivial as it's just like any other maven artifact type. Any takers? What about you @sensorcast ? |
|
I was running with Maven 3.0.3 and the plugin spit something out that it was unhappy and needed 3.1 (I think it was 3.1; message is lost at this point). So I installed 3.2.1. (I don't know where you are getting your Maven binaries from but 3.2.1 is listed as the latest: http://maven.apache.org/download.cgi). As for .aar: I'm not sure I fully understand it myself except to say that I now have a working version/config using Maven 3.2.1, android-maven-plugin 2.9.0-rc-2, Android 19.1.0 build tools, and appcompat-v7 19.1.0 where this was simply rsync'd to our server from the /extras/android/m2repository -- i.e., "sync -av com maven@sensorcast.org:/home/maven/repos/external-free" |
|
Hmm, I replaced the jar/apklib dependency by com.android.support appcompat-v7 19.1.0 aar Now I get "cannot find symbol : class ActionBarActivity" and "package android.support.v7.app does not exist". But the dependency is definitely. Please find below the pom. Any advice is very appreciated. |
|
I am posting here a duplicate comment to stress the issue I am seeing with latest available 3.9.0-rc.2 plugin version. It seems the code change labelled "Solution 2" by both @Shusshu and @Marchelo never made it into the master branch, as the very same issue brought up and discussed here is still there. I have an APK project which depends on one AAR library project, which in turn has a dependency on a third-party library shipped as AAR (a well-known Google Play Services v4). Everything compiles and builds well until we get to dex stage of final APK. There, plugin fails because of a Dex tool error - duplicate BuildConfig class found. The BuildConfig for third-party dependency gets packaged into my library AAR, but then it is produced again when building the final APK, as third-party dependency is still there, it is of AAR type, hence it is handled as such (i.e. both R and BuildConfig are dynamically created).. Could we somehow 1) tell Dex tool to use only one instance of each duplicate class (for example, the first one), or 2) explicitly re-create BuildConfig for each transitive AAR dependency? Alternatively, may it be possible to simply and brutally filter out existing BuildConfig instances from transitive AAR dependencies when building APK, as they would be re-created anyway by the ApkMojo goal? |
|
Can you create a new issue with a sample project reproducing the problem? that would help fixing it. |
|
After spending an hour or so digging through the problem and analyzing whole dependency tree for APK project, two issues were spotted by me. Overall, plugin seems to be doing exactly what it has to, with some minor exceptions I will outline below. One issue was entirely an in-house edge case, where one of the transitive dependencies was apparently plugged in as both AAR and JAR (legacy of awkward APKLIB support in Eclipse...), with JAR having that nasty already-generated BuildConfig class. As JAR dependencies are not handled in any special way by the plugin - and this is right - the duplicate BuildConfig ended up in APK project. The other issue is the way plugin checks for presence of BuildConfig in all AAR dependencies. It does a fine job, BUT each time it checks a transitive dependency, its OWN package namespace is used, not the package name of original AAR artifact that is being built. I have submitted a fairly simply pull request #403 . This does not seem like a big deal, but would be good to apply the change. |
What steps will reproduce the problem?
Adding the following lib: https://github.com/jgilfelt/SystemBarTint
OR the appcompat-v7 lib
What is the expected output?
Build Success
What do you see instead?
[INFO] UNEXPECTED TOP-LEVEL EXCEPTION:
[INFO] java.lang.IllegalArgumentException: already added: Lcom/readystatesoftware/systembartint/BuildConfig;
What version of maven-android-plugin are you using?
3.9.0-rc.1 & current 3.9.0-SNAPSHOT (2014/04/10)
What are the complete output lines of "mvn -version" on your machine?
3.2.1
java 1.7.0_51
Please provide any additional information below.
In this library the BuildConfig is included in the aar (classes.jar)
But for ActionBarSherlock the BuildConfig is not included in the aar (based on comments in the GenerateSourcesMojo).
Should the aar contain the BuildConfig or should android-maven-plugin generate it or should it check if it needs to generate it or not?
Sample project: https://maven-android-plugin.googlecode.com/issues/attachment?aid=4560002000&name=tictactoe.rar&token=koNVAMhc7WzZFlNalJ57WBs2DEc%3A1397132888054
Previous tracker ticket: 456 https://code.google.com/p/maven-android-plugin/issues/detail?id=456
The text was updated successfully, but these errors were encountered: