[jira] [Commented] (MNG-6093) create a slf4j-simple provider extension that supports level color rendering
[ https://issues.apache.org/jira/browse/MNG-6093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15566851#comment-15566851 ] Hervé Boutemy commented on MNG-6093: work finalized in http://git-wip-us.apache.org/repos/asf/maven/commit/bf44e8a0 now need to see if this is what we want > create a slf4j-simple provider extension that supports level color rendering > > > Key: MNG-6093 > URL: https://issues.apache.org/jira/browse/MNG-6093 > Project: Maven > Issue Type: New Feature > Components: Logging >Reporter: Hervé Boutemy > > With color support, core Maven and plugins do general message colorization > (or more high-level "message styling" through maven-shared-utils) > slf4j provider however has to add color: > - for log level output (DEBUG/INFO/WARNING/ERROR) > - for stacktrace rendering > That's why we use Gossip slf4j provider: it has sufficient little extension > points to add this, with just a little bit of code (see > http://maven.apache.org/ref/3-LATEST/maven-embedder/apidocs/org/apache/maven/cli/logging/impl/gossip/package-summary.html > ) > The issue with switching to Gossip slf4j provider is that people don't know > it and it does not have the same features as slf4j-simple, the configuration > file is not the same (name nor content). > But the extension points are not that big: if slf4j-simple provider just made > a few methods protected instread of private, it would be extensible > What if we just copy slf4j-simple to change the signatures and create small > extension classes? The license permits it, we can try it and eventually see > with slf4j if the modification can go into official release -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5993) Confusing error message in case of missing/empty artifactId and version in pluginManagement
[
https://issues.apache.org/jira/browse/MNG-5993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15566504#comment-15566504
]
Hudson commented on MNG-5993:
-
SUCCESS: Integrated in Jenkins build maven-3.x #1393 (See
[https://builds.apache.org/job/maven-3.x/1393/])
[MNG-5993] Confusing error message in case of missing/empty (khmarbaise: rev
8fe10c34128ee1c8dfe00a1be3828931b14b6c5e)
* (edit)
maven-model-builder/src/test/java/org/apache/maven/model/validation/DefaultModelValidatorTest.java
> Confusing error message in case of missing/empty artifactId and version in
> pluginManagement
> ---
>
> Key: MNG-5993
> URL: https://issues.apache.org/jira/browse/MNG-5993
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Konrad Windszus
>Assignee: Karl Heinz Marbaise
> Fix For: 3.4.0
>
>
> Executing any goals/phases on this pom.xml leads to a weird error
> {code}
> 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/xsd/maven-4.0.0.xsd;>
> 4.0.0
> com.example.group
> testinvalidpom
> 0.0.1-SNAPSHOT
>
>
>
>
>
>
>
>
>
>
>
> {code}
> The error being emitted is
> {code}
> [ERROR] Error resolving version for plugin ':null' from the repositories
> [local (), nexus ()]: Plugin not found in
> any plugin repository -> [Help 1]
> {code}
> Even with debug you only see something like this
> {code}
> [ERROR] Error resolving version for plugin ':null' from the repositories
> [...]: Plugin not found in any plugin repository -> [Help 1]
> org.apache.maven.plugin.version.PluginVersionResolutionException: Error
> resolving version for plugin ':null' from the repositories [local
> (/Users/konradwindszus/.m2/repository), nexus
> (https://repo.int.netcentric.biz/nexus/content/groups/public/)]: Plugin not
> found in any plugin repository
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.selectVersion(DefaultPluginVersionResolver.java:236)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository(DefaultPluginVersionResolver.java:148)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve(DefaultPluginVersionResolver.java:96)
> at
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions(LifecyclePluginResolver.java:89)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.calculateExecutionPlan(DefaultLifecycleExecutionPlanCalculator.java:116)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.calculateExecutionPlan(DefaultLifecycleExecutionPlanCalculator.java:135)
> at
> org.apache.maven.lifecycle.internal.builder.BuilderCommon.resolveBuildPlan(BuilderCommon.java:97)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:109)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
> In this example the error is easy to spot, but for bigger pom.xmls with more
> complex hierarchies it is very hard.
> Some basic validation should take place that on the merged pom.xml all of
> groupId, artifactId and
[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern
[
https://issues.apache.org/jira/browse/SUREFIRE-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15566167#comment-15566167
]
ASF GitHub Bot commented on SUREFIRE-1293:
--
Github user britter commented on the issue:
https://github.com/apache/maven-surefire/pull/127
Hello @Tibor17, I'll fix the checkstyle violations and squash everything
into one single commit!
> Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using
> the null object pattern
>
>
> Key: SUREFIRE-1293
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1293
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Reporter: Benedikt Ritter
> Labels: github
> Fix For: 2.19.2
>
>
> The class org.apache.maven.plugin.surefire.report.TestSetRunListener has a
> lot of checks like this:
> {code:java}
> if( field != null )
> {
> // do something with field
> }
> {code}
> This can be simplified by providing fallback implementations for the fields
> being used by TestSetRunListener.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6081) Log refactoring - Method Invocation Replaced By Variable
[
https://issues.apache.org/jira/browse/MNG-6081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nemo Chen updated MNG-6081:
---
Attachment: MNG-6081.patch
> Log refactoring - Method Invocation Replaced By Variable
>
>
> Key: MNG-6081
> URL: https://issues.apache.org/jira/browse/MNG-6081
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.9
>Reporter: Nemo Chen
>Priority: Minor
> Attachments: MNG-6081.patch
>
>
> *Method Invocation Replaced By Variable*
> In file:
> apache-maven-3.3.9/maven-compat/src/main/java/org/apache/maven/artifact/resolver/DebugResolutionListener.java
> from line 70:
> {code}
> String keptVersion = kept.getVersion();
> if ( omittedVersion != null ? !omittedVersion.equals( keptVersion ) :
> keptVersion != null )
> {
> logger.debug( indent + omitted + " (removed - nearer found: " +
> kept.getVersion() + ")" );
> }
> {code}
> the "kept.getVersion()" can be replaced with "keptVersion" for the sake of
> simplicity and readability.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6081) Log refactoring - Method Invocation Replaced By Variable
[
https://issues.apache.org/jira/browse/MNG-6081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nemo Chen updated MNG-6081:
---
Attachment: (was: MNG-6081.diff)
> Log refactoring - Method Invocation Replaced By Variable
>
>
> Key: MNG-6081
> URL: https://issues.apache.org/jira/browse/MNG-6081
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.9
>Reporter: Nemo Chen
>Priority: Minor
>
> *Method Invocation Replaced By Variable*
> In file:
> apache-maven-3.3.9/maven-compat/src/main/java/org/apache/maven/artifact/resolver/DebugResolutionListener.java
> from line 70:
> {code}
> String keptVersion = kept.getVersion();
> if ( omittedVersion != null ? !omittedVersion.equals( keptVersion ) :
> keptVersion != null )
> {
> logger.debug( indent + omitted + " (removed - nearer found: " +
> kept.getVersion() + ")" );
> }
> {code}
> the "kept.getVersion()" can be replaced with "keptVersion" for the sake of
> simplicity and readability.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6081) Log refactoring - Method Invocation Replaced By Variable
[
https://issues.apache.org/jira/browse/MNG-6081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nemo Chen updated MNG-6081:
---
Attachment: MNG-6081.diff
> Log refactoring - Method Invocation Replaced By Variable
>
>
> Key: MNG-6081
> URL: https://issues.apache.org/jira/browse/MNG-6081
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.9
>Reporter: Nemo Chen
>Priority: Minor
>
> *Method Invocation Replaced By Variable*
> In file:
> apache-maven-3.3.9/maven-compat/src/main/java/org/apache/maven/artifact/resolver/DebugResolutionListener.java
> from line 70:
> {code}
> String keptVersion = kept.getVersion();
> if ( omittedVersion != null ? !omittedVersion.equals( keptVersion ) :
> keptVersion != null )
> {
> logger.debug( indent + omitted + " (removed - nearer found: " +
> kept.getVersion() + ")" );
> }
> {code}
> the "kept.getVersion()" can be replaced with "keptVersion" for the sake of
> simplicity and readability.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MJAVADOC-333) Diacritics (accents) in project path prevent the plugin from working on Windows.
[ https://issues.apache.org/jira/browse/MJAVADOC-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15565436#comment-15565436 ] Anthony O. edited comment on MJAVADOC-333 at 10/11/16 2:03 PM: --- This issue still exists with current version of maven-javadoc-plugin (2.10.4)... I created a post on stackoverflow that references this bug: http://stackoverflow.com/q/39979045/535203 was (Author: anthony-o): This issue still exists with current version of maven-javadoc-plugin (2.10.4)... > Diacritics (accents) in project path prevent the plugin from working on > Windows. > > > Key: MJAVADOC-333 > URL: https://issues.apache.org/jira/browse/MJAVADOC-333 > Project: Maven Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.7, 2.8 > Environment: Win7 >Reporter: Martin Pecka > Attachments: options, pom.xml > > > My project is located in "E:\ProgramovánÃ\Java\beam-3D-data-viewer". Notice > the diacritics in the path. > When launching the javadoc:javadoc goal, the build fails: > . > . > . > [ERROR] javadoc: warning - No source files for package org.esa.beam.util > [ERROR] javadoc: error - No public or protected classes found to document. > I looked on the generated "options" file, and that's the problem. Windows > apparentely don't have their filenames encoded in UTF8 when passing them to > the command line, but the options file is saved in UTF8. That's the reason > why the plugin cannot find the source files. When I manually edit the file > and save it in cp1250 encoding, running javadoc.bat works perfectly. > This should obviously be fixed, but is there a quick workaround? Eg. a way to > alter the generated javadoc.bat to prepend a call to iconv or something else. > Now I can use the generated files, manually edit the options file, and run > the task, but if I want to run the jar goal, this bug makes it impossible. > Thanks for cooperation! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MJAVADOC-333) Diacritics (accents) in project path prevent the plugin from working on Windows.
[ https://issues.apache.org/jira/browse/MJAVADOC-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15565436#comment-15565436 ] Anthony O. commented on MJAVADOC-333: - This issue still exists with current version of maven-javadoc-plugin (2.10.4)... > Diacritics (accents) in project path prevent the plugin from working on > Windows. > > > Key: MJAVADOC-333 > URL: https://issues.apache.org/jira/browse/MJAVADOC-333 > Project: Maven Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.7, 2.8 > Environment: Win7 >Reporter: Martin Pecka > Attachments: options, pom.xml > > > My project is located in "E:\ProgramovánÃ\Java\beam-3D-data-viewer". Notice > the diacritics in the path. > When launching the javadoc:javadoc goal, the build fails: > . > . > . > [ERROR] javadoc: warning - No source files for package org.esa.beam.util > [ERROR] javadoc: error - No public or protected classes found to document. > I looked on the generated "options" file, and that's the problem. Windows > apparentely don't have their filenames encoded in UTF8 when passing them to > the command line, but the options file is saved in UTF8. That's the reason > why the plugin cannot find the source files. When I manually edit the file > and save it in cp1250 encoding, running javadoc.bat works perfectly. > This should obviously be fixed, but is there a quick workaround? Eg. a way to > alter the generated javadoc.bat to prepend a call to iconv or something else. > Now I can use the generated files, manually edit the options file, and run > the task, but if I want to run the jar goal, this bug makes it impossible. > Thanks for cooperation! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern
[
https://issues.apache.org/jira/browse/SUREFIRE-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15565257#comment-15565257
]
ASF GitHub Bot commented on SUREFIRE-1293:
--
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/127
After we are done with all commits, would you be able to safely squash them
in one single commit?
> Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using
> the null object pattern
>
>
> Key: SUREFIRE-1293
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1293
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Reporter: Benedikt Ritter
> Labels: github
> Fix For: 2.19.2
>
>
> The class org.apache.maven.plugin.surefire.report.TestSetRunListener has a
> lot of checks like this:
> {code:java}
> if( field != null )
> {
> // do something with field
> }
> {code}
> This can be simplified by providing fallback implementations for the fields
> being used by TestSetRunListener.
--
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=15565253#comment-15565253
]
Tibor Digana commented on SUREFIRE-951:
---
[~fmarot]
Please give me several days to complete the task. It is still in progress..
> 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: Tibor Digana
> 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=15565114#comment-15565114
]
Francois MAROT commented on SUREFIRE-951:
-
[~tibor17] Can you point me to the repository containing the SNAPSHOTS version
please ? Or better directly give me the pom content ;)
> 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: Tibor Digana
> 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] (MNG-6103) Maven Configuration Problem
[ https://issues.apache.org/jira/browse/MNG-6103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15564887#comment-15564887 ] Michael Osipov edited comment on MNG-6103 at 10/11/16 8:25 AM: --- This is not a support forum. As Robert and Guillaume layed out, seek at Stackoverflow or the users mailinglist for help. was (Author: michael-o): This is not a support forum. As Rober and Guillaume layed out, seek at Stackoverflow or the users mailinglist for help. > Maven Configuration Problem > --- > > Key: MNG-6103 > URL: https://issues.apache.org/jira/browse/MNG-6103 > Project: Maven > Issue Type: Question >Reporter: Muneeb Akhtar > > Hi , > I have imported my project into RAD 8.5 and while importing I am seeing below > error in the pom.xml file in RAD 8.5. > org.codehaus.plexus.archiver.jar.Manifest.merge(org.codehaus.plexus.archiver.jar.Manifest) > I am using maven 3.2. > Any idea about this issue? > Appreciate your help. > Thank you > Muneeb Akhtar -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MNG-6103) Maven Configuration Problem
[ https://issues.apache.org/jira/browse/MNG-6103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-6103. --- Resolution: Incomplete This is not a support forum. As Rober and Guillaume layed out, seek at Stackoverflow or the users mailinglist for help. > Maven Configuration Problem > --- > > Key: MNG-6103 > URL: https://issues.apache.org/jira/browse/MNG-6103 > Project: Maven > Issue Type: Question >Reporter: Muneeb Akhtar > > Hi , > I have imported my project into RAD 8.5 and while importing I am seeing below > error in the pom.xml file in RAD 8.5. > org.codehaus.plexus.archiver.jar.Manifest.merge(org.codehaus.plexus.archiver.jar.Manifest) > I am using maven 3.2. > Any idea about this issue? > Appreciate your help. > Thank you > Muneeb Akhtar -- This message was sent by Atlassian JIRA (v6.3.4#6332)
