Re: Why does Maven fail to compile my project occasionally?
Wayne Fay wrote I rarely use any parameters as you have done here. Can you try a simple mvn clean install and see how that goes? Also -U and -X may be useful shortcuts for you to know about. And I agree with Stephen and Ron - Eclipse sometimes does helpful things which produce hard to explain results. I would suggest either using Eclipse or Maven CLI but not both simultaneously on the same project (close Eclipse just use Maven CLI, or just use Eclipse). Wayne Well, Eclipse is not installed on my daily-build server, so I guess it has nothing to do with Eclipse. ;-) I guess when Maven encounters the missing-dependency compilation error, it doesn't stop compiling immediately, and it tries its best to compile other unrelated modules. When I compile the whole project again, the missing dependent modules may appear in the local repository because the unrelated modules compiled previously have declared them as dependencies. Anyway, the long-lasting problem has been solved perfectly. Thank you guys! -- View this message in context: http://maven.40175.n5.nabble.com/Why-does-Maven-fail-to-compile-my-project-occasionally-tp5784849p5786423.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Why does Maven fail to compile my project occasionally?
Well, Eclipse is not installed on my daily-build server, so I guess it has nothing to do with Eclipse. ;-) I guess when Maven encounters the missing-dependency compilation error, it doesn't stop compiling immediately, and it tries its best to compile other unrelated modules. When I compile the whole project again, the missing dependent modules may appear in the local repository because the unrelated modules compiled previously have declared them as dependencies. Anyway, the long-lasting problem has been solved perfectly. Thank you guys! What you have is a http://en.wikipedia.org/wiki/Heisenbug And you need to understand what the root cause of the problem is. Otherwise you will suffer this problem again in the future. Plus, once you understand the problem you should post back to the list and explain it. So that other people can google their similar problems and find the answer. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Google Summer of Code - Java opportunity, mentors needed
Hi, I recently published an idea for discovering the source code of Java projects (e.g. by exploring meta data from pom.xml) and trying to automatically and recursively build dependencies (including plugins) from source https://wiki.debian.org/SummerOfCode2014/Projects#SummerOfCode2014.2FProjects.2FRecursively_building_Java_dependencies_from_source.Recursively_building_Java_dependencies_from_source This would satisfy various objectives, for example: - automated construction of Debian/Ubuntu/RPM packages - ensuring that non-free components don't creep into the dependency tree of projects that aim to be published under a free license - ensuring that 100% of dependency code can be passed through code quality/security scanning tools (this is a common requirement for larger corporations when evaluating whether to use a free software project) I have some plans for how this project could be broken down into achievable tasks for a GSoC student but to go ahead it would need at least one additional mentor, mainly because Google has accepted the Ganglia organisation this year and I am one of the admins for Ganglia. The project has been proposed under Debian (mainly as a way of enabling the creation of more Debian packages) but it could also be completed under another organisation. Please feel free to email me privately if you may be interested. Regards, Daniel - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Where the binnary of mvn knows which mojo do i want to execute?
Ok! thank you very much for the help to all of you! 2014-02-24 21:38 GMT+01:00 Barrie Treloar baerr...@gmail.com: 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 freely available books at http://maven.apache.org/articles.html Some of these may be in a language more native to you than English. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: about https://jira.codehaus.org/browse/MNG-5576 (Allow continuous delivery friendly versions)
Hello Karl-Heinz,
thanks for you suggestions, I replaced classifier tests with type
test-jar. As you stated release:prepare does not work because I do not
have a SNAPSHOT-version. My other concern is still true, running:
env revision=NULL mvn321 clean install
still has the non-resolved property ${revision} in the installed pom
in my localRepository.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/
On Mon, Feb 24, 2014 at 11:05 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote:
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 complains about being not able to
resolve the reactor artifacts. You have to put revision into the
environment, so
env revision=NULL mvn321 clean verify does the trick.
that looks strange...cause if i do that i get the following:
[INFO]
[INFO] --- maven-enforcer-plugin:1.3.1:enforce (default-enforce) @
tljunit-surefire ---
Downloading:
http://localhost:8081/nexus/content/groups/public/net/oneandone/testlinkjunit/tljunit-parent/3.0.3-${revision}/tljunit-parent-3.0.3-${revision}.pom
[WARNING] Rule 3: org.apache.maven.plugins.enforcer.RequireNoRepositories
failed with message:
Could not transfer artifact
net.oneandone.testlinkjunit:tljunit-parent:pom:3.0.3-${revision} from/to
nexus (http://localhost:8081/nexus/content/groups/public): Illegal character
in path at index 100:
http://localhost:8081/nexus/content/groups/public/net/oneandone/testlinkjunit/tljunit-parent/3.0.3-${revision}/tljunit-parent-3.0.3-${revision}.pom
net.oneandone.testlinkjunit:tljunit-parent:pom:3.0.3-${revision}
from the specified remote repositories:
nexus (http://localhost:8081/nexus/content/groups/public, releases=true,
snapshots=true)
That looks like a issue with maven-enforcer ...i will start writing an
integration tests for that
Furthermore i have taken a look into the project and found something
strange:
in the dependencyManagement of the parent:
dependency
groupIdnet.oneandone.testlinkjunit/groupId
artifactIdtljunit-surefire/artifactId
version${project.version}/version
classifiertests/classifier
/dependency
Should this reference the test-jar which is produced in the sub-module by
using maven-jar-plugin:test-jar goal ?
Yes...than the dependency entry is wrong. It must be done like the
following:
dependency
groupIdnet.oneandone.testlinkjunit/groupId
artifactIdtljunit-surefire/artifactId
version${project.version}/version
typetest-jar/type
scopetest/scope
/dependency
And this dependeny is used in the module:
artifactIdtljunit-eclipse/artifactId
which produces your error about the not resolvable artifact in the
reactor
If you are using the maven-release-plugin you need to give the parameters in
a different way cause maven-release-plugin calls maven a second time which
will result in the following:
mvn -Drevision=NULL -Darguments=-Drevision=NULL release:prepare
This looks a bit strange but it works except that i get a message about not
existing SNAPSHOT version...but no failure.
If you enhance your configuration of the maven-release-plugin with the
following line:
arguments-Drevision=${revision}/arguments
You can reduce the above call to:
mvn -Drevision=NULL release:prepare
Kind regards
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen http://www.soebes.de
-
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
[ANN] Apache Maven GPG Plugin 1.5 Released
The Apache Maven team is pleased to announce the release of the Apache Maven GPG Plugin, version 1.5 This plugin signs all of the project's attached artifacts with GnuPG. http://maven.apache.org/plugins/maven-gpg-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-gpg-plugin/artifactId version1.5/version /plugin Release Notes - Maven GPG Plugin - Version 1.5 ** Bug * [MGPG-41] - Passphrase revealed when backspacing at prompt ** Improvement * [MGPG-48] - useAgent=true by default * [MGPG-49] - Add support for --lock-* command line options ** Task * [MGPG-39] - use maven-plugin-tools' java 5 annotations Enjoy, -The Apache Maven team
How to separately configure each Mojo of a plugin executed from command line?
Hi, with regards to the info given at: https://maven.apache.org/guides/mini/guide-default-execution-ids.html How can I configure separately each Mojo of a plugin, if these mojos are executed from command line? e.g. mvn release:clean //SomeProperty == X mvn release:prepare //SomeProperty == A mvn release:perform //SomeProperty == B both goals are executed from command line. how can I configure release:prepare in my pom differently from release:perform? Basically I would need execution Ids like default-prepare-cli, default-perform-cli etc. Grateful for ideas, thanks, Juergen ad: pom.xml plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-release-plugin/artifactId version2.4.2/version configuration SomePropertyX/SomeProperty!-- shared globally-- /configuration executions execution iddefault-cli/id configuration SomePropertyA/SomeProperty !--DOES NOT WORK shared by release:perform, release:prepare, release:clean both if executed from command line-- /configuration /execution iddefault-prepare/id configuration SomePropertyA/SomeProperty !--DOES NOT WORK not used if executed from command line-- /configuration /execution execution iddefault-perform/id configuration SomePropertyB/SomeProperty !--DOES NOT WORK release:perform not bound to lifecycle, but it invokes deploy. Also not used if executed from command line-- /configuration /execution execution execution iddefault/id phasedeploy/phase goals goalprepare/goal /goals configuration SomePropertyA/SomeProperty !--DOES NOT WORK not used if executed from command line-- /configuration /execution /executions /plugin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
