shrinkwrap-issues July 2018

shrinkwrap-issues@lists.jboss.org

1 participants
3 discussions

[JBoss JIRA] (SHRINKRES-289) Different dependency resolution than Maven

by Vincent Massol (JIRA)

Vincent Massol created SHRINKRES-289: ---------------------------------------- Summary: Different dependency resolution than Maven Key: SHRINKRES-289 URL: https://issues.jboss.org/browse/SHRINKRES-289 Project: ShrinkWrap Resolvers Issue Type: Bug Components: maven Affects Versions: 3.1.3 Reporter: Vincent Massol The problem seems to be that Shrinkwrap Resolver takes the first artifact in the tree (navigating each dependency node to the deepest), while Maven takes the artifact closest to the top ("Dependency mediation - this determines what version of a dependency will be used when multiple versions of an artifact are encountered. Currently, Maven 2.0 only supports using the "nearest definition" which means that it will use the version of the closest dependency to your project in the tree of dependencies." from Maven – Introduction to the Dependency Mechanism ). On https://github.com/shrinkwrap/resolver/blob/master/maven/api-maven/src/ma... the doc says "Applies the default behavior exhibited by Maven with regards to handling transitive dependencies during resolution" which seems to indicate that Shrinkwrap is trying to do the same as Maven does. Thanks a lot. This is a blocker for the XWiki project and I hope there's a solution. See https://developer.jboss.org/message/984168#984168 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-522) ManifestContainer.addAsServiceProvider() - make it possible to augment an existing service provider

by Martin Kouba (JIRA)

Martin Kouba created SHRINKWRAP-522: --------------------------------------- Summary: ManifestContainer.addAsServiceProvider() - make it possible to augment an existing service provider Key: SHRINKWRAP-522 URL: https://issues.jboss.org/browse/SHRINKWRAP-522 Project: ShrinkWrap Issue Type: Feature Request Reporter: Martin Kouba Copied from https://github.com/shrinkwrap/shrinkwrap/issues/112 ShrinkWrap currently overwrites the previous value without any warning. It would be useful to make it possible to merge the values instead. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-521) Can't compile without compile without JAVA_HOME set, due to NPE in JavacCompiler

by Jan-Willem Gmelig Meyling (JIRA)

Jan-Willem Gmelig Meyling created SHRINKWRAP-521: ---------------------------------------------------- Summary: Can't compile without compile without JAVA_HOME set, due to NPE in JavacCompiler Key: SHRINKWRAP-521 URL: https://issues.jboss.org/browse/SHRINKWRAP-521 Project: ShrinkWrap Issue Type: Bug Reporter: Jan-Willem Gmelig Meyling Priority: Trivial If JAVA_HOME is not set, the Plexus JavacCompiler will fallback to "which javac". However, this statement is logged without a proper check that checks whether logging is enabled (see my pull request https://github.com/codehaus-plexus/plexus-compiler/pull/52 ). Because Shrinkwrap does not attach a logger to the JavacCompiler, and this issue in Plexus Compiler, the JavacCompiler will throw a null pointer exception during compilation causing the test run to fail. I've already proposed a PR to Plexus Compiler, but perhaps it is a good idea to attach a logger anyway so that compilation output can be printed to the logging output, which will also resolve this issue. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

← Newer
1
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues July 2018