Adds support for predexing libraries to speed up dexing for application

[sragu]

From sdk release 21, android supports pre-dexing of jar files to speed up application build time.

I have integrated support for that in the maven plugin, I am thinking of adding a flag to enable or disable it or fail gracefully if the sdk version is not r21?

Let me know if it will useful for your guys and any other suggestions.

[reneploetz]

It would be really nice to have a configurable folder for the predexed files to prevent that these files end up in the local maven repository or in case of multi-module projects in the build directory of the dependent project.
This might require naming the resulting files using some content matching algorithm (like MD5 that is used in the ant dex task) to prevent duplicate dependency artifact names causing issues. Additionally this would have the benefit of using the algorithm to detect changes in those files and not depending on the file modification date.
The problem with the current (fixed) location is that one cannot easily clean the whole build using a regular "mvn clean", as well as we would automatically add files to the repository which might not be acceptable for all users.

[sragu]

Configurable folder for predexed files is a good idea, so they could override it. For me sub-directory under target didn't work because I use 'mvn clean' all them time. Since maven is not often incremental like the default ant tasks it would be no benefit if it were cleaned for every run. But sure I will make it to the sub-directory under target folder and make it even configurable so users like me could override it.

Using md5 might not help that much because maven jar files are already unique due to versioning, not like ant libs folder. Also Ant DexExecTask just does md5 hashing based on name not by content. It will not be beneficial considering the effort to add md5 or including a library that does md5.

[reneploetz]

I also use 'mvn clean' all the time. My concern is about CI and their handling of multi-module / same-version multi-branch projects as well as Eclipse integration.

For CI an option to disable such a feature would be nice, either by specifying a directory they clean anyway or some option to disable it altogether or both.
To me it seems best to use a flag whether to enable it (defaulting to no - so we don't risk breaking CI or older SDKs), if enabled defaulting to the dependent jar location (so you don't need much logic for a path pointing to a repository [= a hierarchy of folders]), and being able to specify an arbitrary folder which could be used instead.

The other thing is the Maven-Android-Eclipse-ADT-Integration. If we would use the hashing algorithm users could opt to specify 'dexedLibs' as target folder and Eclipse ADT would not try to predex again.

You are right that the ant task is using MD5 on file names (and not actual 'content' as I stated). Even tough MD5 is already provided by J2SE MessageDigest, I'm not sure if this is worth implementing for integration purposes outlined above as I'm not sure if such a feature is would be used in practice.

[mosabua]

imho the predexed files should go into target so that the clean goal works as expected. I realise that this is a problem at the moment since not using clean has issues with the plugin but that does not justify building on something that is wrong. Rather we should predex into target and work using mvn install and if that does not work (as is currently the case) then we should improve the incremental behaviour of the plugin.

Also it should definitely be off by default or at least deactivate itself for older sdk versions (the manifest update goal does that .. check there).

As a compromise I suggest to implement the default predexed files to go into target and provide a configuration parameter that allows you to change it to a different location. This way we can use it for now with the parameter and it can be used e.g. across multiple projects as well.. but the users will have to be aware of the behaviour and the default behaviour dexing into target is working correctly. Then we should look into fixing incremental builds..

[mosabua]

Ping me here if there is any progress regarding my comments.

[sragu]

Made the changes, except being able to override the dexed jar location from the default

• Predexing is off by default
• dexed lib directory is now under target/dexedLibs

What would be good name to add such property which would override the default dexed jar location? dexLibLocation under Dex.java ?

[mosabua]

Maybe preDexLibLocation .. otherwise this is good. I am going to pull it in as is for now..

[ericps]

predexing is very slow. I have a python script that eventually runs the ant release script many times for different configurations of my app, and each time it spends a long time pre-dexing all of the libraries now. After updating to r21 this has slowed down my build time considerably. Is there an option to turn off predexing because for me it is slower, not faster.

[sragu]

predex is turned off by default. you can enable or explicitly disable by setting flag

<dexPreDex>false</dexPreDex>

Predex is slower the first time its used, but it improves build time from the next time. If you are using mvn clean, the predex jars (stored on target/dexedLibs) is cleared every time thus it runs every time making the build time longer.

We already have pull request (#171) to make the location of predexed jars configurable, so you can chose them to be outside target folder thus not cleaned on mvn clean install.

[stephanenicolas]

Javadoc should be updated now : The right settings are :

 <dex>
   <preDex>true</preDex>
   <preDexLibLocation>/tmp/predexedLibs</preDexLibLocation>
</dex>

The header of the Dex mojo is wrong and the goals doc from maven site gets wrong too.

[mosabua]

Pull request ;-) ?

[stephanenicolas]

I updated the docs. I will include it with my next pull request this week.