[00:00:21] <aslak> michaelschuetz, heya
[00:01:12] <aslak> bobmcw, sorry, dinner.. jbossHome/bin
[00:01:56] <michaelschuetz> aslak
[00:02:11] <michaelschuetz> aslak: having time to talk about seam2 integration?
[00:04:25] <aslak> michaelschuetz, sure
[00:05:08] *** jharting has quit IRC
[00:06:09] <bobmcw> thanks!
[00:08:29] <michaelschuetz> aslak: arquillian seam2 integration is my main focus (in evening coding sessions) now for the next week at least
[00:08:51] <michaelschuetz> aslak: wil start with enricher, appender stuff as described by you already
[00:09:02] <michaelschuetz> aslak: but lot's og thins come up
[00:09:54] <michaelschuetz> aslak: "native Seam2 integration", appender for both EAR and WAR deployment, container support and so on
[00:10:03] <aslak> michaelschuetz, where are you at ?
[00:10:27] <aslak> mm
[00:10:46] <aslak> yea, the easies should be to sart with the enricher
[00:10:51] <michaelschuetz> aslak: just starting - currently with enricher
[00:10:55] <michaelschuetz> yeah
[00:17:35] <aslak> michaelschuetz, just shout out as you go along if you get stuck or is wondering about something
[00:21:30] <michaelschuetz> aslak, cheers - i certainly will
[00:54:21] *** ldimaggi_ has joined #jbosstesting
[00:56:41] <ALR> aslak: Got an example of the assembly plugin used in a multi-module build?
[00:57:14] <aslak> ALR, maven?
[00:57:19] <ALR> Yeah
[00:57:50] <aslak> ALR, maybe weld servlet
[00:58:01] <ALR> Mine's trying to run (from the aggregator) before the submodules are built.
[00:58:14] <aslak> don't remember if they use assembly or the share-jar or what it's called
[00:58:28] <ALR> I dislike the assembly plugin anyway.
[00:59:05] <ALR> I think Weld uses Shade
[00:59:09] <aslak> yea, shade
[00:59:11] <ALR> I want just some easy scripting thing.
[00:59:18] <ALR> Maybe Ant is best, actually.
[00:59:21] <aslak> https://github.com/weld/core/blob/master/environments/servlet/build/pom.xml
[00:59:29] <aslak> ALR, for the zip release ?
[00:59:47] <ALR> Yeah, ZIP, TARs
[01:05:54] <michaelschuetz> aslak: why does every enricher has it's own SecurityActions class? Does look highly duplicated..
[01:07:30] *** bleathem has quit IRC
[01:07:58] *** lightguard_jp has quit IRC
[01:08:05] <ALR> michaelschuetz: They're package-private
[01:08:26] <ALR> If you make 'em public, people can use them to subvert the security mechanism
[01:09:39] <aslak> aa, yes.. what alr said.. :)
[01:20:36] *** nthngrtr has joined #jbosstesting
[01:21:55] *** nthngrtr has left #jbosstesting
[01:21:57] *** nthngrtr has joined #jbosstesting
[01:22:10] *** nthngrtr has left #jbosstesting
[01:30:00] *** nthngrtr has joined #jbosstesting
[01:30:02] *** nthngrtr has left #jbosstesting
[01:30:08] *** nthngrtr has joined #jbosstesting
[01:30:12] *** nthngrtr has left #jbosstesting
[01:33:39] <michaelschuetz> alr, cheers
[01:33:51] <ALR> michaelschuetz: N/P, does that explain it?
[01:34:15] <ALR> Something you CAN share and make public are the privileged actions.
[01:34:18] <ALR> For instance
[01:35:00] *** rruss has quit IRC
[01:35:05] *** aslak has quit IRC
[01:35:14] <ALR> public enum GetTcclAction implements PriviligedAction<ClassLoader>{
[01:35:14] <ALR>   INSTANCE,
[01:35:14] <ALR>   public ClassLoader run(){ return Thread.currentThread().getContextClassLoader();}
[01:35:14] <ALR> }
[01:35:19] *** rruss has joined #jbosstesting
[01:35:21] <ALR> That's OK to share.
[01:35:27] <ALR> Then the part you lock down is:
[01:36:01] <ALR> static ClassLoader getTccl(){
[01:36:01] <ALR>   return AccessController.doPriviliged(GetTcclAction.INSTANCE);
[01:36:01] <ALR> }
[01:39:15] <michaelschuetz> alr, yeah i think i get that idea.
[02:01:49] *** bgeorges has joined #jbosstesting
[02:16:44] *** michaelschuetz has quit IRC
[02:50:17] *** rruss has quit IRC
[02:55:19] <jbossbot> git [shrinkwrap] push master 77bbba7.. Andrew Lee Rubinger [SHRINKWRAP-248] Update build w/ Git SCM information for release plugin
[02:55:21] <jbossbot> jira [SHRINKWRAP-248] Setup build for release plugin to honor Git SCM [Open, Major, Andrew Rubinger] https://issues.jboss.org/browse/SHRINKWRAP-248
[02:55:21] <jbossbot> git [shrinkwrap] push master URL: http://github.com/shrinkwrap/shrinkwrap/compare/e64462b...77bbba7
[03:52:47] *** dblevins has quit IRC
[03:57:05] *** dblevins has joined #jbosstesting
[04:19:07] *** rruss has joined #jbosstesting
[04:33:20] *** bgeorges has quit IRC
[04:42:05] *** rruss has quit IRC
[04:42:32] *** rruss has joined #jbosstesting
[04:45:50] *** ldimaggi_ has quit IRC
[04:52:25] *** rruss has quit IRC
[05:37:01] *** stuartdouglas has quit IRC
[05:54:02] *** stuartdouglas has joined #jbosstesting
[06:34:48] *** lightguard_jp has joined #jbosstesting
[06:53:34] *** kpiwko has joined #jbosstesting
[07:39:42] <kpiwko> hi ALR, I've seen SHRINKWRAP-140 is planned to 1.0.0-Beta-1, but there apparently will be an alpha release before...is there a specific thing you would like to see in the extension so I can update fix version to Alpha-12? I've like to have it released as soon as possible
[07:39:46] <jbossbot> jira [SHRINKWRAP-140] Support loading artifacts from a Maven repository [Open, Major, Karel Piwko] https://issues.jboss.org/browse/SHRINKWRAP-140
[07:40:28] *** oskutka has joined #jbosstesting
[07:43:38] <ALR> kpiwko: Go right ahead.
[07:43:49] <ALR> kpiwko: I haven't reviewed the patch yet
[07:43:58] <ALR> The whole "from a Maven repo" scares me a bunch
[07:44:07] <ALR> As I haven't seen yet a reliable way of doing this
[07:44:11] <ALR> Without some extra config.
[07:44:25] <ALR> But if you've got the magic sauce it'll make it in the next release for sure.
[07:46:40] <kpiwko> so I'll check docs are updated and send a pull request...in my pov it is pretty stable now and used in Arquillian Beta.1, so tested as well
[07:46:58] <ALR> kpiwko: I'm sure it works :)
[07:47:05] <ALR> My concern is "how".
[07:47:24] <kpiwko> it is using Aether
[07:47:31] <ALR> And if it's really reliable for all users, even those with nonstandard Maven config filenames, etc
[07:47:46] <kpiwko> so basically does all Maven repository magic without Maven
[07:47:48] <ALR> kpiwko: Does it trigger another Embedded Maven build lifecycle?
[07:47:54] <ALR> (We've gone that route too)
[07:48:10] <kpiwko> no, Maven is not executed
[07:48:13] <ALR> kpiwko: OK, cool.  So then here's the issue:
[07:48:23] <ALR> kpiwko: Say you want to test the "current" project.
[07:48:44] <ALR> If you exec the test in "test" or "integration-test" phase, the artifact is not yet installed into the Maven repo.
[07:49:11] <ALR> And even Aether is going to need to consult settings.xml to figure out where the user's local repo is, right?  How is that handled?
[07:50:10] <kpiwko> basically Aether checks for settings.xml at default location or you can specify it direcly in the java test code...maybe I should provide a way how to define it as a system property as well
[07:50:47] <kpiwko> if you want to check current project, I'm afraid you have to package it yourself in @Deployment method
[07:50:48] <ALR> kpiwko: Yeah, some externalized settings thing would be great.
[07:51:09] <kpiwko> but you can reuse existing pom for getting dependencies/dependency versions
[07:51:30] <ALR> kpiwko: Can't wait to take a look at the code you've got then.  I'll check it out tomorrow
[07:51:37] <ALR> Link to your branch?
[07:52:09] <kpiwko> ALR: https://github.com/kpiwko/shrinkwrap/tree/SHRINKWRAP-140
[07:52:09] <jbossbot> jira [SHRINKWRAP-140] Support loading artifacts from a Maven repository [Open, Major, Karel Piwko] https://issues.jboss.org/browse/SHRINKWRAP-140
[07:52:50] <kpiwko> awesome!
[07:53:03] <kpiwko> do you have an estimate when Alpha-12 could be released?
[07:53:20] <ALR> kpiwko: It can kinda go at any time.
[07:53:35] <ALR> kpiwko: Depending upon how much we wanna cram in it.
[07:53:45] <ALR> Or if anyone is waiting on its release for a specific issue.
[07:54:03] <ALR> I'll push alphas all day long until we stabilize the API enough for Beta.
[07:55:42] <kpiwko> ALR: Aslak might need to have this feature released for Arquillian Beta 1 at the end of this month
[07:56:29] <ALR> kpiwko: ARQ Beta1 should depend on SW Beta.
[07:56:30] <kpiwko> ALR: or, to be more precise, I'm pushing to him to have it released at this time so I can use it my workshop in mid of Feb ;)
[07:56:41] <ALR> Those two should coincide w/ locked APIs.
[07:56:50] <kpiwko> ALR, ah...I see
[07:56:52] <ALR> kpiwko: If wishes were horses....
[07:57:19] <ALR> But aslak and I will def coordinate on that, I'm sure
[07:59:34] <kpiwko> ALR, I'll provide some usage examples of extension into doc module...there's a lot of samples in test methods, but I've missed the doc...this should make your review faster
[08:00:24] <ALR> kpiwko: Which doc module?
[08:00:47] <ALR> kpiwko: Usually I review usage based on unit tests.
[08:01:41] *** mgencur has joined #jbosstesting
[08:01:47] <kpiwko> there's a shrinkwrap/doc module...the documentation there is rather a skeleton though
[08:04:44] <kpiwko> ALR:^
[08:04:55] <ALR> kpiwko: Yeah, it's more a placeholder.
[08:05:32] <kpiwko> ALR: so you want it updated or not?
[08:06:15] <ALR> kpiwko: You can hold off on that. :)
[08:06:23] <ALR> kpiwko: I plan on filling it out once API is stable
[08:06:35] <ALR> Then we'll know what we're working with, and it won't be in flux.
[08:06:44] <ALR> For alpha releases I think JavaDoc suffices.
[08:06:52] <ALR> So we don't spent time rewriting docs.
[08:07:02] <ALR> Don't be surprised if I loop around to you later though! :D
[08:07:13] <kpiwko> ALR: good to know ;)
[08:35:03] *** Jaikiran has joined #jbosstesting
[08:36:13] *** michaelschuetz has joined #jbosstesting
[08:37:20] *** theute has quit IRC
[08:48:37] *** rruss has joined #jbosstesting
[08:53:08] *** maeste has joined #jbosstesting
[09:09:55] *** jeand has joined #jbosstesting
[09:27:21] *** mgoldmann has joined #jbosstesting
[09:44:08] *** jharting has joined #jbosstesting
[09:46:28] *** aslak has joined #jbosstesting
[09:46:29] *** aslak has quit IRC
[09:46:29] *** aslak has joined #jbosstesting
[09:50:59] <kpiwko> michaelschuetz: I've just pushed fixed branch to the github...If you still want to volunteer, you can test it after pull
[09:58:30] *** theute has joined #jbosstesting
[09:59:38] <michaelschuetz> kpiwko: hi; ok just pulled and started run
[10:06:40] <ALR> aslak: Mornin
[10:06:50] <aslak> ALR, HEYA
[10:06:52] <aslak> ops..
[10:06:52] <ALR> aslak: Just a reminder about our discussion fro the summer
[10:06:53] <aslak> :)
[10:06:59] <ALR> Where we gotta lock our APIs together
[10:07:10] <ALR> Or rather, ARQ to lock needs to depend upon SW locked.
[10:07:18] <aslak> yes
[10:07:31] <ALR> Cool
[10:07:34] *** rruss has quit IRC
[10:07:36] <ALR> So SW needs to ge t'er done soon.
[10:08:15] <aslak> true
[10:08:42] <aslak> for sw the two maijor issues are, method renaming, and path mapping for WebArchive right
[10:08:52] <ALR> It's nor far off I don't think
[10:09:09] <aslak> same goes for Descriptors..:)
[10:09:14] <ALR> Only unknown I'm aware of is any API changes maybe needed for OSGi
[10:09:20] <ALR> Descriptors is a whole other beast
[10:09:34] *** lightguard_jp has quit IRC
[10:09:42] <ALR> aslak: You need locked APIs for Descriptors for ARQ?
[10:09:52] <aslak> ALR, but wouldn't the OSGi bring extras, and not changes ?
[10:09:57] <ALR> aslak: I'm not sure.
[10:10:03] <ALR> aslak: It *may* need some hooks.
[10:10:08] <ALR> Which *may( make changes
[10:10:15] <ALR> Ideally it should be extensions.
[10:10:22] <aslak> yea
[10:10:23] <ALR> But I can't rule it out yet.
[10:10:35] <ALR> aslak: I don't anticipate Descriptors getting stable this month.
[10:10:57] <michaelschuetz> kpiwko: cool: "BUILD SUCCESS, Total time: 7:29.671s"
[10:11:00] <aslak> i use Descriptors to manipulate web.xml in the Servlet 2.5 protocol
[10:11:55] <aslak> and I use the Descriptor IF as a posible @Deployment, but i don't depend on any methods besides export
[10:11:59] <ALR> aslak: In the impl?
[10:12:07] <ALR> Oh
[10:12:17] <ALR> So the user would see the Descriptor IF?
[10:12:18] <kpiwko> michaelschuetz: that's awesome ;) thanks! yeah, the build time will always take ages because multiple maven repositories must be downloaded
[10:12:54] <aslak> @Deployment public static Descriptor createX(); @Deployment public static Archive<?> createY();
[10:13:02] <ALR> Yee
[10:13:39] <ALR> That's still a gap methinks
[10:13:42] <aslak> would love to see a better integration between SW and Desc as well
[10:13:51] <ALR> That ShrinkWrap archives must be archives
[10:14:00] <ALR> And not, say, a standalone file deployable like a Descriptor
[10:14:12] <ALR> aslak: Then we best be getting chugging.
[10:14:41] <kpiwko> michaelschuetz: or rather their parts...not trying to download whole internet there ;)
[10:14:50] <aslak> ALR, not sure i understand the last comment there?
[10:15:09] <ALR> aslak: Like we gotta get a move on and fire these things back up
[10:15:18] <ALR> Line up what needs to be done
[10:15:26] <ALR> And make sure every task is JIRA'd
[10:15:29] <aslak> ALR, hehe, no the comment before that.. ;)
[10:15:35] <ALR> Oh
[10:15:55] <ALR> It'd be nice if you could do:
[10:16:07] <ALR> @Deployment public static DeployableThing getThing(){}
[10:16:26] <ALR> Where Archive, Descriptor, and custom types are all DeployableThings
[10:16:47] <ALR> We assumed early on that every deployment would be a SW Archive.
[10:16:53] <ALR> And then tacked on Descriptor support.
[10:16:55] <aslak> that happens on the inside of arq currently
[10:16:58] <ALR> Yeah.
[10:17:27] <ALR> Something in the API for the user would be ideal (maybe)
[10:17:37] <ALR> Cause then you still need to get SW into DeployableThing
[10:17:38] <aslak> to be fair to Descriptors and Archives as general archiving / file manipulating tools, they are only Deployable in our context.
[10:17:42] <ALR> Meaning the user would have to do:
[10:17:53] <ALR> archive.as(DeployableThing.class); at the end
[10:18:16] <ALR> Well yeah, they're deployable into something which accepts deploying it.
[10:18:17] <ALR> Which is us.
[10:18:31] <ALR> In the end I think anything with InputStream getContents() is Deployable
[10:18:43] <ALR> If you've got bytes, you can deploy it.
[10:18:51] <aslak> if they are the correct bytes
[10:18:59] <aslak> or you can still deploy, it will just fail
[10:19:01] <ALR> Not our problem :)
[10:19:04] <ALR> Right
[10:19:21] <aslak> i'm not sure we need a common parent
[10:19:34] <ALR> If we had DeployableThing IF, then actually users could make their own DeployableThings.
[10:19:38] <ALR> They wouldn't *need* to use SW
[10:19:55] <ALR> Hmm...trying to remember what accepts the Archive.
[10:20:06] <aslak> everything.. :)
[10:20:09] <ALR> Like I think the Embedded AS ARQ Container accepts the SW Archive and deals with it natively.
[10:20:14] <ALR> Instead of using bytes
[10:20:16] <ALR> Right.
[10:20:30] <aslak> arq spis do a lot of manipulation on it..
[10:20:42] <ALR> With enrichment you mean?
[10:21:01] <aslak> enrichment, packaging, descriptor modifications etc
[10:21:26] <ALR> Yu
[10:21:27] <ALR> *Yup
[10:21:29] <aslak> we could of course just skip all that if the DeployableThing is not a Archive
[10:21:40] <aslak> but then again, SW has that abstraction with Asset
[10:21:53] <ALR> So pick a contract.
[10:21:57] <ALR> What do we deploy?
[10:21:58] <ALR> Archives?
[10:22:05] <ALR> Archives and/or Descriptors?
[10:22:10] <aslak> Archives and Descriptors
[10:22:47] <aslak> Descriptors might not be 'deployable' in the sense you think. e.g. GlassFish does not support deployment in that sense, so you have to execute Descriptors via their Admin tools
[10:22:59] <ALR> Yep.
[10:23:01] <ALR> asadmin
[10:23:18] <ALR> So I'll keep on w/ SW for a bit.
[10:23:27] <ALR> And split time w/ EJB3 until that's done I guess.
[10:23:35] <aslak> a Descriptor in this case is a Container config/resource, not a EE Module descriptor
[10:23:42] *** mgoldmann is now known as mgoldmann|out
[10:25:36] <aslak> and this line is bugging me: war.setWebXML(new StringAsset(Descriptors.create(WebAppDescriptor.class).exportToString()))
[10:25:50] <aslak> not and this line, this is the line
[10:25:58] <aslak> when talking aobut integration
[10:27:05] <aslak> michaelschuetz, heya, in injectClass() you need to loop for the fields with @In and lookup / set them individually right ?
[10:31:44] <michaelschuetz> aslak: hey. yeah, true i think
[10:32:10] <aslak> michaelschuetz, looks good so far
[10:32:32] <michaelschuetz> aslak: not sure about this: https://github.com/michaelschuetz/arquillian/blob/ARQ-347/frameworks/seam2/src/main/java/org/jboss/arquillian/testenricher/seam2/Seam2InjectionEnricher.java#L62
[10:32:34] <jbossbot> jira [ARQ-347] Seam 2 integration [Coding In Progress, Major, Michael Schuetz] https://issues.jboss.org/browse/ARQ-347
[10:33:27] <michaelschuetz> aslak: tha's the way i do it in current project. But does this suit in that context?
[10:33:41] *** lfryc has joined #jbosstesting
[10:33:57] <aslak> michaelschuetz, yea, was looking at that as well. but keep it there for now. it's really a @BeforeSuite type of action, but at that point you don't really know if the TestCase will even be using Seam. So initialize it when you know
[10:34:43] <aslak> then again, i guess you could have seam in your application without using a @In in the testcase.. but then i don't think it's up to us to initialize it ?
[10:35:05] <michaelschuetz> aslak: ok
[10:35:18] <michaelschuetz> aslak: yeah that's the direction i was wondering about
[10:35:47] <michaelschuetz> aslak: but think your right: do youse manual Seam API lookup sparely
[10:35:53] <michaelschuetz> use
[10:37:05] *** lfryc has quit IRC
[10:37:36] <aslak> brb, coffee
[10:37:42] *** lfryc has joined #jbosstesting
[10:37:47] <michaelschuetz> aslak: you where talking about using https://github.com/michaelschuetz/arquillian/blob/ARQ-347/frameworks/seam2/src/main/java/org/jboss/arquillian/testenricher/seam2/SecurityActions.java#L179 within injectClass() right?
[10:37:47] <jbossbot> jira [ARQ-347] Seam 2 integration [Coding In Progress, Major, Michael Schuetz] https://issues.jboss.org/browse/ARQ-347
[10:43:46] *** ALR has quit IRC
[10:59:10] *** GTobi has joined #jbosstesting
[11:11:42] <aslak> michaelschuetz, to do reflection yes
[11:13:29] <aslak> michaelschuetz, I have been playing with a Reflection Query 'language', but use SecurityActions for now: http://arquillian.pastebin.com/SeRrQ5X6
[11:16:18] *** bgeorges has joined #jbosstesting
[11:20:27] <michaelschuetz> aslak: nice. where does QueryService come from?
[11:21:04] <aslak> michaelschuetz, unknown.. hehe
[11:23:46] <aslak> michaelschuetz, the QueryService is a attempt to fix some issues regarding Arquillian Suites, having multiple test classes run against the same deployment, with @Deployments etc on multiple levels, so the Query language was/is a attempt to hide the complexity of looking up potensial test classes in multiple contexts.. some logic that would have to be replicated into every extension more or less
[11:26:07] <michaelschuetz> aslak, agree - does make sense
[11:35:37] <aslak> kpiwko, you have any comments on this: http://arquillian.pastebin.com/bcrup1UD
[11:36:32] <aslak> kpiwko, wondering about moving all the loadable SPIs into one single Entry point., Extension. then you can register with the ServiceRegistyr all the other Spis you want to be loaded
[11:39:30] <aslak> also one location where we can add e.g. Extension name, possible Dependencies.. maybe some Ordering hints
[11:40:52] *** Jaikiran has quit IRC
[11:41:05] <aslak> don't load extension if Selenium not found on classpath
[11:44:13] *** pmuir has joined #jbosstesting
[11:44:13] *** pmuir has quit IRC
[11:44:13] *** pmuir has joined #jbosstesting
[11:52:26] *** bgeorges_ has joined #jbosstesting
[11:55:51] *** bgeorges has quit IRC
[12:15:11] *** bgeorges_ has quit IRC
[12:17:06] <kpiwko> aslak, makes much more sense than current state...morever, we can move InstantiatorUtil functionality to ServiceRegistry so we can limit ServiceImpl to generic type as well
[12:25:47] *** mgoldmann|out is now known as mgoldmann
[12:28:29] <kpiwko> aslak, see updated http://arquillian.pastebin.com/Ed9gwGK8 for example what I meant
[12:30:44] <kpiwko> so I can get rid of configuration in META-INF as well
[12:37:29] *** michaelschuetz has quit IRC
[12:38:17] *** michaelschuetz has joined #jbosstesting
[12:43:55] <aslak> kpiwko, aa yes
[12:44:33] <aslak> kpiwko, wat are AjocadoInstantiator.class, AjaxSelenium.class
[12:44:34] <aslak> ?
[12:48:09] <aslak> kpiwko, AjaxSelenium is a parameter to AjacadoInstantiator's constructor ?
[12:48:16] <kpiwko> right
[12:48:59] <kpiwko> aslak: for Instantiator are defined as Instantiator<ObjectToCreate>, where AjaxSelenium is current name for non-existing AjocadoInstantiator
[12:49:57] <kpiwko> aslak: so when I see @Selenium ObjectToCreate field; , I know what Instantiator to retrieve from ServiceLoader
[12:50:04] <kpiwko> what -> which
[12:50:23] <aslak> mmm
[12:51:16] <aslak> maybe <T> void add(Class<T> service, T serviceImpl) would be better..
[12:51:48] <aslak> or as a option in those cases..
[12:51:58] <kpiwko> aslak, that won't work because T is generic as well
[12:52:41] <aslak> kpiwko, i mean, registry.add(Instantiator.class, new AjacadoInstantiator(new AjaxSelenium.class) )
[12:52:54] <aslak> opps.. new Ajax
[12:52:57] <aslak> ugh..
[12:53:02] <aslak> registry.add(Instantiator.class, new AjacadoInstantiator(new AjaxSelenium()) )
[12:53:20] <kpiwko> aslak, well, it will actually work, but then I have to traverse all impls returned by ServiceLoader.all() to check which one to use
[12:53:51] <aslak> aa, you mean like a qualifier
[12:54:12] <kpiwko> aslak, yeah, that's the right word!
[12:54:24] <aslak> loader.all(OfType, WithArgument)
[12:54:36] <kpiwko> not parametertype but qualifier
[12:54:46] *** michaelschuetz has quit IRC
[12:55:09] <aslak> where is AjaxSelenium used?
[12:55:20] <aslak> or what is it
[12:55:30] *** michaelschuetz has joined #jbosstesting
[12:56:02] <kpiwko> aslak, AjaxSelenium is current browser object for Ajocado
[12:56:18] <aslak> how do you map that to @Selenium ?
[12:56:19] <kpiwko> there is no such class currently in the extension not it's dependencies
[12:56:33] <kpiwko> see SeleniumCreator.class
[12:57:10] <kpiwko> or my comment few line up
[12:58:43] <kpiwko> aslak, basically I check for @Selenium field type and search for all Instatiator<SeleniumFieldType>, which are later used to create and instance to be injected
[12:59:07] <kpiwko> so any type of field can be marked as @Selenium
[12:59:23] <aslak> aa, right. it will be @Selenium AjaxSelenium
[12:59:27] <kpiwko> this means extension can be further extended
[12:59:39] <kpiwko> aslak, exactly
[13:00:51] <aslak> kpiwko, so when you do loader.onlyOne(Initiator.class, AjaxSelenium.class) you expect to get back a AjacadoInitiator insance which will create a initiator of type AjaxSelenium
[13:01:17] <aslak> not a initiator, but will create a instance of AjaxSelenium
[13:03:34] *** wolfc1 has joined #jbosstesting
[13:04:46] *** wolfc1 is now known as wolfc
[13:04:57] <kpiwko> aslak, I'm expecting Instantiator, because even if its name says differently, it is later used to properly destroy the object as well
[13:05:56] <kpiwko> so I do loader.all(Instantiator.class) and and than filter on generic type AjaxSelenium.class
[13:06:21] <kpiwko> if there're still multiple result I sort on precedence field
[13:06:34] <kpiwko> which is a part of instantiator contract
[13:06:41] <aslak> right
[13:07:01] <aslak> the ServiceLoader does nothing with AjaxSelenium besides filtering
[13:07:11] <kpiwko> actually, all I was suggesting is having this filter in ServiceLoader
[13:07:29] <kpiwko> it is not necessary to change API of ServiceRegistry
[13:07:46] <kpiwko> because the information is already present in class object
[13:08:32] <aslak> Query.forType(Class.class).ofType(Initiator.class).withGenericType(AjaxSelenium.class)
[13:08:46] <aslak> :)
[13:09:12] <aslak> excpet forType would be a intance in this case..
[13:09:35] <kpiwko> aslak, Query is that thing you've spoken in the morning with michaelschuetz?
[13:09:41] <aslak> yea
[13:09:55] <aslak> just a potensial usecase for it.. :)
[13:10:46] <kpiwko> aslak, yeah! can replace my homegrown solution for this problem with it
[13:10:49] <kpiwko> :)
[13:11:12] <aslak> yea, basically..
[13:11:39] <aslak> we do a lot of scanning in the extensions, so a simplified api on top of it could be very useful
[13:13:57] *** pmuir has quit IRC
[13:18:24] *** ldimaggi_ has joined #jbosstesting
[14:00:59] <rkellerm> Hello Aslak, Ralf Kellermann again
[14:01:44] <aslak> rkellerm, heya
[14:02:34] <rkellerm> I just tried to test JPA with Arquillian, but where do I put any Datasource information like persistance.xml for my tests and how does arquillian get it to know
[14:03:09] <aslak> persistence.xml you put in the archive
[14:03:24] <aslak> the datasource itself depends a bit on the server..
[14:03:30] <rkellerm> with addResource()?
[14:03:47] <aslak> rkellerm, JavaArchive or WebArchive?
[14:04:03] <rkellerm> JavaArchive
[14:04:58] <aslak> yea, addManifestResource
[14:05:33] <rkellerm> Can i place the persistance.xml into src/test/resources and let it use a different DB like projectTESTdb
[14:05:58] <aslak> sure
[14:06:16] <aslak> addManifestResource("my-test-persistence.xml", "persistence.xml")
[14:14:44] <rkellerm> Thanks, now i get :    MappingException: Could not determine type for: java.util.List
[14:15:25] <rkellerm> I have two classes:
[14:15:28] <rkellerm> @Entity
[14:15:28] <rkellerm> @Inheritance(strategy=InheritanceType.SINGLE_TABLE)
[14:15:28] <rkellerm> public abstract class AbstractOperation
[14:15:32] <rkellerm> and:
[14:15:56] <rkellerm> @Entity
[14:15:57] <rkellerm> public class Operation extends AbstractOperation implements
[14:17:07] <rkellerm> and a third one:
[14:17:17] <rkellerm> @Entity
[14:17:18] <rkellerm> @Table(name="operationgruppe")
[14:17:18] <rkellerm> public class OperationGroup extends AbstractOperation
[14:17:26] <rkellerm> 	private List<AbstractOperation> operationList;
[14:17:58] <rkellerm> I wanted to persist a composite pattern
[14:25:06] *** michaelschuetz has quit IRC
[14:25:52] *** michaelschuetz has joined #jbosstesting
[14:33:17] <aslak> some mapping error, unrelated to deployment / testing as far as i can tell.. check the jpa spec.. :)
[14:40:44] <rkellerm> Right, it was a missing @ManytoMany
[14:40:49] <rkellerm> Thanks
[14:41:37] <rkellerm> But Now i stuck with : java.lang.ClassNotFoundException: org.postgresql.Driver from BaseClassLoader
[14:59:22] <rkellerm> We suspect, that the driver is not packaged into the test .ear.   Is there a way to keep the teat.ear to look into it?
[15:01:27] *** lfryc has quit IRC
[15:09:22] <rkellerm> I got :    Failed to register driver for: org.postgresql.Driver;
[15:10:18] *** lfryc has joined #jbosstesting
[15:20:17] *** rkellerm has quit IRC
[15:28:09] *** GTobi has quit IRC
[15:36:26] *** awiedenb has quit IRC
[15:41:12] *** theute has quit IRC
[15:44:30] *** kpiwko has quit IRC
[15:45:00] *** theute has joined #jbosstesting
[15:52:42] *** awiedenb has joined #jbosstesting
[15:54:33] *** rruss has joined #jbosstesting
[15:56:29] *** oskutka has quit IRC
[16:18:44] *** jharting has quit IRC
[16:22:03] *** balunasj has joined #jbosstesting
[16:22:05] *** balunasj has joined #jbosstesting
[16:30:49] *** balunasj has quit IRC
[16:47:28] *** lfryc has quit IRC
[17:04:48] *** mgencur has quit IRC
[17:27:49] *** lightguard_jp has joined #jbosstesting
[17:28:24] *** rruss has quit IRC
[17:37:17] *** amitev has quit IRC
[17:39:41] *** rruss has joined #jbosstesting
[17:39:41] *** aslak has quit IRC
[17:39:55] *** rruss has quit IRC
[17:40:21] *** aslak has joined #jbosstesting
[17:40:46] *** rruss has joined #jbosstesting
[17:42:11] *** michaelschuetz has quit IRC
[17:56:22] *** lightguard_jp has quit IRC
[18:12:36] *** theute has quit IRC
[18:20:23] *** pmuir has joined #jbosstesting
[18:30:01] <bobmcw> so, the jars arq creates from my @Deployment.. I end up with a copy in $PWD, and a copy under /tmp
[18:30:14] <bobmcw> and arq attempting to deploy from a 3rd location that is neither of those
[18:30:38] <bobmcw> PWD is the root of my project, and I'm reactoring down to integration-tests/
[18:30:50] <bobmcw> arq writes to ROOT/foo.jar and /tmp/mangly_foo.jar
[18:30:57] <bobmcw> and attempts to deploy ROOT/integration-tests/foo.jar
[18:31:12] <bobmcw> works fine under junit, but not within our rspec stuff, suddenly
[18:31:26] <bobmcw> and I have NFI what I changed to cause this, if anything, or where to look
[18:31:46] <bobmcw> config.getDeploymentExportPath() yields "/tmp"
[18:32:18] <bobmcw> if I run my test from within integration-tests/, it will work, because PWD is the same that arq is deploying from
[18:32:26] <bobmcw> but I still end up with gratuitous jars under /tmp it seems
[18:32:46] <bobmcw> mtime and sha1sum of the jars are identical, seemingly written at the same moment.
[19:07:53] <aslak> bobmcw, DeploymentExportPath is only for debugging the deployment
[19:08:17] <bobmcw> ah, so, that explains my /tmp jars
[19:08:35] <aslak> bobmcw, which container are you using ?
[19:08:40] <bobmcw> AS6 managed
[19:08:43] <aslak> jboss 6 managed ?
[19:09:01] <bobmcw> yah
[19:09:16] <bobmcw> ROOT$ mvn -pl integration-tests/ # fails, jars end up in ROOT/
[19:09:29] <bobmcw> ROOT$ cd integration-tests && mvn # works, jars end up in integration-tests/
[19:09:50] <bobmcw> also, they linger after the tests complete
[19:10:00] <bobmcw> junit integration works fine, only talking about our rspec stuff
[19:10:09] <bobmcw> but obviously we're missing some config or something
[19:10:26] <bobmcw> Caused by: java.io.FileNotFoundException: /Users/bob/torquebox/torquebox/integration-tests/basic-rack.jar (No such file or directory)
[19:10:35] <bobmcw> which is true, since it's up one dir
[19:11:26] <bobmcw> mvn seems to be doing a chdir into integration-tests/
[19:11:27] <aslak> in deploy() we do a new FIle(archive.getName()) and export to that.. that should probably be changed to File.createTempFile()..
[19:11:29] <bobmcw> Dir.pwd == integration-tests/
[19:11:36] <bobmcw> so I dunno what's referencing the one-dir-up
[19:12:00] <bobmcw> aslak: however you create it, should hang onto the same File for deployment
[19:12:06] <bobmcw> instead of maybe reconstructing the path oddly
[19:12:11] <bobmcw> and getting off-by-one?
[19:12:34] <bobmcw> my archive.getName() returns simple names at the moment, like "basic-rack.jar"
[19:12:43] <bobmcw> should/could I give it an absolute path?
[19:12:51] <aslak> bobmcw, no we basically just do the same, new File(archive.getName())
[19:13:12] <aslak> but it could be a surefire vs rspec what ever runner thing..
[19:13:16] <bobmcw> weird, the PWD context must be changing, somehow, between the two
[19:13:24] <aslak> i'm not sure who sets pwd in maven, maven itself or surefire, but
[19:13:37] <bobmcw> from inside rspec Dir.pwd shows the correct value
[19:13:46] <bobmcw> at the point we read the arq.xml config
[19:14:04] <bobmcw> and arq tries to deploy from the "correct" value of what PWD is assumed to be
[19:14:11] <bobmcw> but just it's wrong during jar-scribble-to-disk time
[19:14:26] <bobmcw> and this all worked fine last week
[19:14:29] <bobmcw> so I dunno what I changed :)
[19:14:56] <aslak> well.. it's not arq is it ? hehe
[19:15:09] <bobmcw> no, just hoping you'd know what config/property I'm missing :)
[19:15:13] <aslak> very strange that pwd should change within the same process
[19:15:17] <bobmcw> aye
[19:15:29] <bobmcw> but new File(simpleName) is relative to PWd
[19:15:36] <aslak> yea
[19:15:39] <bobmcw> and that's dodging around somehow
[19:16:24] <aslak> didn't know you could
[19:16:43] <bobmcw> System.setProperty( "user.home", "elsewhere"
[19:16:49] <bobmcw> Dir.chdir() in ruby
[19:16:57] <aslak> right
[19:16:58] <bobmcw> err, user.dir in java
[19:17:07] <aslak> user-home is not pwd ?
[19:17:17] <bobmcw> enabled TRACE in log4j, and see lines like
[19:17:17] <bobmcw> 13:12:19,804 DEBUG [Server] Deploying default, url=file:/Users/bob/torquebox/torquebox/integration-tests/basic-rack.jar
[19:17:19] <bobmcw> which are right
[19:17:25] <bobmcw> but no debug around archive writing :(
[19:17:57] <aslak> brb, dinner..
[19:30:29] <bobmcw> aslak: I'm stumped
[19:30:30] <bobmcw> https://github.com/arquillian/arquillian/blob/master/containers/jbossas-managed-6/src/main/java/org/jboss/arquillian/container/jbossas/managed_6/JBossASLocalContainer.java#L137-142
[19:30:38] <bobmcw> seems like in 5 lines, things change
[19:30:41] <bobmcw> I don't get it
[19:35:55] <bobmcw> btw, big ups on the awesomely clean code
[19:36:36] *** nthngrtr has joined #jbosstesting
[19:36:41] *** nthngrtr has left #jbosstesting
[19:54:32] *** rruss has quit IRC
[19:54:47] *** rruss has joined #jbosstesting
[20:12:30] <aslak> bobmcw, it change after line 5 ?
[20:13:38] <aslak> the only thing that happens is a file.toURL and jmx invoke with that URL to MainDeployer.deploy
[20:16:38] *** ALR has joined #jbosstesting
[20:16:58] <bobmcw> no, within those five lines (137-142)
[20:17:06] <bobmcw> the file is created, written to disk and deployed
[20:17:09] <bobmcw> dunno how it goes wrong
[20:19:08] <aslak> is it deploy or undeploy that fail?
[20:41:42] *** nthngrtr has joined #jbosstesting
[20:41:49] *** nthngrtr has left #jbosstesting
[20:42:37] <ALR> stuartdouglas: Happy Birthday, kiddo.
[20:42:37] <bobmcw> aslak: deploy
[20:42:59] <bobmcw> it's attempting to deploy from the correct location, but the archive.jar has been written to the incorrect location
[20:43:33] <bobmcw> but I don't get how it's scribbling the archive to disk in the wrong place, other than it's my PWD
[20:43:47] <bobmcw> but mvn reactor should (and appears-to-be) chdir'ing correctly
[20:43:53] <bobmcw> hence, confused!
[20:56:40] <aslak> bobmcw, but how can it be write to a different location when it's the target files URL it deploys..
[20:56:58] <bobmcw> ...i don't know... it's spooky
[20:57:03] <aslak> bobmcw, windows again ?
[20:57:06] <aslak> :)
[20:57:09] <bobmcw> no! osx this time!
[20:57:37] <bobmcw> but yah, it works in our other branch
[20:57:43] <bobmcw> so I'm figuring out what I broke
[21:00:29] <bobmcw> hmmm...
[21:00:42] <bobmcw> only diff seems to be if our test-runner forks from the parent maven or not
[21:00:53] <bobmcw> verifying if this might be it
[21:10:45] *** pmuir has quit IRC
[21:13:08] *** balunasj has joined #jbosstesting
[21:22:02] <bobmcw> motherf'er!
[21:22:05] <bobmcw> fork=true solves it
[21:22:25] <bobmcw> somehow without forking off rspec (equiv of surefire forking), the archive locations end up wrong
[21:22:29] <bobmcw> if I fork, all is good
[21:22:38] <bobmcw> aslak: thanks for bearing with me
[21:22:48] <bobmcw> brown bear, black bear, polar bear; whichever you prefer
[21:34:21] <aslak> care bear
[21:34:38] <aslak> but no fork works fine with surefire ?
[21:36:29] <aslak> but what ever pwd is set to, i still don't get it.. how does it manage to get wrong
[21:36:36] *** rruss has quit IRC
[21:59:31] *** maeste has quit IRC
[22:04:59] <ALR> Different ways of defining PWD for Surefire and RSpec maybe?
[22:05:33] <aslak> ALR, sure, but still.. how does this code: https://github.com/arquillian/arquillian/blob/master/containers/jbossas-managed-6/src/main/java/org/jboss/arquillian/container/jbossas/managed_6/JBossASLocalContainer.java#L137-142
[22:05:57] <aslak> manage to write to one file, and try to deploy another in a different dir
[22:06:41] <ALR> The file it writes is not the one it deploys?
[22:06:51] <aslak> yea
[22:07:28] <aslak> ir fails on deploying, since the file is not there, but the file is written to the parent dir of pwd
[22:07:53] <ALR> file.exists() says ?
[22:08:02] <aslak> i donno
[22:08:10] <aslak> it seems like file.toURL is failing
[22:08:56] <ALR> Trace?
[22:09:01] <ALR> I'd need to see it :)
[22:09:14] <aslak> bobmcw has the setup, i don't
[22:10:13] <ALR> Ah OK
[22:10:21] <ALR> I'm going over SHRINKWRAP-140
[22:10:24] <jbossbot> jira [SHRINKWRAP-140] Support loading artifacts from a Maven repository [Open, Major, Karel Piwko] https://issues.jboss.org/browse/SHRINKWRAP-140
[22:12:55] *** maeste has joined #jbosstesting
[22:16:08] <bobmcw> ALR: I'll try to gather up info and attach a jira
[22:16:16] <bobmcw> dunno why the diff with surefire
[22:16:20] <bobmcw> unless surefire is also forking
[22:16:37] <ALR> bobmcw: I wonder about sysprops set by rspec/surefire
[22:16:43] <ALR> And how they play w/ File API?
[22:16:50] <bobmcw> user.dir and Dir.pwd all look "right" from within rspec/ruby
[22:16:56] <bobmcw> dunno wrt File API
[22:17:09] <ALR> Why would those props matter?
[22:17:18] <ALR> If you're specifying the File object on its own?
[22:17:19] <bobmcw> and we're going java (maven) -> ruby (rspec) -> java (arq), so wtf knows
[22:17:25] <ALR> Oh boy.
[22:17:32] <bobmcw> so, I specify a name, arq plays with Files
[22:17:32] *** mgoldmann has quit IRC
[22:17:37] <ALR> I don't know if I'll have the ploygotism required to debug that.
[22:17:47] <ALR> *polyglotism
[22:17:53] <ALR> Which probably isn't a word
[22:17:56] <ALR> But it *sounds* smart
[22:18:09] <bobmcw> I'll poke around, but at least figured out what's up roughly, for now and can work around
[22:18:18] <bobmcw> only not-forking due to freakin' windows 8k cmdline limit
[22:18:19] <ALR> Cool.  Fork 'em.
[22:18:37] <bobmcw> playing with %COMSPEC% now to see if I can't make that bigger
[22:18:44] <ALR> bobmcw: RSpec doesn't have an equiv like Surefire to use a exec JAR?
[22:18:54] <bobmcw> it could, I maintain the rspec-plugin
[22:19:06] <ALR> What a friendly coincidence.
[22:19:10] <bobmcw> ultimately it doesn't need much, since we load classpath stuff from a ruby script anyhow
[22:19:29] <bobmcw> just need jruby.jar on the classpath, is all
[22:27:45] <aslak> ALR, what about 140 ?
[22:32:57] <ALR> aslak: Just that I'm reviewing it
[22:33:02] <ALR> It'd be nice to get this in
[22:33:05] <ALR> Everyone wants it.
[22:33:05] *** jdlee has quit IRC
[22:33:14] <ALR> Right now that module is a 7 minute build
[22:35:01] <aslak> ALR, yea, i know
[22:35:21] <aslak> we need to somehow fix the tests, it kinda tests a bit random artifacts around now..
[22:35:24] *** michaelschuetz has joined #jbosstesting
[22:35:25] <ALR> aslak: Looking to see why.
[22:35:33] <ALR> aslak: If it's resolution this could be a no-go.
[22:37:31] <aslak> it does oth resolve and download..
[22:37:38] <aslak> is it consistent on 7 min?
[22:39:07] <ALR> aslak: Actually my second run was 4.5m
[22:41:01] *** stuartdouglas has quit IRC
[22:47:24] *** stuartdouglas has joined #jbosstesting
[22:52:09] <aslak> ALR, WTF is it doing; http://shrinkwrap.pastebin.com/sgJp3zYT
[22:52:17] <aslak> that's the output of ArtifactDependenciesUnitTestCase
[22:52:38] <aslak> it must be booting maven as well
[22:52:56] <ALR> Right
[22:53:03] <ALR> I asked him if it fired up the Embedded
[22:53:09] <ALR> He said it was just Aether
[22:53:26] <aslak> yea, i know.. but somehow maven is sucked into this
[22:53:48] <ALR> I'm not surprised.
[22:54:16] <ALR> I can't run these from the IDE
[22:54:56] <aslak> or well.. hehe.. it should probably do some filtering in the request
[22:55:04] <ALR> Ah there we go
[22:55:09] <ALR> It got imported as 1.5
[22:55:37] <aslak> those are probably deps from the shrinkwrap artifact, but not compile scope, just what's defined in pom in general
[22:56:27] <ALR> aslak: Weird
[22:56:29] <aslak> plugins and what now
[22:56:33] <ALR> ArtifactDependenciesUnitTestCase takes 4.5s from IDE
[22:56:48] <ALR> And like 90s from Maven
[22:57:31] <ALR> I think because it's building a repo in target/pom-dep-repository
[22:57:38] <ALR> And mvn clean will kill target?
[22:57:54] <ALR> I'm gonna play with these a bit
[23:00:28] <aslak> ha no, the artifact org.jboss.shrinkwrap:shrinkwrap-dependencies-pom-dep:pom:1.0.0 is something that is put in a test-only repo tha tis created/coped, the shrinkwrap artifact that it resolvs has a dep on maven-help-plugin
[23:00:41] <aslak> see target/pom-dep-repository...
[23:05:14] <aslak> hmm.. interesting: http://code.google.com/p/jpa-unit/
[23:05:47] *** jc3 has quit IRC
[23:05:53] <aslak> i think i would prefer just having the dataset as java code, but
[23:08:16] <aslak> ALR, DependencyFilterUnitTestCase is probably a bit more representative
[23:08:55] <ALR> aslak: I've got patches so you can re-run w/out cleaning BTW
[23:08:58] <ALR> It goes much fater
[23:09:00] <ALR> *faster
[23:10:23] <aslak> i've removed the dep on plexus, it's not needed.. and upgraded to athear 1.9
[23:13:01] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 21e3657.. Karel Piwko SHRINKWRAP-140, initial commit
[23:13:01] <jbossbot> jira [SHRINKWRAP-140] Support loading artifacts from a Maven repository [Open, Major, Karel Piwko] https://issues.jboss.org/browse/SHRINKWRAP-140
[23:13:01] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 a9ca96d.. Karel Piwko SHRINKWRAP-140, support for multiple artifacts
[23:13:03] <jbossbot> jira [SHRINKWRAP-140] Support loading artifacts from a Maven repository [Open, Major, Karel Piwko] https://issues.jboss.org/browse/SHRINKWRAP-140
[23:13:03] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 9ae1808.. Karel Piwko SHRINKWRAP-140, added support to load pom.xml
[23:13:03] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 bf6c979.. Karel Piwko SHRINKWRAP-140, add artifact builder...
[23:13:03] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 2f67036.. Karel Piwko SHRINKWRAP-140, allowed remote pom.xml resolution
[23:13:03] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 8757af3.. Karel Piwko SHRINKWRAP-140, support for loading settings.xml
[23:13:03] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 b393376.. Karel Piwko SHRINKWRAP, updated exceptions and logging
[23:13:04] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 5c5044c.. Karel Piwko SHRINKWRAP-140, secured System.getPropety()
[23:13:04] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 6d1b7c6.. Karel Piwko SHRINKWRAP-140, added copyright notices
[23:13:04] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 76f9b70.. Karel Piwko SHRINKWRAP-140, ommiting pom in packages...
[23:13:05] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 a92ddfb.. Karel Piwko SHRINKWRAP-140, ability to ommit artifact version
[23:13:05] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 979848e.. Karel Piwko SHRINKWRAP-140, filters for dependencies
[23:13:06] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 2acb0fc.. Karel Piwko SHRINKWRAP-140, resolving as files and in a batch.
[23:13:06] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 e58eece.. Karel Piwko SHRINKWRAP-140, stacking artifacts for nicer API
[23:13:23] <ALR> aslak: Put your commits into upstream/SHRINKWRAP-140
[23:13:24] <jbossbot> jira [SHRINKWRAP-140] Support loading artifacts from a Maven repository [Open, Major, Karel Piwko] https://issues.jboss.org/browse/SHRINKWRAP-140
[23:13:27] <ALR> We'll all sync in there.
[23:14:25] *** jdlee has joined #jbosstesting
[23:29:13] <ALR> aslak: Need your changes so I can refactor/rename some stuff.
[23:29:18] <ALR> And we should avoid conflicts :)
[23:29:54] <aslak> get some failing tests
[23:30:24] <aslak> PomDependenciesUnitTestCase.testPomRemoteBasedDependencies is Asserting on it's own projects poms hehe
[23:30:39] <aslak> guaranteed failed built with dep changes
[23:30:46] <aslak> :)
[23:30:48] <ALR> aslak: Why don't I see those?
[23:30:53] <ALR> (failures)?
[23:31:07] <aslak> ALR, have you changed the athere v?
[23:31:12] <ALR> aslak: No.
[23:31:18] <aslak> there you go
[23:31:29] <ALR> aslak: Who says newer is better? :)
[23:31:59] <ALR> Though asserting on your own project's POM looks a bit iffy
[23:32:03] <aslak> the test are verifying against dep trees stored on file under resources/dependency-tree
[23:32:11] <ALR> We also have some trees in src/test/resources referencing ShrinkWrap
[23:32:19] <aslak> and arq
[23:32:37] <ALR> Yeah, that should be changed to stuff in Central only.
[23:32:47] <ALR> For once we go to Central, ARQ and SW alphas won't be there.
[23:33:31] <aslak> i think the module should have it's own full defined repo in test resources, where we know the deps and control them
[23:34:38] <ALR> Agreeeeeeed.
[23:34:53] <ALR> And it doesn't need to be *that* full.
[23:34:58] <ALR> Just enough to verify some stuff.
[23:35:11] <ALR> These trees are really involved.
[23:35:16] <ALR> The tests can be simpler
[23:35:24] <aslak> hehe, no full was maybe the wrong wording.. we need a local repo that comes with controlled artifacts
[23:35:26] <ALR> And controlled by our own repo we've got in Git
[23:35:40] <ALR> aslak: I understood whatcha meant.
[23:35:41] <ALR> :)
[23:35:49] <aslak> :)
[23:36:39] <aslak> there are some tests like readon up repo info from settings.xm letc, but i don't think we really need to resolve from them, but rather verify they are part of the repo resolve list
[23:37:03] *** wolfc has quit IRC
[23:37:10] <ALR> aslak: I'll get these comments back to Kawel in his pull request
[23:37:19] <aslak> yea
[23:37:30] <ALR> aslak: Go ahead and commit the breaking Aether update.
[23:37:33] <ALR> He'll fix it :)
[23:37:42] <aslak> hehe
[23:37:46] <aslak> to master?
[23:37:51] <ALR> No
[23:37:58] <ALR> SHRINKWRAP-140
[23:37:58] <jbossbot> jira [SHRINKWRAP-140] Support loading artifacts from a Maven repository [Open, Major, Karel Piwko] https://issues.jboss.org/browse/SHRINKWRAP-140
[23:38:06] <ALR> Or actually.
[23:38:12] <ALR> aslakknutsen/SHRINKWRAP-140
[23:38:13] <jbossbot> jira [SHRINKWRAP-140] Support loading artifacts from a Maven repository [Open, Major, Karel Piwko] https://issues.jboss.org/browse/SHRINKWRAP-140
[23:38:22] <ALR> And I'll cherrypick it.
[23:38:50] *** rruss has joined #jbosstesting
[23:39:12] <aslak> sure
[23:40:12] *** balunasj has quit IRC
[23:45:02] *** jeand has quit IRC
[23:46:10] *** maeste has quit IRC
[23:47:10] <aslak> ALR, https://github.com/aslakknutsen/shrinkwrap/commits/SHRINKWRAP-140
[23:47:10] <jbossbot> jira [SHRINKWRAP-140] Support loading artifacts from a Maven repository [Open, Major, Karel Piwko] https://issues.jboss.org/browse/SHRINKWRAP-140
[23:48:15] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 d1d950d.. Aslak Knutsen SHRINKWRAP-140 Update Aether v to 1.8 and Maven v to 3.0.1
[23:48:16] <jbossbot> jira [SHRINKWRAP-140] Support loading artifacts from a Maven repository [Open, Major, Karel Piwko] https://issues.jboss.org/browse/SHRINKWRAP-140
[23:48:17] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 URL: http://github.com/shrinkwrap/shrinkwrap/compare/2fa9125...d1d950d
[23:49:10] *** lightguard_jp has joined #jbosstesting
[23:54:07] *** lightguard_jp has quit IRC
[23:55:32] *** lightguard_jp has joined #jbosstesting
[23:57:20] *** lightguard_jp has quit IRC
[23:57:42] *** lightguard_jp has joined #jbosstesting





top