[jira] [Closed] (SUREFIRE-1704) [JDK 11 Alpine Linux] long etime within hours has format 2h01 on busybox

2019-10-27 Thread Tibor Digana (Jira)


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

Tibor Digana closed SUREFIRE-1704.
--
Resolution: Fixed

https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=0595e4eeddf900ba2918c8761942fe699327b651

> [JDK 11 Alpine Linux] long etime within hours has format 2h01 on busybox
> 
>
> Key: SUREFIRE-1704
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1704
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin, process 
> forking
> Environment: busybox
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M4
>
>
> The {{etime}} in /procps respects the format {{mm:ss}} and non standard 
> format if the etime exceeds one hour. This improvement is tolerant to the 
> format, example with two hours and one minute: {{2h01}}.



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


[jira] [Updated] (SUREFIRE-1704) [JDK 11 Alpine Linux] long etime within hours has format 2h01 on busybox

2019-10-27 Thread Tibor Digana (Jira)


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

Tibor Digana updated SUREFIRE-1704:
---
Description: The {{etime}} in /procps respects the format {{mm:ss}} and non 
standard format if the etime exceeds one hour. This improvement is tolerant to 
the format, example with two hours and one minute: {{2h01}}.  (was: The 
{{etime}} in /procps respects the format {{mm:ss}} and non standard format if 
the etime exceeds one hour. This improvement is tolerant to the format, example 
with two hours and one minute: {{2h:01}}.)

> [JDK 11 Alpine Linux] long etime within hours has format 2h01 on busybox
> 
>
> Key: SUREFIRE-1704
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1704
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin, process 
> forking
> Environment: busybox
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M4
>
>
> The {{etime}} in /procps respects the format {{mm:ss}} and non standard 
> format if the etime exceeds one hour. This improvement is tolerant to the 
> format, example with two hours and one minute: {{2h01}}.



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


[jira] [Created] (SUREFIRE-1704) [JDK 11 Alpine Linux] long etime within hours has format 2h01 on busybox

2019-10-27 Thread Tibor Digana (Jira)
Tibor Digana created SUREFIRE-1704:
--

 Summary: [JDK 11 Alpine Linux] long etime within hours has format 
2h01 on busybox
 Key: SUREFIRE-1704
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1704
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Maven Failsafe Plugin, Maven Surefire Plugin, process 
forking
 Environment: busybox
Reporter: Tibor Digana
Assignee: Tibor Digana
 Fix For: 3.0.0-M4


The {{etime}} in /procps respects the format {{mm:ss}} and non standard format 
if the etime exceeds one hour. This improvement is tolerant to the format, 
example with two hours and one minute: {{2h:01}}.



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


[jira] [Closed] (SUREFIRE-1703) [JDK 11 Alpine Linux] Surefire handled random order of pid and /procps does not filter pid on busybox distributions

2019-10-27 Thread Tibor Digana (Jira)


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

Tibor Digana closed SUREFIRE-1703.
--
Resolution: Fixed

https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=cf86805500927522501169d5b4ce59055c2721c0

> [JDK 11 Alpine Linux] Surefire handled random order of pid and /procps does 
> not filter pid on busybox distributions
> ---
>
> Key: SUREFIRE-1703
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1703
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin, process 
> forking
> Environment: Alpine Linux Docker
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M4
>
>
> The busybox does not support pid filters on /procps.
> This improvement introduced filter in memory only on busybox. Other Linux and 
> Unix distributions perform filtering on native command level.



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


[jira] [Created] (SUREFIRE-1703) [JDK 11 Alpine Linux] Surefire handled random order of pid and /procps does not filter pid on busybox distributions

2019-10-27 Thread Tibor Digana (Jira)
Tibor Digana created SUREFIRE-1703:
--

 Summary: [JDK 11 Alpine Linux] Surefire handled random order of 
pid and /procps does not filter pid on busybox distributions
 Key: SUREFIRE-1703
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1703
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Maven Failsafe Plugin, Maven Surefire Plugin, process 
forking
 Environment: Alpine Linux Docker
Reporter: Tibor Digana
Assignee: Tibor Digana
 Fix For: 3.0.0-M4


The busybox does not support pid filters on /procps.
This improvement introduced filter in memory only on busybox. Other Linux and 
Unix distributions perform filtering on native command level.



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


[jira] [Assigned] (SUREFIRE-1701) Surefire / Failsafe rerun failed tests functionality fails with JUnit 5 if using @DisplayName

2019-10-27 Thread Tibor Digana (Jira)


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

Tibor Digana reassigned SUREFIRE-1701:
--

Assignee: Tibor Digana

> Surefire / Failsafe rerun failed tests functionality fails with JUnit 5 if 
> using @DisplayName
> -
>
> Key: SUREFIRE-1701
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1701
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.0.0-M3
>Reporter: Abraham
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M4
>
>
> Using the {{@DisplayName}} annotation in JUnit Jupiter prevents 
> {{rerunFailedTestsCount}} functionality in surefire and failsafe from 
> working. Example of this can be found 
> [here|https://github.com/quiram/surefire-retry-failed-tests-issue].
> *Note:* it is possible that other annotations make this functionality fail 
> too, but I haven't checked.



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


[GitHub] [maven-surefire] Tibor17 commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.

2019-10-27 Thread GitBox
Tibor17 commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked 
Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process 
communication.
URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-546745358
 
 
   @jon-bell 
   Thank you that you have actually dived into into it. Of course nothing is 
complete in this PR to just plugin a TCP connector. You have found few missing 
and important parts like ForkedBooter on a physical drive.
   I have to go to sleep. Let's talk about the details tomorrow.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-surefire] jon-bell commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.

2019-10-27 Thread GitBox
jon-bell commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked 
Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process 
communication.
URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-546744745
 
 
   I will plan to implement both TCP and UDP, and we can do a performance 
comparison by running it on real projects' test suites. I am not sure that the 
difference will be that significant, and if it isn't, supporting both can risk 
end-user misconfigurations (and in general increase the complexity of the 
configuration for surefire, which presumably should be avoided if possible). As 
it looks like you’ve already found out, for small messages that come in bursts, 
`TCP_NO_DELAY` can provide a significant performacne improvement for TCP 
connections.
   
   I tried to understand what you’ve got here but am having difficulty due to 
lack of documentation, and because things are not fully connected. Should 
`ForkedChannelServer` implement `DifferedChannelCommandSender`? If so, why is 
it in `surefire-extensions-api` and not in `maven-surefire-common`? Do you have 
any design documentation to point me to? If not, how set are you on this 
architecture?
   
   At a high level, how I would plan to do this is:
   In `ForkStarter.fork`, we will instantiate some new helper class (called, 
for instance, `ForkedProcessServer` that will be responsible for creating and 
managing a `ServerSocket` (or `DatagramSocket` if UDP). This will bind to a 
random port, then pass that port to the forked process as a parameter. It will 
be the responsibility of `ForkedProcessServer` to provide the glue between the 
`ForkClient` the socket?
   
   The `ForkProcessServer` will set up `StreamPumper`s similarly to how 
`CommandLineUtils.executeCommandLine` does right now, but instead of connecting 
to `stdin` and `stdout`, they will connect to the socket’s streams. I was 
planning to have a 1:1 mapping of `SocketServer`s to forks, rather than create 
a single `SocketServer` to keep alive for all forks. It greatly simplifies the 
implementation and fits better to the existing architecture (which effectively 
has a dedicated stream for every fork). We already implemented this and did not 
find significant delays from binding that many `ServerSocket`s, finding that 
performance still improved dramatically over `stdin`/`stdout` communication 
(again, see [discussion here](https://github.com/gmu-swe/maven-surefire/pull/2) 
for a performance breakdown of what we have so far hacked out).
   
   How does this all sound to you, @tibor17 (architecturally) and @col-e (in 
terms of feasibility based on what you’ve already implemented)?
   
   I assume that the desired level of configuration is to allow for users to 
keep on using `stdin`/`stdout` instead of sockets, likely keeping existing 
behavior by default. The socket setup will be annoying to anyone with an OS 
that will bring up a GUI warning whenever a process tries to bind to a socket.
   
   If it's an eventual goal, then it might also be worthwhile co-designing 
support for spawning `ForkedBooter`s on separate physical machines and using 
the socket for communication. I did some work for some clients who used a 
network file system to replicate the build environment across a cluster of 
machines. Assuming this is a typical practice, then it may be easy enough to 
just allow users to specify an IP address to bind to and advertise (or look up 
whatever `getLocalHostName` resolves to by default), and then also allow users 
to specify an arbitrary command string to prepend to the `ForkedBooter` process 
CommandLine (e.g. to specify an `ssh` command, resulting in the command running 
on a remote machine. Do you have any specific feature requestors who can 
provide a little more detail on their setups in order to help define the 
interface for this?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Comment Edited] (MNG-6795) define a replacement for ReasonPhrase to display details about transfert failures

2019-10-27 Thread Michael Osipov (Jira)


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

Michael Osipov edited comment on MNG-6795 at 10/27/19 8:41 PM:
---

It is also to mention that only a few servers allow to set the reason phrase. 
Tomcat never supported it. Other likely neither. See also [Undertow's 
documentation on 
it|http://undertow.io/javadoc/1.3.x/io/undertow/server/HttpServerExchange.html#setReasonPhrase-java.lang.String-].
 I think the resolution of WAGON-541 is just wrong.


was (Author: michael-o):
It is also to mention that only a few servers allow to set the reason phrase. 
Tomcat never supported it. Other likely neither. See also [Undertow's 
documentation on 
it](http://undertow.io/javadoc/1.3.x/io/undertow/server/HttpServerExchange.html#setReasonPhrase-java.lang.String-).
 I think the resolution of WAGON-541 is just wrong.

> define a replacement for ReasonPhrase to display details about transfert 
> failures
> -
>
> Key: MNG-6795
> URL: https://issues.apache.org/jira/browse/MNG-6795
> Project: Maven
>  Issue Type: Task
>  Components: Artifacts and Repositories
>Affects Versions: 3.3.9, 3.6.3
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.7.0-candidate
>
>
> as documented in WAGON-541 
> [372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git&a=commit&h=372aa52c80c2f7b458c095d837e15ebeafbdf0b7],
>  ReasonPhrase has been removed from HTTP/2 and deprecated (optional) in 
> HTTP/1.1 for more than five years. It is useful to give detailed error 
> messages on artifact transfert errors with a repository manager.
> A replacement has to be found



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


[jira] [Commented] (MNG-6795) define a replacement for ReasonPhrase to display details about transfert failures

2019-10-27 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6795:
-

It is also to mention that only a few servers allow to set the reason phrase. 
Tomcat never supported it. Other likely neither. See also [Undertow's 
documentation on 
it](http://undertow.io/javadoc/1.3.x/io/undertow/server/HttpServerExchange.html#setReasonPhrase-java.lang.String-).
 I think the resolution of WAGON-541 is just wrong.

> define a replacement for ReasonPhrase to display details about transfert 
> failures
> -
>
> Key: MNG-6795
> URL: https://issues.apache.org/jira/browse/MNG-6795
> Project: Maven
>  Issue Type: Task
>  Components: Artifacts and Repositories
>Affects Versions: 3.3.9, 3.6.3
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.7.0-candidate
>
>
> as documented in WAGON-541 
> [372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git&a=commit&h=372aa52c80c2f7b458c095d837e15ebeafbdf0b7],
>  ReasonPhrase has been removed from HTTP/2 and deprecated (optional) in 
> HTTP/1.1 for more than five years. It is useful to give detailed error 
> messages on artifact transfert errors with a repository manager.
> A replacement has to be found



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


[jira] [Commented] (MNG-6795) define a replacement for ReasonPhrase to display details about transfert failures

2019-10-27 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6795:
-

I don't see this to be realistically implemented. It will take years to take 
over.

> define a replacement for ReasonPhrase to display details about transfert 
> failures
> -
>
> Key: MNG-6795
> URL: https://issues.apache.org/jira/browse/MNG-6795
> Project: Maven
>  Issue Type: Task
>  Components: Artifacts and Repositories
>Affects Versions: 3.3.9, 3.6.3
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.7.0-candidate
>
>
> as documented in WAGON-541 
> [372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git&a=commit&h=372aa52c80c2f7b458c095d837e15ebeafbdf0b7],
>  ReasonPhrase has been removed from HTTP/2
> it is useful to give detailed error messages on artifact transfert errors 
> with a repository manager
> A replacement has to be found



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


[jira] [Updated] (MNG-6795) define a replacement for ReasonPhrase to display details about transfert failures

2019-10-27 Thread Michael Osipov (Jira)


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

Michael Osipov updated MNG-6795:

Description: 
as documented in WAGON-541 
[372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git&a=commit&h=372aa52c80c2f7b458c095d837e15ebeafbdf0b7],
 ReasonPhrase has been removed from HTTP/2 and deprecated (optional) in 
HTTP/1.1 for more than five years. It is useful to give detailed error messages 
on artifact transfert errors with a repository manager.
A replacement has to be found

  was:
as documented in WAGON-541 
[372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git&a=commit&h=372aa52c80c2f7b458c095d837e15ebeafbdf0b7],
 ReasonPhrase has been removed from HTTP/2
it is useful to give detailed error messages on artifact transfert errors with 
a repository manager
A replacement has to be found


> define a replacement for ReasonPhrase to display details about transfert 
> failures
> -
>
> Key: MNG-6795
> URL: https://issues.apache.org/jira/browse/MNG-6795
> Project: Maven
>  Issue Type: Task
>  Components: Artifacts and Repositories
>Affects Versions: 3.3.9, 3.6.3
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.7.0-candidate
>
>
> as documented in WAGON-541 
> [372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git&a=commit&h=372aa52c80c2f7b458c095d837e15ebeafbdf0b7],
>  ReasonPhrase has been removed from HTTP/2 and deprecated (optional) in 
> HTTP/1.1 for more than five years. It is useful to give detailed error 
> messages on artifact transfert errors with a repository manager.
> A replacement has to be found



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


[GitHub] [maven-pmd-plugin] pzygielo opened a new pull request #14: (doc) Update references to PMD documentation

2019-10-27 Thread GitBox
pzygielo opened a new pull request #14: (doc) Update references to PMD 
documentation
URL: https://github.com/apache/maven-pmd-plugin/pull/14
 
 
   Follow-up to https://github.com/pmd/pmd/commit/04b0859fb2
   (pmd_releases/6.3.0-123-g04b0859fb2)
   
   Following this checklist to help us incorporate your
   contribution quickly and easily:
   
- [x] Make sure there is a [JIRA 
issue](https://issues.apache.org/jira/browse/MPMD) filed
  for the change (usually before you start working on it).  Trivial 
changes like typos do not
  require a JIRA issue.  Your pull request should address just this 
issue, without
  pulling in other changes.
- [x] Each commit in the pull request should have a meaningful subject line 
and body.
- [x] Format the pull request title like `[MPMD-XXX] - Subject of the JIRA 
Ticket`,
  where you replace `MPMD-XXX` with the appropriate JIRA issue. Best 
practice
  is to use the JIRA issue title in the pull request title and in the 
first line of the
  commit message.
- [x] Write a pull request description that is detailed enough to 
understand what the pull request does, how, and why.
- [ ] Run `mvn clean verify` to make sure basic checks pass. A more 
thorough check will
  be performed on your pull request automatically.
- [ ] You have run the integration tests successfully (`mvn -Prun-its clean 
verify`).
   
   If your pull request is about ~20 lines of code you don't need to sign an
   [Individual Contributor License 
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
   please ask on the developers list.
   
   To make clear that you license your contribution under
   the [Apache License Version 2.0, January 
2004](http://www.apache.org/licenses/LICENSE-2.0)
   you have to acknowledge this by using the following check-box.
   
- [x] I hereby declare this contribution to be licenced under the [Apache 
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   
- [ ] In any other case, please file an [Apache Individual Contributor 
License Agreement](https://www.apache.org/licenses/icla.pdf).
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven] alex1989hu commented on issue #295: [MNG-5600] Dependency management import should support exclusions

2019-10-27 Thread GitBox
alex1989hu commented on issue #295: [MNG-5600] Dependency management import 
should support exclusions
URL: https://github.com/apache/maven/pull/295#issuecomment-546724291
 
 
   @olamy kind ping


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Comment Edited] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors

2019-10-27 Thread Herve Boutemy (Jira)


[ 
https://issues.apache.org/jira/browse/WAGON-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16960644#comment-16960644
 ] 

Herve Boutemy edited comment on WAGON-541 at 10/27/19 5:49 PM:
---

done in 
[e6c8e915f4da48df10a67fd965990e5d7b7cf03f|https://gitbox.apache.org/repos/asf?p=maven-wagon.git&a=commit&h=e6c8e915f4da48df10a67fd965990e5d7b7cf03f]
important notice in 
[372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git&a=commit&h=372aa52c80c2f7b458c095d837e15ebeafbdf0b7]
 about Reason Phrase future: MNG-6795 created


was (Author: hboutemy):
done in 
[e6c8e915f4da48df10a67fd965990e5d7b7cf03f|https://gitbox.apache.org/repos/asf?p=maven-wagon.git&a=commit&h=e6c8e915f4da48df10a67fd965990e5d7b7cf03f]
important notice in 
[372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git&a=commit&h=372aa52c80c2f7b458c095d837e15ebeafbdf0b7]
 about Reason Phrase future

> Command Line Not Showing ReasonPhrase for Errors
> 
>
> Key: WAGON-541
> URL: https://issues.apache.org/jira/browse/WAGON-541
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http
>Affects Versions: 3.2.0
> Environment: Windows 10
>Reporter: Aurelie Pluche
>Assignee: Herve Boutemy
>Priority: Minor
> Fix For: 3.3.4
>
> Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG, 
> MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Hi,
> I work in the Azure DevOps Artifacts Packaging team at Microsoft where we 
> provide a Maven service to our customers. We often use a Reason-Phrase to 
> return information on failed requests to customers. This functionality was 
> available in previous versions of maven but seems to have disappeared in 
> Maven 3.6.0. Was this intentional?
> I have included screenshots of the cmd line response using two different 
> maven versions (3.3.9 and 3.6.0). I intentionally made a call that would 
> return a 405 error to be able to get an error response. I also used the same 
> package.
> Thanks



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


[jira] [Updated] (MNG-6795) define a replacement for ReasonPhrase to display details about transfert failures

2019-10-27 Thread Herve Boutemy (Jira)


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

Herve Boutemy updated MNG-6795:
---
Fix Version/s: 3.7.0-candidate

> define a replacement for ReasonPhrase to display details about transfert 
> failures
> -
>
> Key: MNG-6795
> URL: https://issues.apache.org/jira/browse/MNG-6795
> Project: Maven
>  Issue Type: Task
>  Components: Artifacts and Repositories
>Affects Versions: 3.3.9, 3.6.3
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.7.0-candidate
>
>
> as documented in WAGON-541 
> [372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git&a=commit&h=372aa52c80c2f7b458c095d837e15ebeafbdf0b7],
>  ReasonPhrase has been removed from HTTP/2
> it is useful to give detailed error messages on artifact transfert errors 
> with a repository manager
> A replacement has to be found



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


[jira] [Created] (MNG-6795) define a replacement for ReasonPhrase to display details about transfert failures

2019-10-27 Thread Herve Boutemy (Jira)
Herve Boutemy created MNG-6795:
--

 Summary: define a replacement for ReasonPhrase to display details 
about transfert failures
 Key: MNG-6795
 URL: https://issues.apache.org/jira/browse/MNG-6795
 Project: Maven
  Issue Type: Task
  Components: Artifacts and Repositories
Affects Versions: 3.3.9, 3.6.3
Reporter: Herve Boutemy


as documented in WAGON-541 
[372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git&a=commit&h=372aa52c80c2f7b458c095d837e15ebeafbdf0b7],
 ReasonPhrase has been removed from HTTP/2
it is useful to give detailed error messages on artifact transfert errors with 
a repository manager
A replacement has to be found



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


[jira] [Closed] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors

2019-10-27 Thread Herve Boutemy (Jira)


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

Herve Boutemy closed WAGON-541.
---
  Assignee: Herve Boutemy
Resolution: Fixed

done in 
[e6c8e915f4da48df10a67fd965990e5d7b7cf03f|https://gitbox.apache.org/repos/asf?p=maven-wagon.git&a=commit&h=e6c8e915f4da48df10a67fd965990e5d7b7cf03f]
important notice in 
[372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git&a=commit&h=372aa52c80c2f7b458c095d837e15ebeafbdf0b7]
 about Reason Phrase future

> Command Line Not Showing ReasonPhrase for Errors
> 
>
> Key: WAGON-541
> URL: https://issues.apache.org/jira/browse/WAGON-541
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http
>Affects Versions: 3.2.0
> Environment: Windows 10
>Reporter: Aurelie Pluche
>Assignee: Herve Boutemy
>Priority: Minor
> Fix For: 3.3.4
>
> Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG, 
> MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Hi,
> I work in the Azure DevOps Artifacts Packaging team at Microsoft where we 
> provide a Maven service to our customers. We often use a Reason-Phrase to 
> return information on failed requests to customers. This functionality was 
> available in previous versions of maven but seems to have disappeared in 
> Maven 3.6.0. Was this intentional?
> I have included screenshots of the cmd line response using two different 
> maven versions (3.3.9 and 3.6.0). I intentionally made a call that would 
> return a 405 error to be able to get an error response. I also used the same 
> package.
> Thanks



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


[jira] [Updated] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors

2019-10-27 Thread Herve Boutemy (Jira)


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

Herve Boutemy updated WAGON-541:

Fix Version/s: 3.3.4

> Command Line Not Showing ReasonPhrase for Errors
> 
>
> Key: WAGON-541
> URL: https://issues.apache.org/jira/browse/WAGON-541
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http
>Affects Versions: 3.2.0
> Environment: Windows 10
>Reporter: Aurelie Pluche
>Priority: Minor
> Fix For: 3.3.4
>
> Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG, 
> MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Hi,
> I work in the Azure DevOps Artifacts Packaging team at Microsoft where we 
> provide a Maven service to our customers. We often use a Reason-Phrase to 
> return information on failed requests to customers. This functionality was 
> available in previous versions of maven but seems to have disappeared in 
> Maven 3.6.0. Was this intentional?
> I have included screenshots of the cmd line response using two different 
> maven versions (3.3.9 and 3.6.0). I intentionally made a call that would 
> return a 405 error to be able to get an error response. I also used the same 
> package.
> Thanks



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


[GitHub] [maven-wagon] hboutemy commented on issue #56: WAGON-541 Command Line Not Showing ReasonPhrase for Errors

2019-10-27 Thread GitBox
hboutemy commented on issue #56: WAGON-541 Command Line Not Showing 
ReasonPhrase for Errors
URL: https://github.com/apache/maven-wagon/pull/56#issuecomment-546713935
 
 
   merged
   thank you


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-wagon] hboutemy closed pull request #56: WAGON-541 Command Line Not Showing ReasonPhrase for Errors

2019-10-27 Thread GitBox
hboutemy closed pull request #56: WAGON-541 Command Line Not Showing 
ReasonPhrase for Errors
URL: https://github.com/apache/maven-wagon/pull/56
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Updated] (MNG-6794) Add mvn add groupId/artifactId feature like NPM to maven

2019-10-27 Thread Michael Osipov (Jira)


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

Michael Osipov updated MNG-6794:

Priority: Minor  (was: Major)

> Add mvn add groupId/artifactId feature like NPM to maven
> 
>
> Key: MNG-6794
> URL: https://issues.apache.org/jira/browse/MNG-6794
> Project: Maven
>  Issue Type: Wish
>Reporter: gaurav
>Priority: Minor
>
> The article 10 myths about java in 
> 2019(https://developer.okta.com/blog/2019/07/15/java-myths-2019) list a nice 
> feature which maven could add to it.
>  
> For NPM, Want to add a new dependency? Just run {{npm i groupId/artifactId}}.
>  
> do think it would be cool if Maven had something like {{mvn add 
> groupId/artifactId}}



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


[jira] [Commented] (WAGON-566) Add support for URI normalization

2019-10-27 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/WAGON-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16960569#comment-16960569
 ] 

Michael Osipov commented on WAGON-566:
--

[~stvricbr...@gmail.com], are you willing to try a patch?

> Add support for URI normalization
> -
>
> Key: WAGON-566
> URL: https://issues.apache.org/jira/browse/WAGON-566
> Project: Maven Wagon
>  Issue Type: Improvement
>  Components: wagon-http
>Affects Versions: 3.3.3
>Reporter: Steve Brown
>Priority: Major
>  Labels: easyfix, newbie
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> This is a simple fix for MSITE-738. I have set the priority as Major because 
> that is the priority set for MSITE-738
> Some Repository Managers, e.g. JFrog's Artifactory, do not allow puts to a 
> URL with relative path elements ("." or "..").
> Artifactory are addressing the issue for downloads from remote sites 
> ([RTFACT-16457|https://www.jfrog.com/jira/browse/RTFACT-16457]).  Artifactory 
> returns this error:
> {{"status" : 500,"}}
>  {{"Path element cannot end with a dot: sites/ ... redacted ... */../*"}}
> The fix is to amend 
>  {{org.apache.maven.wagon.shared.http.EncodeUtils.encodeURL( String url )}}
>   to normalize the returned URI.
> I will create a pull request.
>  



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


[GitHub] [maven-wagon] michael-o opened a new pull request #58: [WAGON-569] Inconsistent encoding behavior for repository URLs with s…

2019-10-27 Thread GitBox
michael-o opened a new pull request #58: [WAGON-569] Inconsistent encoding 
behavior for repository URLs with s…
URL: https://github.com/apache/maven-wagon/pull/58
 
 
   …paces
   
   @ok2c Can you have a look? I hope I have properly used the `URLEncodedUtils`.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Updated] (WAGON-569) Inconsistent encoding behavior for repository URLs with spaces

2019-10-27 Thread Michael Osipov (Jira)


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

Michael Osipov updated WAGON-569:
-
Summary: Inconsistent encoding behavior for repository URLs with spaces  
(was: Inconsistent encoding behavior for repository urls with spaces)

> Inconsistent encoding behavior for repository URLs with spaces
> --
>
> Key: WAGON-569
> URL: https://issues.apache.org/jira/browse/WAGON-569
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http
>Affects Versions: 3.3.3
> Environment: OS: Windows 10
> mvn -v 
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
> 2018-10-24T11:41:47-07:00)
> Maven home: C:\
> Java version: 12.0.1, vendor: Oracle Corporation, runtime: C:\
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> mvn deploy version:  3.0.0-M1
> other plugins through effective pom:
> 
> 
>   maven-antrun-plugin
>   1.3
> 
> 
>   maven-assembly-plugin
>   2.2-beta-5
> 
> 
>   maven-dependency-plugin
>   2.8
> 
> 
>   maven-release-plugin
>   2.5.3
> 
> 
>   maven-clean-plugin
>   3.0.0
> 
> 
>   maven-resources-plugin
>   3.0.2
> 
> 
>   maven-compiler-plugin
>   3.7.0
> 
> 
>   maven-jar-plugin
>   3.0.2
> 
> 
>   maven-install-plugin
>   2.5.2
> 
> 
>   maven-deploy-plugin
>   2.8.2
> 
>   
>Reporter: Aasim Malladi
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.3.4
>
> Attachments: debug-log-2019-10-16-2.txt, debug-log-2019-10-16.txt
>
>
> Hi - I have a maven project that deploys its artifacts to a remote 
> repository. I have configured the remote repository both in the repositories 
> and distributionRepositories as follows: 
> {code:java}
>    
>     
>   id1  
>   https://hostname/test/spacyurl%20Spacy/maven/v1   
>
> true
>       
>
>true
>     
>     
>    
>    
>     
>   id1  
>   https://hostname/test/spacyurl%20Spacy/maven/v1   
>
> true
>      
>
>true
>    
>     
> 
> {code}
> As you can see my URL has spaces in it.
> When I run 'mvn install', it correctly uses the encoded URL with spaces and 
> downloads the dependencies. However, when I try to deploy this package to the 
> remote repo, it fails with a 404 not found error. On further investigation, 
> it looks like the URL is being encoded twice before the PUT request is sent. 
> If I remove the encoding, ie., put the URL with spaces, the deployment works, 
> however, the install fails.
> Let me know if you need more information about this.
> Aasim
>  



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


[jira] [Updated] (WAGON-566) Add support for URI normalization

2019-10-27 Thread Michael Osipov (Jira)


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

Michael Osipov updated WAGON-566:
-
Summary: Add support for URI normalization  (was: Fix for MSITE-738)

> Add support for URI normalization
> -
>
> Key: WAGON-566
> URL: https://issues.apache.org/jira/browse/WAGON-566
> Project: Maven Wagon
>  Issue Type: Improvement
>  Components: wagon-http
>Affects Versions: 3.3.3
>Reporter: Steve Brown
>Priority: Major
>  Labels: easyfix, newbie
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> This is a simple fix for MSITE-738. I have set the priority as Major because 
> that is the priority set for MSITE-738
> Some Repository Managers, e.g. JFrog's Artifactory, do not allow puts to a 
> URL with relative path elements ("." or "..").
> Artifactory are addressing the issue for downloads from remote sites 
> ([RTFACT-16457|https://www.jfrog.com/jira/browse/RTFACT-16457]).  Artifactory 
> returns this error:
> {{"status" : 500,"}}
>  {{"Path element cannot end with a dot: sites/ ... redacted ... */../*"}}
> The fix is to amend 
>  {{org.apache.maven.wagon.shared.http.EncodeUtils.encodeURL( String url )}}
>   to normalize the returned URI.
> I will create a pull request.
>  



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


[jira] [Updated] (WAGON-569) Inconsistent encoding behavior for repository urls with spaces

2019-10-27 Thread Michael Osipov (Jira)


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

Michael Osipov updated WAGON-569:
-
Fix Version/s: (was: waiting-for-feedback)
   3.3.4

> Inconsistent encoding behavior for repository urls with spaces
> --
>
> Key: WAGON-569
> URL: https://issues.apache.org/jira/browse/WAGON-569
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http
>Affects Versions: 3.3.3
> Environment: OS: Windows 10
> mvn -v 
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
> 2018-10-24T11:41:47-07:00)
> Maven home: C:\
> Java version: 12.0.1, vendor: Oracle Corporation, runtime: C:\
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> mvn deploy version:  3.0.0-M1
> other plugins through effective pom:
> 
> 
>   maven-antrun-plugin
>   1.3
> 
> 
>   maven-assembly-plugin
>   2.2-beta-5
> 
> 
>   maven-dependency-plugin
>   2.8
> 
> 
>   maven-release-plugin
>   2.5.3
> 
> 
>   maven-clean-plugin
>   3.0.0
> 
> 
>   maven-resources-plugin
>   3.0.2
> 
> 
>   maven-compiler-plugin
>   3.7.0
> 
> 
>   maven-jar-plugin
>   3.0.2
> 
> 
>   maven-install-plugin
>   2.5.2
> 
> 
>   maven-deploy-plugin
>   2.8.2
> 
>   
>Reporter: Aasim Malladi
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.3.4
>
> Attachments: debug-log-2019-10-16-2.txt, debug-log-2019-10-16.txt
>
>
> Hi - I have a maven project that deploys its artifacts to a remote 
> repository. I have configured the remote repository both in the repositories 
> and distributionRepositories as follows: 
> {code:java}
>    
>     
>   id1  
>   https://hostname/test/spacyurl%20Spacy/maven/v1   
>
> true
>       
>
>true
>     
>     
>    
>    
>     
>   id1  
>   https://hostname/test/spacyurl%20Spacy/maven/v1   
>
> true
>      
>
>true
>    
>     
> 
> {code}
> As you can see my URL has spaces in it.
> When I run 'mvn install', it correctly uses the encoded URL with spaces and 
> downloads the dependencies. However, when I try to deploy this package to the 
> remote repo, it fails with a 404 not found error. On further investigation, 
> it looks like the URL is being encoded twice before the PUT request is sent. 
> If I remove the encoding, ie., put the URL with spaces, the deployment works, 
> however, the install fails.
> Let me know if you need more information about this.
> Aasim
>  



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


[jira] [Assigned] (WAGON-569) Inconsistent encoding behavior for repository urls with spaces

2019-10-27 Thread Michael Osipov (Jira)


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

Michael Osipov reassigned WAGON-569:


Assignee: Michael Osipov

> Inconsistent encoding behavior for repository urls with spaces
> --
>
> Key: WAGON-569
> URL: https://issues.apache.org/jira/browse/WAGON-569
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http
>Affects Versions: 3.3.3
> Environment: OS: Windows 10
> mvn -v 
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
> 2018-10-24T11:41:47-07:00)
> Maven home: C:\
> Java version: 12.0.1, vendor: Oracle Corporation, runtime: C:\
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> mvn deploy version:  3.0.0-M1
> other plugins through effective pom:
> 
> 
>   maven-antrun-plugin
>   1.3
> 
> 
>   maven-assembly-plugin
>   2.2-beta-5
> 
> 
>   maven-dependency-plugin
>   2.8
> 
> 
>   maven-release-plugin
>   2.5.3
> 
> 
>   maven-clean-plugin
>   3.0.0
> 
> 
>   maven-resources-plugin
>   3.0.2
> 
> 
>   maven-compiler-plugin
>   3.7.0
> 
> 
>   maven-jar-plugin
>   3.0.2
> 
> 
>   maven-install-plugin
>   2.5.2
> 
> 
>   maven-deploy-plugin
>   2.8.2
> 
>   
>Reporter: Aasim Malladi
>Assignee: Michael Osipov
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: debug-log-2019-10-16-2.txt, debug-log-2019-10-16.txt
>
>
> Hi - I have a maven project that deploys its artifacts to a remote 
> repository. I have configured the remote repository both in the repositories 
> and distributionRepositories as follows: 
> {code:java}
>    
>     
>   id1  
>   https://hostname/test/spacyurl%20Spacy/maven/v1   
>
> true
>       
>
>true
>     
>     
>    
>    
>     
>   id1  
>   https://hostname/test/spacyurl%20Spacy/maven/v1   
>
> true
>      
>
>true
>    
>     
> 
> {code}
> As you can see my URL has spaces in it.
> When I run 'mvn install', it correctly uses the encoded URL with spaces and 
> downloads the dependencies. However, when I try to deploy this package to the 
> remote repo, it fails with a 404 not found error. On further investigation, 
> it looks like the URL is being encoded twice before the PUT request is sent. 
> If I remove the encoding, ie., put the URL with spaces, the deployment works, 
> however, the install fails.
> Let me know if you need more information about this.
> Aasim
>  



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


[GitHub] [maven] michael-o commented on a change in pull request #297: MNG-6771 Fix license issues on binary distribution

2019-10-27 Thread GitBox
michael-o commented on a change in pull request #297: MNG-6771 Fix license 
issues on binary distribution
URL: https://github.com/apache/maven/pull/297#discussion_r339337220
 
 

 ##
 File path: apache-maven/src/main/appended-resources/META-INF/LICENSE.vm
 ##
 @@ -22,21 +22,18 @@ Apache Maven includes a number of components and libraries 
with separate
 copyright notices and license terms. Your use of those components are 
 subject to the terms and conditions of the following licenses: 
 ##
-#set ( $apacheLicenseNames = [ "Apache License, Version 2.0", "The Apache 
Software License, Version 2.0",
-"ASLv2", "Apache Public License 2.0", "Apache 2.0" ] )
+#set ( $apacheMavenGroupIds = [ "org.apache.maven", "org.apache.maven.wagon", 
"org.apache.maven.resolver",
+"org.apache.maven.shared" ] )
 #set ( $MITLicenseNames = [ "MIT License", "MIT license", "The MIT License" ] )
 #foreach ( $project in $projects )
 #**##foreach ( $license in $project.licenses)
-#*  *##if ( !$apacheLicenseNames.contains( $license.name ) )
+#*  *##set ( $groupId = $project.artifact.groupId )
+#*  *##if ( !$apacheMavenGroupIds.contains( $groupId ) )
 #**##set ( $artId = $project.artifact.artifactId )
 #**##set ( $url = $license.url )
 #**##set ( $spdx = false )
 #**##set ( $includeLicense = true )
 #**###
-#**##if ( $project.artifact.artifactId == "jcl-over-slf4j" )
 
 Review comment:
   This means we have to wait for 1.7.29, don't we?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven] hboutemy commented on a change in pull request #297: MNG-6771 Fix license issues on binary distribution

2019-10-27 Thread GitBox
hboutemy commented on a change in pull request #297: MNG-6771 Fix license 
issues on binary distribution
URL: https://github.com/apache/maven/pull/297#discussion_r339336793
 
 

 ##
 File path: apache-maven/src/main/appended-resources/META-INF/LICENSE.vm
 ##
 @@ -22,21 +22,18 @@ Apache Maven includes a number of components and libraries 
with separate
 copyright notices and license terms. Your use of those components are 
 subject to the terms and conditions of the following licenses: 
 ##
-#set ( $apacheLicenseNames = [ "Apache License, Version 2.0", "The Apache 
Software License, Version 2.0",
-"ASLv2", "Apache Public License 2.0", "Apache 2.0" ] )
+#set ( $apacheMavenGroupIds = [ "org.apache.maven", "org.apache.maven.wagon", 
"org.apache.maven.resolver",
+"org.apache.maven.shared" ] )
 #set ( $MITLicenseNames = [ "MIT License", "MIT license", "The MIT License" ] )
 #foreach ( $project in $projects )
 #**##foreach ( $license in $project.licenses)
-#*  *##if ( !$apacheLicenseNames.contains( $license.name ) )
+#*  *##set ( $groupId = $project.artifact.groupId )
+#*  *##if ( !$apacheMavenGroupIds.contains( $groupId ) )
 #**##set ( $artId = $project.artifact.artifactId )
 #**##set ( $url = $license.url )
 #**##set ( $spdx = false )
 #**##set ( $includeLicense = true )
 #**###
-#**##if ( $project.artifact.artifactId == "jcl-over-slf4j" )
 
 Review comment:
   everything already done: license in pom.xml was not consistent with license 
in scm
   see https://issues.apache.org/jira/browse/MNG-6779 and the associated PR to 
slf4j that has already been merged


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven] michael-o commented on a change in pull request #297: MNG-6771 Fix license issues on binary distribution

2019-10-27 Thread GitBox
michael-o commented on a change in pull request #297: MNG-6771 Fix license 
issues on binary distribution
URL: https://github.com/apache/maven/pull/297#discussion_r339336197
 
 

 ##
 File path: dev/check-binary-license
 ##
 @@ -0,0 +1,117 @@
+#!/usr/bin/env bash
+#
+# 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.
+#
+
+# Script to check licenses on a binary tarball.
+# It extracts the list of bundled jars, the NOTICE, and the LICENSE
+# files. It checked that every non-maven jar bundled is mentioned in the
+# LICENSE file. It checked that all jar files mentioned in NOTICE and
+# LICENSE are actually bundled.
+
+# all error fatal
+set -e
+
+TARBALL="$1"
+if [ -z $TARBALL ]; then
+echo "Usage: $0 "
+exit -1
+fi
+
+TAR='tar'
+unamestr=`uname`
+if [[ "$unamestr" == 'Linux' ]]; then
 
 Review comment:
   That's bad code. You should rather test for GNU tar instead of Linux.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven] michael-o commented on a change in pull request #297: MNG-6771 Fix license issues on binary distribution

2019-10-27 Thread GitBox
michael-o commented on a change in pull request #297: MNG-6771 Fix license 
issues on binary distribution
URL: https://github.com/apache/maven/pull/297#discussion_r339336129
 
 

 ##
 File path: apache-maven/src/main/appended-resources/META-INF/LICENSE.vm
 ##
 @@ -22,21 +22,18 @@ Apache Maven includes a number of components and libraries 
with separate
 copyright notices and license terms. Your use of those components are 
 subject to the terms and conditions of the following licenses: 
 ##
-#set ( $apacheLicenseNames = [ "Apache License, Version 2.0", "The Apache 
Software License, Version 2.0",
-"ASLv2", "Apache Public License 2.0", "Apache 2.0" ] )
+#set ( $apacheMavenGroupIds = [ "org.apache.maven", "org.apache.maven.wagon", 
"org.apache.maven.resolver",
+"org.apache.maven.shared" ] )
 #set ( $MITLicenseNames = [ "MIT License", "MIT license", "The MIT License" ] )
 #foreach ( $project in $projects )
 #**##foreach ( $license in $project.licenses)
-#*  *##if ( !$apacheLicenseNames.contains( $license.name ) )
+#*  *##set ( $groupId = $project.artifact.groupId )
+#*  *##if ( !$apacheMavenGroupIds.contains( $groupId ) )
 #**##set ( $artId = $project.artifact.artifactId )
 #**##set ( $url = $license.url )
 #**##set ( $spdx = false )
 #**##set ( $includeLicense = true )
 #**###
-#**##if ( $project.artifact.artifactId == "jcl-over-slf4j" )
 
 Review comment:
   This must be raised upstream.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services