Android Maven Plugin Version 3.4.0 released
The Android Maven Plugin team is pleased to announce the release of version 3.4.0 of the plugin. New features are - Added support to specify application makefile in ndk-build - New additional parameter for proguard goal, "outputDirectory" - Support for building arm and x86 at the same time - Fixed ndkstripper when no toolchain is specified - Fixed parsing of error message from test failures - Check renameManifestPackage parameter before using package from AndroidManifest.xml - Make inclusion of JDK libs in ProGuard input optional - Configure BuildConfig? generation via a mojo parameter instead of system property - Added code to merge APKLIB manifests - Improvements and fixes for APKLib support with Native code including sample projects - Clean up of configuration for zipalign goal to work properly with pom, settings and command line config - Fix for failure when ndk-build run twice by task sequence Attention the zipalign goal now needs the skip parameter set to false in order to execute (just like the proguard goal). When upgrading please ensure to check the change log for further details: http://code.google.com/p/maven-android-plugin/wiki/Changelog We would like to thank the contributors to this release for their valuable help and invite you all to help us out as well: Jonathan Reyes http://vaporwarecorp.com Michal Harakal https://github.com/michalharakal Aleksander Pyszny https://github.com/olekp http://www.alan-systems.com Jason Holmes http://blog.thejholmes.com Karsten Sperling https://github.com/ksperling http://www.pluk.com Tom Bollwitt https://github.com/tlbollwitt Andi Everitt https://github.com/andi12 http://www.raje.org.uk Manfred Moser http://www.simpligility.com Documentation, issue tracker and more can be found on the plugin website at http://code.google.com/p/maven-android-plugin/ For a primer to use the plugin check out the Android Development chapter in Maven: The Complete Reference http://www.sonatype.com/books/mvnref-book/reference/android-dev.html Please join the Maven Android Mailing List for relevant discussions: https://groups.google.com/forum/?fromgroups#!forum/maven-android-developers Enjoy Manfred Moser http://www.simpligility.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Site plugin running, apparently, for ever
On Wed, Oct 24, 2012 at 10:59 AM, Benson Margulies wrote: > OK, that explains the forks, but not iterating infinitely in a loop > forking the top of the build (and all the interior pieces). Can't really help there. Can only suggest running with -X and writing output to a file. Manually go through this and cull everything that is not telling you which plugin is running and why. You will be left with the call tree of the plugins. I'm assuming at this point it will be obvious what plugin is not behaving the way you expect it to. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Site plugin running, apparently, for ever
On Tue, Oct 23, 2012 at 7:45 PM, Barrie Treloar wrote: > On Wed, Oct 24, 2012 at 9:28 AM, Benson Margulies > wrote: >> Barrie, >> >> We have an execution of the gmaven-plugin to set a property -- a >> property that we don't even need in the site build. >> >> I see: >> >> [INFO] --- gmaven-plugin:1.4:execute (default) @ tanuki-unpack --- >> >> and then a bunch of the usual, and then ... >> >> [INFO] >> >> [INFO] Forking Juggernaut Release Distribution 0.9.101-SNAPSHOT >> [INFO] >> >> >> The gmaven execution is bound to 'validate', which isn't even supposed >> to be in the site lifecycle as previously noted. >> >> Or, some of the Forking follows just after >> maven-javadoc-plugin:2.8.1:aggregate (aggregate) @ jug-setup-bt-root > > See > > http://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html > > "Invokes the execution of the lifecycle phase generate-sources prior > to executing itself." > > So that's why verify is being run. > > I had this problem with enforcer bound to validate and being run > because of source:jar forking. OK, that explains the forks, but not iterating infinitely in a loop forking the top of the build (and all the interior pieces). > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Site plugin running, apparently, for ever
On Wed, Oct 24, 2012 at 9:28 AM, Benson Margulies wrote: > Barrie, > > We have an execution of the gmaven-plugin to set a property -- a > property that we don't even need in the site build. > > I see: > > [INFO] --- gmaven-plugin:1.4:execute (default) @ tanuki-unpack --- > > and then a bunch of the usual, and then ... > > [INFO] > > [INFO] Forking Juggernaut Release Distribution 0.9.101-SNAPSHOT > [INFO] > > > The gmaven execution is bound to 'validate', which isn't even supposed > to be in the site lifecycle as previously noted. > > Or, some of the Forking follows just after > maven-javadoc-plugin:2.8.1:aggregate (aggregate) @ jug-setup-bt-root See http://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html "Invokes the execution of the lifecycle phase generate-sources prior to executing itself." So that's why verify is being run. I had this problem with enforcer bound to validate and being run because of source:jar forking. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Site plugin running, apparently, for ever
Barrie, We have an execution of the gmaven-plugin to set a property -- a property that we don't even need in the site build. I see: [INFO] --- gmaven-plugin:1.4:execute (default) @ tanuki-unpack --- and then a bunch of the usual, and then ... [INFO] [INFO] Forking Juggernaut Release Distribution 0.9.101-SNAPSHOT [INFO] The gmaven execution is bound to 'validate', which isn't even supposed to be in the site lifecycle as previously noted. Or, some of the Forking follows just after maven-javadoc-plugin:2.8.1:aggregate (aggregate) @ jug-setup-bt-root >>>. On Tue, Oct 23, 2012 at 6:12 PM, Barrie Treloar wrote: > On Wed, Oct 24, 2012 at 6:42 AM, Benson Margulies > wrote: >> Using either 3.1 or 3.2, a large project of mine has developed the >> tendency to just keep running the site plugin forever when I run mvn >> site-deploy with 3.0.4. >> >> One aspect of this that I find confusing is this: 'validate' is not >> listed as part of the site lifecycle, yet mvn site-deploy is most >> definitely running executions bound to validate. If wanted something >> to run very early in the normal lifecycle and not when building the >> site, any suggestions? >> >> I see a lot of messages about forking, and it seems to be running the >> same stuff over, and over, and over again. > > I had a problem with lots of unnecessary forking. > > Running with -X spews out lots of information, but forcing myself to > sift through it found that I was using maven-source-jar:jar (which > forks) when I switched to :jar-no-fork problem went away. > > You might have something similar. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Site plugin running, apparently, for ever
On Wed, Oct 24, 2012 at 6:42 AM, Benson Margulies wrote: > Using either 3.1 or 3.2, a large project of mine has developed the > tendency to just keep running the site plugin forever when I run mvn > site-deploy with 3.0.4. > > One aspect of this that I find confusing is this: 'validate' is not > listed as part of the site lifecycle, yet mvn site-deploy is most > definitely running executions bound to validate. If wanted something > to run very early in the normal lifecycle and not when building the > site, any suggestions? > > I see a lot of messages about forking, and it seems to be running the > same stuff over, and over, and over again. I had a problem with lots of unnecessary forking. Running with -X spews out lots of information, but forcing myself to sift through it found that I was using maven-source-jar:jar (which forks) when I switched to :jar-no-fork problem went away. You might have something similar. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Site plugin running, apparently, for ever
i would roll back from the maven-site-plugin 3.0 betas to an older more stable version such as 2.2 org.apache.maven.plugins maven-site-plugin 2.2 validate jar do you see the same behavior when binding specifically validate phase to a stable version? forking: perhaps the LifecycleExecutor calculateForkedExecutions(MojoExecution, MavenSession) is inserting too many entries into the queue can you force mojoExecution.getForkedExecutions().isEmpty() to be true in org.apache.maven.plugins.site.DefaultMavenReportExecutor ? Martin __ long-winded disclaimer goes here > Date: Tue, 23 Oct 2012 16:12:56 -0400 > Subject: Site plugin running, apparently, for ever > From: bimargul...@gmail.com > To: users@maven.apache.org > > Using either 3.1 or 3.2, a large project of mine has developed the > tendency to just keep running the site plugin forever when I run mvn > site-deploy with 3.0.4. > > One aspect of this that I find confusing is this: 'validate' is not > listed as part of the site lifecycle, yet mvn site-deploy is most > definitely running executions bound to validate. If wanted something > to run very early in the normal lifecycle and not when building the > site, any suggestions? > > I see a lot of messages about forking, and it seems to be running the > same stuff over, and over, and over again. > > mvn site:site does not suffer from this effect. > > Any suggestions for tracking this down? > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org >
Site plugin running, apparently, for ever
Using either 3.1 or 3.2, a large project of mine has developed the tendency to just keep running the site plugin forever when I run mvn site-deploy with 3.0.4. One aspect of this that I find confusing is this: 'validate' is not listed as part of the site lifecycle, yet mvn site-deploy is most definitely running executions bound to validate. If wanted something to run very early in the normal lifecycle and not when building the site, any suggestions? I see a lot of messages about forking, and it seems to be running the same stuff over, and over, and over again. mvn site:site does not suffer from this effect. Any suggestions for tracking this down? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency:analyze seems to report spurious 'unused' jars
Well, for starters this plugin analyzes the binary code and not the source code. This means that reported unused declared dependencies might in fact be used when compiling the source code. Here's a few examples; * static constants - the compiler optimizes this by replacing the constant references with the actual value. Thus, analyzing the binary code there is no dependency any longer. * runtime dependencies - runtime dependencies normally don't have a direct code dependency so the plugin don't see this. The plugin should probably ignore runtime deps and I think I've seen some discussion/jira around adding this in the upcoming release, but I could be wrong. * Annotations with source retention - these annotation references are discarded by the compiler. There a more cases I'm sure. And there could of course also be bugs...:-) I think that what the plugin reports as "used undeclared dependencies" are always correct, but "unused declared dependencies" may be wrong. /Anders On Tue, Oct 23, 2012 at 8:05 PM, Benson Margulies wrote: > I've a situation in which 2.5.1 of m-d-p:analyze is reporting 'unused > declared dependencies' that are not unused, in fact, removing them and > running maven 3.0.4 has the immediate and dramatic effect of making > the compile fail. Is there something I don't understand here about > what those goals are trying to report? Should I try to make a test > case? > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Specify enforcer:enforce rules from command line
Don't think it's possible. The enforcer plugin is meant to be bound to the build lifecycle so it should be configured in the pom. But I guess an enhancement ticket with a patch could change that? :-) /Anders On Tue, Oct 23, 2012 at 5:50 PM, Arnaud bourree wrote: > Hello, > > How could we specify enforcer:enforce rules from command line? > > I want to run command line like following without updating any pom.xml: > mvn enforcer:enforce -Drules=com.acme.UseAcmeParentPom > > The goal of this enforcer:enforce rule is to check that Acme's > developers write pom.xml which inherit from acme's parent pom.xml > And because they may not inherit from acme's parent pom.xml, I cannot > specify enforcer rule in. > > Regards, > > Arnaud. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
dependency:analyze seems to report spurious 'unused' jars
I've a situation in which 2.5.1 of m-d-p:analyze is reporting 'unused declared dependencies' that are not unused, in fact, removing them and running maven 3.0.4 has the immediate and dramatic effect of making the compile fail. Is there something I don't understand here about what those goals are trying to report? Should I try to make a test case? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Specify enforcer:enforce rules from command line
Hello, How could we specify enforcer:enforce rules from command line? I want to run command line like following without updating any pom.xml: mvn enforcer:enforce -Drules=com.acme.UseAcmeParentPom The goal of this enforcer:enforce rule is to check that Acme's developers write pom.xml which inherit from acme's parent pom.xml And because they may not inherit from acme's parent pom.xml, I cannot specify enforcer rule in. Regards, Arnaud. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
dependency:unpack doesn't work correctly with Nexus, SNAPSHOT and classifier?
Hi
First of all I'd like to ask you to be gentle with me :-)
The solution I'm talking about is one big hack and will have to be migrated one
day.
But for the time being, here's the issue:
We have a WAR from an old Ant build which is built in a stage-dependent way
(one WAR for local use, one for development, one for production etc.).
The old build was coaxed into deploying the WAR into our Nexus with a
classifier representing the stage, e.g.
ch.ige:wdlbrowserzk:local:3.3.0-SNAPSHOT:war
This works well, and I can see the different WARs with their build date.
To deploy the WAR, I rebuild it with a Maven build. First, I use
dependency:unpack to get the WAR and unpack it. Later on, since the Maven
project is a war project, the WAR is rebuilt and deployed.
Now, my problem is that dependency:unpack always unpacks from the local repo.
It downloads the metadata from Nexus and then assumes that the local WAR is the
same as on Nexus - which it isn't!
The classifier is given to the plugin's configuration by using a profile. The
only bug I can imagine is that the plugin downloads the metadata, sees no
difference between the local repo and Nexus (since it seems to ignore the
classifier) and then proceeds with the local repo.
Does the plugin use a different dependency resolution? Or is my approach wrong?
(I mean, apart from the obviously hacky way of doing it)
Here's the configuration:
org.apache.maven.plugins
maven-dependency-plugin
unpack-wdl-war
prepare-package
unpack
ch.ige
wdlbrowserzk
${wdlbrowserzk.version}
war
${profile.id}
true
${webapp.directory}
true
true
And here's the console output:
[INFO] --- maven-dependency-plugin:2.5.1:unpack (unpack-wdl-war) @
etrademark-nt-wdl-web ---
[INFO] Configured Artifact: ch.ige:wdlbrowserzk:local:3.3.0-SNAPSHOT:war
Downloading:
http://myrepo.com/content/groups/public/ch/ige/wdlbrowserzk/3.3.0-SNAPSHOT/maven-metadata.xml
Downloaded:
http://myrepo.com/content/groups/public/ch/ige/wdlbrowserzk/3.3.0-SNAPSHOT/maven-metadata.xml
(264 B at 7.2 KB/sec)
[INFO] Unpacking
C:\jp\maven-repository\ch\ige\wdlbrowserzk\3.3.0-SNAPSHOT\wdlbrowserzk-3.3.0-SNAPSHOT-local.war
to C:\jp\esv-projects\etrademark-nt\etrademark-nt-wdl-web\target\wdl with
includes "" and excludes ""
Any hint is appreciated!
Best regards,
Eric
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
AW: Independent module release strategies
Well after quite a lot of digging in the code of the release plugin, I think
that I will use a different strategy:
- in the release.properties or using the commandline, I am able to set
individual versions of my modules and the release plugin will use them
http://maven.apache.org/plugins/maven-release-plugin/examples/non-interactive-release.html
which is basically what I wanted in the first place.
- In order to release only individual projects, using the advanced reactor
otions of maven seems ideal:
http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-advanced-reactor-options/
So in order to have exactly what I wanted, all I need to do, is create a
release.properties file to tell the plugin the versions and then limit the
maven reactor to only the modules I want to release and use the normal
"release:prepare" and "release:perform" targets.
As creating the properties and commandline arguments I a little uncomfortable,
I'm currently wokring on a jenking plugin for my client to select which modules
to release and to provide versions for them ... hopefully this way releasing a
new version is just a number of clicks and providing version numbers.
What do you think about this solution? Any Kittens in danger this time? ;-)
Chris
Von: Stephen Connolly [stephen.alan.conno...@gmail.com]
Gesendet: Dienstag, 16. Oktober 2012 11:06
An: Maven Users List
Cc: rwhee...@artifact-software.com
Betreff: Re: Independent module release strategies
On 16 October 2012 07:45, christofer.d...@c-ware.de <
christofer.d...@c-ware.de> wrote:
> As described in my other response. Simply keeping the versions in sync is
> not an option for us due to the donwtime this would mean for our clients
> and the load this would generate on the central servers.
>
> Well currently the approach to release a new version was to have all
> modules defined in the master pom modules-section as well as a
> dependencyManagement-section that defines the versions of all the modules.
>
> Now if a new build was to be made that updates only some of the modules,
> the other modules (the ones that should stay the same) were commented out
> of the master poms modules-section and then the releaseplugin was used to
> release the desired artifacts. After the release was finished the versions
> hat do be manually updated.
>
> This process really sucked and caused a lot of problems.
>
> Now my approach was not to use the release plugin at all and to define all
> of the versions used throughout the entire project in the master pom using
> properties. So all I had to do was to increase the versions in the release
> profile to the versions I want and commit that. Now in jenkins I was able
> to define some jobs to run "mvn deploy" for individual projects with turned
> on "release" profile.
>
>
well first off, in my experience, the use of profiles to modify the
dependencies is bad karma. many kittens will die if you follow that use of
profiles. no matter how "clean" you think it is, with the current versions
of Maven and their current behaviour, attempts to follow this path will
result in many dead kittens underfoot.
> To me this seems a lot cleaner than all other approaches, but as I don't
> want to kill too many kittens (As stephen on the dev-list called it). So
> I'm open for other suggestions or explanationy WHY this is bad.
>
> Stephen claimed that if I re-define my properties in child modules, I
> would have really big trouble, but we are developing the entire project and
> this is a thing we could fefinitely rule out because it should be really
> easy to enforce such a constraint ("Versions are defines solely in the
> master pom"). And as I mentioned, to me it looks more like a highly
> restricted feature than a bug in maven that I was able to use a variable in
> the version.
>
>
Not quite, I fear it is loosing something in translation for you.
In an ideal world, before deploying the pom into the local cache (i.e.
install:install) or remote repository (i.e. deploy:deploy) Maven would
compute a resolved effective pom. Such a pom would strip out a lot of the
stuff that is in a pom at present, e.g. it would probably only consist of
/project/groupId
/project/artifactId
/project/version
/project/packaging
/project/dependencies/*
and maybe
/project/build/extensions/*
(but it gets tricky deciding exactly how much to prune out)
Such a pom would be capturing the dependency tree of the built artifact
after inheritance from the parent, and any active profiles, etc had been
applied. [Let's ignore the problem of “magic” profiles that alter the
dependencies when building on JDK1.5 vs JDK1.6 vs JDK1.7 vs JDK1.8]
*IF* we did something like that *THEN* it could be valid to try what you
want to do (Note: I say ‘could be’ not ‘would be’)
This is because anyone depending on the artifact would have a consistent
classpath.
Now for pom projects we would have to deploy the raw
pom to the repository so that inheritance w
