[JBoss JIRA] (SHRINKRES-223) ClasspathWorkspaceReader does not resolve version variables
by Falko Modler (Jira)
[ https://issues.redhat.com/browse/SHRINKRES-223?page=com.atlassian.jira.pl... ]
Falko Modler commented on SHRINKRES-223:
----------------------------------------
As a side note: Since 3.1.4 {{ClasspathWorkspaceReader}} _does_ support placeholders in the version, but only if {{flatten-maven-plugin}} is used.
See also SHRINKRES-299.
> ClasspathWorkspaceReader does not resolve version variables
> -----------------------------------------------------------
>
> Key: SHRINKRES-223
> URL: https://issues.redhat.com/browse/SHRINKRES-223
> Project: ShrinkWrap Resolvers
> Issue Type: Bug
> Components: maven
> Affects Versions: 2.2.0-beta-2
> Reporter: Thorsten Meinl
> Priority: Major
> Attachments: resolver-bug.zip
>
>
> The ClasspathWorkspaceReader does not resolve variables in artifact versions. We have an artifact whose version is a variable that is defined in its parent pom. "ClasspathWorkspaceReader.createFoundArtifact" reads the variable as-is and does not resolve it to the real version. However, when resolving the dependencies for the "root" artifacts (the one whose pom has been loaded by the resolver via "loadPomFromFile") version variables *are* resolved and therefore there will always be a mismatch.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (SHRINKRES-295) Support Maven 3.6+
by Falko Modler (Jira)
[ https://issues.redhat.com/browse/SHRINKRES-295?page=com.atlassian.jira.pl... ]
Falko Modler commented on SHRINKRES-295:
----------------------------------------
PR upgrading to Maven 3.6.3 was *merged*: https://github.com/shrinkwrap/resolver/pull/140
> Support Maven 3.6+
> ------------------
>
> Key: SHRINKRES-295
> URL: https://issues.redhat.com/browse/SHRINKRES-295
> Project: ShrinkWrap Resolvers
> Issue Type: Feature Request
> Affects Versions: 3.1.3
> Reporter: Aurélien Pupier
> Priority: Major
>
> it seems that shrinkwrap-maven-plugin doesn't work with Maven 3.6+
> It would be nice to have it compatible.
> for instance when using it through syndesis extension maven plugin, there is this error:
> {noformat}
> [ERROR] Failed to execute goal io.syndesis.extension:extension-maven-plugin:1.3.12.fuse-000001-redhat-2:repackage-extension (default) on project custom-step-camel: Execution default of goal io.syndesis.extension:extension-maven-plugin:1.3.12.fuse-000001-redhat-2:repackage-extension failed: Unable to invoke onlyOne([Ljava.lang.Class;@57151b3a) on object org.jboss.shrinkwrap.resolver.spi.loader.ServiceRegistry with parameters [Ljava.lang.Object;@26457986: InvocationTargetException: Could not create new service instance: org/eclipse/aether/internal/impl/DefaultDependencyCollector: org.eclipse.aether.internal.impl.DefaultDependencyCollector -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal io.syndesis.extension:extension-maven-plugin:1.3.12.fuse-000001-redhat-2:repackage-extension (default) on project custom-step-camel: Execution default of goal io.syndesis.extension:extension-maven-plugin:1.3.12.fuse-000001-redhat-2:repackage-extension failed: Unable to invoke onlyOne([Ljava.lang.Class;@57151b3a) on object org.jboss.shrinkwrap.resolver.spi.loader.ServiceRegistry with parameters [Ljava.lang.Object;@26457986
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> 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:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
> 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:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default of goal io.syndesis.extension:extension-maven-plugin:1.3.12.fuse-000001-redhat-2:repackage-extension failed: Unable to invoke onlyOne([Ljava.lang.Class;@57151b3a) on object org.jboss.shrinkwrap.resolver.spi.loader.ServiceRegistry with parameters [Ljava.lang.Object;@26457986
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:148)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
> ... 20 more
> Caused by: org.jboss.shrinkwrap.resolver.api.Invokable$InvocationException: Unable to invoke onlyOne([Ljava.lang.Class;@57151b3a) on object org.jboss.shrinkwrap.resolver.spi.loader.ServiceRegistry with parameters [Ljava.lang.Object;@26457986
> at org.jboss.shrinkwrap.resolver.api.Invokable.invokeMethod(Invokable.java:109)
> at org.jboss.shrinkwrap.resolver.api.ResolverSystemFactory.createFromUserView(ResolverSystemFactory.java:93)
> at org.jboss.shrinkwrap.resolver.api.ResolverSystemFactory.createFromUserView(ResolverSystemFactory.java:54)
> at org.jboss.shrinkwrap.resolver.api.Resolvers.use(Resolvers.java:75)
> at org.jboss.shrinkwrap.resolver.api.maven.Maven.resolver(Maven.java:36)
> at io.syndesis.extension.maven.plugin.RepackageExtensionMojo.obtainBomDependencies(RepackageExtensionMojo.java:262)
> at io.syndesis.extension.maven.plugin.RepackageExtensionMojo.addDefaultBOMs(RepackageExtensionMojo.java:218)
> at io.syndesis.extension.maven.plugin.RepackageExtensionMojo.getAdditionalFilters(RepackageExtensionMojo.java:133)
> at io.syndesis.extension.maven.plugin.SupportMojo.filterDependencies(SupportMojo.java:94)
> at org.springframework.boot.maven.RepackageMojo.repackage(RepackageMojo.java:211)
> at org.springframework.boot.maven.RepackageMojo.execute(RepackageMojo.java:204)
> at io.syndesis.extension.maven.plugin.SupportMojo.execute(SupportMojo.java:50)
> at io.syndesis.extension.maven.plugin.RepackageExtensionMojo.execute(RepackageExtensionMojo.java:113)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> ... 21 more
> Caused by: java.lang.reflect.InvocationTargetException
> 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.jboss.shrinkwrap.resolver.api.Invokable.invokeMethod(Invokable.java:100)
> ... 34 more
> Caused by: java.lang.RuntimeException: Could not create new service instance
> at org.jboss.shrinkwrap.resolver.spi.loader.SpiServiceLoader.createInstance(SpiServiceLoader.java:251)
> at org.jboss.shrinkwrap.resolver.spi.loader.SpiServiceLoader.createInstances(SpiServiceLoader.java:211)
> at org.jboss.shrinkwrap.resolver.spi.loader.SpiServiceLoader.all(SpiServiceLoader.java:79)
> at org.jboss.shrinkwrap.resolver.spi.loader.SpiServiceLoader.onlyOne(SpiServiceLoader.java:85)
> at org.jboss.shrinkwrap.resolver.spi.loader.ServiceRegistry.onlyOne(ServiceRegistry.java:102)
> ... 39 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.jboss.shrinkwrap.resolver.spi.loader.SpiServiceLoader.createInstance(SpiServiceLoader.java:247)
> ... 43 more
> Caused by: java.lang.NoClassDefFoundError: org/eclipse/aether/internal/impl/DefaultDependencyCollector
> at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.ShrinkWrapResolverServiceLocator.<init>(ShrinkWrapResolverServiceLocator.java:157)
> at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenRepositorySystem.getRepositorySystem(MavenRepositorySystem.java:162)
> at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenRepositorySystem.<init>(MavenRepositorySystem.java:61)
> at org.jboss.shrinkwrap.resolver.impl.maven.ConfigurableMavenWorkingSessionImpl.<init>(ConfigurableMavenWorkingSessionImpl.java:58)
> at org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.<init>(MavenWorkingSessionImpl.java:122)
> at org.jboss.shrinkwrap.resolver.impl.maven.MavenResolverSystemImpl.<init>(MavenResolverSystemImpl.java:43)
> ... 48 more
> Caused by: java.lang.ClassNotFoundException: org.eclipse.aether.internal.impl.DefaultDependencyCollector
> at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 54 more
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (SHRINKRES-299) ClasspathWorkspaceReader does not support "Maven CI Friendly Versions" (e.g. ${revision})
by Falko Modler (Jira)
[ https://issues.redhat.com/browse/SHRINKRES-299?page=com.atlassian.jira.pl... ]
Falko Modler updated SHRINKRES-299:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
[~bmajsak] Not sure which "Fix Version/s" to set. I leave this up to you.
> ClasspathWorkspaceReader does not support "Maven CI Friendly Versions" (e.g. ${revision})
> -----------------------------------------------------------------------------------------
>
> Key: SHRINKRES-299
> URL: https://issues.redhat.com/browse/SHRINKRES-299
> Project: ShrinkWrap Resolvers
> Issue Type: Bug
> Components: maven
> Affects Versions: 3.1.3
> Reporter: Falko Modler
> Priority: Major
>
> Maven 3.5.0 introduced [Maven CI Friendly Versions|https://maven.apache.org/maven-ci-friendly.html].
> A version element with such a setup can look like this:
> {code:xml}
> <version>${revision}</version>
> {code}
> Via debugging I found out that {{ClasspathWorkspaceReader}} will never be able to match a given {{artifact}} (which contains the interpolated, final version) with the respective workspace/classpath entry because in {{ClasspathWorkspaceReader.createFoundArtifact(File)}} it just loads the XML document, without any interpolation or even {{parent}} lookup.
> This issuse is very similar to SHRINKRES-223. Nevertheless, I saw/see two reasons for a separate issue:
> - I am not sure that the setup in SHRINKRES-223 is even officially supported by Maven (in contrast to "CI Friendly Versions")
> - I will come up with a PR that re-uses {{.flattened-pom.xml}} (created by {{flatten-maven-plugin}}, see "Install / Deploy" part on the "CI Friendly Versions" page) and that will be of no use for SHRINKRES-223
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (SHRINKRES-298) Various test failures in impl-maven-embedded on Windows
by Falko Modler (Jira)
[ https://issues.redhat.com/browse/SHRINKRES-298?page=com.atlassian.jira.pl... ]
Falko Modler updated SHRINKRES-298:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
[~bmajsak] Not sure which "Fix Version/s" to set. I leave this up to you.
> Various test failures in impl-maven-embedded on Windows
> -------------------------------------------------------
>
> Key: SHRINKRES-298
> URL: https://issues.redhat.com/browse/SHRINKRES-298
> Project: ShrinkWrap Resolvers
> Issue Type: Bug
> Components: EmbeddedMaven
> Affects Versions: 3.1.3
> Reporter: Falko Modler
> Assignee: Matous Jobanek
> Priority: Minor
> Attachments: org.jboss.shrinkwrap.resolver.impl.maven.embedded.BuildOutputTestCase.txt, org.jboss.shrinkwrap.resolver.impl.maven.embedded.invoker.equipped.InvokerEquippedEmbeddedMavenForJarSampleTestCase.txt, org.jboss.shrinkwrap.resolver.impl.maven.embedded.pom.equipped.PomEquippedEmbeddedMavenForJarSampleTestCase.txt, org.jboss.shrinkwrap.resolver.impl.maven.embedded.pom.equipped.PomEquippedEmbeddedMavenRunningAsDaemonTestCase.txt
>
>
> Building the project in this environment:
> {noformat}
> $ ./mvnw -version
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T09:58:13+02:00)
> Maven home: C:\Users\Falko\.m2\wrapper\dists\apache-maven-3.5.2-bin\28qa8v9e2mq69covern8vmdkj0\apache-maven-3.5.2
> Java version: 1.8.0_202, vendor: Oracle Corporation
> Java home: C:\_dev\Java\jdk1.8.0_202\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> {noformat}
> yields multiple test failures which can be broken down into two cause categories:
> - log output matching with {{/}} instead of {{File.separatorChar}}
> - failing {{clean}} due to still opened jar files (Windows is very picky about that)
> The second category is mainly caused by Shrinkwrap leaving {{ZipFile}} objects open after they have been parsed into {{Archives}} (which makes sense if you'd want to modify them) in combination with each test operating on the same test project in {{src/it}}.
> The second aspect is not a good idea in terms of test separation, either.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (SHRINKRES-299) ClasspathWorkspaceReader does not support "Maven CI Friendly Versions" (e.g. ${revision})
by Falko Modler (Jira)
[ https://issues.redhat.com/browse/SHRINKRES-299?page=com.atlassian.jira.pl... ]
Falko Modler updated SHRINKRES-299:
-----------------------------------
Description:
Maven 3.5.0 introduced [Maven CI Friendly Versions|https://maven.apache.org/maven-ci-friendly.html].
A version element with such a setup can look like this:
{code:xml}
<version>${revision}</version>
{code}
Via debugging I found out that {{ClasspathWorkspaceReader}} will never be able to match a given {{artifact}} (which contains the interpolated, final version) with the respective workspace/classpath entry because in {{ClasspathWorkspaceReader.createFoundArtifact(File)}} it just loads the XML document, without any interpolation or even {{parent}} lookup.
This issuse is very similar to SHRINKRES-223. Nevertheless, I saw/see two reasons for a separate issue:
- I am not sure that the setup in SHRINKRES-223 is even officially supported by Maven (in contrast to "CI Friendly Versions")
- I will come up with a PR that re-uses {{.flattened-pom.xml}} (created by {{flatten-maven-plugin}}, see "Install / Deploy" part on the "CI Friendly Versions" page) and that will be of no use for SHRINKRES-223
was:
Maven 3.5.0 introduced [Maven CI Friendly Versions|https://maven.apache.org/maven-ci-friendly.html].
A version element with such a setup can look like this:
{code:xml}
<version>${revision}</version>
{code}
Via debugging I found out that {{ClasspathWorkspaceReader}} will never be able to match a given {{artifact}} (which contains the interpolated, final version) with the respective workspace/classpath entry because in {{ClasspathWorkspaceReader.createFoundArtifact(File)}} it just loads the XML document, without any interpolation or even {{parent}} lookup.
This issuse is related to SHRINKRES-223. I still saw/see two reasons for a separate issue:
- I am not sure that the setup in SHRINKRES-223 is even officially supported by Maven (in contrast to "CI Friendly Versions")
- I will come up with a PR that re-uses {{.flattened-pom.xml}} (created by {{flatten-maven-plugin}}, see "Install / Deploy" part on the "CI Friendly Versions" page) and that will be of no use for SHRINKRES-223
> ClasspathWorkspaceReader does not support "Maven CI Friendly Versions" (e.g. ${revision})
> -----------------------------------------------------------------------------------------
>
> Key: SHRINKRES-299
> URL: https://issues.redhat.com/browse/SHRINKRES-299
> Project: ShrinkWrap Resolvers
> Issue Type: Bug
> Components: maven
> Affects Versions: 3.1.3
> Reporter: Falko Modler
> Priority: Major
>
> Maven 3.5.0 introduced [Maven CI Friendly Versions|https://maven.apache.org/maven-ci-friendly.html].
> A version element with such a setup can look like this:
> {code:xml}
> <version>${revision}</version>
> {code}
> Via debugging I found out that {{ClasspathWorkspaceReader}} will never be able to match a given {{artifact}} (which contains the interpolated, final version) with the respective workspace/classpath entry because in {{ClasspathWorkspaceReader.createFoundArtifact(File)}} it just loads the XML document, without any interpolation or even {{parent}} lookup.
> This issuse is very similar to SHRINKRES-223. Nevertheless, I saw/see two reasons for a separate issue:
> - I am not sure that the setup in SHRINKRES-223 is even officially supported by Maven (in contrast to "CI Friendly Versions")
> - I will come up with a PR that re-uses {{.flattened-pom.xml}} (created by {{flatten-maven-plugin}}, see "Install / Deploy" part on the "CI Friendly Versions" page) and that will be of no use for SHRINKRES-223
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (SHRINKRES-299) ClasspathWorkspaceReader does not support "Maven CI Friendly Versions" (e.g. ${revision})
by Falko Modler (Jira)
Falko Modler created SHRINKRES-299:
--------------------------------------
Summary: ClasspathWorkspaceReader does not support "Maven CI Friendly Versions" (e.g. ${revision})
Key: SHRINKRES-299
URL: https://issues.redhat.com/browse/SHRINKRES-299
Project: ShrinkWrap Resolvers
Issue Type: Bug
Components: maven
Affects Versions: 3.1.3
Reporter: Falko Modler
Maven 3.5.0 introduced [Maven CI Friendly Versions|https://maven.apache.org/maven-ci-friendly.html].
A version element with such a setup can look like this:
{code:xml}
<version>${revision}</version>
{code}
Via debugging I found out that {{ClasspathWorkspaceReader}} will never be able to match a given {{artifact}} (which contains the interpolated, final version) with the respective workspace/classpath entry because in {{ClasspathWorkspaceReader.createFoundArtifact(File)}} it just loads the XML document, without any interpolation or even {{parent}} lookup.
This issuse is related to SHRINKRES-223. I still saw/see two reasons for a separate issue:
- I am not sure that the setup in SHRINKRES-223 is even officially supported by Maven (in contrast to "CI Friendly Versions")
- I will come up with a PR that re-uses {{.flattened-pom.xml}} (created by {{flatten-maven-plugin}}, see "Install / Deploy" part on the "CI Friendly Versions" page) and that will be of no use for SHRINKRES-223
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (SHRINKRES-298) Various test failures in impl-maven-embedded on Windows
by Falko Modler (Jira)
[ https://issues.redhat.com/browse/SHRINKRES-298?page=com.atlassian.jira.pl... ]
Falko Modler updated SHRINKRES-298:
-----------------------------------
Description:
Building the project in this environment:
{noformat}
$ ./mvnw -version
Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T09:58:13+02:00)
Maven home: C:\Users\Falko\.m2\wrapper\dists\apache-maven-3.5.2-bin\28qa8v9e2mq69covern8vmdkj0\apache-maven-3.5.2
Java version: 1.8.0_202, vendor: Oracle Corporation
Java home: C:\_dev\Java\jdk1.8.0_202\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
{noformat}
yields multiple test failures which can be broken down into two cause categories:
- log output matching with {{/}} instead of {{File.separatorChar}}
- failing {{clean}} due to still opened jar files (Windows is very picky about that)
The second category is mainly caused by Shrinkwrap leaving {{ZipFile}} objects open after they have been parsed into {{Archives}} (which makes sense if you'd want to modify them) in combination with each test operating on the same test project in {{src/it}}.
The second aspect is not a good idea in terms of test separation, either.
was:
Building the project in this environment:
{noformat}
$ ./mvnw -version
Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T09:58:13+02:00)
Maven home: C:\Users\Falko\.m2\wrapper\dists\apache-maven-3.5.2-bin\28qa8v9e2mq69covern8vmdkj0\apache-maven-3.5.2
Java version: 1.8.0_202, vendor: Oracle Corporation
Java home: C:\_dev\Java\jdk1.8.0_202\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
{noformat}
yields multiple test failures which can be broken down into two cause categories:
- log output matching with {{/}} instead of {{File.separatorChar}}
- failing {{clean}} due to still opened jar files (Windows is very picky about that)
The second category is mainly caused by Shrinkwrap leaving {{ZipFile}} objects open after they have been parsed into {{Archive}}s (which makes sense if you'd want to modify them) in combination with each test operating on the same test project in {{src/it}}.
The second aspect is not a good idea in terms of test separation, either.
> Various test failures in impl-maven-embedded on Windows
> -------------------------------------------------------
>
> Key: SHRINKRES-298
> URL: https://issues.redhat.com/browse/SHRINKRES-298
> Project: ShrinkWrap Resolvers
> Issue Type: Bug
> Components: EmbeddedMaven
> Affects Versions: 3.1.3
> Reporter: Falko Modler
> Assignee: Matous Jobanek
> Priority: Minor
> Attachments: org.jboss.shrinkwrap.resolver.impl.maven.embedded.BuildOutputTestCase.txt, org.jboss.shrinkwrap.resolver.impl.maven.embedded.invoker.equipped.InvokerEquippedEmbeddedMavenForJarSampleTestCase.txt, org.jboss.shrinkwrap.resolver.impl.maven.embedded.pom.equipped.PomEquippedEmbeddedMavenForJarSampleTestCase.txt, org.jboss.shrinkwrap.resolver.impl.maven.embedded.pom.equipped.PomEquippedEmbeddedMavenRunningAsDaemonTestCase.txt
>
>
> Building the project in this environment:
> {noformat}
> $ ./mvnw -version
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T09:58:13+02:00)
> Maven home: C:\Users\Falko\.m2\wrapper\dists\apache-maven-3.5.2-bin\28qa8v9e2mq69covern8vmdkj0\apache-maven-3.5.2
> Java version: 1.8.0_202, vendor: Oracle Corporation
> Java home: C:\_dev\Java\jdk1.8.0_202\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> {noformat}
> yields multiple test failures which can be broken down into two cause categories:
> - log output matching with {{/}} instead of {{File.separatorChar}}
> - failing {{clean}} due to still opened jar files (Windows is very picky about that)
> The second category is mainly caused by Shrinkwrap leaving {{ZipFile}} objects open after they have been parsed into {{Archives}} (which makes sense if you'd want to modify them) in combination with each test operating on the same test project in {{src/it}}.
> The second aspect is not a good idea in terms of test separation, either.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (SHRINKRES-298) Various test failures in impl-maven-embedded on Windows
by Falko Modler (Jira)
[ https://issues.redhat.com/browse/SHRINKRES-298?page=com.atlassian.jira.pl... ]
Falko Modler updated SHRINKRES-298:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/shrinkwrap/resolver/pull/141
[PR 141|https://github.com/shrinkwrap/resolver/pull/141] created.
> Various test failures in impl-maven-embedded on Windows
> -------------------------------------------------------
>
> Key: SHRINKRES-298
> URL: https://issues.redhat.com/browse/SHRINKRES-298
> Project: ShrinkWrap Resolvers
> Issue Type: Bug
> Components: EmbeddedMaven
> Affects Versions: 3.1.3
> Reporter: Falko Modler
> Assignee: Matous Jobanek
> Priority: Minor
> Attachments: org.jboss.shrinkwrap.resolver.impl.maven.embedded.BuildOutputTestCase.txt, org.jboss.shrinkwrap.resolver.impl.maven.embedded.invoker.equipped.InvokerEquippedEmbeddedMavenForJarSampleTestCase.txt, org.jboss.shrinkwrap.resolver.impl.maven.embedded.pom.equipped.PomEquippedEmbeddedMavenForJarSampleTestCase.txt, org.jboss.shrinkwrap.resolver.impl.maven.embedded.pom.equipped.PomEquippedEmbeddedMavenRunningAsDaemonTestCase.txt
>
>
> Building the project in this environment:
> {noformat}
> $ ./mvnw -version
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T09:58:13+02:00)
> Maven home: C:\Users\Falko\.m2\wrapper\dists\apache-maven-3.5.2-bin\28qa8v9e2mq69covern8vmdkj0\apache-maven-3.5.2
> Java version: 1.8.0_202, vendor: Oracle Corporation
> Java home: C:\_dev\Java\jdk1.8.0_202\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> {noformat}
> yields multiple test failures which can be broken down into two cause categories:
> - log output matching with {{/}} instead of {{File.separatorChar}}
> - failing {{clean}} due to still opened jar files (Windows is very picky about that)
> The second category is mainly caused by Shrinkwrap leaving {{ZipFile}} objects open after they have been parsed into {{Archive}}s (which makes sense if you'd want to modify them) in combination with each test operating on the same test project in {{src/it}}.
> The second aspect is not a good idea in terms of test separation, either.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months