[jira] [Closed] (MNG-5879) Add autoproxy support

2015-08-29 Thread Michael Schnell (JIRA)

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

Michael Schnell closed MNG-5879.

Resolution: Duplicate

OK, I'm fine with closing it.

> Add autoproxy support
> -
>
> Key: MNG-5879
> URL: https://issues.apache.org/jira/browse/MNG-5879
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Reporter: Michael Schnell
>
> A common problem with Maven is when you work behind a proxy in large 
> companies. Therefore Maven should support "autoproxy" settings. 
> An example that this is technically possible could be found here: 
> https://github.com/volkertb/autoproxy-maven-plugin 
> (It's just a workaround because Maven lacks such functionality out of the 
> box.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (WAGON-423) Add support of .pac file for proxy configuration

2015-08-29 Thread Michael Schnell (JIRA)

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

Michael Schnell commented on WAGON-423:
---

Just as information: There is a small plugin that tries to solve the autoproxy 
problem. Maybe it's helpful as an inspiration for this issue: 
https://github.com/volkertb/autoproxy-maven-plugin

> Add support of .pac file for proxy configuration
> 
>
> Key: WAGON-423
> URL: https://issues.apache.org/jira/browse/WAGON-423
> Project: Maven Wagon
>  Issue Type: New Feature
>  Components: wagon-http, wagon-http-lightweight
>Reporter: Emmanuel Venisse
>Priority: Minor
>
> Authorize Proxy Auto-Config File (.pac file) for proxy configuration in user 
> model.
> http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html
> =>Use rhino for read the pac file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MRELEASE-549) Pin svn:externals when tagging

2015-08-29 Thread Stephen Connolly (JIRA)

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

Stephen Connolly commented on MRELEASE-549:
---

You would need to do the pinning as a separate revision, then copy to tag and 
then restore the externals to unpinned.

Sent from my iPhone



> Pin svn:externals when tagging
> --
>
> Key: MRELEASE-549
> URL: https://issues.apache.org/jira/browse/MRELEASE-549
> Project: Maven Release Plugin
>  Issue Type: Improvement
>  Components: prepare
>Affects Versions: 2.0
>Reporter: Stephen Connolly
>
> svn:externals is a property set on directories in a subversion repository.
> there are two classes of svn:externals, ones which specify a revision and 
> ones which do not.
> when creating a tag, the tag should only contain svn:externals which have 
> been pinned to specific revisions, otherwise the tag is not a tag, i.e. it is 
> subject to change.
> A generic solution (i.e. not SVN specific) would be to add preTagGoals and 
> postTagGoals so that a custom goal could be invoked around creating the tag.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MRELEASE-549) Pin svn:externals when tagging

2015-08-29 Thread Michael Osipov (JIRA)

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

Michael Osipov commented on MRELEASE-549:
-

This is not natively supported by Subversion: 
http://subversion.apache.org/docs/release-notes/1.9.html#svn-copy-pin-externals

> Pin svn:externals when tagging
> --
>
> Key: MRELEASE-549
> URL: https://issues.apache.org/jira/browse/MRELEASE-549
> Project: Maven Release Plugin
>  Issue Type: Improvement
>  Components: prepare
>Affects Versions: 2.0
>Reporter: Stephen Connolly
>
> svn:externals is a property set on directories in a subversion repository.
> there are two classes of svn:externals, ones which specify a revision and 
> ones which do not.
> when creating a tag, the tag should only contain svn:externals which have 
> been pinned to specific revisions, otherwise the tag is not a tag, i.e. it is 
> subject to change.
> A generic solution (i.e. not SVN specific) would be to add preTagGoals and 
> postTagGoals so that a custom goal could be invoked around creating the tag.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (WAGON-413) Private Key authentication is no longer working with wagon-ssh-2.6

2015-08-29 Thread Florian Kolbe (JIRA)

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

Florian Kolbe commented on WAGON-413:
-

Vielen Dank für Ihre E-Mail.

bis 28.08.15 bin ich außer Haus und kann Ihre E-Mail nicht beantworten.

Bitte wenden Sie sich in dringenden Angelegenheiten an meine Vertretung, Herrn 
Daniel Malhotra (daniel.malho...@in-gmbh.de), oder an die im Vorfeld genannten 
Ansprechpartner.

Ab dem 31.08.15 bin ich wieder wie gewohnt für Sie erreichbar.

-

Thank you very much for your message.

I am out of office from (see above) and cannot reply to your email.

In urgent cases please contact the secretary's office.

I will be back in the office on (see above).

Mit freundlichen Grüßen
Kind regards

Florian Kolbe
IT Consultant
in-integrierte informationssysteme GmbH



> Private Key authentication is no longer working with wagon-ssh-2.6
> --
>
> Key: WAGON-413
> URL: https://issues.apache.org/jira/browse/WAGON-413
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-ssh
>Affects Versions: 2.6
> Environment: Windows, Maven 3.0.4, Java 7 64-bit
>Reporter: Anthony Whitford
>Assignee: Dan Tran
>Priority: Blocker
> Fix For: 2.10
>
> Attachments: maven-wagon-ssh-WAGON-413.patch
>
>
> I have to provide the {{wagon-ssh}} dependency to the {{maven-site-plugin}} 
> in order to upload the site via {{scp}}.  Authentication for the {{scp}} is 
> done via an _SSH key_.
> Version 2.5 works fine, but when I upgrade to version 2.6, I am now getting a 
> Password prompt, and then a _Connection Refused_.  (The Private Key should 
> negate a password prompt.)
> With version 2.6, I get BUILD FAILURE:
> {noformat}
> [INFO] --- maven-site-plugin:3.3:deploy (default-deploy) @ project ---
>  Using private key: C:\Users\BuildAgent\.ssh\id_rsa
>  Password for buildagent@mvnsitehost: 
> scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Connection 
> refused
>  scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: 
> Disconnecting  
>  scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: 
> Disconnected
>  [INFO] 
> 
>  [INFO] BUILD FAILURE
> {noformat}
> With version 2.5, I get BUILD SUCCESS:
> {noformat}
>  [INFO] --- maven-site-plugin:3.3:deploy (default-deploy) @ project ---
>  Using private key: C:\Users\BuildAgent\.ssh\id_rsa
>  scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Opened  
>  [INFO] Pushing D:\BuildAgent\projects\Project\Build_Snapshot\target\site
>  [INFO]>>> to scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/./
>  Executing command: mkdir -p "/opt/maven/sites/project/3.4-SNAPSHOT/./"
>  Executing command: mkdir -p "/opt/maven/sites/project/3.4-SNAPSHOT/."
>  Executing command: scp -t 
> "/opt/maven/sites/project/3.4-SNAPSHOT/./wagon4279752042048724778.zip"
>  Uploading: ./wagon4279752042048724778.zip to 
> scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/
>  
>  
> ##
>  Transfer finished. 316495 bytes copied in 0.031 seconds
>  Executing command: cd "/opt/maven/sites/project/3.4-SNAPSHOT/./"; unzip -q 
> -o "wagon4279752042048724778.zip"; rm -f "wagon4279752042048724778.zip"
>  Executing command: chmod -Rf g+w,a+rX /opt/maven/sites/project/3.4-SNAPSHOT/
>  scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: 
> Disconnecting  
>  scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: 
> Disconnected
>  [INFO] 
> 
>  [INFO] BUILD SUCCESS
> {noformat}
> So, clearly the _new behavior_ is the _Connection Refused_:
> {noformat}
>  Password for buildagent@mvnsitehost: 
> scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Connection 
> refused
> {noformat}
> (?) Could version 2.6 have broken the private key logic?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (WAGON-413) Private Key authentication is no longer working with wagon-ssh-2.6

2015-08-29 Thread Anthony Whitford (JIRA)

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

Anthony Whitford commented on WAGON-413:


Great to see this fixed...  Is there an ETA on the {{wagon-ssh-2.10}} release?

> Private Key authentication is no longer working with wagon-ssh-2.6
> --
>
> Key: WAGON-413
> URL: https://issues.apache.org/jira/browse/WAGON-413
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-ssh
>Affects Versions: 2.6
> Environment: Windows, Maven 3.0.4, Java 7 64-bit
>Reporter: Anthony Whitford
>Assignee: Dan Tran
>Priority: Blocker
> Fix For: 2.10
>
> Attachments: maven-wagon-ssh-WAGON-413.patch
>
>
> I have to provide the {{wagon-ssh}} dependency to the {{maven-site-plugin}} 
> in order to upload the site via {{scp}}.  Authentication for the {{scp}} is 
> done via an _SSH key_.
> Version 2.5 works fine, but when I upgrade to version 2.6, I am now getting a 
> Password prompt, and then a _Connection Refused_.  (The Private Key should 
> negate a password prompt.)
> With version 2.6, I get BUILD FAILURE:
> {noformat}
> [INFO] --- maven-site-plugin:3.3:deploy (default-deploy) @ project ---
>  Using private key: C:\Users\BuildAgent\.ssh\id_rsa
>  Password for buildagent@mvnsitehost: 
> scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Connection 
> refused
>  scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: 
> Disconnecting  
>  scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: 
> Disconnected
>  [INFO] 
> 
>  [INFO] BUILD FAILURE
> {noformat}
> With version 2.5, I get BUILD SUCCESS:
> {noformat}
>  [INFO] --- maven-site-plugin:3.3:deploy (default-deploy) @ project ---
>  Using private key: C:\Users\BuildAgent\.ssh\id_rsa
>  scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Opened  
>  [INFO] Pushing D:\BuildAgent\projects\Project\Build_Snapshot\target\site
>  [INFO]>>> to scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/./
>  Executing command: mkdir -p "/opt/maven/sites/project/3.4-SNAPSHOT/./"
>  Executing command: mkdir -p "/opt/maven/sites/project/3.4-SNAPSHOT/."
>  Executing command: scp -t 
> "/opt/maven/sites/project/3.4-SNAPSHOT/./wagon4279752042048724778.zip"
>  Uploading: ./wagon4279752042048724778.zip to 
> scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/
>  
>  
> ##
>  Transfer finished. 316495 bytes copied in 0.031 seconds
>  Executing command: cd "/opt/maven/sites/project/3.4-SNAPSHOT/./"; unzip -q 
> -o "wagon4279752042048724778.zip"; rm -f "wagon4279752042048724778.zip"
>  Executing command: chmod -Rf g+w,a+rX /opt/maven/sites/project/3.4-SNAPSHOT/
>  scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: 
> Disconnecting  
>  scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: 
> Disconnected
>  [INFO] 
> 
>  [INFO] BUILD SUCCESS
> {noformat}
> So, clearly the _new behavior_ is the _Connection Refused_:
> {noformat}
>  Password for buildagent@mvnsitehost: 
> scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Connection 
> refused
> {noformat}
> (?) Could version 2.6 have broken the private key logic?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MNG-5879) Add autoproxy support

2015-08-29 Thread Michael Osipov (JIRA)

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

Michael Osipov commented on MNG-5879:
-

I am inclined to close this as duplicate of WAGON-423. I have mid-term plans to 
add proxy auto configuration on Windows for HttpClient. Without this, it won't 
happen.

> Add autoproxy support
> -
>
> Key: MNG-5879
> URL: https://issues.apache.org/jira/browse/MNG-5879
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Reporter: Michael Schnell
>
> A common problem with Maven is when you work behind a proxy in large 
> companies. Therefore Maven should support "autoproxy" settings. 
> An example that this is technically possible could be found here: 
> https://github.com/volkertb/autoproxy-maven-plugin 
> (It's just a workaround because Maven lacks such functionality out of the 
> box.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml

2015-08-29 Thread JIRA

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

Hervé Boutemy updated MRELEASE-899:
---
Summary: release:prepare should not change the line separator but detect 
effective line separator from pom.xml  (was: release:prepare should not change 
the line separator (ie detect instead of forcing platform line separator in 
pom.xml))

> release:prepare should not change the line separator but detect effective 
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
>  Issue Type: Improvement
>Reporter: Ralph van Etten
>
> Currently the plugin use the system property {{line.separator}} when it 
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is 
> released sometimes under Windows and sometimes under Linux (because of its 
> different line separators). 
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the 
> systems line separator but the line separator that is already used in the 
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm 
> someone else.
> Therefore it would be an great feature when there would be an property that 
> define the expected behaviour, maybe in the same way it is done by the 
> maven-assembly-plugin's property fileSet.lineEnding 
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (MRELEASE-899) release:prepare should not change the line separator (ie detect instead of forcing platform line separator in pom.xml)

2015-08-29 Thread JIRA

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

Hervé Boutemy updated MRELEASE-899:
---
Summary: release:prepare should not change the line separator (ie detect 
instead of forcing platform line separator in pom.xml)  (was: release:prepare 
should not change the line separator)

> release:prepare should not change the line separator (ie detect instead of 
> forcing platform line separator in pom.xml)
> --
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
>  Issue Type: Improvement
>Reporter: Ralph van Etten
>
> Currently the plugin use the system property {{line.separator}} when it 
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is 
> released sometimes under Windows and sometimes under Linux (because of its 
> different line separators). 
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the 
> systems line separator but the line separator that is already used in the 
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm 
> someone else.
> Therefore it would be an great feature when there would be an property that 
> define the expected behaviour, maybe in the same way it is done by the 
> maven-assembly-plugin's property fileSet.lineEnding 
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MRELEASE-899) release:prepare should not change the line separator

2015-08-29 Thread JIRA

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

Hervé Boutemy commented on MRELEASE-899:


you "prefer to configure (your) Git with option "check out as-is, commit 
UNIX"", ie not like thousands of developpers who work on multi-OS configuration 
(then choose autocrlf=true): that's your choice
I just tell you that:
1. you chose the hard way, for an unknown reason (perhaps the message in the 
git client you're using makes you think that changing line ending is bad, but 
it is good. You can have a look at git official documentation on this: 
https://git-scm.com/book/tr/v2/Customizing-Git-Git-Configuration#Formatting-and-Whitespace
 )
2. I'm working on Maven on my free time and I have a lot to do: one way to not 
add more work is to avoid the hard way

Then, to limit friutration waiting for something that won't happen, I'm clear 
with you:
1. I won't take time on coding this feature myself
2. but if somebody works on it, I'm ready to take time to integrate. How can 
you convince someone to write code for the feature? I don't know: pay someone? 
Or perhaps someone reads this Jira issue and is interested in coding the 
feature.

And to help you, I tell you the feature everybody I know uses: source control 
management line ending management, ie autocrlf=true on git

> release:prepare should not change the line separator
> 
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
>  Issue Type: Improvement
>Reporter: Ralph van Etten
>
> Currently the plugin use the system property {{line.separator}} when it 
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is 
> released sometimes under Windows and sometimes under Linux (because of its 
> different line separators). 
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the 
> systems line separator but the line separator that is already used in the 
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm 
> someone else.
> Therefore it would be an great feature when there would be an property that 
> define the expected behaviour, maybe in the same way it is done by the 
> maven-assembly-plugin's property fileSet.lineEnding 
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)