adding new mojos for file based deployments separate from project based ones
adding new mojos for file based deployments separate from project based ones
Fixed deploy, undeploy and redeploy mojos to work in multi module
projects, moved support for file/package parameters into separate mojos,
cleaned up some logging
added config for deploy apk mojos and related cleanup
added clean goal to builds
GenSources: Only copying library assets to combined assets during apk build.
GenSources: Only adding aar or apklib resources to R generation for apk build.
ConsumeAar: Not unpacking Aar lib classes into target classes. Just adding Aar lib class to compilation path.
Aar: Not including lib resources (should only be included for apk build)
Aar: Not including lib assets (should only be included for apk build)
Give the possibility to set a list of device
More cleanup of the File resource returned by AbstractAndroidMojo
added comment about android sdk component upgrade and resulting problems to avoid others falling into the same problem
updated parent pom
Merge branch 'master' into deployapk
updated documentation for un/re/deploy mojos
Slight logging cleanup.
Removed Javadoc checks because they are hiding other potential bugs.
If we want to keep those checks then we need to fix up all the Javadoc errors and upgrade the severity to error.

 Also relaxed nr of params to 10 to allow for BuildHelper.
NB the plugin is NOT WORKING as of this commit.

This commit introduces the AarMavenLifecycleParticipant which is invoked after the project is read but before any Mojos have been executed. It has been suggested by Igor that this is where we need to add the dependent Aar lib classes to the compile classpath. That means we need to extract the libs here and THEN add the Aar classes to the compile classpath. IMHO this is also where we should be adding any apklib sources to the compileSourceRoot too.
NB the AarMavenLifecycleParticipant actually works and successfully extracts the libs, nut doesn't add the classes to the compile classpath.

Also introduces the AarMavenLifecycleParticipantPlayground which is a testing ground for altering the compile classpath. It is currently failing because it is not being successfully injected with the

This commit also includes BuildHelper which does all the heavy lifting of extracting the libs into target\unpacked-libs. It was a necessary addition because we need this func in the MavenLifecycleParticipant, and this functionality was originally in ConsumeAarMojo and AbstractAndroidMojo. They both now delegate to the BuildHelper.

Final class is MavenDependencyInjector which is just a copy from Tycho of a class that Igor suggested should how to inject classes into the compile classpath. I have left it there as reference. It should be deleted before release.

What needs to be done is to get AarMavenLifecycleParticipantPlayground to alter the compile classpath. Once that is proven we should push that into the AarMavenLifecycleParticipant and remove AarMavenLifecycleParticipantPlayground.
At that point ConsumeAarMojo becomes redundant.
Add the new force jumbo flag for dex.
setting default value for api level in sdk so that plugin executions outside of a maven project dont fail
fully working new mojo to deploy an apk file
completed implementation and documentation for new standalone goals
Merge pull request #272 from jayway/deployapk

(Un/Re) deployment improvements