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
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
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
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
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
arnaud.bour...@gmail.com wrote:
Hello,
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
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
i would roll back from the maven-site-plugin 3.0 betas to an older more stable
version such as 2.2
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version2.2/version
executions
execution
id/
On Wed, Oct 24, 2012 at 6:42 AM, Benson Margulies bimargul...@gmail.com 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:
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
On Wed, Oct 24, 2012 at 9:28 AM, Benson Margulies bimargul...@gmail.com 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
On Tue, Oct 23, 2012 at 7:45 PM, Barrie Treloar baerr...@gmail.com wrote:
On Wed, Oct 24, 2012 at 9:28 AM, Benson Margulies bimargul...@gmail.com
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:
On Wed, Oct 24, 2012 at 10:59 AM, Benson Margulies
bimargul...@gmail.com 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
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
14 matches
Mail list logo
