[jira] [Closed] (DOXIASITETOOLS-187) edit value not inherited
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed DOXIASITETOOLS-187. Resolution: Fixed Assignee: Hervé Boutemy fixed in https://gitbox.apache.org/repos/asf?p=maven-doxia-sitetools.git&a=commit&h=9ab6080a5146e63575cf8384b55af59b08f7081c > edit value not inherited > > > Key: DOXIASITETOOLS-187 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-187 > Project: Maven Doxia Sitetools > Issue Type: Bug > Components: Decoration model >Affects Versions: 1.8 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy >Priority: Critical > Fix For: 1.8.1 > > > edit property was added in DOXIASITETOOLS-183 but was forgotten in > inheritance: currently need to configure it explicitely in every site.xml > should be inhertited -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MPATCH-19) ignored patches must not be applied
[
https://issues.apache.org/jira/browse/MPATCH-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16387385#comment-16387385
]
Matthias Balke commented on MPATCH-19:
--
Maybe one should rename this option to {{optionalPatches}}. For what I
understand, this is what it does. If a patch should be applied, but does not
exist and it is listet as ignored no exception is thrown.
> ignored patches must not be applied
> ---
>
> Key: MPATCH-19
> URL: https://issues.apache.org/jira/browse/MPATCH-19
> Project: Maven Patch Plugin
> Issue Type: Bug
>Affects Versions: 1.2
>Reporter: Matthias Balke
>Priority: Critical
>
> To reproduce this bug one has to configure the maven patch plugin to ignore
> some patches.
> {code:java}
>
> ignored.patch
> {code}
> When executing the plugin the ignored files are also applied! It seems that
> this feature is broken or not well enough documented.
> Also using {{strictPatching}} does not work as documented:
> {code:java}
> true
>
> ignored.patch
> {code}
> I created a minimal example to reproduce this bug:
> https://github.com/matthiasbalke/maven-patch-plugin-MPATCH-19
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-444) Add an 'aggregated-no-fork' goal
[
https://issues.apache.org/jira/browse/MJAVADOC-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16387264#comment-16387264
]
Sean Busbey commented on MJAVADOC-444:
--
PR has now been updated with docs and an it, modeled after the work for
MJAVADOC-369 which added the no-fork versions of the javadoc and javadoc-test
goals.
> Add an 'aggregated-no-fork' goal
>
>
> Key: MJAVADOC-444
> URL: https://issues.apache.org/jira/browse/MJAVADOC-444
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 2.10.3
>Reporter: Karl Heinz Marbaise
>Priority: Critical
>
> Currently you can call maven-javadoc-plugin via {{mvn clean package
> javadoc:aggregate}} which results in deleting all previously created
> artifacts in {{target}} folder. So it would be helpful having a separate goal
> without forking the life cycle.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-205) maven-compiler-plugin: incremental compilation broken
[
https://issues.apache.org/jira/browse/MCOMPILER-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16387212#comment-16387212
]
ASF GitHub Bot commented on MCOMPILER-205:
--
aikar commented on a change in pull request #3: [MCOMPILER-205] fixes
incremental compilation
URL:
https://github.com/apache/maven-compiler-plugin/pull/3#discussion_r172400211
##
File path:
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java
##
@@ -750,36 +750,16 @@ else if (
CompilerConfiguration.CompilerReuseStrategy.ReuseSame.getStrategy().eq
IncrementalBuildHelperRequest incrementalBuildHelperRequest = null;
-if ( useIncrementalCompilation )
+if ( !useIncrementalCompilation )
{
getLog().debug( "useIncrementalCompilation enabled" );
Review comment:
You forgot to invert these log lines.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> maven-compiler-plugin: incremental compilation broken
> -
>
> Key: MCOMPILER-205
> URL: https://issues.apache.org/jira/browse/MCOMPILER-205
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Lukas Fryc
>Priority: Major
> Attachments: hello.tgz, ignore-package-info.patch,
> no-class-in-java-file.zip, only-recompile-changed.patch
>
>
> When we do {{clean}} -> {{compile}} -> {{compile}}, all Java sources are
> re-compiled for second compilation steps:
> {code}
> [framework]$ mvn clean
> ...
> [framework]$ mvn compile
> ...
> [INFO] --- maven-compiler-plugin:3.1:compile (precompile-sources-for-cdk) @
> richfaces-framework ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 915 source files to
> /mnt/workspace/workspaces/richfaces/richfaces5/framework/target/classes
> ...
> [framework]$ mvn compile
> ...
> [INFO] --- maven-compiler-plugin:3.1:compile (precompile-sources-for-cdk) @
> richfaces-framework ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 915 source files to
> /mnt/workspace/workspaces/richfaces/richfaces5/framework/target/classes
> ...
> {code}
> The source code of the affected project:
> https://github.com/richfaces/richfaces5/tree/077dcfc0a46d03d7ba9a7ac3e701a4adfb834c71
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] aikar commented on a change in pull request #3: [MCOMPILER-205] fixes incremental compilation
aikar commented on a change in pull request #3: [MCOMPILER-205] fixes
incremental compilation
URL:
https://github.com/apache/maven-compiler-plugin/pull/3#discussion_r172400211
##
File path:
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java
##
@@ -750,36 +750,16 @@ else if (
CompilerConfiguration.CompilerReuseStrategy.ReuseSame.getStrategy().eq
IncrementalBuildHelperRequest incrementalBuildHelperRequest = null;
-if ( useIncrementalCompilation )
+if ( !useIncrementalCompilation )
{
getLog().debug( "useIncrementalCompilation enabled" );
Review comment:
You forgot to invert these log lines.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Updated] (MNG-6370) ConcurrencyDependencyGraph#getNumberOfBuilds() does not remove finished projects from unfinished ones
[
https://issues.apache.org/jira/browse/MNG-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6370:
Summary: ConcurrencyDependencyGraph#getNumberOfBuilds() does not remove
finished projects from unfinished ones (was: Actual argument type
'HashSet' is incompatible with expected argument type
'MavenProject'.)
> ConcurrencyDependencyGraph#getNumberOfBuilds() does not remove finished
> projects from unfinished ones
> -
>
> Key: MNG-6370
> URL: https://issues.apache.org/jira/browse/MNG-6370
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2, 3.5.3
>Reporter: Sylwester Lachiewicz
>Assignee: Michael Osipov
>Priority: Trivial
> Fix For: 3.5.4-candidate
>
>
> Fix _ConcurrencyDependencyGraph.getUnfinishedProjects_
> {code:java}
> private final HashSet finishedProjects = new HashSet<>();
> /**
> * @return set of projects that have yet to be processed successfully by the
> build.
> */
> public Set getUnfinishedProjects()
> {
> Set unfinished = new HashSet<>( projectBuilds.getProjects() );
> unfinished.remove( finishedProjects );
> return unfinished;
> }{code}
> replace _remove()_ with _removeAll()_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6370) Actual argument type 'HashSet' is incompatible with expected argument type 'MavenProject'.
[
https://issues.apache.org/jira/browse/MNG-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16387055#comment-16387055
]
Michael Osipov commented on MNG-6370:
-
You are right, checked the impl. No CCEs are thrown.
> Actual argument type 'HashSet' is incompatible with expected
> argument type 'MavenProject'.
>
>
> Key: MNG-6370
> URL: https://issues.apache.org/jira/browse/MNG-6370
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2, 3.5.3
>Reporter: Sylwester Lachiewicz
>Priority: Trivial
> Fix For: 3.5.4-candidate
>
>
> Fix _ConcurrencyDependencyGraph.getUnfinishedProjects_
> {code:java}
> private final HashSet finishedProjects = new HashSet<>();
> /**
> * @return set of projects that have yet to be processed successfully by the
> build.
> */
> public Set getUnfinishedProjects()
> {
> Set unfinished = new HashSet<>( projectBuilds.getProjects() );
> unfinished.remove( finishedProjects );
> return unfinished;
> }{code}
> replace _remove()_ with _removeAll()_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MNG-6370) Actual argument type 'HashSet' is incompatible with expected argument type 'MavenProject'.
[
https://issues.apache.org/jira/browse/MNG-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-6370:
---
Assignee: Michael Osipov
> Actual argument type 'HashSet' is incompatible with expected
> argument type 'MavenProject'.
>
>
> Key: MNG-6370
> URL: https://issues.apache.org/jira/browse/MNG-6370
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2, 3.5.3
>Reporter: Sylwester Lachiewicz
>Assignee: Michael Osipov
>Priority: Trivial
> Fix For: 3.5.4-candidate
>
>
> Fix _ConcurrencyDependencyGraph.getUnfinishedProjects_
> {code:java}
> private final HashSet finishedProjects = new HashSet<>();
> /**
> * @return set of projects that have yet to be processed successfully by the
> build.
> */
> public Set getUnfinishedProjects()
> {
> Set unfinished = new HashSet<>( projectBuilds.getProjects() );
> unfinished.remove( finishedProjects );
> return unfinished;
> }{code}
> replace _remove()_ with _removeAll()_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6370) Actual argument type 'HashSet' is incompatible with expected argument type 'MavenProject'.
[
https://issues.apache.org/jira/browse/MNG-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6370:
Fix Version/s: 3.5.4-candidate
> Actual argument type 'HashSet' is incompatible with expected
> argument type 'MavenProject'.
>
>
> Key: MNG-6370
> URL: https://issues.apache.org/jira/browse/MNG-6370
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2, 3.5.3
>Reporter: Sylwester Lachiewicz
>Assignee: Michael Osipov
>Priority: Trivial
> Fix For: 3.5.4-candidate
>
>
> Fix _ConcurrencyDependencyGraph.getUnfinishedProjects_
> {code:java}
> private final HashSet finishedProjects = new HashSet<>();
> /**
> * @return set of projects that have yet to be processed successfully by the
> build.
> */
> public Set getUnfinishedProjects()
> {
> Set unfinished = new HashSet<>( projectBuilds.getProjects() );
> unfinished.remove( finishedProjects );
> return unfinished;
> }{code}
> replace _remove()_ with _removeAll()_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6370) Actual argument type 'HashSet' is incompatible with expected argument type 'MavenProject'.
[
https://issues.apache.org/jira/browse/MNG-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16387030#comment-16387030
]
Sylwester Lachiewicz commented on MNG-6370:
---
No, will just return not modified array. As far i can check there was not calls
to getUnfinishedProject() in Maven sources.
> Actual argument type 'HashSet' is incompatible with expected
> argument type 'MavenProject'.
>
>
> Key: MNG-6370
> URL: https://issues.apache.org/jira/browse/MNG-6370
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2, 3.5.3
>Reporter: Sylwester Lachiewicz
>Priority: Trivial
>
> Fix _ConcurrencyDependencyGraph.getUnfinishedProjects_
> {code:java}
> private final HashSet finishedProjects = new HashSet<>();
> /**
> * @return set of projects that have yet to be processed successfully by the
> build.
> */
> public Set getUnfinishedProjects()
> {
> Set unfinished = new HashSet<>( projectBuilds.getProjects() );
> unfinished.remove( finishedProjects );
> return unfinished;
> }{code}
> replace _remove()_ with _removeAll()_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6370) Actual argument type 'HashSet' is incompatible with expected argument type 'MavenProject'.
[
https://issues.apache.org/jira/browse/MNG-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6370:
Affects Version/s: 3.5.2
> Actual argument type 'HashSet' is incompatible with expected
> argument type 'MavenProject'.
>
>
> Key: MNG-6370
> URL: https://issues.apache.org/jira/browse/MNG-6370
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2, 3.5.3
>Reporter: Sylwester Lachiewicz
>Priority: Trivial
>
> Fix _ConcurrencyDependencyGraph.getUnfinishedProjects_
> {code:java}
> private final HashSet finishedProjects = new HashSet<>();
> /**
> * @return set of projects that have yet to be processed successfully by the
> build.
> */
> public Set getUnfinishedProjects()
> {
> Set unfinished = new HashSet<>( projectBuilds.getProjects() );
> unfinished.remove( finishedProjects );
> return unfinished;
> }{code}
> replace _remove()_ with _removeAll()_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6370) Actual argument type 'HashSet' is incompatible with expected argument type 'MavenProject'.
[
https://issues.apache.org/jira/browse/MNG-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6370:
Affects Version/s: 3.5.3
> Actual argument type 'HashSet' is incompatible with expected
> argument type 'MavenProject'.
>
>
> Key: MNG-6370
> URL: https://issues.apache.org/jira/browse/MNG-6370
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2, 3.5.3
>Reporter: Sylwester Lachiewicz
>Priority: Trivial
>
> Fix _ConcurrencyDependencyGraph.getUnfinishedProjects_
> {code:java}
> private final HashSet finishedProjects = new HashSet<>();
> /**
> * @return set of projects that have yet to be processed successfully by the
> build.
> */
> public Set getUnfinishedProjects()
> {
> Set unfinished = new HashSet<>( projectBuilds.getProjects() );
> unfinished.remove( finishedProjects );
> return unfinished;
> }{code}
> replace _remove()_ with _removeAll()_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6370) Actual argument type 'HashSet' is incompatible with expected argument type 'MavenProject'.
[
https://issues.apache.org/jira/browse/MNG-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386929#comment-16386929
]
Michael Osipov commented on MNG-6370:
-
At least all ITs pass here.
> Actual argument type 'HashSet' is incompatible with expected
> argument type 'MavenProject'.
>
>
> Key: MNG-6370
> URL: https://issues.apache.org/jira/browse/MNG-6370
> Project: Maven
> Issue Type: Bug
>Reporter: Sylwester Lachiewicz
>Priority: Trivial
>
> Fix _ConcurrencyDependencyGraph.getUnfinishedProjects_
> {code:java}
> private final HashSet finishedProjects = new HashSet<>();
> /**
> * @return set of projects that have yet to be processed successfully by the
> build.
> */
> public Set getUnfinishedProjects()
> {
> Set unfinished = new HashSet<>( projectBuilds.getProjects() );
> unfinished.remove( finishedProjects );
> return unfinished;
> }{code}
> replace _remove()_ with _removeAll()_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MRESOLVER-35) Move dependency collector and friends to subpackage in maven-resolver-impl
[ https://issues.apache.org/jira/browse/MRESOLVER-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MRESOLVER-35. --- Resolution: Fixed Fixed with [142469e78633de0d27ba0a75f1c440587a604307|https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=142469e78633de0d27ba0a75f1c440587a604307]. > Move dependency collector and friends to subpackage in maven-resolver-impl > -- > > Key: MRESOLVER-35 > URL: https://issues.apache.org/jira/browse/MRESOLVER-35 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Affects Versions: Maven Artifact Resolver 1.1.1 >Reporter: Sylwester Lachiewicz >Assignee: Michael Osipov >Priority: Minor > Fix For: Maven Artifact Resolver 1.1.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6370) Actual argument type 'HashSet' is incompatible with expected argument type 'MavenProject'.
[
https://issues.apache.org/jira/browse/MNG-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386850#comment-16386850
]
Michael Osipov commented on MNG-6370:
-
The current code will lead to a {{ClassCastException}}, right?
> Actual argument type 'HashSet' is incompatible with expected
> argument type 'MavenProject'.
>
>
> Key: MNG-6370
> URL: https://issues.apache.org/jira/browse/MNG-6370
> Project: Maven
> Issue Type: Bug
>Reporter: Sylwester Lachiewicz
>Priority: Trivial
>
> Fix _ConcurrencyDependencyGraph.getUnfinishedProjects_
> {code:java}
> private final HashSet finishedProjects = new HashSet<>();
> /**
> * @return set of projects that have yet to be processed successfully by the
> build.
> */
> public Set getUnfinishedProjects()
> {
> Set unfinished = new HashSet<>( projectBuilds.getProjects() );
> unfinished.remove( finishedProjects );
> return unfinished;
> }{code}
> replace _remove()_ with _removeAll()_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MNG-6370) Actual argument type 'HashSet' is incompatible with expected argument type 'MavenProject'.
[
https://issues.apache.org/jira/browse/MNG-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386850#comment-16386850
]
Michael Osipov edited comment on MNG-6370 at 3/5/18 10:20 PM:
--
The current code will lead to a {{ClassCastException}}, right? If so, why
wasn't this raised way earlier?
was (Author: michael-o):
The current code will lead to a {{ClassCastException}}, right?
> Actual argument type 'HashSet' is incompatible with expected
> argument type 'MavenProject'.
>
>
> Key: MNG-6370
> URL: https://issues.apache.org/jira/browse/MNG-6370
> Project: Maven
> Issue Type: Bug
>Reporter: Sylwester Lachiewicz
>Priority: Trivial
>
> Fix _ConcurrencyDependencyGraph.getUnfinishedProjects_
> {code:java}
> private final HashSet finishedProjects = new HashSet<>();
> /**
> * @return set of projects that have yet to be processed successfully by the
> build.
> */
> public Set getUnfinishedProjects()
> {
> Set unfinished = new HashSet<>( projectBuilds.getProjects() );
> unfinished.remove( finishedProjects );
> return unfinished;
> }{code}
> replace _remove()_ with _removeAll()_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MRESOLVER-35) Move dependency collector and friends to subpackage in maven-resolver-impl
[ https://issues.apache.org/jira/browse/MRESOLVER-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MRESOLVER-35: Summary: Move dependency collector and friends to subpackage in maven-resolver-impl (was: maven-resolver-impl move dependency collector and friends to subpackage) > Move dependency collector and friends to subpackage in maven-resolver-impl > -- > > Key: MRESOLVER-35 > URL: https://issues.apache.org/jira/browse/MRESOLVER-35 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Affects Versions: Maven Artifact Resolver 1.1.1 >Reporter: Sylwester Lachiewicz >Assignee: Michael Osipov >Priority: Minor > Fix For: Maven Artifact Resolver 1.1.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MRESOLVER-35) maven-resolver-impl move dependency collector and friends to subpackage
[ https://issues.apache.org/jira/browse/MRESOLVER-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MRESOLVER-35: Fix Version/s: Maven Artifact Resolver 1.1.2 > maven-resolver-impl move dependency collector and friends to subpackage > --- > > Key: MRESOLVER-35 > URL: https://issues.apache.org/jira/browse/MRESOLVER-35 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Affects Versions: Maven Artifact Resolver 1.1.1 >Reporter: Sylwester Lachiewicz >Assignee: Michael Osipov >Priority: Minor > Fix For: Maven Artifact Resolver 1.1.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MRESOLVER-35) maven-resolver-impl move dependency collector and friends to subpackage
[ https://issues.apache.org/jira/browse/MRESOLVER-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MRESOLVER-35: --- Assignee: Michael Osipov > maven-resolver-impl move dependency collector and friends to subpackage > --- > > Key: MRESOLVER-35 > URL: https://issues.apache.org/jira/browse/MRESOLVER-35 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Affects Versions: Maven Artifact Resolver 1.1.1 >Reporter: Sylwester Lachiewicz >Assignee: Michael Osipov >Priority: Minor > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MRESOLVER-35) maven-resolver-impl move dependency collector and friends to subpackage
[ https://issues.apache.org/jira/browse/MRESOLVER-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MRESOLVER-35: Component/s: resolver > maven-resolver-impl move dependency collector and friends to subpackage > --- > > Key: MRESOLVER-35 > URL: https://issues.apache.org/jira/browse/MRESOLVER-35 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Affects Versions: Maven Artifact Resolver 1.1.1 >Reporter: Sylwester Lachiewicz >Assignee: Michael Osipov >Priority: Minor > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MRESOLVER-35) maven-resolver-impl move dependency collector and friends to subpackage
[ https://issues.apache.org/jira/browse/MRESOLVER-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MRESOLVER-35: Affects Version/s: Maven Artifact Resolver 1.1.1 > maven-resolver-impl move dependency collector and friends to subpackage > --- > > Key: MRESOLVER-35 > URL: https://issues.apache.org/jira/browse/MRESOLVER-35 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Affects Versions: Maven Artifact Resolver 1.1.1 >Reporter: Sylwester Lachiewicz >Assignee: Michael Osipov >Priority: Minor > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6370) Actual argument type 'HashSet' is incompatible with expected argument type 'MavenProject'.
[
https://issues.apache.org/jira/browse/MNG-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386788#comment-16386788
]
ASF GitHub Bot commented on MNG-6370:
-
GitHub user slachiewicz opened a pull request:
https://github.com/apache/maven/pull/161
[MNG-6370] Fix typo in list filtering ConcurrencyDependencyGraph.getU…
…nfinishedProjects
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/slachiewicz/maven fix/MNG-6370
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/maven/pull/161.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #161
commit 683504fdcd0d901a06c9b49463175d9076299925
Author: Sylwester Lachiewicz
Date: 2018-03-05T21:24:14Z
[MNG-6370] Fix typo in list filtering
ConcurrencyDependencyGraph.getUnfinishedProjects
> Actual argument type 'HashSet' is incompatible with expected
> argument type 'MavenProject'.
>
>
> Key: MNG-6370
> URL: https://issues.apache.org/jira/browse/MNG-6370
> Project: Maven
> Issue Type: Bug
>Reporter: Sylwester Lachiewicz
>Priority: Trivial
>
> Fix _ConcurrencyDependencyGraph.getUnfinishedProjects_
> {code:java}
> private final HashSet finishedProjects = new HashSet<>();
> /**
> * @return set of projects that have yet to be processed successfully by the
> build.
> */
> public Set getUnfinishedProjects()
> {
> Set unfinished = new HashSet<>( projectBuilds.getProjects() );
> unfinished.remove( finishedProjects );
> return unfinished;
> }{code}
> replace _remove()_ with _removeAll()_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6370) Actual argument type 'HashSet' is incompatible with expected argument type 'MavenProject'.
Sylwester Lachiewicz created MNG-6370:
-
Summary: Actual argument type 'HashSet' is
incompatible with expected argument type 'MavenProject'.
Key: MNG-6370
URL: https://issues.apache.org/jira/browse/MNG-6370
Project: Maven
Issue Type: Bug
Reporter: Sylwester Lachiewicz
Fix _ConcurrencyDependencyGraph.getUnfinishedProjects_
{code:java}
private final HashSet finishedProjects = new HashSet<>();
/**
* @return set of projects that have yet to be processed successfully by the
build.
*/
public Set getUnfinishedProjects()
{
Set unfinished = new HashSet<>( projectBuilds.getProjects() );
unfinished.remove( finishedProjects );
return unfinished;
}{code}
replace _remove()_ with _removeAll()_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MENFORCER-298) bannedDependencies can break compilation against a timestamped snapshot
[
https://issues.apache.org/jira/browse/MENFORCER-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386743#comment-16386743
]
Jesse Glick commented on MENFORCER-298:
---
It is possible that my patch is also effective against MENFORCER-168 though I
did not check it.
> bannedDependencies can break compilation against a timestamped snapshot
> ---
>
> Key: MENFORCER-298
> URL: https://issues.apache.org/jira/browse/MENFORCER-298
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0, 3.0.0-M1
>Reporter: Jesse Glick
>Priority: Critical
>
> While working heavily with timestamped snapshots across repositories
> (reactors) I found occasional build errors suggesting that
> {{maven-compiler-plugin}} was picking up the wrong version of a dependency.
> To reproduce, using say Maven 3.5.2:
> {code:none}
> git clone https://github.com/jenkinsci/jenkins
> cd jenkins
> git checkout e2c1ae15a3bc6a9e1dcde0bc139b34d2c5812214
> mvn -DskipTests -am -pl core clean install
> {code}
> Compilation will fail with some errors like
> {code:none}
> [ERROR]
> .../jenkins/core/src/main/java/jenkins/security/ClassFilterImpl.java:[77,19]
> error: cannot find symbol
> [ERROR] symbol: method setDefault(ClassFilterImpl)
> [ERROR] location: class ClassFilter
> {code}
> What is going on here is that [the artifact
> repository|http://repo.jenkins-ci.org/public/org/jenkins-ci/main/remoting/3.15-SNAPSHOT/]
> contains various timestamped snapshots for this base version of
> {{remoting}}. The {{jenkins}} commit requests the {{-3}} snapshot in its
> {{pom.xml}}; the newest currently available is {{-10}}, which represents an
> unrelated branch. The compiler error happens when
> {{jenkins/core/src/main/java/}} is compiled against the {{-10}} artifact.
> Now {{MavenITmng4189UniqueVersionSnapshotTest}} in
> {{maven-integration-testing}} verifies that the compiler classpath in such
> cases is correct, and in fact you can patch the IT to actually run the
> compiler and it will work as expected: Maven will copy the requested
> timestamped snapshot artifacts to the corresponding base versions, then
> return those from {{MavenProject.getCompileClasspathElements}}, as [this
> blog|http://blog.sonatype.com/2009/12/maven-dependency-resolution-a-repository-perspective/]
> says it will (without further explanation). Yet it breaks in {{jenkins}}.
> I managed to narrow this down to the fact that {{jenkins}} used the
> {{bannedDependencies}} Enforcer rule. If it uses only, say,
> {{}}, then there is no error. But running {{bannedDependencies}}
> changes the behavior of compilation (even though the {{enforce}} mojo
> passes): the {{-10}} artifacts ({{pom}} and {{jar}}) are downloaded, and the
> base artifacts (esp. {{remoting-3.15-SNAPSHOT.jar}}) are overwritten with the
> {{-10}} versions, not the {{-3}} versions as expected. By patching
> {{BannedDependencies}} I found that this problem occurs iff
> {{buildDependencyGraph}} is called. By adding
> {code}
> System.setSecurityManager( new SecurityManager()
> {
> @Override
> public void checkWrite( String file )
> {
> if ( file.contains( "remoting" ) )
> {
> System.err.println( file );
> Thread.dumpStack();
> }
> }
> @Override
> public void checkPermission( Permission perm )
> {
> }
> }
> );
> {code}
> I found this stack trace:
> {code:none}
> at java.io.FileOutputStream.(FileOutputStream.java:200)
> at java.io.FileOutputStream.(FileOutputStream.java:162)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:166)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:150)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:464)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:329)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:224)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:338)
> at
> org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:202)
> at
> org.apache.maven.shared.dependency.graph.internal.Maven31DependencyGraphBuilder.resolveDependencies(Maven31DependencyGraphBuilder.java:127)
> at
> org.apache.maven.shared.dependency.graph.internal.Maven31DependencyGraphBuilder.buildDependencyGraph(Maven31DependencyGraphBuilder.java:113)
> at
> org.apache.maven.shared.dependency.graph.internal.DefaultDependencyGraphBuilder.buildDependencyGraph(DefaultDepen
[jira] [Commented] (MENFORCER-298) bannedDependencies can break compilation against a timestamped snapshot
[
https://issues.apache.org/jira/browse/MENFORCER-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386733#comment-16386733
]
Jesse Glick commented on MENFORCER-298:
---
I suspect the _best_ fix is to use {{maven-dependency-tree 3.0}}, as tracked in
MENFORCER-277.
> bannedDependencies can break compilation against a timestamped snapshot
> ---
>
> Key: MENFORCER-298
> URL: https://issues.apache.org/jira/browse/MENFORCER-298
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0, 3.0.0-M1
>Reporter: Jesse Glick
>Priority: Critical
>
> While working heavily with timestamped snapshots across repositories
> (reactors) I found occasional build errors suggesting that
> {{maven-compiler-plugin}} was picking up the wrong version of a dependency.
> To reproduce, using say Maven 3.5.2:
> {code:none}
> git clone https://github.com/jenkinsci/jenkins
> cd jenkins
> git checkout e2c1ae15a3bc6a9e1dcde0bc139b34d2c5812214
> mvn -DskipTests -am -pl core clean install
> {code}
> Compilation will fail with some errors like
> {code:none}
> [ERROR]
> .../jenkins/core/src/main/java/jenkins/security/ClassFilterImpl.java:[77,19]
> error: cannot find symbol
> [ERROR] symbol: method setDefault(ClassFilterImpl)
> [ERROR] location: class ClassFilter
> {code}
> What is going on here is that [the artifact
> repository|http://repo.jenkins-ci.org/public/org/jenkins-ci/main/remoting/3.15-SNAPSHOT/]
> contains various timestamped snapshots for this base version of
> {{remoting}}. The {{jenkins}} commit requests the {{-3}} snapshot in its
> {{pom.xml}}; the newest currently available is {{-10}}, which represents an
> unrelated branch. The compiler error happens when
> {{jenkins/core/src/main/java/}} is compiled against the {{-10}} artifact.
> Now {{MavenITmng4189UniqueVersionSnapshotTest}} in
> {{maven-integration-testing}} verifies that the compiler classpath in such
> cases is correct, and in fact you can patch the IT to actually run the
> compiler and it will work as expected: Maven will copy the requested
> timestamped snapshot artifacts to the corresponding base versions, then
> return those from {{MavenProject.getCompileClasspathElements}}, as [this
> blog|http://blog.sonatype.com/2009/12/maven-dependency-resolution-a-repository-perspective/]
> says it will (without further explanation). Yet it breaks in {{jenkins}}.
> I managed to narrow this down to the fact that {{jenkins}} used the
> {{bannedDependencies}} Enforcer rule. If it uses only, say,
> {{}}, then there is no error. But running {{bannedDependencies}}
> changes the behavior of compilation (even though the {{enforce}} mojo
> passes): the {{-10}} artifacts ({{pom}} and {{jar}}) are downloaded, and the
> base artifacts (esp. {{remoting-3.15-SNAPSHOT.jar}}) are overwritten with the
> {{-10}} versions, not the {{-3}} versions as expected. By patching
> {{BannedDependencies}} I found that this problem occurs iff
> {{buildDependencyGraph}} is called. By adding
> {code}
> System.setSecurityManager( new SecurityManager()
> {
> @Override
> public void checkWrite( String file )
> {
> if ( file.contains( "remoting" ) )
> {
> System.err.println( file );
> Thread.dumpStack();
> }
> }
> @Override
> public void checkPermission( Permission perm )
> {
> }
> }
> );
> {code}
> I found this stack trace:
> {code:none}
> at java.io.FileOutputStream.(FileOutputStream.java:200)
> at java.io.FileOutputStream.(FileOutputStream.java:162)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:166)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:150)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:464)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:329)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:224)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:338)
> at
> org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:202)
> at
> org.apache.maven.shared.dependency.graph.internal.Maven31DependencyGraphBuilder.resolveDependencies(Maven31DependencyGraphBuilder.java:127)
> at
> org.apache.maven.shared.dependency.graph.internal.Maven31DependencyGraphBuilder.buildDependencyGraph(Maven31DependencyGraphBuilder.java:113)
> at
> org.apache.maven.shared.dependency.graph.internal.DefaultDependencyGraphBuilder.buildDependencyGraph(DefaultDepend
[jira] [Commented] (MNG-5129) Maven struggles while resolving locked snapshots by two or more simultaneously used projects.
[
https://issues.apache.org/jira/browse/MNG-5129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386730#comment-16386730
]
Jesse Glick commented on MNG-5129:
--
Sounds similar to MNG-4189.
> Maven struggles while resolving locked snapshots by two or more
> simultaneously used projects.
> -
>
> Key: MNG-5129
> URL: https://issues.apache.org/jira/browse/MNG-5129
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.3
>Reporter: Christopher Klewes
>Priority: Blocker
> Attachments: maven-dependency-issue.zip
>
>
> This has to be explained with an easy example. Given that we have three
> projects (A, B and C). Both projects B and C has a dependency to a locked
> snapshot of project A.
> {code:title=Project B requires build number #2}
>
> org.codehaus
> A
> 1.0.0-20110705.132520-2
>
> {code}
> {code:title=Project C requires build number #1}
>
> org.codehaus
> A
> 1.0.0-20110705.132120-1
>
> {code}
> We now call {{dependency:resolve}} on each projects to resolve their
> dependencies from the repositories. As we can see in our local repository
> both versions are fetched and downloaded from their respective repository
> server. Unfortunately a last one wins conflict occurs. The project on which
> {{dependency:resolve}} is called last wins the race. Maven typically copies
> the latest fetched snapshot version (even if it's locked!) to the default
> version. Let's have a look at the folder structure:
> {code:title=Folder listing of the artifact dependency A
> (repository/org/codehaus/A/)}
> maven-metadata-local.xml
> maven-metadata-opensaga.xml
> maven-metadata-opensaga.xml.sha1
> A-1.0.0-20110705.132120-1.jar
> A-1.0.0-20110705.132120-1.pom
> A-1.0.0-20110705.132520-2.jar
> A-1.0.0-20110705.132520-2.pom
>
> A-1.0.0-SNAPSHOT.jar (the last fetched snapshot version)
> A-1.0.0-SNAPSHOT.pom
> {code}
> The last version will be copied to the file {{A-1.0.0-SNAPSHOT.jar}}. Maven
> references their dependencies to the file without the exactt
> timestamp/buildnumber. This fact make it impossible to develop the project B
> and C or even run them simultaneously, because only the last one wins.
> It would be mandatory to exactly reference the file with the timestamp of
> each project!
> What do you think on this issue? I submitted the project structure so you can
> easily reproduce this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MENFORCER-298) bannedDependencies can break compilation against a timestamped snapshot
[
https://issues.apache.org/jira/browse/MENFORCER-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386727#comment-16386727
]
Jesse Glick commented on MENFORCER-298:
---
Filed PR 32 with a simple proposed fix. If this is rejected, I guess the
Jenkins project can deploy its own version of {{bannedDependencies}} as a
workaround.
> bannedDependencies can break compilation against a timestamped snapshot
> ---
>
> Key: MENFORCER-298
> URL: https://issues.apache.org/jira/browse/MENFORCER-298
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0, 3.0.0-M1
>Reporter: Jesse Glick
>Priority: Critical
>
> While working heavily with timestamped snapshots across repositories
> (reactors) I found occasional build errors suggesting that
> {{maven-compiler-plugin}} was picking up the wrong version of a dependency.
> To reproduce, using say Maven 3.5.2:
> {code:none}
> git clone https://github.com/jenkinsci/jenkins
> cd jenkins
> git checkout e2c1ae15a3bc6a9e1dcde0bc139b34d2c5812214
> mvn -DskipTests -am -pl core clean install
> {code}
> Compilation will fail with some errors like
> {code:none}
> [ERROR]
> .../jenkins/core/src/main/java/jenkins/security/ClassFilterImpl.java:[77,19]
> error: cannot find symbol
> [ERROR] symbol: method setDefault(ClassFilterImpl)
> [ERROR] location: class ClassFilter
> {code}
> What is going on here is that [the artifact
> repository|http://repo.jenkins-ci.org/public/org/jenkins-ci/main/remoting/3.15-SNAPSHOT/]
> contains various timestamped snapshots for this base version of
> {{remoting}}. The {{jenkins}} commit requests the {{-3}} snapshot in its
> {{pom.xml}}; the newest currently available is {{-10}}, which represents an
> unrelated branch. The compiler error happens when
> {{jenkins/core/src/main/java/}} is compiled against the {{-10}} artifact.
> Now {{MavenITmng4189UniqueVersionSnapshotTest}} in
> {{maven-integration-testing}} verifies that the compiler classpath in such
> cases is correct, and in fact you can patch the IT to actually run the
> compiler and it will work as expected: Maven will copy the requested
> timestamped snapshot artifacts to the corresponding base versions, then
> return those from {{MavenProject.getCompileClasspathElements}}, as [this
> blog|http://blog.sonatype.com/2009/12/maven-dependency-resolution-a-repository-perspective/]
> says it will (without further explanation). Yet it breaks in {{jenkins}}.
> I managed to narrow this down to the fact that {{jenkins}} used the
> {{bannedDependencies}} Enforcer rule. If it uses only, say,
> {{}}, then there is no error. But running {{bannedDependencies}}
> changes the behavior of compilation (even though the {{enforce}} mojo
> passes): the {{-10}} artifacts ({{pom}} and {{jar}}) are downloaded, and the
> base artifacts (esp. {{remoting-3.15-SNAPSHOT.jar}}) are overwritten with the
> {{-10}} versions, not the {{-3}} versions as expected. By patching
> {{BannedDependencies}} I found that this problem occurs iff
> {{buildDependencyGraph}} is called. By adding
> {code}
> System.setSecurityManager( new SecurityManager()
> {
> @Override
> public void checkWrite( String file )
> {
> if ( file.contains( "remoting" ) )
> {
> System.err.println( file );
> Thread.dumpStack();
> }
> }
> @Override
> public void checkPermission( Permission perm )
> {
> }
> }
> );
> {code}
> I found this stack trace:
> {code:none}
> at java.io.FileOutputStream.(FileOutputStream.java:200)
> at java.io.FileOutputStream.(FileOutputStream.java:162)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:166)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:150)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:464)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:329)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:224)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:338)
> at
> org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:202)
> at
> org.apache.maven.shared.dependency.graph.internal.Maven31DependencyGraphBuilder.resolveDependencies(Maven31DependencyGraphBuilder.java:127)
> at
> org.apache.maven.shared.dependency.graph.internal.Maven31DependencyGraphBuilder.buildDependencyGraph(Maven31DependencyGraphBuilder.java:113)
> at
> org.apache.maven.shared.dependency.graph.internal
[jira] [Commented] (MRELEASE-1005) Extract ResourceGenerator from ReleasePhase
[
https://issues.apache.org/jira/browse/MRELEASE-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386726#comment-16386726
]
Hudson commented on MRELEASE-1005:
--
Build succeeded in Jenkins: Maven TLP » maven-release » master #39
See https://builds.apache.org/job/maven-box/job/maven-release/job/master/39/
> Extract ResourceGenerator from ReleasePhase
> ---
>
> Key: MRELEASE-1005
> URL: https://issues.apache.org/jira/browse/MRELEASE-1005
> Project: Maven Release Plugin
> Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.0.0
>
>
> The {{ReleasePhase}} has a clean-method, which is only useful in cases files
> are generated and which should be cleaned up afterwards. Better to put this
> in a separate interface.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MENFORCER-298) bannedDependencies can break compilation against a timestamped snapshot
[
https://issues.apache.org/jira/browse/MENFORCER-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386720#comment-16386720
]
ASF GitHub Bot commented on MENFORCER-298:
--
jglick opened a new pull request #32: [MENFORCER-298] Ensure bannedDependencies
does not corrupt the classpath when using timestamped snapshots
URL: https://github.com/apache/maven-enforcer/pull/32
See background in
[MENFORCER-298](https://issues.apache.org/jira/browse/MENFORCER-298).
This patch is confirmed to fix the problem on the originally discovered test
case. It does not purport to fix problems when using
```xml
false
```
nor with other calls to `buildDependencyGraph`, notably from
`banTransitiveDependencies` or `banCircularDependencies` in
`extra-enforcer-rules`. Those _might_ be fixable using
`MavenProject.getDependencyArtifacts` and/or `Artifact.getDependencyTrail`.
I attempted to write an IT to reproduce the bug but failed:
`mrm-maven-plugin` refused to serve the snapshot JAR artifacts needed for my
test even though I tried placing them, along with POMs and
`maven-metadata.xml`, in `maven-enforcer-plugin/src/it/mrm/repository/` using
* a flat directory structure, as in current ITs in this repo
* an unpacked JAR format-2 layout as the [mrm documentation seems to
suggest](http://www.mojohaus.org/mrm/mrm-maven-plugin/examples/invoker-tests.html)
* same, but with prepacked JARs, as `maven-integration-testing` does
I just copied the basic test setup from
`MavenITmng4189UniqueVersionSnapshotTest` with minor modifications. If anyone
is interested I can file a PR showing my attempt.
@stephenc suggested that my simple call to `MavenProject.getArtifacts` might
have some undesirable side effects relating to overeager download of
dependencies. Whatever the case, my patch does not regress any of the existing
unit or integration tests.
@reviewbybees for my colleagues
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> bannedDependencies can break compilation against a timestamped snapshot
> ---
>
> Key: MENFORCER-298
> URL: https://issues.apache.org/jira/browse/MENFORCER-298
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0, 3.0.0-M1
>Reporter: Jesse Glick
>Priority: Critical
>
> While working heavily with timestamped snapshots across repositories
> (reactors) I found occasional build errors suggesting that
> {{maven-compiler-plugin}} was picking up the wrong version of a dependency.
> To reproduce, using say Maven 3.5.2:
> {code:none}
> git clone https://github.com/jenkinsci/jenkins
> cd jenkins
> git checkout e2c1ae15a3bc6a9e1dcde0bc139b34d2c5812214
> mvn -DskipTests -am -pl core clean install
> {code}
> Compilation will fail with some errors like
> {code:none}
> [ERROR]
> .../jenkins/core/src/main/java/jenkins/security/ClassFilterImpl.java:[77,19]
> error: cannot find symbol
> [ERROR] symbol: method setDefault(ClassFilterImpl)
> [ERROR] location: class ClassFilter
> {code}
> What is going on here is that [the artifact
> repository|http://repo.jenkins-ci.org/public/org/jenkins-ci/main/remoting/3.15-SNAPSHOT/]
> contains various timestamped snapshots for this base version of
> {{remoting}}. The {{jenkins}} commit requests the {{-3}} snapshot in its
> {{pom.xml}}; the newest currently available is {{-10}}, which represents an
> unrelated branch. The compiler error happens when
> {{jenkins/core/src/main/java/}} is compiled against the {{-10}} artifact.
> Now {{MavenITmng4189UniqueVersionSnapshotTest}} in
> {{maven-integration-testing}} verifies that the compiler classpath in such
> cases is correct, and in fact you can patch the IT to actually run the
> compiler and it will work as expected: Maven will copy the requested
> timestamped snapshot artifacts to the corresponding base versions, then
> return those from {{MavenProject.getCompileClasspathElements}}, as [this
> blog|http://blog.sonatype.com/2009/12/maven-dependency-resolution-a-repository-perspective/]
> says it will (without further explanation). Yet it breaks in {{jenkins}}.
> I managed to narrow this down to the fact that {{jenkins}} used the
> {{bannedDependencies}} Enforcer rule. If it uses only, say,
> {{}}, then there is no error. But running {{bannedDependencies}}
> changes the behavior of compilation (even though the {{enforce}} mojo
> passes): the {{-10}} artifacts ({{pom}} and {{jar}}) are down
[jira] [Commented] (MENFORCER-298) bannedDependencies can break compilation against a timestamped snapshot
[
https://issues.apache.org/jira/browse/MENFORCER-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386722#comment-16386722
]
ASF GitHub Bot commented on MENFORCER-298:
--
jglick commented on a change in pull request #32: [MENFORCER-298] Ensure
bannedDependencies does not corrupt the classpath when using timestamped
snapshots
URL: https://github.com/apache/maven-enforcer/pull/32#discussion_r172319530
##
File path:
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java
##
@@ -63,22 +63,25 @@ public void execute( EnforcerRuleHelper helper )
throw new EnforcerRuleException( "Unable to retrieve the
MavenProject: ", eee );
}
-try
Review comment:
Note that [most of the changes are just
reindentation](https://github.com/apache/maven-enforcer/pull/32/files?w=1).
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> bannedDependencies can break compilation against a timestamped snapshot
> ---
>
> Key: MENFORCER-298
> URL: https://issues.apache.org/jira/browse/MENFORCER-298
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0, 3.0.0-M1
>Reporter: Jesse Glick
>Priority: Critical
>
> While working heavily with timestamped snapshots across repositories
> (reactors) I found occasional build errors suggesting that
> {{maven-compiler-plugin}} was picking up the wrong version of a dependency.
> To reproduce, using say Maven 3.5.2:
> {code:none}
> git clone https://github.com/jenkinsci/jenkins
> cd jenkins
> git checkout e2c1ae15a3bc6a9e1dcde0bc139b34d2c5812214
> mvn -DskipTests -am -pl core clean install
> {code}
> Compilation will fail with some errors like
> {code:none}
> [ERROR]
> .../jenkins/core/src/main/java/jenkins/security/ClassFilterImpl.java:[77,19]
> error: cannot find symbol
> [ERROR] symbol: method setDefault(ClassFilterImpl)
> [ERROR] location: class ClassFilter
> {code}
> What is going on here is that [the artifact
> repository|http://repo.jenkins-ci.org/public/org/jenkins-ci/main/remoting/3.15-SNAPSHOT/]
> contains various timestamped snapshots for this base version of
> {{remoting}}. The {{jenkins}} commit requests the {{-3}} snapshot in its
> {{pom.xml}}; the newest currently available is {{-10}}, which represents an
> unrelated branch. The compiler error happens when
> {{jenkins/core/src/main/java/}} is compiled against the {{-10}} artifact.
> Now {{MavenITmng4189UniqueVersionSnapshotTest}} in
> {{maven-integration-testing}} verifies that the compiler classpath in such
> cases is correct, and in fact you can patch the IT to actually run the
> compiler and it will work as expected: Maven will copy the requested
> timestamped snapshot artifacts to the corresponding base versions, then
> return those from {{MavenProject.getCompileClasspathElements}}, as [this
> blog|http://blog.sonatype.com/2009/12/maven-dependency-resolution-a-repository-perspective/]
> says it will (without further explanation). Yet it breaks in {{jenkins}}.
> I managed to narrow this down to the fact that {{jenkins}} used the
> {{bannedDependencies}} Enforcer rule. If it uses only, say,
> {{}}, then there is no error. But running {{bannedDependencies}}
> changes the behavior of compilation (even though the {{enforce}} mojo
> passes): the {{-10}} artifacts ({{pom}} and {{jar}}) are downloaded, and the
> base artifacts (esp. {{remoting-3.15-SNAPSHOT.jar}}) are overwritten with the
> {{-10}} versions, not the {{-3}} versions as expected. By patching
> {{BannedDependencies}} I found that this problem occurs iff
> {{buildDependencyGraph}} is called. By adding
> {code}
> System.setSecurityManager( new SecurityManager()
> {
> @Override
> public void checkWrite( String file )
> {
> if ( file.contains( "remoting" ) )
> {
> System.err.println( file );
> Thread.dumpStack();
> }
> }
> @Override
> public void checkPermission( Permission perm )
> {
> }
> }
> );
> {code}
> I found this stack trace:
> {code:none}
> at java.io.FileOutputStream.(FileOutputStream.java:200)
> at java.io.FileOutputStream.(FileOutputStream.java:162)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:166)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:150)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver
[GitHub] jglick commented on a change in pull request #32: [MENFORCER-298] Ensure bannedDependencies does not corrupt the classpath when using timestamped snapshots
jglick commented on a change in pull request #32: [MENFORCER-298] Ensure bannedDependencies does not corrupt the classpath when using timestamped snapshots URL: https://github.com/apache/maven-enforcer/pull/32#discussion_r172319530 ## File path: enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java ## @@ -63,22 +63,25 @@ public void execute( EnforcerRuleHelper helper ) throw new EnforcerRuleException( "Unable to retrieve the MavenProject: ", eee ); } -try Review comment: Note that [most of the changes are just reindentation](https://github.com/apache/maven-enforcer/pull/32/files?w=1). This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] jglick opened a new pull request #32: [MENFORCER-298] Ensure bannedDependencies does not corrupt the classpath when using timestamped snapshots
jglick opened a new pull request #32: [MENFORCER-298] Ensure bannedDependencies does not corrupt the classpath when using timestamped snapshots URL: https://github.com/apache/maven-enforcer/pull/32 See background in [MENFORCER-298](https://issues.apache.org/jira/browse/MENFORCER-298). This patch is confirmed to fix the problem on the originally discovered test case. It does not purport to fix problems when using ```xml false ``` nor with other calls to `buildDependencyGraph`, notably from `banTransitiveDependencies` or `banCircularDependencies` in `extra-enforcer-rules`. Those _might_ be fixable using `MavenProject.getDependencyArtifacts` and/or `Artifact.getDependencyTrail`. I attempted to write an IT to reproduce the bug but failed: `mrm-maven-plugin` refused to serve the snapshot JAR artifacts needed for my test even though I tried placing them, along with POMs and `maven-metadata.xml`, in `maven-enforcer-plugin/src/it/mrm/repository/` using * a flat directory structure, as in current ITs in this repo * an unpacked JAR format-2 layout as the [mrm documentation seems to suggest](http://www.mojohaus.org/mrm/mrm-maven-plugin/examples/invoker-tests.html) * same, but with prepacked JARs, as `maven-integration-testing` does I just copied the basic test setup from `MavenITmng4189UniqueVersionSnapshotTest` with minor modifications. If anyone is interested I can file a PR showing my attempt. @stephenc suggested that my simple call to `MavenProject.getArtifacts` might have some undesirable side effects relating to overeager download of dependencies. Whatever the case, my patch does not regress any of the existing unit or integration tests. @reviewbybees for my colleagues This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Closed] (MRELEASE-1005) Extract ResourceGenerator from ReleasePhase
[
https://issues.apache.org/jira/browse/MRELEASE-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-1005.
Resolution: Fixed
Fixed in
[e8a43fc9db5126d3d95b71433fd5928e5dfd3f61|https://gitbox.apache.org/repos/asf?p=maven-release.git;a=commit;h=e8a43fc9db5126d3d95b71433fd5928e5dfd3f61]
> Extract ResourceGenerator from ReleasePhase
> ---
>
> Key: MRELEASE-1005
> URL: https://issues.apache.org/jira/browse/MRELEASE-1005
> Project: Maven Release Plugin
> Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.0.0
>
>
> The {{ReleasePhase}} has a clean-method, which is only useful in cases files
> are generated and which should be cleaned up afterwards. Better to put this
> in a separate interface.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MRELEASE-1005) Extract ResourceGenerator from ReleasePhase
Robert Scholte created MRELEASE-1005:
Summary: Extract ResourceGenerator from ReleasePhase
Key: MRELEASE-1005
URL: https://issues.apache.org/jira/browse/MRELEASE-1005
Project: Maven Release Plugin
Issue Type: Improvement
Reporter: Robert Scholte
Assignee: Robert Scholte
Fix For: 3.0.0
The {{ReleasePhase}} has a clean-method, which is only useful in cases files
are generated and which should be cleaned up afterwards. Better to put this in
a separate interface.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MENFORCER-298) bannedDependencies can break compilation against a timestamped snapshot
Jesse Glick created MENFORCER-298:
-
Summary: bannedDependencies can break compilation against a
timestamped snapshot
Key: MENFORCER-298
URL: https://issues.apache.org/jira/browse/MENFORCER-298
Project: Maven Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 3.0.0-M1, 3.0.0
Reporter: Jesse Glick
While working heavily with timestamped snapshots across repositories (reactors)
I found occasional build errors suggesting that {{maven-compiler-plugin}} was
picking up the wrong version of a dependency. To reproduce, using say Maven
3.5.2:
{code:none}
git clone https://github.com/jenkinsci/jenkins
cd jenkins
git checkout e2c1ae15a3bc6a9e1dcde0bc139b34d2c5812214
mvn -DskipTests -am -pl core clean install
{code}
Compilation will fail with some errors like
{code:none}
[ERROR]
.../jenkins/core/src/main/java/jenkins/security/ClassFilterImpl.java:[77,19]
error: cannot find symbol
[ERROR] symbol: method setDefault(ClassFilterImpl)
[ERROR] location: class ClassFilter
{code}
What is going on here is that [the artifact
repository|http://repo.jenkins-ci.org/public/org/jenkins-ci/main/remoting/3.15-SNAPSHOT/]
contains various timestamped snapshots for this base version of {{remoting}}.
The {{jenkins}} commit requests the {{-3}} snapshot in its {{pom.xml}}; the
newest currently available is {{-10}}, which represents an unrelated branch.
The compiler error happens when {{jenkins/core/src/main/java/}} is compiled
against the {{-10}} artifact.
Now {{MavenITmng4189UniqueVersionSnapshotTest}} in
{{maven-integration-testing}} verifies that the compiler classpath in such
cases is correct, and in fact you can patch the IT to actually run the compiler
and it will work as expected: Maven will copy the requested timestamped
snapshot artifacts to the corresponding base versions, then return those from
{{MavenProject.getCompileClasspathElements}}, as [this
blog|http://blog.sonatype.com/2009/12/maven-dependency-resolution-a-repository-perspective/]
says it will (without further explanation). Yet it breaks in {{jenkins}}.
I managed to narrow this down to the fact that {{jenkins}} used the
{{bannedDependencies}} Enforcer rule. If it uses only, say, {{}},
then there is no error. But running {{bannedDependencies}} changes the behavior
of compilation (even though the {{enforce}} mojo passes): the {{-10}} artifacts
({{pom}} and {{jar}}) are downloaded, and the base artifacts (esp.
{{remoting-3.15-SNAPSHOT.jar}}) are overwritten with the {{-10}} versions, not
the {{-3}} versions as expected. By patching {{BannedDependencies}} I found
that this problem occurs iff {{buildDependencyGraph}} is called. By adding
{code}
System.setSecurityManager( new SecurityManager()
{
@Override
public void checkWrite( String file )
{
if ( file.contains( "remoting" ) )
{
System.err.println( file );
Thread.dumpStack();
}
}
@Override
public void checkPermission( Permission perm )
{
}
}
);
{code}
I found this stack trace:
{code:none}
at java.io.FileOutputStream.(FileOutputStream.java:200)
at java.io.FileOutputStream.(FileOutputStream.java:162)
at
org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:166)
at
org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:150)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:464)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:329)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:224)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:338)
at
org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:202)
at
org.apache.maven.shared.dependency.graph.internal.Maven31DependencyGraphBuilder.resolveDependencies(Maven31DependencyGraphBuilder.java:127)
at
org.apache.maven.shared.dependency.graph.internal.Maven31DependencyGraphBuilder.buildDependencyGraph(Maven31DependencyGraphBuilder.java:113)
at
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyGraphBuilder.buildDependencyGraph(DefaultDependencyGraphBuilder.java:91)
at
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyGraphBuilder.buildDependencyGraph(DefaultDependencyGraphBuilder.java:66)
{code}
And passing {{-Daether.artifactResolver.snapshotNormalization=false}} resolves
the issue.
CC [~stephenc] who reviewed this strange misbehavior with me.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MENFORCER-244) Scoping and BannedDependencies
[ https://issues.apache.org/jira/browse/MENFORCER-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386668#comment-16386668 ] Jesse Glick commented on MENFORCER-244: --- I think you [can already do this|https://github.com/jenkinsci/jenkins/commit/a6485510be07ef06639d7b193a9a0d119effc3be]. > Scoping and BannedDependencies > -- > > Key: MENFORCER-244 > URL: https://issues.apache.org/jira/browse/MENFORCER-244 > Project: Maven Enforcer Plugin > Issue Type: Improvement >Reporter: Nick Cross >Priority: Major > > Currently > https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html has > an option to ignore transitive dependencies. It would be quite useful to also > have an option to ignore test scoped dependencies. The use-case is that, > while we might care that for a runtime project we don't use certain > dependencies, using them during testing is acceptable. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSITE-812) Missing '/' in log when deploying documentation by site:stage
[
https://issues.apache.org/jira/browse/MSITE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386661#comment-16386661
]
ASF GitHub Bot commented on MSITE-812:
--
aajisaka opened a new pull request #1: [MSITE-812] Missing '/' in log when
deploying documentation by site:stage
URL: https://github.com/apache/maven-site-plugin/pull/1
Detail: https://issues.apache.org/jira/browse/MSITE-812
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Missing '/' in log when deploying documentation by site:stage
> -
>
> Key: MSITE-812
> URL: https://issues.apache.org/jira/browse/MSITE-812
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: site:stage(-deploy)
>Affects Versions: 3.7
>Reporter: Akira Ajisaka
>Priority: Major
>
> When running {{mvn site:stage -DstagingDirectory=/Users/ajisaka/YARN-7736}}
> {noformat}
> [INFO]
>
> [INFO] Building Apache Hadoop Project POM 3.2.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-site-plugin:3.7:stage (default-cli) @ hadoop-project ---
> [INFO] Using this base directory for staging: /Users/ajisaka/YARN-7736
> [INFO] Pushing /Users/ajisaka/git/hadoop/hadoop-project/target/site
> [INFO]>>> to file:///Users/ajisaka/YARN-7736hadoop-project
> {noformat}
> '/' is missing between YARN-7736 and hadoop-project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MSITE-812) Missing '/' in log when deploying documentation by site:stage
Akira Ajisaka created MSITE-812:
---
Summary: Missing '/' in log when deploying documentation by
site:stage
Key: MSITE-812
URL: https://issues.apache.org/jira/browse/MSITE-812
Project: Maven Site Plugin
Issue Type: Bug
Components: site:stage(-deploy)
Affects Versions: 3.7
Reporter: Akira Ajisaka
When running {{mvn site:stage -DstagingDirectory=/Users/ajisaka/YARN-7736}}
{noformat}
[INFO]
[INFO] Building Apache Hadoop Project POM 3.2.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-site-plugin:3.7:stage (default-cli) @ hadoop-project ---
[INFO] Using this base directory for staging: /Users/ajisaka/YARN-7736
[INFO] Pushing /Users/ajisaka/git/hadoop/hadoop-project/target/site
[INFO]>>> to file:///Users/ajisaka/YARN-7736hadoop-project
{noformat}
'/' is missing between YARN-7736 and hadoop-project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MRESOLVER-42) Use pre-compiled pattern in DefaultArtifact constructor
[ https://issues.apache.org/jira/browse/MRESOLVER-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MRESOLVER-42. --- Resolution: Fixed Fixed with [90dfc9c00470d2469013e0c76681832360d4d7f1|https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=90dfc9c00470d2469013e0c76681832360d4d7f1]. > Use pre-compiled pattern in DefaultArtifact constructor > --- > > Key: MRESOLVER-42 > URL: https://issues.apache.org/jira/browse/MRESOLVER-42 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Affects Versions: Maven Artifact Resolver 1.0.3, Maven Artifact Resolver > 1.1.0 >Reporter: Robert Varga >Assignee: Michael Osipov >Priority: Major > Fix For: Maven Artifact Resolver 1.1.2 > > > DefaultArtifact(String) always compiles the coordinate matching pattern. This > leads to sub-optimal performance when this constructor is used. > The pattern being matched should be a constant, so that we instantiate only a > matcher, which is fast compared to Pattern.compile(String). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MRESOLVER-42) Use pre-compiled pattern in DefaultArtifact constructor
[ https://issues.apache.org/jira/browse/MRESOLVER-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MRESOLVER-42: Fix Version/s: Maven Artifact Resolver 1.1.2 > Use pre-compiled pattern in DefaultArtifact constructor > --- > > Key: MRESOLVER-42 > URL: https://issues.apache.org/jira/browse/MRESOLVER-42 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Affects Versions: Maven Artifact Resolver 1.0.3, Maven Artifact Resolver > 1.1.0 >Reporter: Robert Varga >Assignee: Michael Osipov >Priority: Major > Fix For: Maven Artifact Resolver 1.1.2 > > > DefaultArtifact(String) always compiles the coordinate matching pattern. This > leads to sub-optimal performance when this constructor is used. > The pattern being matched should be a constant, so that we instantiate only a > matcher, which is fast compared to Pattern.compile(String). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MRELEASE-1004) preparationGoals scm:checkin goal comma separated list does not work
[
https://issues.apache.org/jira/browse/MRELEASE-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-1004:
-
Description:
I am specifying an array of files to be committed before the release plugin
commits poms.
{code:xml}
org.apache.maven.plugins
maven-release-plugin
2.5.4
clean verify scm:checkin -Dmessage="[maven-release-plugin] Update version
text" -Dincludes="tool-plugins/vscode/package.json,
tool-plugins/vscode/package-lock.json"
{code}
But this ends up commiting all the files including the poms, not just
{{package.json}} and {{package-lock.json}}. When its just one file instead of a
comma seperated list it works (just commits the specified file)
{{scm:checkin}} goal with above arguments works when specified directly. It
only does not work when specified in {{preparationGoals}}.
was:
I am specifying an array of files to be committed before the release plugin
commits poms.
org.apache.maven.plugins
maven-release-plugin
2.5.4
clean verify scm:checkin -Dmessage="[maven-release-plugin] Update version text"
-Dincludes="tool-plugins/vscode/package.json,
tool-plugins/vscode/package-lock.json"
But this ends up commiting all the files including the poms, not just
package.json and package-lock.json. When its just one file instead of a comma
seperated list it works (just commits the specified file)
scm:checkin goal with above arguments works when specified directly. It only
does not work when specified in preparationGoals.
> preparationGoals scm:checkin goal comma separated list does not work
>
>
> Key: MRELEASE-1004
> URL: https://issues.apache.org/jira/browse/MRELEASE-1004
> Project: Maven Release Plugin
> Issue Type: Bug
>Reporter: HMAB Herath
>Priority: Major
>
> I am specifying an array of files to be committed before the release plugin
> commits poms.
> {code:xml}
>
>org.apache.maven.plugins
>maven-release-plugin
>2.5.4
>
>
> clean verify scm:checkin -Dmessage="[maven-release-plugin] Update version
> text" -Dincludes="tool-plugins/vscode/package.json,
> tool-plugins/vscode/package-lock.json"
>
>
>
> {code}
> But this ends up commiting all the files including the poms, not just
> {{package.json}} and {{package-lock.json}}. When its just one file instead of
> a comma seperated list it works (just commits the specified file)
>
> {{scm:checkin}} goal with above arguments works when specified directly. It
> only does not work when specified in {{preparationGoals}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MRESOLVER-42) Use pre-compiled pattern in DefaultArtifact constructor
[ https://issues.apache.org/jira/browse/MRESOLVER-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MRESOLVER-42: --- Assignee: Michael Osipov > Use pre-compiled pattern in DefaultArtifact constructor > --- > > Key: MRESOLVER-42 > URL: https://issues.apache.org/jira/browse/MRESOLVER-42 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Affects Versions: Maven Artifact Resolver 1.0.3, Maven Artifact Resolver > 1.1.0 >Reporter: Robert Varga >Assignee: Michael Osipov >Priority: Major > > DefaultArtifact(String) always compiles the coordinate matching pattern. This > leads to sub-optimal performance when this constructor is used. > The pattern being matched should be a constant, so that we instantiate only a > matcher, which is fast compared to Pattern.compile(String). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MRESOLVER-42) Use pre-compiled pattern in DefaultArtifact constructor
[ https://issues.apache.org/jira/browse/MRESOLVER-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MRESOLVER-42: Summary: Use pre-compiled pattern in DefaultArtifact constructor (was: DefaultArtifact(String) is inefficient) > Use pre-compiled pattern in DefaultArtifact constructor > --- > > Key: MRESOLVER-42 > URL: https://issues.apache.org/jira/browse/MRESOLVER-42 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Affects Versions: Maven Artifact Resolver 1.0.3, Maven Artifact Resolver > 1.1.0 >Reporter: Robert Varga >Priority: Major > > DefaultArtifact(String) always compiles the coordinate matching pattern. This > leads to sub-optimal performance when this constructor is used. > The pattern being matched should be a constant, so that we instantiate only a > matcher, which is fast compared to Pattern.compile(String). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MRESOLVER-43) Enhancements to the public API to add support for tracking various informational declaration source hints.
[ https://issues.apache.org/jira/browse/MRESOLVER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386552#comment-16386552 ] Michael Osipov edited comment on MRESOLVER-43 at 3/5/18 6:59 PM: - Can you provide the very same snippet for the current implemenation? How would this implace Maven Core codewise? was (Author: michael-o): Can you provide the very same snippet for the current implemenation? > Enhancements to the public API to add support for tracking various > informational declaration source hints. > -- > > Key: MRESOLVER-43 > URL: https://issues.apache.org/jira/browse/MRESOLVER-43 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Minor > Attachments: example.log > > > The Maven Core uses various Maven Resolver API DependencyVisitor > implementations to provide debug level messages displaying final resolution > results provided by the Maven Resolver. In order to decouple those debug > messages from Maven Resolver internal implementation details, the Maven > Resolver API needs to be enhanced to provide more information like > informational hints to declaration sources. Please see the example log file > about how the final debug messages provided by Maven Core could look like. > All this information is provided by Maven Resolver without Maven Core having > any knowledge about Maven Resolver implementation internals any more. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MRESOLVER-43) Enhancements to the public API to add support for tracking various informational declaration source hints.
[ https://issues.apache.org/jira/browse/MRESOLVER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386552#comment-16386552 ] Michael Osipov commented on MRESOLVER-43: - Can you provide the very same snippet for the current implemenation? > Enhancements to the public API to add support for tracking various > informational declaration source hints. > -- > > Key: MRESOLVER-43 > URL: https://issues.apache.org/jira/browse/MRESOLVER-43 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Minor > Attachments: example.log > > > The Maven Core uses various Maven Resolver API DependencyVisitor > implementations to provide debug level messages displaying final resolution > results provided by the Maven Resolver. In order to decouple those debug > messages from Maven Resolver internal implementation details, the Maven > Resolver API needs to be enhanced to provide more information like > informational hints to declaration sources. Please see the example log file > about how the final debug messages provided by Maven Core could look like. > All this information is provided by Maven Resolver without Maven Core having > any knowledge about Maven Resolver implementation internals any more. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MPIR-345) Upgrade to Doxia 1.7
[ https://issues.apache.org/jira/browse/MPIR-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386525#comment-16386525 ] Michael Osipov commented on MPIR-345: - Try! I didn't have the time to investigate the failures. I'd be very grateful if you could handle that. > Upgrade to Doxia 1.7 > > > Key: MPIR-345 > URL: https://issues.apache.org/jira/browse/MPIR-345 > Project: Maven Project Info Reports Plugin > Issue Type: Task >Affects Versions: 2.9 >Reporter: Michael Osipov >Priority: Major > Fix For: 2.10 > > Attachments: 1.7.log, MPIR-345.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MCHANGELOG-144) svn and maven-changelog-plugin results in “The filename, directory name, or volume label syntax is incorrect”
[
https://issues.apache.org/jira/browse/MCHANGELOG-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386505#comment-16386505
]
Michael Osipov commented on MCHANGELOG-144:
---
I think this is a quoting issue. Can you drop the date range and see wether it
works for you?
> svn and maven-changelog-plugin results in “The filename, directory name, or
> volume label syntax is incorrect”
> -
>
> Key: MCHANGELOG-144
> URL: https://issues.apache.org/jira/browse/MCHANGELOG-144
> Project: Maven Changelog Plugin
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: Windows Server 2016
> maven 3.5.2
>Reporter: Adrian Wyssmann
>Priority: Major
>
> We are using maven-changelog-plugin:2.3 to generate the changelog. The job is
> triggered by Jenkins but recently the job starts failing. Here is what I see
> in the log
> {code:java}
> ...
> ...
> 22:05:41 [DEBUG] Multipage report: 0 subreports
> 22:05:41 [DEBUG] Generating
> D:\jenkins\workspace\MAVEN-Company-Project\target\site\changelog.html
> 22:05:41 [INFO] Generating "Change Log" report---
> maven-changelog-plugin:2.3:changelog
> 22:05:41 [INFO] Generating changed sets xml to:
> D:\jenkins\workspace\MAVEN-Company-Project\target\changelog.xml
> 22:05:41 [INFO] Executing: cmd.exe /X /C "svn --username CIUSER --password
> * --no-auth-cache --non-interactive log -v -r "{2018-01-29 21:05:41
> +}:{2018-03-01 21:05:41 +}"
> http://svn.mycompany.intra:80/svn/parentpom/trunk/";
> 22:05:41 [INFO] Working directory: D:\jenkins\workspace\MAVEN-Company-Project
> 22:05:41 [ERROR] Provider message:
> 22:05:41 [ERROR] The svn command failed.
> 22:05:41 [ERROR] Command output:
> 22:05:41 [ERROR] The filename, directory name, or volume label syntax is
> incorrect.
> 22:05:41
> 22:05:41 [INFO]
>
> 22:05:41 [INFO] BUILD FAILURE
> 22:05:41 [INFO]
>
> 22:05:41 [INFO] Total time: 13.994 s
> 22:05:41 [INFO] Finished at: 2018-02-28T22:05:41+01:00
> 22:05:41 [INFO] Final Memory: 43M/451M
> 22:05:41 [INFO]
>
> 22:05:41 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.6:site (default-cli) on project
> mycompany: Error generating maven-changelog-plugin:2.3:changelog: An error
> has occurred during changelog command : : Command failed. -> [Help 1]
> 22:05:41 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-site-plugin:3.6:site
> (default-cli) on project mycompany: Error generating
> maven-changelog-plugin:2.3:changelog: An error has occurred during changelog
> command :
> 22:05:41 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> 22:05:41 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> 22:05:41 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> 22:05:41 at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> 22:05:41 at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> 22:05:41 at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
> 22:05:41 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> ...{code}
> Running the command manually in the workspace directory
> D:\jenkins\workspace\MAVEN-Company-Project\ works without problems.
> The problems occurs in conjunction with maven 3.5.2. When switching back to
> maven 3.1.1 the error does not appear.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6369) fastly.com cdn for https://repo.maven.apache.org/maven2/ hangs for keep-alive http
Frank Ch. Eigler created MNG-6369: - Summary: fastly.com cdn for https://repo.maven.apache.org/maven2/ hangs for keep-alive http Key: MNG-6369 URL: https://issues.apache.org/jira/browse/MNG-6369 Project: Maven Issue Type: Bug Reporter: Frank Ch. Eigler Users with java clients that happen to use https with the "Connection: keep-alive" header to fetch maven content from the fastly.com cdn of your repo are experiencing hung connections. To reproduce, observe hang with: ab -v 2 -H "User-Agent: curl/7.29.0" -c1 -n1 -k [https://repo.maven.apache.org/maven2/] Noting that there is no hang if one uses http:// or drops the -k. Already reported to fastly: [https://fastly.zendesk.com/hc/en-us/requests/73810] but they don't seem to take the issue seriously, coming from me. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MPATCH-20) support exclude pattern
[
https://issues.apache.org/jira/browse/MPATCH-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386216#comment-16386216
]
ASF GitHub Bot commented on MPATCH-20:
--
matthiasbalke opened a new pull request #2: added support for excludePattern
(fixes MPATCH-20)
URL: https://github.com/apache/maven-patch-plugin/pull/2
This PR adds support for the `excludePattern` configuration described in
[MPATCH-20](https://issues.apache.org/jira/browse/MPATCH-20).
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> support exclude pattern
> ---
>
> Key: MPATCH-20
> URL: https://issues.apache.org/jira/browse/MPATCH-20
> Project: Maven Patch Plugin
> Issue Type: New Feature
>Affects Versions: 1.2, 1.3
>Reporter: Matthias Balke
>Priority: Major
>
> The maven-patch-plugin should provide a feature to configure an exclude
> pattern which is applied, when searching for patch files within
> {{patchDirectory}}.
>
> I'll provide a PR on GitHub for this feature.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MPATCH-20) support exclude pattern
[
https://issues.apache.org/jira/browse/MPATCH-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386220#comment-16386220
]
Matthias Balke commented on MPATCH-20:
--
Sorry for opening two PRs. I used the wrong author config before comitting.
> support exclude pattern
> ---
>
> Key: MPATCH-20
> URL: https://issues.apache.org/jira/browse/MPATCH-20
> Project: Maven Patch Plugin
> Issue Type: New Feature
>Affects Versions: 1.2, 1.3
>Reporter: Matthias Balke
>Priority: Major
>
> The maven-patch-plugin should provide a feature to configure an exclude
> pattern which is applied, when searching for patch files within
> {{patchDirectory}}.
>
> I'll provide a PR on GitHub for this feature.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] matthiasbalke opened a new pull request #2: added support for excludePattern (fixes MPATCH-20)
matthiasbalke opened a new pull request #2: added support for excludePattern (fixes MPATCH-20) URL: https://github.com/apache/maven-patch-plugin/pull/2 This PR adds support for the `excludePattern` configuration described in [MPATCH-20](https://issues.apache.org/jira/browse/MPATCH-20). This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MPATCH-20) support exclude pattern
[
https://issues.apache.org/jira/browse/MPATCH-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386214#comment-16386214
]
ASF GitHub Bot commented on MPATCH-20:
--
matthiasbalke closed pull request #1: added support for excludePattern (fixes
MPATCH-20)
URL: https://github.com/apache/maven-patch-plugin/pull/1
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/src/it/cant-exclude-patches-from-patches/pom.xml
b/src/it/cant-exclude-patches-from-patches/pom.xml
new file mode 100644
index 000..e13970e
--- /dev/null
+++ b/src/it/cant-exclude-patches-from-patches/pom.xml
@@ -0,0 +1,67 @@
+
+http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
+ xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
+ 4.0.0
+
+ test
+ cant-exclude-patches-from-patches
+ cant-exclude-patches-from-patches
+ 1.0-SNAPSHOT
+
+
+UTF-8
+
+
+
+
+
+org.apache.maven.plugins
+maven-patch-plugin
+@pom.version@
+
+
+ ${basedir}
+
+ se*.patch
+
+
+first.patch
+second.patch
+
+
+
+
+
+apply-patches
+
+initialize
+
+
+ apply
+
+
+
+
+
+
+
+
+
+
diff --git
a/src/it/cant-exclude-patches-from-patches/src/main/patches/first.patch
b/src/it/cant-exclude-patches-from-patches/src/main/patches/first.patch
new file mode 100644
index 000..5c6f211
--- /dev/null
+++ b/src/it/cant-exclude-patches-from-patches/src/main/patches/first.patch
@@ -0,0 +1,26 @@
+#
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+#http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+#
+Index: target/test.txt
+===
+--- target/test.txt(revision 0)
target/test.txt(revision 0)
+@@ -0,0 +1 @@
++This is a test.
+\ No newline at end of file
+
diff --git
a/src/it/cant-exclude-patches-from-patches/src/main/patches/second.patch
b/src/it/cant-exclude-patches-from-patches/src/main/patches/second.patch
new file mode 100644
index 000..0ae1671
--- /dev/null
+++ b/src/it/cant-exclude-patches-from-patches/src/main/patches/second.patch
@@ -0,0 +1,25 @@
+#
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+#http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+#
+Index: target/test2.txt
+===
+--- target/test2.txt (revision 0)
target/test2.txt (revision 0)
+@@ -0,0 +1 @@
++This is a test.
+
diff --git a/src/it/cant-exclude-patches-from-patches/verify.bsh
b/src/it/cant-exclude-patches-from-patches/verify.bsh
new file mode 100644
index 000..dd3f3b8
--- /dev/null
+++ b/src/it/cant-exclude-patches-from-patches/verify.bsh
@@ -0,0 +1,45 @@
+/*
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"Licens
[GitHub] matthiasbalke closed pull request #1: added support for excludePattern (fixes MPATCH-20)
matthiasbalke closed pull request #1: added support for excludePattern (fixes
MPATCH-20)
URL: https://github.com/apache/maven-patch-plugin/pull/1
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/src/it/cant-exclude-patches-from-patches/pom.xml
b/src/it/cant-exclude-patches-from-patches/pom.xml
new file mode 100644
index 000..e13970e
--- /dev/null
+++ b/src/it/cant-exclude-patches-from-patches/pom.xml
@@ -0,0 +1,67 @@
+
+http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
+ xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
+ 4.0.0
+
+ test
+ cant-exclude-patches-from-patches
+ cant-exclude-patches-from-patches
+ 1.0-SNAPSHOT
+
+
+UTF-8
+
+
+
+
+
+org.apache.maven.plugins
+maven-patch-plugin
+@pom.version@
+
+
+ ${basedir}
+
+ se*.patch
+
+
+first.patch
+second.patch
+
+
+
+
+
+apply-patches
+
+initialize
+
+
+ apply
+
+
+
+
+
+
+
+
+
+
diff --git
a/src/it/cant-exclude-patches-from-patches/src/main/patches/first.patch
b/src/it/cant-exclude-patches-from-patches/src/main/patches/first.patch
new file mode 100644
index 000..5c6f211
--- /dev/null
+++ b/src/it/cant-exclude-patches-from-patches/src/main/patches/first.patch
@@ -0,0 +1,26 @@
+#
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+#http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+#
+Index: target/test.txt
+===
+--- target/test.txt(revision 0)
target/test.txt(revision 0)
+@@ -0,0 +1 @@
++This is a test.
+\ No newline at end of file
+
diff --git
a/src/it/cant-exclude-patches-from-patches/src/main/patches/second.patch
b/src/it/cant-exclude-patches-from-patches/src/main/patches/second.patch
new file mode 100644
index 000..0ae1671
--- /dev/null
+++ b/src/it/cant-exclude-patches-from-patches/src/main/patches/second.patch
@@ -0,0 +1,25 @@
+#
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+#http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+#
+Index: target/test2.txt
+===
+--- target/test2.txt (revision 0)
target/test2.txt (revision 0)
+@@ -0,0 +1 @@
++This is a test.
+
diff --git a/src/it/cant-exclude-patches-from-patches/verify.bsh
b/src/it/cant-exclude-patches-from-patches/verify.bsh
new file mode 100644
index 000..dd3f3b8
--- /dev/null
+++ b/src/it/cant-exclude-patches-from-patches/verify.bsh
@@ -0,0 +1,45 @@
+/*
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+softwa
[jira] [Commented] (MPATCH-20) support exclude pattern
[
https://issues.apache.org/jira/browse/MPATCH-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386211#comment-16386211
]
Matthias Balke commented on MPATCH-20:
--
Opened PR: https://github.com/apache/maven-patch-plugin/pull/1
> support exclude pattern
> ---
>
> Key: MPATCH-20
> URL: https://issues.apache.org/jira/browse/MPATCH-20
> Project: Maven Patch Plugin
> Issue Type: New Feature
>Affects Versions: 1.2, 1.3
>Reporter: Matthias Balke
>Priority: Major
>
> The maven-patch-plugin should provide a feature to configure an exclude
> pattern which is applied, when searching for patch files within
> {{patchDirectory}}.
>
> I'll provide a PR on GitHub for this feature.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MPATCH-20) support exclude pattern
[
https://issues.apache.org/jira/browse/MPATCH-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386210#comment-16386210
]
ASF GitHub Bot commented on MPATCH-20:
--
matthiasbalke opened a new pull request #1: added support for excludePattern
(fixes MPATCH-20)
URL: https://github.com/apache/maven-patch-plugin/pull/1
This PR adds support for the `excludePattern` configuration described in
[MPATCH-20](https://issues.apache.org/jira/browse/MPATCH-20).
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> support exclude pattern
> ---
>
> Key: MPATCH-20
> URL: https://issues.apache.org/jira/browse/MPATCH-20
> Project: Maven Patch Plugin
> Issue Type: New Feature
>Affects Versions: 1.2, 1.3
>Reporter: Matthias Balke
>Priority: Major
>
> The maven-patch-plugin should provide a feature to configure an exclude
> pattern which is applied, when searching for patch files within
> {{patchDirectory}}.
>
> I'll provide a PR on GitHub for this feature.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] matthiasbalke opened a new pull request #1: added support for excludePattern (fixes MPATCH-20)
matthiasbalke opened a new pull request #1: added support for excludePattern (fixes MPATCH-20) URL: https://github.com/apache/maven-patch-plugin/pull/1 This PR adds support for the `excludePattern` configuration described in [MPATCH-20](https://issues.apache.org/jira/browse/MPATCH-20). This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (MPATCH-19) ignored patches must not be applied
[
https://issues.apache.org/jira/browse/MPATCH-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386149#comment-16386149
]
Matthias Balke edited comment on MPATCH-19 at 3/5/18 2:48 PM:
--
It seems, that I'm searching for an {{exludePattern}} configuration, which is
not available yet. The {{ignorePatches}} option is just very misleading. The
documentation should be updated to explain, that this will not exlude patches
found in {{patchDirectory}}.
I filed a feature request MPATCH-20 and will provide a PR for the
{{excludePattern}} support.
was (Author: matthiasbalke):
It seems, that I'm searching for an {{exludePattern}} configuration, which is
not available yet. The {{ignorePatches}} option is just very misleading. The
documentation should be updated to explain, that this will not exlude patches
found in {{patchDirectory}}.
I'll file a feature request and provide a PR for the excludePattern support.
> ignored patches must not be applied
> ---
>
> Key: MPATCH-19
> URL: https://issues.apache.org/jira/browse/MPATCH-19
> Project: Maven Patch Plugin
> Issue Type: Bug
>Affects Versions: 1.2
>Reporter: Matthias Balke
>Priority: Critical
>
> To reproduce this bug one has to configure the maven patch plugin to ignore
> some patches.
> {code:java}
>
> ignored.patch
> {code}
> When executing the plugin the ignored files are also applied! It seems that
> this feature is broken or not well enough documented.
> Also using {{strictPatching}} does not work as documented:
> {code:java}
> true
>
> ignored.patch
> {code}
> I created a minimal example to reproduce this bug:
> https://github.com/matthiasbalke/maven-patch-plugin-MPATCH-19
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MPATCH-20) support exclude pattern
Matthias Balke created MPATCH-20:
Summary: support exclude pattern
Key: MPATCH-20
URL: https://issues.apache.org/jira/browse/MPATCH-20
Project: Maven Patch Plugin
Issue Type: New Feature
Affects Versions: 1.2, 1.3
Reporter: Matthias Balke
The maven-patch-plugin should provide a feature to configure an exclude pattern
which is applied, when searching for patch files within {{patchDirectory}}.
I'll provide a PR on GitHub for this feature.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MPATCH-19) ignored patches must not be applied
[
https://issues.apache.org/jira/browse/MPATCH-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386149#comment-16386149
]
Matthias Balke commented on MPATCH-19:
--
It seems, that I'm searching for an {{exludePattern}} configuration, which is
not available yet. The {{ignorePatches}} option is just very misleading. The
documentation should be updated to explain, that this will not exlude patches
found in {{patchDirectory}}.
I'll file a feature request and provide a PR for the excludePattern support.
> ignored patches must not be applied
> ---
>
> Key: MPATCH-19
> URL: https://issues.apache.org/jira/browse/MPATCH-19
> Project: Maven Patch Plugin
> Issue Type: Bug
>Affects Versions: 1.2
>Reporter: Matthias Balke
>Priority: Critical
>
> To reproduce this bug one has to configure the maven patch plugin to ignore
> some patches.
> {code:java}
>
> ignored.patch
> {code}
> When executing the plugin the ignored files are also applied! It seems that
> this feature is broken or not well enough documented.
> Also using {{strictPatching}} does not work as documented:
> {code:java}
> true
>
> ignored.patch
> {code}
> I created a minimal example to reproduce this bug:
> https://github.com/matthiasbalke/maven-patch-plugin-MPATCH-19
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCHANGELOG-144) svn and maven-changelog-plugin results in “The filename, directory name, or volume label syntax is incorrect”
[
https://issues.apache.org/jira/browse/MCHANGELOG-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385997#comment-16385997
]
Adrian Wyssmann commented on MCHANGELOG-144:
Same issue with 3.5.3 @ [~michael-o]
> svn and maven-changelog-plugin results in “The filename, directory name, or
> volume label syntax is incorrect”
> -
>
> Key: MCHANGELOG-144
> URL: https://issues.apache.org/jira/browse/MCHANGELOG-144
> Project: Maven Changelog Plugin
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: Windows Server 2016
> maven 3.5.2
>Reporter: Adrian Wyssmann
>Priority: Major
>
> We are using maven-changelog-plugin:2.3 to generate the changelog. The job is
> triggered by Jenkins but recently the job starts failing. Here is what I see
> in the log
> {code:java}
> ...
> ...
> 22:05:41 [DEBUG] Multipage report: 0 subreports
> 22:05:41 [DEBUG] Generating
> D:\jenkins\workspace\MAVEN-Company-Project\target\site\changelog.html
> 22:05:41 [INFO] Generating "Change Log" report---
> maven-changelog-plugin:2.3:changelog
> 22:05:41 [INFO] Generating changed sets xml to:
> D:\jenkins\workspace\MAVEN-Company-Project\target\changelog.xml
> 22:05:41 [INFO] Executing: cmd.exe /X /C "svn --username CIUSER --password
> * --no-auth-cache --non-interactive log -v -r "{2018-01-29 21:05:41
> +}:{2018-03-01 21:05:41 +}"
> http://svn.mycompany.intra:80/svn/parentpom/trunk/";
> 22:05:41 [INFO] Working directory: D:\jenkins\workspace\MAVEN-Company-Project
> 22:05:41 [ERROR] Provider message:
> 22:05:41 [ERROR] The svn command failed.
> 22:05:41 [ERROR] Command output:
> 22:05:41 [ERROR] The filename, directory name, or volume label syntax is
> incorrect.
> 22:05:41
> 22:05:41 [INFO]
>
> 22:05:41 [INFO] BUILD FAILURE
> 22:05:41 [INFO]
>
> 22:05:41 [INFO] Total time: 13.994 s
> 22:05:41 [INFO] Finished at: 2018-02-28T22:05:41+01:00
> 22:05:41 [INFO] Final Memory: 43M/451M
> 22:05:41 [INFO]
>
> 22:05:41 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.6:site (default-cli) on project
> mycompany: Error generating maven-changelog-plugin:2.3:changelog: An error
> has occurred during changelog command : : Command failed. -> [Help 1]
> 22:05:41 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-site-plugin:3.6:site
> (default-cli) on project mycompany: Error generating
> maven-changelog-plugin:2.3:changelog: An error has occurred during changelog
> command :
> 22:05:41 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> 22:05:41 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> 22:05:41 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> 22:05:41 at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> 22:05:41 at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> 22:05:41 at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
> 22:05:41 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> ...{code}
> Running the command manually in the workspace directory
> D:\jenkins\workspace\MAVEN-Company-Project\ works without problems.
> The problems occurs in conjunction with maven 3.5.2. When switching back to
> maven 3.1.1 the error does not appear.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRESOLVER-31) OSGi metadata
[ https://issues.apache.org/jira/browse/MRESOLVER-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385954#comment-16385954 ] Mat Booth commented on MRESOLVER-31: I rebased my against latest master. > OSGi metadata > - > > Key: MRESOLVER-31 > URL: https://issues.apache.org/jira/browse/MRESOLVER-31 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Affects Versions: Maven Artifact Resolver 1.1.0 > Environment: all >Reporter: Elliotte Rusty Harold >Priority: Major > > The MANIFEST.MF for the HTTP transport (and I suspect the file transport too > though I haven't popped it open and looked yet) does not have OSGI metadata: > elharo-macbookair99:Downloads elharo$ more META-INF/MANIFEST.MF > Manifest-Version: 1.0 > Implementation-Title: Maven Artifact Resolver Transport HTTP > Implementation-Version: 1.1.0 > Built-By: mosipov > Specification-Vendor: The Apache Software Foundation > Created-By: Apache Maven 3.5.0 > Implementation-URL: https://maven.apache.org/resolver/maven-resolver-t > ransport-http/ > Implementation-Vendor: The Apache Software Foundation > Automatic-Module-Name: org.apache.maven.resolver.transport.http > Implementation-Vendor-Id: org.apache.maven.resolver > Build-Jdk: 1.7.0_121 > Specification-Title: Maven Artifact Resolver Transport HTTP > Specification-Version: 1.1 > Archiver-Version: Plexus Archiver > Adding this would be extremely helpful for anyone who wants to use this in an > Eclipse plugin. E.g. > Bundle-ManifestVersion: 2 > Bundle-Name: org.apache.maven.resolver.transport.http > Bundle-RequiredExecutionEnvironment: J2SE-1.5, J2SE-1.4 > Bundle-SymbolicName: org.apache.maven.resolver.transport.http > Bundle-Vendor: apache.org > Bundle-Version: 1.1.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MRELEASE-1004) preparationGoals scm:checkin goal comma separated list does not work
HMAB Herath created MRELEASE-1004: - Summary: preparationGoals scm:checkin goal comma separated list does not work Key: MRELEASE-1004 URL: https://issues.apache.org/jira/browse/MRELEASE-1004 Project: Maven Release Plugin Issue Type: Bug Reporter: HMAB Herath I am specifying an array of files to be committed before the release plugin commits poms. org.apache.maven.plugins maven-release-plugin 2.5.4 clean verify scm:checkin -Dmessage="[maven-release-plugin] Update version text" -Dincludes="tool-plugins/vscode/package.json, tool-plugins/vscode/package-lock.json" But this ends up commiting all the files including the poms, not just package.json and package-lock.json. When its just one file instead of a comma seperated list it works (just commits the specified file) scm:checkin goal with above arguments works when specified directly. It only does not work when specified in preparationGoals. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MPATCH-19) ignored patches must not be applied
[
https://issues.apache.org/jira/browse/MPATCH-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Balke updated MPATCH-19:
-
Description:
To reproduce this bug one has to configure the maven patch plugin to ignore
some patches.
{code:java}
ignored.patch
{code}
When executing the plugin the ignored files are also applied! It seems that
this feature is broken or not well enough documented.
Also using {{strictPatching}} does not work as documented:
{code:java}
true
ignored.patch
{code}
I created a minimal example to reproduce this bug:
https://github.com/matthiasbalke/maven-patch-plugin-MPATCH-19
was:
To reproduce this bug one has to configure the maven patch plugin to ignore
some patches.
{code:java}
ignored.patch
{code}
When executing the plugin the ignored files are also applied! It seems that
this feature is broken or not well enough documented.
Also using {{strictPatching}} does not work as documented:
{code:java}
true
ignored.patch
{code}
I created a minimal example to reproduce this bug
> ignored patches must not be applied
> ---
>
> Key: MPATCH-19
> URL: https://issues.apache.org/jira/browse/MPATCH-19
> Project: Maven Patch Plugin
> Issue Type: Bug
>Affects Versions: 1.2
>Reporter: Matthias Balke
>Priority: Critical
>
> To reproduce this bug one has to configure the maven patch plugin to ignore
> some patches.
> {code:java}
>
> ignored.patch
> {code}
> When executing the plugin the ignored files are also applied! It seems that
> this feature is broken or not well enough documented.
> Also using {{strictPatching}} does not work as documented:
> {code:java}
> true
>
> ignored.patch
> {code}
> I created a minimal example to reproduce this bug:
> https://github.com/matthiasbalke/maven-patch-plugin-MPATCH-19
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MPATCH-19) ignored patches must not be applied
Matthias Balke created MPATCH-19:
Summary: ignored patches must not be applied
Key: MPATCH-19
URL: https://issues.apache.org/jira/browse/MPATCH-19
Project: Maven Patch Plugin
Issue Type: Bug
Affects Versions: 1.2
Reporter: Matthias Balke
To reproduce this bug one has to configure the maven patch plugin to ignore
some patches.
{code:java}
ignored.patch
{code}
When executing the plugin the ignored files are also applied! It seems that
this feature is broken or not well enough documented.
Also using {{strictPatching}} does not work as documented:
{code:java}
true
ignored.patch
{code}
I created a minimal example to reproduce this bug
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MPATCH-16) maven-patch-plugin fails silent when patch binary is not found
[
https://issues.apache.org/jira/browse/MPATCH-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385885#comment-16385885
]
Matthias Balke commented on MPATCH-16:
--
It seems that this was fixed in version 1.2. I got an exception, that patch is
missing while configuring the maven patch plugin recently.
> maven-patch-plugin fails silent when patch binary is not found
> --
>
> Key: MPATCH-16
> URL: https://issues.apache.org/jira/browse/MPATCH-16
> Project: Maven Patch Plugin
> Issue Type: Bug
>Affects Versions: 1.1.1
>Reporter: Chris Pimlott
>Priority: Major
>
> The {{maven-patch-plugin}} does not throw an error or display any message
> when the GNU {{patch}} binary is not present in the system path. This makes
> it easy to accidentally include an unpatched file in the build artifact that
> may cause undetected subtle errors.
> The plugin should report an error when the binary cannot be found in order to
> cause the build to fail.
> {code}
> PATH=/bin /usr/bin/java -classpath
> /usr/share/maven/boot/plexus-classworlds-2.4.jar
> -Dclassworlds.conf=/usr/share/maven/bin/m2.conf -Dmaven.home=/usr/share/maven
> org.codehaus.plexus.classworlds.launcher.Launcher -o prepare-package
> {code}
> {quote}
> [INFO] --- maven-patch-plugin:1.1.1:apply (patch) @ leo-dist ---
> [INFO]
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
