ProGuard and android-maven-plugin; does not run with 3rd party dependencies

[Matthias]

Hey guys,

we're currently looking into getting ProGuard run as part of our Maven build. However, we found a few strange issues that we can't seem to sort out properly.

So the problem is this: as part of the build, something (I assume android-maven-plugin?) creates a folder called android-classes in target/, which does not only contain the app's classes but also all classes of all the project's dependencies. That folder is then fed as the single -injars to the ProGuard plugin, as per the morseflash example. Now that's a problem, since we end up with a gazillion of "duplicate class" errors, since all the dependencies that are flattened into that folder are passed again as -libraryjars when ProGuard is invoked. That happens to works for the morseflash example, but only by accident. The reason is simply that morseflash does not have any 3rd party dependencies other than the Android JARs, which are not extracted into android-classes/. One would think that we could simply set includeDependency to false for the proguard-maven-plugin, but that will unfortunately also remove the dependency to the android.jar.

Bottom line being: if we filter all classes that are not part of our app from the input folder, then we end up with a classes.dex that does not include the classes of any library dependencies. Conversely, if we keep these, but remove them from the libraryjars, then ProGuard will not even run anymore (for obvious reasons). Now I guess we could do something like adding all dependencies *except* the Android ones to an excludes block, that seems like a wild hack to me.

Is this a known problem? How does everyone actually do this? Is there any way to not have android-maven-plugin flatten all dependencies into the android-classes folder but instead have ProGuard pick up all the dependency JARs separately as -injars? (that's how I think it should work ideally)

Thanks!

[Matthias]

PS: you can easily reproduce this by simply adding a 3rd party dependency from Maven Central to the morseflash-app POM:

    <dependencies>

        <dependency>

            <groupId>com.simpligility.android.morse</groupId>

            <artifactId>morse-library</artifactId>

            <version>${project.version}</version>

        </dependency>

        <dependency>

            <groupId>junit</groupId>

            <artifactId>junit</artifactId>

            <scope>test</scope>

        </dependency>

        <dependency>

            <groupId>com.google.android</groupId>

            <artifactId>android</artifactId>

            <scope>provided</scope>

        </dependency>

        <dependency>

            <groupId>com.google.android</groupId>

            <artifactId>android-test</artifactId>

            <scope>provided</scope>

        </dependency>

<!-- added this one -->

        <dependency>

            <groupId>oauth.signpost</groupId>

            <artifactId>signpost-commonshttp4</artifactId>

            <version></version>

        </dependency>        

    </dependencies>

Now run:

$mvn clean install -Prelease

The build will fail during the proguard step with "duplicate definition of library class" errors on all dependencies of Signpost, and the library itself. That's because all these classes are also found in the android-classes/ folder generated at build time. This will be further complicated if you don't depend on the Android JARs from Central, but on the original ones when deployed e.g. via maven-android-sdk-deployer, since these contain Apache HttpClient (and other open source libraries) in the JAR itself, so not even an exclude would work.

[Luigi Agosti]

I try a bit ....

with the following exclusions I get just 8 warning about missing references

<dependency>

            <groupId>com.simpligility.android.morse</groupId>

            <artifactId>morse-library</artifactId>

            <version>${project.version}</version>

        </dependency>

        <dependency>

            <groupId>junit</groupId>

            <artifactId>junit</artifactId>

            <scope>test</scope>

        </dependency>

        <dependency>

            <groupId>com.google.android</groupId>

            <artifactId>android</artifactId>

            <scope>provided</scope>

            <exclusions>

              <exclusion>

                <groupId>commons-logging</groupId>

                <artifactId>commons-logging</artifactId>

              </exclusion>

            </exclusions>

        </dependency>

        <dependency>

            <groupId>com.google.android</groupId>

            <artifactId>android-test</artifactId>

            <scope>test</scope>

        </dependency>

    <dependency>

            <groupId>oauth.signpost</groupId>

            <artifactId>signpost-commonshttp4</artifactId>

            <version>1.2.1</version>

            <exclusions>

              <exclusion>

                <groupId>commons-codec</groupId>

                <artifactId>commons-codec</artifactId>

              </exclusion>

              <exclusion>

                <groupId>org.apache.httpcomponents</groupId>

                <artifactId>httpcore</artifactId>

              </exclusion>

              <exclusion>

                <groupId>org.apache.httpcomponents</groupId>

                <artifactId>httpclient</artifactId>

              </exclusion>

            </exclusions>

        </dependency>

there are still a lot of duplications I think you need to check them 

the majority are due to xmlParserApi importing stuff that are in jre rt.jar and

[proguard] Reading library jar [/usr/lib/jvm/java-6-openjdk/jre/lib/jsse.jar]

 [proguard] Initializing...

 [proguard] Note: there were 222 duplicate class definitions.

 [proguard] Warning: oauth.signpost.signature.HmacSha1MessageSigner: can't find referenced class javax.crypto.spec.SecretKeySpec

 [proguard] Warning: oauth.signpost.signature.HmacSha1MessageSigner: can't find referenced class javax.crypto.spec.SecretKeySpec

 [proguard] Warning: oauth.signpost.signature.HmacSha1MessageSigner: can't find referenced class javax.crypto.Mac

 [proguard] Warning: oauth.signpost.signature.HmacSha1MessageSigner: can't find referenced class javax.crypto.Mac

 [proguard] Warning: oauth.signpost.signature.HmacSha1MessageSigner: can't find referenced class javax.crypto.Mac

 [proguard] Warning: oauth.signpost.signature.HmacSha1MessageSigner: can't find referenced class javax.crypto.Mac

 [proguard] Warning: oauth.signpost.signature.HmacSha1MessageSigner: can't find referenced class javax.crypto.SecretKey

 [proguard] Warning: oauth.signpost.signature.HmacSha1MessageSigner: can't find referenced class javax.crypto.Mac

 [proguard] Warning: there were 8 unresolved references to classes or interfaces.

 [proguard] Note: You're ignoring all warnings!

 [proguard]          You may need to specify additional library jars (using '-libraryjars'),

 [proguard] Ignoring unused library classes...

 [proguard]          or perhaps the '-dontskipnonpubliclibraryclasses' option.

 [proguard]   Original number of library classes: 18947

 [proguard]   Final number of library classes:    316

 [proguard] Printing kept classes, fields, and methods...

 [proguard] Shrinking...

 [proguard] Removing unused program classes and class elements...

 [proguard]   Original number of program classes: 53

 [proguard]   Final number of program classes:    7

 [proguard] Inlining subroutines...

 [proguard] Optimizing...

[Luigi Agosti]

I added the jce jar

<lib>${env.JAVA_HOME}/jre/lib/jce.jar</lib>

this for me is removing all the warnings ...

apart from duplications from jre jars I just have this duplications now to check now

not sure exactly which jar is importing them to cause the duplication

 [proguard] Reading library jar [/home/luigi/.m2/repository/oauth/signpost/signpost-commonshttp4/1.2.1/signpost-commonshttp4-1.2.1.jar]

 [proguard] Note: duplicate definition of library class [oauth.signpost.commonshttp.CommonsHttpOAuthConsumer]

 [proguard] Note: duplicate definition of library class [oauth.signpost.commonshttp.HttpRequestAdapter]

 [proguard] Note: duplicate definition of library class [oauth.signpost.commonshttp.CommonsHttpOAuthProvider]

 [proguard] Note: duplicate definition of library class [oauth.signpost.commonshttp.HttpResponseAdapter]

 [proguard] Reading library jar [/home/luigi/.m2/repository/oauth/signpost/signpost-core/1.2.1/signpost-core-1.2.1.jar]

 [proguard] Note: duplicate definition of library class [oauth.signpost.http.HttpResponse]

 [proguard] Note: duplicate definition of library class [oauth.signpost.http.HttpParameters]

 [proguard] Note: duplicate definition of library class [oauth.signpost.http.HttpRequest]

 [proguard] Note: duplicate definition of library class [oauth.signpost.OAuth]

 [proguard] Note: duplicate definition of library class [oauth.signpost.exception.OAuthException]

 [proguard] Note: duplicate definition of library class [oauth.signpost.exception.OAuthNotAuthorizedException]

 [proguard] Note: duplicate definition of library class [oauth.signpost.exception.OAuthMessageSignerException]

 [proguard] Note: duplicate definition of library class [oauth.signpost.exception.OAuthCommunicationException]

 [proguard] Note: duplicate definition of library class [oauth.signpost.exception.OAuthExpectationFailedException]

 [proguard] Note: duplicate definition of library class [oauth.signpost.OAuthProvider]

 [proguard] Note: duplicate definition of library class [oauth.signpost.OAuthConsumer]

 [proguard] Note: duplicate definition of library class [oauth.signpost.AbstractOAuthConsumer]

 [proguard] Note: duplicate definition of library class [oauth.signpost.signature.QueryStringSigningStrategy]

 [proguard] Note: duplicate definition of library class [oauth.signpost.signature.OAuthMessageSigner]

 [proguard] Note: duplicate definition of library class [oauth.signpost.signature.SigningStrategy]

 [proguard] Note: duplicate definition of library class [oauth.signpost.signature.SignatureBaseString]

 [proguard] Note: duplicate definition of library class [oauth.signpost.signature.PlainTextMessageSigner]

 [proguard] Note: duplicate definition of library class [oauth.signpost.signature.HmacSha1MessageSigner]

 [proguard] Note: duplicate definition of library class [oauth.signpost.signature.AuthorizationHeaderSigningStrategy]

 [proguard] Note: duplicate definition of library class [oauth.signpost.AbstractOAuthProvider]

 [proguard] Note: duplicate definition of library class [oauth.signpost.basic.DefaultOAuthConsumer]

 [proguard] Note: duplicate definition of library class [oauth.signpost.basic.HttpURLConnectionRequestAdapter]

 [proguard] Note: duplicate definition of library class [oauth.signpost.basic.DefaultOAuthProvider]

 [proguard] Note: duplicate definition of library class [oauth.signpost.basic.UrlStringRequestAdapter]

 [proguard] Note: duplicate definition of library class [oauth.signpost.basic.HttpURLConnectionResponseAdapter]

 [proguard] Note: duplicate definition of library class [oauth.signpost.OAuthProviderListener]

 [proguard] Note: duplicate definition of library class [com.google.gdata.util.common.base.UnicodeEscaper$1]

 [proguard] Note: duplicate definition of library class [com.google.gdata.util.common.base.Preconditions]

 [proguard] Note: duplicate definition of library class [com.google.gdata.util.common.base.UnicodeEscaper]

 [proguard] Note: duplicate definition of library class [com.google.gdata.util.common.base.PercentEscaper]

 [proguard] Note: duplicate definition of library class [com.google.gdata.util.common.base.Escaper]

 [proguard] Note: duplicate definition of library class [com.google.gdata.util.common.base.UnicodeEscaper$2]

[Matthias]

Hi Luigi!

thanks for looking into this. We do not add rt.jar as an injar for ProGuard, since we do not use the Android JAR from Central, but the one shipped with the SDK (which already includes all Java framework classes). So I don't think that would help in our case.

You're absolutely right about commons-logging, we actually do exclude that already (and a few others I believe) as part of our project's dependency set up.

Using an exclude block in the ProGuard plugin config is not feasible for us, however. With transitive dependencies, we'd end up listing 20-something excludes there, I don't think I want to maintain that! Moreover, since all classes in the HTTP package are bundled with android.jar (and not pulled in as a separate artifact from Central as is the case in the morseflash app (which uses the community Android JAR from Central), we'd need a more fine grained way of excluding things than just by artifactId.

From what I understand (and by comparing it to how we did it with gradle-android-plugin), the problem may be that the project's dependencies are processed twice by the plugin: once they are merged with the application's class files, and then given to ProGuard in one go, as a single injar. Then however, they are all passed again as libraryjars. As far as I know the libraryjars option should only be used for libraries that have "provided" semantics. With Gradle what we did is pass every project dependency as a separate injar, and only pass the Android JARs as libraryjars. That worked fine. More specifically:

      injar(path: project.jar.archivePath)

      // Add each dependency into the ProGuard-processed JAR
      project.configurations.compile.files.each { dependency ->
        injar(file: dependency)
      }
      outjar(file: tempFilePath)
      ant.references['android.target.classpath'].each { targetjar ->
        libraryjar(file: targetjar)
      }

I don't exactly recall what was contained in "android.target.classpath" (the Android Ant tasks set that up), but I think it was simply the paths to android.jar and vendor specific or extra APIs shipped with the SDK.

That being said, this may well be an issue with proguard-maven-plugin and not android-maven-plugin, I'm just wondering whether others had the same problems before, since our situation seems like a very common one to me.

[Manfred Moser]

Somebody posted an alternative implementation of the proguard stuff as
part of the android maven plugin on the list a while ago. This still needs
fix up and integration but might be worth looking into. Check the archive
to find the github clone url..

manfred

> --
> You received this message because you are subscribed to the Google Groups
> "Maven Android Developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/maven-android-developers/-/L_2DTaDyJ-UJ.
> To post to this group, send email to
> maven-androi...@googlegroups.com.
> To unsubscribe from this group, send email to
> maven-android-deve...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/maven-android-developers?hl=en.
>
>

[Matthias]

Thanks Manfred, found it, I'll speak to him.

[Manfred Moser]

On Thu, November 3, 2011 1:41 am, Matthias wrote:
> Thanks Manfred, found it, I'll speak to him.

I am contemplating pulling this in even if it is not yet fully baked and
take it further together in master... wdyt?

manfred

[jonson]

Hey guys

I will throw this up on github shortly, just testing it out after I merged the latest code.

Cheers

Jon

[Matthias Käppler]

fantastic guys, thanks! Let me know when you having something ready,
I'd be more than happy to help testing it.

2011/11/3 jonson <jdey...@gmail.com>:

> --
> You received this message because you are subscribed to the Google Groups
> "Maven Android Developers" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/maven-android-developers/-/LhI-xHJiR5sJ.

> To post to this group, send email to
> maven-androi...@googlegroups.com.
> To unsubscribe from this group, send email to
> maven-android-deve...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/maven-android-developers?hl=en.
>

--
-Matthias

[jonson]

OK I dug up my old code and thrown it up here:  https://github.com/jonson/maven-android-plugin

It's not ready for primetime yet, this seems to break some test cases in the build.  Also, I haven't tested with a real project yet, but the idea is as follows:

 * DexMojo changed to read the input from directory + dependent jars, rather than the "android-classes" directory.  When dealing with proguard, use that as input (ugly impl in there now).

 * UnpackMojo removed from build, this is no longer needed -- just extra CPU cycles.

 * new proguard mojo that uses the bundled SDK proguard jar.  no config options yet, will need to add these before enabling this.

To use it, simply add the following to your pom:

...

            <plugin>

                <groupId>com.jayway.maven.plugins.android.generation2</groupId>

                <artifactId>android-maven-plugin</artifactId>

                <configuration>

                    <sdk>

                        <!-- platform or api level (api level 4 = platform 1.6)-->

                        <platform>4</platform>

                    </sdk>

                    <proguard>

                        <config>proguard.cfg</config>

                    </proguard>

                </configuration>

            </plugin>

....

I'm not really comfortable with the dex change, I don't know the codebase enough to know if this is breaking anything.  It *should* be fine, this is the process the Android ant build uses.  I'll try to test it out a bit more and will push any changes here.   I think the best way is to break this into two separate changes, first add the configurable dex input change, then the proguard support.

[Matthias]

So I finally had time to look into this, and not sure if I'm missing something, but it still doesn't work for me (no difference in fact to what we had before, which makes me think that I'm probably doing something wrong).

What I did is this:

$git remote add jonson git://github.com/jonson/maven-android-plugin.git

$git fetch jonson

$git co jonson/master

$mvn clean install

that should be enough to pull in your changes for all android-maven builds on my machine no? Oddly all tests passed and I believe you mentioned they didn't pass for you, so I'm wondering if I'm looking at the correct branch? I see proguard related commits in jonson/master so I thought that's the one.

[Matthias]

In fact, perhaps I simply didn't quite understand what the changes were that you made. I see there is now a proguard tag in the android plugin configuration. Does this replace the proguard plugin altogether? I was also wondering what's the difference between having a <proguard><config>proguard.cfg</config></proguard> in the android plugin configuration vs having a <options><option>@proguard.cfg</option></options> in the proguard plugin config?

[Matthias]

Nevermind, forgot to rewire the version to -SNAPSHOT...

It's still not working for me, and I see a few problems with the code. I'll see if I can some up with a patch by tonight.

[Matthias]

Sorry for the flood of messages, but I'm struggling a little here since I've never done any Maven development before. Let me first point out the problems that still persist:

1) when collecting the list of dependency injars, instead of getAllRelevantDependencyArtifacts, getRelevantDependencyArtifacts should be used. That's because otherwise any <exclude> directive will be ignored (and with the JARs from the SDK, we need to exclude Apache HttpClient and a few other things; we could even think about excluding them by default, but that's another story).

2) even with 1) fixed, getRelevantDependencyArtifacts merely collects the direct dependencies of the project, which is not sufficient. We need the transitive closure, since application code may reference dependencies of dependencies, in which case ProGuard will currently break with "can't find referenced class" errors. For instance, our project declares a direct dependency to signpost-commonshttp4, which in turn depends on signpost-core (to which we do not declare an explicit dependency), but we use classes from both artifacts in code.

3) while the mojo automatically adds android.jar, it does not add maps.jar. Since it currently seems to exclude any dependencies with provided scope, this will fail for any apps that require functionality from SDK extensions (not just the maps stuff; any vendor specific JARs.)

4) not sure whether this is a problem, but the way the plugin currently determines the library JARs to link (i.e. the Android JARs) doesn't look very Maven-ish to me. It constructs a path to your SDK installation, and links the JARs from there:

Reading library jar [/Users/matthias/Library/Development/android-sdk-mac_86/platforms/android-10/android.jar]

That will break on build servers, where no SDK is installed (our Jenkins pulls these from a Nexus repo). Instead, this should not be handled any different from how the injars are resolved, i.e. via Maven's repository/artifact API. This will then also be in line with how maven-android-sdk-deployer works, since it deploys Android JARs as maven artifacts to the local artifact cache.

Now, as for how to fix all this. 1) is simple enough, I already did that. 2) I investigated this, and could not find out how to properly do that in Maven 3. MavenProject.getDependencies used to return the entire tree in Maven 2, but does not anymore in Maven 3. There's a class called DefaultArtifactResolver, but it's deprecated and only contained in a back compat JAR. So I suppose that's not the way to go. Any pointers? I was a little surprised at the lack of documentation in Maven. I couldn't find a single documented plugin API in the official JavaDoc... :-(

As for 3), again, I couldn't find an API that allows me to retrieve the location of extension modules in the SDK. If we had that, would it be safe to simply always feed these to ProGuard as library jars? I suppose that if not used by the app, that would simply do nothing, and when used, it'd already be there.

Thoughts / suggestions?

[Manfred Moser]

I cant answer in detail now but for dependency stuff you have to use
aether. Look at

https://github.com/jayway/maven-android-plugin/blob/master/src/main/java/com/jayway/maven/plugins/android/phase05compile/NdkBuildMojo.java

and

https://github.com/jayway/maven-android-plugin/blob/master/src/main/java/com/jayway/maven/plugins/android/common/AetherHelper.java

and ask on the list for more..

> --
> You received this message because you are subscribed to the Google Groups
> "Maven Android Developers" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/maven-android-developers/-/QPMHF14JkdUJ.

[Johan Lindquist]

The NativeHelper.java [1] class may also be of help

Cheers,

Johan

[1] https://github.com/jayway/maven-android-plugin/blob/master/src/main/java/com/jayway/maven/plugins/android/common/NativeHelper.java

[Matthias]

Thanks guys. I think ProGuard hates me. Spent all day on this yesterday, and I felt like I was only clambering from one problem to the next.

So what I have done so far is take the project's full dependency tree (turned out I didn't have to use the Aether APIs for that, I think the problem that the helpers from AbstractAndroidMojo didn't return the full set had to do with my POM setup), and separate them into those that have provided scope, and those that don't. Artifacts with provided scope I add as libraryjars, the rest as injars (that's a relatively simple fix for most problems I raised before).

Problem is: I still get a bunch of "references class not found" errors, and I simply don't understand why. Looking at the options used to invoke ProGuard, I am now doing exactly what I did with our older project setup (where we used Gradle), but here it doesn't work, and in the old setup it worked. The only difference in implementation of Gradle's proguard task and android-maven's proguard mojo is that in Gradle we used the ProGuard Ant task instead of doing a command line invocation. Since that was the only difference I could see, so mostly out of desperation I rewrote the entire Mojo to use proguard.ant.ProGuardTask (it's part of proguard.jar in the SDK), but no luck.

One thing that definitely makes the whole thing very complicated is adding support for the android.jar that's shipped with the SDK. Since that JAR contains a few open source libraries (json.org, Apache HttpClient, commons-codec), you end up with duplicate class definition errors when one of your other project dependencies depend on one of those libraries from Central. One thing I started looking into are ProGuard filter expressions. With these you can filter directories from input JARs from being processed. We could leverage that to ignore, for instance, org.apache.* in android.jar. I didn't finish working on this yesterday though. We're unfortunately already behind schedule with our project, so I won't have time to look into this further today, but perhaps I'll find some time over the weekend.

Sorry, I was hoping this would be simpler than it turned out to be...

[Matthias]

There's nothing like a good night's sleep. Fixed all the issues this morning.

https://github.com/jayway/maven-android-plugin/pull/78

Let me say I'm slightly optimistic the changes I made will work for most or even all scenarios, but I'm by no means I'm sure about that. I still find that black magic ProGuard performs slightly scary and difficult to understand, and quite a few changes I made were based around trial and error (meaning I don't have a good explanation for everything, e.g. I don't understand why it's required to blacklist commons-logging, it just always got in the way).

Moreover, I think that at some point we should make the thing more configurable (the only setting it supports right now is the path to the config file). But that's for another day :-)

Can you please both review my code and test it with your own projects? Tested it with morseflash-app and our app, both worked fine.

[Matthias]

Okay so one thing I noticed is that when ProGuard becomes part of the build equation, instrumentation tests will fail to build (the DEXer breaks with duplicate class errors). I guess that is because the test project is working off a minimized version of the app JAR or something, I didn't really dig into it. I think it's not a game breaker, but should be investigated at some point.

[Manfred Moser]

Hi Matthias,

This is AWESOME. I will pull it in next week and probably wrap a
configuration around like so that proguard is disabled by default and you
can then enable it and I might add some more config options like path to
the proguard config file and maybe others

I envisage something like

<configuration>
<proguard>
<skip>true<skip>

to be the default so to activate it you just add it with false into the
release profile.

Sounds good?

manfred

> --
> You received this message because you are subscribed to the Google Groups
> "Maven Android Developers" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/maven-android-developers/-/z0BMCWDqpjUJ.

[Matthias Käppler]

Perfect, thanks!

Jonson, can you please double check if everything's still working for you? I really want to make sure the latest changes didn't introduce any regressions for anyone.

--
sent on the run, from my precious nexus one. (it rhymes!)

[Manfred Moser (simpligility)]

I am digging into the failures now since as far as I am concerned the samples projects build has to succeed before we can pull this in. Once I get the build of the samples project to succeed I will update them to use the new proguard goal and see how that goes.. 

If someone wants to help you could create proguard.cfg files for the samples apps that duplicate the setup that currently resides in the pom.xml file and see if you get the scala app and the release profile of the morseflash app to work..

manfred

[Matthias Käppler]

thanks Manfred, I'll try to put some time aside for this this week. I
didn't realize that some samples were failing, only tried the
morseflash sample.

2011/11/15 Manfred Moser (simpligility) <man...@mosabuam.com>:

> --
> You received this message because you are subscribed to the Google Groups
> "Maven Android Developers" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/maven-android-developers/-/ARPfLFEH_m4J.

> To post to this group, send email to
> maven-androi...@googlegroups.com.
> To unsubscribe from this group, send email to
> maven-android-deve...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/maven-android-developers?hl=en.
>

--
-Matthias

[Manfred Moser]

The main thing is the instrumentation tests failing. I think once we get
that to work we should be golden..

manfred

[Matthias]

Will spend some time on this today, but have a few questions already: first, the tests don't even pass on the master branch for me, i.e. without my changes. The Scala project fails during the ProGuard step (that's the old proguard goal). Here's the error: http://pastebin.com/raw.php?i=YKezhVu3. For now I'll ignore that and fix the things that are specific to the changes in the proguard-support branch.

Second, I know you're not using Eclipse, but perhaps someone knows how to fix that: when importing the sample projects, I get the following error on all projects that have the Android project nature:

Plugin execution not covered by lifecycle configuration: com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.0.0-SNAPSHOT:proguard (execution: default-proguard, phase: process-classes) pom.xml /application line 39 Maven Project Build Lifecycle Mapping Problem

No idea what that means. That related to the incompatibility of m2e-android-integration with the latest tools release? Any pointers? Thanks!

[Macarse]

To make the scala sample code work you might need to define the JAVA_HOME env var.

--

You received this message because you are subscribed to the Google Groups "Maven Android Developers" group.

To view this discussion on the web visit https://groups.google.com/d/msg/maven-android-developers/-/IPBHdKYuzRQJ.

[Matthias]

Thanks, that helped. I have added two commits to the pull request that fix all issues, except Scala support.

The problem with the Scala JAR is that it must be processed both as a program JAR, and a library JAR. It must be processed as a program JAR since it must be deployed with the app. It must be processed as a library JAR, too, since it references classes from the Java JDK, and the JDK classes are added as library JARs, not program JARs. That being said, it currently fails with "can't find referenced class" errors, I think most are related to XML stuff. The problem is that I am not familiar with Scala, and the workarounds I tried so far did not help.

It would be cool if someone else could look into this, someone who has experience with building Scala apps on Android? I think if we can sort out this last issue, we should be good to go.

Oh and with my last 2 commits, I believe I know removed all references to the android-classes output folder that is generated by UnpackMojo. In return, this probably means that it is now safe to remove that class entirely. But let's wait with the cleanup until everything's working again.

[Manfred Moser (simpligility)]

Ok.. in the interest of fixing this all up together I have 

a. pulled the current state into master

b. deactivated the failing samples in master

These are the scala and the native/java-transient-dependency examples. 

It would be great if you could look at the ones breaking and working on getting them up and running again. I hope to work on the config for the mojo a bit and maybe look at the scala example myself later this week.

In any case.. any help would be greatly appreciated. Once we got this in I believe we should just just 3.0.0 final.. and ref further versions after and in parallel deprecate any <3.x

manfred

[Manfred Moser (simpligility)]

Ok... I have ported the morseflash app to use the new proguard integration for the release profile. Feel free to test it with

mvn clean install -P release 

in the app folder of the example.

I have also migrated the scala app to use the new proguard integration and reactivated it since it works again.

The native transitive dep example is the only deactivated example now that still fails and needs some attention. 

I will leave that to somebody with more clue about the native stuff.. 

manfred

[Johan Lindquist]

If I am lucky enough, I might get a moment free to catch up with it this week ...

Johan

manfred

--
You received this message because you are subscribed to the Google Groups "Maven Android Developers" group.

To view this discussion on the web visit https://groups.google.com/d/msg/maven-android-developers/-/ff2OnH1cZKUJ.

[Manfred Moser]

That would seriously rock!

[Johan Lindquist]

Looks like there is a clash of class names when the dexing is done - the generated & compiled R.class from the 'Java with Native Dependency' clashes with the R.class in the 'Java with Transient Dependency' (simply because they share the same package names).  Guess the old method of overwriting (assume this was what happened?) the content in the classes output directory, preventing the collision.

Quick fixes available:

a) rename the packages (emulates real-life more, drawback is that native samples would all install as separate apps)
b) remove the strings.xml for all native samples (only have a single entry in this file)

Either way would be fine, but not thinking a) would probably be a better fix - any thoughts?  I ask since this is not necessarily an issue with native code only - any clashes of names within dependent jars would cause this - but rightly so.

Johan

[Manfred Moser]

The more real life the examples are the better so I would suggest we implement a) .. separate apps is no problem imho.

If you or someone else can implement that I can pull it into master and we should be good with another release.

manfred