September 2013 - shrinkwrap-issues

[JBoss JIRA] (SHRINKRES-140) Update Aether implementation to org.eclipse.aether one

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-140?page=com.atlassian.jira.plu... ] George Gastaldi commented on SHRINKRES-140: ------------------------------------------- Hi Andrew, I managed to work around this by relaxing the default checksum policy setting. It looks like this behavior is changed in this new Aether version. See https://github.com/forge/furnace/blob/master/manager/resolver/maven/src/m... > Update Aether implementation to org.eclipse.aether one > ------------------------------------------------------ > > Key: SHRINKRES-140 > URL: https://issues.jboss.org/browse/SHRINKRES-140 > Project: ShrinkWrap Resolvers > Issue Type: Component Upgrade > Components: impl-maven > Affects Versions: 2.0.0-beta-5 > Reporter: Karel Piwko > Assignee: Michal Matloka > > Aether is now a part of org.eclipse foundation. We should update to newer version when they release first stable version. > Update should not affect user at all, it should comprise of replacing imports with new ones. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-140) Update Aether implementation to org.eclipse.aether one

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-140?page=com.atlassian.jira.plu... ] Andrew Rubinger commented on SHRINKRES-140: ------------------------------------------- Well, setting DefaultRepositorySystemSession.setChecksumPolicy(RepositoryPolicy.CHECKSUM_POLICY_WARN); didn't quite fix it. :) > Update Aether implementation to org.eclipse.aether one > ------------------------------------------------------ > > Key: SHRINKRES-140 > URL: https://issues.jboss.org/browse/SHRINKRES-140 > Project: ShrinkWrap Resolvers > Issue Type: Component Upgrade > Components: impl-maven > Affects Versions: 2.0.0-beta-5 > Reporter: Karel Piwko > Assignee: Michal Matloka > > Aether is now a part of org.eclipse foundation. We should update to newer version when they release first stable version. > Update should not affect user at all, it should comprise of replacing imports with new ones. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-149) Maven classpathworkspace resolver shouldn't assume classes are under target/classes

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-149?page=com.atlassian.jira.plu... ] Andrew Rubinger commented on SHRINKRES-149: ------------------------------------------- Correct, the hardcoded "classes" and "test-classes" directories need to be externalized and configurable. Same holds true for the "pom.xml" assumption in that code block. Let's hear some sensible proposals before we delve into fixing it. Compelling ideas, team? [~m_baechler] feel free to weigh in; what approach do you believe would work well? > Maven classpathworkspace resolver shouldn't assume classes are under target/classes > ----------------------------------------------------------------------------------- > > Key: SHRINKRES-149 > URL: https://issues.jboss.org/browse/SHRINKRES-149 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Affects Versions: 2.0.0 > Reporter: Matthieu Baechler > Assignee: Andrew Rubinger > > To avoid conflicting builds between Maven and Eclipse, I put eclipse build into a "eclipse-build/classes" directory. > Considering this configuration, with the following code : > {code:java} > Maven.resolver() > .offline() > .loadPomFromFile("../../pom.xml") > .resolve("com.linagora.obm:services-module:2.6.0-SNAPSHOT") > .withClassPathResolution(true) > .withTransitivity() > .asFile(); > {code} > Maven resolver find my services-module on the classpath, but when trying a build a jar, it fails in MavenResolvedArtifactImpl.artifactToFile : > {code:java} > // SHRINKRES-102, allow test classes to be packaged as well > File root = new File(artifact.getFile().getParentFile(), "target/classes"); > {code} > In my case, target/classes contains maven build result and not what's on the classpath. > Can this resolver use the classes on the classpath instead ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-149) Maven classpathworkspace resolver shouldn't assume classes are under target/classes

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-149?page=com.atlassian.jira.plu... ] Andrew Rubinger commented on SHRINKRES-149: ------------------------------------------- [~mmatloka], care to take a stab at this? > Maven classpathworkspace resolver shouldn't assume classes are under target/classes > ----------------------------------------------------------------------------------- > > Key: SHRINKRES-149 > URL: https://issues.jboss.org/browse/SHRINKRES-149 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Affects Versions: 2.0.0 > Reporter: Matthieu Baechler > Assignee: Andrew Rubinger > > To avoid conflicting builds between Maven and Eclipse, I put eclipse build into a "eclipse-build/classes" directory. > Considering this configuration, with the following code : > {code:java} > Maven.resolver() > .offline() > .loadPomFromFile("../../pom.xml") > .resolve("com.linagora.obm:services-module:2.6.0-SNAPSHOT") > .withClassPathResolution(true) > .withTransitivity() > .asFile(); > {code} > Maven resolver find my services-module on the classpath, but when trying a build a jar, it fails in MavenResolvedArtifactImpl.artifactToFile : > {code:java} > // SHRINKRES-102, allow test classes to be packaged as well > File root = new File(artifact.getFile().getParentFile(), "target/classes"); > {code} > In my case, target/classes contains maven build result and not what's on the classpath. > Can this resolver use the classes on the classpath instead ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-140) Update Aether implementation to org.eclipse.aether one

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-140?page=com.atlassian.jira.plu... ] Andrew Rubinger commented on SHRINKRES-140: ------------------------------------------- In upstream/SHRINKRES-140, "target/the-other-repository" is never getting populated with any artifacts (as is the case in master). All tests setting this via: System.setProperty(MavenSettingsBuilder.ALT_LOCAL_REPOSITORY_LOCATION, "target/the-other-repository"); ...will then fail. In the working version on master, we *do* have these warnings: WARNING: Corrupted download of org/jboss/shrinkwrap/test/test-deps-a/1.0.0/test-deps-a-1.0.0.jar from file:///home/alr/business/jboss/git/shrinkwrap/resolver/impl-maven/target/repository/. Reason: org.sonatype.aether.transfer.ChecksumFailureException: Checksum validation failed, no checksums available from the repository I wonder aloud if the upgraded Aether simply is failing the download of these artifacts into the local repo when there's no checksum available? > Update Aether implementation to org.eclipse.aether one > ------------------------------------------------------ > > Key: SHRINKRES-140 > URL: https://issues.jboss.org/browse/SHRINKRES-140 > Project: ShrinkWrap Resolvers > Issue Type: Component Upgrade > Components: impl-maven > Affects Versions: 2.0.0-beta-5 > Reporter: Karel Piwko > Assignee: Michal Matloka > > Aether is now a part of org.eclipse foundation. We should update to newer version when they release first stable version. > Update should not affect user at all, it should comprise of replacing imports with new ones. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-140) Update Aether implementation to org.eclipse.aether one

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-140?page=com.atlassian.jira.plu... ] Andrew Rubinger commented on SHRINKRES-140: ------------------------------------------- Update: We've all been hacking on the version at upstream/SHRINKRES-140, and I've just added some more context to the exceptions thrown by failing tests. The primary problem at the moment is stemming from Aether not able to find artifacts in question, for instance: {code}Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: Could not find artifact org.jboss.shrinkwrap.test:test-deps-a:pom:1.0.0{code} > Update Aether implementation to org.eclipse.aether one > ------------------------------------------------------ > > Key: SHRINKRES-140 > URL: https://issues.jboss.org/browse/SHRINKRES-140 > Project: ShrinkWrap Resolvers > Issue Type: Component Upgrade > Components: impl-maven > Affects Versions: 2.0.0-beta-5 > Reporter: Karel Piwko > Assignee: Michal Matloka > > Aether is now a part of org.eclipse foundation. We should update to newer version when they release first stable version. > Update should not affect user at all, it should comprise of replacing imports with new ones. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-149) Maven classpathworkspace resolver shouldn't assume classes are under target/classes

by Matthieu Baechler (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-149?page=com.atlassian.jira.plu... ] Matthieu Baechler commented on SHRINKRES-149: --------------------------------------------- Is there anybody reading issues ? > Maven classpathworkspace resolver shouldn't assume classes are under target/classes > ----------------------------------------------------------------------------------- > > Key: SHRINKRES-149 > URL: https://issues.jboss.org/browse/SHRINKRES-149 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Affects Versions: 2.0.0 > Reporter: Matthieu Baechler > Assignee: Andrew Rubinger > > To avoid conflicting builds between Maven and Eclipse, I put eclipse build into a "eclipse-build/classes" directory. > Considering this configuration, with the following code : > {code:java} > Maven.resolver() > .offline() > .loadPomFromFile("../../pom.xml") > .resolve("com.linagora.obm:services-module:2.6.0-SNAPSHOT") > .withClassPathResolution(true) > .withTransitivity() > .asFile(); > {code} > Maven resolver find my services-module on the classpath, but when trying a build a jar, it fails in MavenResolvedArtifactImpl.artifactToFile : > {code:java} > // SHRINKRES-102, allow test classes to be packaged as well > File root = new File(artifact.getFile().getParentFile(), "target/classes"); > {code} > In my case, target/classes contains maven build result and not what's on the classpath. > Can this resolver use the classes on the classpath instead ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues September 2013