May 2013 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] (SHRINKRES-133) RejectDependenciesFilter and strategy should be able to work in both recursive and nonrecursive way

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-133?page=com.atlassian.jira.plu... ] Karel Piwko reassigned SHRINKRES-133: ------------------------------------- Assignee: Karel Piwko (was: Andrew Rubinger) > RejectDependenciesFilter and strategy should be able to work in both recursive and nonrecursive way > --------------------------------------------------------------------------------------------------- > > Key: SHRINKRES-133 > URL: https://issues.jboss.org/browse/SHRINKRES-133 > Project: ShrinkWrap Resolvers > Issue Type: Enhancement > Reporter: Karel Piwko > Assignee: Karel Piwko > > It is unclear what should happen if you use RejectDependencies Filter/Strategy. > Currently, it does: > 1/ Reject in preResolution -> that means dependency is removed including all possible transtives > 2/ Reject in resolution -> removed during resolution, not including transitives > We need to cover both use cases especially with SHRINKRES-112 changes. -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-136) System scoped dependencies shouldn't be added to WAR

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-136?page=com.atlassian.jira.plu... ] Andrew Rubinger commented on SHRINKRES-136: ------------------------------------------- Warning: SHRINKRES-112 as provided now has breaking API changes. Working with Karel to resolve. > System scoped dependencies shouldn't be added to WAR > ---------------------------------------------------- > > Key: SHRINKRES-136 > URL: https://issues.jboss.org/browse/SHRINKRES-136 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Components: impl-maven > Affects Versions: 2.0.0-beta-3 > Reporter: Ron Šmeral > Assignee: Karel Piwko > Fix For: 2.0.0-beta-4 > > > When resolving dependencies with {{importRuntimeDependencies}} and adding them to an archive as in > {code} > File[] libs = Maven.resolver().loadPomFromFile("pom.xml").importRuntimeDependencies().asFile(); > ShrinkWrap.create(WebArchive.class, "seam-blog.war").addAsLibraries(libs); > {code} > system-scoped dependencies are resolved and added to the archive as well. > This should not happen and should be aligned with the behaviour of the maven war plugin, as described in this issue: https://jira.codehaus.org/browse/MWAR-23. -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-137) Remove extra debug output from FileUitil

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-137?page=com.atlassian.jira.plu... ] Andrew Rubinger resolved SHRINKRES-137. --------------------------------------- Resolution: Done https://github.com/shrinkwrap/resolver/commit/2216a7c3a6730a91f2226887513... > Remove extra debug output from FileUitil > ---------------------------------------- > > Key: SHRINKRES-137 > URL: https://issues.jboss.org/browse/SHRINKRES-137 > Project: ShrinkWrap Resolvers > Issue Type: Task > Affects Versions: 2.0.0-beta-3 > Reporter: Andrew Rubinger > Assignee: Karel Piwko > Fix For: 2.0.0-beta-4 > > -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-137) Remove extra debug output from FileUitil

by Andrew Rubinger (JIRA)

Andrew Rubinger created SHRINKRES-137: ----------------------------------------- Summary: Remove extra debug output from FileUitil Key: SHRINKRES-137 URL: https://issues.jboss.org/browse/SHRINKRES-137 Project: ShrinkWrap Resolvers Issue Type: Task Affects Versions: 2.0.0-beta-3 Reporter: Andrew Rubinger Assignee: Karel Piwko Fix For: 2.0.0-beta-4 -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-136) System scoped dependencies shouldn't be added to WAR

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-136?page=com.atlassian.jira.plu... ] Karel Piwko commented on SHRINKRES-136: --------------------------------------- This seems to be fixed by SHRINKRES-112 impl. > System scoped dependencies shouldn't be added to WAR > ---------------------------------------------------- > > Key: SHRINKRES-136 > URL: https://issues.jboss.org/browse/SHRINKRES-136 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Components: impl-maven > Affects Versions: 2.0.0-beta-3 > Reporter: Ron Šmeral > Assignee: Karel Piwko > Fix For: 2.0.0-beta-4 > > > When resolving dependencies with {{importRuntimeDependencies}} and adding them to an archive as in > {code} > File[] libs = Maven.resolver().loadPomFromFile("pom.xml").importRuntimeDependencies().asFile(); > ShrinkWrap.create(WebArchive.class, "seam-blog.war").addAsLibraries(libs); > {code} > system-scoped dependencies are resolved and added to the archive as well. > This should not happen and should be aligned with the behaviour of the maven war plugin, as described in this issue: https://jira.codehaus.org/browse/MWAR-23. -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-135) Ignore maven.repo.local for MavenImporter tests

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-135?page=com.atlassian.jira.plu... ] Karel Piwko resolved SHRINKRES-135. ----------------------------------- Fix Version/s: 2.0.0-beta-4 Resolution: Done Pushed upstream in https://github.com/shrinkwrap/resolver/commit/c9b124cf7afb9693119efc3bf38... > Ignore maven.repo.local for MavenImporter tests > ----------------------------------------------- > > Key: SHRINKRES-135 > URL: https://issues.jboss.org/browse/SHRINKRES-135 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Reporter: Karel Piwko > Assignee: Karel Piwko > Priority: Minor > Fix For: 2.0.0-beta-4 > > > -Dmaven.repo.local will override location where tests are looking for the artifacts during install phase or on jenkins, so we need to ignore that property. -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-402) Support method for checking what type of Archive this is

by John Ament (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-402?page=com.atlassian.jira.pl... ] John Ament commented on SHRINKWRAP-402: --------------------------------------- I don't think it needs to be a core of it, but there should be a way to validate the archive in some manner, perhaps one version is based on its name. ShrinkWrap.create(WebArchive.class).addClasses(Foo.class,Bar.class,FooBar.class).validateUsing(WebArchiveValidator.class); There just needs to be a way to do it, not that ShrinkWrap needs to enforce these rules (since *ar's are just zip files after all) > Support method for checking what type of Archive this is > -------------------------------------------------------- > > Key: SHRINKWRAP-402 > URL: https://issues.jboss.org/browse/SHRINKWRAP-402 > Project: ShrinkWrap > Issue Type: Feature Request > Components: api, impl-base > Affects Versions: 1.0.0 > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > > ShrinkWrap has the notion of views to wrap a Archive. While a view can be anything, some of the views describes types of Archives, e.g. WebArchive. A Archive should be able to tell which type it is. Even tho the content structure to some extent define the type, external sources like a Container will determine the type of the Archive soley on the archive name extension. > {code} > ShrinkWrap.create(JavaArchive.class).isOfType(WebArchive.class) == false > ShrinkWrap.create(JavaArchive.class, "my.war").isOfType(WebArchive.class) == true > ShrinkWrap.create(MySpecialWebArchive.class, "my.war").isOfType(WebArchive.class) == true > {code} > A simple check if the current archive name ends with the Types defined extension mapping should work in most cases. -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-402) Support method for checking what type of Archive this is

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-402?page=com.atlassian.jira.pl... ] Andrew Rubinger commented on SHRINKWRAP-402: -------------------------------------------- So what we're asking here really is to further couple ShrinkWrap archives (generic VFS) with Java EE spec-defined naming conventions. I'm not a fan of coupling in general, but as it stands, Java EE support is already built into ShrinkWrap core. This seems like a natural extension of that, and if it makes things easier for users without introducing some opinionated behaviors, then OK. > Support method for checking what type of Archive this is > -------------------------------------------------------- > > Key: SHRINKWRAP-402 > URL: https://issues.jboss.org/browse/SHRINKWRAP-402 > Project: ShrinkWrap > Issue Type: Feature Request > Components: api, impl-base > Affects Versions: 1.0.0 > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > > ShrinkWrap has the notion of views to wrap a Archive. While a view can be anything, some of the views describes types of Archives, e.g. WebArchive. A Archive should be able to tell which type it is. Even tho the content structure to some extent define the type, external sources like a Container will determine the type of the Archive soley on the archive name extension. > {code} > ShrinkWrap.create(JavaArchive.class).isOfType(WebArchive.class) == false > ShrinkWrap.create(JavaArchive.class, "my.war").isOfType(WebArchive.class) == true > ShrinkWrap.create(MySpecialWebArchive.class, "my.war").isOfType(WebArchive.class) == true > {code} > A simple check if the current archive name ends with the Types defined extension mapping should work in most cases. -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-116) Gradle support

by SBS JIRA Integration (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-116?page=com.atlassian.jira.plu... ] SBS JIRA Integration updated SHRINKRES-116: ------------------------------------------- Forum Reference: https://community.jboss.org/message/820137#820137 > Gradle support > -------------- > > Key: SHRINKRES-116 > URL: https://issues.jboss.org/browse/SHRINKRES-116 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Affects Versions: 2.0.0-beta-2 > Reporter: Michal Matloka > Assignee: Michal Matloka > > ShrinkWrap Resolver was designed to support multiple dependency management/build systems. It seems that there are already people using Gradle wanting to use ShrinkWrap. API seems much more friendly than Aether ;) and probably even supports build in 'build' feature. > http://forums.gradle.org/gradle/topics/dependency_resolution_with_gradle_... > http://gradle.1045684.n5.nabble.com/Gradle-support-for-Arquillian-maybe-a... > https://community.jboss.org/message/772433 -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-402) Support method for checking what type of Archive this is

by John Ament (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-402?page=com.atlassian.jira.pl... ] John Ament commented on SHRINKWRAP-402: --------------------------------------- +1 ShrinkWrap should export the right types. > Support method for checking what type of Archive this is > -------------------------------------------------------- > > Key: SHRINKWRAP-402 > URL: https://issues.jboss.org/browse/SHRINKWRAP-402 > Project: ShrinkWrap > Issue Type: Feature Request > Components: api, impl-base > Affects Versions: 1.0.0 > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > > ShrinkWrap has the notion of views to wrap a Archive. While a view can be anything, some of the views describes types of Archives, e.g. WebArchive. A Archive should be able to tell which type it is. Even tho the content structure to some extent define the type, external sources like a Container will determine the type of the Archive soley on the archive name extension. > {code} > ShrinkWrap.create(JavaArchive.class).isOfType(WebArchive.class) == false > ShrinkWrap.create(JavaArchive.class, "my.war").isOfType(WebArchive.class) == true > ShrinkWrap.create(MySpecialWebArchive.class, "my.war").isOfType(WebArchive.class) == true > {code} > A simple check if the current archive name ends with the Types defined extension mapping should work in most cases. -- 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

11 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues May 2013