[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file
[
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14747169#comment-14747169
]
Daniel Spilker commented on MNG-5889:
-
Hi Arnaud,
indeed I was running into this problem when using the [Jenkins Maven
Plugin|https://wiki.jenkins-ci.org/display/JENKINS/Maven+Project+Plugin].
It should be possible to add a "base directory" setting to that plugin so that
the CI can change to the base directory before launching Maven, but I think it
would be better to fix the problem at the root.
> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build
>Affects Versions: 3.3.3
>Reporter: Daniel Spilker
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of
> the POM selected by {{--file}} and then go through the parent directories.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5522) properties project.parent.xxx not supported under Linux
[
https://issues.apache.org/jira/browse/MNG-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14747007#comment-14747007
]
Karl Heinz Marbaise commented on MNG-5522:
--
Based on the example it shows that you try to use something which is only
possible in a multi module build. The problem here is that the parent (does
not contain modules) and based on that you can't access the parent.basedir,
cause you can't know where the project is located. In this case it is by
coincidence located a level higher...so i don't see here a bug..i see more a
problem in understanding parent/child relationship.
> properties project.parent.xxx not supported under Linux
> ---
>
> Key: MNG-5522
> URL: https://issues.apache.org/jira/browse/MNG-5522
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build, POM
>Affects Versions: 3.0.5
> Environment: Few Linuxes tested, work under Windows
>Reporter: Pavel
> Attachments: maven-MNG-5522.zip
>
>
> Initially it was there:
> https://jira.codehaus.org/browse/MRM-1772#comment-333654 . But It is maven
> problem itself.
> It is reproducible on two our Linux machines (Fedora and Gentoo), so it may
> be Linux relative. On all our colleagues on windows it does not reproduced.
> Some details.
> Parent pom among others have:
> {code}
> 1.5.300-SNAPSHOT
> imus
> ...
>
> 2.5.6
> 3.2.2.RELEASE
> 2.1.1
> 1.7.0
> windows-1251
> none
> 1.7
> 1.7
> ${basedir}
> QWERTY
>
> {code}
> First child module:
> {code}
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.1
>
>
> validate
>
> run
>
>
>
>
> [project.parent.rootProjectPath]:
> ${project.parent.rootProjectPath}
>
> [project.parent.getRootProjectPath()]:
> ${project.parent.getRootProjectPath()}
>
> [project.parent.rootProjectPath1]:
> ${project.parent.rootProjectPath1}
>
> [project.parent.spring3.version]:
> ${project.parent.spring3.version}
>
> [project.parent.properties.spring3.version]:
> ${project.parent.properties.spring3.version}
>
> [project.parent.properties.rootProjectPath]:
> ${project.parent.properties.rootProjectPath}
>
> [project.parent.properties.rootProjectPath1]:
> ${project.parent.properties.rootProjectPath1}
>
> [project.parent.name]: ${project.parent.name}
>
> [project.parent.properties]: ${project.parent.properties}
>
>
>
>
>
>
>
> {code}
> *In out I see what project.parent.name resolved and even
> project.parent.properties, but not any property in collection (f.e.
> project.parent.rootProjectPath or project.parent.properties.rootProjectPath)
> as it should [by documentation|http://maven.apache.org/pom.html#Properties]*:
> {code}
> [INFO] --- maven-antrun-plugin:1.1:run (default) @ antinform-lib-parent ---
> [INFO] Executing tasks
> [echo] [project.parent.rootProjectPath]:
> ${project.parent.rootProjectPath}
> [echo] [project.parent.getRootProjectPath()]:
> ${project.parent.getRootProjectPath()}
> [echo] [project.parent.rootProjectPath1]:
> ${project.parent.rootProjectPath1}
> [echo] [project.parent.spring3.version]:
> ${project.parent.spring3.version}
> [echo] [project.parent.properties.spring3.version]:
> ${project.parent.properties.spring3.version}
> [echo] [project.parent.properties.rootProjectPath]:
> ${project.parent.properties.rootProjectPath}
> [echo] [project.parent.properties.rootProjectPath1]:
>
[jira] [Closed] (MNG-5522) properties project.parent.xxx not supported under Linux
[
https://issues.apache.org/jira/browse/MNG-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MNG-5522.
Resolution: Not A Problem
> properties project.parent.xxx not supported under Linux
> ---
>
> Key: MNG-5522
> URL: https://issues.apache.org/jira/browse/MNG-5522
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build, POM
>Affects Versions: 3.0.5
> Environment: Few Linuxes tested, work under Windows
>Reporter: Pavel
> Attachments: maven-MNG-5522.zip
>
>
> Initially it was there:
> https://jira.codehaus.org/browse/MRM-1772#comment-333654 . But It is maven
> problem itself.
> It is reproducible on two our Linux machines (Fedora and Gentoo), so it may
> be Linux relative. On all our colleagues on windows it does not reproduced.
> Some details.
> Parent pom among others have:
> {code}
> 1.5.300-SNAPSHOT
> imus
> ...
>
> 2.5.6
> 3.2.2.RELEASE
> 2.1.1
> 1.7.0
> windows-1251
> none
> 1.7
> 1.7
> ${basedir}
> QWERTY
>
> {code}
> First child module:
> {code}
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.1
>
>
> validate
>
> run
>
>
>
>
> [project.parent.rootProjectPath]:
> ${project.parent.rootProjectPath}
>
> [project.parent.getRootProjectPath()]:
> ${project.parent.getRootProjectPath()}
>
> [project.parent.rootProjectPath1]:
> ${project.parent.rootProjectPath1}
>
> [project.parent.spring3.version]:
> ${project.parent.spring3.version}
>
> [project.parent.properties.spring3.version]:
> ${project.parent.properties.spring3.version}
>
> [project.parent.properties.rootProjectPath]:
> ${project.parent.properties.rootProjectPath}
>
> [project.parent.properties.rootProjectPath1]:
> ${project.parent.properties.rootProjectPath1}
>
> [project.parent.name]: ${project.parent.name}
>
> [project.parent.properties]: ${project.parent.properties}
>
>
>
>
>
>
>
> {code}
> *In out I see what project.parent.name resolved and even
> project.parent.properties, but not any property in collection (f.e.
> project.parent.rootProjectPath or project.parent.properties.rootProjectPath)
> as it should [by documentation|http://maven.apache.org/pom.html#Properties]*:
> {code}
> [INFO] --- maven-antrun-plugin:1.1:run (default) @ antinform-lib-parent ---
> [INFO] Executing tasks
> [echo] [project.parent.rootProjectPath]:
> ${project.parent.rootProjectPath}
> [echo] [project.parent.getRootProjectPath()]:
> ${project.parent.getRootProjectPath()}
> [echo] [project.parent.rootProjectPath1]:
> ${project.parent.rootProjectPath1}
> [echo] [project.parent.spring3.version]:
> ${project.parent.spring3.version}
> [echo] [project.parent.properties.spring3.version]:
> ${project.parent.properties.spring3.version}
> [echo] [project.parent.properties.rootProjectPath]:
> ${project.parent.properties.rootProjectPath}
> [echo] [project.parent.properties.rootProjectPath1]:
> ${project.parent.properties.rootProjectPath1}
> [echo] [project.parent.name]: imus
> [echo] [project.parent.properties]: {rootProjectPath1=QWERTY,
> spring3.version=3.2.2.RELEASE, mule.version=2.1.1, aspectj.version=1.7.0,
> maven.compiler.target=1.7, source.encoding=windows-1251,
> maven.test.include=none, maven.compiler.source=1.7, spring.version=2.5.6,
> rootProjectPath=/home/pasha/imus/IdeaProjects/imus-1.5}
> {code}
> Version is
[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file
[
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14747150#comment-14747150
]
Arnaud HERITIER commented on MNG-5889:
--
Hi Daniel,
It is clearly a bug/limitation of the current implementation and it is really
annoying for exemple on CI servers where you can checkout the project in a
subdirectory and launch the build with the path to the pom parameter.
I was aware of this bug for few months but I forgot to report it. I described
it to the team on IRC few days ago but I had sadly no feedback.
Technically I don't yet know how to fix it. The problem is that it enforces
at the .sh/.cmd script level to parte the command line options to find if the
-f/--file option is defined. If it is the case we need to extract its value and
compute the path of the module directory (AFAIR we can either pass to the
option the module directory or the POM file). When the module directory is
found we need to find the .mvn directory from this path and not from the local
directory. For the shell .sh version I think I may succeed to propose a fix,
but for the windows .cmd I'm less confident and I'm clearly against to have a
different behaviour based on the OS
> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build
>Affects Versions: 3.3.3
>Reporter: Daniel Spilker
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of
> the POM selected by {{--file}} and then go through the parent directories.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MASSEMBLY-505) Feature Request: useStrictFiltering option for FileSets
[ https://issues.apache.org/jira/browse/MASSEMBLY-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14747157#comment-14747157 ] Karl Heinz Marbaise commented on MASSEMBLY-505: --- What about providing a patch ? > Feature Request: useStrictFiltering option for FileSets > --- > > Key: MASSEMBLY-505 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-505 > Project: Maven Assembly Plugin > Issue Type: New Feature >Affects Versions: 2.2 > Environment: Maven 2.2.1, RHEL4 >Reporter: John Casey > Attachments: fail_strictfiltering.zip > > > *NOTE:* This is a clone of MASSEMBLY-488. The original issue will be closed > Won't Fix, since the plexus-utils class DirectoryScanner, which is the core > of the FileSet functionality, doesn't support strict include/exclude > filtering. > This issue is a feature request to have that added. > - > I'm trying to turn on useStrictFiltering in a fileSet in an assembly > descriptor, but maven doesn't fail when the file does not exist. Here > is an example of what the assembly descriptor looks like: > > > tar.gz > > > > true > src/main > > nonexistant.txt* > > > > > Running "mvn package" happily produces a tarball with no indication that > anything is wrong. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MASSEMBLY-505) Feature Request: useStrictFiltering option for FileSets
[ https://issues.apache.org/jira/browse/MASSEMBLY-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14747098#comment-14747098 ] Kangol commented on MASSEMBLY-505: -- Stuck on this, too. It's been 4 years, still no fix? Should be a bug instead of feature since the documentation says it is working: https://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html > Feature Request: useStrictFiltering option for FileSets > --- > > Key: MASSEMBLY-505 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-505 > Project: Maven Assembly Plugin > Issue Type: New Feature >Affects Versions: 2.2 > Environment: Maven 2.2.1, RHEL4 >Reporter: John Casey > Attachments: fail_strictfiltering.zip > > > *NOTE:* This is a clone of MASSEMBLY-488. The original issue will be closed > Won't Fix, since the plexus-utils class DirectoryScanner, which is the core > of the FileSet functionality, doesn't support strict include/exclude > filtering. > This issue is a feature request to have that added. > - > I'm trying to turn on useStrictFiltering in a fileSet in an assembly > descriptor, but maven doesn't fail when the file does not exist. Here > is an example of what the assembly descriptor looks like: > > > tar.gz > > > > true > src/main > > nonexistant.txt* > > > > > Running "mvn package" happily produces a tarball with no indication that > anything is wrong. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file
[
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14747310#comment-14747310
]
Arnaud HERITIER commented on MNG-5889:
--
[~daniel.spil...@hamburg.de] Yes I discovered the issue within Jenkins too
where it is a common need to define the path and to not checkout the project in
the root directory of the workspace. Having an option to setup the base
directory may be a workaround but I don't find any other usage of it and like
you I would prefer to see the problem fixed on Maven side
[~khmarbaise] yes because of JVM options which have to be discovered before
launching Maven :(
> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build
>Affects Versions: 3.3.3
>Reporter: Daniel Spilker
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of
> the POM selected by {{--file}} and then go through the parent directories.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-5890) In reactor projects, having a "root" counterpart to "project" properties would be useful
Jordan Zimmerman created MNG-5890:
-
Summary: In reactor projects, having a "root" counterpart to
"project" properties would be useful
Key: MNG-5890
URL: https://issues.apache.org/jira/browse/MNG-5890
Project: Maven
Issue Type: Improvement
Components: Bootstrap & Build, core, General
Affects Versions: 3.3.3
Reporter: Jordan Zimmerman
Often, in reactor builds, modules need to refer to a properties relative to the
root pom. E.g.:
{noformat}
root-pom.xml
\___ module1-pom.xml
\___ sub-module1-pom.xml
\___ module2-pom.xml
\___ sub-module2-pom.xml
{noformat}
In this example, there's no way to set a dependency in the root pom that uses
the root pom's parent version. This is because ${project.parent.version} will
be evaluated relatively in module1/2 and sub-module1/2. In module1/2, it will
refer to the root's parent. But, in sub-module1/2 it will refer only to the
root.
Ideally, we could do something like this:
{code:type=xml}
my.group
foo
1.2.3
my.group
a-different-artifact-in-my.group
${root.parent.version}
{code}
With this "root" feature, ${root.parent.version} would refer to the same value
at every level of the reactor build.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5890) In reactor projects, having a "root" counterpart to "project" properties would be useful
[
https://issues.apache.org/jira/browse/MNG-5890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan Zimmerman updated MNG-5890:
--
Description:
Often, in reactor builds, modules need to refer to properties relative to the
root pom. E.g.:
{noformat}
root-pom.xml
\___ module1-pom.xml
\___ sub-module1-pom.xml
\___ module2-pom.xml
\___ sub-module2-pom.xml
{noformat}
In this example, there's no way to set a dependency in the root pom that uses
the root pom's parent version. This is because ${project.parent.version} will
be evaluated relatively in module1/2 and sub-module1/2. In module1/2, it will
refer to the root's parent. But, in sub-module1/2 it will refer only to the
root.
Ideally, we could do something like this:
{code:type=xml}
my.group
foo
1.2.3
my.group
a-different-artifact-in-my.group
${root.parent.version}
{code}
With this "root" feature, ${root.parent.version} would refer to the same value
at every level of the reactor build.
was:
Often, in reactor builds, modules need to refer to a properties relative to the
root pom. E.g.:
{noformat}
root-pom.xml
\___ module1-pom.xml
\___ sub-module1-pom.xml
\___ module2-pom.xml
\___ sub-module2-pom.xml
{noformat}
In this example, there's no way to set a dependency in the root pom that uses
the root pom's parent version. This is because ${project.parent.version} will
be evaluated relatively in module1/2 and sub-module1/2. In module1/2, it will
refer to the root's parent. But, in sub-module1/2 it will refer only to the
root.
Ideally, we could do something like this:
{code:type=xml}
my.group
foo
1.2.3
my.group
a-different-artifact-in-my.group
${root.parent.version}
{code}
With this "root" feature, ${root.parent.version} would refer to the same value
at every level of the reactor build.
> In reactor projects, having a "root" counterpart to "project" properties
> would be useful
>
>
> Key: MNG-5890
> URL: https://issues.apache.org/jira/browse/MNG-5890
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build, core, General
>Affects Versions: 3.3.3
>Reporter: Jordan Zimmerman
>
> Often, in reactor builds, modules need to refer to properties relative to the
> root pom. E.g.:
> {noformat}
> root-pom.xml
> \___ module1-pom.xml
> \___ sub-module1-pom.xml
> \___ module2-pom.xml
> \___ sub-module2-pom.xml
> {noformat}
> In this example, there's no way to set a dependency in the root pom that uses
> the root pom's parent version. This is because ${project.parent.version} will
> be evaluated relatively in module1/2 and sub-module1/2. In module1/2, it will
> refer to the root's parent. But, in sub-module1/2 it will refer only to the
> root.
> Ideally, we could do something like this:
> {code:type=xml}
>
> my.group
> foo
> 1.2.3
>
>
>
>
> my.group
> a-different-artifact-in-my.group
> ${root.parent.version}
>
>
>
> {code}
> With this "root" feature, ${root.parent.version} would refer to the same
> value at every level of the reactor build.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5890) In reactor projects, having a "root" counterpart to "project" properties would be useful
[
https://issues.apache.org/jira/browse/MNG-5890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan Zimmerman updated MNG-5890:
--
Description:
Often, in reactor builds, modules need to refer to properties relative to the
root pom. E.g.:
{noformat}
root-pom.xml
\___ module1-pom.xml
\___ sub-module1-pom.xml
\___ module2-pom.xml
\___ sub-module2-pom.xml
{noformat}
In this example, there's no way to set a dependency in the root pom that uses
the root pom's parent version. This is because $\{project.parent.version\} will
be evaluated relatively in module1/2 and sub-module1/2. In module1/2, it will
refer to the root's parent. But, in sub-module1/2 it will refer only to the
root.
Ideally, we could do something like this:
{code:type=xml}
my.group
foo
1.2.3
my.group
a-different-artifact-in-my.group
${root.parent.version}
{code}
With this "root" feature, $\{root.parent.version\} would refer to the same
value at every level of the reactor build.
was:
Often, in reactor builds, modules need to refer to properties relative to the
root pom. E.g.:
{noformat}
root-pom.xml
\___ module1-pom.xml
\___ sub-module1-pom.xml
\___ module2-pom.xml
\___ sub-module2-pom.xml
{noformat}
In this example, there's no way to set a dependency in the root pom that uses
the root pom's parent version. This is because ${project.parent.version} will
be evaluated relatively in module1/2 and sub-module1/2. In module1/2, it will
refer to the root's parent. But, in sub-module1/2 it will refer only to the
root.
Ideally, we could do something like this:
{code:type=xml}
my.group
foo
1.2.3
my.group
a-different-artifact-in-my.group
${root.parent.version}
{code}
With this "root" feature, ${root.parent.version} would refer to the same value
at every level of the reactor build.
> In reactor projects, having a "root" counterpart to "project" properties
> would be useful
>
>
> Key: MNG-5890
> URL: https://issues.apache.org/jira/browse/MNG-5890
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build, core, General
>Affects Versions: 3.3.3
>Reporter: Jordan Zimmerman
>
> Often, in reactor builds, modules need to refer to properties relative to the
> root pom. E.g.:
> {noformat}
> root-pom.xml
> \___ module1-pom.xml
> \___ sub-module1-pom.xml
> \___ module2-pom.xml
> \___ sub-module2-pom.xml
> {noformat}
> In this example, there's no way to set a dependency in the root pom that uses
> the root pom's parent version. This is because $\{project.parent.version\}
> will be evaluated relatively in module1/2 and sub-module1/2. In module1/2, it
> will refer to the root's parent. But, in sub-module1/2 it will refer only to
> the root.
> Ideally, we could do something like this:
> {code:type=xml}
>
> my.group
> foo
> 1.2.3
>
>
>
>
> my.group
> a-different-artifact-in-my.group
> ${root.parent.version}
>
>
>
> {code}
> With this "root" feature, $\{root.parent.version\} would refer to the same
> value at every level of the reactor build.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MDEP-490) Add flag to analyze-dep-mgt goal to ignore exclusion errors
[
https://issues.apache.org/jira/browse/MDEP-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14790737#comment-14790737
]
Jonathan Haber commented on MDEP-490:
-
[~khmarbaise] [~krosenvold] [~agudian] [~rfscholte] does the PR look good to
merge?
> Add flag to analyze-dep-mgt goal to ignore exclusion errors
> ---
>
> Key: MDEP-490
> URL: https://issues.apache.org/jira/browse/MDEP-490
> Project: Maven Dependency Plugin
> Issue Type: Improvement
>Reporter: Jonathan Haber
>
> I would like to run the analyze-dep-mgt goal with failBuild=true, but it
> doesn't work because of exclusion errors. One common example is libraries
> that accidentally depend on junit at compile scope instead of test scope.
> When I encounter a library like this, I add an exclusion on junit. But I have
> junit in my dependency tree at test scope, so my build fails with a message
> like:
> {quote}
> [INFO] junit:junit:jar was excluded in DepMgt, but version 4.11 has been
> found in the dependency tree.
> {quote}
> I think the simplest fix is to add a flag to the analyze-dep-mgt goal to
> ignore exclusion errors. I just want to use the goal to check for version
> mismatches, if I want to enforce banned dependencies the
> maven-enforcer-plugin has more robust support for this. I implemented this
> change in [this|https://github.com/apache/maven-plugins/pull/54] pull
> request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MDEP-490) Add flag to analyze-dep-mgt goal to ignore exclusion errors
[
https://issues.apache.org/jira/browse/MDEP-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14790937#comment-14790937
]
Kristian Rosenvold edited comment on MDEP-490 at 9/16/15 6:57 PM:
--
Please stop name dropping people to catch their attention. In a lot of cases it
has the opposite effect of what you want.
was (Author: krosenvold):
Please stop name dropping people to catch their attention. In a lot of cases it
has the opposite intention of what you want.
> Add flag to analyze-dep-mgt goal to ignore exclusion errors
> ---
>
> Key: MDEP-490
> URL: https://issues.apache.org/jira/browse/MDEP-490
> Project: Maven Dependency Plugin
> Issue Type: Improvement
>Reporter: Jonathan Haber
>
> I would like to run the analyze-dep-mgt goal with failBuild=true, but it
> doesn't work because of exclusion errors. One common example is libraries
> that accidentally depend on junit at compile scope instead of test scope.
> When I encounter a library like this, I add an exclusion on junit. But I have
> junit in my dependency tree at test scope, so my build fails with a message
> like:
> {quote}
> [INFO] junit:junit:jar was excluded in DepMgt, but version 4.11 has been
> found in the dependency tree.
> {quote}
> I think the simplest fix is to add a flag to the analyze-dep-mgt goal to
> ignore exclusion errors. I just want to use the goal to check for version
> mismatches, if I want to enforce banned dependencies the
> maven-enforcer-plugin has more robust support for this. I implemented this
> change in [this|https://github.com/apache/maven-plugins/pull/54] pull
> request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MDEP-490) Add flag to analyze-dep-mgt goal to ignore exclusion errors
[
https://issues.apache.org/jira/browse/MDEP-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14790937#comment-14790937
]
Kristian Rosenvold commented on MDEP-490:
-
Please stop name dropping people to catch their attention. In a lot of cases it
has the opposite intention of what you want.
> Add flag to analyze-dep-mgt goal to ignore exclusion errors
> ---
>
> Key: MDEP-490
> URL: https://issues.apache.org/jira/browse/MDEP-490
> Project: Maven Dependency Plugin
> Issue Type: Improvement
>Reporter: Jonathan Haber
>
> I would like to run the analyze-dep-mgt goal with failBuild=true, but it
> doesn't work because of exclusion errors. One common example is libraries
> that accidentally depend on junit at compile scope instead of test scope.
> When I encounter a library like this, I add an exclusion on junit. But I have
> junit in my dependency tree at test scope, so my build fails with a message
> like:
> {quote}
> [INFO] junit:junit:jar was excluded in DepMgt, but version 4.11 has been
> found in the dependency tree.
> {quote}
> I think the simplest fix is to add a flag to the analyze-dep-mgt goal to
> ignore exclusion errors. I just want to use the goal to check for version
> mismatches, if I want to enforce banned dependencies the
> maven-enforcer-plugin has more robust support for this. I implemented this
> change in [this|https://github.com/apache/maven-plugins/pull/54] pull
> request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MCHANGES-359) announcement-mail in multi-module project
[
https://issues.apache.org/jira/browse/MCHANGES-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14790894#comment-14790894
]
Dennis Lundberg commented on MCHANGES-359:
--
What does your configuration look like?
> announcement-mail in multi-module project
> -
>
> Key: MCHANGES-359
> URL: https://issues.apache.org/jira/browse/MCHANGES-359
> Project: Maven Changes Plugin
> Issue Type: Bug
> Components: announcement
>Affects Versions: 2.11
> Environment: apache-maven-3.2.5
>Reporter: Daniel Kreutz
>
> Hi,
> I am using the announcement-mail goal on a multi-module project. I'd like to
> send one mail for the whole projekt and not for every single module. So
> maven-changes-plugin is only configured at the parent pom. The parent pom is
> called with {{-Dannouncement.runOnlyAtExecutionRoot=true}}.
> Goal announcement-generate works well, but with announcement-mail I get the
> following error:
> {code}
> [INFO]
>
> [INFO] Building Submodule 1.0.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] >>> maven-changes-plugin:2.11:announcement-mail (default-cli) >
> :announcement-generate @ submodule >>>
> [INFO]
> [INFO] --- maven-changes-plugin:2.11:announcement-generate
> (announcement-generate) @ submodule ---
> [INFO] Skipping the announcement generation in this project because it's not
> the Execution Root
> [INFO]
> [INFO] <<< maven-changes-plugin:2.11:announcement-mail (default-cli) <
> :announcement-generate @ submodule <<<
> [INFO]
> [INFO] --- maven-changes-plugin:2.11:announcement-mail (default-cli) @
> submodule ---
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Submodule FAILURE [ 0.784 s]
> [INFO] Parent ... SUCCESS [ 24.840 s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 26.711 s
> [INFO] Finished at: 2015-09-15T11:27:36+02:00
> [INFO] Final Memory: 22M/218M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-changes-plugin:2.11:announcement-mail
> (default-cli) on project submodule: The parameters 'toAddresses' for goal
> org.apache.maven.plugins:maven-changes-plugin:2.11:announcement-mail are
> missing or invalid -> [Help 1]
> {code}
> I suppose, {{toAddresses}} will be injected before runOnlyAtExecutionRoot is
> checked. So I get that error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MDEP-490) Add flag to analyze-dep-mgt goal to ignore exclusion errors
[
https://issues.apache.org/jira/browse/MDEP-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14790941#comment-14790941
]
Jonathan Haber commented on MDEP-490:
-
I'm sorry, I'm not sure what the proper avenue is to get the attention of a
project maintainer. It has been two months of silence since I addressed the PR
feedback.
> Add flag to analyze-dep-mgt goal to ignore exclusion errors
> ---
>
> Key: MDEP-490
> URL: https://issues.apache.org/jira/browse/MDEP-490
> Project: Maven Dependency Plugin
> Issue Type: Improvement
>Reporter: Jonathan Haber
>
> I would like to run the analyze-dep-mgt goal with failBuild=true, but it
> doesn't work because of exclusion errors. One common example is libraries
> that accidentally depend on junit at compile scope instead of test scope.
> When I encounter a library like this, I add an exclusion on junit. But I have
> junit in my dependency tree at test scope, so my build fails with a message
> like:
> {quote}
> [INFO] junit:junit:jar was excluded in DepMgt, but version 4.11 has been
> found in the dependency tree.
> {quote}
> I think the simplest fix is to add a flag to the analyze-dep-mgt goal to
> ignore exclusion errors. I just want to use the goal to check for version
> mismatches, if I want to enforce banned dependencies the
> maven-enforcer-plugin has more robust support for this. I implemented this
> change in [this|https://github.com/apache/maven-plugins/pull/54] pull
> request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5890) In reactor projects, having a "root" counterpart to "project" properties would be useful
[
https://issues.apache.org/jira/browse/MNG-5890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14791103#comment-14791103
]
Karl Heinz Marbaise commented on MNG-5890:
--
Can you please make an example project (for example on github) to have
something more concrete to talk about...
> In reactor projects, having a "root" counterpart to "project" properties
> would be useful
>
>
> Key: MNG-5890
> URL: https://issues.apache.org/jira/browse/MNG-5890
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build, core, General
>Affects Versions: 3.3.3
>Reporter: Jordan Zimmerman
>
> Often, in reactor builds, modules need to refer to properties relative to the
> root pom. E.g.:
> {noformat}
> root-pom.xml
> \___ module1-pom.xml
> \___ sub-module1-pom.xml
> \___ module2-pom.xml
> \___ sub-module2-pom.xml
> {noformat}
> In this example, there's no way to set a dependency in the root pom that uses
> the root pom's parent version. This is because $\{project.parent.version\}
> will be evaluated relatively in module1/2 and sub-module1/2. In module1/2, it
> will refer to the root's parent. But, in sub-module1/2 it will refer only to
> the root.
> Ideally, we could do something like this:
> {code:type=xml}
>
> my.group
> foo
> 1.2.3
>
>
>
>
> my.group
> a-different-artifact-in-my.group
> ${root.parent.version}
>
>
>
> {code}
> With this "root" feature, $\{root.parent.version\} would refer to the same
> value at every level of the reactor build.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MDEP-490) Add flag to analyze-dep-mgt goal to ignore exclusion errors
[
https://issues.apache.org/jira/browse/MDEP-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1479#comment-1479
]
Karl Heinz Marbaise commented on MDEP-490:
--
Sorry to say that but as Kristian already mentioned this is the wrong
way...please go first via the user mailing or in this cast it might be good way
to go via dev list...but JIRA issues is definitively not the right way...
> Add flag to analyze-dep-mgt goal to ignore exclusion errors
> ---
>
> Key: MDEP-490
> URL: https://issues.apache.org/jira/browse/MDEP-490
> Project: Maven Dependency Plugin
> Issue Type: Improvement
>Reporter: Jonathan Haber
>
> I would like to run the analyze-dep-mgt goal with failBuild=true, but it
> doesn't work because of exclusion errors. One common example is libraries
> that accidentally depend on junit at compile scope instead of test scope.
> When I encounter a library like this, I add an exclusion on junit. But I have
> junit in my dependency tree at test scope, so my build fails with a message
> like:
> {quote}
> [INFO] junit:junit:jar was excluded in DepMgt, but version 4.11 has been
> found in the dependency tree.
> {quote}
> I think the simplest fix is to add a flag to the analyze-dep-mgt goal to
> ignore exclusion errors. I just want to use the goal to check for version
> mismatches, if I want to enforce banned dependencies the
> maven-enforcer-plugin has more robust support for this. I implemented this
> change in [this|https://github.com/apache/maven-plugins/pull/54] pull
> request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MDEP-490) Add flag to analyze-dep-mgt goal to ignore exclusion errors
[
https://issues.apache.org/jira/browse/MDEP-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14791117#comment-14791117
]
Jonathan Haber commented on MDEP-490:
-
Ok I sent a
[PR|https://github.com/apache/maven-plugins/pull/54#issuecomment-110448753] and
[~agudian] asked me to open a JIRA so I did I'm just going to write my own
maven plugin.
> Add flag to analyze-dep-mgt goal to ignore exclusion errors
> ---
>
> Key: MDEP-490
> URL: https://issues.apache.org/jira/browse/MDEP-490
> Project: Maven Dependency Plugin
> Issue Type: Improvement
>Reporter: Jonathan Haber
>
> I would like to run the analyze-dep-mgt goal with failBuild=true, but it
> doesn't work because of exclusion errors. One common example is libraries
> that accidentally depend on junit at compile scope instead of test scope.
> When I encounter a library like this, I add an exclusion on junit. But I have
> junit in my dependency tree at test scope, so my build fails with a message
> like:
> {quote}
> [INFO] junit:junit:jar was excluded in DepMgt, but version 4.11 has been
> found in the dependency tree.
> {quote}
> I think the simplest fix is to add a flag to the analyze-dep-mgt goal to
> ignore exclusion errors. I just want to use the goal to check for version
> mismatches, if I want to enforce banned dependencies the
> maven-enforcer-plugin has more robust support for this. I implemented this
> change in [this|https://github.com/apache/maven-plugins/pull/54] pull
> request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5890) In reactor projects, having a "root" counterpart to "project" properties would be useful
[
https://issues.apache.org/jira/browse/MNG-5890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14791122#comment-14791122
]
Jordan Zimmerman commented on MNG-5890:
---
This is very contrived but it's enough to see the issue:
https://github.com/Randgalt/example
Do a "mvn help:effective-pom" from the root and you will see that the version
for io.soabase:soabase-core keeps changing. There's no way to specify that a
dependency match the version of the root's parent.
> In reactor projects, having a "root" counterpart to "project" properties
> would be useful
>
>
> Key: MNG-5890
> URL: https://issues.apache.org/jira/browse/MNG-5890
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build, core, General
>Affects Versions: 3.3.3
>Reporter: Jordan Zimmerman
>
> Often, in reactor builds, modules need to refer to properties relative to the
> root pom. E.g.:
> {noformat}
> root-pom.xml
> \___ module1-pom.xml
> \___ sub-module1-pom.xml
> \___ module2-pom.xml
> \___ sub-module2-pom.xml
> {noformat}
> In this example, there's no way to set a dependency in the root pom that uses
> the root pom's parent version. This is because $\{project.parent.version\}
> will be evaluated relatively in module1/2 and sub-module1/2. In module1/2, it
> will refer to the root's parent. But, in sub-module1/2 it will refer only to
> the root.
> Ideally, we could do something like this:
> {code:type=xml}
>
> my.group
> foo
> 1.2.3
>
>
>
>
> my.group
> a-different-artifact-in-my.group
> ${root.parent.version}
>
>
>
> {code}
> With this "root" feature, $\{root.parent.version\} would refer to the same
> value at every level of the reactor build.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MDEP-490) Add flag to analyze-dep-mgt goal to ignore exclusion errors
[
https://issues.apache.org/jira/browse/MDEP-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Haber closed MDEP-490.
---
Resolution: Won't Fix
> Add flag to analyze-dep-mgt goal to ignore exclusion errors
> ---
>
> Key: MDEP-490
> URL: https://issues.apache.org/jira/browse/MDEP-490
> Project: Maven Dependency Plugin
> Issue Type: Improvement
>Reporter: Jonathan Haber
>
> I would like to run the analyze-dep-mgt goal with failBuild=true, but it
> doesn't work because of exclusion errors. One common example is libraries
> that accidentally depend on junit at compile scope instead of test scope.
> When I encounter a library like this, I add an exclusion on junit. But I have
> junit in my dependency tree at test scope, so my build fails with a message
> like:
> {quote}
> [INFO] junit:junit:jar was excluded in DepMgt, but version 4.11 has been
> found in the dependency tree.
> {quote}
> I think the simplest fix is to add a flag to the analyze-dep-mgt goal to
> ignore exclusion errors. I just want to use the goal to check for version
> mismatches, if I want to enforce banned dependencies the
> maven-enforcer-plugin has more robust support for this. I implemented this
> change in [this|https://github.com/apache/maven-plugins/pull/54] pull
> request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MDEP-490) Add flag to analyze-dep-mgt goal to ignore exclusion errors
[
https://issues.apache.org/jira/browse/MDEP-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14791256#comment-14791256
]
ASF GitHub Bot commented on MDEP-490:
-
Github user jhaber closed the pull request at:
https://github.com/apache/maven-plugins/pull/54
> Add flag to analyze-dep-mgt goal to ignore exclusion errors
> ---
>
> Key: MDEP-490
> URL: https://issues.apache.org/jira/browse/MDEP-490
> Project: Maven Dependency Plugin
> Issue Type: Improvement
>Reporter: Jonathan Haber
>
> I would like to run the analyze-dep-mgt goal with failBuild=true, but it
> doesn't work because of exclusion errors. One common example is libraries
> that accidentally depend on junit at compile scope instead of test scope.
> When I encounter a library like this, I add an exclusion on junit. But I have
> junit in my dependency tree at test scope, so my build fails with a message
> like:
> {quote}
> [INFO] junit:junit:jar was excluded in DepMgt, but version 4.11 has been
> found in the dependency tree.
> {quote}
> I think the simplest fix is to add a flag to the analyze-dep-mgt goal to
> ignore exclusion errors. I just want to use the goal to check for version
> mismatches, if I want to enforce banned dependencies the
> maven-enforcer-plugin has more robust support for this. I implemented this
> change in [this|https://github.com/apache/maven-plugins/pull/54] pull
> request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1179) TestNG parallel options seem to not be honored
[ https://issues.apache.org/jira/browse/SUREFIRE-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Vincent updated SUREFIRE-1179: --- Attachment: testng-test.zip Sample project attempting to illustrate a parallel data provider feeding a method. Attempting to increase the number of threads handling the method calls. > TestNG parallel options seem to not be honored > -- > > Key: SUREFIRE-1179 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1179 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.18.1 > Environment: Windows 7 x64, Java 8 (1.8.0_60), TestNG v6.9.6, Maven > Surefire version 2.18.1 >Reporter: Jeff Vincent > Attachments: testng-test.zip > > > I have some simple tests I'm trying to configure to run in parallel. I've > set my POM file to the following: > > org.apache.maven.plugins > maven-surefire-plugin > 2.18.1 > > methods > 50 > > > When I run in parallel, I only get 10 threads no matter the setting and I can > not change it. I've tried adding the annotation parameter to the method as > well: > @Test(dataProvider = "dataProvider", threadPoolSize = 50) > Nothing seems to help. I have a simple project that illustrates what I'm > seeing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SUREFIRE-1179) TestNG parallel options seem to not be honored
Jeff Vincent created SUREFIRE-1179: -- Summary: TestNG parallel options seem to not be honored Key: SUREFIRE-1179 URL: https://issues.apache.org/jira/browse/SUREFIRE-1179 Project: Maven Surefire Issue Type: Bug Components: TestNG support Affects Versions: 2.18.1 Environment: Windows 7 x64, Java 8 (1.8.0_60), TestNG v6.9.6, Maven Surefire version 2.18.1 Reporter: Jeff Vincent I have some simple tests I'm trying to configure to run in parallel. I've set my POM file to the following: org.apache.maven.plugins maven-surefire-plugin 2.18.1 methods 50 When I run in parallel, I only get 10 threads no matter the setting and I can not change it. I've tried adding the annotation parameter to the method as well: @Test(dataProvider = "dataProvider", threadPoolSize = 50) Nothing seems to help. I have a simple project that illustrates what I'm seeing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1179) TestNG parallel options seem to not be honored
[ https://issues.apache.org/jira/browse/SUREFIRE-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Vincent updated SUREFIRE-1179: --- Description: I have some simple tests I'm trying to configure to run in parallel using Maven 3.3.3 and the latest versions of TestNG. I've set my POM file to the following: org.apache.maven.plugins maven-surefire-plugin 2.18.1 methods 50 When I run in parallel, I only get 10 threads no matter the setting and I can not change it. I've tried adding the annotation parameter to the method as well: @Test(dataProvider = "dataProvider", threadPoolSize = 50) Nothing seems to help. I have a simple project that illustrates what I'm seeing. was: I have some simple tests I'm trying to configure to run in parallel. I've set my POM file to the following: org.apache.maven.plugins maven-surefire-plugin 2.18.1 methods 50 When I run in parallel, I only get 10 threads no matter the setting and I can not change it. I've tried adding the annotation parameter to the method as well: @Test(dataProvider = "dataProvider", threadPoolSize = 50) Nothing seems to help. I have a simple project that illustrates what I'm seeing. > TestNG parallel options seem to not be honored > -- > > Key: SUREFIRE-1179 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1179 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.18.1 > Environment: Windows 7 x64, Java 8 (1.8.0_60), TestNG v6.9.6, Maven > Surefire version 2.18.1 >Reporter: Jeff Vincent > Attachments: testng-test.zip > > > I have some simple tests I'm trying to configure to run in parallel using > Maven 3.3.3 and the latest versions of TestNG. I've set my POM file to the > following: > > org.apache.maven.plugins > maven-surefire-plugin > 2.18.1 > > methods > 50 > > > When I run in parallel, I only get 10 threads no matter the setting and I can > not change it. I've tried adding the annotation parameter to the method as > well: > @Test(dataProvider = "dataProvider", threadPoolSize = 50) > Nothing seems to help. I have a simple project that illustrates what I'm > seeing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
