[00:00:56] <aslak> jose_freitas, ok, got servlet protocol working with as7 now..
[00:01:08] <jose_freitas> aslak: yay! :)
[00:01:11] <aslak> jose_freitas, just needs to cordinate arq-core + arq-osgi + as7 releases.. :)
[00:01:19] <jose_freitas> good news!
[00:03:29] <jose_freitas> In my case didn't have much progress. at least I know that the weld filter is not the problem
[00:04:09] <jose_freitas> but I don't have idea why jsffacescontext is not injected on the session
[00:04:49] *** kevinpollet has quit IRC
[00:09:12] <jose_freitas> and I didnt find a specific place where JSFUnitFacesContext.SESSION_KEY is setted on the session, And as a last resource I search the entire workspace for "JSFUnitFacesContext.SESSION_KEY"]
[00:09:17] <jose_freitas> and didn't find
[00:09:19] *** samaxes has joined #jbosstesting
[00:09:23] <jose_freitas> find a get() and a remove()
[00:09:26] <jose_freitas> but not a set()
[00:21:05] <jose_freitas> have to go, bye
[00:21:45] *** jose_freitas has quit IRC
[01:09:41] *** lightguard_jp is now known as lightguard_jp_aw
[01:13:16] *** oskutka has quit IRC
[01:31:26] *** rruss has quit IRC
[01:40:16] *** alesj has quit IRC
[01:44:22] *** aslak has quit IRC
[01:57:16] *** bleathem has quit IRC
[02:16:03] *** bleathem has joined #jbosstesting
[02:55:40] *** bleathem has quit IRC
[02:59:16] *** ianbrandt has quit IRC
[03:29:54] *** dblevins has quit IRC
[03:49:11] *** dblevins has joined #jbosstesting
[05:49:23] *** samaxes has quit IRC
[05:52:40] *** dblevins has quit IRC
[06:31:00] *** bleathem has joined #jbosstesting
[06:59:01] *** lightguard_jp_aw is now known as lightguard_jp
[07:01:29] *** dblevins has joined #jbosstesting
[07:02:38] *** oskutka has joined #jbosstesting
[08:02:50] *** lightguard_jp has quit IRC
[08:12:36] *** lightguard_jp has joined #jbosstesting
[08:15:23] *** oskutka has quit IRC
[08:19:37] *** galderz has joined #jbosstesting
[08:29:27] *** galderz has quit IRC
[08:29:55] *** galderz has joined #jbosstesting
[08:37:02] *** ge0ffrey has joined #jbosstesting
[08:59:01] *** kpiwko has joined #jbosstesting
[09:13:57] *** oskutka has joined #jbosstesting
[09:28:16] *** Jaikiran has joined #jbosstesting
[09:30:07] *** milestone has joined #jbosstesting
[09:34:57] *** pil-zZzzZzzz is now known as pilhuhn
[09:38:42] *** jharting has joined #jbosstesting
[09:39:34] *** maschmid has joined #jbosstesting
[09:41:01] *** jhuska has joined #jbosstesting
[09:42:48] *** lfryc has joined #jbosstesting
[09:53:23] *** aslak has joined #jbosstesting
[10:17:36] *** aslak has quit IRC
[10:24:25] *** jeand_ has joined #jbosstesting
[10:33:14] *** alesj has joined #jbosstesting
[10:34:58] <ge0ffrey> hi guys
[10:35:19] <ge0ffrey> how do I use shrinkwrap without having to list all my classes specifically?
[10:41:52] *** milestone has quit IRC
[10:51:16] *** alesj has quit IRC
[11:00:13] *** milestone has joined #jbosstesting
[11:01:44] *** ALR has joined #jbosstesting
[11:11:47] *** aslak has joined #jbosstesting
[11:15:22] *** milestone has quit IRC
[11:23:16] <nickarls> I think you can add a package structure recurisievely
[11:26:13] <ge0ffrey> nickarls: I can't find anything about that in the documentation
[11:27:13] <ge0ffrey> I 've worked with spring-testing before. Tbh, that was a lot easier: just give it the applicationContext.xml (= an aggreation of all beans.xml) and it worked. No need to say which classes and with meta files it uses
[11:27:35] <ge0ffrey> nickarls: do I also have to configure each of the libs I use?
[11:27:55] <ge0ffrey> (note that arquillian can do more of course, like in container testing)
[11:29:37] *** milestone has joined #jbosstesting
[11:33:37] *** Jaikiran has quit IRC
[11:37:10] *** milestone has quit IRC
[11:38:29] <ge0ffrey> aslak: I am trying to migrate JBoss drools Guvnor from seam 2 to seam 3. (It's not going that well, so excuse my sarcasm :) A critical part is moving the tests from a seam 2 container faking hack to arquillian
[11:39:00] <ge0ffrey> The problem is, we have a lot of tests, that each use a lot of classes from different packages that in turn use any of our 40 dependencies
[11:39:33] <nickarls> wonder if there's a api for reverse-engineering a deployment archive...
[11:39:50] <ge0ffrey> at this point we only care about getting them to run in 1 JVM (in/out container, tomcat/jetty/jboss 5.1/6/7, ... we don't care, as long as they run once :)
[11:40:25] <ge0ffrey> nickarls: reverse-enginering?
[11:46:02] <aslak> ge0ffrey, what type of tests are they? htmlunit servlet requests or ?
[11:46:41] <ge0ffrey> aslak: junit integration tests
[11:46:59] <ge0ffrey> so server side tests
[11:47:07] <ge0ffrey> with CDI
[11:47:48] <aslak> ge0ffrey, can you point me to a example test..
[11:47:50] <ge0ffrey> so @Inject myService; test() { mySErvice != null ; myService.findAllAssetsInDataRepository().size() == 5; }
[11:47:57] <aslak> aa ok
[11:48:45] <ge0ffrey> aslak: https://github.com/ge0ffrey/guvnor/blob/master/guvnor-webapp/src/test/java/org/drools/guvnor/server/GuvnorTestBase.java
[11:49:08] <ge0ffrey> and here's a real test: https://github.com/ge0ffrey/guvnor/blob/master/guvnor-webapp/src/test/java/org/drools/guvnor/server/RepositoryCategoryOperationsTest.java
[11:49:22] <ge0ffrey> hmm, nevermand that last link
[11:49:41] *** milestone has joined #jbosstesting
[11:49:46] <ge0ffrey> this is the correct real test: https://github.com/ge0ffrey/guvnor/blob/master/guvnor-webapp/src/test/java/org/drools/guvnor/server/RepositoryCategoryServiceTest.java
[11:50:20] <ge0ffrey> aslak: first I trying to set up a simple dummy test with an @Inject in there to prove that arquillian with cdi works
[11:51:12] <ge0ffrey> but I am trial-and-erroring on finding the correct maven dependencies and @Deployment method implementation.
[11:51:57] <ge0ffrey> so my first question would be, what maven dependencies would you recommend? Just test CDI as simple as possible
[12:00:26] <aslak> org.jboss.arquillian.junit:arquillian-junit-container:1.0.0.CR2 + org.jboss.arquillian.container:arquillian-weld-se-embedded-1.1:1.0.0.CR2
[12:00:45] <aslak> + https://docs.jboss.org/author/display/ARQ/Weld+SE+1.1+-+Embedded
[12:00:58] <aslak> brb, food
[12:01:18] <ge0ffrey> tnx :)
[12:15:41] *** milestone has quit IRC
[12:16:30] *** Jaikiran has joined #jbosstesting
[12:18:56] *** lightguard_jp has quit IRC
[12:20:07] *** galderz has quit IRC
[12:20:53] *** galderz has joined #jbosstesting
[12:28:44] *** milestone has joined #jbosstesting
[12:45:16] *** alesj has joined #jbosstesting
[13:12:53] *** milestone has quit IRC
[13:23:33] *** jeand_ has quit IRC
[13:28:21] *** jose_freitas has joined #jbosstesting
[13:28:38] <jose_freitas> good morning
[13:32:11] *** milestone has joined #jbosstesting
[13:35:35] *** bleathem has quit IRC
[13:36:09] *** jeand_ has joined #jbosstesting
[13:37:04] <ge0ffrey> aslak: I got a lot further now, but now I am running into the wall of having to add class by class (with no end in sight): https://gist.github.com/1139434
[13:38:08] *** galderz has quit IRC
[13:38:49] <jose_freitas> ge0ffrey: you can add by package
[13:39:16] <jose_freitas> addPackage(Xyz.class.getPackage())
[13:39:26] <ge0ffrey> jose I got many packages :)
[13:39:30] <jose_freitas> you can add a jar
[13:39:36] <jose_freitas> with addAsLibraries
[13:39:52] <jose_freitas> and you can even resolve jars with maven
[13:39:52] <ge0ffrey> jose_freitas: we change our dependencies frequently in maven
[13:39:55] <jose_freitas> with maven resolver
[13:40:00] <ge0ffrey> jose_freitas: ah, that sounds intresting :)
[13:40:12] <ge0ffrey> jose_freitas: any docs I can read about that maven resolver?
[13:40:33] <jose_freitas> let me see
[13:40:37] <ge0ffrey> tnx
[13:40:54] <jose_freitas> kpiwko might have the link directly.
[13:41:07] <jose_freitas> but let me search for it a little bit
[13:41:41] <kpiwko> jose_freitas: ge0ffrey: unfortunately, the doc is very sparse there
[13:42:11] <ge0ffrey> kpiwko: is it used in the showcase by any chance?
[13:42:20] <kpiwko> ge0ffrey: the best information can be found in test classes and some examples
[13:42:26] <ge0ffrey> is it ready enough to use, with version 1.0.0.CR2?
[13:42:36] <kpiwko> ge0ffrey: you mean arquillian-showcase?
[13:42:44] <ge0ffrey> yes, I 've cloned that locally
[13:42:50] <aslak> ge0ffrey, see gist comment
[13:42:58] <ge0ffrey> aslak: tnx
[13:43:02] <kpiwko> ge0ffrey: afaik it is in multinode example at least
[13:43:41] <kpiwko> aslak: I really have to do a blog about SWR
[13:43:46] <ge0ffrey> aslak: that looks wonderfull! that should be on page 1 of the manual IMO ;)
[13:43:58] <jose_freitas> hehehe
[13:44:10] <ge0ffrey> (of course I am overreacting, but just trying to give some feedback)
[13:44:32] <kpiwko> aslak: where can I find that awesome gist?
[13:44:34] <ge0ffrey> the reasoning being that it "just works"
[13:44:43] <aslak> kpiwko, https://gist.github.com/1139434#comments
[13:44:58] <aslak> ge0ffrey, not sure if it works 100%, but something in those lines should give you what you want
[13:45:20] <aslak> ge0ffrey, it won't run on the weld-se-container tho, but should work on jetty, tomcat, jboss,  etc
[13:45:36] <ge0ffrey> aslak: just the fact that it's possible to do something like that, gives me a lot more confidence in arquillian
[13:45:49] <aslak> :)
[13:45:58] <ge0ffrey> just need to figure out which maven artifact has MavenDependencyResolver.class
[13:46:20] <aslak> org.jboss.shrinkwrap:shrinkwrap-resolver-impl-maven
[13:46:27] <ge0ffrey> tnx, I 'll run with tomcat 6 (https://docs.jboss.org/author/display/ARQ/Tomcat+6.0+-+Embedded)
[13:46:36] <kpiwko> aslak: ge0ffrey, be careful, this call will try to package your testing container inside of the archive as well
[13:47:31] <jose_freitas> I think that one best practice is to have a testspecificpom, right kpiwko?
[13:48:03] <ge0ffrey> kpiwko: tnx for the hint, I 'll deal with that problem when I get there
[13:48:38] <kpiwko> jose_freitas: my original idea was to use a filter or to play with scopes
[13:49:57] <jose_freitas> hmm
[13:51:06] <aslak> ge0ffrey, yea, you'll need some scope / artifact filtering on that clal
[13:51:08] <aslak> call
[13:52:23] <kpiwko> jose_freitas: you can use exclusions as well but this will be nasty for some of the containers
[13:53:29] <kpiwko> so probably the best way now is to use loadMetadataFromPom instead and specify artifacts by hand
[13:53:43] <ALR> kpiwko: http://lists.jboss.org/pipermail/jboss-as7-dev/2011-August/003452.html
[13:53:46] <ALR> Per yesterday.
[13:53:56] <ALR> Would love you to weigh in if you have opinions on the matter.
[13:54:23] <ALR> Critiques on my points, my POC, or on the existing AS7 integration testsuite.  Your views are important here.
[13:54:28] *** alesj has quit IRC
[13:54:30] *** alesj1 has joined #jbosstesting
[13:54:46] *** alesj1 is now known as alesj
[13:54:52] <ge0ffrey> aslak: only runtime scope I presume?
[13:56:07] <aslak> ge0ffrey, runtime or compile i gues
[13:57:52] <kpiwko> ge0ffrey: I think it will use all the scopes
[13:59:56] <ge0ffrey> this can be done: .includeDependenciesFromPom("pom.xml").scope("runtime")....
[14:00:06] <ge0ffrey> not sure if it works yet
[14:01:42] <ge0ffrey> I also have filtered-webapp resources etc, but since they go to the same target dir, I doubt that will cause a problem
[14:02:15] <kpiwko> ge0ffrey: not, it won't work
[14:02:24] <kpiwko> ge0ffrey: here's the way how you can filter
[14:02:28] <kpiwko> ge0ffrey: https://github.com/kpiwko/resolver/blob/master/impl-maven/src/test/java/org/jboss/shrinkwrap/resolver/impl/maven/MavenResolutionFilterUnitTestCase.java#L478
[14:04:02] <ge0ffrey> kpiwko: tnx
[14:11:22] <kpiwko> ALR: from discussion above, .includeDependenciesFromPom("pom.xml").scope("runtime") ... I remember that fluent API which used to be in pre-1.0 version (read before split to api and impl) didn't allowed such call...I'll file a jira and do the update...update might cause incompatibility (in sense that code which does not make sense won't be compilable) but will have no impact on functionality, is that ok?
[14:11:52] <ALR> kpiwko: Compatibility with what?
[14:11:55] <ALR> Previous releases?
[14:11:58] <kpiwko> yep
[14:12:14] <ALR> As far as I'm concerned, we never said the Maven Resolver stuff was locked.
[14:12:19] <kpiwko> :)
[14:12:23] <ALR> But ARQ is using it I believe.
[14:12:35] <ALR> So we must coordinate that we fix this properly and lock it before ARQ goes final.
[14:12:47] <ALR> And ensure we issue a ticket to ARQ so that it's blocking on us doing so.
[14:13:12] <kpiwko> I'm pretty sure there is no such stuff in arquillian, but this jira will be filed by me as well
[14:13:13] <ALR> aslak has a habit of pressuring me to lock APIs. :)
[14:13:26] <kpiwko> aslak: any timeframe for ARQ final?
[14:13:32] <ALR> By relying on stuff I try to hide away :)
[14:14:00] <ALR> (Which ends up being a good thing, otherwise I'd never lock anything.  The SD SPI for instance)
[14:22:58] <aslak> ALR, no, arq is not a user
[14:23:11] <aslak> ALR, besides some examples/tests
[14:23:33] <aslak> ALR, no longer exposed in the normal dep chain either
[14:26:10] <ALR> Coool
[14:26:12] <ALR> Even better
[14:37:56] *** alesj has quit IRC
[14:38:13] *** alesj has joined #jbosstesting
[14:40:19] *** rruss has joined #jbosstesting
[14:44:08] *** bleathem has joined #jbosstesting
[14:47:34] <ge0ffrey> I am constantly running into a NoSuchMethodError: org.apache.catalina.startup.Embedded.createConnector
[14:48:07] <ge0ffrey> the problem is it returns Connector of the package org.apache.catalina.connector.Connector instead of org.apache.catalina.Connector
[14:48:23] <ge0ffrey> actually the other way around
[14:48:25] <aslak> ge0ffrey, which v?
[14:48:50] <ge0ffrey> latest release, so arquillian-tomcat-embedded-6 = 1.0.0.CR1
[14:48:57] <ge0ffrey> catalina = 6.0.29
[14:49:06] <aslak> hmm
[14:49:25] <ge0ffrey> I 've checked that the arq-t-emb has the same catalina verison dep
[14:49:50] <aslak> yea, that's the one we have been testing with
[14:49:51] <ge0ffrey> according to the docs I need to specify my cataline dependency too, so I did, but if if I don't, it doesn't make a diff
[14:50:01] <aslak> updated to 6.0.32 yesterday but
[14:50:35] <aslak> ge0ffrey, possible some tomcat libs being pulled in from else where ?
[14:50:43] <ge0ffrey> I 'll check with mvn dependency:tree
[14:51:40] <ge0ffrey> aslak: ah... I think I got a good idea
[14:51:42] <ge0ffrey> I am using gwt
[14:52:10] <ge0ffrey> and gwt-dev - the worst behaving artifact ever - is in my classpath. that has catalina stuff
[14:52:17] <ge0ffrey> (yet uses jetty
[14:52:35] <aslak> :)
[14:53:37] <ge0ffrey> I 'll think I 'll go for creating a seperate module with the tests
[14:56:13] *** galderz has joined #jbosstesting
[15:02:59] <jose_freitas> aslak: thanks for the help yesterday
[15:03:25] <jose_freitas> I found out that my tests are not using JSFUnitFacesContext but normal FacesContextImpl
[15:08:19] <aslak> jose_freitas, right..  can you check in the JSFUnitFacadesFacotry or similar, where it is suppose to create the wrapper
[15:08:31] <aslak> i had similar issues on jboss before, where it some times 'looses' the cookies
[15:08:59] <aslak> the jsfunit request will set a cookie so the server side can only wrap if this is a jsfunit request..
[15:09:29] <aslak> i don't remember the details, but somehow something was leaking/ not being cleared properly between tomcat requests in as
[15:09:44] <jose_freitas> hmmm
[15:10:01] <jose_freitas> let me check that
[15:11:20] <kpiwko> ALR: ping
[15:11:22] <jose_freitas> I found the problem
[15:11:25] <jose_freitas> I think
[15:11:49] <ALR> kpiwko: Pong
[15:11:51] <kpiwko> ALR: no shrinkwrap here? https://docs.jboss.org/author/dashboard.action
[15:12:08] <ALR> kpiwko: Well, no.
[15:12:18] <ALR> I've held off on real docs until we have CR1
[15:12:34] <ALR> But it's really getting to be time to do CR1.
[15:12:40] <ALR> We're not getting many bug issues.
[15:12:43] <ALR> And we took out Resolvers.
[15:12:46] <ALR> Etc
[15:13:01] <kpiwko> ALR: any chance you could create a skeleton there and I'll add doc for extensions - resolver?
[15:13:03] <jose_freitas> aslak: somehow, jsfunit extension on my project is packaging the wrong faces-config
[15:13:08] <ALR> I think if I comb through JIRA for blockers, and also move out maybe VFS3 and some other extensions, we'd be set
[15:13:23] <jose_freitas> aslak: it's grabbing another faces-config on my classpath
[15:13:27] <ALR> kpiwko: Recommend not doc-ing that until the Resolver API is stable.
[15:13:29] <kpiwko> ALR: I'm leaving for like two weeks and SWR related question are starting to appear more and more often
[15:13:31] <ALR> Else it'll go stale.
[15:13:35] <ALR> Hmm.
[15:13:43] <ALR> kpiwko: How are the SWR JavaDocs?
[15:13:54] <kpiwko> ALR: so I can go blog or doc way
[15:14:02] <ALR> Because IMO that's most useful now.
[15:14:10] <kpiwko> ALR: javadoc should be pretty fine
[15:14:10] <jose_freitas> aslak: wdyt on putting faces config on a folder like org/jboss/arquillian.../
[15:14:15] <ALR> We already have issues to refactor/rename a lot of SWR
[15:14:17] <aslak> jose_freitas, hmm.. isn't that packaged with a prefix alla jsfunit/faces-config ?
[15:14:21] <ALR> And I don't wanna have stale docs :)
[15:14:51] <aslak> jbossbot, but yea, even that might be to generic of a name t onot cause clashes
[15:14:55] <aslak> jose_freitas, ^
[15:14:56] <aslak> :)
[15:15:03] <kpiwko> ALR: yep, all docs are stale sooner or later until there's a doc team behind :)
[15:15:09] <aslak> jose_freitas, sure, org/jboss/arquillian/jsfunit/internal or something
[15:15:17] <ALR> Untrue!
[15:15:27] <kpiwko> ALR: give me one example
[15:15:30] <ALR> With back-compat APIs the docs can't get incorrect.
[15:15:39] <ALR> They can be outdated, but not wrong.
[15:15:42] <kpiwko> :D
[15:15:53] <ALR> And now you're in Alpha-level.
[15:16:12] <kpiwko> brb
[15:16:22] <ALR> Anyway, logging in
[15:16:26] <ALR> To make the SW space
[15:17:27] <ALR> OK, Requesting a Space from eng-ops
[15:34:08] *** milestone has quit IRC
[15:39:37] <jose_freitas> aslak:I'm afraid that we might need to replicate jsfunit faces config.
[15:39:40] <jose_freitas> return org.jboss.jsfunit.context.JSFUnitFacesContext.class.getResource("/META-INF/faces-config.xml");
[15:39:59] <jose_freitas> alter the path of it would break a lot of things
[15:40:18] <jose_freitas> do you have another idea besides duplicating the config file?
[15:40:31] <jose_freitas> this could be hellish to maintain
[15:41:28] <jose_freitas> I think that a + is that this config won't change very often
[15:41:39] <jose_freitas> but this could be a fallacy
[15:42:18] <aslak> where is that code ?
[15:42:31] <jose_freitas> JSFUnitArchiveAppender
[15:42:48] <aslak> that is the jsfunit faces config
[15:42:49] <jose_freitas> .addAsManifestResource(this.jsfunitFacesConfigXml(), "faces-config.xml")
[15:43:00] <jose_freitas> yes
[15:43:59] <jose_freitas> yes, we need to package the jsfunit faces config, but when accessing /META-INF/faces-config as a resource, it's grabbing a different faces-config
[15:44:02] <aslak> i'm not following, why is there a problem to update the getResource location in JSFUnitArchiveAppender and move the faces-config fil e?
[15:45:12] <jose_freitas> because we'd have to move the file from META-INF/
[15:45:28] <aslak> ?
[15:46:06] <jose_freitas> and jsf needs to have it on META-INF folder so it can be read
[15:46:20] <aslak> jose_freitas, sure, but that is during deploy
[15:46:29] <aslak> this is on client
[15:46:40] <jose_freitas> yes, but not person using arquillian would use jsfunit
[15:46:42] <aslak> JSFUnitArchiveAppender create what is being deployed
[15:46:51] <jose_freitas> not only
[15:47:03] <jose_freitas> there're other jsfunit users
[15:47:05] <aslak> which module is the faces-config file located ?
[15:47:11] <jose_freitas> jsfunit core
[15:47:25] <aslak> aa
[15:48:50] <aslak> jose_freitas, it's finding your modules faces-config i assume ?
[15:49:52] <jose_freitas> yes
[15:50:11] <aslak> ALR, ^
[15:50:19] <ALR> Yes?
[15:50:21] <aslak> ALR, i think we have touched upon this before, but..
[15:50:31] <aslak> ALR, might even have a jira on it somewhere
[15:50:51] <aslak> how to add a resource form a specific module, e.g jar
[15:51:07] <aslak> MyClass.class.getResource only use the CL from where that was loaded...
[15:51:13] <ALR> Uh huh
[15:51:21] <ALR> You wanna get the resource from a specific source.
[15:51:37] <aslak> give me "reosurce-x" found where MyClass.class is found
[15:51:43] <aslak> yea
[15:52:13] *** milestone has joined #jbosstesting
[15:54:19] <ALR> Yeeee.
[15:54:29] <jose_freitas> ?
[15:54:41] <ALR> Tying it to another nonunique resource?
[15:54:48] <ALR> MyClass.class can be in N locations too
[16:00:41] <aslak> mm, yea true
[16:02:56] <jose_freitas> hm, how jsf does?
[16:07:03] <jose_freitas> because it can loads different faces-config on jar:META-INF/
[16:07:10] <jose_freitas> from many jars
[16:24:34] *** rruss has quit IRC
[16:28:10] *** rruss has joined #jbosstesting
[16:31:33] <ge0ffrey> Somehow I am getting container-tomcat-60 beta1 in my classpath
[16:31:44] <ge0ffrey> even though I use shrinkwrap beta 5
[16:31:53] <ge0ffrey> that causes NoSuchMethodException: org.jboss.shrinkwrap.tomcat_6.api.ShrinkWrapStandardContext addChild
[16:33:08] <aslak> ge0ffrey, two different shrinkwrap lifecycles
[16:33:22] <ge0ffrey> aslak: what do you mean?
[16:34:01] <aslak> https://github.com/arquillian/arquillian-container-tomcat/blob/master/pom.xml#L36
[16:34:06] <aslak> https://github.com/arquillian/arquillian-container-tomcat/blob/master/pom.xml#L64
[16:34:17] *** alesj has quit IRC
[16:34:28] *** alesj has joined #jbosstesting
[16:34:52] <ge0ffrey> aslak: ok, so I 'll want to override that dependency too
[16:35:15] <ge0ffrey> and set shrinkwrap-container-tomcat-60 to beta5 ?
[16:35:18] *** mgoldmann has quit IRC
[16:35:30] <aslak> no
[16:35:41] <aslak> beta-1 is the latest release of that to my knowledge
[16:36:06] <ge0ffrey> aslak: so they should be compatible? What's causing the NSME?
[16:36:52] <aslak> could be some tomcat lib being pulled in from somewhere else
[16:37:00] <aslak> it extends a Tomcat class
[16:37:34] <aslak> yea, addChild comes from it's super class
[16:37:41] <ge0ffrey> btw, I tried .exclusion("com.google.gwt:gwt-dev") but the MavenDependencyResolver ignored that
[16:37:55] <ge0ffrey> so I am doing a seperate module now, guvnor-integration-tests
[16:38:15] <aslak> kpiwko, ^
[16:40:03] <kpiwko> ge0ffrey: exclusion always applies to a dependency, the same way as maven does it
[16:40:29] <ge0ffrey> yep, yet I verified at runtime that it didn't apply that exclusion
[16:41:12] <kpiwko> ge0ffrey: can you provide that call? that would be a bug if exclusion wasn't applied
[16:41:46] <ge0ffrey> kpiwko: I 'll push what I got locally so you can emulate locally
[16:42:11] <kpiwko> ge0ffrey: thanks!
[16:47:35] *** jharting has quit IRC
[16:47:54] <ge0ffrey> kpiwko: https://github.com/ge0ffrey/guvnor/tree/upgradeToSeam3
[16:48:23] <ge0ffrey> and here's the test that has the bug: https://github.com/ge0ffrey/guvnor/blob/upgradeToSeam3/guvnor-webapp/src/test/prototype-test/org/drools/guvnor/WebappPrototypeArqTest.java
[16:49:17] <kpiwko> ge0ffrey: I'm sorry to say but this is not expected to work
[16:50:03] <kpiwko> ge0ffrey: you includeAll the dependencies from pom file ... imagine the <dependencies> there...where would you like your <exclusion> to apply? to all of them?
[16:50:33] <ge0ffrey> kpiwko: yes, like specifying <exclusion> in the pom?
[16:50:48] <kpiwko> exclusion() corresponds to <dependency>...<exclusions><exclusion>...</exclusion></dependency>
[16:51:06] <ge0ffrey> it's possible to do general <exclusion> too IIRC
[16:51:07] <kpiwko> so basically it is applied to the last artifact() you specified
[16:51:18] <ge0ffrey> ah k
[16:51:25] <ge0ffrey> there's not support for generalExclusion() ?
[16:52:24] <kpiwko> in resolver, you can do artifacts("a", "b").exclusion("c"), then c is excluded from both a and b
[16:52:39] <ge0ffrey> yes, but not if you start from a pom
[16:52:46] <kpiwko> however, support for exclusion of all deps loaded from a pom file is not implemented
[16:52:53] <ge0ffrey> ok, does make sense, even though it sux for my use case :)
[16:52:56] <kpiwko> ge0ffrey: yep
[16:52:58] <ge0ffrey> I can't find general exclusions in http://maven.apache.org/ref/3.0.3/maven-model/maven.html
[16:53:10] <ge0ffrey> either
[16:53:11] <kpiwko> ge0ffrey: I think they does not exist
[16:53:22] <ge0ffrey> no, else they would be documented there
[16:53:23] <kpiwko> ge0ffrey: can you file a jira with that use case
[16:53:28] <ge0ffrey> IIRW :)
[16:53:38] <ge0ffrey> i recalled wrong
[16:55:02] <ge0ffrey> but there is a solution
[16:55:25] <ge0ffrey> kpiwko: how do I tell it now to include the provided scope artifacts?
[16:55:57] <kpiwko> ge0ffrey: apply a ScopeFilter("provided") in resolveXYZ() call
[16:56:24] <ge0ffrey> provided will include them Isuupose
[16:56:36] <ge0ffrey> so "runtime" will exclude them?
[16:57:03] <kpiwko> yes, but resolver does not depend on runtime scope
[16:57:04] <ge0ffrey> ah here's the catch 22: I need "test", but without catalina, etc of course
[16:57:12] <kpiwko> yep
[16:57:43] <kpiwko> ge0ffrey: the most straighforward solution I see now is to use loadMetadataFromPom() instead
[16:58:10] <kpiwko> then enumerate artifacts("","").exclusions("")
[16:58:22] <kpiwko> you can omit versions if you load metadata
[16:58:56] <kpiwko> artifacts().exclusions() chain does exactly the stuff you want, e.g. exclusions are applied to every artifact in artifacts()
[16:59:20] <ge0ffrey> kpiwko: that's to solve the distinction between test scope for test methods and test scope for plubming (catalina, weld container, ...)
[16:59:23] <ge0ffrey> ?
[17:00:07] <kpiwko> ge0ffrey: yes, it will solve it
[17:00:36] <kpiwko> because you won't have "catalina" in artifacts(), it won't be fetched :)
[17:00:47] <ge0ffrey> in any case stating .resolveAsFiles(new ScopeFilter("runtime"))); still makes it include the provided scope
[17:01:36] <ge0ffrey> kpiwko: is there an example that has a module that builds a war and then another module (integration-tests) that tests that war?
[17:04:04] <kpiwko> kpiwko: I'm aware of none
[17:05:52] <kpiwko> kpiwko: but a call like ShrinkWrap.createFromZipFile(WebArchive.class, new File(XYZ)); will do
[17:06:15] <kpiwko> however, not really usable for integration testing apart from WEB UI layer
[17:06:15] *** oskutka has quit IRC
[17:06:53] <ge0ffrey> yea, we need to be able to do @Inject, so I am thinking the seperate integration-tests modules is a dead end
[17:08:11] <ge0ffrey> kpiwko: got any idea how I ask all dependencies that will end up in WEB-INF/lib? So not including those in scope "provided"?
[17:08:25] <ge0ffrey> .resolveAsFiles(new ScopeFilter("runtime"))) does include them
[17:08:57] <kpiwko> what scope you have at the dependies?
[17:09:05] <ge0ffrey> gwt-dev is scope provided
[17:09:12] <ge0ffrey> and a couple more, like the servlet-api
[17:09:18] <ge0ffrey> which I don't want to deploy to tomcat either
[17:09:22] <kpiwko> yep
[17:09:29] <ge0ffrey> so it makes sense not to include them
[17:09:55] <kpiwko> but for the ones you want to deploy you have no <scope> tags in <dependency>, right?
[17:09:59] <ge0ffrey> and it's exactly the same set as maven puts into the WEB-INF/lib dir
[17:10:10] <ge0ffrey> kpiwko: some have compile, other have runtime
[17:10:17] <kpiwko> hmm
[17:10:31] <kpiwko> "compile", "runtime" won't do the work?
[17:10:36] <ge0ffrey> nope
[17:10:50] <kpiwko> if there is no scope on some of them, "", "compile", "runtime"
[17:11:28] <ge0ffrey> no scope defaults to "compile", no?
[17:11:54] <ge0ffrey> .resolveAsFiles(new ScopeFilter("", "compile", "runtime"))); still includes the compile/runtime dependencies that have scope provided
[17:12:02] <ge0ffrey> it's logical
[17:12:17] <ge0ffrey> if you ask runtime, you get all compile time scopes too
[17:12:29] <ge0ffrey> with test you get all compile and runtime too
[17:13:12] <kpiwko> yep, no scope is default, but maven does distinguish between no scope defined and compile on xml level
[17:13:14] <ge0ffrey> this doesn't fail-fast: .resolveAsFiles(new ScopeFilter("foobar")
[17:13:18] <kpiwko> or metadata level
[17:13:42] <ge0ffrey> ah k, intresting
[17:14:04] <kpiwko> it won't fail, it will simply reject all deps afte dependency graph is constructed :)
[17:14:39] <ge0ffrey> yet I still have gwt-dev on the classpath
[17:14:42] <ge0ffrey> but of course...
[17:14:53] <ge0ffrey> that's the classpath of the jar
[17:15:04] <ge0ffrey> I mean the war
[17:15:05] *** bdlink has joined #jbosstesting
[17:15:15] <ge0ffrey> I meddling with the wrong classpath
[17:15:43] <ge0ffrey> when arq is starting the embedded container, it's still in the module's classpath
[17:15:56] <kpiwko> yep
[17:15:57] <ge0ffrey> and there gwt-dev is in front of tomcat and shadows it
[17:16:22] <kpiwko> that's why you get a nasty warning gwt-dev should not be a maven dep at all
[17:16:57] <ge0ffrey> don't get a warning, I get a MethotNotFoundError :)
[17:17:10] <kpiwko> :)
[17:17:21] <ge0ffrey> but gwt-dev's evil, as it shades stuff
[17:23:19] <kpiwko> you can force cl in surefire
[17:23:23] <kpiwko> that might help
[17:23:55] <kpiwko> I saw a explanation/workaround somewhere in gwt-maven plugin why the can't use surefire for testing
[17:23:59] <kpiwko> ge0ffrey: ^
[17:24:12] <kpiwko> *the -> they
[17:24:25] *** alesj has quit IRC
[17:24:34] <ge0ffrey> kpiwko: the tests need to run in intelij and eclipse too :/
[17:24:47] <ge0ffrey> I need to get gwt-dev out of the classpath
[17:25:47] <kpiwko> ge0ffrey: I'd like to see the result if you manage to do that...because the same problem is waiting for me to solve sooner or later
[17:26:22] <ge0ffrey> kpiwko: split up client and server side?
[17:26:30] <ge0ffrey> here are some issue's to watch
[17:26:36] <ge0ffrey> https://issues.jboss.org/browse/GUVNOR-1538
[17:26:38] <jbossbot> jira [GUVNOR-1538] Do not include gwt-dev in the guvnor-webapp classpath [Open (Unresolved) Bug, Blocker, Geoffrey De Smet] https://issues.jboss.org/browse/GUVNOR-1538
[17:26:44] <ge0ffrey> https://issues.jboss.org/browse/GUVNOR-1196
[17:26:48] <jbossbot> jira [GUVNOR-1196] Build: Split up drools-guvnor into guvnor-gwt-client and guvnor-webapp [Open (Unresolved) Task, Critical, Geoffrey De Smet] https://issues.jboss.org/browse/GUVNOR-1196
[17:26:50] <kpiwko> ge0ffrey: cause I'd like to try to use arq + drone with development mode in browser
[17:27:45] <ge0ffrey> one thing I am wondering though
[17:27:56] <ge0ffrey> Why do I want to use a tomcat container to test my stuff?
[17:28:23] <ge0ffrey> Can't I just use junit standalone?
[17:29:31] <ge0ffrey> kpiwko: btw, putting gwt-dev dependency dead last in the dependency list, makes tomcat shade it instead of the other way around :)
[17:31:12] <kpiwko> ge0ffrey: nice...but I'd guess this is not reliable...
[17:31:26] <kpiwko> ge0ffrey: you said you're using tomcat embedded 6, right?
[17:31:31] <ge0ffrey> yes
[17:31:54] <ge0ffrey> since my old tests were just plain unit tests that faked CDI
[17:32:06] <kpiwko> ge0ffrey: I hope to see tomcat managed 6 impl soon, so whats on classpath won't matter
[17:32:10] <ge0ffrey> I should be able to use the SE container instead?
[17:32:25] <ge0ffrey> What does managed mean?
[17:32:55] <kpiwko> ge0ffrey: it means that Arquillian controls the lifecycle of the container (start/stop) but the container is running as separate process
[17:33:27] <kpiwko> ge0ffrey: so what's on project classpath does not matter anymore
[17:33:36] <kpiwko> ge0ffrey: a bit slower though
[17:34:16] <kpiwko> ge0ffrey: there are many managed containers but tomcat is unfortunately missing
[17:35:50] <ge0ffrey> intresting
[17:36:59] <ge0ffrey> running in different containers (embedded and managed, not remote) is intresting stuff, but it's cherry on the cake - first I need to get the tests working with real CDI (they are full of Contexts. and Component. abuse with seam 2)
[17:39:57] *** lfryc has quit IRC
[17:48:47] <ge0ffrey> thanks for you help guys
[17:48:56] <ge0ffrey> I am finally making some progress :)
[17:49:31] <ge0ffrey> to bad I got pto soon, but I 'll be here with more questions soon (I hope you don't mind)
[17:49:39] <ge0ffrey> goodnight
[17:49:47] *** ge0ffrey has quit IRC
[18:04:03] *** Jaikiran is now known as Jaikiran|AFK
[18:07:13] *** maschmid has quit IRC
[18:15:41] *** pilhuhn is now known as pil-dinner
[18:28:29] *** Jaikiran|AFK has quit IRC
[18:45:42] *** kpiwko has quit IRC
[18:53:57] *** rbattenfeld has joined #jbosstesting
[18:54:37] <rbattenfeld> ALR: Hi Andrew, I just read your twitter message:-)
[18:55:27] *** ALR has quit IRC
[18:55:27] *** lightguard_jp has joined #jbosstesting
[18:59:16] *** milestone has quit IRC
[19:10:29] *** ALR has joined #jbosstesting
[19:10:53] *** ALR has quit IRC
[19:11:21] <jose_freitas> aslak: so, how should I procceed on that problem on loading META-INF/faces-config  ?
[19:20:28] <aslak> jose_freitas, copy for now..
[19:21:48] <jose_freitas> should I pull a jira so this won't be forgotten?
[19:22:33] <jose_freitas> I mean, a jira on jsfunit, and maybe pointing dependency to a shrinkwrap jira
[19:22:42] <aslak> jose_freitas, yea sure, do that
[19:27:05] *** bobmcw_ has joined #jbosstesting
[19:30:10] *** rbattenfeld has left #jbosstesting
[19:32:19] *** jbossbot has quit IRC
[19:32:20] *** galderz has quit IRC
[19:32:21] *** galderz has joined #jbosstesting
[19:32:22] *** galderz has quit IRC
[19:32:22] *** galderz has joined #jbosstesting
[19:40:06] *** galderz1 has joined #jbosstesting
[19:41:34] *** ianbrandt has joined #jbosstesting
[19:43:16] *** galderz has quit IRC
[19:45:02] <jose_freitas> aslak: is there a shrinkwrap jira issue for that? no, right?
[19:45:50] <aslak> jose_freitas, i don't remember
[19:51:27] <jose_freitas> I'll create another one, just in case. we can resolve it as a duplicate later.
[19:51:32] <jose_freitas> ok?
[19:51:38] <aslak> sure
[19:57:33] *** rruss has quit IRC
[20:00:13] <jose_freitas> aslak: https://issues.jboss.org/browse/JSFUNIT-282?focusedCommentId=12620508#comment-12620508
[20:02:07] <aslak> :)
[20:02:30] *** jbossbot has joined #jbosstesting
[20:15:12] *** jhuska has quit IRC
[20:28:43] *** dblevins has quit IRC
[20:29:27] *** galderz1 has quit IRC
[20:30:01] *** pil-dinner is now known as pilhuhn
[20:34:59] *** dblevins has joined #jbosstesting
[20:54:54] *** bleathem is now known as bleathem_away
[21:02:38] *** bleathem_away is now known as bleathem
[21:07:28] *** dblevins has quit IRC
[21:09:54] <jose_freitas> aslak: you mentioned that sharing a deployed archive between testcases is a future feature but for 1.1.0, right? I'm aligning some plans
[21:12:44] *** dblevins has joined #jbosstesting
[21:13:44] <aslak> jose_freitas, yea
[21:14:21] <jose_freitas> thanks
[21:20:35] *** dblevins has quit IRC
[21:43:22] *** rruss has joined #jbosstesting
[22:16:10] *** alesj has joined #jbosstesting
[22:19:31] *** bleathem has quit IRC
[22:27:54] *** rbattenfeld has joined #jbosstesting
[22:37:06] *** rbattenfeld has left #jbosstesting
[22:53:29] *** bobmcw_ has quit IRC
[23:11:17] *** pilhuhn is now known as pil-zZzZzzZ
[23:30:10] *** alesj has quit IRC
[23:52:16] *** galderz has joined #jbosstesting
[23:52:22] *** galderz has quit IRC





top