[jira] [Commented] (MPLUGIN-323) create @Requirement annotation to replace @Component (should be deprecated)

[Robert Scholte (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPLUGIN-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16483529#comment-16483529
 ] 

Robert Scholte commented on MPLUGIN-323:


Let's keep https://wiki.eclipse.org/Sisu/PlexusMigration in mind. To me 
@Component to @Requirement is like @Named to @Inject ,so I'm not sure if this 
would be an improvement.


> create @Requirement annotation to replace @Component (should be deprecated)
> ---
>
> Key: MPLUGIN-323
> URL: https://issues.apache.org/jira/browse/MPLUGIN-323
> Project: Maven Plugin Tools
>  Issue Type: Wish
>  Components: maven-plugin-annotations, maven-plugin-tools-javadoc
>Affects Versions: 3.5
>Reporter: Hervé Boutemy
>Priority: Major
> Fix For: 3.6
>
>
> injecting a Plexus component into a mojo is currently marked through 
> {{@Component}} annotation (or {{@component}} javadoc tag)
> This "component" term is misleading for 2 reasons:
> 1. in plugin descriptor, it creates a {{}} XML element: 
> http://maven.apache.org/ref/3-LATEST/maven-plugin-api/plugin.html#class_requirement
> 2. in Plexus, injecting is marked with {{@Requirement}} annotation, when 
> {{@Component}} is used to define a component: 
> http://codehaus-plexus.github.io/plexus-containers/plexus-component-annotations/
> This annotation creates great confusion for years, then even if Plexus is 
> being dropped for javax.inject, fixing this misleading terms would be 
> beneficial IMHO



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16483514#comment-16483514
 ] 

ASF GitHub Bot commented on SCM-885:


McFoggy commented on a change in pull request #74: [SCM-885] third 
implementation
URL: https://github.com/apache/maven-scm/pull/74#discussion_r189780680
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/changelog/GitChangeLogCommand.java
 ##
 @@ -89,17 +97,28 @@ protected ChangeLogScmResult executeChangeLogCommand( 
ChangeLogScmRequest reques
 final String datePattern = request.getDatePattern();
 return executeChangeLogCommand( 
request.getScmRepository().getProviderRepository(), fileSet,
 request.getStartDate(), request.getEndDate(), 
request.getScmBranch(), datePattern, startVersion,
-endVersion, request.getLimit() );
+endVersion, request.getLimit(), request.getRevision() );
 
 Review comment:
   which both? there are 10 parameters, 4 provided as variables, 6 as method 
calls on request variable.


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


> GitChangeLogCommand is wrong when only endVersion is set
> 
>
> Key: SCM-885
> URL: https://issues.apache.org/jira/browse/SCM-885
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5
>Reporter: Matthieu Brouillard
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.9.6
>
> Attachments: scm-885-different-behavior-exe-jgit-patch.diff
>
>
> Invoking execution of a GitChangeLogCommand where only the end revision has 
> been set produces a wrong out.
> +Actual result:+
> {{git whatchanged --date=iso  ..END_REVISION_SHA1 -- PROJECT_PATH}}
> +Expected result:+ only the end revison SHA1 is used without the two dots
> {{git whatchanged --date=iso  END_REVISION_SHA1 -- PROJECT_PATH}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] McFoggy commented on a change in pull request #74: [SCM-885] third implementation

[GitBox]

McFoggy commented on a change in pull request #74: [SCM-885] third 
implementation
URL: https://github.com/apache/maven-scm/pull/74#discussion_r189780680
 
 

 ##
 File path: 
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/changelog/GitChangeLogCommand.java
 ##
 @@ -89,17 +97,28 @@ protected ChangeLogScmResult executeChangeLogCommand( 
ChangeLogScmRequest reques
 final String datePattern = request.getDatePattern();
 return executeChangeLogCommand( 
request.getScmRepository().getProviderRepository(), fileSet,
 request.getStartDate(), request.getEndDate(), 
request.getScmBranch(), datePattern, startVersion,
-endVersion, request.getLimit() );
+endVersion, request.getLimit(), request.getRevision() );
 
 Review comment:
   which both? there are 10 parameters, 4 provided as variables, 6 as method 
calls on request variable.


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] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16483511#comment-16483511
 ] 

ASF GitHub Bot commented on SCM-885:


McFoggy commented on issue #74: [SCM-885] third implementation
URL: https://github.com/apache/maven-scm/pull/74#issuecomment-390867101
 
 
   Hi Mickael, was of for some days and could not answer before.
   
   > Why did you rename the test repo and have added a new one?
   Unless I did a mistake, I did not touch the existing one.
   But I have provided a new one in order to have known commits with a 
documentation on how the repo was built. We are talking about integration tests 
; I do not see a problem in providing more controlled ones.
   The repo is a direct result of a `git clone --bare`. I did not removed or 
added any files from the built bare repository.
   I'll amend the PR to take your other remarks into account.


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


> GitChangeLogCommand is wrong when only endVersion is set
> 
>
> Key: SCM-885
> URL: https://issues.apache.org/jira/browse/SCM-885
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5
>Reporter: Matthieu Brouillard
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.9.6
>
> Attachments: scm-885-different-behavior-exe-jgit-patch.diff
>
>
> Invoking execution of a GitChangeLogCommand where only the end revision has 
> been set produces a wrong out.
> +Actual result:+
> {{git whatchanged --date=iso  ..END_REVISION_SHA1 -- PROJECT_PATH}}
> +Expected result:+ only the end revison SHA1 is used without the two dots
> {{git whatchanged --date=iso  END_REVISION_SHA1 -- PROJECT_PATH}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16483512#comment-16483512
 ] 

ASF GitHub Bot commented on SCM-885:


McFoggy commented on issue #74: [SCM-885] third implementation
URL: https://github.com/apache/maven-scm/pull/74#issuecomment-390867101
 
 
   Hi Mickael, was of for some days and could not answer before.
   
   > Why did you rename the test repo and have added a new one?
   
   Unless I did a mistake, I did not touch the existing one.
   But I have provided a new one in order to have known commits with a 
documentation on how the repo was built. We are talking about integration tests 
; I do not see a problem in providing more controlled ones.
   The repo is a direct result of a `git clone --bare`. I did not removed or 
added any files from the built bare repository.
   I'll amend the PR to take your other remarks into account.


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


> GitChangeLogCommand is wrong when only endVersion is set
> 
>
> Key: SCM-885
> URL: https://issues.apache.org/jira/browse/SCM-885
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5
>Reporter: Matthieu Brouillard
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.9.6
>
> Attachments: scm-885-different-behavior-exe-jgit-patch.diff
>
>
> Invoking execution of a GitChangeLogCommand where only the end revision has 
> been set produces a wrong out.
> +Actual result:+
> {{git whatchanged --date=iso  ..END_REVISION_SHA1 -- PROJECT_PATH}}
> +Expected result:+ only the end revison SHA1 is used without the two dots
> {{git whatchanged --date=iso  END_REVISION_SHA1 -- PROJECT_PATH}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] McFoggy commented on issue #74: [SCM-885] third implementation

[GitBox]

McFoggy commented on issue #74: [SCM-885] third implementation
URL: https://github.com/apache/maven-scm/pull/74#issuecomment-390867101
 
 
   Hi Mickael, was of for some days and could not answer before.
   
   > Why did you rename the test repo and have added a new one?
   Unless I did a mistake, I did not touch the existing one.
   But I have provided a new one in order to have known commits with a 
documentation on how the repo was built. We are talking about integration tests 
; I do not see a problem in providing more controlled ones.
   The repo is a direct result of a `git clone --bare`. I did not removed or 
added any files from the built bare repository.
   I'll amend the PR to take your other remarks into account.


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] McFoggy commented on issue #74: [SCM-885] third implementation

[GitBox]

McFoggy commented on issue #74: [SCM-885] third implementation
URL: https://github.com/apache/maven-scm/pull/74#issuecomment-390867101
 
 
   Hi Mickael, was of for some days and could not answer before.
   
   > Why did you rename the test repo and have added a new one?
   
   Unless I did a mistake, I did not touch the existing one.
   But I have provided a new one in order to have known commits with a 
documentation on how the repo was built. We are talking about integration tests 
; I do not see a problem in providing more controlled ones.
   The repo is a direct result of a `git clone --bare`. I did not removed or 
added any files from the built bare repository.
   I'll amend the PR to take your other remarks into account.


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] [Created] (MDEP-615) Could not find method getCompileConfiguration() for arguments[]

[anuj namjoshi (JIRA)]

anuj namjoshi created MDEP-615:
--

 Summary: Could not find method getCompileConfiguration() for 
arguments[]
 Key: MDEP-615
 URL: https://issues.apache.org/jira/browse/MDEP-615
 Project: Maven Dependency Plugin
  Issue Type: Bug
  Components: sources
Affects Versions: 3.1.0
Reporter: anuj namjoshi


 I am using mavenCentral, i am getting following error.

Could not find method getCompileConfiguration() for arguments [] on object of 
type com.android.build.gradle.internal.api.ApplicationVariantImpl.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MNG-6413) Redesign proxies in Settings

[Robert Scholte (JIRA)]

Robert Scholte created MNG-6413:
---

 Summary: Redesign proxies in Settings
 Key: MNG-6413
 URL: https://issues.apache.org/jira/browse/MNG-6413
 Project: Maven
  Issue Type: Task
  Components: Settings
Reporter: Robert Scholte


The design of proxies doesn't match the with the real world anymore.
It is important that multiple protocols are supported, quite often handled by 
the same proxy. Also, the non-proxy is a global setting, not a per-proxy one.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6401) Cannot interpolate property in proxy port of settings.xml

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MNG-6401:
-

hboutemy commented on issue #163: [MNG-6401] - Cannot interpolate property in 
proxy port of settings.xml
URL: https://github.com/apache/maven/pull/163#issuecomment-390789509
 
 
   branch 6401-2 pushed, with port and active fields as String and handwritten 
methods to provide compatibility


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


> Cannot interpolate property in proxy port of settings.xml
> -
>
> Key: MNG-6401
> URL: https://issues.apache.org/jira/browse/MNG-6401
> Project: Maven
>  Issue Type: Bug
>  Components: Bootstrap  Build
>Affects Versions: 3.0, 3.5.3
>Reporter: KATADA Junya
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.6.0-candidate
>
>
> If you use a property in proxy port of settings.xml, the property is not 
> replaced and the port number is "0" instead of property value.
> My minimal demo about this problem is 
> [here|https://github.com/jkatada/maven-property-demo]. 
> In my demo, export two environment variables as follows.
> {code}
> export MAVEN_PROXY_HOST_STRING=proxy.foo.com
> export MAVEN_PROXY_PORT_INT=18080
> {code}
> These variables are used in settings.xml for proxy settings.
> {code:xml}
> 
>     my_proxy
>     true
>     http
>     ${env.MAVEN_PROXY_HOST_STRING}
>     ${env.MAVEN_PROXY_PORT_INT}
>     local.net|some.host.com
>  
> {code}
> Execute maven-help-plugin to show effective settings.xml.
> {code}
> mvn help:effective-settings -X
> {code}
> The result is as follows.
> {code:xml}
> 
>     0
>     proxy.foo.com
>     local.net|some.host.com
>     my_proxy
> 
>  {code}
> `*${env.MAVEN_PROXY_HOST_STRING}*` is replaced with `*proxy.foo.com*`, 
>  but `*${env.MAVEN_PROXY_PORT_INT}*` is not replaced with `*18080*`.
> I found the following WARNING message in console.
> {code:java}
> [WARNING] Some problems were encountered while building the effective settings
> [WARNING] Unable to parse element 'port', must be an integer (position: 
> END_TAG seen ...${env.MAVEN_PROXY_PORT_INT}... @12:47) caused 
> by: java.lang.NumberFormatException: For input string: 
> "${env.MAVEN_PROXY_PORT_INT}" @ /root/.m2/settings.xml, line 12, column 47
> {code}
> I think that the cause of this problem is to parse settings.xml before 
> interpolation.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] hboutemy commented on issue #163: [MNG-6401] - Cannot interpolate property in proxy port of settings.xml

[GitBox]

hboutemy commented on issue #163: [MNG-6401] - Cannot interpolate property in 
proxy port of settings.xml
URL: https://github.com/apache/maven/pull/163#issuecomment-390789509
 
 
   branch 6401-2 pushed, with port and active fields as String and handwritten 
methods to provide compatibility


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] (MNG-6401) Cannot interpolate property in proxy port of settings.xml

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MNG-6401:
-

hboutemy commented on issue #163: [MNG-6401] - Cannot interpolate property in 
proxy port of settings.xml
URL: https://github.com/apache/maven/pull/163#issuecomment-390782288
 
 
   on handwritten, look at optional field in maven.mdo
   I'm working on another branch to apply the same strategy: I'm currently 
running core-its to check it works as expected, will report soon
   


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


> Cannot interpolate property in proxy port of settings.xml
> -
>
> Key: MNG-6401
> URL: https://issues.apache.org/jira/browse/MNG-6401
> Project: Maven
>  Issue Type: Bug
>  Components: Bootstrap  Build
>Affects Versions: 3.0, 3.5.3
>Reporter: KATADA Junya
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.6.0-candidate
>
>
> If you use a property in proxy port of settings.xml, the property is not 
> replaced and the port number is "0" instead of property value.
> My minimal demo about this problem is 
> [here|https://github.com/jkatada/maven-property-demo]. 
> In my demo, export two environment variables as follows.
> {code}
> export MAVEN_PROXY_HOST_STRING=proxy.foo.com
> export MAVEN_PROXY_PORT_INT=18080
> {code}
> These variables are used in settings.xml for proxy settings.
> {code:xml}
> 
>     my_proxy
>     true
>     http
>     ${env.MAVEN_PROXY_HOST_STRING}
>     ${env.MAVEN_PROXY_PORT_INT}
>     local.net|some.host.com
>  
> {code}
> Execute maven-help-plugin to show effective settings.xml.
> {code}
> mvn help:effective-settings -X
> {code}
> The result is as follows.
> {code:xml}
> 
>     0
>     proxy.foo.com
>     local.net|some.host.com
>     my_proxy
> 
>  {code}
> `*${env.MAVEN_PROXY_HOST_STRING}*` is replaced with `*proxy.foo.com*`, 
>  but `*${env.MAVEN_PROXY_PORT_INT}*` is not replaced with `*18080*`.
> I found the following WARNING message in console.
> {code:java}
> [WARNING] Some problems were encountered while building the effective settings
> [WARNING] Unable to parse element 'port', must be an integer (position: 
> END_TAG seen ...${env.MAVEN_PROXY_PORT_INT}... @12:47) caused 
> by: java.lang.NumberFormatException: For input string: 
> "${env.MAVEN_PROXY_PORT_INT}" @ /root/.m2/settings.xml, line 12, column 47
> {code}
> I think that the cause of this problem is to parse settings.xml before 
> interpolation.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] hboutemy commented on issue #163: [MNG-6401] - Cannot interpolate property in proxy port of settings.xml

[GitBox]

hboutemy commented on issue #163: [MNG-6401] - Cannot interpolate property in 
proxy port of settings.xml
URL: https://github.com/apache/maven/pull/163#issuecomment-390782288
 
 
   on handwritten, look at optional field in maven.mdo
   I'm working on another branch to apply the same strategy: I'm currently 
running core-its to check it works as expected, will report soon
   


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-6401) Cannot interpolate property in proxy port of settings.xml

[Michael Osipov (JIRA)]

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

Michael Osipov updated MNG-6401:

Fix Version/s: (was: 3.5.4-candidate)
   3.6.0-candidate

> Cannot interpolate property in proxy port of settings.xml
> -
>
> Key: MNG-6401
> URL: https://issues.apache.org/jira/browse/MNG-6401
> Project: Maven
>  Issue Type: Bug
>  Components: Bootstrap  Build
>Affects Versions: 3.0, 3.5.3
>Reporter: KATADA Junya
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.6.0-candidate
>
>
> If you use a property in proxy port of settings.xml, the property is not 
> replaced and the port number is "0" instead of property value.
> My minimal demo about this problem is 
> [here|https://github.com/jkatada/maven-property-demo]. 
> In my demo, export two environment variables as follows.
> {code}
> export MAVEN_PROXY_HOST_STRING=proxy.foo.com
> export MAVEN_PROXY_PORT_INT=18080
> {code}
> These variables are used in settings.xml for proxy settings.
> {code:xml}
> 
>     my_proxy
>     true
>     http
>     ${env.MAVEN_PROXY_HOST_STRING}
>     ${env.MAVEN_PROXY_PORT_INT}
>     local.net|some.host.com
>  
> {code}
> Execute maven-help-plugin to show effective settings.xml.
> {code}
> mvn help:effective-settings -X
> {code}
> The result is as follows.
> {code:xml}
> 
>     0
>     proxy.foo.com
>     local.net|some.host.com
>     my_proxy
> 
>  {code}
> `*${env.MAVEN_PROXY_HOST_STRING}*` is replaced with `*proxy.foo.com*`, 
>  but `*${env.MAVEN_PROXY_PORT_INT}*` is not replaced with `*18080*`.
> I found the following WARNING message in console.
> {code:java}
> [WARNING] Some problems were encountered while building the effective settings
> [WARNING] Unable to parse element 'port', must be an integer (position: 
> END_TAG seen ...${env.MAVEN_PROXY_PORT_INT}... @12:47) caused 
> by: java.lang.NumberFormatException: For input string: 
> "${env.MAVEN_PROXY_PORT_INT}" @ /root/.m2/settings.xml, line 12, column 47
> {code}
> I think that the cause of this problem is to parse settings.xml before 
> interpolation.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6401) Cannot interpolate property in proxy port of settings.xml

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MNG-6401:
-

michael-o commented on issue #163: [MNG-6401] - Cannot interpolate property in 
proxy port of settings.xml
URL: https://github.com/apache/maven/pull/163#issuecomment-390731655
 
 
   > I know that we have such a case with booleans, where we do not put the 
effective field type in the descriptor but String for more flexibility: in this 
boolean case, it was about inheritance, to make the difference between 
inheriting and overriding with a value.
   Then there is a hand-written getter to get the field as boolean (instead of 
the internal String)
   
   This is another issue with our interpolation. Can you point me to that 
handwritten spot?
   
   > I don't know if we have such cases in Maven core with ints, but the 
previous pattern hand-writing a typed getter to int should do the job.
   
   The core model does not use ints, but only booleans for activation.
   
   > switch back to String based interpolation instead of Object interpolation?
   
   I don't see any quality difference between those two, from user POV
   
   > change the field from int to String and add the hand-written getter?
   
   This is going to be hard because a lot of our code relies on the int 
#getPort().
   
   If this PR breaks our approach w/o understanding previous motives, I'd stall 
it for 3.6.0 or later.


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


> Cannot interpolate property in proxy port of settings.xml
> -
>
> Key: MNG-6401
> URL: https://issues.apache.org/jira/browse/MNG-6401
> Project: Maven
>  Issue Type: Bug
>  Components: Bootstrap  Build
>Affects Versions: 3.0, 3.5.3
>Reporter: KATADA Junya
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.5.4-candidate
>
>
> If you use a property in proxy port of settings.xml, the property is not 
> replaced and the port number is "0" instead of property value.
> My minimal demo about this problem is 
> [here|https://github.com/jkatada/maven-property-demo]. 
> In my demo, export two environment variables as follows.
> {code}
> export MAVEN_PROXY_HOST_STRING=proxy.foo.com
> export MAVEN_PROXY_PORT_INT=18080
> {code}
> These variables are used in settings.xml for proxy settings.
> {code:xml}
> 
>     my_proxy
>     true
>     http
>     ${env.MAVEN_PROXY_HOST_STRING}
>     ${env.MAVEN_PROXY_PORT_INT}
>     local.net|some.host.com
>  
> {code}
> Execute maven-help-plugin to show effective settings.xml.
> {code}
> mvn help:effective-settings -X
> {code}
> The result is as follows.
> {code:xml}
> 
>     0
>     proxy.foo.com
>     local.net|some.host.com
>     my_proxy
> 
>  {code}
> `*${env.MAVEN_PROXY_HOST_STRING}*` is replaced with `*proxy.foo.com*`, 
>  but `*${env.MAVEN_PROXY_PORT_INT}*` is not replaced with `*18080*`.
> I found the following WARNING message in console.
> {code:java}
> [WARNING] Some problems were encountered while building the effective settings
> [WARNING] Unable to parse element 'port', must be an integer (position: 
> END_TAG seen ...${env.MAVEN_PROXY_PORT_INT}... @12:47) caused 
> by: java.lang.NumberFormatException: For input string: 
> "${env.MAVEN_PROXY_PORT_INT}" @ /root/.m2/settings.xml, line 12, column 47
> {code}
> I think that the cause of this problem is to parse settings.xml before 
> interpolation.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] michael-o commented on issue #163: [MNG-6401] - Cannot interpolate property in proxy port of settings.xml

[GitBox]

michael-o commented on issue #163: [MNG-6401] - Cannot interpolate property in 
proxy port of settings.xml
URL: https://github.com/apache/maven/pull/163#issuecomment-390731655
 
 
   > I know that we have such a case with booleans, where we do not put the 
effective field type in the descriptor but String for more flexibility: in this 
boolean case, it was about inheritance, to make the difference between 
inheriting and overriding with a value.
   Then there is a hand-written getter to get the field as boolean (instead of 
the internal String)
   
   This is another issue with our interpolation. Can you point me to that 
handwritten spot?
   
   > I don't know if we have such cases in Maven core with ints, but the 
previous pattern hand-writing a typed getter to int should do the job.
   
   The core model does not use ints, but only booleans for activation.
   
   > switch back to String based interpolation instead of Object interpolation?
   
   I don't see any quality difference between those two, from user POV
   
   > change the field from int to String and add the hand-written getter?
   
   This is going to be hard because a lot of our code relies on the int 
#getPort().
   
   If this PR breaks our approach w/o understanding previous motives, I'd stall 
it for 3.6.0 or later.


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] (MNG-6364) Enhanced Jenkinsfile to test Core with JDK 9

[Hudson (JIRA)]

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

Hudson commented on MNG-6364:
-

Build succeeded in Jenkins: Maven TLP » maven » MNG-6364 #20

See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6364/20/

> Enhanced Jenkinsfile to test Core with JDK 9
> 
>
> Key: MNG-6364
> URL: https://issues.apache.org/jira/browse/MNG-6364
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap  Build
>Affects Versions: 3.5.3
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.4
>
>
> currently, Maven core is build with one configuration OS+JDK+Maven
>  then it is tested (ie [Maven Core ITs|https://maven.apache.org/core-its/] 
> are built and executed) in misc configurations:
>  - Java 7 and Java 8
>  - Linux and Windows
> Now that Java 9 and even Java 10 are out, it would be useful to add Java 9 
> and even Java 10 to the tests



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MASSEMBLY-887) Magically merged conflicting classpath

[Michael Osipov (JIRA)]

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

Michael Osipov closed MASSEMBLY-887.

Resolution: Not A Problem

The mediation happens on the shortest path to a dependency. The assembly plugin 
handles all request to the core. If you have questions regarding Maven, use the 
mailing list please. There is no bug here since you didn't show me any.

> Magically merged conflicting classpath 
> ---
>
> Key: MASSEMBLY-887
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-887
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: component descriptor
>Affects Versions: 3.1.0
>Reporter: Michał
>Priority: Major
>
> I have found this issue, while migrating a project from Maven to SBT.
> To describe the problem I have created an example project with dependencies 
> that I found to behave differently, depending on the build tool.
> [https://github.com/atais/mvn-sbt-assembly]
>  
> The only dependencies are (sbt style)
> {code:java}
> "com.netflix.astyanax" % "astyanax-cassandra" % "3.9.0", 
> "org.apache.cassandra" % "cassandra-all" % "3.4",{code}
> and what I do not understand is, why {{mvn package}} creates the fat jar 
> successfully, while {{sbt assembly}} gives conflicts:
> {code:java}
> [error] 39 errors were encountered during merge [error] 
> java.lang.RuntimeException: deduplicate: different file contents found in the 
> following: [error] 
> /home/siatkowskim/.ivy2/cache/org.slf4j/jcl-over-slf4j/jars/jcl-over-slf4j-1.7.7.jar:org/apache/commons/logging/  classes> [error] 
> /home/siatkowskim/.ivy2/cache/commons-logging/commons-logging/jars/commons-logging-1.1.1.jar:org/apache/commons/logging/  classes> ... [error] 
> /home/siatkowskim/.ivy2/cache/com.github.stephenc.high-scale-lib/high-scale-lib/jars/high-scale-lib-1.1.2.jar:org/cliffc/high_scale_lib/  classes> [error] 
> /home/siatkowskim/.ivy2/cache/com.boundary/high-scale-lib/jars/high-scale-lib-1.0.6.jar:org/cliffc/high_scale_lib/  classes> ...{code}
> *{{So I wonder, how come this plugin overcomes this conflicts?}}*
> {{I have also created a SO question, if one would like to earn some points: 
> [https://stackoverflow.com/questions/50249818/why-maven-assembly-works-when-sbt-assembly-find-conflicts]}}
> {{ }}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-5814) Be able to verify the pgp signature of downloaded plugins against a trust configuration

[JIRA]

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

Hervé Boutemy updated MNG-5814:
---
Summary: Be able to verify the pgp signature of downloaded plugins against 
a trust configuration  (was: Be able to verify the pgp signature of downloaded 
plugins)

> Be able to verify the pgp signature of downloaded plugins against a trust 
> configuration
> ---
>
> Key: MNG-5814
> URL: https://issues.apache.org/jira/browse/MNG-5814
> Project: Maven
>  Issue Type: Improvement
>  Components: Plugin Requests
>Reporter: Alexander Kjäll
>Priority: Major
>  Labels: security
>
> In order to protect ourself against an attacker that can do injection attacks 
> on our downloads we need to verify the pgp signatures of the downloaded 
> artifacts.
> For normal dependencies this can be done with a plugin, for example this one: 
> https://github.com/s4u/pgpverify-maven-plugin/
> But it's not possible for a plugin to verify it's own authenticity, as it was 
> downloaded over an possible insecure channel itself.
> Therefor we need something preinstalled that verifies that the plugin we 
> downloaded is the same one that was specified in our pom file.
> I propose that functionality is added to maven that verifies the jar and pom 
> files against it's pgp signature files for plugins. And some sort of notation 
> is added to the pom file so that it's possible to specify the signing key for 
> a plugin. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] Tibor17 commented on a change in pull request #184: Donate current sources from junit-platform-surefire-provider

[GitBox]

Tibor17 commented on a change in pull request #184: Donate current sources from 
junit-platform-surefire-provider
URL: https://github.com/apache/maven-surefire/pull/184#discussion_r189634127
 
 

 ##
 File path: maven-surefire-plugin/src/site/apt/examples/junit-platform.apt.vm
 ##
 @@ -0,0 +1,206 @@
+ --
+ Using JUnit Platform
+ --
+ JUnit Lambda Team 
+ --
+ 2018-05-14
+ --
+ 
+ ~~ 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.
+
+ ~~ NOTE: For help with the syntax of this file, see:
+ ~~ http://maven.apache.org/doxia/references/apt-format.html 
+
+Using JUnit Platform
+
+* Configuring JUnit Platform
+
+  To get started with JUnit Platform, you need to add at least a single 
<<>> implementation
+  to your project. For example, if you want to write tests with Jupiter, you 
must add the
+  <<>> to the dependencies like:
+
++---+
+
+  [...]
+
+  org.junit.jupiter
+  junit-jupiter-engine
+  5.2.0
+  test
+
+  [...]
+
++---+
+
+  This will pull in all required dependencies. Among those dependencies is 
<<>> which contains
+  the classes and interfaces your test source requires to compile. 
<<>> is also resolved and
+  added.
+
+  This is the only step that is required to get started - you can now create 
tests in your test source directory
+  (e.g., <<>>).
+
+  If you want to write and execute JUnit 3 or 4 tests via the JUnit Platform 
add the Vintage Engine to your projects'
+  dependencies:
+
++---+
+
+  [...]
+
+  org.junit.vintage
+  junit-vintage-engine
+  5.2.0
+  test
+
+  [...]
+
++---+
+
+* Provider Selection
+
+   If nothing is configured, Surefire detects which JUnit version to use by 
the following algorithm:
+
++---+
+if the JUnit Platform Engine is present in the project
+use junit-platform
+if the JUnit version in the project >= 4.7 and the parallel attribute has ANY 
value
+use junit47 provider
+if JUnit >= 4.0 is present
+use junit4 provider
+else
+use junit3.8.1
++---+
+
+  When using this technique there is no check that the proper test-frameworks 
are present on your project's
+  classpath. Failing to add the proper test-frameworks will result in a build 
failure.
+
+* Running Tests in Parallel
+
+  From JUnit Platform does not support running tests in parallel.
+
+* Running a Single Test Class
+
+   The JUnit Platform Provider supports the <<>> JVM system property 
supported by
+   the Maven Surefire Plugin. For example, to run only test methods in the 
<<>> test class
+   you can execute <<>> from the command 
line.
+
+
+* Filtering by Test Class Names
+
+   The Maven Surefire Plugin will scan for test classes whose fully qualified 
names match
+   the following patterns.
+
+   * <<<**/Test*.java>>>
+
+   * <<<**/*Test.java>>>
+
+   * <<<**/*Tests.java>>>
+
+   * <<<**/*TestCase.java>>>
+
+Moreover, it will exclude all nested classes (including static member classes) 
by default.
+
+Note, however, that you can override this default behavior by configuring 
explicit
+`include` and `exclude` rules in your `pom.xml` file. For example, to keep 
Maven Surefire
+from excluding static member classes, you can override its exclude rules.
+
+Overriding exclude rules of Maven Surefire
+
++---+
+...
+
+
+...
+
+maven-surefire-plugin
+{surefire-version}
+
+
+
+
+
+...
+
+
+
+...
++---+
+
+
+* Filtering by Tags
+
+You can filter tests by tags or tag expressions using the following 
configuration properties.
+
+* to include <<>> or <<>>, use either <<>> 
or <<>>.
+
+* to exclude <<>> or <<>>, use either 
<<>> or <<>>.
+
++---+
+...
+
+
+...
+
+maven-surefire-plugin
+{surefire-version}
+
+
+acceptance | !feature-a
+integration, regression
+
+
+
+...
+
+
+
+
+...
++---+
+
+
+* Configuration Parameters
+
+   You can set JUnit Platform configuration parameters to influence 

[jira] [Comment Edited] (MASSEMBLY-887) Magically merged conflicting classpath

[JIRA]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482393#comment-16482393
 ] 

Michał edited comment on MASSEMBLY-887 at 5/21/18 3:26 PM:
---

I am actually trying to report, what you have described as correct:
{code:java}
The dependency is properly mediated. {code}
How do you know it is done correctly? Could you please share it with me how it 
is currently handled?



I see a classpath error of (f.e)
 * com.boundary:high-scale-lib:1.0.6 (dependency of 
org.apache.cassandra:cassandra-all:3.4)
 * com.github.stephenc.high-scale-lib:high-scale-lib:1.1.2 (dependency of  
com.netflix.astyanax:astyanax-core:3.9.0)

Since they both contain some classes, like
 * org/cliffc/high_scale_lib/NonBlockingSetInt.class

 

SBT is only here for reference, since it reports what I think should be 
reported.
I would like to understand how maven-assembly-plugin solves it automatically, 
since to me it looks like a place for potential error.

 

 


was (Author: atais):
I am actually trying to report, what you have described as correct:
{code:java}
The dependency is properly mediated. {code}
How do you know it is done correctly? Could you please share it with me?



I see a classpath error of (f.e)
 * com.boundary:high-scale-lib:1.0.6 (dependency of 
org.apache.cassandra:cassandra-all:3.4)
 * com.github.stephenc.high-scale-lib:high-scale-lib:1.1.2 (dependency of  
com.netflix.astyanax:astyanax-core:3.9.0)

Since they both contain some classes, like
 * org/cliffc/high_scale_lib/NonBlockingSetInt.class

 

SBT is only here for reference, since it reports what I think should be 
reported.
I would like to understand how maven-assembly-plugin solves it automatically, 
since to me it looks like a place for potential error.

 

 

> Magically merged conflicting classpath 
> ---
>
> Key: MASSEMBLY-887
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-887
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: component descriptor
>Affects Versions: 3.1.0
>Reporter: Michał
>Priority: Major
>
> I have found this issue, while migrating a project from Maven to SBT.
> To describe the problem I have created an example project with dependencies 
> that I found to behave differently, depending on the build tool.
> [https://github.com/atais/mvn-sbt-assembly]
>  
> The only dependencies are (sbt style)
> {code:java}
> "com.netflix.astyanax" % "astyanax-cassandra" % "3.9.0", 
> "org.apache.cassandra" % "cassandra-all" % "3.4",{code}
> and what I do not understand is, why {{mvn package}} creates the fat jar 
> successfully, while {{sbt assembly}} gives conflicts:
> {code:java}
> [error] 39 errors were encountered during merge [error] 
> java.lang.RuntimeException: deduplicate: different file contents found in the 
> following: [error] 
> /home/siatkowskim/.ivy2/cache/org.slf4j/jcl-over-slf4j/jars/jcl-over-slf4j-1.7.7.jar:org/apache/commons/logging/  classes> [error] 
> /home/siatkowskim/.ivy2/cache/commons-logging/commons-logging/jars/commons-logging-1.1.1.jar:org/apache/commons/logging/  classes> ... [error] 
> /home/siatkowskim/.ivy2/cache/com.github.stephenc.high-scale-lib/high-scale-lib/jars/high-scale-lib-1.1.2.jar:org/cliffc/high_scale_lib/  classes> [error] 
> /home/siatkowskim/.ivy2/cache/com.boundary/high-scale-lib/jars/high-scale-lib-1.0.6.jar:org/cliffc/high_scale_lib/  classes> ...{code}
> *{{So I wonder, how come this plugin overcomes this conflicts?}}*
> {{I have also created a SO question, if one would like to earn some points: 
> [https://stackoverflow.com/questions/50249818/why-maven-assembly-works-when-sbt-assembly-find-conflicts]}}
> {{ }}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SUREFIRE-1523) Adding item to JceKeyStore fails when non-forking with JDK 8_171

[Jonathan Coustick (JIRA)]

Jonathan Coustick created SUREFIRE-1523:
---

 Summary: Adding item to JceKeyStore fails when non-forking with 
JDK 8_171
 Key: SUREFIRE-1523
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1523
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin, process forking
Affects Versions: 2.21.0
Reporter: Jonathan Coustick


When putting an item in a JceKeyStore in Java 1.8.0_171 where forkCount is 0 it 
fails with InvalidSecretKeyFormat. This does not occur in Java 1.8.0_162 or 
when forkCount is 1.

The full stacktrace is:

{{}}
{code:java}
java.io.IOException: Invalid secret key format
    at com.sun.crypto.provider.JceKeyStore.engineLoad(JceKeyStore.java:856)
    at java.security.KeyStore.load(KeyStore.java:1445)
    at  
fish.payara.jcekstest.PasswordAdapter.loadKeyStore(PasswordAdapter.java:116)
    at 
fish.payara.jcekstest.PasswordAdapter.writeKeyStoreSafe(PasswordAdapter.java:303)
    at 
fish.payara.jcekstest.PasswordAdapter.writeStore(PasswordAdapter.java:184)
    at 
fish.payara.jcekstest.PasswordAdapter.setPasswordForAlias(PasswordAdapter.java:202)
    at 
fish.payara.jcekstest.JCEKSPasswordAliasStore.put(JCEKSPasswordAliasStore.java:104)
    at 
fish.payara.jcekstest.PasswordAliasTest.checkStoreAndGetPWByAlias(PasswordAliasTest.java:97)
    at 
fish.payara.jcekstest.PasswordAliasTest.checkLongPW(PasswordAliasTest.java:93)
    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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
    at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
    at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
    at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
    at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
    at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
    at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
    at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
    at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
    at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
    at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
    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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:206)
    at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:160)
    at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:83)
    at 
org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:87)
    at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1132)
    at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:978)
    at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:854)
    at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
    at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
    at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
    at 

[jira] [Commented] (MJAVADOC-521) Add documentation information for GitHub

[Robert Scholte (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482508#comment-16482508
 ] 

Robert Scholte commented on MJAVADOC-521:
-

[~khmarbaise] is the branch ready to be merged?

> Add documentation information for GitHub
> 
>
> Key: MJAVADOC-521
> URL: https://issues.apache.org/jira/browse/MJAVADOC-521
> Project: Maven Javadoc Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.1
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MJAVADOC-516) Replace usage of deprecated HttpClient code

[Robert Scholte (JIRA)]

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

Robert Scholte updated MJAVADOC-516:

Fix Version/s: (was: 3.0.1)
   3.1.0

> Replace usage of deprecated HttpClient code
> ---
>
> Key: MJAVADOC-516
> URL: https://issues.apache.org/jira/browse/MJAVADOC-516
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
>Priority: Minor
> Fix For: 3.1.0
>
>
> Since HttpClient 4.3, classes like {{DefaultHttpClient}} [were 
> deprecated|https://archive.apache.org/dist/httpcomponents/httpclient/RELEASE_NOTES-4.3.x.txt]
>  in favor of using builder classes to create immutable {{HttpClient}} 
> instances. As a consequence, we should update the code to use the newer APIs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MJAVADOC-510) Investigate JavadocUtil.invokeMaven

[Robert Scholte (JIRA)]

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

Robert Scholte updated MJAVADOC-510:

Fix Version/s: (was: 3.0.1)
   3.1.0

> Investigate JavadocUtil.invokeMaven
> ---
>
> Key: MJAVADOC-510
> URL: https://issues.apache.org/jira/browse/MJAVADOC-510
> Project: Maven Javadoc Plugin
>  Issue Type: Task
>Reporter: Stephen Connolly
>Priority: Major
> Fix For: 3.1.0
>
>
> Spotted while fine-tuning the Jenkinsfile builds. Unclear why Javadoc plugin 
> needs to fork Maven and whether it is doing it the correct way if the 
> requirement is actually valid.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MJAVADOC-447) Command line dump reveals proxy user/password in case of errors

[Robert Scholte (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482501#comment-16482501
 ] 

Robert Scholte commented on MJAVADOC-447:
-

Needs to be investigated again after upgrading to plexus-utils 3.1.0

> Command line dump reveals proxy user/password in case of errors
> ---
>
> Key: MJAVADOC-447
> URL: https://issues.apache.org/jira/browse/MJAVADOC-447
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
> Environment: Maven version: 2.0.7 Java version: 1.4.2 OS name: 
> "windows xp" version: "5.1" arch: "x86"
>Reporter: Christian K.
>Assignee: Robert Scholte
>Priority: Minor
>
> If http proxy is set, in case of error calling javadoc, the whole command 
> line call is dumped out on console.
> This can reveal sensible information about personal proxy settings (user and 
> password) which are passed
> via -J-Dhttp.proxyUser= and -J-Dhttp.proxyPassword= arguments to the javadoc 
> executable.
> For example:
> Command line was:"C:\Program 
> Files\IBM\WebSphere\AppServer\java\jre\..\bin\javadoc.exe" 
> -J-DproxyHost=urlofmyproxy -J-DproxyPort=8080 -J-Dhttp.proxySet=true 
> -J-Dhttp.proxyHost=urlofmyproxy -J-Dhttp.proxyPort=8080 
> -J-Dhttp.nonProxyHosts="myinternalrepo" -J-Dhttp.proxyUser="FOO" 
> -J-Dhttp.proxyPassword="BAR" @options @packages
> If this can be an issue, consider hiding these values in the dump.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MJAVADOC-447) Command line dump reveals proxy user/password in case of errors

[Robert Scholte (JIRA)]

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

Robert Scholte updated MJAVADOC-447:

Fix Version/s: (was: 3.0.1)

> Command line dump reveals proxy user/password in case of errors
> ---
>
> Key: MJAVADOC-447
> URL: https://issues.apache.org/jira/browse/MJAVADOC-447
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
> Environment: Maven version: 2.0.7 Java version: 1.4.2 OS name: 
> "windows xp" version: "5.1" arch: "x86"
>Reporter: Christian K.
>Assignee: Robert Scholte
>Priority: Minor
>
> If http proxy is set, in case of error calling javadoc, the whole command 
> line call is dumped out on console.
> This can reveal sensible information about personal proxy settings (user and 
> password) which are passed
> via -J-Dhttp.proxyUser= and -J-Dhttp.proxyPassword= arguments to the javadoc 
> executable.
> For example:
> Command line was:"C:\Program 
> Files\IBM\WebSphere\AppServer\java\jre\..\bin\javadoc.exe" 
> -J-DproxyHost=urlofmyproxy -J-DproxyPort=8080 -J-Dhttp.proxySet=true 
> -J-Dhttp.proxyHost=urlofmyproxy -J-Dhttp.proxyPort=8080 
> -J-Dhttp.nonProxyHosts="myinternalrepo" -J-Dhttp.proxyUser="FOO" 
> -J-Dhttp.proxyPassword="BAR" @options @packages
> If this can be an issue, consider hiding these values in the dump.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MJAVADOC-519) IT detectLinks fails on Windows

[Robert Scholte (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482499#comment-16482499
 ] 

Robert Scholte commented on MJAVADOC-519:
-

I cannot reproduce this issue, can we close it?

> IT detectLinks fails on Windows
> ---
>
> Key: MJAVADOC-519
> URL: https://issues.apache.org/jira/browse/MJAVADOC-519
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 3.0.1
>
> Attachments: failing-javadoc-it.log
>
>
> [Currently|https://gitbox.apache.org/repos/asf?p=maven-javadoc-plugin.git;a=commitdiff;h=e637834a1aecaaa835fe2cdcda67664156f3630d]
>  the following IT is failing:
> {code}
> [windows-jdk9] [INFO]   Passed: 35, Failed: 1, Errors: 0, Skipped: 0
> [windows-jdk9] [INFO] -
> [windows-jdk9] [WARNING] The following builds failed:
> [windows-jdk9] [WARNING] *  detectLinks\pom.xml
> [windows-jdk9] [INFO] -
> [windows-jdk9] [WARNING] Ignoring that 1 build failed.
> [windows-jdk9] [INFO] 
> 
> [windows-jdk9] [INFO] BUILD SUCCESS
> [windows-jdk9] [INFO] ---
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MJAVADOC-520) Upgrade plexus-utils/qdox/plexus-archiver/

[Robert Scholte (JIRA)]

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

Robert Scholte closed MJAVADOC-520.
---
Resolution: Fixed

Fixed in 
[8e47dca880c40c69a59af03e36c59f76e4c14ef7|https://gitbox.apache.org/repos/asf?p=maven-javadoc-plugin.git;a=commit;h=8e47dca880c40c69a59af03e36c59f76e4c14ef7]

> Upgrade plexus-utils/qdox/plexus-archiver/
> --
>
> Key: MJAVADOC-520
> URL: https://issues.apache.org/jira/browse/MJAVADOC-520
> Project: Maven Javadoc Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.1
>Reporter: Karl Heinz Marbaise
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.0.1
>
>
> * -plexus-utils to 3.1.0-
> * qdox to 2.0-M8
> * plexus-archiver 3.5, 3.6.0
> * plexus-utils-3.1.0
> * maven-archiver 3.2.0
> * plexus-interactivity-api 1.0-alpha-6
> * plexus-java 0.9.8



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MJAVADOC-520) Upgrade plexus-utils/qdox/plexus-archiver/

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482487#comment-16482487
 ] 

Hudson commented on MJAVADOC-520:
-

Build succeeded in Jenkins: Maven TLP » maven-javadoc-plugin » master #35

See 
https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/master/35/

> Upgrade plexus-utils/qdox/plexus-archiver/
> --
>
> Key: MJAVADOC-520
> URL: https://issues.apache.org/jira/browse/MJAVADOC-520
> Project: Maven Javadoc Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.1
>Reporter: Karl Heinz Marbaise
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.0.1
>
>
> * -plexus-utils to 3.1.0-
> * qdox to 2.0-M8
> * plexus-archiver 3.5, 3.6.0
> * plexus-utils-3.1.0
> * maven-archiver 3.2.0
> * plexus-interactivity-api 1.0-alpha-6
> * plexus-java 0.9.8



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (MJAVADOC-520) Upgrade plexus-utils/qdox/plexus-archiver/

[Robert Scholte (JIRA)]

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

Robert Scholte reassigned MJAVADOC-520:
---

Assignee: Robert Scholte  (was: Karl Heinz Marbaise)

> Upgrade plexus-utils/qdox/plexus-archiver/
> --
>
> Key: MJAVADOC-520
> URL: https://issues.apache.org/jira/browse/MJAVADOC-520
> Project: Maven Javadoc Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.1
>Reporter: Karl Heinz Marbaise
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.0.1
>
>
> * -plexus-utils to 3.1.0-
> * qdox to 2.0-M8
> * plexus-archiver 3.5, 3.6.0
> * plexus-utils-3.1.0
> * maven-archiver 3.2.0
> * plexus-interactivity-api 1.0-alpha-6
> * plexus-java 0.9.8



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MJAVADOC-512) Even when 1.8.0 matches there still is a warning.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482463#comment-16482463
 ] 

Hudson commented on MJAVADOC-512:
-

Build succeeded in Jenkins: Maven TLP » maven-javadoc-plugin » MJAVADOC-520 #7

See 
https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/MJAVADOC-520/7/

> Even when 1.8.0 matches there still is a 
> warning.
> --
>
> Key: MJAVADOC-512
> URL: https://issues.apache.org/jira/browse/MJAVADOC-512
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: javadoc
>Affects Versions: 3.0.0
>Reporter: Jene Jasper
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.1
>
>
> Even when {{1.8.0}} matches there still is 
> the following log message:
> {quote}[WARNING] Are you sure about the parameter? It seems to be 1.8.0.
> {quote}
>  
> See [https://github.com/apache/maven-javadoc-plugin/pull/1]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MJAVADOC-519) IT detectLinks fails on Windows

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482462#comment-16482462
 ] 

Hudson commented on MJAVADOC-519:
-

Build succeeded in Jenkins: Maven TLP » maven-javadoc-plugin » MJAVADOC-520 #7

See 
https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/MJAVADOC-520/7/

> IT detectLinks fails on Windows
> ---
>
> Key: MJAVADOC-519
> URL: https://issues.apache.org/jira/browse/MJAVADOC-519
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 3.0.1
>
> Attachments: failing-javadoc-it.log
>
>
> [Currently|https://gitbox.apache.org/repos/asf?p=maven-javadoc-plugin.git;a=commitdiff;h=e637834a1aecaaa835fe2cdcda67664156f3630d]
>  the following IT is failing:
> {code}
> [windows-jdk9] [INFO]   Passed: 35, Failed: 1, Errors: 0, Skipped: 0
> [windows-jdk9] [INFO] -
> [windows-jdk9] [WARNING] The following builds failed:
> [windows-jdk9] [WARNING] *  detectLinks\pom.xml
> [windows-jdk9] [INFO] -
> [windows-jdk9] [WARNING] Ignoring that 1 build failed.
> [windows-jdk9] [INFO] 
> 
> [windows-jdk9] [INFO] BUILD SUCCESS
> [windows-jdk9] [INFO] ---
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNGSITE-332) Changed download templates of plugins not to reference .md5 anymore

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482464#comment-16482464
 ] 

Hudson commented on MNGSITE-332:


Build succeeded in Jenkins: Maven TLP » maven-javadoc-plugin » MJAVADOC-520 #7

See 
https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/MJAVADOC-520/7/

> Changed download templates of plugins not to reference .md5 anymore
> ---
>
> Key: MNGSITE-332
> URL: https://issues.apache.org/jira/browse/MNGSITE-332
> Project: Maven Project Web Site
>  Issue Type: Task
>Reporter: Karl Heinz Marbaise
>Priority: Critical
>
> Currently we have links to md5 checksums for the plugin download pages this 
> has to be changed into links to {{sha1}} and {{sha256}} instead.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MJAVADOC-520) Upgrade plexus-utils/qdox/plexus-archiver/

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482465#comment-16482465
 ] 

Hudson commented on MJAVADOC-520:
-

Build succeeded in Jenkins: Maven TLP » maven-javadoc-plugin » MJAVADOC-520 #7

See 
https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/MJAVADOC-520/7/

> Upgrade plexus-utils/qdox/plexus-archiver/
> --
>
> Key: MJAVADOC-520
> URL: https://issues.apache.org/jira/browse/MJAVADOC-520
> Project: Maven Javadoc Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.1
>
>
> * -plexus-utils to 3.1.0-
> * qdox to 2.0-M8
> * plexus-archiver 3.5, 3.6.0
> * plexus-utils-3.1.0
> * maven-archiver 3.2.0
> * plexus-interactivity-api 1.0-alpha-6
> * plexus-java 0.9.8



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MJAVADOC-520) Upgrade plexus-utils/qdox/plexus-archiver/

[Robert Scholte (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482456#comment-16482456
 ] 

Robert Scholte commented on MJAVADOC-520:
-

Reverted upgrade of plexus-utils to 3.1.0, the proxyTest fails, which also 
exposes another issue: the generated 
{{target/test/unit/proxy-test/target/site/apidocs/javadoc.bat}} is useless 
because the generated commandline is invalid.

> Upgrade plexus-utils/qdox/plexus-archiver/
> --
>
> Key: MJAVADOC-520
> URL: https://issues.apache.org/jira/browse/MJAVADOC-520
> Project: Maven Javadoc Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.1
>
>
> * -plexus-utils to 3.1.0-
> * qdox to 2.0-M8
> * plexus-archiver 3.5, 3.6.0
> * plexus-utils-3.1.0
> * maven-archiver 3.2.0
> * plexus-interactivity-api 1.0-alpha-6
> * plexus-java 0.9.8



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6401) Cannot interpolate property in proxy port of settings.xml

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MNG-6401:
-

hboutemy commented on issue #163: [MNG-6401] - Cannot interpolate property in 
proxy port of settings.xml
URL: https://github.com/apache/maven/pull/163#issuecomment-390640786
 
 
   on String interpolation vs Object interpolation:
   String based interpolation was replaced by Object interpolation a few years 
ago (perhaps during the switch from Maven 2 to Maven 3, I need to get precise 
facts if necessary): I don't precisely know why (is Object interpolation more 
robust, against XML injection?)
   
   what I see in this precise case of proxy port interpolation: it's an int, 
then it's hard to do Object interpolation on "${param}" value once it has been 
transfrmed to a String...
   at least, this give us the good root cause: if we want interpolation with 
Object implementation, we need to change the field type to String
   
   I know that we have such a case with booleans, where we do not put the 
effective field type in the descriptor but String for more flexibility: in this 
boolean case, it was about inheritance, to make the difference between 
inheriting and overriding with a value.
   Then there is a hand-written getter to get the field as boolean (instead of 
the internal String)
   
   I don't know if we have such cases in Maven core with ints, but the previous 
pattern hand-writing a typed getter to int should do the job.
   
   Now what's the best solution for now:
   - switch back to String based interpolation instead of Object interpolation?
   - change the field from int to String and add the hand-written getter?
   
   at this time, I don't have strong opinion: I wanted to write and share the 
analysis.
   
   Now I need to dig into the reasons why we switched from String based 
interpolation to Object based: this is where we should find the best view on 
what issue could arise when getting back to former solution


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


> Cannot interpolate property in proxy port of settings.xml
> -
>
> Key: MNG-6401
> URL: https://issues.apache.org/jira/browse/MNG-6401
> Project: Maven
>  Issue Type: Bug
>  Components: Bootstrap  Build
>Affects Versions: 3.0, 3.5.3
>Reporter: KATADA Junya
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.5.4-candidate
>
>
> If you use a property in proxy port of settings.xml, the property is not 
> replaced and the port number is "0" instead of property value.
> My minimal demo about this problem is 
> [here|https://github.com/jkatada/maven-property-demo]. 
> In my demo, export two environment variables as follows.
> {code}
> export MAVEN_PROXY_HOST_STRING=proxy.foo.com
> export MAVEN_PROXY_PORT_INT=18080
> {code}
> These variables are used in settings.xml for proxy settings.
> {code:xml}
> 
>     my_proxy
>     true
>     http
>     ${env.MAVEN_PROXY_HOST_STRING}
>     ${env.MAVEN_PROXY_PORT_INT}
>     local.net|some.host.com
>  
> {code}
> Execute maven-help-plugin to show effective settings.xml.
> {code}
> mvn help:effective-settings -X
> {code}
> The result is as follows.
> {code:xml}
> 
>     0
>     proxy.foo.com
>     local.net|some.host.com
>     my_proxy
> 
>  {code}
> `*${env.MAVEN_PROXY_HOST_STRING}*` is replaced with `*proxy.foo.com*`, 
>  but `*${env.MAVEN_PROXY_PORT_INT}*` is not replaced with `*18080*`.
> I found the following WARNING message in console.
> {code:java}
> [WARNING] Some problems were encountered while building the effective settings
> [WARNING] Unable to parse element 'port', must be an integer (position: 
> END_TAG seen ...${env.MAVEN_PROXY_PORT_INT}... @12:47) caused 
> by: java.lang.NumberFormatException: For input string: 
> "${env.MAVEN_PROXY_PORT_INT}" @ /root/.m2/settings.xml, line 12, column 47
> {code}
> I think that the cause of this problem is to parse settings.xml before 
> interpolation.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] hboutemy commented on issue #163: [MNG-6401] - Cannot interpolate property in proxy port of settings.xml

[GitBox]

hboutemy commented on issue #163: [MNG-6401] - Cannot interpolate property in 
proxy port of settings.xml
URL: https://github.com/apache/maven/pull/163#issuecomment-390640786
 
 
   on String interpolation vs Object interpolation:
   String based interpolation was replaced by Object interpolation a few years 
ago (perhaps during the switch from Maven 2 to Maven 3, I need to get precise 
facts if necessary): I don't precisely know why (is Object interpolation more 
robust, against XML injection?)
   
   what I see in this precise case of proxy port interpolation: it's an int, 
then it's hard to do Object interpolation on "${param}" value once it has been 
transfrmed to a String...
   at least, this give us the good root cause: if we want interpolation with 
Object implementation, we need to change the field type to String
   
   I know that we have such a case with booleans, where we do not put the 
effective field type in the descriptor but String for more flexibility: in this 
boolean case, it was about inheritance, to make the difference between 
inheriting and overriding with a value.
   Then there is a hand-written getter to get the field as boolean (instead of 
the internal String)
   
   I don't know if we have such cases in Maven core with ints, but the previous 
pattern hand-writing a typed getter to int should do the job.
   
   Now what's the best solution for now:
   - switch back to String based interpolation instead of Object interpolation?
   - change the field from int to String and add the hand-written getter?
   
   at this time, I don't have strong opinion: I wanted to write and share the 
analysis.
   
   Now I need to dig into the reasons why we switched from String based 
interpolation to Object based: this is where we should find the best view on 
what issue could arise when getting back to former solution


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] (MJAVADOC-520) Upgrade plexus-utils/qdox/plexus-archiver/

[Robert Scholte (JIRA)]

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

Robert Scholte updated MJAVADOC-520:

Description: 
* -plexus-utils to 3.1.0-
* qdox to 2.0-M8
* plexus-archiver 3.5, 3.6.0
* plexus-utils-3.1.0
* maven-archiver 3.2.0
* plexus-interactivity-api 1.0-alpha-6
* plexus-java 0.9.8

  was:
* plexus-utils to 3.1.0
* qdox to 2.0-M8
* plexus-archiver 3.5, 3.6.0
* plexus-utils-3.1.0
* maven-archiver 3.2.0
* plexus-interactivity-api 1.0-alpha-6
* plexus-java 0.9.8


> Upgrade plexus-utils/qdox/plexus-archiver/
> --
>
> Key: MJAVADOC-520
> URL: https://issues.apache.org/jira/browse/MJAVADOC-520
> Project: Maven Javadoc Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.1
>
>
> * -plexus-utils to 3.1.0-
> * qdox to 2.0-M8
> * plexus-archiver 3.5, 3.6.0
> * plexus-utils-3.1.0
> * maven-archiver 3.2.0
> * plexus-interactivity-api 1.0-alpha-6
> * plexus-java 0.9.8



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] marcphilipp commented on a change in pull request #184: Donate current sources from junit-platform-surefire-provider

[GitBox]

marcphilipp commented on a change in pull request #184: Donate current sources 
from junit-platform-surefire-provider
URL: https://github.com/apache/maven-surefire/pull/184#discussion_r189572469
 
 

 ##
 File path: maven-surefire-plugin/src/site/apt/examples/junit-platform.apt.vm
 ##
 @@ -0,0 +1,206 @@
+ --
+ Using JUnit Platform
+ --
+ JUnit Lambda Team 
+ --
+ 2018-05-14
+ --
+ 
+ ~~ 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.
+
+ ~~ NOTE: For help with the syntax of this file, see:
+ ~~ http://maven.apache.org/doxia/references/apt-format.html 
+
+Using JUnit Platform
+
+* Configuring JUnit Platform
+
+  To get started with JUnit Platform, you need to add at least a single 
<<>> implementation
+  to your project. For example, if you want to write tests with Jupiter, you 
must add the
+  <<>> to the dependencies like:
+
++---+
+
+  [...]
+
+  org.junit.jupiter
+  junit-jupiter-engine
+  5.2.0
+  test
+
+  [...]
+
++---+
+
+  This will pull in all required dependencies. Among those dependencies is 
<<>> which contains
+  the classes and interfaces your test source requires to compile. 
<<>> is also resolved and
+  added.
+
+  This is the only step that is required to get started - you can now create 
tests in your test source directory
+  (e.g., <<>>).
+
+  If you want to write and execute JUnit 3 or 4 tests via the JUnit Platform 
add the Vintage Engine to your projects'
+  dependencies:
+
++---+
+
+  [...]
+
+  org.junit.vintage
+  junit-vintage-engine
+  5.2.0
+  test
+
+  [...]
+
++---+
+
+* Provider Selection
+
+   If nothing is configured, Surefire detects which JUnit version to use by 
the following algorithm:
+
++---+
+if the JUnit Platform Engine is present in the project
+use junit-platform
+if the JUnit version in the project >= 4.7 and the parallel attribute has ANY 
value
+use junit47 provider
+if JUnit >= 4.0 is present
+use junit4 provider
+else
+use junit3.8.1
++---+
+
+  When using this technique there is no check that the proper test-frameworks 
are present on your project's
+  classpath. Failing to add the proper test-frameworks will result in a build 
failure.
+
+* Running Tests in Parallel
+
+  From JUnit Platform does not support running tests in parallel.
+
+* Running a Single Test Class
+
+   The JUnit Platform Provider supports the <<>> JVM system property 
supported by
+   the Maven Surefire Plugin. For example, to run only test methods in the 
<<>> test class
+   you can execute <<>> from the command 
line.
+
+
+* Filtering by Test Class Names
+
+   The Maven Surefire Plugin will scan for test classes whose fully qualified 
names match
+   the following patterns.
+
+   * <<<**/Test*.java>>>
+
+   * <<<**/*Test.java>>>
+
+   * <<<**/*Tests.java>>>
+
+   * <<<**/*TestCase.java>>>
+
+Moreover, it will exclude all nested classes (including static member classes) 
by default.
+
+Note, however, that you can override this default behavior by configuring 
explicit
+`include` and `exclude` rules in your `pom.xml` file. For example, to keep 
Maven Surefire
+from excluding static member classes, you can override its exclude rules.
+
+Overriding exclude rules of Maven Surefire
+
++---+
+...
+
+
+...
+
+maven-surefire-plugin
+{surefire-version}
+
+
+
+
+
+...
+
+
+
+...
++---+
+
+
+* Filtering by Tags
+
+You can filter tests by tags or tag expressions using the following 
configuration properties.
+
+* to include <<>> or <<>>, use either <<>> 
or <<>>.
+
+* to exclude <<>> or <<>>, use either 
<<>> or <<>>.
+
++---+
+...
+
+
+...
+
+maven-surefire-plugin
+{surefire-version}
+
+
+acceptance | !feature-a
+integration, regression
+
+
+
+...
+
+
+
+
+...
++---+
+
+
+* Configuration Parameters
+
+   You can set JUnit Platform configuration parameters to 

[jira] [Commented] (MPLUGIN-339) maven-plugin-tools-javadoc broken by com.sun.tools.doclets removal in Java 10

[Emmanuel Bourg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPLUGIN-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482440#comment-16482440
 ] 

Emmanuel Bourg commented on MPLUGIN-339:


What about packaging the com.sun.tools.doclets API as a separate artifact 
uploaded to Maven Central?

> maven-plugin-tools-javadoc broken by com.sun.tools.doclets removal in Java 10
> -
>
> Key: MPLUGIN-339
> URL: https://issues.apache.org/jira/browse/MPLUGIN-339
> Project: Maven Plugin Tools
>  Issue Type: Bug
>  Components: maven-plugin-tools-javadoc
>Affects Versions: 3.5.1
>Reporter: Emmanuel Bourg
>Priority: Major
> Fix For: 3.6
>
>
> The com.sun.tools.doclets API is no longer available in Java 10, this breaks 
> the maven-plugin-tools-javadoc module.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MJAVADOC-447) Command line dump reveals proxy user/password in case of errors

[Robert Scholte (JIRA)]

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

Robert Scholte updated MJAVADOC-447:

Fix Version/s: 3.0.1

> Command line dump reveals proxy user/password in case of errors
> ---
>
> Key: MJAVADOC-447
> URL: https://issues.apache.org/jira/browse/MJAVADOC-447
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
> Environment: Maven version: 2.0.7 Java version: 1.4.2 OS name: 
> "windows xp" version: "5.1" arch: "x86"
>Reporter: Christian K.
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.0.1
>
>
> If http proxy is set, in case of error calling javadoc, the whole command 
> line call is dumped out on console.
> This can reveal sensible information about personal proxy settings (user and 
> password) which are passed
> via -J-Dhttp.proxyUser= and -J-Dhttp.proxyPassword= arguments to the javadoc 
> executable.
> For example:
> Command line was:"C:\Program 
> Files\IBM\WebSphere\AppServer\java\jre\..\bin\javadoc.exe" 
> -J-DproxyHost=urlofmyproxy -J-DproxyPort=8080 -J-Dhttp.proxySet=true 
> -J-Dhttp.proxyHost=urlofmyproxy -J-Dhttp.proxyPort=8080 
> -J-Dhttp.nonProxyHosts="myinternalrepo" -J-Dhttp.proxyUser="FOO" 
> -J-Dhttp.proxyPassword="BAR" @options @packages
> If this can be an issue, consider hiding these values in the dump.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (MJAVADOC-447) Command line dump reveals proxy user/password in case of errors

[Robert Scholte (JIRA)]

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

Robert Scholte reassigned MJAVADOC-447:
---

Assignee: Robert Scholte  (was: Siveton Vincent)

> Command line dump reveals proxy user/password in case of errors
> ---
>
> Key: MJAVADOC-447
> URL: https://issues.apache.org/jira/browse/MJAVADOC-447
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
> Environment: Maven version: 2.0.7 Java version: 1.4.2 OS name: 
> "windows xp" version: "5.1" arch: "x86"
>Reporter: Christian K.
>Assignee: Robert Scholte
>Priority: Minor
>
> If http proxy is set, in case of error calling javadoc, the whole command 
> line call is dumped out on console.
> This can reveal sensible information about personal proxy settings (user and 
> password) which are passed
> via -J-Dhttp.proxyUser= and -J-Dhttp.proxyPassword= arguments to the javadoc 
> executable.
> For example:
> Command line was:"C:\Program 
> Files\IBM\WebSphere\AppServer\java\jre\..\bin\javadoc.exe" 
> -J-DproxyHost=urlofmyproxy -J-DproxyPort=8080 -J-Dhttp.proxySet=true 
> -J-Dhttp.proxyHost=urlofmyproxy -J-Dhttp.proxyPort=8080 
> -J-Dhttp.nonProxyHosts="myinternalrepo" -J-Dhttp.proxyUser="FOO" 
> -J-Dhttp.proxyPassword="BAR" @options @packages
> If this can be an issue, consider hiding these values in the dump.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MASSEMBLY-887) Magically merged conflicting classpath

[JIRA]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482393#comment-16482393
 ] 

Michał edited comment on MASSEMBLY-887 at 5/21/18 10:50 AM:


I am actually trying to report, what you have described as correct:
{code:java}
The dependency is properly mediated. {code}
How do you know it is done correctly? Could you please share it with me?



I see a classpath error of (f.e)
 * com.boundary:high-scale-lib:1.0.6 (dependency of 
org.apache.cassandra:cassandra-all:3.4)
 * com.github.stephenc.high-scale-lib:high-scale-lib:1.1.2 (dependency of  
com.netflix.astyanax:astyanax-core:3.9.0)

Since they both contain some classes, like
 * org/cliffc/high_scale_lib/NonBlockingSetInt.class

 

SBT is only here for reference, since it reports what I think should be 
reported.
I would like to understand how maven-assembly-plugin solves it automatically, 
since to me it looks like a place for potential error.

 

 


was (Author: atais):
I am actually trying to report, what you have described as correct:
{code:java}
The dependency is properly mediated. {code}
How do you know it is done correctly? Could you please share it with me?



I see a classpath error of (f.e)
 * com.boundary:high-scale-lib:1.0.6 (dependency of 
org.apache.cassandra:cassandra-all:3.4)
 * com.github.stephenc.high-scale-lib:high-scale-lib:1.1.2 (dependency of  
com.netflix.astyanax:astyanax-core:3.9.0)

Since they both contain some classes, like
 * org/cliffc/high_scale_lib/NonBlockingSetInt.class

 

SBT is only here for reference, since it reports what I think should be 
reported.
I woule like to understand how maven-assembly-plugin solves it automatically.

 

> Magically merged conflicting classpath 
> ---
>
> Key: MASSEMBLY-887
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-887
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: component descriptor
>Affects Versions: 3.1.0
>Reporter: Michał
>Priority: Major
>
> I have found this issue, while migrating a project from Maven to SBT.
> To describe the problem I have created an example project with dependencies 
> that I found to behave differently, depending on the build tool.
> [https://github.com/atais/mvn-sbt-assembly]
>  
> The only dependencies are (sbt style)
> {code:java}
> "com.netflix.astyanax" % "astyanax-cassandra" % "3.9.0", 
> "org.apache.cassandra" % "cassandra-all" % "3.4",{code}
> and what I do not understand is, why {{mvn package}} creates the fat jar 
> successfully, while {{sbt assembly}} gives conflicts:
> {code:java}
> [error] 39 errors were encountered during merge [error] 
> java.lang.RuntimeException: deduplicate: different file contents found in the 
> following: [error] 
> /home/siatkowskim/.ivy2/cache/org.slf4j/jcl-over-slf4j/jars/jcl-over-slf4j-1.7.7.jar:org/apache/commons/logging/  classes> [error] 
> /home/siatkowskim/.ivy2/cache/commons-logging/commons-logging/jars/commons-logging-1.1.1.jar:org/apache/commons/logging/  classes> ... [error] 
> /home/siatkowskim/.ivy2/cache/com.github.stephenc.high-scale-lib/high-scale-lib/jars/high-scale-lib-1.1.2.jar:org/cliffc/high_scale_lib/  classes> [error] 
> /home/siatkowskim/.ivy2/cache/com.boundary/high-scale-lib/jars/high-scale-lib-1.0.6.jar:org/cliffc/high_scale_lib/  classes> ...{code}
> *{{So I wonder, how come this plugin overcomes this conflicts?}}*
> {{I have also created a SO question, if one would like to earn some points: 
> [https://stackoverflow.com/questions/50249818/why-maven-assembly-works-when-sbt-assembly-find-conflicts]}}
> {{ }}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MASSEMBLY-887) Magically merged conflicting classpath

[JIRA]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482393#comment-16482393
 ] 

Michał commented on MASSEMBLY-887:
--

I am actually trying to report, what you have described as correct:
{code:java}
The dependency is properly mediated. {code}
How do you know it is done correctly? Could you please share it with me?



I see a classpath error of (f.e)
 * com.boundary:high-scale-lib:1.0.6 (dependency of 
org.apache.cassandra:cassandra-all:3.4)
 * com.github.stephenc.high-scale-lib:high-scale-lib:1.1.2 (dependency of  
com.netflix.astyanax:astyanax-core:3.9.0)

Since they both contain some classes, like
 * org/cliffc/high_scale_lib/NonBlockingSetInt.class

 

SBT is only here for reference, since it reports what I think should be 
reported.
I woule like to understand how maven-assembly-plugin solves it automatically.

 

> Magically merged conflicting classpath 
> ---
>
> Key: MASSEMBLY-887
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-887
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: component descriptor
>Affects Versions: 3.1.0
>Reporter: Michał
>Priority: Major
>
> I have found this issue, while migrating a project from Maven to SBT.
> To describe the problem I have created an example project with dependencies 
> that I found to behave differently, depending on the build tool.
> [https://github.com/atais/mvn-sbt-assembly]
>  
> The only dependencies are (sbt style)
> {code:java}
> "com.netflix.astyanax" % "astyanax-cassandra" % "3.9.0", 
> "org.apache.cassandra" % "cassandra-all" % "3.4",{code}
> and what I do not understand is, why {{mvn package}} creates the fat jar 
> successfully, while {{sbt assembly}} gives conflicts:
> {code:java}
> [error] 39 errors were encountered during merge [error] 
> java.lang.RuntimeException: deduplicate: different file contents found in the 
> following: [error] 
> /home/siatkowskim/.ivy2/cache/org.slf4j/jcl-over-slf4j/jars/jcl-over-slf4j-1.7.7.jar:org/apache/commons/logging/  classes> [error] 
> /home/siatkowskim/.ivy2/cache/commons-logging/commons-logging/jars/commons-logging-1.1.1.jar:org/apache/commons/logging/  classes> ... [error] 
> /home/siatkowskim/.ivy2/cache/com.github.stephenc.high-scale-lib/high-scale-lib/jars/high-scale-lib-1.1.2.jar:org/cliffc/high_scale_lib/  classes> [error] 
> /home/siatkowskim/.ivy2/cache/com.boundary/high-scale-lib/jars/high-scale-lib-1.0.6.jar:org/cliffc/high_scale_lib/  classes> ...{code}
> *{{So I wonder, how come this plugin overcomes this conflicts?}}*
> {{I have also created a SO question, if one would like to earn some points: 
> [https://stackoverflow.com/questions/50249818/why-maven-assembly-works-when-sbt-assembly-find-conflicts]}}
> {{ }}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-6364) Enhanced Jenkinsfile to test Core with JDK 9

[JIRA]

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

Hervé Boutemy updated MNG-6364:
---
Description: 
currently, Maven core is build with one configuration OS+JDK+Maven
 then it is tested (ie [Maven Core ITs|https://maven.apache.org/core-its/] are 
built and executed) in misc configurations:
 - Java 7 and Java 8
 - Linux and Windows

Now that Java 9 and even Java 10 are out, it would be useful to add Java 9 and 
even Java 10 to the tests

  was:
currently, Maven core is build with one configuration OS+JDK+Maven
then it is tested (ie Maven Core ITs are built and executed) in misc 
configurations:
- Java 7 and Java 8
- Linux and Windows

Now that Java 9 and even Java 10 are out, it would be useful to add Java 9 and 
even Java 10 to the tests


> Enhanced Jenkinsfile to test Core with JDK 9
> 
>
> Key: MNG-6364
> URL: https://issues.apache.org/jira/browse/MNG-6364
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap  Build
>Affects Versions: 3.5.3
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.4
>
>
> currently, Maven core is build with one configuration OS+JDK+Maven
>  then it is tested (ie [Maven Core ITs|https://maven.apache.org/core-its/] 
> are built and executed) in misc configurations:
>  - Java 7 and Java 8
>  - Linux and Windows
> Now that Java 9 and even Java 10 are out, it would be useful to add Java 9 
> and even Java 10 to the tests



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-6364) Enhanced Jenkinsfile to test Core with JDK 9

[JIRA]

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

Hervé Boutemy updated MNG-6364:
---
Description: 
currently, Maven core is build with one configuration OS+JDK+Maven
then it is tested (ie Maven Core ITs are built and executed) in misc 
configurations:
- Java 7 and Java 8
- Linux and Windows

Now that Java 9 and even Java 10 are out, it would be useful to add Java 9 and 
even Java 10 to the tests

> Enhanced Jenkinsfile to test Core with JDK 9
> 
>
> Key: MNG-6364
> URL: https://issues.apache.org/jira/browse/MNG-6364
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap  Build
>Affects Versions: 3.5.3
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.4
>
>
> currently, Maven core is build with one configuration OS+JDK+Maven
> then it is tested (ie Maven Core ITs are built and executed) in misc 
> configurations:
> - Java 7 and Java 8
> - Linux and Windows
> Now that Java 9 and even Java 10 are out, it would be useful to add Java 9 
> and even Java 10 to the tests



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-6364) Enhanced Jenkinsfile to test Core with JDK 9

[JIRA]

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

Hervé Boutemy updated MNG-6364:
---
Summary: Enhanced Jenkinsfile to test Core with JDK 9  (was: Enhanced 
Jenkinsfile to Build Core with JDK 9)

> Enhanced Jenkinsfile to test Core with JDK 9
> 
>
> Key: MNG-6364
> URL: https://issues.apache.org/jira/browse/MNG-6364
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap  Build
>Affects Versions: 3.5.3
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.4
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MJAVADOC-520) Upgrade plexus-utils/qdox/plexus-archiver/

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482382#comment-16482382
 ] 

Hudson commented on MJAVADOC-520:
-

Build unstable in Jenkins: Maven TLP » maven-javadoc-plugin » MJAVADOC-520 #6

See 
https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/MJAVADOC-520/6/

> Upgrade plexus-utils/qdox/plexus-archiver/
> --
>
> Key: MJAVADOC-520
> URL: https://issues.apache.org/jira/browse/MJAVADOC-520
> Project: Maven Javadoc Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.1
>
>
> * plexus-utils to 3.1.0
> * qdox to 2.0-M8
> * plexus-archiver 3.5, 3.6.0
> * plexus-utils-3.1.0
> * maven-archiver 3.2.0
> * plexus-interactivity-api 1.0-alpha-6
> * plexus-java 0.9.8



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MASSEMBLY-887) Magically merged conflicting classpath

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482365#comment-16482365
 ] 

Michael Osipov commented on MASSEMBLY-887:
--

I do not see a problem here with Maven. The dependency is properly mediated. 
You have an issue with SBT. What are you trying to report?

> Magically merged conflicting classpath 
> ---
>
> Key: MASSEMBLY-887
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-887
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: component descriptor
>Affects Versions: 3.1.0
>Reporter: Michał
>Priority: Major
>
> I have found this issue, while migrating a project from Maven to SBT.
> To describe the problem I have created an example project with dependencies 
> that I found to behave differently, depending on the build tool.
> [https://github.com/atais/mvn-sbt-assembly]
>  
> The only dependencies are (sbt style)
> {code:java}
> "com.netflix.astyanax" % "astyanax-cassandra" % "3.9.0", 
> "org.apache.cassandra" % "cassandra-all" % "3.4",{code}
> and what I do not understand is, why {{mvn package}} creates the fat jar 
> successfully, while {{sbt assembly}} gives conflicts:
> {code:java}
> [error] 39 errors were encountered during merge [error] 
> java.lang.RuntimeException: deduplicate: different file contents found in the 
> following: [error] 
> /home/siatkowskim/.ivy2/cache/org.slf4j/jcl-over-slf4j/jars/jcl-over-slf4j-1.7.7.jar:org/apache/commons/logging/  classes> [error] 
> /home/siatkowskim/.ivy2/cache/commons-logging/commons-logging/jars/commons-logging-1.1.1.jar:org/apache/commons/logging/  classes> ... [error] 
> /home/siatkowskim/.ivy2/cache/com.github.stephenc.high-scale-lib/high-scale-lib/jars/high-scale-lib-1.1.2.jar:org/cliffc/high_scale_lib/  classes> [error] 
> /home/siatkowskim/.ivy2/cache/com.boundary/high-scale-lib/jars/high-scale-lib-1.0.6.jar:org/cliffc/high_scale_lib/  classes> ...{code}
> *{{So I wonder, how come this plugin overcomes this conflicts?}}*
> {{I have also created a SO question, if one would like to earn some points: 
> [https://stackoverflow.com/questions/50249818/why-maven-assembly-works-when-sbt-assembly-find-conflicts]}}
> {{ }}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MJAVADOC-520) Upgrade plexus-utils/qdox/plexus-archiver/

[Robert Scholte (JIRA)]

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

Robert Scholte updated MJAVADOC-520:

Description: 
* plexus-utils to 3.1.0
* qdox to 2.0-M8
* plexus-archiver 3.5, 3.6.0
* plexus-utils-3.1.0
* maven-archiver 3.2.0
* plexus-interactivity-api 1.0-alpha-6
* plexus-java 0.9.8

  was:
* plexus-utils to 3.1.0
* qdox to 2.0-M8
* plexus-archiver 3.5, 3.6.0
* plexus-utils-3.1.0
* maven-archiver 3.2.0
* plexus-interactivity-api 1.0-alpha-6


> Upgrade plexus-utils/qdox/plexus-archiver/
> --
>
> Key: MJAVADOC-520
> URL: https://issues.apache.org/jira/browse/MJAVADOC-520
> Project: Maven Javadoc Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.1
>
>
> * plexus-utils to 3.1.0
> * qdox to 2.0-M8
> * plexus-archiver 3.5, 3.6.0
> * plexus-utils-3.1.0
> * maven-archiver 3.2.0
> * plexus-interactivity-api 1.0-alpha-6
> * plexus-java 0.9.8



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MJAVADOC-524) Running javadoc plugin under JDK 10 fails with NPE

[Robert Scholte (JIRA)]

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

Robert Scholte closed MJAVADOC-524.
---
   Resolution: Duplicate
 Assignee: Robert Scholte
Fix Version/s: (was: 3.0.1)

> Running javadoc plugin under JDK 10 fails with NPE
> --
>
> Key: MJAVADOC-524
> URL: https://issues.apache.org/jira/browse/MJAVADOC-524
> Project: Maven Javadoc Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Robert Scholte
>Priority: Blocker
>
> Running under JDK 10 produces the following:
> {code}
> [INFO] [INFO] 
> 
> [INFO] [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-javadoc-plugin:3.0.0:jar (attach-javadocs) on 
> project maven-dependency-analyzer: Execution attach-javadocs of goal 
> org.apache.maven.plugins:maven-javadoc-plugin:3.0.0:jar failed.: 
> NullPointerException -> [Help 1]
> [INFO] [ERROR]
> [INFO] [ERROR] To see the full stack trace of the errors, re-run Maven with 
> the -e switch.
> [INFO] [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [INFO] [ERROR]
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MJAVADOC-522) Javadoc generation broken on JDK 10 (Commons Lang3 gives NullPointerException)

[Robert Scholte (JIRA)]

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

Robert Scholte closed MJAVADOC-522.
---
Resolution: Duplicate
  Assignee: Robert Scholte

> Javadoc generation broken on JDK 10 (Commons Lang3 gives NullPointerException)
> --
>
> Key: MJAVADOC-522
> URL: https://issues.apache.org/jira/browse/MJAVADOC-522
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: javadoc
>Affects Versions: 3.0.0
> Environment:  * JDK 10
>  * Maven 3.5.3
>  * Maven Javadoc plugin 3.0.0
>Reporter: Daniel Fernández
>Assignee: Robert Scholte
>Priority: Major
>
> Executing {{javadoc:javadoc}} in JDK 10 throws a {{NullPointerException}} 
> caused by Apache Commons Lang 3.5:
> {code}
> Caused by: java.lang.NullPointerException at 
> org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast 
> (SystemUtils.java:1626) at 
> org.apache.maven.plugins.javadoc.AbstractJavadocMojo.getJavadocExecutable 
> (AbstractJavadocMojo.java:3683) at 
> org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport 
> (AbstractJavadocMojo.java:2001) at 
> org.apache.maven.plugins.javadoc.JavadocReport.generate 
> (JavadocReport.java:134) at 
> org.apache.maven.plugins.javadoc.JavadocReport.doExecute 
> (JavadocReport.java:329) at 
> org.apache.maven.plugins.javadoc.AbstractJavadocMojo.execute 
> (AbstractJavadocMojo.java:1909) at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:137) at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:208) at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:154) at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:146) at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117) at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81) at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:56) at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute 
> (DefaultMaven.java:305) at org.apache.maven.DefaultMaven.doExecute 
> (DefaultMaven.java:192) at org.apache.maven.DefaultMaven.execute 
> (DefaultMaven.java:105) at org.apache.maven.cli.MavenCli.execute 
> (MavenCli.java:956) at org.apache.maven.cli.MavenCli.doMain 
> (MavenCli.java:290) at org.apache.maven.cli.MavenCli.main (MavenCli.java:194) 
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> ...
> {code}
> The reason for this is 
> [LANG-1365|https://issues.apache.org/jira/browse/LANG-1365] which was fixed 
> in [this 
> commit|https://github.com/apache/commons-lang/commit/a618b844c5a261ced37385ab3947de6e215d46f7].
> Updating to Apache Commons Lang 3.7 should solve the issue.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] Tibor17 commented on a change in pull request #184: Donate current sources from junit-platform-surefire-provider

[GitBox]

Tibor17 commented on a change in pull request #184: Donate current sources from 
junit-platform-surefire-provider
URL: https://github.com/apache/maven-surefire/pull/184#discussion_r189519348
 
 

 ##
 File path: maven-surefire-plugin/src/site/apt/examples/junit-platform.apt.vm
 ##
 @@ -0,0 +1,206 @@
+ --
+ Using JUnit Platform
+ --
+ JUnit Lambda Team 
+ --
+ 2018-05-14
+ --
+ 
+ ~~ 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.
+
+ ~~ NOTE: For help with the syntax of this file, see:
+ ~~ http://maven.apache.org/doxia/references/apt-format.html 
+
+Using JUnit Platform
+
+* Configuring JUnit Platform
+
+  To get started with JUnit Platform, you need to add at least a single 
<<>> implementation
+  to your project. For example, if you want to write tests with Jupiter, you 
must add the
+  <<>> to the dependencies like:
+
++---+
+
+  [...]
+
+  org.junit.jupiter
+  junit-jupiter-engine
+  5.2.0
+  test
+
+  [...]
+
++---+
+
+  This will pull in all required dependencies. Among those dependencies is 
<<>> which contains
+  the classes and interfaces your test source requires to compile. 
<<>> is also resolved and
+  added.
+
+  This is the only step that is required to get started - you can now create 
tests in your test source directory
+  (e.g., <<>>).
+
+  If you want to write and execute JUnit 3 or 4 tests via the JUnit Platform 
add the Vintage Engine to your projects'
+  dependencies:
+
++---+
+
+  [...]
+
+  org.junit.vintage
+  junit-vintage-engine
+  5.2.0
+  test
+
+  [...]
+
++---+
+
+* Provider Selection
+
+   If nothing is configured, Surefire detects which JUnit version to use by 
the following algorithm:
+
++---+
+if the JUnit Platform Engine is present in the project
+use junit-platform
+if the JUnit version in the project >= 4.7 and the parallel attribute has ANY 
value
+use junit47 provider
+if JUnit >= 4.0 is present
+use junit4 provider
+else
+use junit3.8.1
++---+
+
+  When using this technique there is no check that the proper test-frameworks 
are present on your project's
+  classpath. Failing to add the proper test-frameworks will result in a build 
failure.
+
+* Running Tests in Parallel
+
+  From JUnit Platform does not support running tests in parallel.
+
+* Running a Single Test Class
+
+   The JUnit Platform Provider supports the <<>> JVM system property 
supported by
+   the Maven Surefire Plugin. For example, to run only test methods in the 
<<>> test class
+   you can execute <<>> from the command 
line.
+
+
+* Filtering by Test Class Names
+
+   The Maven Surefire Plugin will scan for test classes whose fully qualified 
names match
+   the following patterns.
+
+   * <<<**/Test*.java>>>
+
+   * <<<**/*Test.java>>>
+
+   * <<<**/*Tests.java>>>
+
+   * <<<**/*TestCase.java>>>
+
+Moreover, it will exclude all nested classes (including static member classes) 
by default.
+
+Note, however, that you can override this default behavior by configuring 
explicit
+`include` and `exclude` rules in your `pom.xml` file. For example, to keep 
Maven Surefire
+from excluding static member classes, you can override its exclude rules.
+
+Overriding exclude rules of Maven Surefire
+
++---+
+...
+
+
+...
+
+maven-surefire-plugin
+{surefire-version}
+
+
+
+
+
+...
+
+
+
+...
++---+
+
+
+* Filtering by Tags
+
+You can filter tests by tags or tag expressions using the following 
configuration properties.
+
+* to include <<>> or <<>>, use either <<>> 
or <<>>.
+
+* to exclude <<>> or <<>>, use either 
<<>> or <<>>.
+
++---+
+...
+
+
+...
+
+maven-surefire-plugin
+{surefire-version}
+
+
+acceptance | !feature-a
+integration, regression
+
+
+
+...
+
+
+
+
+...
++---+
+
+
+* Configuration Parameters
+
+   You can set JUnit Platform configuration parameters to influence