[jira] [Closed] (MSHARED-560) Support includeNullScope for ArtifactFilter
[
https://issues.apache.org/jira/browse/MSHARED-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MSHARED-560.
--
Resolution: Fixed
Fixed in [r1748774|http://svn.apache.org/viewvc?rev=1748774&view=rev]
> Support includeNullScope for ArtifactFilter
> ---
>
> Key: MSHARED-560
> URL: https://issues.apache.org/jira/browse/MSHARED-560
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-common-artifact-filters
>Affects Versions: maven-common-artifact-filters-3.0.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
> Fix For: maven-common-artifact-filters-3.0.1
>
>
> For the ArtifactIncludeFilter the scope of an Artifact can be used to filter,
> although this can be {{null}}. (With Aether it is not the Artifact but the
> Dependency which has a scope)
> By adding the option {{includeNullScope}} to the ArtifactIncludeTransformer
> is will be possible to filter on null-scoped Artifacts too.
> This should make it easier to migrate to {{TransformableFilter}}s
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MSHARED-560) Support includeNullScope for ArtifactFilter
Robert Scholte created MSHARED-560:
--
Summary: Support includeNullScope for ArtifactFilter
Key: MSHARED-560
URL: https://issues.apache.org/jira/browse/MSHARED-560
Project: Maven Shared Components
Issue Type: Bug
Components: maven-common-artifact-filters
Affects Versions: maven-common-artifact-filters-3.0.0
Reporter: Robert Scholte
Assignee: Robert Scholte
Fix For: maven-common-artifact-filters-3.0.1
For the ArtifactIncludeFilter the scope of an Artifact can be used to filter,
although this can be {{null}}. (With Aether it is not the Artifact but the
Dependency which has a scope)
By adding the option {{includeNullScope}} to the ArtifactIncludeTransformer is
will be possible to filter on null-scoped Artifacts too.
This should make it easier to migrate to {{TransformableFilter}}s
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5227) Make 'optional' flag of a dependency manageable.
[
https://issues.apache.org/jira/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15334439#comment-15334439
]
Hudson commented on MNG-5227:
-
SUCCESS: Integrated in maven-3.x #1309 (See
[https://builds.apache.org/job/maven-3.x/1309/])
[MNG-5227] The 'optional' flag of a dependency should be manageable. (schulte:
rev 09bfdee699443b2482d2427b5eff7226768b340a)
*
maven-model-builder/src/main/java/org/apache/maven/model/management/DefaultDependencyManagementInjector.java
> Make 'optional' flag of a dependency manageable.
>
>
> Key: MNG-5227
> URL: https://issues.apache.org/jira/browse/MNG-5227
> Project: Maven
> Issue Type: New Feature
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
> Attachments: MNG-5227.patch, MNG-5227.patch
>
>
> {code}
>
>
>
> groupId
> artifactId
> version
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MNG-5227) Make 'optional' flag of a dependency manageable.
[
https://issues.apache.org/jira/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte closed MNG-5227.
--
Resolution: Fixed
> Make 'optional' flag of a dependency manageable.
>
>
> Key: MNG-5227
> URL: https://issues.apache.org/jira/browse/MNG-5227
> Project: Maven
> Issue Type: New Feature
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
> Attachments: MNG-5227.patch, MNG-5227.patch
>
>
> {code}
>
>
>
> groupId
> artifactId
> version
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5227) Make 'optional' flag of a dependency manageable.
[
https://issues.apache.org/jira/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MNG-5227:
---
Fix Version/s: (was: 3.5.0)
3.4.0
> Make 'optional' flag of a dependency manageable.
>
>
> Key: MNG-5227
> URL: https://issues.apache.org/jira/browse/MNG-5227
> Project: Maven
> Issue Type: New Feature
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
> Attachments: MNG-5227.patch, MNG-5227.patch
>
>
> {code}
>
>
>
> groupId
> artifactId
> version
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSITE-779) add color to report generation messages
[
https://issues.apache.org/jira/browse/MSITE-779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15334406#comment-15334406
]
Hudson commented on MSITE-779:
--
UNSTABLE: Integrated in maven-plugins #6464 (See
[https://builds.apache.org/job/maven-plugins/6464/])
[MSITE-779] use Maven consistent colors API (hboutemy:
[http://svn.apache.org/viewvc/?view=rev&rev=1748768])
*
maven-site-plugin/src/main/java/org/apache/maven/plugins/site/render/ReportDocumentRenderer.java
> add color to report generation messages
> ---
>
> Key: MSITE-779
> URL: https://issues.apache.org/jira/browse/MSITE-779
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.5.1
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
> Fix For: 3.6
>
>
> with ANSI color support added in MNG-3507, it would be useful to use the same
> color rendering for report generation messages:
> {noformat}[INFO] Generating "Summary" report ---
> maven-project-info-reports-plugin:2.9:summary{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SUREFIRE-951) Better handling of file.encoding system property
[
https://issues.apache.org/jira/browse/SUREFIRE-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15333559#comment-15333559
]
Mark edited comment on SUREFIRE-951 at 6/16/16 10:53 AM:
-
still not working reliably as of surefire 2.19.1. Netbeans is starting maven
tests with "mvn -Dfile.encoding=...", and that seems to trigger the warning.
was (Author: gwdfl59u):
still not working reliably as of surefire 2.19.1.
> Better handling of file.encoding system property
>
>
> Key: SUREFIRE-951
> URL: https://issues.apache.org/jira/browse/SUREFIRE-951
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.13
> Environment: Any environment in which the file encoding is distinct
> from ${project.build.sourceEncoding}.
>Reporter: Stephan Schroevers
>Assignee: Kristian Rosenvold
> Fix For: 2.15
>
> Attachments: file-encoding-example.tbz
>
>
> It appears that Surefire doesn't (correctly) set
> {{-Dfile.encoding=$\{project.build.sourceEncoding\}}} prior to running the
> tests. As a result the JVM will derive {{file.encoding}} from the
> environment's file encoding. This affects the return value of
> {{java.nio.charset.Charset#defaultCharset()}}, which reads the
> {{file.encoding}} system property exactly once, and is invoked very early on.
> Concretely this means that the unit tests are unnecessarily platform
> dependent.
> Thus I have two requests:
> # Make {{-Dfile.encoding=$\{project.build.sourceEncoding\}}} the default.
> That is, the following configuration setting should be implied:
> {noformat}
> -Dfile.encoding=${project.build.sourceEncoding}
> {noformat}
> # Extend the method
> {{org.apache.maven.plugin.surefire.SurefireProperties#verifyLegalSystemProperties(org.apache.maven.plugin.logging.Log)}}
> such that is warns about users attempting to set the {{file.encoding}}
> property through the {{systemPropertyVariables}} configuration setting. Like
> with {{java.library.path}}, this does _not_ work.
> I have [attached|^file-encoding-example.tbz] a sample project that
> demonstrates the issue (simply run {{`mvn test`}}). Please have a look at the
> comments I added to the POM. I have tested this sample project only on Linux,
> but a colleague has confirmed that an instance of this issue can also be
> recreated on Windows.
> TIA for looking into this!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-951) Better handling of file.encoding system property
[
https://issues.apache.org/jira/browse/SUREFIRE-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15333559#comment-15333559
]
Mark commented on SUREFIRE-951:
---
still not working reliably as of surefire 2.19.1.
> Better handling of file.encoding system property
>
>
> Key: SUREFIRE-951
> URL: https://issues.apache.org/jira/browse/SUREFIRE-951
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.13
> Environment: Any environment in which the file encoding is distinct
> from ${project.build.sourceEncoding}.
>Reporter: Stephan Schroevers
>Assignee: Kristian Rosenvold
> Fix For: 2.15
>
> Attachments: file-encoding-example.tbz
>
>
> It appears that Surefire doesn't (correctly) set
> {{-Dfile.encoding=$\{project.build.sourceEncoding\}}} prior to running the
> tests. As a result the JVM will derive {{file.encoding}} from the
> environment's file encoding. This affects the return value of
> {{java.nio.charset.Charset#defaultCharset()}}, which reads the
> {{file.encoding}} system property exactly once, and is invoked very early on.
> Concretely this means that the unit tests are unnecessarily platform
> dependent.
> Thus I have two requests:
> # Make {{-Dfile.encoding=$\{project.build.sourceEncoding\}}} the default.
> That is, the following configuration setting should be implied:
> {noformat}
> -Dfile.encoding=${project.build.sourceEncoding}
> {noformat}
> # Extend the method
> {{org.apache.maven.plugin.surefire.SurefireProperties#verifyLegalSystemProperties(org.apache.maven.plugin.logging.Log)}}
> such that is warns about users attempting to set the {{file.encoding}}
> property through the {{systemPropertyVariables}} configuration setting. Like
> with {{java.library.path}}, this does _not_ work.
> I have [attached|^file-encoding-example.tbz] a sample project that
> demonstrates the issue (simply run {{`mvn test`}}). Please have a look at the
> comments I added to the POM. I have tested this sample project only on Linux,
> but a colleague has confirmed that an instance of this issue can also be
> recreated on Windows.
> TIA for looking into this!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MCOMPILER-270) Support release=8 on JDK 9 (with fallback on source=8 and target=8 on JDK 8)
[
https://issues.apache.org/jira/browse/MCOMPILER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15333276#comment-15333276
]
Geoffrey De Smet edited comment on MCOMPILER-270 at 6/16/16 7:25 AM:
-
Great :)
Note: not translate source/target to release, but the other way around:
translate release to source/target on older JDK's.
was (Author: ge0ffrey):
Great :)
Note: not translate source/target to release, but translate release to
source/target on older JDK's.
> Support release=8 on JDK 9 (with fallback on source=8 and target=8 on JDK 8)
>
>
> Key: MCOMPILER-270
> URL: https://issues.apache.org/jira/browse/MCOMPILER-270
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 3.5.1
>Reporter: Geoffrey De Smet
>Priority: Blocker
>
> JDK 9 now supports the the follow argument:
> {code}
> javac -release 7
> {code}
> This replaced both `-source 7` and `-target 7`. And it prevents from using
> methods introduced in JDK 9 or JDK 8 when compiling for 7 with JDK 9. So
> `-release 8` basically better in every way than `-source 7 -target 7`.
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-July/002414.html
> Support this in the maven-compiler plugin, something like:
> {code}
>
> maven-compiler-plugin
>
> 7
>
>
> {code}
> When compiling with JDK 9, it should just do `javac -release 7`.
> When compiling with JDK 8 or lower, it should fallback to `javac -source 7
> -target 7`, so it behaves exactly like:
> {code}
>
> maven-compiler-plugin
>
> 7
> 7
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MCOMPILER-270) Support release=8 on JDK 9 (with fallback on source=8 and target=8 on JDK 8)
[
https://issues.apache.org/jira/browse/MCOMPILER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15333276#comment-15333276
]
Geoffrey De Smet edited comment on MCOMPILER-270 at 6/16/16 7:25 AM:
-
Great :)
Note: not translate source/target to release, but translate release to
source/target on older JDK's.
was (Author: ge0ffrey):
not translate source/target to release, but translate release to source/target
on older JDK's.
> Support release=8 on JDK 9 (with fallback on source=8 and target=8 on JDK 8)
>
>
> Key: MCOMPILER-270
> URL: https://issues.apache.org/jira/browse/MCOMPILER-270
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 3.5.1
>Reporter: Geoffrey De Smet
>Priority: Blocker
>
> JDK 9 now supports the the follow argument:
> {code}
> javac -release 7
> {code}
> This replaced both `-source 7` and `-target 7`. And it prevents from using
> methods introduced in JDK 9 or JDK 8 when compiling for 7 with JDK 9. So
> `-release 8` basically better in every way than `-source 7 -target 7`.
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-July/002414.html
> Support this in the maven-compiler plugin, something like:
> {code}
>
> maven-compiler-plugin
>
> 7
>
>
> {code}
> When compiling with JDK 9, it should just do `javac -release 7`.
> When compiling with JDK 8 or lower, it should fallback to `javac -source 7
> -target 7`, so it behaves exactly like:
> {code}
>
> maven-compiler-plugin
>
> 7
> 7
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MCOMPILER-270) Support release=8 on JDK 9 (with fallback on source=8 and target=8 on JDK 8)
[
https://issues.apache.org/jira/browse/MCOMPILER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15333276#comment-15333276
]
Geoffrey De Smet edited comment on MCOMPILER-270 at 6/16/16 7:25 AM:
-
Great :)
Note: not translate source/target to release, but the other way around:
translate release to source/target on older JDK's that doen't support release.
was (Author: ge0ffrey):
Great :)
Note: not translate source/target to release, but the other way around:
translate release to source/target on older JDK's.
> Support release=8 on JDK 9 (with fallback on source=8 and target=8 on JDK 8)
>
>
> Key: MCOMPILER-270
> URL: https://issues.apache.org/jira/browse/MCOMPILER-270
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 3.5.1
>Reporter: Geoffrey De Smet
>Priority: Blocker
>
> JDK 9 now supports the the follow argument:
> {code}
> javac -release 7
> {code}
> This replaced both `-source 7` and `-target 7`. And it prevents from using
> methods introduced in JDK 9 or JDK 8 when compiling for 7 with JDK 9. So
> `-release 8` basically better in every way than `-source 7 -target 7`.
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-July/002414.html
> Support this in the maven-compiler plugin, something like:
> {code}
>
> maven-compiler-plugin
>
> 7
>
>
> {code}
> When compiling with JDK 9, it should just do `javac -release 7`.
> When compiling with JDK 8 or lower, it should fallback to `javac -source 7
> -target 7`, so it behaves exactly like:
> {code}
>
> maven-compiler-plugin
>
> 7
> 7
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MCOMPILER-270) Support release=8 on JDK 9 (with fallback on source=8 and target=8 on JDK 8)
[
https://issues.apache.org/jira/browse/MCOMPILER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15333276#comment-15333276
]
Geoffrey De Smet commented on MCOMPILER-270:
not translate source/target to release, but translate release to source/target
on older JDK's.
> Support release=8 on JDK 9 (with fallback on source=8 and target=8 on JDK 8)
>
>
> Key: MCOMPILER-270
> URL: https://issues.apache.org/jira/browse/MCOMPILER-270
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 3.5.1
>Reporter: Geoffrey De Smet
>Priority: Blocker
>
> JDK 9 now supports the the follow argument:
> {code}
> javac -release 7
> {code}
> This replaced both `-source 7` and `-target 7`. And it prevents from using
> methods introduced in JDK 9 or JDK 8 when compiling for 7 with JDK 9. So
> `-release 8` basically better in every way than `-source 7 -target 7`.
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-July/002414.html
> Support this in the maven-compiler plugin, something like:
> {code}
>
> maven-compiler-plugin
>
> 7
>
>
> {code}
> When compiling with JDK 9, it should just do `javac -release 7`.
> When compiling with JDK 8 or lower, it should fallback to `javac -source 7
> -target 7`, so it behaves exactly like:
> {code}
>
> maven-compiler-plugin
>
> 7
> 7
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MNG-6046) upgrade JAnsi from 1.12 to 1.13
[ https://issues.apache.org/jira/browse/MNG-6046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed MNG-6046. -- Resolution: Fixed > upgrade JAnsi from 1.12 to 1.13 > --- > > Key: MNG-6046 > URL: https://issues.apache.org/jira/browse/MNG-6046 > Project: Maven > Issue Type: Improvement > Components: Logging >Affects Versions: 3.4.0 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 3.4.0 > > > JAnsi 1.12 blows up when AnsiConsole.systemInstall() is called for a platform > where no native lib exists ( see > https://repo.maven.apache.org/maven2/org/fusesource/jansi/ for the list of > native libraries ) : then Maven becomes unusable for OpenBSD, FreeBSD, > Solaris, AIX, ... > JAnsi 1.13 contains the critical fix: > https://github.com/fusesource/jansi/pull/54 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-6046) upgrade JAnsi from 1.12 to 1.13
[ https://issues.apache.org/jira/browse/MNG-6046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15333248#comment-15333248 ] Hudson commented on MNG-6046: - SUCCESS: Integrated in maven-3.x #1306 (See [https://builds.apache.org/job/maven-3.x/1306/]) [MNG-6046] upgrade JAnsi from 1.12 to 1.13 (hboutemy: rev bcaad5668ead035e2c2cae7971b9ebed33fa82b9) * pom.xml > upgrade JAnsi from 1.12 to 1.13 > --- > > Key: MNG-6046 > URL: https://issues.apache.org/jira/browse/MNG-6046 > Project: Maven > Issue Type: Improvement > Components: Logging >Affects Versions: 3.4.0 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 3.4.0 > > > JAnsi 1.12 blows up when AnsiConsole.systemInstall() is called for a platform > where no native lib exists ( see > https://repo.maven.apache.org/maven2/org/fusesource/jansi/ for the list of > native libraries ) : then Maven becomes unusable for OpenBSD, FreeBSD, > Solaris, AIX, ... > JAnsi 1.13 contains the critical fix: > https://github.com/fusesource/jansi/pull/54 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
