December 2015 - shrinkwrap-issues

[JBoss JIRA] (SHRINKWRAP-492) addPackages method not ever succeeds

by G. Richard Bellamy (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-492?page=com.atlassian.jira.pl... ] G. Richard Bellamy commented on SHRINKWRAP-492: ----------------------------------------------- Sorry for the noise - something else is going on for me. Nothing I use (neither {{addPackage(s)}} or {{addClasses}}) is succeeding. > addPackages method not ever succeeds > ------------------------------------ > > Key: SHRINKWRAP-492 > URL: https://issues.jboss.org/browse/SHRINKWRAP-492 > Project: ShrinkWrap > Issue Type: Bug > Components: impl-base > Environment: shrinkwrap-impl-base 1.2.2 > Reporter: Luca Stancapiano > > there are cases where the addPackages method doesn't succeed to load the packages also if they are in the current classloader. An example can be the com.h2database library. This library is registered as resource in the classloader with the name com.h2database and ambigously it contains the package org.h2. > If I try to include the library in my shrinkwrap java archive with the expression addPackages(true, "com") or with the expression addPackages(true, "org") , the h2 packages are not loaded because shrinkwrap need the name of the resource starting with the same name of the package. > So seems that shrinkwrap can load only something as a resource called com.h2database combined with the package com.h2 or a resource called org.h2database combined with the package org.h2. > I presume this ambiguous name should be managed in shrinkwrap -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-492) addPackages method not ever succeeds

by G. Richard Bellamy (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-492?page=com.atlassian.jira.pl... ] G. Richard Bellamy commented on SHRINKWRAP-492: ----------------------------------------------- This is happening for me as well - but for my local packages as opposed to something external. Basically, for me, {{addPackages}} or {{addPackage}} ALWAYS results in a {{RuntimeException}} in WildFly 9. > addPackages method not ever succeeds > ------------------------------------ > > Key: SHRINKWRAP-492 > URL: https://issues.jboss.org/browse/SHRINKWRAP-492 > Project: ShrinkWrap > Issue Type: Bug > Components: impl-base > Environment: shrinkwrap-impl-base 1.2.2 > Reporter: Luca Stancapiano > > there are cases where the addPackages method doesn't succeed to load the packages also if they are in the current classloader. An example can be the com.h2database library. This library is registered as resource in the classloader with the name com.h2database and ambigously it contains the package org.h2. > If I try to include the library in my shrinkwrap java archive with the expression addPackages(true, "com") or with the expression addPackages(true, "org") , the h2 packages are not loaded because shrinkwrap need the name of the resource starting with the same name of the package. > So seems that shrinkwrap can load only something as a resource called com.h2database combined with the package com.h2 or a resource called org.h2database combined with the package org.h2. > I presume this ambiguous name should be managed in shrinkwrap -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-235) Maven resolver does not support global settings file

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-235?page=com.atlassian.jira.plu... ] Karel Piwko moved SHRINKWRAP-497 to SHRINKRES-235: -------------------------------------------------- Project: ShrinkWrap Resolvers (was: ShrinkWrap) Key: SHRINKRES-235 (was: SHRINKWRAP-497) Component/s: maven-plugin (was: ext-resolver) > Maven resolver does not support global settings file > ---------------------------------------------------- > > Key: SHRINKRES-235 > URL: https://issues.jboss.org/browse/SHRINKRES-235 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Components: maven-plugin > Reporter: Jeff MAURY > Labels: maven, resolver > > When using the Maven resolver together with the shrinkwrap-resolver-maven-plugin, the Maven session can be configured with the user settings file but not with the global settings file. > See ConfigureSettingsFromPluginTask -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-498) Support JAR file generation with embedded JARs, like the ones generated by spring-boot

by Ramon Rivas (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-498?page=com.atlassian.jira.pl... ] Ramon Rivas commented on SHRINKWRAP-498: ---------------------------------------- The issue is triggered by the class @org.arquillian.cube.impl.containerless.ContainerlessDockerDeployableContainer method createDockerFileFromTemplate(..), that exports the JAR using @org.jboss.shrinkwrap.api.exporter.ZipExporter. That ends up using an instance of @org.jboss.shrinkwrap.impl.base.exporter.zip.ZipExporterImpl that simply exports all entries with default values, which is using ZipEntry.DEFLATED method. I tried to change the code in class @org.jboss.shrinkwrap.impl.base.exporter.zip.ZipOnDemandInputStream to create ZIP entries with ZipEntry.STORED method, but for some reason the Java API doesn't support creating entries with STORED method without knowing the size of the file to store, which is not yet know in that part of the code. > Support JAR file generation with embedded JARs, like the ones generated by spring-boot > -------------------------------------------------------------------------------------- > > Key: SHRINKWRAP-498 > URL: https://issues.jboss.org/browse/SHRINKWRAP-498 > Project: ShrinkWrap > Issue Type: Feature Request > Affects Versions: 1.2.3 > Environment: ShrinkWrap 1.2.3 > Arquillian Core 1.1.10.Final > Arquillian Cube 1.0.0.Alpha7 > Spring Boot 1.3.0.RELEASE > Reporter: Ramon Rivas > Priority: Optional > > I'm trying to use Arquillian + Cube Docker + Cube Containerless to generate tests for an application that uses Spring Boot. The Spring Boot plugin ends up generating a JAR file that internally contains other JARs (the application dependencies). Those JARs are stored with no compression (as opposed to regular classes that are stored deflated). > To simplify my test and make it as compatible as possible to the final artifact, my deployment generation imports the same JAR file that spring boot plugin is generating. But when said JAR is exported internally by Arquillian Cube, all entries (including embedded libraries) are stored in the final JAR file as compressed. As a result, the JAR file cannot be executed using java -jar <my jar file> > The ideal solution is that the exporter should be aware of this limitation, and embedded JARs inside another JAR shouldn't be compressed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-498) Support JAR file generation with embedded JARs, like the ones generated by spring-boot

by Ramon Rivas (JIRA)

Ramon Rivas created SHRINKWRAP-498: -------------------------------------- Summary: Support JAR file generation with embedded JARs, like the ones generated by spring-boot Key: SHRINKWRAP-498 URL: https://issues.jboss.org/browse/SHRINKWRAP-498 Project: ShrinkWrap Issue Type: Feature Request Affects Versions: 1.2.3 Environment: ShrinkWrap 1.2.3 Arquillian Core 1.1.10.Final Arquillian Cube 1.0.0.Alpha7 Spring Boot 1.3.0.RELEASE Reporter: Ramon Rivas Priority: Optional I'm trying to use Arquillian + Cube Docker + Cube Containerless to generate tests for an application that uses Spring Boot. The Spring Boot plugin ends up generating a JAR file that internally contains other JARs (the application dependencies). Those JARs are stored with no compression (as opposed to regular classes that are stored deflated). To simplify my test and make it as compatible as possible to the final artifact, my deployment generation imports the same JAR file that spring boot plugin is generating. But when said JAR is exported internally by Arquillian Cube, all entries (including embedded libraries) are stored in the final JAR file as compressed. As a result, the JAR file cannot be executed using java -jar <my jar file> The ideal solution is that the exporter should be aware of this limitation, and embedded JARs inside another JAR shouldn't be compressed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-234) Declared dependency order is not the same as in Maven

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-234?page=com.atlassian.jira.plu... ] Karel Piwko updated SHRINKRES-234: ---------------------------------- Issue Type: Bug (was: Feature Request) > Declared dependency order is not the same as in Maven > ----------------------------------------------------- > > Key: SHRINKRES-234 > URL: https://issues.jboss.org/browse/SHRINKRES-234 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Affects Versions: 2.2.0 > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: 2.2.1 > > > It looks that SWR does not preserve order of dependencies as they are coming from Aether because of HashSet storage in MavenDependencySession. > https://github.com/shrinkwrap/resolver/blob/0da07b860d34ce048270b06200a56... > This might cause problems if constructing classpath manually from resolved dependencies. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-234) Declared dependency order is not the same as in Maven

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-234?page=com.atlassian.jira.plu... ] Karel Piwko resolved SHRINKRES-234. ----------------------------------- Resolution: Done Pushed upstream in https://github.com/shrinkwrap/resolver/commit/09fdd223155ca28081cda2ed1df.... Test has not been included but it has been verified locally. > Declared dependency order is not the same as in Maven > ----------------------------------------------------- > > Key: SHRINKRES-234 > URL: https://issues.jboss.org/browse/SHRINKRES-234 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Affects Versions: 2.2.0 > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: 2.2.1 > > > It looks that SWR does not preserve order of dependencies as they are coming from Aether because of HashSet storage in MavenDependencySession. > https://github.com/shrinkwrap/resolver/blob/0da07b860d34ce048270b06200a56... > This might cause problems if constructing classpath manually from resolved dependencies. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-234) Declared dependency order is not the same as in Maven

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-234?page=com.atlassian.jira.plu... ] Work on SHRINKRES-234 started by Karel Piwko. --------------------------------------------- > Declared dependency order is not the same as in Maven > ----------------------------------------------------- > > Key: SHRINKRES-234 > URL: https://issues.jboss.org/browse/SHRINKRES-234 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Affects Versions: 2.2.0 > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: 2.2.1 > > > It looks that SWR does not preserve order of dependencies as they are coming from Aether because of HashSet storage in MavenDependencySession. > https://github.com/shrinkwrap/resolver/blob/0da07b860d34ce048270b06200a56... > This might cause problems if constructing classpath manually from resolved dependencies. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-234) Declared dependency order is not the same as in Maven

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-234?page=com.atlassian.jira.plu... ] Karel Piwko reassigned SHRINKRES-234: ------------------------------------- Assignee: Karel Piwko > Declared dependency order is not the same as in Maven > ----------------------------------------------------- > > Key: SHRINKRES-234 > URL: https://issues.jboss.org/browse/SHRINKRES-234 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Affects Versions: 2.2.0 > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: 2.2.1 > > > It looks that SWR does not preserve order of dependencies as they are coming from Aether because of HashSet storage in MavenDependencySession. > https://github.com/shrinkwrap/resolver/blob/0da07b860d34ce048270b06200a56... > This might cause problems if constructing classpath manually from resolved dependencies. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-234) Declared dependency order is not the same as in Maven

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-234?page=com.atlassian.jira.plu... ] Karel Piwko updated SHRINKRES-234: ---------------------------------- Fix Version/s: 2.2.1 > Declared dependency order is not the same as in Maven > ----------------------------------------------------- > > Key: SHRINKRES-234 > URL: https://issues.jboss.org/browse/SHRINKRES-234 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Affects Versions: 2.2.0 > Reporter: Karel Piwko > Fix For: 2.2.1 > > > It looks that SWR does not preserve order of dependencies as they are coming from Aether because of HashSet storage in MavenDependencySession. > https://github.com/shrinkwrap/resolver/blob/0da07b860d34ce048270b06200a56... > This might cause problems if constructing classpath manually from resolved dependencies. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues December 2015