July 2014 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] (SHRINKRES-192) embedded gradle shrinkwrap-resolver - propagate project properties via API

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-192?page=com.atlassian.jira.plu... ] Michal Matloka commented on SHRINKRES-192: ------------------------------------------ Ok, I will test this, but it's good to hear that anybody uses SWR with gradle :) > embedded gradle shrinkwrap-resolver - propagate project properties via API > -------------------------------------------------------------------------- > > Key: SHRINKRES-192 > URL: https://issues.jboss.org/browse/SHRINKRES-192 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Environment: gradle 1.12, jdk 1.7_u45, fedora, org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-impl-gradle-embedded-archive:2.2.0-alpha-1 > Reporter: Peter Butkovic > Assignee: Michal Matloka > Labels: gradle > > I'd like to propagate project properties to embedded gradle build. > I tried following: > {code} > ShrinkWrap.create(EmbeddedGradleImporter.class) > .forThisProjectDirectory().forTasks("build").withArguments("-x", "test", "-Psomepropname=somepropvalue") > .importBuildOutput().as(WebArchive.class) > {code} > but the {{somepropname}} is not set in embedded build. > Using the gradle.properties is not an option for me, as {{somepropname}} value changes from build to build. > Workaround was to write temp properties file and read it in embedded build with silent failure (as suggested here: http://issues.gradle.org/browse/GRADLE-1419?focusedCommentId=16245&page=c...) but that sounds too much work to do for such a simple task. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-192) embedded gradle shrinkwrap-resolver - propagate project properties via API

by Peter Butkovic (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-192?page=com.atlassian.jira.plu... ] Peter Butkovic commented on SHRINKRES-192: ------------------------------------------ honestly I don't remember any more if I gave it a try. still it sounds like worth a try. > embedded gradle shrinkwrap-resolver - propagate project properties via API > -------------------------------------------------------------------------- > > Key: SHRINKRES-192 > URL: https://issues.jboss.org/browse/SHRINKRES-192 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Environment: gradle 1.12, jdk 1.7_u45, fedora, org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-impl-gradle-embedded-archive:2.2.0-alpha-1 > Reporter: Peter Butkovic > Assignee: Michal Matloka > Labels: gradle > > I'd like to propagate project properties to embedded gradle build. > I tried following: > {code} > ShrinkWrap.create(EmbeddedGradleImporter.class) > .forThisProjectDirectory().forTasks("build").withArguments("-x", "test", "-Psomepropname=somepropvalue") > .importBuildOutput().as(WebArchive.class) > {code} > but the {{somepropname}} is not set in embedded build. > Using the gradle.properties is not an option for me, as {{somepropname}} value changes from build to build. > Workaround was to write temp properties file and read it in embedded build with silent failure (as suggested here: http://issues.gradle.org/browse/GRADLE-1419?focusedCommentId=16245&page=c...) but that sounds too much work to do for such a simple task. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-192) embedded gradle shrinkwrap-resolver - propagate project properties via API

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-192?page=com.atlassian.jira.plu... ] Michal Matloka commented on SHRINKRES-192: ------------------------------------------ Hi, I will try to check why they are not available in embedded build. Have you tried also passing them via -D ? ( http://java.dzone.com/articles/specifying-gradle-build Passing System Properties from Command-Line with -D ) > embedded gradle shrinkwrap-resolver - propagate project properties via API > -------------------------------------------------------------------------- > > Key: SHRINKRES-192 > URL: https://issues.jboss.org/browse/SHRINKRES-192 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Environment: gradle 1.12, jdk 1.7_u45, fedora, org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-impl-gradle-embedded-archive:2.2.0-alpha-1 > Reporter: Peter Butkovic > Assignee: Michal Matloka > Labels: gradle > > I'd like to propagate project properties to embedded gradle build. > I tried following: > {code} > ShrinkWrap.create(EmbeddedGradleImporter.class) > .forThisProjectDirectory().forTasks("build").withArguments("-x", "test", "-Psomepropname=somepropvalue") > .importBuildOutput().as(WebArchive.class) > {code} > but the {{somepropname}} is not set in embedded build. > Using the gradle.properties is not an option for me, as {{somepropname}} value changes from build to build. > Workaround was to write temp properties file and read it in embedded build with silent failure (as suggested here: http://issues.gradle.org/browse/GRADLE-1419?focusedCommentId=16245&page=c...) but that sounds too much work to do for such a simple task. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-480) Fix order of entries in exported zip file

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-480?page=com.atlassian.jira.pl... ] Michal Matloka commented on SHRINKWRAP-480: ------------------------------------------- Old approach was removed due to some issues SHRINKWRAP-279, SHRINKWRAP-433 . So the real problem for you is that we obtain different orders of entries using these two methods. Old approach looks just like it was sorting entries by name. Because new code it's not against ZIP standard, may I ask you what problems bring this different order with usage of that 3rd party library?:) > Fix order of entries in exported zip file > ----------------------------------------- > > Key: SHRINKWRAP-480 > URL: https://issues.jboss.org/browse/SHRINKWRAP-480 > Project: ShrinkWrap > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: impl-base > Affects Versions: 1.2.2 > Reporter: Stefan Bunciak > Assignee: Michal Matloka > > ZipExporter from ShwinkWrap 1.0.1 created zip file with the following structure: > {code} > Archive: s-ramp-exporter.jar > Length Method Size Cmpr Date Time CRC-32 Name > -------- ------ ------- ---- ---------- ----- -------- ---- > 0 Defl:N 2 0% 03-31-2014 13:36 00000000 META-INF/ > 3847 Defl:N 898 77% 03-31-2014 13:36 b04e8666 META-INF/switchyard.xml > 0 Defl:N 2 0% 03-31-2014 13:36 00000000 META-INF/beans.xml > 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/ > 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/jboss/ > 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/jboss/arquillian/ > 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/jboss/arquillian/container/ > 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/jboss/arquillian/container/sramp/ > 1881 Defl:N 875 54% 03-31-2014 13:36 21ed2654 org/jboss/arquillian/container/sramp/DeploymentTest.class > -------- ------- --- ------- > 5728 1787 69% 9 files > {code} > Newer versions on ShrinkWrap gave me: > {code} > Archive: s-ramp-resource.jar > Length Method Size Cmpr Date Time CRC-32 Name > -------- ------ ------- ---- ---------- ----- -------- ---- > 3847 Defl:N 898 77% 03-30-2014 17:45 b04e8666 META-INF/switchyard.xml > 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/jboss/ > 0 Defl:N 2 0% 03-30-2014 17:45 00000000 META-INF/beans.xml > 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/jboss/arquillian/container/ > 1790 Defl:N 842 53% 03-30-2014 17:45 7a7ed211 org/jboss/arquillian/container/sramp/DeploymentTest.class > 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/jboss/arquillian/container/sramp/ > 0 Defl:N 2 0% 03-30-2014 17:45 00000000 META-INF/ > 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/jboss/arquillian/ > 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/ > -------- ------- --- ------- > 5637 1754 69% 9 files > {code} > Would it be possible to provide users with both exporting mechanisms (single & multi threaded)? By default use the multi-threaded approach. > I assume this behavior is result of https://issues.jboss.org/browse/SHRINKWRAP-434. It's not against ZIP standard, afaik, however due to such structure I had to revert to older version of ShrinkWrap (I need zip file for further processing by 3rd party library) -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-480) Fix order of entries in exported zip file

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-480?page=com.atlassian.jira.pl... ] Michal Matloka reassigned SHRINKWRAP-480: ----------------------------------------- Assignee: Michal Matloka > Fix order of entries in exported zip file > ----------------------------------------- > > Key: SHRINKWRAP-480 > URL: https://issues.jboss.org/browse/SHRINKWRAP-480 > Project: ShrinkWrap > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: impl-base > Affects Versions: 1.2.2 > Reporter: Stefan Bunciak > Assignee: Michal Matloka > > ZipExporter from ShwinkWrap 1.0.1 created zip file with the following structure: > {code} > Archive: s-ramp-exporter.jar > Length Method Size Cmpr Date Time CRC-32 Name > -------- ------ ------- ---- ---------- ----- -------- ---- > 0 Defl:N 2 0% 03-31-2014 13:36 00000000 META-INF/ > 3847 Defl:N 898 77% 03-31-2014 13:36 b04e8666 META-INF/switchyard.xml > 0 Defl:N 2 0% 03-31-2014 13:36 00000000 META-INF/beans.xml > 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/ > 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/jboss/ > 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/jboss/arquillian/ > 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/jboss/arquillian/container/ > 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/jboss/arquillian/container/sramp/ > 1881 Defl:N 875 54% 03-31-2014 13:36 21ed2654 org/jboss/arquillian/container/sramp/DeploymentTest.class > -------- ------- --- ------- > 5728 1787 69% 9 files > {code} > Newer versions on ShrinkWrap gave me: > {code} > Archive: s-ramp-resource.jar > Length Method Size Cmpr Date Time CRC-32 Name > -------- ------ ------- ---- ---------- ----- -------- ---- > 3847 Defl:N 898 77% 03-30-2014 17:45 b04e8666 META-INF/switchyard.xml > 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/jboss/ > 0 Defl:N 2 0% 03-30-2014 17:45 00000000 META-INF/beans.xml > 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/jboss/arquillian/container/ > 1790 Defl:N 842 53% 03-30-2014 17:45 7a7ed211 org/jboss/arquillian/container/sramp/DeploymentTest.class > 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/jboss/arquillian/container/sramp/ > 0 Defl:N 2 0% 03-30-2014 17:45 00000000 META-INF/ > 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/jboss/arquillian/ > 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/ > -------- ------- --- ------- > 5637 1754 69% 9 files > {code} > Would it be possible to provide users with both exporting mechanisms (single & multi threaded)? By default use the multi-threaded approach. > I assume this behavior is result of https://issues.jboss.org/browse/SHRINKWRAP-434. It's not against ZIP standard, afaik, however due to such structure I had to revert to older version of ShrinkWrap (I need zip file for further processing by 3rd party library) -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-481) Fix "mvn site" failure after "mvn clean install"

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-481?page=com.atlassian.jira.pl... ] Michal Matloka updated SHRINKWRAP-481: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/shrinkwrap/shrinkwrap/pull/88 https://java.net/jira/browse/PINEAPPLE-563 https://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound > Fix "mvn site" failure after "mvn clean install" > ------------------------------------------------ > > Key: SHRINKWRAP-481 > URL: https://issues.jboss.org/browse/SHRINKWRAP-481 > Project: ShrinkWrap > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 1.2.2 > Reporter: Andrew Rubinger > Assignee: Michal Matloka > > While we've always needed to execute "mvn install" before "mvn site", the site plugin used to work. This is now failing on the CloudBees builds and the JavaDocs can no longer be built. > > For instance: > https://shrinkwrap.ci.cloudbees.com/job/ShrinkWrap_upstream-master/84/ -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-481) Fix "mvn site" failure after "mvn clean install"

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-481?page=com.atlassian.jira.pl... ] Michal Matloka reassigned SHRINKWRAP-481: ----------------------------------------- Assignee: Michal Matloka (was: Karel Piwko) > Fix "mvn site" failure after "mvn clean install" > ------------------------------------------------ > > Key: SHRINKWRAP-481 > URL: https://issues.jboss.org/browse/SHRINKWRAP-481 > Project: ShrinkWrap > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 1.2.2 > Reporter: Andrew Rubinger > Assignee: Michal Matloka > > While we've always needed to execute "mvn install" before "mvn site", the site plugin used to work. This is now failing on the CloudBees builds and the JavaDocs can no longer be built. > > For instance: > https://shrinkwrap.ci.cloudbees.com/job/ShrinkWrap_upstream-master/84/ -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-192) embedded gradle shrinkwrap-resolver - propagate project properties via API

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-192?page=com.atlassian.jira.plu... ] Michal Matloka moved SHRINKWRAP-482 to SHRINKRES-192: ----------------------------------------------------- Project: ShrinkWrap Resolvers (was: ShrinkWrap) Key: SHRINKRES-192 (was: SHRINKWRAP-482) Component/s: (was: ext-resolver) > embedded gradle shrinkwrap-resolver - propagate project properties via API > -------------------------------------------------------------------------- > > Key: SHRINKRES-192 > URL: https://issues.jboss.org/browse/SHRINKRES-192 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Environment: gradle 1.12, jdk 1.7_u45, fedora, org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-impl-gradle-embedded-archive:2.2.0-alpha-1 > Reporter: Peter Butkovic > Assignee: Michal Matloka > Labels: gradle > > I'd like to propagate project properties to embedded gradle build. > I tried following: > {code} > ShrinkWrap.create(EmbeddedGradleImporter.class) > .forThisProjectDirectory().forTasks("build").withArguments("-x", "test", "-Psomepropname=somepropvalue") > .importBuildOutput().as(WebArchive.class) > {code} > but the {{somepropname}} is not set in embedded build. > Using the gradle.properties is not an option for me, as {{somepropname}} value changes from build to build. > Workaround was to write temp properties file and read it in embedded build with silent failure (as suggested here: http://issues.gradle.org/browse/GRADLE-1419?focusedCommentId=16245&page=c...) but that sounds too much work to do for such a simple task. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-482) embedded gradle shrinkwrap-resolver - propagate project properties via API

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-482?page=com.atlassian.jira.pl... ] Michal Matloka reassigned SHRINKWRAP-482: ----------------------------------------- Assignee: Michal Matloka > embedded gradle shrinkwrap-resolver - propagate project properties via API > -------------------------------------------------------------------------- > > Key: SHRINKWRAP-482 > URL: https://issues.jboss.org/browse/SHRINKWRAP-482 > Project: ShrinkWrap > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: ext-resolver > Environment: gradle 1.12, jdk 1.7_u45, fedora, org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-impl-gradle-embedded-archive:2.2.0-alpha-1 > Reporter: Peter Butkovic > Assignee: Michal Matloka > Labels: gradle > > I'd like to propagate project properties to embedded gradle build. > I tried following: > {code} > ShrinkWrap.create(EmbeddedGradleImporter.class) > .forThisProjectDirectory().forTasks("build").withArguments("-x", "test", "-Psomepropname=somepropvalue") > .importBuildOutput().as(WebArchive.class) > {code} > but the {{somepropname}} is not set in embedded build. > Using the gradle.properties is not an option for me, as {{somepropname}} value changes from build to build. > Workaround was to write temp properties file and read it in embedded build with silent failure (as suggested here: http://issues.gradle.org/browse/GRADLE-1419?focusedCommentId=16245&page=c...) but that sounds too much work to do for such a simple task. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-472) Shrinkwrap BOM seems to be unreleased in Maven Central

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-472?page=com.atlassian.jira.pl... ] Michal Matloka commented on SHRINKWRAP-472: ------------------------------------------- This seems to be already fixed? > Shrinkwrap BOM seems to be unreleased in Maven Central > ------------------------------------------------------ > > Key: SHRINKWRAP-472 > URL: https://issues.jboss.org/browse/SHRINKWRAP-472 > Project: ShrinkWrap > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 1.2.1 > Reporter: Stefan Miklosovic > Priority: Critical > > Hi, > I am wondering why is this happening, it seems ShrinkWrap BOM of version 1.2.1 is released here > https://repository.jboss.org/nexus/index.html#nexus-search;gav~org.jboss.... > https://github.com/shrinkwrap/shrinkwrap/blob/1.2.1/bom/pom.xml#L13 > But it is not here: > http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.jboss.shrinkwrap%2... > I was trying to use 1.2.1 of BOM and Maven just can not resolve it since it is not in Central. > It seems to me that there was some synchronization issue while these bits where uploaded to central. What is the next step? > Regards -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues July 2014