[jira] (SCM-695) Mvn release plugin problems with too many - in name
[
https://jira.codehaus.org/browse/SCM-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365988#comment-365988
]
David SPORN commented on SCM-695:
-
Rebased my [pull request|https://github.com/apache/maven-scm/pull/28]
> Mvn release plugin problems with too many - in name
> ---
>
> Key: SCM-695
> URL: https://jira.codehaus.org/browse/SCM-695
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.7
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Maven home: /home/devent/apps/apache-maven-3.0.3
> Java version: 1.7.0_b147-icedtea, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.1/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.1.9-1.fc16.i686", arch: "i386", family: "unix"
>Reporter: Erwin Mueller
>Priority: Blocker
> Attachments: mvn-release-prepare.log
>
>
> Have maven problems with modules containing too many "-"?
> I have projects that are named:
> {noformat}
> globalpom-groovy/
> globalpom-groovy/globalpom-groovy/pom.xml < parent pom
> globalpom-groovy/globalpom-groovy-izpack/pom.xml
> globalpom-groovy/globalpom-groovy-izpack-snglejar/pom.xml
> globalpom-groovy/globalpom-groovy-testutils/pom.xml
> {noformat}
> But if I do mvn release:prepare inside of globalpom-groovy/globalpom-groovy/,
> then I get the error:
> {noformat}
> [INFO] Executing: /bin/sh -c cd
> /mnt/read/projects/com.anrisoftware/globalpom/globalpom-groovy/globalpom-
> groovy && git add -- pom.xml -izpack/pom.xml -izpack-singlejar/pom.xml -
> testutils/pom.xml
> [INFO] Working directory:
> /mnt/read/projects/com.anrisoftware/globalpom/globalpom-groovy/globalpom-
> groovy
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Global POM Groovy . FAILURE [12.365s]
> [INFO] Global POM Groovy IzPack .. SKIPPED
> [INFO] Global POM Groovy IzPack Single Jar ... SKIPPED
> [INFO] Global POM Groovy Test Utilities .. SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 13.066s
> [INFO] Finished at: Sat Jan 21 15:45:50 CET 2012
> [INFO] Final Memory: 12M/152M
> [INFO]
>
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-
> plugin:2.0:prepare (default-cli) on project globalpom-groovy: Unable to
> commit
> files
> [ERROR] Provider message:
> [ERROR] The git-add command failed.
> [ERROR] Command output:
> [ERROR] fatal: pathspec 'globalpom-groovy/-izpack/pom.xml' did not match any
> files
> {noformat}
> Of course that's wrong 'globalpom-groovy/-izpack/pom.xml' should be
> '../globalpom-groovy-izpack/pom.xml', or something like that.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5795) Maven extensions can not be retrieved from authenticated repositories
[
https://jira.codehaus.org/browse/MNG-5795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365986#comment-365986
]
Jason van Zyl commented on MNG-5795:
Still working locally on ITs, but if anyone wants to try a distro with the
fixes you can try this:
https://www.dropbox.com/sh/q9p0xnem3a1ym9v/AADdI630z8OOlyVCl3vZteJ_a?dl=0
> Maven extensions can not be retrieved from authenticated repositories
> -
>
> Key: MNG-5795
> URL: https://jira.codehaus.org/browse/MNG-5795
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.1
> Environment: RHEL 6.6 on POWER
>Reporter: Jeff Care
>
> I'm attempting to use the new .mvn/extensions.xml feature to load the takari
> smart builder. I get the following error:
> {{{quote}
> Downloading:
> REDACTED/nexus/content/groups/public/io/takari/maven/takari-smart-builder/0.4.0/takari-smart-builder-0.4.0.pom
>
> [WARNING] Failed to read extensions descriptor
> /home/carej/sandbox/sccStandalone/solutions-root/.mvn/extensions.xml: Plugin
> io.takari.maven:takari-smart-builder:0.4.0 or one of its dependencies could
> not be resolved: Failed to read artifact descriptor for
> io.takari.maven:takari-smart-builder:jar:0.4.0
> {quote}}}
> After some initial discussion on the developer mailing list it seems that
> this might be related to using mirrorOf=* against our corporate repository,
> which requires authentication.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SCM-790) Jazz SCM: Support branch creation
[ https://jira.codehaus.org/browse/SCM-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365985#comment-365985 ] Chris Graham commented on SCM-790: -- Hi Martin. Would you be able to share your script anyway? Just for reference? Privately if needed Ta. > Jazz SCM: Support branch creation > - > > Key: SCM-790 > URL: https://jira.codehaus.org/browse/SCM-790 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-jazz >Reporter: Martin E >Priority: Minor > Fix For: 1.9.5 > > > Implement the branching command by creating a stream. > This feature is not implemented yet because (as stated in > JazzBranchCommand.java) the "scm" command doesn't support stream creation. > But since RTC 4 it is possibe to create streams... (see > http://www-01.ibm.com/support/knowledgecenter/SSYMRC_4.0.5/com.ibm.team.scm.doc/topics/create_stream.html) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5796) mvn fails when the current directory is a root drive on Windowds
Brandon Enochs created MNG-5796: --- Summary: mvn fails when the current directory is a root drive on Windowds Key: MNG-5796 URL: https://jira.codehaus.org/browse/MNG-5796 Project: Maven Issue Type: Bug Components: Command Line Affects Versions: 3.3.1 Environment: Windows 7 Reporter: Brandon Enochs Priority: Minor Executing mvn.cmd when the current directory is a drive root like C: outputs the help for the java command. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-555) update versions does not update intermodule dependencies
[ https://jira.codehaus.org/browse/MRELEASE-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MRELEASE-555: Fix Version/s: 2.5.2 > update versions does not update intermodule dependencies > > > Key: MRELEASE-555 > URL: https://jira.codehaus.org/browse/MRELEASE-555 > Project: Maven Release Plugin > Issue Type: Bug > Components: update-versions >Affects Versions: 2.0 > Environment: Maven 2.2.1, JDK 6, XP SP3 >Reporter: Michael Osipov > Fix For: 2.5.2 > > Attachments: MRELEASE-555.patch > > > I recently tried the update-versions goal which is really nice and worked > well. I cleaned my local repo today and reran "mvn package" on a multi-module > project. It failed due tue a depenceny error. > My project was previously on version 2.6.1-SNAPSHOT. Module war depends on > module jar with the same version. When doing a release:prepare, the plugin > perfectly bumps this intermodule dependency. The release:update-versions > missed that dep spot. My build process failed. > The goal should crawl for those deps too and update them if > autoVersionSubmodules is on. (Same behavior as the prepare goal) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-555) update versions does not update intermodule dependencies
[ https://jira.codehaus.org/browse/MRELEASE-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reassigned MRELEASE-555: --- Assignee: Robert Scholte > update versions does not update intermodule dependencies > > > Key: MRELEASE-555 > URL: https://jira.codehaus.org/browse/MRELEASE-555 > Project: Maven Release Plugin > Issue Type: Bug > Components: update-versions >Affects Versions: 2.0 > Environment: Maven 2.2.1, JDK 6, XP SP3 >Reporter: Michael Osipov >Assignee: Robert Scholte > Fix For: 2.5.2 > > Attachments: MRELEASE-555.patch > > > I recently tried the update-versions goal which is really nice and worked > well. I cleaned my local repo today and reran "mvn package" on a multi-module > project. It failed due tue a depenceny error. > My project was previously on version 2.6.1-SNAPSHOT. Module war depends on > module jar with the same version. When doing a release:prepare, the plugin > perfectly bumps this intermodule dependency. The release:update-versions > missed that dep spot. My build process failed. > The goal should crawl for those deps too and update them if > autoVersionSubmodules is on. (Same behavior as the prepare goal) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1024) "verify" goal ignores "dependenciesToScan" parameter when checking tests existence
[
https://jira.codehaus.org/browse/SUREFIRE-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365975#comment-365975
]
Tibor Digana commented on SUREFIRE-1024:
@Sebastian
I have attached a ZIP which still is not able to reproduce this issue. There is
a project and .m2/repository.
Run mvn verify or mvn install on your side.
I am using failsafe 2.18.1. Isn't your version different?
> "verify" goal ignores "dependenciesToScan" parameter when checking tests
> existence
> --
>
> Key: SUREFIRE-1024
> URL: https://jira.codehaus.org/browse/SUREFIRE-1024
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.16
>Reporter: Dmitry Kholodilov
> Fix For: 3.0
>
> Attachments: surefire-1024-works-for-me.zip,
> verify_goal_ignores_dependenciesToScan_parameter_when_checking_tests_existence.patch
>
>
> Consider Maven project with packaging=pom that executes tests from some
> external jar:
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> test
> test
> test
> pom
>
>
> test
> tests-jar
> 1.0
> tests
>
>
> org.testng
> testng
> 6.8
>
>
>
>
>
> maven-failsafe-plugin
> 2.17-SNAPSHOT
>
>
> test:tests-jar
>
>
>
>
> integration-test
> integration-test
>
> integration-test
>
>
>
> verify
> verify
>
> verify
>
>
>
>
>
>
>
> {code}
> (real use case is execution of prebuilt end-to-end tests of some system after
> its deployment)
> When we run `mvn clean verify` on such project, failsafe plugin's "verify"
> goal reports the following:
> {noformat}
> [INFO] --- maven-failsafe-plugin:2.16:verify (verify) @ test ---
> [INFO] No tests to run.
> {noformat}
> Consequently, even if there are test failures, build success is reported.
> The reason of such behavior is that VerifyMojo ignores "dependenciesToScan"
> parameter. So, the fix is easy - check its existence along with
> "testClassesDirectory" existence, the same way as implemented in
> AbstractSurefireMojo.
> The patch in attachment includes integration test that checks for build
> failure when there is failed test from dependency jar.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1024) "verify" goal ignores "dependenciesToScan" parameter when checking tests existence
[
https://jira.codehaus.org/browse/SUREFIRE-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1024:
---
Attachment: surefire-1024-works-for-me.zip
a test with 2.18.1 which is not able to reproduce this issue
> "verify" goal ignores "dependenciesToScan" parameter when checking tests
> existence
> --
>
> Key: SUREFIRE-1024
> URL: https://jira.codehaus.org/browse/SUREFIRE-1024
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.16
>Reporter: Dmitry Kholodilov
> Fix For: 3.0
>
> Attachments: surefire-1024-works-for-me.zip,
> verify_goal_ignores_dependenciesToScan_parameter_when_checking_tests_existence.patch
>
>
> Consider Maven project with packaging=pom that executes tests from some
> external jar:
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> test
> test
> test
> pom
>
>
> test
> tests-jar
> 1.0
> tests
>
>
> org.testng
> testng
> 6.8
>
>
>
>
>
> maven-failsafe-plugin
> 2.17-SNAPSHOT
>
>
> test:tests-jar
>
>
>
>
> integration-test
> integration-test
>
> integration-test
>
>
>
> verify
> verify
>
> verify
>
>
>
>
>
>
>
> {code}
> (real use case is execution of prebuilt end-to-end tests of some system after
> its deployment)
> When we run `mvn clean verify` on such project, failsafe plugin's "verify"
> goal reports the following:
> {noformat}
> [INFO] --- maven-failsafe-plugin:2.16:verify (verify) @ test ---
> [INFO] No tests to run.
> {noformat}
> Consequently, even if there are test failures, build success is reported.
> The reason of such behavior is that VerifyMojo ignores "dependenciesToScan"
> parameter. So, the fix is easy - check its existence along with
> "testClassesDirectory" existence, the same way as implemented in
> AbstractSurefireMojo.
> The patch in attachment includes integration test that checks for build
> failure when there is failed test from dependency jar.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-738) Provide ability to create new version of release version from release other release version [regular patch scenario]
[ https://jira.codehaus.org/browse/MRELEASE-738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365973#comment-365973 ] Robert Scholte commented on MRELEASE-738: - Is this still an issue? Currently, i.e. 2.5.1 (you didn't mention a version) it should work this way. > Provide ability to create new version of release version from release other > release version [regular patch scenario] > > > Key: MRELEASE-738 > URL: https://jira.codehaus.org/browse/MRELEASE-738 > Project: Maven Release Plugin > Issue Type: New Feature > Components: update-versions >Reporter: Paul Green > > Currently release version (using maven release plugin) can be created only > from snapshot version - which works fine but didn't cover the scenario when > you need to patch branch tag and create new version (patched) of release and > not doing that from trunk (that contains snapshot version) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5795) Maven extensions can not be retrieved from authenticated repositories
[
https://jira.codehaus.org/browse/MNG-5795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365972#comment-365972
]
Jason van Zyl commented on MNG-5795:
I have fixed it here locally. Need to write an IT and i'll push it in as soon
as I can.
> Maven extensions can not be retrieved from authenticated repositories
> -
>
> Key: MNG-5795
> URL: https://jira.codehaus.org/browse/MNG-5795
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.1
> Environment: RHEL 6.6 on POWER
>Reporter: Jeff Care
>
> I'm attempting to use the new .mvn/extensions.xml feature to load the takari
> smart builder. I get the following error:
> {{{quote}
> Downloading:
> REDACTED/nexus/content/groups/public/io/takari/maven/takari-smart-builder/0.4.0/takari-smart-builder-0.4.0.pom
>
> [WARNING] Failed to read extensions descriptor
> /home/carej/sandbox/sccStandalone/solutions-root/.mvn/extensions.xml: Plugin
> io.takari.maven:takari-smart-builder:0.4.0 or one of its dependencies could
> not be resolved: Failed to read artifact descriptor for
> io.takari.maven:takari-smart-builder:jar:0.4.0
> {quote}}}
> After some initial discussion on the developer mailing list it seems that
> this might be related to using mirrorOf=* against our corporate repository,
> which requires authentication.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-525) Update-versions does not work in batch mode
[
https://jira.codehaus.org/browse/MRELEASE-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-525.
---
Resolution: Cannot Reproduce
Assignee: Robert Scholte
No feedback, can't reproduce anymore. So closing it.
> Update-versions does not work in batch mode
> ---
>
> Key: MRELEASE-525
> URL: https://jira.codehaus.org/browse/MRELEASE-525
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: update-versions
>Affects Versions: 2.0
> Environment: Maven 2.2.1
>Reporter: Damien Coraboeuf
>Assignee: Robert Scholte
>
> When I run the {{release:update-versions}} goal in batch mode, it performs
> the transformation and just cleans the things up...
> Command which is executed:
> {{mvn -B release:update-versions -DautoVersionSubmodules=true
> -DdevelopmentVersion=0.4.0}}
> The output looks like:
> {noformat}
> [INFO] Transforming 'ModuleA'...
> [INFO] Transforming 'ModuleB'...
> [INFO] Cleaning up after release...
> {noformat}
> If I run the command in interactive mode, everything goes fine:
> {{mvn -B release:update-versions -DautoVersionSubmodules=true}}
> It asks the version on the prompt and updates the pom files accordingly.
> Any idea?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1024) "verify" goal ignores "dependenciesToScan" parameter when checking tests existence
[
https://jira.codehaus.org/browse/SUREFIRE-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365965#comment-365965
]
Tibor Digana commented on SUREFIRE-1024:
@Sebastian
The class AbstractSurefireMojo.java handles the executions differently from
defaul execution.
You may have a look in GitHub https://github.com/apache/maven-surefire and fix
it in new pull request.
> "verify" goal ignores "dependenciesToScan" parameter when checking tests
> existence
> --
>
> Key: SUREFIRE-1024
> URL: https://jira.codehaus.org/browse/SUREFIRE-1024
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.16
>Reporter: Dmitry Kholodilov
> Fix For: 3.0
>
> Attachments:
> verify_goal_ignores_dependenciesToScan_parameter_when_checking_tests_existence.patch
>
>
> Consider Maven project with packaging=pom that executes tests from some
> external jar:
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> test
> test
> test
> pom
>
>
> test
> tests-jar
> 1.0
> tests
>
>
> org.testng
> testng
> 6.8
>
>
>
>
>
> maven-failsafe-plugin
> 2.17-SNAPSHOT
>
>
> test:tests-jar
>
>
>
>
> integration-test
> integration-test
>
> integration-test
>
>
>
> verify
> verify
>
> verify
>
>
>
>
>
>
>
> {code}
> (real use case is execution of prebuilt end-to-end tests of some system after
> its deployment)
> When we run `mvn clean verify` on such project, failsafe plugin's "verify"
> goal reports the following:
> {noformat}
> [INFO] --- maven-failsafe-plugin:2.16:verify (verify) @ test ---
> [INFO] No tests to run.
> {noformat}
> Consequently, even if there are test failures, build success is reported.
> The reason of such behavior is that VerifyMojo ignores "dependenciesToScan"
> parameter. So, the fix is easy - check its existence along with
> "testClassesDirectory" existence, the same way as implemented in
> AbstractSurefireMojo.
> The patch in attachment includes integration test that checks for build
> failure when there is failed test from dependency jar.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (WAGON-436) wagon-ssh kills ecdsa entries in known_hosts
[
https://jira.codehaus.org/browse/WAGON-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Did Lich updated WAGON-436:
---
Description:
I use wagon-ssh in my Android library project:
{code:title=build.gradle|borderStyle=solid}
configurations {
deployerJars
}
dependencies {
deployerJars "org.apache.maven.wagon:wagon-ssh:2.8"
compile fileTree(dir: 'libs', include: ['*.jar'])
}
{code}
which uploads my AAR files over ssh to the specified home directory on my local
server:
{code:title=build.gradle|borderStyle=solid}
uploadArchives {
repositories.mavenDeployer {
configuration = configurations.deployerJars
repository(url: "scp://" + System.getenv("PRJ_MAVEN_REPO_HOST_NAME")) {
authentication(userName: "un", privateKey:
System.getenv("PRJ_MAVEN_REPO_KEY_FILE"))
}
}
}
{code}
After executing the gradle build I see that known_hosts file on my server,
where the build job was running, has been changed and all "ecdsa" entries are
killed. As you can imagine other jobs on the server rely on these entries to
contact other server.
I think this is a no-go if a piece of software is removing entries from a file
where other components are depend on.
Is there a way to fix this by any option settings?
was:
I use wagon-ssh in my Android library project:
configurations {
deployerJars
}
dependencies {
deployerJars "org.apache.maven.wagon:wagon-ssh:2.8"
compile fileTree(dir: 'libs', include: ['*.jar'])
}
which uploads my AAR files over ssh to the specified home directory on my local
server:
uploadArchives {
repositories.mavenDeployer {
configuration = configurations.deployerJars
repository(url: "scp://" + System.getenv("PRJ_MAVEN_REPO_HOST_NAME")) {
authentication(userName: "un", privateKey:
System.getenv("PRJ_MAVEN_REPO_KEY_FILE"))
}
}
}
After executing the gradle build I see that known_hosts file on my server,
where the build job was running, has been changed and all "ecdsa" entries are
killed. As you can imagine other jobs on the server rely on these entries to
contact other server.
I think this is a no-go if a piece of software is removing entries from a file
where other components are depend on.
Is there a way to fix this by any option settings?
> wagon-ssh kills ecdsa entries in known_hosts
>
>
> Key: WAGON-436
> URL: https://jira.codehaus.org/browse/WAGON-436
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.8
> Environment: Ubuntu 12.04
>Reporter: Did Lich
>Priority: Critical
>
> I use wagon-ssh in my Android library project:
> {code:title=build.gradle|borderStyle=solid}
> configurations {
> deployerJars
> }
> dependencies {
> deployerJars "org.apache.maven.wagon:wagon-ssh:2.8"
> compile fileTree(dir: 'libs', include: ['*.jar'])
> }
> {code}
> which uploads my AAR files over ssh to the specified home directory on my
> local server:
> {code:title=build.gradle|borderStyle=solid}
> uploadArchives {
> repositories.mavenDeployer {
> configuration = configurations.deployerJars
> repository(url: "scp://" + System.getenv("PRJ_MAVEN_REPO_HOST_NAME"))
> {
> authentication(userName: "un", privateKey:
> System.getenv("PRJ_MAVEN_REPO_KEY_FILE"))
> }
> }
> }
> {code}
> After executing the gradle build I see that known_hosts file on my server,
> where the build job was running, has been changed and all "ecdsa" entries are
> killed. As you can imagine other jobs on the server rely on these entries to
> contact other server.
> I think this is a no-go if a piece of software is removing entries from a
> file where other components are depend on.
> Is there a way to fix this by any option settings?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (WAGON-436) wagon-ssh kills ecdsa entries in known_hosts
[
https://jira.codehaus.org/browse/WAGON-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365963#comment-365963
]
Did Lich commented on WAGON-436:
A similar behavior is described in WAGON-324.
> wagon-ssh kills ecdsa entries in known_hosts
>
>
> Key: WAGON-436
> URL: https://jira.codehaus.org/browse/WAGON-436
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.8
> Environment: Ubuntu 12.04
>Reporter: Did Lich
>Priority: Critical
>
> I use wagon-ssh in my Android library project:
> configurations {
> deployerJars
> }
> dependencies {
> deployerJars "org.apache.maven.wagon:wagon-ssh:2.8"
> compile fileTree(dir: 'libs', include: ['*.jar'])
> }
> which uploads my AAR files over ssh to the specified home directory on my
> local server:
> uploadArchives {
> repositories.mavenDeployer {
> configuration = configurations.deployerJars
> repository(url: "scp://" + System.getenv("PRJ_MAVEN_REPO_HOST_NAME"))
> {
> authentication(userName: "un", privateKey:
> System.getenv("PRJ_MAVEN_REPO_KEY_FILE"))
> }
> }
> }
> After executing the gradle build I see that known_hosts file on my server,
> where the build job was running, has been changed and all "ecdsa" entries are
> killed. As you can imagine other jobs on the server rely on these entries to
> contact other server.
> I think this is a no-go if a piece of software is removing entries from a
> file where other components are depend on.
> Is there a way to fix this by any option settings?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (WAGON-436) wagon-ssh kills ecdsa entries in known_hosts
Did Lich created WAGON-436:
--
Summary: wagon-ssh kills ecdsa entries in known_hosts
Key: WAGON-436
URL: https://jira.codehaus.org/browse/WAGON-436
Project: Maven Wagon
Issue Type: Bug
Components: wagon-ssh
Affects Versions: 2.8
Environment: Ubuntu 12.04
Reporter: Did Lich
Priority: Critical
I use wagon-ssh in my Android library project:
configurations {
deployerJars
}
dependencies {
deployerJars "org.apache.maven.wagon:wagon-ssh:2.8"
compile fileTree(dir: 'libs', include: ['*.jar'])
}
which uploads my AAR files over ssh to the specified home directory on my local
server:
uploadArchives {
repositories.mavenDeployer {
configuration = configurations.deployerJars
repository(url: "scp://" + System.getenv("PRJ_MAVEN_REPO_HOST_NAME")) {
authentication(userName: "un", privateKey:
System.getenv("PRJ_MAVEN_REPO_KEY_FILE"))
}
}
}
After executing the gradle build I see that known_hosts file on my server,
where the build job was running, has been changed and all "ecdsa" entries are
killed. As you can imagine other jobs on the server rely on these entries to
contact other server.
I think this is a no-go if a piece of software is removing entries from a file
where other components are depend on.
Is there a way to fix this by any option settings?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5795) Maven extensions can not be retrieved from authenticated repositories
[
https://jira.codehaus.org/browse/MNG-5795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365957#comment-365957
]
Jason van Zyl edited comment on MNG-5795 at 4/1/15 9:20 AM:
I can reproduce this. It's definitely not working with a mirror settings. I
don't see any auth headers being passed through. Igor and I touched some of the
same code last release and I think it looks like I set up the execution request
incorrectly.
was (Author: jason):
I can reproduce this. It definitely not working with a mirror settings. I don't
see any auth headers being passed through. Igor and I touched some of the same
code last release and I think it looks like I set up the execution request
incorrectly.
> Maven extensions can not be retrieved from authenticated repositories
> -
>
> Key: MNG-5795
> URL: https://jira.codehaus.org/browse/MNG-5795
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.1
> Environment: RHEL 6.6 on POWER
>Reporter: Jeff Care
>
> I'm attempting to use the new .mvn/extensions.xml feature to load the takari
> smart builder. I get the following error:
> {{{quote}
> Downloading:
> REDACTED/nexus/content/groups/public/io/takari/maven/takari-smart-builder/0.4.0/takari-smart-builder-0.4.0.pom
>
> [WARNING] Failed to read extensions descriptor
> /home/carej/sandbox/sccStandalone/solutions-root/.mvn/extensions.xml: Plugin
> io.takari.maven:takari-smart-builder:0.4.0 or one of its dependencies could
> not be resolved: Failed to read artifact descriptor for
> io.takari.maven:takari-smart-builder:jar:0.4.0
> {quote}}}
> After some initial discussion on the developer mailing list it seems that
> this might be related to using mirrorOf=* against our corporate repository,
> which requires authentication.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5795) Maven extensions can not be retrieved from authenticated repositories
[
https://jira.codehaus.org/browse/MNG-5795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365957#comment-365957
]
Jason van Zyl commented on MNG-5795:
I can reproduce this. It definitely not working with a mirror settings. I don't
see any auth headers being passed through. Igor and I touched some of the same
code last release and I think it looks like I set up the execution request
incorrectly.
> Maven extensions can not be retrieved from authenticated repositories
> -
>
> Key: MNG-5795
> URL: https://jira.codehaus.org/browse/MNG-5795
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.1
> Environment: RHEL 6.6 on POWER
>Reporter: Jeff Care
>
> I'm attempting to use the new .mvn/extensions.xml feature to load the takari
> smart builder. I get the following error:
> {{{quote}
> Downloading:
> REDACTED/nexus/content/groups/public/io/takari/maven/takari-smart-builder/0.4.0/takari-smart-builder-0.4.0.pom
>
> [WARNING] Failed to read extensions descriptor
> /home/carej/sandbox/sccStandalone/solutions-root/.mvn/extensions.xml: Plugin
> io.takari.maven:takari-smart-builder:0.4.0 or one of its dependencies could
> not be resolved: Failed to read artifact descriptor for
> io.takari.maven:takari-smart-builder:jar:0.4.0
> {quote}}}
> After some initial discussion on the developer mailing list it seems that
> this might be related to using mirrorOf=* against our corporate repository,
> which requires authentication.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1024) "verify" goal ignores "dependenciesToScan" parameter when checking tests existence
[
https://jira.codehaus.org/browse/SUREFIRE-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365931#comment-365931
]
Sebastian Paul edited comment on SUREFIRE-1024 at 4/1/15 2:51 AM:
--
I have that problem with JUnit, i.e. it is independent from the provider.
At a first sight, I see a similarity between my POM and and that one in the
description above:
integration-test and verify are in separate executions
In Tibors POM, they are in one single execution.
I can imagine that this is the cause.
My build depends on separate executions, as I need to bind the goals to
different phases than the default,
was (Author: sebpaul):
I have that problem with JUnit, i.e. it is independent from the provider.
> "verify" goal ignores "dependenciesToScan" parameter when checking tests
> existence
> --
>
> Key: SUREFIRE-1024
> URL: https://jira.codehaus.org/browse/SUREFIRE-1024
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.16
>Reporter: Dmitry Kholodilov
> Fix For: 3.0
>
> Attachments:
> verify_goal_ignores_dependenciesToScan_parameter_when_checking_tests_existence.patch
>
>
> Consider Maven project with packaging=pom that executes tests from some
> external jar:
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> test
> test
> test
> pom
>
>
> test
> tests-jar
> 1.0
> tests
>
>
> org.testng
> testng
> 6.8
>
>
>
>
>
> maven-failsafe-plugin
> 2.17-SNAPSHOT
>
>
> test:tests-jar
>
>
>
>
> integration-test
> integration-test
>
> integration-test
>
>
>
> verify
> verify
>
> verify
>
>
>
>
>
>
>
> {code}
> (real use case is execution of prebuilt end-to-end tests of some system after
> its deployment)
> When we run `mvn clean verify` on such project, failsafe plugin's "verify"
> goal reports the following:
> {noformat}
> [INFO] --- maven-failsafe-plugin:2.16:verify (verify) @ test ---
> [INFO] No tests to run.
> {noformat}
> Consequently, even if there are test failures, build success is reported.
> The reason of such behavior is that VerifyMojo ignores "dependenciesToScan"
> parameter. So, the fix is easy - check its existence along with
> "testClassesDirectory" existence, the same way as implemented in
> AbstractSurefireMojo.
> The patch in attachment includes integration test that checks for build
> failure when there is failed test from dependency jar.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1024) "verify" goal ignores "dependenciesToScan" parameter when checking tests existence
[
https://jira.codehaus.org/browse/SUREFIRE-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365931#comment-365931
]
Sebastian Paul commented on SUREFIRE-1024:
--
I have that problem with JUnit, i.e. it is independent from the provider.
> "verify" goal ignores "dependenciesToScan" parameter when checking tests
> existence
> --
>
> Key: SUREFIRE-1024
> URL: https://jira.codehaus.org/browse/SUREFIRE-1024
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.16
>Reporter: Dmitry Kholodilov
> Fix For: 3.0
>
> Attachments:
> verify_goal_ignores_dependenciesToScan_parameter_when_checking_tests_existence.patch
>
>
> Consider Maven project with packaging=pom that executes tests from some
> external jar:
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> test
> test
> test
> pom
>
>
> test
> tests-jar
> 1.0
> tests
>
>
> org.testng
> testng
> 6.8
>
>
>
>
>
> maven-failsafe-plugin
> 2.17-SNAPSHOT
>
>
> test:tests-jar
>
>
>
>
> integration-test
> integration-test
>
> integration-test
>
>
>
> verify
> verify
>
> verify
>
>
>
>
>
>
>
> {code}
> (real use case is execution of prebuilt end-to-end tests of some system after
> its deployment)
> When we run `mvn clean verify` on such project, failsafe plugin's "verify"
> goal reports the following:
> {noformat}
> [INFO] --- maven-failsafe-plugin:2.16:verify (verify) @ test ---
> [INFO] No tests to run.
> {noformat}
> Consequently, even if there are test failures, build success is reported.
> The reason of such behavior is that VerifyMojo ignores "dependenciesToScan"
> parameter. So, the fix is easy - check its existence along with
> "testClassesDirectory" existence, the same way as implemented in
> AbstractSurefireMojo.
> The patch in attachment includes integration test that checks for build
> failure when there is failed test from dependency jar.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-762) Assembly plugin doesn't exclude transitive dependencies when excluded by wildcards in dependencies section
Denis Goihburg created MASSEMBLY-762:
Summary: Assembly plugin doesn't exclude transitive dependencies
when excluded by wildcards in dependencies section
Key: MASSEMBLY-762
URL: https://jira.codehaus.org/browse/MASSEMBLY-762
Project: Maven Assembly Plugin
Issue Type: Bug
Components: dependencySet
Affects Versions: 2.5.3
Reporter: Denis Goihburg
On goal assembly:single with pom file:
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
MyTests
Tests
pom
1.0-SNAPSHOT
org.springframework
spring-core
4.1.0.RELEASE
*
*
org.apache.maven.plugins
maven-assembly-plugin
2.5.3
jar-with-dependencies
{code}
transitive dependency commons-logging appears in resulting jar.
When wildcard is replaced with specific dependency:
{code:xml}
org.springframework
spring-core
4.1.0.RELEASE
commons-logging
commons-logging
{code}
the plugin works as expected and doesn't add this dependency.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
Unsubscription emails are treated as spam
Hello, I want to unsubscrbe from the mailinig list. However my mails are treated as spam. Can anyone provide help? With regards Sebastian
