Where the binnary of mvn knows which mojo do i want to execute?

I am novice using mvn and having a look to /usr/bin/mvn, I can see the eval method, but I can not understand where the mojo is called. Please can anyone explain how the eval method works? I would be very pleased if someone could help me. That is my eval

Re: Where the binnary of mvn knows which mojo do i want to execute?

What are you trying to do actually? Plugin development? Understanding Maven to patch it? Just want to use it and stuck somewhere? 2014-02-24 13:25 GMT+01:00 enrique bernal ruiz kbernalr...@gmail.com: I am novice using mvn and having a look to /usr/bin/mvn, I can see the eval method, but I can

[ANN] Maven 3.2.1 Release

Hi! The Apache Maven Team is pleased to announce the release of 3.2.1 The release notes can be found here: http://maven.apache.org/docs/3.2.1/release-notes.html The release can be downloaded from: http://maven.apache.org/download.cgi Full list of changes can be viewed in JIRA:

Re: Where the binnary of mvn knows which mojo do i want to execute?

Hello! And thank you so much for your help. I am working(starting) with it, and i am trying to understand it. What mvn does when i call mvn run for example, i mean, I have a collection of mvn plugins and what i want to know is, where mvn knows that i am calling a mvn plugin in: mvn run for

Re: Where the binnary of mvn knows which mojo do i want to execute?

Hi, Eval method will not help understanding maven much, it is just a script that pass some arguments to a main java. You should find more information on what get executed here : https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html You should also take a look at some

about https://jira.codehaus.org/browse/MNG-5576 (Allow continuous delivery friendly versions)

Now that Maven 3.2.1 is out. May I ask how this may be used? Thanks -D

Rule for maven plugin inheritance

Hi there, Met an interesting question recently about plugin inheritance and hope you could give me some feedback :) At first, I define two maven java doc plugin inside the reporting tag and used to generate different type of javadoc, one for standard javadoc and for customize one. Later, I

Re: about https://jira.codehaus.org/browse/MNG-5576 (Allow continuous delivery friendly versions)

Hi Dan, now you can write on your GAV definition a thing like: groupId.../groupId artifactId.../artifactId version1.0-${revision}-SNAPSHOT/version and via command line you can now do the following: mvn -Drevision=3456 clean test If you done that via Maven 3.1.1 you get a warning with Maven

Re: about https://jira.codehaus.org/browse/MNG-5576 (Allow continuous delivery friendly versions)

Thanks, that helps -D On Mon, Feb 24, 2014 at 12:23 PM, Karl Heinz Marbaise khmarba...@gmx.dewrote: Hi Dan, now you can write on your GAV definition a thing like: groupId.../groupId artifactId.../artifactId version1.0-${revision}-SNAPSHOT/version and via command line you can now do

Re: Where the binnary of mvn knows which mojo do i want to execute?

On 25 February 2014 00:46, enrique bernal ruiz kbernalr...@gmail.com wrote: Hello! And thank you so much for your help. I am working(starting) with it, and i am trying to understand it. What mvn does when i call mvn run for example, i mean, I have a collection of mvn Please have a look at the

Re: about https://jira.codehaus.org/browse/MNG-5576 (Allow continuous delivery friendly versions)

Hello, I just tried this with a small multimodule pet project, see the mvn321 branch (https://github.com/1and1/testlink-junit/compare/master...mvn321). Now giving revision as a property (mvn321 -Drevision=NULL clean verify) does *not* work, enforcer complains about being not able to resolve the

Re: about https://jira.codehaus.org/browse/MNG-5576 (Allow continuous delivery friendly versions)

Hello, I now tried running `env revision=123456 mvn321 release:prepare`, but this does not work as release:prepare does not seem to use the information from the environment, I get: --- snip --- There are still some remaining snapshot dependencies. : Do you want to resolve them now? (yes/no) no: :

Re: about https://jira.codehaus.org/browse/MNG-5576 (Allow continuous delivery friendly versions)

Hello, I now removed -SNAPSHOT from the version strings, what I get now when running: env revision=123456 mvn321 clean install is: Installing /Users/mirko/workspace/foss/testlink-junit/pom.xml to

Re: about https://jira.codehaus.org/browse/MNG-5576 (Allow continuous delivery friendly versions)

Hi Mirko, I just tried this with a small multimodule pet project, see the mvn321 branch (https://github.com/1and1/testlink-junit/compare/master...mvn321). Just forked it give it a try.. Now giving revision as a property (mvn321 -Drevision=NULL clean verify) does *not* work, enforcer

Re: Rule for maven plugin inheritance

At first, I define two maven java doc plugin inside the reporting tag and used to generate different type of javadoc, one for standard javadoc and for customize one. FYI: I don't use much of the reporting functionality in Maven, just the basics. Later, I want to move those two javadoc plug

RE: Rule for maven plugin inheritance

Hi Wayne, Thanks, will try today. Br, Tim -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: den 24 februari 2014 23:11 To: Maven Users List Subject: Re: Rule for maven plugin inheritance At first, I define two maven java doc plugin inside the reporting tag and