[GitHub] [maven-dependency-plugin] ian-lavallee opened a new pull request #95: [MDEP-644] Reintroduce the verbose option for dependency:tree

2020-08-13 Thread GitBox


ian-lavallee opened a new pull request #95:
URL: https://github.com/apache/maven-dependency-plugin/pull/95


   Added DOT, TGF, and GraphML support for the verbose serializer
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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




[jira] [Commented] (MRESOURCES-265) Resource copying not using specified encoding

2020-08-13 Thread Duncan Kinnear (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177382#comment-17177382
 ] 

Duncan Kinnear commented on MRESOURCES-265:
---

Oh, and in the POM, there is no configuration section for the resource plugin, 
and the build/resources section is as follows:

{{<{color:#0033b3}resources{color}>}}
{{  <{color:#0033b3}resource{color}>}}
{{    
<{color:#0033b3}directory{color}>src/main/resources}}
{{    <{color:#0033b3}filtering{color}>true}}
{{  }}
{{}}

I have no idea why the filtering is on. This was set up by a previous employee, 
and as it was working fine before, so we've not messed with it.

> Resource copying not using specified encoding
> -
>
> Key: MRESOURCES-265
> URL: https://issues.apache.org/jira/browse/MRESOURCES-265
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: copy
>Affects Versions: 3.2.0
> Environment: Linux, CentOS 7
> Jenkins 2.251
> Jenkins Maven Integration plugin 3.1.2
> Java 1.8
>Reporter: Duncan Kinnear
>Priority: Major
>
> Overnight our Jenkins builds stopped working. On investigation we found that 
> maven-resources-plugin version used yesterday was 3.1.0 (which worked fine) 
> and today it was using 3.2.0.
> The stacktrace produced by adding the "e" switch to the maven command line 
> had the following root cause (truncated for brevity):-
> Caused by: java.nio.charset.MalformedInputException: Input length = 1
>  at java.nio.charset.CoderResult.throwException (CoderResult.java:281)
>  at sun.nio.cs.StreamDecoder.implRead (StreamDecoder.java:339)
>  at sun.nio.cs.StreamDecoder.read (StreamDecoder.java:178)
>  at java.io.InputStreamReader.read (InputStreamReader.java:184)
>  at java.io.BufferedReader.read1 (BufferedReader.java:210)
>  at java.io.BufferedReader.read (BufferedReader.java:286)
>  at java.io.BufferedReader.fill (BufferedReader.java:161)
>  at java.io.BufferedReader.read (BufferedReader.java:182)
>  at org.apache.maven.shared.filtering.BoundedReader.read 
> (BoundedReader.java:85)
>  at 
> org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read
>  (MultiDelimiterInterpolatorFilterReaderLineEnding.java:235)
>  at 
> org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read
>  (MultiDelimiterInterpolatorFilterReaderLineEnding.java:197)
>  at java.io.Reader.read (Reader.java:140)
>  at org.apache.maven.shared.utils.io.IOUtil.copy (IOUtil.java:199)
>  
> After a google search told us this was an encoding issue, we added the 
> following to the maven command line, but this made no difference:
> -Dproject.build.sourceEncoding=UTF-8 -Dproject.reporting.outputEncoding=UTF-8
>  
> The maven build log has these info messsage just before the error:
> [INFO] — maven-resources-plugin:3.2.0:resources (default-cli) @ uniworks —
>  [INFO] Using 'UTF-8' encoding to copy filtered resources.
>  [INFO] Using 'UTF-8' encoding to copy filtered properties files.
>  [INFO] Copying 430 resources
> We only 'fixed' the problem by specifying version 3.1.0 of the plugin in the 
> projects POM 'pluginManagement' section.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MRESOURCES-265) Resource copying not using specified encoding

2020-08-13 Thread Duncan Kinnear (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177354#comment-17177354
 ] 

Duncan Kinnear commented on MRESOURCES-265:
---

Actually, for just now I'm not going to attach this file as someone here has 
said that it could be a security issue.

If you really need it, I can perhaps email it directly to someone.

> Resource copying not using specified encoding
> -
>
> Key: MRESOURCES-265
> URL: https://issues.apache.org/jira/browse/MRESOURCES-265
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: copy
>Affects Versions: 3.2.0
> Environment: Linux, CentOS 7
> Jenkins 2.251
> Jenkins Maven Integration plugin 3.1.2
> Java 1.8
>Reporter: Duncan Kinnear
>Priority: Major
>
> Overnight our Jenkins builds stopped working. On investigation we found that 
> maven-resources-plugin version used yesterday was 3.1.0 (which worked fine) 
> and today it was using 3.2.0.
> The stacktrace produced by adding the "e" switch to the maven command line 
> had the following root cause (truncated for brevity):-
> Caused by: java.nio.charset.MalformedInputException: Input length = 1
>  at java.nio.charset.CoderResult.throwException (CoderResult.java:281)
>  at sun.nio.cs.StreamDecoder.implRead (StreamDecoder.java:339)
>  at sun.nio.cs.StreamDecoder.read (StreamDecoder.java:178)
>  at java.io.InputStreamReader.read (InputStreamReader.java:184)
>  at java.io.BufferedReader.read1 (BufferedReader.java:210)
>  at java.io.BufferedReader.read (BufferedReader.java:286)
>  at java.io.BufferedReader.fill (BufferedReader.java:161)
>  at java.io.BufferedReader.read (BufferedReader.java:182)
>  at org.apache.maven.shared.filtering.BoundedReader.read 
> (BoundedReader.java:85)
>  at 
> org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read
>  (MultiDelimiterInterpolatorFilterReaderLineEnding.java:235)
>  at 
> org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read
>  (MultiDelimiterInterpolatorFilterReaderLineEnding.java:197)
>  at java.io.Reader.read (Reader.java:140)
>  at org.apache.maven.shared.utils.io.IOUtil.copy (IOUtil.java:199)
>  
> After a google search told us this was an encoding issue, we added the 
> following to the maven command line, but this made no difference:
> -Dproject.build.sourceEncoding=UTF-8 -Dproject.reporting.outputEncoding=UTF-8
>  
> The maven build log has these info messsage just before the error:
> [INFO] — maven-resources-plugin:3.2.0:resources (default-cli) @ uniworks —
>  [INFO] Using 'UTF-8' encoding to copy filtered resources.
>  [INFO] Using 'UTF-8' encoding to copy filtered properties files.
>  [INFO] Copying 430 resources
> We only 'fixed' the problem by specifying version 3.1.0 of the plugin in the 
> projects POM 'pluginManagement' section.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MRESOURCES-265) Resource copying not using specified encoding

2020-08-13 Thread Duncan Kinnear (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177348#comment-17177348
 ] 

Duncan Kinnear commented on MRESOURCES-265:
---

I added the '-X' option to the mvn command line to give me debug level logging.

The following is a snippet of the log before the failure:

{{{color:#FF}[WARNING] Using platform encoding (UTF-8 actually) to copy 
filtered resources, i.e. build is platform dependent!{color}}}
{{{color:#ffab00}[INFO] Using 'null' encoding to copy filtered properties 
files.{color}}}
{{[DEBUG] resource with targetPath null}}
{{directory /home/duncan/NetBeansProjects/uniworks-2.2.7/src/main/resources}}
{{excludes []}}
{{includes []}}
{{[DEBUG] ignoreDelta true}}
{{[INFO] Copying 489 resources}}
{{[DEBUG] Copying file settings/settings.xml}}
{{[DEBUG] file settings.xml has a filtered file extension}}
{{{color:#ffab00}[DEBUG] Using 'null' encoding to copy filtered resource 
'settings.xml'.{color}}}
{{[DEBUG] filtering 
/home/duncan/NetBeansProjects/uniworks-2.2.7/src/main/resources/settings/settings.xml
 to 
/home/duncan/NetBeansProjects/uniworks-2.2.7/target/classes/settings/settings.xml}}
{{[DEBUG] Copying file keystore/keystore.jks}}
{{[DEBUG] file keystore.jks has a filtered file extension}}
{{{color:#ffab00}[DEBUG] Using 'null' encoding to copy filtered resource 
'keystore.jks'.{color}}}
{{[DEBUG] filtering 
/home/duncan/NetBeansProjects/uniworks-2.2.7/src/main/resources/keystore/keystore.jks
 to 
/home/duncan/NetBeansProjects/uniworks-2.2.7/target/classes/keystore/keystore.jks}}

{{So it is the second file that it is copying which fails (keystore.jks). This 
file has been in our build for 8 years and is the keystore used to sign our 
OSGi bundles. I will attach it to the issue.}}

{{The interesting thing about these log messages is the fact that before it 
starts copying the files, Maven warns that encoding is not set, and that the 
platform encoding (UTF-8) will be used (red highlight).}}

{{However, before copying each file, it states that it is "Using 'null' 
encoding to copy " (yellow highlight). So it seems that it is not picking 
up the platform encoding correctly.}}

{{If I specify version 3.1.0 of the resource plugin, the same part of the build 
log has the following:}}

{{{color:#de350b}[WARNING] Using platform encoding (UTF-8 actually) to copy 
filtered resources, i.e. build is platform dependent!{color}}}
{{[DEBUG] resource with targetPath null}}
{{directory /home/duncan/NetBeansProjects/clean-2.2.6/src/main/resources}}
{{excludes []}}
{{includes []}}
{{[DEBUG] ignoreDelta true}}
{{[INFO] Copying 430 resources}}
{{[DEBUG] Copying file settings/settings.xml}}
{{[DEBUG] file settings.xml has a filtered file extension}}
{{[DEBUG] filtering 
/home/duncan/NetBeansProjects/clean-2.2.6/src/main/resources/settings/settings.xml
 to 
/home/duncan/NetBeansProjects/clean-2.2.6/target/classes/settings/settings.xml}}
{{[DEBUG] Copying file keystore/keystore.jks}}
{{[DEBUG] file keystore.jks has a filtered file extension}}
{{[DEBUG] filtering 
/home/duncan/NetBeansProjects/clean-2.2.6/src/main/resources/keystore/keystore.jks
 to 
/home/duncan/NetBeansProjects/clean-2.2.6/target/classes/keystore/keystore.jks}}
{{[DEBUG] Copying file spring-config.xml}}
{{[DEBUG] file spring-config.xml has a filtered file extension}}
{{[DEBUG] filtering 
/home/duncan/NetBeansProjects/clean-2.2.6/src/main/resources/spring-config.xml 
to /home/duncan/NetBeansProjects/clean-2.2.6/target/classes/spring-config.xml}}

{{Note there is no mention of a 'null encoding.}}

> Resource copying not using specified encoding
> -
>
> Key: MRESOURCES-265
> URL: https://issues.apache.org/jira/browse/MRESOURCES-265
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: copy
>Affects Versions: 3.2.0
> Environment: Linux, CentOS 7
> Jenkins 2.251
> Jenkins Maven Integration plugin 3.1.2
> Java 1.8
>Reporter: Duncan Kinnear
>Priority: Major
>
> Overnight our Jenkins builds stopped working. On investigation we found that 
> maven-resources-plugin version used yesterday was 3.1.0 (which worked fine) 
> and today it was using 3.2.0.
> The stacktrace produced by adding the "e" switch to the maven command line 
> had the following root cause (truncated for brevity):-
> Caused by: java.nio.charset.MalformedInputException: Input length = 1
>  at java.nio.charset.CoderResult.throwException (CoderResult.java:281)
>  at sun.nio.cs.StreamDecoder.implRead (StreamDecoder.java:339)
>  at sun.nio.cs.StreamDecoder.read (StreamDecoder.java:178)
>  at java.io.InputStreamReader.read (InputStreamReader.java:184)
>  at java.io.BufferedReader.read1 (BufferedReader.java:210)
>  at java.io.BufferedReader.read (BufferedReader.java:286)
>  at java.io.BufferedReader.fill 

[jira] [Commented] (MNG-6928) CREATE: Call to Action design card

2020-08-13 Thread Amelia Eiras (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177277#comment-17177277
 ] 

Amelia Eiras commented on MNG-6928:
---

[~ryanstjames] the style of the cards are clean & the colors look fantastic. 

> CREATE: Call to Action design card
> --
>
> Key: MNG-6928
> URL: https://issues.apache.org/jira/browse/MNG-6928
> Project: Maven
>  Issue Type: New Feature
>Reporter: Amelia Eiras
>Priority: Major
> Attachments: Maven-SM-Content.png, Maven-SM-Contributor.png, 
> Maven-SM-Contributor.png, Maven-SM-User.png, Maven-SM-User.png, 
> Maven-SM-User.png, Maven-SM-User.png, image-2020-08-11-19-04-07-654.png, 
> image-2020-08-11-19-04-07-776.png, image-2020-08-11-19-04-08-038.png, 
> image-2020-08-11-19-06-16-333.png, image-2020-08-11-19-06-16-469.png, 
> image-2020-08-11-19-06-16-615.png, image-2020-08-11-19-06-44-982.png
>
>
> general call out as Maven benefits for diverse contributions that are not 
> solely focused on code. 
> [Maven 
> Logos|https://drive.google.com/drive/folders/1oKAnZAlvUlck9XgNGUkr6UGgzEguY8n3?usp=sharing]
> Tomitribe will create the drafts. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6928) CREATE: Call to Action design card

2020-08-13 Thread Amelia Eiras (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177271#comment-17177271
 ] 

Amelia Eiras commented on MNG-6928:
---

Hola Maven Community, 

 

*Tracing on this ticket:*

On July 22nd, [~rfscholte] dedicated 1hr of his day so a zoom video call that 
with [~ryanstjames]  & I, so that together we could understand the project 
trademarks, the do and don'ts, etc.

The Brainstorming hour was fantastic, plenty of questions. That call has 
allowed for Ryan to produce a few crude Maven designs that could be of 
value/use to the Maven community. Specially  when using media to share his/her 
involvement in the Maven project.

Everything since that 1hr is now being shared publicly via this ticket.  This 
ticket welcomes anyone to contribute. 

Please note that the July 22 comment by Robert is a direct part of the minutes 
of the call along side with the link of the 2 issues to this ticket.    

The list on [~rfscholte] comment is just the start of potential Maven messages 
we came up on that call.

 If you have other suggestions, messages, please use the comment section to 
provide that feedback.

 

 

 

> CREATE: Call to Action design card
> --
>
> Key: MNG-6928
> URL: https://issues.apache.org/jira/browse/MNG-6928
> Project: Maven
>  Issue Type: New Feature
>Reporter: Amelia Eiras
>Priority: Major
> Attachments: Maven-SM-Content.png, Maven-SM-Contributor.png, 
> Maven-SM-Contributor.png, Maven-SM-User.png, Maven-SM-User.png, 
> Maven-SM-User.png, Maven-SM-User.png, image-2020-08-11-19-04-07-654.png, 
> image-2020-08-11-19-04-07-776.png, image-2020-08-11-19-04-08-038.png, 
> image-2020-08-11-19-06-16-333.png, image-2020-08-11-19-06-16-469.png, 
> image-2020-08-11-19-06-16-615.png, image-2020-08-11-19-06-44-982.png
>
>
> general call out as Maven benefits for diverse contributions that are not 
> solely focused on code. 
> [Maven 
> Logos|https://drive.google.com/drive/folders/1oKAnZAlvUlck9XgNGUkr6UGgzEguY8n3?usp=sharing]
> Tomitribe will create the drafts. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [maven-checkstyle-plugin] elharo commented on a change in pull request #34: [MCHECKSTYLE-99] should use default test

2020-08-13 Thread GitBox


elharo commented on a change in pull request #34:
URL: 
https://github.com/apache/maven-checkstyle-plugin/pull/34#discussion_r470088921



##
File path: 
src/main/java/org/apache/maven/plugins/checkstyle/AbstractCheckstyleReport.java
##
@@ -780,6 +770,53 @@ private void generateMainReport( CheckstyleResults 
results, ResourceBundle bundl
 generator.generateReport( results );
 }
 
+private void initializeXrefLocation( CheckstyleReportGenerator generator )
+{
+  String relativePath = determineRelativePath( xrefLocation );
+  if ( xrefLocation.exists() || checkMavenJxrPluginIsConfigured() )
+  {
+  // XRef was already generated by manual execution of a lifecycle 
binding
+  // the report is on its way
+  generator.setXrefLocation( relativePath );
+  }
+}
+
+private void initializeXrefTestLocation( CheckstyleReportGenerator 
generator )
+{
+  String relativePath = determineRelativePath( xrefTestLocation );
+  if ( xrefTestLocation.exists() || checkMavenJxrPluginIsConfigured() )
+  {
+  // XRef was already generated by manual execution of a lifecycle 
binding
+  // the report is on its way
+  generator.setXrefTestLocation( relativePath );
+  }
+}
+
+private String determineRelativePath( File location )
+{
+  String relativePath = PathTool.getRelativePath( getOutputDirectory(), 
location.getAbsolutePath() );
+  if ( StringUtils.isEmpty( relativePath ) )

Review comment:
   which StringUtils is this?





This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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




[jira] [Reopened] (MCHECKSTYLE-99) should use default test sources xref output dir: ${project.reporting.outputDirectory}/xref-test

2020-08-13 Thread Elliotte Rusty Harold (Jira)


 [ 
https://issues.apache.org/jira/browse/MCHECKSTYLE-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliotte Rusty Harold reopened MCHECKSTYLE-99:
--

There's a PR in flight for this one

>  should use default test sources xref output dir: 
> ${project.reporting.outputDirectory}/xref-test
> 
>
> Key: MCHECKSTYLE-99
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-99
> Project: Maven Checkstyle Plugin
>  Issue Type: Bug
>  Components: checkstyle:checkstyle
>Affects Versions: 2.2
> Environment: Linux (but I assume it happens in all environs)
>Reporter: Dan Rollo
>Priority: Major
> Attachments: pom.xml
>
>
> The xref link to the Source pages in the checkstyle report page is
> broken. The source xref link for Unit Test Source files is not using the
> default value of the destDir for jxr test sources. From the jxr plugin docs
> for jxr:test-jxr:
> destDir
> Folder where the Xref files will be copied to.
> * Type: java.lang.String
> * Required: No
> * Expression: ${project.reporting.outputDirectory}/xref-test
> I think the checkstyle plugin should:
> - assume the default dir for jxr:test-jxr
> - provide it's own additional override setting (similar to xrefLocation,
> but for test sources). like: testXrefLocation.
> A pom file exhibiting this problem is attached.
> Dan Rollo



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [maven-checkstyle-plugin] bmhm commented on pull request #17: [MCHECKSTYLE-385] rework code to use a Violation.java class.

2020-08-13 Thread GitBox


bmhm commented on pull request #17:
URL: 
https://github.com/apache/maven-checkstyle-plugin/pull/17#issuecomment-673558156


   retest this please
   
   @eolivelli or @elharo  please merge it when retested, all reviewers gave 
their LGTM.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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




[jira] [Commented] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs

2020-08-13 Thread Eddie Wiegers (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177096#comment-17177096
 ] 

Eddie Wiegers commented on MNG-6772:


Hey [~rfscholte], just checking in to see if your changes are completed and if 
you need me to do anything to prepare these changes. Thanks!

> Super POM overwrites remapped central repository in nested import POMs
> --
>
> Key: MNG-6772
> URL: https://issues.apache.org/jira/browse/MNG-6772
> Project: Maven
>  Issue Type: Bug
>  Components: Artifacts and Repositories, POM
>Affects Versions: 3.6.2
>Reporter: Eddie Wiegers
>Priority: Major
> Fix For: 3.7.x-candidate
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> My projects define a repository with {{central,}} which is meant to 
> specifically override the entry in the Super POM. This is specifically what 
> [JFrog Artifactory 
> recommends|https://www.jfrog.com/confluence/display/RTF/Maven+Repository#MavenRepository-ManuallyOverridingtheBuilt-inRepositories]
>  doing, and seems valid in situations where the _real_ Maven Central may be 
> unreachable.
>  
> The override takes precedence almost all of the time. However, there is at 
> least one scenario where this is not the case, and that is when importing a 
> POM that in turn imports another POM.
>  
> Digging into the code, it appears the reason this happens is because the 
> {{DefaultModelBuilder}} overwrites repositories after interpolation is 
> complete:
> [https://github.com/apache/maven/blob/53f04f03e3e58c75dcc791d557758357a6ec7983/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L411]
>  
> From what I can tell, this is done with the intention of overwriting 
> repositories that were added to the local resolver prior to interpolation 
> with the interpolated version. Due to the way the {{DefaultModelResolver}} 
> works, an unintended side effect is that the {{central}} repository from the 
> Super POM is added once after each interpolation. The first time the 
> repository is added, it is added to the {{repositoryIds}} but doesn't 
> actually remove the original repository. The second time it is added is when 
> the original repository will be replaced. Currently, the repositoryIds are 
> preserved in the {{ModelResolver}} when resolving import POMs, leading to the 
> behavior I am seeing where the second nested import POM ends up being where 
> the failure occurs.
>  
> I am planning on submitting a PR to clone the {{ModelResolver}} in a way that 
> resets the repositoryIds prior to import POMs being resolved, since they are 
> separate artifact builds. That seems like the most consistent fix to me that 
> covers cases outside of the the Super POM's {{central}} definition.
>  
> *Workarounds*:
> The current workaround is to use a repository ID other than {{central}} for 
> my Artifactory repository, which isn't ideal since it leaves the potential 
> for long timeouts to occur on the real {{central}} when an artifact can't be 
> resolved from my Artifactory repository.
>  
> Mirrors are not an ideal workaround since getting them in place on all 
> possible build environments isn't trivial.
>  
> When looking at the code I noticed 
> {{RepositorySystemSession#isIgnoreArtifactDescriptorRepositories()}} being 
> checked in various places, which seems like it would also act as a potential 
> workaround, but I don't see a way to enable this value via MavenCLI or 
> properties of any kind. It seems like this value aligns well with what 
> Artifactory is already trying to enforce, so it would make sense to enable 
> this in projects that intend to exclusively use Artifactory. Is there a 
> supported way to set this value outside of constructing a Maven build in code?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (MDEP-630) error dependency:list (caused by postgresql dependency)

2020-08-13 Thread Elliotte Rusty Harold (Jira)


 [ 
https://issues.apache.org/jira/browse/MDEP-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliotte Rusty Harold updated MDEP-630:
---
Labels: S2 list postgresql  (was: list postgresql)

> error dependency:list (caused by postgresql dependency)
> ---
>
> Key: MDEP-630
> URL: https://issues.apache.org/jira/browse/MDEP-630
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: tree
>Affects Versions: 3.0.2
> Environment: Windows 10
>Reporter: Khalil Bouzekri
>Priority: Major
>  Labels: S2, list, postgresql
> Attachments: error.txt, pom.xml
>
>
> Hi, when doing a
> {code:java}
> mvn -e dependency:list
> {code}
> on a project having the attached pom.xml, I get errors (see attached, 
> error.txt)
> I am not sure if the problem comes from the plugin or the dependency's pom.
> I tried with different versions and I get the same error.
> Thanks to let me know
> P.S.: I had to choose "tree" as component as "list" was not listed (note that 
> it works with "tree")
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (MNG-6978) Setting inherited to false on execution has no effect

2020-08-13 Thread Jira
László Stahorszki created MNG-6978:
--

 Summary: Setting inherited to false on execution has no effect
 Key: MNG-6978
 URL: https://issues.apache.org/jira/browse/MNG-6978
 Project: Maven
  Issue Type: Bug
  Components: Plugins and Lifecycle
Affects Versions: 3.6.3
Reporter: László Stahorszki


Minimal reproducible example

[https://github.com/rolaca11/maven-inherited-min/tree/master]

When the execution configuration comes from a  tag, disabling 
inheritance doesn't work on subsequent child projects.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (MSHARED-953) trimming can remove all whitespace

2020-08-13 Thread Elliotte Rusty Harold (Jira)


 [ 
https://issues.apache.org/jira/browse/MSHARED-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliotte Rusty Harold updated MSHARED-953:
--
Description: 
The trim parameter in buildDom methods in Xpp3DomBuilder is based on a serious 
misunderstanding of how the characters method in SAX works. As currently 
written, trim can potentially remove all whitespace in text content from a 
document. A little more commonly, it will randomly remove or not remove 
whitespace depending on how the SAX parser chooses to split text nodes when it 
reports them.

It might be possible to implement this correctly at the cost of a lot of code 
complexity if anyone is using this. More easily, we could make the parameter a 
no-op and never trim. 
 

  was:
The trim parameter in buildDom methods in Xpp3DomBuilder is base don a serious 
misunderstanding of how the characters method in SAX works. As currently 
written, trim can potentially remove all whitespace in text content from a 
document. A little more commonly, it will randomly remove or not remove 
whitespace depending on how the SAX parser chooses to split text nodes when it 
reports them.

It might be possible to implement this correctly at the cost of a lot of code 
complexity if anyone is using this. More easily, we could make the parameter a 
no-op and never trim. 
 


> trimming can remove all whitespace
> --
>
> Key: MSHARED-953
> URL: https://issues.apache.org/jira/browse/MSHARED-953
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-shared-utils
>Reporter: Elliotte Rusty Harold
>Priority: Critical
>
> The trim parameter in buildDom methods in Xpp3DomBuilder is based on a 
> serious misunderstanding of how the characters method in SAX works. As 
> currently written, trim can potentially remove all whitespace in text content 
> from a document. A little more commonly, it will randomly remove or not 
> remove whitespace depending on how the SAX parser chooses to split text nodes 
> when it reports them.
> It might be possible to implement this correctly at the cost of a lot of code 
> complexity if anyone is using this. More easily, we could make the parameter 
> a no-op and never trim. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (MSHARED-953) trimming can remove all whitespace

2020-08-13 Thread Elliotte Rusty Harold (Jira)
Elliotte Rusty Harold created MSHARED-953:
-

 Summary: trimming can remove all whitespace
 Key: MSHARED-953
 URL: https://issues.apache.org/jira/browse/MSHARED-953
 Project: Maven Shared Components
  Issue Type: Bug
  Components: maven-shared-utils
Reporter: Elliotte Rusty Harold


The trim parameter in buildDom methods in Xpp3DomBuilder is base don a serious 
misunderstanding of how the characters method in SAX works. As currently 
written, trim can potentially remove all whitespace in text content from a 
document. A little more commonly, it will randomly remove or not remove 
whitespace depending on how the SAX parser chooses to split text nodes when it 
reports them.

It might be possible to implement this correctly at the cost of a lot of code 
complexity if anyone is using this. More easily, we could make the parameter a 
no-op and never trim. 
 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [maven-shared-utils] elharo commented on a change in pull request #61: [MSHARED-951] fix exception handling

2020-08-13 Thread GitBox


elharo commented on a change in pull request #61:
URL: https://github.com/apache/maven-shared-utils/pull/61#discussion_r469932352



##
File path: src/main/java/org/apache/maven/shared/utils/xml/Xpp3DomBuilder.java
##
@@ -84,14 +84,14 @@ public static Xpp3Dom build( @WillClose InputStream is, 
@Nonnull String encoding
 }
 catch ( UnsupportedEncodingException e )
 {
-throw new RuntimeException( e );
+throw new XmlPullParserException( e );
 }
 }
 
 /**
  * @param reader {@link Reader}

Review comment:
   fixed





This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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




[GitHub] [maven-shared-utils] pzygielo commented on a change in pull request #61: [MSHARED-951] fix exception handling

2020-08-13 Thread GitBox


pzygielo commented on a change in pull request #61:
URL: https://github.com/apache/maven-shared-utils/pull/61#discussion_r469920518



##
File path: src/main/java/org/apache/maven/shared/utils/xml/Xpp3DomBuilder.java
##
@@ -84,14 +84,14 @@ public static Xpp3Dom build( @WillClose InputStream is, 
@Nonnull String encoding
 }
 catch ( UnsupportedEncodingException e )
 {
-throw new RuntimeException( e );
+throw new XmlPullParserException( e );
 }
 }
 
 /**
  * @param reader {@link Reader}

Review comment:
   There is no such parameter `reader`, as in #58 it was renamed to `in`.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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




[jira] [Created] (MSHARED-952) Xpp3DomBuilderTest converts line separators for no good reason

2020-08-13 Thread Elliotte Rusty Harold (Jira)
Elliotte Rusty Harold created MSHARED-952:
-

 Summary: Xpp3DomBuilderTest converts line separators for no good 
reason
 Key: MSHARED-952
 URL: https://issues.apache.org/jira/browse/MSHARED-952
 Project: Maven Shared Components
  Issue Type: Improvement
  Components: maven-shared-utils
Reporter: Elliotte Rusty Harold


This makes the test platform dependent. All this code can be ripped out. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [maven-shared-utils] elharo opened a new pull request #61: fix exception handling

2020-08-13 Thread GitBox


elharo opened a new pull request #61:
URL: https://github.com/apache/maven-shared-utils/pull/61


   @pzygielo 



This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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




[jira] [Created] (MSHARED-951) Checked exception converted to raw runtime exception

2020-08-13 Thread Elliotte Rusty Harold (Jira)
Elliotte Rusty Harold created MSHARED-951:
-

 Summary: Checked exception converted to raw runtime exception
 Key: MSHARED-951
 URL: https://issues.apache.org/jira/browse/MSHARED-951
 Project: Maven Shared Components
  Issue Type: Bug
Reporter: Elliotte Rusty Harold
Assignee: Elliotte Rusty Harold


In Xpp3DOMBuilder

```
public static Xpp3Dom build( @WillClose InputStream is, @Nonnull String 
encoding, boolean trim )
throws XmlPullParserException
{
try
{
Reader reader = new InputStreamReader( is, encoding );
return build( reader, trim );
}
catch ( UnsupportedEncodingException e )
{
throw new RuntimeException( e );
}
}
```




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6928) CREATE: Call to Action design card

2020-08-13 Thread Ryan St. James (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17176946#comment-17176946
 ] 

Ryan St. James commented on MNG-6928:
-

[~rfscholte]  could you get me examples of the correct code that would show on 
each image? Then I will update the tickets with new images. 

> CREATE: Call to Action design card
> --
>
> Key: MNG-6928
> URL: https://issues.apache.org/jira/browse/MNG-6928
> Project: Maven
>  Issue Type: New Feature
>Reporter: Amelia Eiras
>Priority: Major
> Attachments: Maven-SM-Content.png, Maven-SM-Contributor.png, 
> Maven-SM-Contributor.png, Maven-SM-User.png, Maven-SM-User.png, 
> Maven-SM-User.png, Maven-SM-User.png, image-2020-08-11-19-04-07-654.png, 
> image-2020-08-11-19-04-07-776.png, image-2020-08-11-19-04-08-038.png, 
> image-2020-08-11-19-06-16-333.png, image-2020-08-11-19-06-16-469.png, 
> image-2020-08-11-19-06-16-615.png, image-2020-08-11-19-06-44-982.png
>
>
> general call out as Maven benefits for diverse contributions that are not 
> solely focused on code. 
> [Maven 
> Logos|https://drive.google.com/drive/folders/1oKAnZAlvUlck9XgNGUkr6UGgzEguY8n3?usp=sharing]
> Tomitribe will create the drafts. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (MRESOLVER-131) Introduce a Redisson-based SyncContextFactory

2020-08-13 Thread Michael Osipov (Jira)


 [ 
https://issues.apache.org/jira/browse/MRESOLVER-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MRESOLVER-131:
-
Fix Version/s: 1.5.1

> Introduce a Redisson-based SyncContextFactory
> -
>
> Key: MRESOLVER-131
> URL: https://issues.apache.org/jira/browse/MRESOLVER-131
> Project: Maven Resolver
>  Issue Type: New Feature
>  Components: resolver
>Affects Versions: 1.5.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.5.1
>
>
> Users have been plagued for years with missing concurrent access to the local 
> repository either from on JVM or multiple ones. It will finally solve a 13 
> years old issue: MNG-2802.
> Create a {{RedissonSyncContextFactory}} which will use one or multiple Redis 
> instances to hold Redisson reentrant read write locks. This will protect 
> artifacts as well as metadata to be accessed (written) concurrently.
> It should be easy to setup (extension) and default case requires zero 
> configuration.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (MRESOLVER-131) Introduce a Redisson-based SyncContextFactory

2020-08-13 Thread Michael Osipov (Jira)
Michael Osipov created MRESOLVER-131:


 Summary: Introduce a Redisson-based SyncContextFactory
 Key: MRESOLVER-131
 URL: https://issues.apache.org/jira/browse/MRESOLVER-131
 Project: Maven Resolver
  Issue Type: New Feature
  Components: resolver
Affects Versions: 1.5.0
Reporter: Michael Osipov
Assignee: Michael Osipov


Users have been plagued for years with missing concurrent access to the local 
repository either from on JVM or multiple ones. It will finally solve a 13 
years old issue: MNG-2802.

Create a {{RedissonSyncContextFactory}} which will use one or multiple Redis 
instances to hold Redisson reentrant read write locks. This will protect 
artifacts as well as metadata to be accessed (written) concurrently.

It should be easy to setup (extension) and default case requires zero 
configuration.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6843) Parallel build fails due to missing JAR artifacts in compilePath

2020-08-13 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17176867#comment-17176867
 ] 

Michael Osipov commented on MNG-6843:
-

FWIW, [~fkalinski] , you generate script ist not portable. It does not work 
with BSD sed. Please apply the following:

 {noformat}
index ddc4dbe..2285a68 100755
--- a/generate.sh
+++ b/generate.sh
@@ -1,4 +1,4 @@
 #!/bin/sh
 COUNT=$1
 find . -maxdepth 1 -type d -name 'child*' | grep -v 'child1$' | xargs rm -rf
-MODULES=$(for i in `seq 2 $COUNT`; do cp -a child1 child$i; sed -i 
"s/>child1child$ichild$i"; 
done); (cat pom-start; echo $MODULES; cat pom-end) > pom.xml
+MODULES=$(for i in `seq 2 $COUNT`; do cp -a child1 child$i; sed -i"" -e 
"s/>child1child$ichild$i"; 
done); (cat pom-start; echo $MODULES; cat pom-end) > pom.xml
 {noformat}

I expect it to work with GNU sed too.

> Parallel build fails due to missing JAR artifacts in compilePath
> 
>
> Key: MNG-6843
> URL: https://issues.apache.org/jira/browse/MNG-6843
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.6.3
> Environment: - Linux (tested Docker using maven:3-jdk-8 tag): happens 
> most times.
> - Windows 10: happens sometimes.
>Reporter: Stepan Hrbacek
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Build of our multi module (57) Java maven project is failing phase when 
> running it as parallel in 4 threads (mvn -T 4 clean install). The failure 
> happens during compilation because packages/classes from compile dependencies 
> cannot be found:
> {noformat}
> [main] [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile 
> (default-compile) on project common: Compilation failure: Compilation 
> failure: 
> [main] [ERROR] 
> /home/common/src/main/java/com/foo/ZonedDateTimeParser.java:[6,32] package 
> org.apache.commons.lang3 does not exist{noformat}
> After enabling debug logging (with thread names) I have found out that a 
> compile path of the failing module is empty (besides target/classes):
> When running in 4 threads (-T 4):
> {noformat}
> [BuilderThread 2] [DEBUG] (f) compilePath = [/home/common/target/classes]
> ...
> [BuilderThread 2] [DEBUG] Command line options:
> [BuilderThread 2] [DEBUG] -d /home/common/target/classes -classpath 
> /home/common/target/classes: -sourcepath 
> /home/common/src/main/java:/home/common/target/generated-sources/annotations: 
> -s /home/common/target/generated-sources/annotations -g -nowarn -target 1.8 
> -source 1.8 -encoding UTF-8{noformat}
> When running in a single thread (-T 1):
> {noformat}
> [BuilderThread 0] [DEBUG] (f) compilePath = [/home/common/target/classes, 
> /root/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar,
>  
> /root/.m2/repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar,
>  
> /root/.m2/repository/org/apache/commons/commons-collections4/4.3/commons-collections4-4.3.jar,
>  
> /root/.m2/repository/org/apache/commons/commons-lang3/3.9/commons-lang3-3.9.jar,
>  /root/.m2/repository/org/jooq/jool-java-8/0.9.14/jool-java-8-0.9.14.jar, 
> /root/.m2/repository/org/slf4j/slf4j-api/1.7.26/slf4j-api-1.7.26.jar, 
> /root/.m2/repository/org/springframework/spring-beans/5.1.8.RELEASE/spring-beans-5.1.8.RELEASE.jar,
>  
> /root/.m2/repository/org/springframework/spring-core/5.1.8.RELEASE/spring-core-5.1.8.RELEASE.jar,
>  
> /root/.m2/repository/org/springframework/spring-context/5.1.8.RELEASE/spring-context-5.1.8.RELEASE.jar]
> ...
> [BuilderThread 0] [DEBUG] Command line options:
> [BuilderThread 0] [DEBUG] -d /home/common/target/classes -classpath 
> /home/common/target/classes:/root/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar:/root/.m2/repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar:/root/.m2/repository/org/apache/commons/commons-collections4/4.3/commons-collections4-4.3.jar:/root/.m2/repository/org/apache/commons/commons-lang3/3.9/commons-lang3-3.9.jar:/root/.m2/repository/org/jooq/jool-java-8/0.9.14/jool-java-8-0.9.14.jar:/root/.m2/repository/org/slf4j/slf4j-api/1.7.26/slf4j-api-1.7.26.jar:/root/.m2/repository/org/springframework/spring-beans/5.1.8.RELEASE/spring-beans-5.1.8.RELEASE.jar:/root/.m2/repository/org/springframework/spring-core/5.1.8.RELEASE/spring-core-5.1.8.RELEASE.jar:/root/.m2/repository/org/springframework/spring-context/5.1.8.RELEASE/spring-context-5.1.8.RELEASE.jar:
>  -sourcepath 
> /home/common/src/main/java:/home/common/target/generated-sources/annotations: 
> -s /home/common/target/generated-sources/annotations -g -nowarn -target 1.8 
> -source 1.8 -encoding UTF-8{noformat}
> After adding custom log messages I have found out that the root 

[jira] [Created] (MNG-6977) Use hyphen when creating builder threads (names)

2020-08-13 Thread Michael Osipov (Jira)
Michael Osipov created MNG-6977:
---

 Summary: Use hyphen when creating builder threads (names)
 Key: MNG-6977
 URL: https://issues.apache.org/jira/browse/MNG-6977
 Project: Maven
  Issue Type: Improvement
  Components: core
Affects Versions: 3.6.3
Reporter: Michael Osipov
Assignee: Michael Osipov
 Fix For: 3.7.0-candidate


We currently create bulder threads as {{Builder Thread %d}}. This is bit 
problematic because you cannot properly {{grep}} or {{cut}} through this due to 
the while space. Most other use a hyphen and is then a snap to analyze debug 
output.

 

Proposal is to use {{BuilderThread-%d}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MRESOURCES-265) Resource copying not using specified encoding

2020-08-13 Thread Dennis Lundberg (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOURCES-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17176836#comment-17176836
 ] 

Dennis Lundberg commented on MRESOURCES-265:


Thanks for your report [~DuncanKinnear].

Were you able to determine which file caused the error, and the content and 
encoding of that file? That would help us to debug your problem. It would be 
great if you could attach that file to the issue, if possible.

Also it would help if you can cut-and-paste the  section of 
maven-resources-plugin and the / section of your POM.

> Resource copying not using specified encoding
> -
>
> Key: MRESOURCES-265
> URL: https://issues.apache.org/jira/browse/MRESOURCES-265
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: copy
>Affects Versions: 3.2.0
> Environment: Linux, CentOS 7
> Jenkins 2.251
> Jenkins Maven Integration plugin 3.1.2
> Java 1.8
>Reporter: Duncan Kinnear
>Priority: Major
>
> Overnight our Jenkins builds stopped working. On investigation we found that 
> maven-resources-plugin version used yesterday was 3.1.0 (which worked fine) 
> and today it was using 3.2.0.
> The stacktrace produced by adding the "e" switch to the maven command line 
> had the following root cause (truncated for brevity):-
> Caused by: java.nio.charset.MalformedInputException: Input length = 1
>  at java.nio.charset.CoderResult.throwException (CoderResult.java:281)
>  at sun.nio.cs.StreamDecoder.implRead (StreamDecoder.java:339)
>  at sun.nio.cs.StreamDecoder.read (StreamDecoder.java:178)
>  at java.io.InputStreamReader.read (InputStreamReader.java:184)
>  at java.io.BufferedReader.read1 (BufferedReader.java:210)
>  at java.io.BufferedReader.read (BufferedReader.java:286)
>  at java.io.BufferedReader.fill (BufferedReader.java:161)
>  at java.io.BufferedReader.read (BufferedReader.java:182)
>  at org.apache.maven.shared.filtering.BoundedReader.read 
> (BoundedReader.java:85)
>  at 
> org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read
>  (MultiDelimiterInterpolatorFilterReaderLineEnding.java:235)
>  at 
> org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read
>  (MultiDelimiterInterpolatorFilterReaderLineEnding.java:197)
>  at java.io.Reader.read (Reader.java:140)
>  at org.apache.maven.shared.utils.io.IOUtil.copy (IOUtil.java:199)
>  
> After a google search told us this was an encoding issue, we added the 
> following to the maven command line, but this made no difference:
> -Dproject.build.sourceEncoding=UTF-8 -Dproject.reporting.outputEncoding=UTF-8
>  
> The maven build log has these info messsage just before the error:
> [INFO] — maven-resources-plugin:3.2.0:resources (default-cli) @ uniworks —
>  [INFO] Using 'UTF-8' encoding to copy filtered resources.
>  [INFO] Using 'UTF-8' encoding to copy filtered properties files.
>  [INFO] Copying 430 resources
> We only 'fixed' the problem by specifying version 3.1.0 of the plugin in the 
> projects POM 'pluginManagement' section.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [maven-shared-utils] pzygielo commented on a change in pull request #58: remove call to deprecated method

2020-08-13 Thread GitBox


pzygielo commented on a change in pull request #58:
URL: https://github.com/apache/maven-shared-utils/pull/58#discussion_r469746624



##
File path: src/main/java/org/apache/maven/shared/utils/xml/Xpp3DomBuilder.java
##
@@ -95,10 +94,10 @@ public static Xpp3Dom build( @WillClose InputStream is, 
@Nonnull String encoding
  * @return the built dom
  * @throws XmlPullParserException in case of an error
  */
-public static Xpp3Dom build( @WillClose Reader reader, boolean trim )
+public static Xpp3Dom build( @WillClose Reader in, boolean trim )

Review comment:
   @param not updated





This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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