[ https://issues.jboss.org/browse/SHRINKWRAP-325?page=com.atlassian.jira.pl... ] Aslak Knutsen commented on SHRINKWRAP-325: ------------------------------------------ just as a note: this would add things like Arquillian, The Container itself / client libs, JavaEE Apis, ShrinkWrap and other 'random' things in test scope you might not want to deploy to the container runtime.. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-325?page=com.atlassian.jira.pl... ] Geoffrey De Smet edited comment on SHRINKWRAP-325 at 9/6/11 10:27 AM: ---------------------------------------------------------------------- JavaEE Api's will be scope=provided, so they shouldn't be added. Arquillian and Shrinkwrap will be added, which is normal because their classes are used in our test classes (@Arquillian, ShrinkWrap.create...) at test runtime. As for The container itself: The container itself should not be a scope=test dependency. With a managed/remote container this isn't the case. With embedded it is, but that smells like a design flaw not to separate those classpaths. Maybe an embedded container should be a maven plugin? Or maybe the embedded++ container is some day implementable and it can replace the current embedded container: it is an embedded container (so no zip to download), but starts in a separate process in it's own classpath. As for the other random things? If it's in the pom.xml, it maybe not be random but actually required :) was (Author: ge0ffrey): JavaEE Api's will be scope=provided, so they shouldn't be added. Arquillian and Shrinkwrap will be added, which is normal because their classes are used in our test classes (@Arquillian, ShrinkWrap.create...) at test runtime. As for The container itself: The container itself should not be a scope=test dependency. With a managed/remote container this isn't the case. With embedded it is, but that smells like a design flaw not to separate those classpaths. Maybe an embedded container should be a maven plugin? Or maybe the embedded++ container is some day implementable and it can replace the current embedded container: it is an embedded container (so no zip to download), but starts in a separate process in it's own classpath. As for the other random things? If it's in the pom.xml it maybe not random but actually required :) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-325?page=com.atlassian.jira.pl... ] Geoffrey De Smet commented on SHRINKWRAP-325: --------------------------------------------- Note: everything should be grabbed for the target dir (or local repository), never from the src dir. Consider for example: src/main/java goes to target/classes src/main/resources goes to target/classes src/main/jasperreports goes to target/generated-java goes to target/classes src/webapp/WEB-INF/web.xml could be an empty template that is filled and generated to target/${maven.final.name}/WEB-INF/web.xml -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-325?page=com.atlassian.jira.pl... ] Aslak Knutsen commented on SHRINKWRAP-325: ------------------------------------------ Arquillian has it's own way of packaging it self that it does runtime. It's not the same version / configuration that runs incontainer as you have on your client cp. Adding Arq as the Client v most likely fail -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-325?page=com.atlassian.jira.pl... ] Andrew Rubinger reassigned SHRINKWRAP-325: ------------------------------------------ Assignee: Karel Piwko Karel, please add your opinions on this. At first glance, looks like the feature request is asking for SW to do some sketchy assumptions which could lead to undesired behaviour. Perhaps there's a cleaner way you've got in mind, or we can discuss further in the forums. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-325?page=com.atlassian.jira.pl... ] Karel Piwko commented on SHRINKWRAP-325: ---------------------------------------- If I got you correctly, we could use following skeleton without recopying all the Maven plugins or executing the Maven life cycle twice: 0/ Add <profile> support to ShrinkWrap Resolver 1/ Specify multiple profiles in pom.xml, strictly push all test dependencies into a profile 2/ Determine default target/XYZ locations by artifact type (jar, war, ear, rar) 3/ Pack all target dirs into test archive + !filter required here! 4/ Pack all non-profile or non-profile+specified-profiles dependencies (user specifies profiles, scopes in java-code) into library directory of the archive 5/ Return JavaArchive, WebArchive, etc. and pray :) This might help to achive the goal, still it will suffer from 2/ (IDE fragile) as my hack proposed before. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-325?page=com.atlassian.jira.pl... ] Geoffrey De Smet commented on SHRINKWRAP-325: --------------------------------------------- @Karel The "../example/target/example.war" trick doesn't put test helper classes, test abstract superclasses and test dependencies (mockito) on the classpath. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-325?page=com.atlassian.jira.pl... ] Geoffrey De Smet commented on SHRINKWRAP-325: --------------------------------------------- After some discussion with Karel, this is a first draft of the API: Basic usage: {code} ShrinkWrap.create(MavenImporter.class) .importPomFile("pom.xml") .as(WebArchive.class) {code} Advanced usage: profiles {code} ShrinkWrap.create(MavenImporter.class) .importPomFile("pom.xml", "profile1", "profile2") // vararg of profile id's can be added .as(WebArchive.class) {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-325?page=com.atlassian.jira.pl... ] Geoffrey De Smet edited comment on SHRINKWRAP-325 at 9/8/11 4:22 AM: --------------------------------------------------------------------- Following "configuration by exception": By default, it includes all compile, runtime and test dependencies (not scope provided). Note that reusing the exploded war file will already contain compile and runtime dependencies. Yet, you can override this: {code} importPomFile("pom.xml").filterDependencies(new ScopeFilter("compile")).as(WebArchive.class) {code} was (Author: ge0ffrey): Following "configuration by exception": By default, it includes all compile, runtime and test dependencies (not provided). Note that reusing the exploded war file will already contain compile and runtime dependencies. Yet, you can override this: {code} importPomFile("pom.xml").filterDependencies(new ScopeFilter("compile")).as(WebArchive.class) {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-325?page=com.atlassian.jira.pl... ] Geoffrey De Smet edited comment on SHRINKWRAP-325 at 9/8/11 5:03 AM: --------------------------------------------------------------------- Following "configuration by exception": By default, it might or might include the entire test classpath, so it would includes all compile, runtime and test dependencies (not scope provided). Note that reusing the exploded war file will already contain compile and runtime dependencies. ge0ffrey believes it should include the entire test classpath by default, from the pov that a "NoClassFoundException MyTestHelper (or Mockito)" is hard to trace to includeTestDependencies() kwipko does not (and it's his call :)), from the pov of client-side tests don't need it Yet, you can override it of course. Originally we thought, but that won't work due to the jars already being in the WEB-INF/lib dir: {code} includeTestDepedencies() {code} so it's probably something like this now: {code} {code} With sw filtering SHRINKWRAP-326 (a feature for a later version) you can exclude sources or test sources files too. was (Author: ge0ffrey): Following "configuration by exception": By default, it includes the entire test classpath, so it includes all compile, runtime and test dependencies (not scope provided). Note that reusing the exploded war file will already contain compile and runtime dependencies. Yet, you can override this: {code} importPomFile("pom.xml").filterDependencies(new ScopeFilter("compile")).as(WebArchive.class) {code} With sw filtering (a feature for a later version) you can exclude sources or test sources files too. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-325?page=com.atlassian.jira.pl... ] Geoffrey De Smet edited comment on SHRINKWRAP-325 at 9/8/11 5:05 AM: --------------------------------------------------------------------- Following "configuration by exception": By default, it might or might include the entire test classpath, so it would includes all compile, runtime and test dependencies (not scope provided). Note that reusing the exploded war file will already contain compile and runtime dependencies. ge0ffrey believes it should include the entire test classpath by default, from the pov that a "NoClassFoundException MyTestHelper (or Mockito)" is hard to trace to includeTestDependencies() kwipko does not (and it's his call :)), from the pov of client-side tests don't need it Yet, you can override it of course in both implementations: so either way works. Originally we thought, but that won't work due to the jars already being in the WEB-INF/lib dir: {code} filterDependencies() {code} so it's probably something like this now: {code} includeTestDepedencies( {code} With sw filtering SHRINKWRAP-326 (a feature for a later version) you can exclude sources or test sources files too. was (Author: ge0ffrey): Following "configuration by exception": By default, it might or might include the entire test classpath, so it would includes all compile, runtime and test dependencies (not scope provided). Note that reusing the exploded war file will already contain compile and runtime dependencies. ge0ffrey believes it should include the entire test classpath by default, from the pov that a "NoClassFoundException MyTestHelper (or Mockito)" is hard to trace to includeTestDependencies() kwipko does not (and it's his call :)), from the pov of client-side tests don't need it Yet, you can override it of course. Originally we thought, but that won't work due to the jars already being in the WEB-INF/lib dir: {code} filterDependencies() {code} so it's probably something like this now: {code} includeTestDepedencies( {code} With sw filtering SHRINKWRAP-326 (a feature for a later version) you can exclude sources or test sources files too. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-325?page=com.atlassian.jira.pl... ] Marek Schmidt commented on SHRINKWRAP-325: ------------------------------------------ I would say that "importPomFile" is misleading name, as it does too many things and it is not clear what. Users would especially be confused by the fact that selecting a different profile will have no effect on the actual imported build output. I would suggest something like `loadEffectivePom("pom.xml", "profile1", "profile2")' (or whatever it would be called) which would only load the effective pom and don't import anything. then there should be several methods, such as importBuildOutput() which would import target/guvnor-webapp-5.3.0-SNAPSHOT.war and importTestDependencies(filter) which would do what Geoffrey wants and perhaps other methods... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-325?page=com.atlassian.jira.pl... ] Geoffrey De Smet commented on SHRINKWRAP-325: --------------------------------------------- @Marek: I am ok with adding finer-grained methods, so people can control to "only import the build output", but the 1 course-grained facade method should still be there. Most users, just want it "to just work", without having to fine tune all knobs and buttons. I 've wasted much time trial and erroring on all those knobs and buttons. And in 80% of the cases, "to just work" means deploying the maven generated war with the test classpath added. Yet, Marak's extra methods are useful for those 20% use cases where you need to do sometimes special. General idea: configuration by exception. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-325?page=com.atlassian.jira.pl... ] Geoffrey De Smet commented on SHRINKWRAP-325: --------------------------------------------- @kpiwko Looks good. When it's merged to blessed master, I 'll build the snapshot locally and try it out. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-325?page=com.atlassian.jira.pl... ] Karel Piwko updated SHRINKWRAP-325: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/shrinkwrap/resolver/pull/7 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira