[jira] (SCM-709) REGRESSION: git status doesn't work if repository root is not the working directory
[
https://jira.codehaus.org/browse/SCM-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317829#comment-317829
]
Tim Kettler commented on SCM-709:
-
I started looking into how to fix this yesterday, too. The most natural
solution for me seemed to be to find the repository root and create the files
based on that. Either by invoking {{git rev-parse --show-toplevel}} or by
walking up the directory tree and looking for {{'.git'}}.
The other issue to consider is the actual semantics of the status command.
Invoked from the repository root all provider implementations behave the same
but from a subdirectory {{svn status}} only shows changes in the subdirectory
and below while git shows changes from the whole repository. Is this intended
or should the scm status command behave uniform regardless of the provider?
> REGRESSION: git status doesn't work if repository root is not the working
> directory
> ---
>
> Key: SCM-709
> URL: https://jira.codehaus.org/browse/SCM-709
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.8, 1.8.1
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Blocker
>
> SCM-686 introduced the {{--porcelain}} option to make the {{status}} result
> language independend.
> Without the {{--porcelain}} option files were listed relative to the working
> directory, but with {{--porcelain}} files are listed relative to the
> repository root. In most cases these are the same, but not always.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-138) No way to control the archiver
Benson Margulies created MSHADE-138:
---
Summary: No way to control the archiver
Key: MSHADE-138
URL: https://jira.codehaus.org/browse/MSHADE-138
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 1.7.1
Reporter: Benson Margulies
The shade plugin produces jars, but lacks support for:
{code:xml}
false
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-709) REGRESSION: git status doesn't work if repository root is not the working directory
[
https://jira.codehaus.org/browse/SCM-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317822#comment-317822
]
Andrei Pozolotin commented on SCM-709:
--
I took a look. few ideas:
1) "/" feels like a hack; who guarantees its presence ?
2) could you differentiate via all of: File.exists() File.isFile()
File.isDirectory() ?
3) "/" probably should be File.separator ?
4) need File.getCanonicalFile() to guard against symlinks ?
5) need File.getAbsolutePath() to actually render File.separator suffix ?
6) only one of oldFilePath or newFilePath is actually present on file system
for File.exists() to work,
could be logic error in :: if ( status == ScmFileStatus.RENAMED ) {} :: block,
if treating both same way ?
7) if original issue is path/file overlap, may be should detect specifically
only that?
> REGRESSION: git status doesn't work if repository root is not the working
> directory
> ---
>
> Key: SCM-709
> URL: https://jira.codehaus.org/browse/SCM-709
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.8, 1.8.1
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Blocker
>
> SCM-686 introduced the {{--porcelain}} option to make the {{status}} result
> language independend.
> Without the {{--porcelain}} option files were listed relative to the working
> directory, but with {{--porcelain}} files are listed relative to the
> repository root. In most cases these are the same, but not always.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-383) Regression for SSLv3
[
https://jira.codehaus.org/browse/WAGON-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317818#comment-317818
]
Jesse Glick commented on WAGON-383:
---
{{e instanceof SSLException && e.toString().contains("bad_record_mac")}} is
pretty specific.
> Regression for SSLv3
>
>
> Key: WAGON-383
> URL: https://jira.codehaus.org/browse/WAGON-383
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 2.2, 2.3
> Environment: Operation system independent, but tested on Macbook Pro
> with 10.6 and Red Hat Enterprise Linux 6 on a virtual machine.
>Reporter: James Kionka
>Priority: Critical
>
> When attempting to access a Maven repository which uses SSLv3, you get the
> following error, "javax.net.ssl.SSLException: Received fatal alert:
> bad_record_mac".
> Earlier versions of Maven used java.net.URLConnection which respects the
> https.protocols system property. This allowed us to set it to SSLv3, which is
> what our Maven repository uses. However, HttpClient ignores that property. In
> other situations, we programmatically tell HttpClient to use SSLv3, which we
> cannot do from our end.
> You can find another person in the same situation here:
> http://stackoverflow.com/questions/12787657/received-fatal-alert-bad-record-mac-when-deploying-to-sonatype
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-383) Regression for SSLv3
[
https://jira.codehaus.org/browse/WAGON-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317811#comment-317811
]
Olivier Lamy commented on WAGON-383:
maybe but how ?
The jdk doesn't provide correct exception to know the cause of the issue.
I don't really like the idea about if exception.getMessage().contains("Received
fatal alert") :-).
> Regression for SSLv3
>
>
> Key: WAGON-383
> URL: https://jira.codehaus.org/browse/WAGON-383
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 2.2, 2.3
> Environment: Operation system independent, but tested on Macbook Pro
> with 10.6 and Red Hat Enterprise Linux 6 on a virtual machine.
>Reporter: James Kionka
>Priority: Critical
>
> When attempting to access a Maven repository which uses SSLv3, you get the
> following error, "javax.net.ssl.SSLException: Received fatal alert:
> bad_record_mac".
> Earlier versions of Maven used java.net.URLConnection which respects the
> https.protocols system property. This allowed us to set it to SSLv3, which is
> what our Maven repository uses. However, HttpClient ignores that property. In
> other situations, we programmatically tell HttpClient to use SSLv3, which we
> cannot do from our end.
> You can find another person in the same situation here:
> http://stackoverflow.com/questions/12787657/received-fatal-alert-bad-record-mac-when-deploying-to-sonatype
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-709) REGRESSION: git status doesn't work if repository root is not the working directory
[
https://jira.codehaus.org/browse/SCM-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317806#comment-317806
]
Robert Scholte commented on SCM-709:
My latest commit was
https://git-wip-us.apache.org/repos/asf?p=maven-scm.git;a=commitdiff;h=6aff3431817108139d29914dc81d8d2dc53e3c6a
The idea is to check for a forward slash at the end. If so, it should be a
directory, otherwise a file.
But if I switch the lines of {{private boolean isFile( String file )}}, some
tests fail.
The reason: if a file does not exist, it returns {{false}}, but that's not the
same as being a directory.
Mark Struberg offered his help within a couple of weeks to check if the tests
are wrong or not.
Or you could speed it up by having a look at it.
> REGRESSION: git status doesn't work if repository root is not the working
> directory
> ---
>
> Key: SCM-709
> URL: https://jira.codehaus.org/browse/SCM-709
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.8, 1.8.1
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Blocker
>
> SCM-686 introduced the {{--porcelain}} option to make the {{status}} result
> language independend.
> Without the {{--porcelain}} option files were listed relative to the working
> directory, but with {{--porcelain}} files are listed relative to the
> repository root. In most cases these are the same, but not always.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-709) REGRESSION: git status doesn't work if repository root is not the working directory
[
https://jira.codehaus.org/browse/SCM-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317801#comment-317801
]
Andrei Pozolotin commented on SCM-709:
--
I am curious what next steps would be?
> REGRESSION: git status doesn't work if repository root is not the working
> directory
> ---
>
> Key: SCM-709
> URL: https://jira.codehaus.org/browse/SCM-709
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.8, 1.8.1
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Blocker
>
> SCM-686 introduced the {{--porcelain}} option to make the {{status}} result
> language independend.
> Without the {{--porcelain}} option files were listed relative to the working
> directory, but with {{--porcelain}} files are listed relative to the
> repository root. In most cases these are the same, but not always.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-422) Unable to find resource 'archetype-resources/*/pom.xml'
[ https://jira.codehaus.org/browse/ARCHETYPE-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317800#comment-317800 ] JM Collin commented on ARCHETYPE-422: - Same problem for me. > Unable to find resource 'archetype-resources/*/pom.xml' > --- > > Key: ARCHETYPE-422 > URL: https://jira.codehaus.org/browse/ARCHETYPE-422 > Project: Maven Archetype > Issue Type: Bug > Components: Generator > Environment: Windows 7, Apache Maven 3.0.4 (r1232337; 2012-01-17 > 00:44:56-0800) > Java version: 1.6.0_30, vendor: Sun Microsystems Inc. >Reporter: Aleksei Serov >Priority: Minor > Attachments: archetype.zip > > > I am running a mvn archetype:generate on multi-module project archetype I > have created using mvn archetype:create-from-project and mvn install. > Archetype attached. > I get: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-archetype-plugin:2.2:generate (default-cli) on > project standalone-pom: > org.apache.maven.archetype.exception.ArchetypeGenerationFailure: Error > merging velocity templates: Unable to find resource > 'archetype-resources/*/pom.xml' -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-archetype-plugin:2.2:generate > (default-cli) on project standalone-pom: > org.apache.maven.archetype.exception.ArchetypeGenerationFailure: Error > merging velocity templates: Unable to find resource > 'archetype-resources/*/pom.xml' -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-383) Regression for SSLv3
[
https://jira.codehaus.org/browse/WAGON-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317776#comment-317776
]
Jesse Glick commented on WAGON-383:
---
Even assuming that Wagon/HttpClient is made to respect {{https.protocols}},
this is hardly friendly. Is it possible for Wagon to detect the probable
symptoms of this error and automatically retry the connection while forcing
SSLv3 handshakes, rather than making the user spend an hour with Google finding
the workaround?
> Regression for SSLv3
>
>
> Key: WAGON-383
> URL: https://jira.codehaus.org/browse/WAGON-383
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 2.2, 2.3
> Environment: Operation system independent, but tested on Macbook Pro
> with 10.6 and Red Hat Enterprise Linux 6 on a virtual machine.
>Reporter: James Kionka
>Priority: Critical
>
> When attempting to access a Maven repository which uses SSLv3, you get the
> following error, "javax.net.ssl.SSLException: Received fatal alert:
> bad_record_mac".
> Earlier versions of Maven used java.net.URLConnection which respects the
> https.protocols system property. This allowed us to set it to SSLv3, which is
> what our Maven repository uses. However, HttpClient ignores that property. In
> other situations, we programmatically tell HttpClient to use SSLv3, which we
> cannot do from our end.
> You can find another person in the same situation here:
> http://stackoverflow.com/questions/12787657/received-fatal-alert-bad-record-mac-when-deploying-to-sonatype
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-383) Regression for SSLv3
[ https://jira.codehaus.org/browse/WAGON-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317770#comment-317770 ] Olivier Lamy commented on WAGON-383: adding support of -Dhttps.protocols="SSLv3" You can replace your wagon jar in $M2_HOME/lib/wagon-http-x.x-shaded.jar With the last snapshot from https://repository.apache.org/content/groups/snapshots/org/apache/maven/wagon/wagon-http/2.4-SNAPSHOT/ build number must be >= 156. And let me know if that work better. Thanks > Regression for SSLv3 > > > Key: WAGON-383 > URL: https://jira.codehaus.org/browse/WAGON-383 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 2.2, 2.3 > Environment: Operation system independent, but tested on Macbook Pro > with 10.6 and Red Hat Enterprise Linux 6 on a virtual machine. >Reporter: James Kionka >Priority: Critical > > When attempting to access a Maven repository which uses SSLv3, you get the > following error, "javax.net.ssl.SSLException: Received fatal alert: > bad_record_mac". > Earlier versions of Maven used java.net.URLConnection which respects the > https.protocols system property. This allowed us to set it to SSLv3, which is > what our Maven repository uses. However, HttpClient ignores that property. In > other situations, we programmatically tell HttpClient to use SSLv3, which we > cannot do from our end. > You can find another person in the same situation here: > http://stackoverflow.com/questions/12787657/received-fatal-alert-bad-record-mac-when-deploying-to-sonatype -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-383) Regression for SSLv3
[ https://jira.codehaus.org/browse/WAGON-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy moved MNG-5363 to WAGON-383: - Complexity: (was: Intermediate) Component/s: (was: Errors) wagon-http Affects Version/s: (was: 3.0.4) 2.3 2.2 Key: WAGON-383 (was: MNG-5363) Project: Maven Wagon (was: Maven 2 & 3) > Regression for SSLv3 > > > Key: WAGON-383 > URL: https://jira.codehaus.org/browse/WAGON-383 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 2.2, 2.3 > Environment: Operation system independent, but tested on Macbook Pro > with 10.6 and Red Hat Enterprise Linux 6 on a virtual machine. >Reporter: James Kionka >Priority: Critical > > When attempting to access a Maven repository which uses SSLv3, you get the > following error, "javax.net.ssl.SSLException: Received fatal alert: > bad_record_mac". > Earlier versions of Maven used java.net.URLConnection which respects the > https.protocols system property. This allowed us to set it to SSLv3, which is > what our Maven repository uses. However, HttpClient ignores that property. In > other situations, we programmatically tell HttpClient to use SSLv3, which we > cannot do from our end. > You can find another person in the same situation here: > http://stackoverflow.com/questions/12787657/received-fatal-alert-bad-record-mac-when-deploying-to-sonatype -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5363) Regression for SSLv3
[ https://jira.codehaus.org/browse/MNG-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317767#comment-317767 ] Gili commented on MNG-5363: --- This issue makes me so frustrated I don't know where to begin :) # Yes, Maven should provide a consistent mechanism for specifying what https protocols to respect regardless of the underlying implementation it decides to use (JDK or HttpClient). # We need to get this fixed in the JDK! The only way to do this is getting an easily reproducible testcase. Any idea on how to do this (ideally using a local server instance?) We need to avoid intermittent failures. > Regression for SSLv3 > > > Key: MNG-5363 > URL: https://jira.codehaus.org/browse/MNG-5363 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Errors >Affects Versions: 3.0.4 > Environment: Operation system independent, but tested on Macbook Pro > with 10.6 and Red Hat Enterprise Linux 6 on a virtual machine. >Reporter: James Kionka >Priority: Critical > > When attempting to access a Maven repository which uses SSLv3, you get the > following error, "javax.net.ssl.SSLException: Received fatal alert: > bad_record_mac". > Earlier versions of Maven used java.net.URLConnection which respects the > https.protocols system property. This allowed us to set it to SSLv3, which is > what our Maven repository uses. However, HttpClient ignores that property. In > other situations, we programmatically tell HttpClient to use SSLv3, which we > cannot do from our end. > You can find another person in the same situation here: > http://stackoverflow.com/questions/12787657/received-fatal-alert-bad-record-mac-when-deploying-to-sonatype -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-643) release:branch in mercurial provider updates the version in the new branch
[ https://jira.codehaus.org/browse/SCM-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317761#comment-317761 ] Magne Nordtveit commented on SCM-643: - This also affects version 1.8. Currently when using release plugin to perform a release:branch, I have to manually rebase the last commit to the release branch over to the original branch. Although this is a simple task in theory, it causes some issues when we want to automate the release process. > release:branch in mercurial provider updates the version in the new branch > -- > > Key: SCM-643 > URL: https://jira.codehaus.org/browse/SCM-643 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-mercurial (hg) >Affects Versions: 1.5, 1.6 >Reporter: Jared Bunting > Attachments: hg-scm-branch-fix.patch > > > When running release:branch with a mercurial repository, and having all > properties set to defaults, I would expect the current version to be carried > over to the new branch, and the new "developmentVersion" to be set on the > original branch. This is the behavior that I have always seen in the > subversion provider (which is the only other one that I really have > experience with), and what I believe the documentation states. However, that > is not the behavior that I am seeing. I see the branch created, then the new > version set on the branch. > I believe the issue is that HgBranchCommand not only creates a new branch, > but updates the working copy to the new branch. This seems to be counter to > the behavior expected by maven-release-plugin, differs from the behavior in > the subversion provider, and also seems to not be the behavior described in > the ScmProvider interface. > Since this "updating to the new branch" behavior is inherent to mercurial, > I've written a patch that saves the original branch name prior to branching, > and after branching is complete updates to the original branch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5363) Regression for SSLv3
[
https://jira.codehaus.org/browse/MNG-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317745#comment-317745
]
James Kionka commented on MNG-5363:
---
Gili, the link in your comment on 23/Dec/12 2:26 PM is correct. Hendy, I agree,
all the SSL error messages I've seen are pretty terrible.
This ticket is more or less independent of deploying to oss.sonatype.org. Based
on the error description and attempted fixes on the stackoverflow page, it
sounds almost exactly like this problem. The one part that does not make sense
is that their deployments failed only sometimes. Our problem is repeatable. I
figured their problem was intermittent from a load balancer which was sometimes
sent the client to an SSLv3 server. However, based on Roberto's comments and
the current evidence, these problems are not related as it originally seemed.
Our team at work was able to handle the Java SSLv3 issues for
java.net.URLConnection using:
-Dhttps.protocols="SSLv3"
or
System.setProperty("https.protocols", "SSLv3");
This how we worked out the issue before Maven made the switch to HttpClient in
3.0.4. HttpClient does not respect this setting.
When we use HttpClient in our other projects, we have a method named
getSslv3SocketFactory() which creates a generic SocketFactory with the method
on it.
private void setSslv3Protocol(SSLSocket sslSocket) {
sslSocket.setEnabledProtocols(new String[] { "SSLv3" });
}
We then create ThreadSafeClientConnManager using our SocketFactory.
(Apparently, it is now called PoolingClientConnectionManager.)
How to create that object is explained in "2.8.4. Pooling connection manager":
https://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html
Javadoc for PoolingClientConnectionManager:
https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/conn/PoolingClientConnectionManager.html
This is obviously a frustrating solution, but there were no other options. Part
of life is that web browsers handle SSL better than Java, and HttpClient did
not feel like this was something they'd like to make easy.
Some more background is available at:
http://stackoverflow.com/questions/2159586/jsse-handshake-failure-on-public-https-web-site
http://docs.oracle.com/javase/1.4.2/docs/guide/plugin/developer_guide/faq/troubleshooting.html
http://httpcomponents.10934.n7.nabble.com/Fwd-Httpclient-sslv3-amp-bad-record-mac-error-td16136.html#a21999553
Maven could really use a way to specify what https protocols to respect, one
way or another, since there is currently no way to do so as of 3.0.4. This
could be done in a lot of different ways, but respecting the System Property
seems like a clean solution to me at this time.
> Regression for SSLv3
>
>
> Key: MNG-5363
> URL: https://jira.codehaus.org/browse/MNG-5363
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Errors
>Affects Versions: 3.0.4
> Environment: Operation system independent, but tested on Macbook Pro
> with 10.6 and Red Hat Enterprise Linux 6 on a virtual machine.
>Reporter: James Kionka
>Priority: Critical
>
> When attempting to access a Maven repository which uses SSLv3, you get the
> following error, "javax.net.ssl.SSLException: Received fatal alert:
> bad_record_mac".
> Earlier versions of Maven used java.net.URLConnection which respects the
> https.protocols system property. This allowed us to set it to SSLv3, which is
> what our Maven repository uses. However, HttpClient ignores that property. In
> other situations, we programmatically tell HttpClient to use SSLv3, which we
> cannot do from our end.
> You can find another person in the same situation here:
> http://stackoverflow.com/questions/12787657/received-fatal-alert-bad-record-mac-when-deploying-to-sonatype
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
