[jira] [Commented] (MNG-6262) getCanonicalFile() is not used consistently during project resolution
[
https://issues.apache.org/jira/browse/MNG-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16109623#comment-16109623
]
Robert Scholte commented on MNG-6262:
-
Maven now requires Java 7, so this is probably a good reason to switch to
{{java.nio.file.Path}} at some places, as long as it doesn't break interfaces.
> getCanonicalFile() is not used consistently during project resolution
> -
>
> Key: MNG-6262
> URL: https://issues.apache.org/jira/browse/MNG-6262
> Project: Maven
> Issue Type: Bug
> Components: core, Reactor and workspace
>Affects Versions: 3.5.0, 3.5.1-candidate
> Environment: Windows 7
>Reporter: Gene Smith
>Priority: Minor
> Attachments: test-inconsistent-canonicalization.zip
>
>
> This bug manifests with...
> * maven 3.5.0 *AND WITH* maven built from 3.5.1's unreleased sources
> * on Windows 7 when the "Drive Letter" is configured with the wrong case.
> * in projects which descend from a pom which does not reference them.
> On Windows getCanonicalFile() is used on module File objects before they
> are wrapped in a FileSource and cached. But DefaultModelBuilder compares
> its cache hits against a File which has not been made cananonical.
> Normally it does not matter on Windows, because the lack of symbolic links
> makes it difficult to find an "Absolute File" which is not the same as its
> "Canonical File", but there is at least one use case it happens in...
> If invoking scripts use a "lower case drive letter" (ex: c:\, d:\, etc...)
> then the "Canonical File" has an "upper case drive letter".
> The error only seems to occur if a POM references a parent which does not list
> the referencing POM as a child. In other words, when there is POM inheritance
> without a reactor module relationship. In my use case there is a Dependency
> Management POM which does not reference all the modules which list it as their
> parent.
> A simple work around is...
> Make sure all your Windows Environments have capital drive letters in the
> Jenkins node configuration, and scripting.
> ..
> {noformat}
> Testing from sources:
> https://git-wip-us.apache.org/repos/asf/maven.git
> origin/master
> b10025751 (HEAD -> master, origin/master, origin/MNG-5457_2,
> origin/HEAD) [MNG-5457] Show repository id when downloading or uploading
> from/to a remote repository
> https://git-wip-us.apache.org/repos/asf/maven-resolver.git
> origin/master
> c9212232 (HEAD -> master, origin/master, origin/HEAD)
> [maven-release-plugin] prepare for next development iteration
> {noformat}
> I found {{DefaultModelBuilder}} compares a POM's Non-Canonical File's URI
> against a
> cached Model's POM's Canonical File's URI.
> {code}
> org.apache.maven.model.building.DefaultModelBuilder
> File pomFile = parentData.getModel().getPomFile();
> if ( pomFile != null )
> {
> ModelSource expectedParentSource = getParentPomFile( childModel,
> childSource );
> if ( expectedParentSource instanceof ModelSource2
> && !pomFile.toURI().equals( ( (ModelSource2)
> expectedParentSource ).getLocationURI() ) )
> {
> parentData = readParentExternally( childModel, request,
> problems );
> }
> }
> {code}
> Where {{ModelSource2}} is a {{org.apache.maven.building.FileSource}} which
> has been
> made from a canonical file.
> In my test environment it composed and compared these two URIs for
> test-inconsistent-canonicalization:dependency-management:pom:1.0.0-SNAPSHOT
> and found they did not match:
> file:/C:/Jenkins/workspace/test/pom.xml
> file:/c:/Jenkins/workspace/test/pom.xml
> resulting in this error output:
> {noformat}
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for
> test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT: Could not find
> artifact
> test-inconsistent-canonicalization:dependency-management:pom:1.0.0-SNAPSHOT
> and 'parent.relativePath' points at wrong local POM @
> test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT,
> C:\Jenkins\workspace\test\reactor\pom.xml, line 5, column 11
> @
> [ERROR] The build could not read 1 project -> [Help 1]
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for
> test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT: Could not find
> artifact
> test-inconsistent-canonicalization:dependency-management:pom:1.0.0-SNAPSHOT
> and 'parent.relativePath' points at wrong local POM @
> test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT,
>
[jira] [Closed] (MNG-6266) Getting error " 2.6 or one of its dependencies could not be resolved" while creating a project in Eclipse.
[ https://issues.apache.org/jira/browse/MNG-6266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MNG-6266. --- Resolution: Not A Problem Assignee: Robert Scholte Closing it for now, just reopen if you have evidence this is really a Maven issue. > Getting error " 2.6 or one of its dependencies could not be resolved" while > creating a project in Eclipse. > -- > > Key: MNG-6266 > URL: https://issues.apache.org/jira/browse/MNG-6266 > Project: Maven > Issue Type: Task > Environment: Windows 8.1, 64 bit OS >Reporter: Saket Kumar >Assignee: Robert Scholte > Attachments: maven_err.png > > > Issue description: > When creating a maven project in Eclipse(version neon.3) getting error "2.6 > or one of its dependencies could not be resolved, Failed to read artifact > descriptor for org.apache.maven.plugins". > Expected: Maven Project should get created. > Actual: Not able to create maven project -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MSHADE-257) Bad zero length source jars published by 3rd parties cause source jar creation to fail.
[ https://issues.apache.org/jira/browse/MSHADE-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jess updated MSHADE-257: Attachment: maven-shade-plugin-257-patch.diff Simple guard against zero length source jars. > Bad zero length source jars published by 3rd parties cause source jar > creation to fail. > --- > > Key: MSHADE-257 > URL: https://issues.apache.org/jira/browse/MSHADE-257 > Project: Maven Shade Plugin > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Jess > Attachments: maven-shade-plugin-257-patch.diff > > > If a transient dependency that is being shaded (in my case > xmlpull:xmlpull:1.1.3.1) published a zero length source jar, then the source > generation will throw a zip exception and abort the build. The plugin should > guard against this and issue a warning instead of failing. > A patch with the guard will be attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MSHADE-257) Bad zero length source jars published by 3rd parties cause source jar creation to fail.
Jess created MSHADE-257: --- Summary: Bad zero length source jars published by 3rd parties cause source jar creation to fail. Key: MSHADE-257 URL: https://issues.apache.org/jira/browse/MSHADE-257 Project: Maven Shade Plugin Issue Type: Improvement Affects Versions: 3.0.0 Reporter: Jess If a transient dependency that is being shaded (in my case xmlpull:xmlpull:1.1.3.1) published a zero length source jar, then the source generation will throw a zip exception and abort the build. The plugin should guard against this and issue a warning instead of failing. A patch with the guard will be attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MSHADE-254) NullPointerException thrown by Maven Shade Plugin 3.0.0
[ https://issues.apache.org/jira/browse/MSHADE-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jess updated MSHADE-254: Attachment: maven-shade-plugin-254-patch.diff The attached patch adds a guard to handle the null return behavior that occurs when a source jar is not published for a given shaded artifact. > NullPointerException thrown by Maven Shade Plugin 3.0.0 > --- > > Key: MSHADE-254 > URL: https://issues.apache.org/jira/browse/MSHADE-254 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 3.0.0 > Environment: Maven 3.5.0 >Reporter: Rafael Winterhalter > Attachments: maven-shade-plugin-254-patch.diff > > > When building my project https://github.com/raphw/byte-buddy, a null pointer > exception is thrown with 3.0.0 that did not occur before: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-shade-plugin:3.0.0:shade (default) on project > byte-buddy: Execution default of goal > org.apache.maven.plugins:maven-shade-plugin:3.0.0:shade failed.: > NullPointerException -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-shade-plugin:3.0.0:shade (default) on > project byte-buddy: Execution default of goal > org.apache.maven.plugins:maven-shade-plugin:3.0.0:shade failed. > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:191) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > Caused by: org.apache.maven.plugin.PluginExecutionException: Execution > default of goal org.apache.maven.plugins:maven-shade-plugin:3.0.0:shade > failed. > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) > ... 20 more > Caused by: java.lang.NullPointerException > at > org.apache.maven.plugins.shade.mojo.ShadeMojo.resolveArtifactSources(ShadeMojo.java:730) > at > org.apache.maven.plugins.shade.mojo.ShadeMojo.processArtifactSelectors(ShadeMojo.java:627) > at > org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:425) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) > ... 21 more -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6265) Controlling reactor order of modules
[ https://issues.apache.org/jira/browse/MNG-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16109351#comment-16109351 ] August Shi commented on MNG-6265: - Thank you for pointing out the --builder option. We implemented a custom Builder and it seems to work for our use case; we can run modules for testing in an order different from the reactor order. The printing of modules is still in the reactor order, but it is something we can work on later. > Controlling reactor order of modules > > > Key: MNG-6265 > URL: https://issues.apache.org/jira/browse/MNG-6265 > Project: Maven > Issue Type: New Feature > Components: core >Affects Versions: 3.5.0 >Reporter: August Shi > Attachments: p.patch > > > We have a use case for controlling the reactor order in Maven, specifically > for running tests on Travis. The common pattern is to run "mvn install > -DskipTests; mvn test". After modules are installed (in the default order), > the modules can be run in any order during testing, e.g., running the failed > modules first, as in -Dsurefire.runOrder=failedfirst for Surefire. > Would this feature be useful for others? I am attaching a *draft* patch that > implements this feature by modifying DefaultMaven.java. I see no clean way of > implementing this feature through an extension, unless some new callback, > e.g., afterProjectsOrdered, is implemented first. Would it be worthwhile to > improve this draft? > One can test the feature by applying the patch, building Maven, and running > tests with the modules in a random order like this: > $ mvn -DdistributionTargetDir=$(pwd)/apache-maven-3.5.x-SNAPSHOT clean > install -DskipTests > $ apache-maven-3.5.x-SNAPSHOT/bin/mvn test -Dmaven.project.order.file=<(ls -d > maven* | shuf) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MRELEASE-911) release plugin forming incorrect git clone command
[
https://issues.apache.org/jira/browse/MRELEASE-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16109293#comment-16109293
]
Robert Scholte commented on MRELEASE-911:
-
[~inforedaster] have you read
http://maven.apache.org/maven-release/maven-release-plugin/examples/branch.html
?
> release plugin forming incorrect git clone command
> --
>
> Key: MRELEASE-911
> URL: https://issues.apache.org/jira/browse/MRELEASE-911
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: Git
>Affects Versions: 2.5.2
>Reporter: sandyzden
>
> git-exe plugin completely ignores the branch parameter and fails in cloning
> the repository during {{release:perform}}
> e.g. git clone --branch this causes it to determine
> the as the branch parameter and failing.
> Below is the error message
> {noformat}
> [ERROR] The git-clone command failed.
> [ERROR] fatal: repository '/target/checkout' does not exist
> {noformat}
> A bit fiddling on the source code i found out
> {code}
> if ( version != null && ( version instanceof ScmBranch ) )
> {
> cl.createArg().setValue( "--branch" );
> cl.createArg().setValue( version.getName() );
> }
> {code}
> it needed version number, but i was not able to figure how it passed from
> Main Mojo to this class
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MPLUGINTESTING-53) default-value on mojo parameter of type collection or array effectively make parameter read-only
Konrad Windszus created MPLUGINTESTING-53:
-
Summary: default-value on mojo parameter of type collection or
array effectively make parameter read-only
Key: MPLUGINTESTING-53
URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-53
Project: Maven Plugin Testing
Issue Type: Bug
Components: plugin-testing-harness
Affects Versions: 3.3.0
Reporter: Konrad Windszus
The tests leveraging {{maven-plugin-testing-harness}} are suffering from the
problem described in https://issues.apache.org/jira/browse/MNG-5440. That
should be fixed by upgrading the sisu plexus dependency to at least 0.3.2.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1396) Provider class path is incorrect for custom provider in Failsafe
[ https://issues.apache.org/jira/browse/SUREFIRE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16108791#comment-16108791 ] ASF GitHub Bot commented on SUREFIRE-1396: -- Github user jon-bell commented on the issue: https://github.com/apache/maven-surefire/pull/161 Done > Provider class path is incorrect for custom provider in Failsafe > > > Key: SUREFIRE-1396 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1396 > Project: Maven Surefire > Issue Type: Bug >Reporter: Jonathan Bell > > Hi, > When using a custom Surefire provider with Surefire (not Failsafe), the > "provider classpath" contains only the provider and surefire-api. However, > when using a custom provider with Failsafe, the provider class path ends up > including a lot more... it seems like perhaps all plugins that are loaded? > This has caused some mayhem for me when using a custom provider in projects > that use a specific version of SLF4J... because then failsafe forces 1.5.6 to > be loaded (from this process of incorrectly finding the custom provider), > causing a crash. > It is a simple fix (3 lines in AbstractSurefireMojo - it had the name of the > Surefire plugin hardcoded, which isn't correct when it's actually Failsafe). > I've got a patched fork of master on GitHub > (https://github.com/jon-bell/maven-surefire/commit/04f66cdd828d131a028eb400d1ed26fe104fe3f2) > that fixes it and an integration test that demonstrates the flaw. I am not > 100% sure on the formatting of the integration test (i.e., I am opening a > JIRA ticket so that I suppose I can name it under the JIRA issue? How should > I specify the current version of surefire in the integration test package?) - > if the fix is welcome against master I'd be happy to open a PR on GitHub. I > am also happy to merge against a different branch if it's more helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MRELEASE-911) release plugin forming incorrect git clone command
[
https://issues.apache.org/jira/browse/MRELEASE-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16108570#comment-16108570
]
Med Reda commented on MRELEASE-911:
---
release:prepare + release:perform ==> create a tag has version without snapshot
release:branch ==> create branche has version with -SNAPSHOT
when i add release:branch + release:perform i have this problem :
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.3:perform (default-cli) on
project impulse-sdk: Unable to checkout from SCM
[ERROR] Provider message:
[ERROR] The git-clone command failed.
[ERROR] Command output:
[ERROR] fatal: repository
'/home/jenkins/workspace/release-exp/reda-projects/target/checkout' does not
exist
how can i have release:branch + release:perform ==> create a branch has
version without snapshot ??!!
any help please
> release plugin forming incorrect git clone command
> --
>
> Key: MRELEASE-911
> URL: https://issues.apache.org/jira/browse/MRELEASE-911
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: Git
>Affects Versions: 2.5.2
>Reporter: sandyzden
>
> git-exe plugin completely ignores the branch parameter and fails in cloning
> the repository during {{release:perform}}
> e.g. git clone --branch this causes it to determine
> the as the branch parameter and failing.
> Below is the error message
> {noformat}
> [ERROR] The git-clone command failed.
> [ERROR] fatal: repository '/target/checkout' does not exist
> {noformat}
> A bit fiddling on the source code i found out
> {code}
> if ( version != null && ( version instanceof ScmBranch ) )
> {
> cl.createArg().setValue( "--branch" );
> cl.createArg().setValue( version.getName() );
> }
> {code}
> it needed version number, but i was not able to figure how it passed from
> Main Mojo to this class
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1396) Provider class path is incorrect for custom provider in Failsafe
[ https://issues.apache.org/jira/browse/SUREFIRE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16108531#comment-16108531 ] ASF GitHub Bot commented on SUREFIRE-1396: -- Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/161 @jon-bell Please squash your commits into one single commit and override your branch. Name the final commit `[SUREFIRE-1396] Provider class path is incorrect for custom provider in Failsafe` > Provider class path is incorrect for custom provider in Failsafe > > > Key: SUREFIRE-1396 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1396 > Project: Maven Surefire > Issue Type: Bug >Reporter: Jonathan Bell > > Hi, > When using a custom Surefire provider with Surefire (not Failsafe), the > "provider classpath" contains only the provider and surefire-api. However, > when using a custom provider with Failsafe, the provider class path ends up > including a lot more... it seems like perhaps all plugins that are loaded? > This has caused some mayhem for me when using a custom provider in projects > that use a specific version of SLF4J... because then failsafe forces 1.5.6 to > be loaded (from this process of incorrectly finding the custom provider), > causing a crash. > It is a simple fix (3 lines in AbstractSurefireMojo - it had the name of the > Surefire plugin hardcoded, which isn't correct when it's actually Failsafe). > I've got a patched fork of master on GitHub > (https://github.com/jon-bell/maven-surefire/commit/04f66cdd828d131a028eb400d1ed26fe104fe3f2) > that fixes it and an integration test that demonstrates the flaw. I am not > 100% sure on the formatting of the integration test (i.e., I am opening a > JIRA ticket so that I suppose I can name it under the JIRA issue? How should > I specify the current version of surefire in the integration test package?) - > if the fix is welcome against master I'd be happy to open a PR on GitHub. I > am also happy to merge against a different branch if it's more helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1400) Windows surefire boot directory should appear in system default temporary-directory
[ https://issues.apache.org/jira/browse/SUREFIRE-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16108527#comment-16108527 ] Tibor Digana commented on SUREFIRE-1400: [~gboue] [~tunaki] I could not establish IT because the IT engine itself has problem to run cmd.exe with long path. Can you install Surefire project and test this snapshot version together with maven-assembly-plugin? > Windows surefire boot directory should appear in system default > temporary-directory > --- > > Key: SUREFIRE-1400 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1400 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin > Environment: Windows >Reporter: Tibor Digana >Assignee: Tibor Digana > > Windows paths are limited in length. The path of surefire boot should point > to system tmp dir. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SUREFIRE-1400) Windows surefire boot directory should appear in system default temporary-directory
[ https://issues.apache.org/jira/browse/SUREFIRE-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1400: --- Description: Windows paths are limited in length. The path of surefire boot should point to system tmp dir. > Windows surefire boot directory should appear in system default > temporary-directory > --- > > Key: SUREFIRE-1400 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1400 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin > Environment: Windows >Reporter: Tibor Digana >Assignee: Tibor Digana > > Windows paths are limited in length. The path of surefire boot should point > to system tmp dir. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1376) "The forked VM terminated without properly saying goodbye" when running Surefire in a very deep project structure on Windows
[
https://issues.apache.org/jira/browse/SUREFIRE-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16108523#comment-16108523
]
Tibor Digana commented on SUREFIRE-1376:
[~gboue]
[~tunaki]
I have created Jira ticket SUREFIRE-1400 with some fix. Can we talk about
Windows issue right there?
> "The forked VM terminated without properly saying goodbye" when running
> Surefire in a very deep project structure on Windows
>
>
> Key: SUREFIRE-1376
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1376
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: Windows
>Reporter: Guillaume Boué
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: SUREFIRE-1376-prefix.patch
>
>
> When Surefire is ran on a project under a very long path (exceeding Windows'
> {{MAX_PATH}}), the invocation fails with
> {noformat}
> org.apache.maven.surefire.booter.SurefireBooterForkException: The forked VM
> terminated without properly saying goodbye. VM crash or System.exit called?
> {noformat}
> In the generated dumpstream, there is
> {noformat}
> # Created on 2017-05-28T10:17:09.474
> Error: Unable to access jarfile
> C:\Users\Guillaume\Desktop\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\target\surefire\surefirebooter2512478076549179739.jar
> {noformat}
> The problem is that the path to the JAR file exceeds the maximum path length
> of 260 characters, and so it cannot be accessed.
> Prepending the path to the JAR file with {{?}}, [as documented
> on
> MSDN|https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath],
> makes the test run again correctly. I've attached a possible patch with this
> approach (SUREFIRE-1376-prefix.patch, that also handles UNC pathnames), but
> perhaps there is a better way to tackle this problem.
> In order to reproduce this, it is possible to create a project under lots of
> different subdirectories, something like:
> {noformat}
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> │ pom.xml
> │
> └───src
> └───test
> └───java
> └───Test.java
> {noformat}
> As a side-note, this issue is behind the current Jenkins failures on
> [maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8_windows|https://builds.apache.org/job/maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8_windows/3702/]
> when running the ITs on the Assembly Plugin.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1400) Windows surefire boot directory should appear in system default temporary-directory
[ https://issues.apache.org/jira/browse/SUREFIRE-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16108524#comment-16108524 ] Tibor Digana commented on SUREFIRE-1400: Review ASF branch https://git1-us-west.apache.org/repos/asf?p=maven-surefire.git;a=shortlog;h=refs/heads/SUREFIRE-1400 > Windows surefire boot directory should appear in system default > temporary-directory > --- > > Key: SUREFIRE-1400 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1400 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin > Environment: Windows >Reporter: Tibor Digana >Assignee: Tibor Digana > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Issue Comment Deleted] (MRELEASE-911) release plugin forming incorrect git clone command
[
https://issues.apache.org/jira/browse/MRELEASE-911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Med Reda updated MRELEASE-911:
--
Comment: was deleted
(was: When i use release:prepare with release:perform it works fin and it
creates a tag otherwise i need a branch instead of tag with this command i have
the same issue :
(mvn clean -DreleaseVersion=${v} -DdevelopmentVersion=${newdevversion}
-DpreparationGoals=clean verify release:branch -DbranchName=release-${v}
release:perform
-DconnectionUrl=scm:git:g...@git.project.net:project-domaine/poc/reda-projects.git
-B)
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.3:perform (default-cli) on
project impulse-sdk: Unable to checkout from SCM
[ERROR] Provider message:
[ERROR] The git-clone command failed.
[ERROR] Command output:
[ERROR] fatal: repository
'/home/jenkins/workspace/release-exp/reda-projects/target/checkout' does not
exist
When i check the existing directory :
'/home/jenkins/workspace/release-exp/reda-projects/target but not have a
"checkout" directory.
any idea ?
)
> release plugin forming incorrect git clone command
> --
>
> Key: MRELEASE-911
> URL: https://issues.apache.org/jira/browse/MRELEASE-911
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: Git
>Affects Versions: 2.5.2
>Reporter: sandyzden
>
> git-exe plugin completely ignores the branch parameter and fails in cloning
> the repository during {{release:perform}}
> e.g. git clone --branch this causes it to determine
> the as the branch parameter and failing.
> Below is the error message
> {noformat}
> [ERROR] The git-clone command failed.
> [ERROR] fatal: repository '/target/checkout' does not exist
> {noformat}
> A bit fiddling on the source code i found out
> {code}
> if ( version != null && ( version instanceof ScmBranch ) )
> {
> cl.createArg().setValue( "--branch" );
> cl.createArg().setValue( version.getName() );
> }
> {code}
> it needed version number, but i was not able to figure how it passed from
> Main Mojo to this class
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (SUREFIRE-1400) Windows surefire boot directory should appear in system default temporary-directory
Tibor Digana created SUREFIRE-1400: -- Summary: Windows surefire boot directory should appear in system default temporary-directory Key: SUREFIRE-1400 URL: https://issues.apache.org/jira/browse/SUREFIRE-1400 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin, Maven Surefire Plugin Environment: Windows Reporter: Tibor Digana Assignee: Tibor Digana -- This message was sent by Atlassian JIRA (v6.4.14#64029)
