[jira] (MNG-1958) we need a var that always points to the root directory in multi module builds
[
https://jira.codehaus.org/browse/MNG-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347131#comment-347131
]
Mirko Friedenhagen commented on MNG-1958:
-
I use {{user.dir}} for this as well. And what about
{{session.executionRootDirectory}}? At least in Mojos the latter is usable.
> we need a var that always points to the root directory in multi module builds
> -
>
> Key: MNG-1958
> URL: https://jira.codehaus.org/browse/MNG-1958
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Reactor and workspace
>Reporter: Mark Proctor
>Assignee: Jason van Zyl
> Fix For: 3.2.2
>
>
> $\{basedir} always points to the local module. There are cases, when having a
> local relative repository, when it would be usefull to have a var that always
> pointed to the root project, $\{rootdir}.
> In such a case you may want to think of having the names $\{rootdir}
> $\{moduledir}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEPLOY-176) With DeployAtEnd activated and a project using customized lifecycle plugin, deploy is skipped
[ https://jira.codehaus.org/browse/MDEPLOY-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347159#comment-347159 ] Jörg von Frantzius commented on MDEPLOY-176: Hi Olivier, the title of this issue mentions "project using customized lifecycle plugin", could you explain what you mean by this? I looked at the sample and couldn't find anything like that. If this is outdated then maybe you can remove this from your issue title? By the way, I can reproduce the problem with your sample and maven-deploy-plugin 2.8.1 and a simple "mvn deploy", and I have a similar problem with my own project. > With DeployAtEnd activated and a project using customized lifecycle plugin, > deploy is skipped > -- > > Key: MDEPLOY-176 > URL: https://jira.codehaus.org/browse/MDEPLOY-176 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy >Affects Versions: 2.8.1, 2.9 > Environment: Maven 3.0.5 >Reporter: olivier o > Attachments: deploy-end-fail.zip > > > Hi, > When deployAtEnd is enabled, the deployment of all modules is skipped. It > seems that the "readyProjectsCounter" is not accurate for one module. So the > last module is not detected. > I've attached a simple sample project with 4 modules : > - pom : set version and plugin management > - jar and ear : empty project (only to illustrate counter reset) > - war : module with readyProjectsCounter > I've looked at 2.9-SNAP version code , and displayed some info from attached > sample : > pom : readyProjectsCounter: 1 - reactorProjects: 4 > jar: readyProjectsCounter: 2 - reactorProjects: 4 > war: *readyProjectsCounter: 1* - reactorProjects: 4 > ear: readyProjectsCounter: 3 - reactorProjects: 4 > Regards, > Olivier -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEPLOY-176) With DeployAtEnd activated and a project using customized lifecycle plugin, deploy is skipped
[ https://jira.codehaus.org/browse/MDEPLOY-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347163#comment-347163 ] olivier o commented on MDEPLOY-176: --- Hi Jôrg, Here some details, in fact in the war module deploy-end-fail-war, I use this plugin com.devspan.mojo.javascript javascript-maven-plugin 0.9.3 It seems this plugin customize the maven lifecycle, and I think if you comment the plugin, it's working. Is it cleared ? > With DeployAtEnd activated and a project using customized lifecycle plugin, > deploy is skipped > -- > > Key: MDEPLOY-176 > URL: https://jira.codehaus.org/browse/MDEPLOY-176 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy >Affects Versions: 2.8.1, 2.9 > Environment: Maven 3.0.5 >Reporter: olivier o > Attachments: deploy-end-fail.zip > > > Hi, > When deployAtEnd is enabled, the deployment of all modules is skipped. It > seems that the "readyProjectsCounter" is not accurate for one module. So the > last module is not detected. > I've attached a simple sample project with 4 modules : > - pom : set version and plugin management > - jar and ear : empty project (only to illustrate counter reset) > - war : module with readyProjectsCounter > I've looked at 2.9-SNAP version code , and displayed some info from attached > sample : > pom : readyProjectsCounter: 1 - reactorProjects: 4 > jar: readyProjectsCounter: 2 - reactorProjects: 4 > war: *readyProjectsCounter: 1* - reactorProjects: 4 > ear: readyProjectsCounter: 3 - reactorProjects: 4 > Regards, > Olivier -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-879) Custom toolchain configuration is not passed to forked Maven executions
[
https://jira.codehaus.org/browse/MRELEASE-879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347164#comment-347164
]
Sergei Ivanov commented on MRELEASE-879:
Unfortunately, Plan B did not work either: {{InvokerMavenExecutor}} does not
recognise {{\-t}} ({{\-\-toolchains}}) option, so an attempt to pass that
option as part of the {{arguments}} parameter of {{maven-release-plugin}} fails
with the following exception:
{noformat}
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to re-parse
additional arguments for Maven invocation.
at
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:281)
at
org.apache.maven.plugins.release.PrepareWithPomReleaseMojo.execute(PrepareWithPomReleaseMojo.java:47)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 31 more
Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Failed to
re-parse additional arguments for Maven invocation.
at
org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:89)
at
org.apache.maven.shared.release.phase.RunPrepareGoalsPhase.execute(RunPrepareGoalsPhase.java:44)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:234)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:169)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:146)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:107)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:277)
... 34 more
Caused by: org.apache.maven.shared.release.exec.MavenExecutorException: Failed
to re-parse additional arguments for Maven invocation.
at
org.apache.maven.shared.release.exec.InvokerMavenExecutor.setupRequest(InvokerMavenExecutor.java:320)
at
org.apache.maven.shared.release.exec.InvokerMavenExecutor.executeGoals(InvokerMavenExecutor.java:379)
at
org.apache.maven.shared.release.exec.AbstractMavenExecutor.executeGoals(AbstractMavenExecutor.java:110)
at
org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:81)
... 40 more
Caused by: org.apache.commons.cli.UnrecognizedOptionException: Unrecognized
option: --toolchains
at org.apache.commons.cli.Parser.processOption(Parser.java:363)
at org.apache.commons.cli.Parser.parse(Parser.java:199)
at org.apache.commons.cli.Parser.parse(Parser.java:85)
at
org.apache.maven.shared.release.exec.InvokerMavenExecutor.setupRequest(InvokerMavenExecutor.java:186)
... 43 more
{noformat}
I assume that patching {{InvokerMavenExecutor}} will be a pre-requisite for
propagating the custom toolchain location automatically. Let me see if I can
knock up a patch for both.
> Custom toolchain configuration is not passed to forked Maven executions
> ---
>
> Key: MRELEASE-879
> URL: https://jira.codehaus.org/browse/MRELEASE-879
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare-with-pom
>Affects Versions: 2.5
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+)
> Maven home: /opt/app/xxx/uat1/tools/apache-maven-3.0.4
> Java version: 1.7.0_07, vendor: Oracle Corporation
> Java home: /opt/app/xxx/uat/uat1/tools/jdk/32/jdk1.7.0_07/jre
> Default locale: en_US, platform encoding: ANSI_X3.4-1968
> OS name: "linux", version: "2.6.18-194.32.1.el5", arch: "i386", family: "unix"
>Reporter: Sergei Ivanov
>
> We do use maven toolchains extensively, and recently we had to make a change
> to pass a custom node-specific toolchain file to our release jobs. We can no
> longer have a common toolchain file in {{~/.m2/}} directory, so we started
> using {{--toolchain}} command line option instead.
> Unfortunately, this did not work well at all with the Maven release process.
> It seems that the forked Maven executions (as spawned by {{release:prepare}}
> and {{release:perform}} goals) do not inherit the custom toolchain
> configuration from the release plugin execution.
> Quickly skimming through the release plugin sources, I could not see any
> mention of toolchains either.
> As far as I can tell, one would need to extend the {{ReleaseEnvironment}} to
> pass toolchains file location to the forked Maven process. It should be
> possible to extract the location of the toolchains file by calling
> {{org.apache.maven.execution.Mav
[jira] (MDEPLOY-176) With DeployAtEnd activated and a project using customized lifecycle plugin, deploy is skipped
[ https://jira.codehaus.org/browse/MDEPLOY-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347163#comment-347163 ] olivier o edited comment on MDEPLOY-176 at 5/27/14 9:02 AM: Hi Jôrg, Here some details, in fact in the war module deploy-end-fail-war, I use this plugin com.devspan.mojo.javascript javascript-maven-plugin 0.9.3 It seems this plugin customize the maven lifecycle, and I think if you comment the plugin, it's working. Is it clearer ? was (Author: olivier o.): Hi Jôrg, Here some details, in fact in the war module deploy-end-fail-war, I use this plugin com.devspan.mojo.javascript javascript-maven-plugin 0.9.3 It seems this plugin customize the maven lifecycle, and I think if you comment the plugin, it's working. Is it cleared ? > With DeployAtEnd activated and a project using customized lifecycle plugin, > deploy is skipped > -- > > Key: MDEPLOY-176 > URL: https://jira.codehaus.org/browse/MDEPLOY-176 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy >Affects Versions: 2.8.1, 2.9 > Environment: Maven 3.0.5 >Reporter: olivier o > Attachments: deploy-end-fail.zip > > > Hi, > When deployAtEnd is enabled, the deployment of all modules is skipped. It > seems that the "readyProjectsCounter" is not accurate for one module. So the > last module is not detected. > I've attached a simple sample project with 4 modules : > - pom : set version and plugin management > - jar and ear : empty project (only to illustrate counter reset) > - war : module with readyProjectsCounter > I've looked at 2.9-SNAP version code , and displayed some info from attached > sample : > pom : readyProjectsCounter: 1 - reactorProjects: 4 > jar: readyProjectsCounter: 2 - reactorProjects: 4 > war: *readyProjectsCounter: 1* - reactorProjects: 4 > ear: readyProjectsCounter: 3 - reactorProjects: 4 > Regards, > Olivier -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}
Mark Ingram created MNG-5639:
Summary: Support resolution of Import Scope POMs from Repo that
contains a ${parameter}
Key: MNG-5639
URL: https://jira.codehaus.org/browse/MNG-5639
Project: Maven 2 & 3
Issue Type: Improvement
Components: Dependencies
Affects Versions: 3.2.1
Reporter: Mark Ingram
Priority: Minor
Attachments: pom.xml
Running mvn help-effective-pom on the attached POM:
[ERROR] The project com.ming:maven-failing-import-pom-example:1.0.0-SNAPSHOT
(C:\wip\scratch-dev\maven-import-dependency-management\pom.xml) has 1 error
[ERROR] Non-resolvable import POM: Could not transfer artifact
org.springframework:spring-framework-bom:pom:4.0.0.R2 from/to spring-milestones
(${spring.url}): No connector available to access repository spring-milestones
(${spring.url}) of type default using the available factories
WagonRepositoryConnectorFactory @ line 20, column 25 -> Help 2]
mvn help-effective-pom -Prepo-will-succeed works as expected.
Note that prior to attempting the failing resolution the full project POM model
has successfully been resolved. So the correct value for the property is known
and could in theory be substituted into the repository URL before the failing
import pom resolve attempt.
Will create a Github pull request with one possible solution to this - it
includes a JUnit test case.
Note: agreed this is a contrived example. To try and give an idea of the actual
use case - several development streams are setup with individual sandboxed
Nexus repository holding specific version of several shared components. The
repository configuration uses the pattern
${nexus.baseurl}/content/groups/${stream.name} with the properties set in
settings.xml file.
One workaround would be to create profiles for every work stream that
explicitly list the full repository URL, even then the above feature would be
nice to allow the ${nexus.baseurl} to avoid repeating that part.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}
[
https://jira.codehaus.org/browse/MNG-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347221#comment-347221
]
Jason van Zyl commented on MNG-5639:
Thanks, I will take a look as soon as I can. It will go faster if an
integration test is made that runs along side our normal integration tests:
https://github.com/apache/maven-integration-testing
I will take a look and make the requisite integration test later this week if
you don't have time. Thanks again for the patch. At first blush seems like a
useful addition.
> Support resolution of Import Scope POMs from Repo that contains a ${parameter}
> --
>
> Key: MNG-5639
> URL: https://jira.codehaus.org/browse/MNG-5639
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.2.1
>Reporter: Mark Ingram
>Priority: Minor
> Attachments: pom.xml
>
>
> Running mvn help-effective-pom on the attached POM:
> [ERROR] The project
> com.ming:maven-failing-import-pom-example:1.0.0-SNAPSHOT
> (C:\wip\scratch-dev\maven-import-dependency-management\pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not transfer artifact
> org.springframework:spring-framework-bom:pom:4.0.0.R2 from/to
> spring-milestones (${spring.url}): No connector available to access
> repository spring-milestones (${spring.url}) of type default using the
> available factories WagonRepositoryConnectorFactory @ line 20, column 25 ->
> Help 2]
> mvn help-effective-pom -Prepo-will-succeed works as expected.
> Note that prior to attempting the failing resolution the full project POM
> model has successfully been resolved. So the correct value for the property
> is known and could in theory be substituted into the repository URL before
> the failing import pom resolve attempt.
> Will create a Github pull request with one possible solution to this - it
> includes a JUnit test case.
> Note: agreed this is a contrived example. To try and give an idea of the
> actual use case - several development streams are setup with individual
> sandboxed Nexus repository holding specific version of several shared
> components. The repository configuration uses the pattern
> ${nexus.baseurl}/content/groups/${stream.name} with the properties set in
> settings.xml file.
> One workaround would be to create profiles for every work stream that
> explicitly list the full repository URL, even then the above feature would be
> nice to allow the ${nexus.baseurl} to avoid repeating that part.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output
[ https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MCOMPILER-224. Resolution: Fixed Fix Version/s: 3.2 Assignee: John Casey Added IT and verified fix. > Maven compiler plugin does not properly consume plexus compiler output > -- > > Key: MCOMPILER-224 > URL: https://jira.codehaus.org/browse/MCOMPILER-224 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0, 3.1 >Reporter: David M. Lloyd >Assignee: John Casey > Fix For: 3.2 > > Attachments: MCOMPILER-224.patch, MCOMPILER-224.zip > > > Maven compiler plugin does not properly read the output from the plexus > compiler. All CompilerMessages are logged at warning or error level, even if > they are not warnings or errors. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-66) Compiler swallows messages from annotation processors
[ https://jira.codehaus.org/browse/MCOMPILER-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347228#comment-347228 ] David M. Lloyd commented on MCOMPILER-66: - This issue should be closed because MCOMPILER-224 supersedes it and that issue has been fixed. > Compiler swallows messages from annotation processors > - > > Key: MCOMPILER-66 > URL: https://jira.codehaus.org/browse/MCOMPILER-66 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 2.0.2, 2.1 >Reporter: Evan Cowden > Attachments: AnnotationProcessorMessagerBug.zip > > > When using the annotation processor API to print messages through the > javax.annotation.processing.Messager object, only messagesspecified by levels > javax.tools.Diagnostic.Kind.ERROR and > javax.tools.Diagnostic.Kind.MANDATORY_WARNING are displayed (and cause the > build to fail). All other messages are swallowed. > Note that while the attached JUnit test case is necessary to help expose the > problem, passing it will not imply that the bug is fixed. The only way to > confirm the fix (that I know of) is to examine console output. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
