December 2012 - shrinkwrap-issues

[JBoss JIRA] (SHRINKDESC-108) Apply CheckStyle Rules and Bulk-Format the codebase

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-108?page=com.atlassian.jira.pl... ] Michal Matloka commented on SHRINKDESC-108: ------------------------------------------- Unfortunately I didn't have time this weekend to do this. If you don't mind I will solve this task around Wednesday. > Apply CheckStyle Rules and Bulk-Format the codebase > --------------------------------------------------- > > Key: SHRINKDESC-108 > URL: https://issues.jboss.org/browse/SHRINKDESC-108 > Project: ShrinkWrap Descriptors > Issue Type: Task > Reporter: Andrew Rubinger > Assignee: Michal Matloka > > For ease in contribution and limiting conflicts while merging, apply the ShrinkWrap Checkstyle configuration and bulk-format the codebase to match. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-436) Support recursive Class addition

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-436?page=com.atlassian.jira.pl... ] Michal Matloka updated SHRINKWRAP-436: -------------------------------------- Forum Reference: https://community.jboss.org/thread/215418 > Support recursive Class addition > -------------------------------- > > Key: SHRINKWRAP-436 > URL: https://issues.jboss.org/browse/SHRINKWRAP-436 > Project: ShrinkWrap > Issue Type: Feature Request > Components: api, impl-base > Reporter: Michal Matloka > Assignee: Michal Matloka > > I'd like propose to add e.g the following methods to the API: > // gets clazz and classed directly used by this clazz > addClass(boolean recursive, Class<?> clazz) > // gets clazz and recursivly classes in given depth > // addClass(boolean recursive, Class<?> clazz) runs addClass(boolean recursive, 1, Class<?> clazz) > addClass(boolean recursive, int depth, Class<?> clazz) > They would add to the archive, given clazz, and all other classes mentioned in clazz, e.g > For the following class strcture > {noformat} > public class DummyDependentA { > private DummyDependentB dummyDependentB; > } > public class DummyDependentB { > private DummyDependentC dummyDependentC ; > } > public class DummyDependentC { > } > {noformat} > operation .addClass(true, DummyDependentA .class) would result in adding both DummyDependentA and DummyDependentB to the archive (but not DummyDependentC ). In order to add also DummyDependentC user would have to use at least .addClass(true, 2, DummyDependentA .class). > It is possible to achieve, e.g. using ASM library - as described in answer of the following topic http://stackoverflow.com/questions/3734825/find-out-which-classes-of-a-gi... > I've locally prepared proof of concept, after some refactorings I will present the pull request. > It's worth to discuss what API methods would be the most useful. Recursion might get really big number of classes. Obligatory is filtering out "java.*" classes. Maybe it would be useful to apply additional package filtering for this, so that recursion would work only on current project classes. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-436) Support recursive Class addition

by SBS JIRA Integration (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-436?page=com.atlassian.jira.pl... ] SBS JIRA Integration updated SHRINKWRAP-436: -------------------------------------------- Forum Reference: https://community.jboss.org/message/782416#782416, https://community.jboss.org/thread/215418 (was: https://community.jboss.org/thread/215418) > Support recursive Class addition > -------------------------------- > > Key: SHRINKWRAP-436 > URL: https://issues.jboss.org/browse/SHRINKWRAP-436 > Project: ShrinkWrap > Issue Type: Feature Request > Components: api, impl-base > Reporter: Michal Matloka > Assignee: Michal Matloka > > I'd like propose to add e.g the following methods to the API: > // gets clazz and classed directly used by this clazz > addClass(boolean recursive, Class<?> clazz) > // gets clazz and recursivly classes in given depth > // addClass(boolean recursive, Class<?> clazz) runs addClass(boolean recursive, 1, Class<?> clazz) > addClass(boolean recursive, int depth, Class<?> clazz) > They would add to the archive, given clazz, and all other classes mentioned in clazz, e.g > For the following class strcture > {noformat} > public class DummyDependentA { > private DummyDependentB dummyDependentB; > } > public class DummyDependentB { > private DummyDependentC dummyDependentC ; > } > public class DummyDependentC { > } > {noformat} > operation .addClass(true, DummyDependentA .class) would result in adding both DummyDependentA and DummyDependentB to the archive (but not DummyDependentC ). In order to add also DummyDependentC user would have to use at least .addClass(true, 2, DummyDependentA .class). > It is possible to achieve, e.g. using ASM library - as described in answer of the following topic http://stackoverflow.com/questions/3734825/find-out-which-classes-of-a-gi... > I've locally prepared proof of concept, after some refactorings I will present the pull request. > It's worth to discuss what API methods would be the most useful. Recursion might get really big number of classes. Obligatory is filtering out "java.*" classes. Maybe it would be useful to apply additional package filtering for this, so that recursion would work only on current project classes. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-436) Support recursive Class addition

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-436?page=com.atlassian.jira.pl... ] Michal Matloka edited comment on SHRINKWRAP-436 at 12/9/12 3:42 PM: -------------------------------------------------------------------- Proof of concept: https://github.com/mmatloka/shrinkwrap/commit/39d5c3aa63a9bb85e6d7b687828... was (Author: mmatloka): Proof of concept with proposed API: https://github.com/mmatloka/shrinkwrap/commit/39d5c3aa63a9bb85e6d7b687828... > Support recursive Class addition > -------------------------------- > > Key: SHRINKWRAP-436 > URL: https://issues.jboss.org/browse/SHRINKWRAP-436 > Project: ShrinkWrap > Issue Type: Feature Request > Components: api, impl-base > Reporter: Michal Matloka > Assignee: Michal Matloka > > I'd like propose to add e.g the following methods to the API: > // gets clazz and classed directly used by this clazz > addClass(boolean recursive, Class<?> clazz) > // gets clazz and recursivly classes in given depth > // addClass(boolean recursive, Class<?> clazz) runs addClass(boolean recursive, 1, Class<?> clazz) > addClass(boolean recursive, int depth, Class<?> clazz) > They would add to the archive, given clazz, and all other classes mentioned in clazz, e.g > For the following class strcture > {noformat} > public class DummyDependentA { > private DummyDependentB dummyDependentB; > } > public class DummyDependentB { > private DummyDependentC dummyDependentC ; > } > public class DummyDependentC { > } > {noformat} > operation .addClass(true, DummyDependentA .class) would result in adding both DummyDependentA and DummyDependentB to the archive (but not DummyDependentC ). In order to add also DummyDependentC user would have to use at least .addClass(true, 2, DummyDependentA .class). > It is possible to achieve, e.g. using ASM library - as described in answer of the following topic http://stackoverflow.com/questions/3734825/find-out-which-classes-of-a-gi... > I've locally prepared proof of concept, after some refactorings I will present the pull request. > It's worth to discuss what API methods would be the most useful. Recursion might get really big number of classes. Obligatory is filtering out "java.*" classes. Maybe it would be useful to apply additional package filtering for this, so that recursion would work only on current project classes. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-18) MavenImporter on war files should support a configuration that supports "skipping the build" in the IDE (and preferably use it by default)

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-18?page=com.atlassian.jira.plug... ] Karel Piwko updated SHRINKRES-18: --------------------------------- Fix Version/s: 2.0.0-alpha-6 > MavenImporter on war files should support a configuration that supports "skipping the build" in the IDE (and preferably use it by default) > ------------------------------------------------------------------------------------------------------------------------------------------ > > Key: SHRINKRES-18 > URL: https://issues.jboss.org/browse/SHRINKRES-18 > Project: ShrinkWrap Resolvers > Issue Type: Enhancement > Affects Versions: 2.0.0-alpha-1 > Reporter: Geoffrey De Smet > Assignee: Karel Piwko > Fix For: 2.0.0-alpha-6 > > > Currently the MavenImporter on war files requires "mvn package" to be run every time (not only the first time), to update the exploded directory at "target/{finalName}". > This means if you change something in your code and want to (re)run a test, > and forget to run "mvn package" first, you're running the old code (and the results are not representative of the changed code). > Karel and Geoffrey discussed this at JUDCon London. > The following things can be probably presumed: > - The IDE compiles all classes from src/main/java to target/classes. > - The IDE copies all non-filtered resources from src/main/resources to target/classes. > - That target/classes is copied into the war at WEB-INF/classes. > - Most src/main/webapp dirs are copied unaltered into the root of the war. (*) > - "mvn compile" is run once after any "mvn clean": in other words, all src/main/filtered-resources are in target/classes > So MavenImporter doesn't have to require "mvn package" to build the exploded dir first (which it then zips, enriches and sends to arquillian). > Instead, it can construct the war zip directly from target/classes and src/main/webapp. > That is at least one less copy and more importantly, to run the test from the IDE without having to build first. > Note: all examples above used the explicit directory locations, but in reality the pom.xml's <build> section should be used to determinate the directory locations for a certain project. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-61) Reimplement MavenImporter

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-61?page=com.atlassian.jira.plug... ] Karel Piwko updated SHRINKRES-61: --------------------------------- Fix Version/s: 2.0.0-alpha-6 > Reimplement MavenImporter > ------------------------- > > Key: SHRINKRES-61 > URL: https://issues.jboss.org/browse/SHRINKRES-61 > Project: ShrinkWrap Resolvers > Issue Type: Task > Components: api-maven > Affects Versions: 2.0.0-alpha-1 > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: 2.0.0-alpha-6 > > > Current MavenImporter implementation have many usability concerns. > Spawn a discussion about MavenImporter use cases and reimplement it in order to be independent of previous Maven execution. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-18) MavenImporter on war files should support a configuration that supports "skipping the build" in the IDE (and preferably use it by default)

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-18?page=com.atlassian.jira.plug... ] Karel Piwko commented on SHRINKRES-18: -------------------------------------- This will be fixed by SHRINKRES-61. > MavenImporter on war files should support a configuration that supports "skipping the build" in the IDE (and preferably use it by default) > ------------------------------------------------------------------------------------------------------------------------------------------ > > Key: SHRINKRES-18 > URL: https://issues.jboss.org/browse/SHRINKRES-18 > Project: ShrinkWrap Resolvers > Issue Type: Enhancement > Affects Versions: 2.0.0-alpha-1 > Reporter: Geoffrey De Smet > Assignee: Karel Piwko > Fix For: 2.0.0-alpha-6 > > > Currently the MavenImporter on war files requires "mvn package" to be run every time (not only the first time), to update the exploded directory at "target/{finalName}". > This means if you change something in your code and want to (re)run a test, > and forget to run "mvn package" first, you're running the old code (and the results are not representative of the changed code). > Karel and Geoffrey discussed this at JUDCon London. > The following things can be probably presumed: > - The IDE compiles all classes from src/main/java to target/classes. > - The IDE copies all non-filtered resources from src/main/resources to target/classes. > - That target/classes is copied into the war at WEB-INF/classes. > - Most src/main/webapp dirs are copied unaltered into the root of the war. (*) > - "mvn compile" is run once after any "mvn clean": in other words, all src/main/filtered-resources are in target/classes > So MavenImporter doesn't have to require "mvn package" to build the exploded dir first (which it then zips, enriches and sends to arquillian). > Instead, it can construct the war zip directly from target/classes and src/main/webapp. > That is at least one less copy and more importantly, to run the test from the IDE without having to build first. > Note: all examples above used the explicit directory locations, but in reality the pom.xml's <build> section should be used to determinate the directory locations for a certain project. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-81) Poor encapsulation, passing around Aether (Artifact) objects when we should be using our own

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-81?page=com.atlassian.jira.plug... ] Karel Piwko updated SHRINKRES-81: --------------------------------- Fix Version/s: 2.0.0-alpha-6 Component/s: api-maven impl-maven > Poor encapsulation, passing around Aether (Artifact) objects when we should be using our own > -------------------------------------------------------------------------------------------- > > Key: SHRINKRES-81 > URL: https://issues.jboss.org/browse/SHRINKRES-81 > Project: ShrinkWrap Resolvers > Issue Type: Task > Components: api-maven, impl-maven > Reporter: Michal Matloka > Assignee: Michal Matloka > Fix For: 2.0.0-alpha-6 > > > TODO located in MavenStrategyBaseImpl > // TODO Poor encapsulation, passing around Aether (Artifact) objects when we should be using our own > // representation > and > MavenWorkingSession > // TODO We're not really encapsulating much here, as we expose out Aether and Maven classes. Refactor this class and > // usages to hide all implementation details of Maven and Aether *behind* this SPI facade > Some of this refactors has to be made for SHRINKRES-27 -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-81) Poor encapsulation, passing around Aether (Artifact) objects when we should be using our own

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-81?page=com.atlassian.jira.plug... ] Karel Piwko commented on SHRINKRES-81: -------------------------------------- REST of the encapsulation is done in SHRINKRES-61. > Poor encapsulation, passing around Aether (Artifact) objects when we should be using our own > -------------------------------------------------------------------------------------------- > > Key: SHRINKRES-81 > URL: https://issues.jboss.org/browse/SHRINKRES-81 > Project: ShrinkWrap Resolvers > Issue Type: Task > Reporter: Michal Matloka > Assignee: Michal Matloka > > TODO located in MavenStrategyBaseImpl > // TODO Poor encapsulation, passing around Aether (Artifact) objects when we should be using our own > // representation > and > MavenWorkingSession > // TODO We're not really encapsulating much here, as we expose out Aether and Maven classes. Refactor this class and > // usages to hide all implementation details of Maven and Aether *behind* this SPI facade > Some of this refactors has to be made for SHRINKRES-27 -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-107) Refactor MetadataUtil

by Andrew Rubinger (JIRA)

Andrew Rubinger created SHRINKDESC-107: ------------------------------------------ Summary: Refactor MetadataUtil Key: SHRINKDESC-107 URL: https://issues.jboss.org/browse/SHRINKDESC-107 Project: ShrinkWrap Descriptors Issue Type: Task Components: metadata-parser Reporter: Andrew Rubinger Instead of the static util approach, we should likely be taking these methods and making them part of the capabilities of the relevent entities (ie. Node, Parser, etc). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 5 months

3
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues December 2012