[00:17:01] *** ALR has joined #jbosstesting
[00:21:29] *** ALR has quit IRC
[00:34:11] *** maschmid has quit IRC
[00:37:35] *** bleathem is now known as bleathem_busy
[01:21:53] *** lightguard_jp is now known as lightguard_jp_aw
[01:31:03] *** aaronwalker has joined #jbosstesting
[01:41:17] *** lightguard_jp_aw has quit IRC
[02:10:42] *** rruss has quit IRC
[02:16:02] *** mgoldmann has quit IRC
[02:28:00] *** johnament has joined #jbosstesting
[02:43:38] *** jamezp is now known as jamezp_afk
[03:00:28] *** ianbrandt has quit IRC
[03:14:41] *** ldimaggi has joined #jbosstesting
[03:17:52] *** johnament has quit IRC
[03:37:56] *** bgeorges has quit IRC
[04:27:03] *** aaronwalker has quit IRC
[04:57:48] *** aaronwalker has joined #jbosstesting
[05:01:51] *** bgeorges has joined #jbosstesting
[05:45:05] *** lightguard_jp has joined #jbosstesting
[06:03:59] *** echelog-2 has joined #jbosstesting
[06:10:09] *** ldimaggi has quit IRC
[07:32:12] *** echelog-2 has joined #jbosstesting
[07:48:48] *** aaronwalker has quit IRC
[08:13:23] *** vnvarsete has joined #jbosstesting
[08:40:47] *** ge0ffrey has joined #jbosstesting
[09:01:35] *** aaronwalker has joined #jbosstesting
[09:03:55] *** mgoldmann has joined #jbosstesting
[09:06:40] *** alesj has quit IRC
[09:08:45] *** lfryc has joined #jbosstesting
[09:15:30] *** alesj has joined #jbosstesting
[09:27:45] *** lightguard_jp has quit IRC
[09:28:13] *** kpiwko has joined #jbosstesting
[09:33:47] *** maschmid has joined #jbosstesting
[09:44:51] *** maeste has joined #jbosstesting
[11:09:48] *** aaronwalker has quit IRC
[12:18:03] *** bgeorges has quit IRC
[12:59:34] <jose_freitas> kpiwko: ping
[13:00:05] <kpiwko> jose_freitas: pong
[13:00:28] <jose_freitas> how you doing kpiwko? were you on vacation?
[13:02:05] <kpiwko> jose_freitas: I'm fine, thanks! Yep, I was on a vacation. I'm just going through the mailbox, it will take some time :)
[13:02:58] <jose_freitas> hehehe
[13:03:20] <jose_freitas> I did unify those methods that load pom and settings
[13:03:29] <jose_freitas> in one method that receives a string as arg
[13:04:33] 
[13:06:01] <kpiwko> jose_freitas: that's awesome! you mean to add a pom.xml into jar created by Shrinkwrap?
[13:06:33] <jose_freitas> no, to load dependencies from a pom shipped inside a jar
[13:06:59] <kpiwko> ok, I see
[13:07:43] <jose_freitas> do you remember a method I wrote: includeDependenciesFromPomInClassPath ?
[13:08:03] <kpiwko> jose_freitas: yes, I do
[13:08:04] <jose_freitas> it included based on classpath but not if it was inside a jar.
[13:08:17] <jose_freitas> now it read stream from a jar
[13:08:23] <jose_freitas> if you want to
[13:09:18] <jose_freitas> got it?
[13:09:52] <kpiwko> I used test/util/JarGenerator to create a jar using Shrinkwrap...I guess you can do the same to generate your mock jar file...then place the resulting jar into test/resources/artifacts
[13:10:42] <jose_freitas> hm, and that resources/artifacts are all loaded in classpath?
[13:10:49] <jose_freitas> because I put a jar there
[13:10:59] <jose_freitas> and it's not finding
[13:11:17] <jose_freitas> basically I did what you suggested, but I created jar manually and put there
[13:12:22] <jose_freitas> but it seems that those jar are not loaded to classpath, they are used for maven to resolve its classpath
[13:12:23] <kpiwko> I'm a bit lost...you want to resolve the jar file from the test execution class path?
[13:12:53] <jose_freitas> yes
[13:13:40] <kpiwko> hmm, the most straightforward way will be to have this jar as test scoped dependency
[13:14:41] <kpiwko> maybe you can create a new surefire execution and add the jar into additionalClasspathElement
[13:14:44] <kpiwko> this should work
[13:15:30] <kpiwko> and then include only your test case into that execution...so it won't interfere with other tests
[13:19:07] <jose_freitas> brb
[13:19:09] <jose_freitas> sorry
[13:23:24] <kpiwko> jose_freitas: np, approach I suggested should work...here's the configuration http://maven.apache.org/plugins/maven-surefire-plugin/examples/configuring-classpath.html
[13:26:06] *** kevinpollet_ has joined #jbosstesting
[13:42:24] *** oskutka has joined #jbosstesting
[14:02:07] *** kevinpollet_ has quit IRC
[14:07:44] *** maeste has quit IRC
[14:40:17] *** OndraZizka has quit IRC
[14:40:49] *** OndraZizka has joined #jbosstesting
[14:50:28] *** vnvarsete has quit IRC
[14:58:31] <jose_freitas> thanks kpiwko
[14:58:35] <jose_freitas> I'll try it now
[14:58:46] <jose_freitas> I was called for a urgency metting
[14:58:48] <jose_freitas> meeting
[14:59:14] <kpiwko> np jose
[15:01:18] *** rruss has joined #jbosstesting
[15:12:37] *** ldimaggi has joined #jbosstesting
[15:15:32] *** rruss has quit IRC
[15:24:20] <jose_freitas> kpiwko: this plugin don't give any error message when it doesn't find the additionalElement
[15:25:30] <jose_freitas> do you know perchance if is there a conf for that?
[15:26:03] <kpiwko> jose_freitas: you can use enforcer plugin to check file exists
[15:26:33] <jose_freitas> hmm
[15:26:37] <jose_freitas> right, I'll do that
[15:27:15] <kpiwko> jose_freitas: however, if I read the sample correctly, it should be enough to add directory only and it will append all the files included there
[15:33:10] <jose_freitas> https://gist.github.com/1170665
[15:33:24] <jose_freitas> added a var name with the location of the file
[15:33:36] <jose_freitas> and added conf to surefire and an enforcer configuration
[15:33:38] <jose_freitas> it finds the file
[15:33:54] <jose_freitas> and I 'suppose' it's adding the jar to classpath
[15:34:10] *** oskutka has quit IRC
[15:36:04] <jose_freitas> it's working
[15:36:05] <jose_freitas> :)
[15:37:10] <jose_freitas> thanks kpiwko
[15:37:47] <jose_freitas> do you think it's necessary to keep enforcer plugin?
[15:37:55] <kpiwko> it won't hurt :)
[15:38:16] <jose_freitas> ok, great
[15:38:25] <jose_freitas> I'll commit then and you can take a look
[15:38:33] <kpiwko> sure
[15:38:48] <kpiwko> don't you think that it would make sense to split the executions?
[15:39:14] <kpiwko> I mean one execution with the jar on classpath, one without?
[15:39:37] <kpiwko> on having it on cp all the time won't influence other tests?
[15:45:19] *** rachmatowicz has quit IRC
[15:45:22] *** rachmatowicz_ has joined #jbosstesting
[15:45:44] *** rachmatowicz has joined #jbosstesting
[15:52:04] <jose_freitas> ok, pull requested
[15:52:46] <jose_freitas> kpiwko: the jar added have no code, just a pom and a settings
[15:53:05] <jose_freitas> 3kb jar
[15:53:38] <jose_freitas> I don't see how it could interfere on other tests
[15:54:57] <kpiwko> jose_freitas: thanks, I'll check the code
[15:56:57] <jose_freitas> hm
[15:57:17] <jose_freitas> just checked that I have two commits that I thought it was already merged
[15:57:39] <jose_freitas> those with SHRINKWRAP-288 on name
[15:57:40] 
[16:02:59] *** lfryc has quit IRC
[16:03:16] *** maeste has joined #jbosstesting
[16:06:22] <jose_freitas> kpiwko: I use jboss community formatter code for eclipse
[16:07:10] <jose_freitas> it changed too many lines on mavenbuilderimpl, even after I setup to change just editted lines.
[16:07:24] *** lfryc has joined #jbosstesting
[16:07:38] <jose_freitas> this was a headache on my last pull request.
[16:07:52] <jose_freitas> we should consider unify our code formatters
[16:09:00] <kpiwko> yep, definitely
[16:09:25] <kpiwko> there is likely a jira for shrinkwrap to use new jboss as formatter
[16:10:19] <kpiwko> however it is extremely difficult to track changes in your request
[16:10:35] <kpiwko> because of the formatting
[16:10:41] <jose_freitas> yes
[16:10:52] <jose_freitas> I'm trying to revert it
[16:11:04] <kpiwko> you can use old formatter
[16:11:12] <jose_freitas> tryed
[16:11:19] <jose_freitas> but no success
[16:14:27] <kpiwko> I'm not sure if there's the old formatter somewhere
[16:18:26] <jose_freitas> kpiwko
[16:18:40] <jose_freitas> would you look at it now?
[16:18:48] <jose_freitas> I changed the file
[16:18:51] <kpiwko> jose_freitas: sure
[16:18:52] <jose_freitas> copy and paste old filre
[16:18:59] <jose_freitas> and added the changes manually
[16:19:19] <jose_freitas> it's easier to track now
[16:31:23] <kpiwko> jose_freitas: can you help me recall what was the motivation of not having a path type qualifier? like classpath:org/foo/bar.xml ?
[16:32:20] <kpiwko> jose_freitas: what happens if user wants to use a resources from cp but have the same name in filesystem? he won't be able to do so, according to the impl
[16:32:34] <jose_freitas> there wasn't a decision on that. so (as I needed the feature) I implemented the way I found more intuite
[16:32:49] <jose_freitas> no
[16:32:56] <jose_freitas> it's going to take locally first
[16:33:40] <jose_freitas> it's true that that case would be a problem
[16:34:49] <jose_freitas> but I don't know, I really think it's more usual to write a normal string.
[16:34:58] <jose_freitas> what we could do, is accept both
[16:35:04] <jose_freitas> wdyt?
[16:35:22] <jose_freitas> we could look for a qualifier first
[16:35:26] <jose_freitas> and in the absence of it
[16:35:35] <jose_freitas> we let the flow as it is
[16:35:50] <kpiwko> actually I thought that without a qualifier it will check for (file:)
[16:35:56] <kpiwko> so we keep current behaviour
[16:36:18] <kpiwko> and by qualifying we add a new functionality
[16:36:27] <jose_freitas> take a look at ArtifactDependenciesUnitTestCase
[16:36:41] <jose_freitas> there're two more test methods
[16:36:49] <jose_freitas> one that look at a file in classpath
[16:36:57] <kpiwko> I've seen that
[16:37:03] <jose_freitas> and one that load a pom as a stream (cause it's inside a jar)
[16:37:31] <kpiwko> and the only way how to see it loads it from cp is by guessing org/jboss/foo/bar is likely a package
[16:37:44] <kpiwko> which is not really intuitive behaviour
[16:38:11] <kpiwko> imho this makes reading test case very difficult for other people
[16:38:43] <jose_freitas> hm
[16:38:50] <kpiwko> same method, same parameters, different behavior based on something which is even specified externally
[16:39:51] <jose_freitas> uh hm
[16:40:29] <jose_freitas> btw, I use this package approach to avoid conflicts between files. like if I have a pom on the root of a project, two projects shipping a pom at root will be conflicting
[16:40:52] <jose_freitas> but np, you're the boss :)
[16:40:56] <jose_freitas> I can change it
[16:41:07] <jose_freitas> so, file: for locally, classpath: for inside jar?
[16:41:28] <jose_freitas> or do we use two qualifiers?  jar: and classpath?
[16:41:56] <jose_freitas> there's no jar: though
[16:42:01] <jose_freitas> as expression
[16:42:05] <jose_freitas> afaik
[16:43:39] <jose_freitas> I mean, when in classpath there're two possibilities: a normal resource and a stream inside a jar.
[16:44:01] <kpiwko> jose_freitas: good point
[16:44:46] <kpiwko> jose_freitas: afaik I've seen things like jar:foo.jar!bla/pom.xml but I find this too heavyweight
[16:45:11] <jose_freitas> hm nice to know
[16:46:37] <kpiwko> let me check how this is done in Spring...if you do it the same way, I guess it will be intuitive for many people out there
[16:46:48] <jose_freitas> good point
[16:49:16] <kpiwko> http://static.springsource.org/spring/docs/3.0.6.RELEASE/spring-framework-reference/htmlsingle/spring-framework-reference.html#resources, table 4.1
[16:49:32] <kpiwko> they have file: and classpath: with no qualifier it is context type dependent
[16:49:54] <kpiwko> for use default context type is file:
[16:50:10] <kpiwko> or I think it should be
[16:50:48] <jose_freitas> btw, we load resources from classpath at base shrinkwrap too
[16:50:58] <jose_freitas> and it uses normal string
[16:51:00] <jose_freitas> without qualifier
[16:51:04] <jose_freitas> brb
[17:13:56] *** ALR has joined #jbosstesting
[17:18:21] *** dabloem has joined #jbosstesting
[17:19:57] *** alesj has quit IRC
[17:22:37] *** OndrejZizka has quit IRC
[17:23:18] *** vtunka has quit IRC
[17:28:43] *** bleathem_busy is now known as bleathem
[17:31:19] *** jamezp_afk is now known as jamezp
[17:31:31] <jose_freitas> kpiwko: so, when accessing classpath (file or stream) we're going to use classpath:com/myapp/pom.xml and when accessing file locally no qualifier
[17:32:05] <jose_freitas> is that it?
[17:32:46] <jose_freitas> we should consider .addAsResource() to work that way too
[17:33:16] <kpiwko> jose_freitas: almost, for accessing a file locally there should be file: as well, but file: is not mandatory
[17:34:49] *** ALR has quit IRC
[17:35:46] <jose_freitas> ok
[17:35:57] <jose_freitas> I'll try to do that today
[17:36:14] <jose_freitas> we should write a documentation on it too
[17:37:15] <kpiwko> jose_freitas: isn't the addAsResource a bit different use case? it claims that it loads resources from cp
[17:38:30] <jose_freitas> oh yes
[17:38:30] <jose_freitas> indeed
[17:39:10] <kpiwko> jose_freitas: resolver using the same scheme as SW should have String for cp resources and File for local files
[17:39:53] <kpiwko> however, I'm still convinced Resolver should go a protocol qualifier way
[17:40:12] *** jharting has quit IRC
[17:40:14] <kpiwko> because you can for example specify settings.xml by a system property
[17:40:31] <kpiwko> and there file: and classpath: will become really handy
[17:40:43] <jose_freitas> okidoki
[17:41:56] *** ALR has joined #jbosstesting
[17:44:26] *** maschmid has quit IRC
[17:44:59] *** mgoldmann has quit IRC
[17:52:09] *** kpiwko has quit IRC
[18:16:08] *** maeste has quit IRC
[18:18:55] *** rruss has joined #jbosstesting
[18:23:55] *** bleathem is now known as bleathem_afk
[18:31:31] *** maeste has joined #jbosstesting
[18:41:08] *** ge0ffrey has quit IRC
[18:56:25] *** rbattenfeld has joined #jbosstesting
[18:56:30] *** ianbrandt has joined #jbosstesting
[18:57:14] *** ge0ffrey has joined #jbosstesting
[19:03:13] *** dabloem has quit IRC
[19:04:11] *** dabloem has joined #jbosstesting
[19:08:09] *** OndrejZizka has joined #jbosstesting
[19:10:11] <rbattenfeld> ALR: Hi Andrew, shall I wait with rebasing remote/upstream? I am ready with SHRINKDESK-74 but I can wait
[19:10:14] *** kevinpollet has joined #jbosstesting
[19:10:34] *** bleathem_afk is now known as bleathem
[19:12:56] <ALR> rbattenfeld: Hiya
[19:13:11] <ALR> rbattenfeld: I just pushed some stuff to upstream/1.2.0-X
[19:13:18] <ALR> And now I'm working on SPI stuff in master
[19:13:24] <ALR> Which 1.2.0-X will go atop
[19:13:35] <ALR> Lemme see what SD-74 is all about
[19:13:54] <ALR> rbattenfeld: Ah yes
[19:14:06] <ALR> You can safely do SD-74 without too much conflict on the other stuff
[19:14:14] <ALR> I'll rebase everything as the commits trickle in.
[19:14:32] <ALR> Recommend you do SD-74 rebased on the current upstream/1.2.0-X, and all should be fine.
[19:15:03] <rbattenfeld> ALR: Yes, I will do it
[19:15:09] <ALR> Cool
[19:15:14] <ALR> For instance I just pushed SD-75
[19:15:31] <rbattenfeld> ALR: super!
[19:15:39] <ALR> Aside from static test coverage (which is lacking), I'd say we're looking really really good
[19:15:56] <ALR> I'll ask Davide to look into pumping up the test coverage.
[19:16:27] <rbattenfeld> ALR: YES! I like it too:-)
[19:17:10] <rbattenfeld> ALR: you mean generating static tests?
[19:17:25] <ALR> rbattenfeld: Generating?  Nope.  Writing by hand?  Yup :)
[19:17:32] *** ge0ffrey has quit IRC
[19:18:37] <rbattenfeld> ALR: yes, the static tests are very important but are time consuming. There is no way to get rid of these tests
[19:19:01] <ALR> rbattenfeld: That's fine.  We can do an 1.2.0-alpha-1 without too much coverage there.
[19:19:09] <ALR> And then switch focus to beefing those up.
[19:19:29] <ALR> Also let the community start to pull in the spec Descriptors and kick their tires, get some feedback.
[19:19:53] <ALR> The next 1.1.x release will be a candidate for freezing the SPI; there's just one issue left there to address.
[19:20:01] <ALR> And I'm looking at that now.
[19:20:45] <rbattenfeld> ALR: great! Are there demands for more descriptors?
[19:21:02] <ALR> rbattenfeld: That I'm aware of at the moment, not really.
[19:21:16] <ALR> IronJacamar, but Jesper wants to provide that one.
[19:21:26] <ALR> And probably some other JBoss projectss.
[19:21:43] <ALR> *projects
[19:21:54] <ALR> If they can consume "gen" and use it that'd be cool.
[19:21:59] <ALR> But let's limit focus for now.
[19:22:18] <rbattenfeld> ALR: Yes!
[19:23:56] <ALR> :D
[19:24:04] <ALR> rbattenfeld: So go for it.
[19:24:10] <ALR> BTW, I am very, very bad w/ XSL
[19:25:30] <rbattenfeld> ALR: you can not be worser than I am... but as professionals we know what has to come out!
[19:25:57] <ALR> Hehe
[19:26:20] <ALR> Simply removing the numbers from the Descriptor class names took me an embarrassing amount of time.
[19:27:03] <rbattenfeld> ALR: sorry for that
[19:28:00] <rbattenfeld> ALR: but I am happy that we work together
[19:28:05] <ALR> Don't apologize!
[19:28:24] <ALR> The generation is saving us a serious amount of manual time and bugs by working off the schema.
[19:28:44] <ALR> You'd be surprised how much time we spent on jboss-metadata, a similar object model for spec metadata.
[19:29:05] <ALR> Course jboss-metadata mixes in other concerns.  Like merging, overriding, and even adding business logic where it shouldn't be.
[19:29:13] <rbattenfeld> ALR: I can image that
[19:29:15] <ALR> You're doing great stuff.
[19:29:36] <rbattenfeld> ALR: thanks!
[19:30:36] <rbattenfeld> ALR: I have to leave for now. Probably see you later or tomorrow.
[19:31:41] <ALR> rbattenfeld: Great, have a nice night.
[19:39:55] <rbattenfeld> ALR: the same to you
[19:40:01] *** rbattenfeld has left #jbosstesting
[19:47:15] *** bobmcw has quit IRC
[20:02:21] *** kevinpollet has quit IRC
[20:09:51] *** lightguard_jp has joined #jbosstesting
[20:21:41] *** mgoldmann has joined #jbosstesting
[20:40:00] *** kevinpollet has joined #jbosstesting
[20:47:51] <jose_freitas> hey ALR: what about sw-maven-resolver api review? did you guys already make it?
[20:48:25] <jose_freitas> do you make a review? or do a review?
[20:51:09] *** rruss has quit IRC
[21:04:50] *** ldimaggi has quit IRC
[21:04:57] *** rachmatowicz has quit IRC
[21:13:27] *** jamezp is now known as jamezp_afk
[21:19:37] *** ldimaggi has joined #jbosstesting
[21:33:25] *** maeste has quit IRC
[21:39:12] *** lfryc has quit IRC
[21:41:25] <ALR> jose_freitas: Yep, we haven't reviewed that
[21:41:35] <ALR> For now I'm cleaning/prepping SD for releases
[21:41:59] <ALR> So likely candidates for that review: jose_freitas, aslak, me, kpiwko
[21:42:03] <ALR> Anyone else
[21:42:03] <ALR> ?
[21:44:48] <jose_freitas> kpwiko mentioned samuel (I guess)
[21:46:22] <jose_freitas> Samuel santos
[21:46:24] <jose_freitas> just checked
[21:49:31] <ALR> Ah OK.
[21:49:41] <ALR> Allright, I'll mail all to see when we can agree on some time.
[21:51:21] <jose_freitas> okay
[22:04:09] *** mgoldmann has quit IRC
[22:05:06] <jose_freitas> ALR: do you known when we can find aslak?
[22:05:21] <ALR> I believe he's out through the end of the week.
[22:05:31] <ALR> jose_freitas: ^
[22:05:40] <jose_freitas> hmm
[22:05:44] <ALR> jose_freitas: Anything I can help with?
[22:08:02] <jose_freitas> well, I've been working on jsfunit for a while, and besides it's not working yet on jbossas7, I'd like to release a new beta version.
[22:08:10] <jose_freitas> a lot of people waiting for that
[22:08:12] <jose_freitas> and since the actual released version uses Arq-Alpha-5
[22:08:29] <jose_freitas> people cannot migrate to use the new api
[22:08:32] <jose_freitas> spi
[22:09:14] <jose_freitas> actually the version working in seam-faces tests for eaxmple, it's already a snapshot
[22:10:27] <jose_freitas> I wanted to get it working on as7 before releasing it. but perhaps there's no need for waiting this.
[22:11:45] <jose_freitas> ALR ^
[22:12:13] <ALR> jose_freitas: Yes, I know lots of folks are waiting for JSFUnit
[22:12:15] <ALR> On AS7
[22:12:30] <ALR> jose_freitas: So what's now blocking forward progress?
[22:12:44] <jose_freitas> on as7? or on release process?
[22:12:57] <ALR> The release process I suppose.
[22:13:10] <ALR> You want to verify it's working on AS7 first?
[22:13:53] <jose_freitas> at first yes, but people convinced me that it'd be useful to release as it is now, since it's working with newest version of arquillian and jbossas6
[22:14:13] <ALR> jose_freitas: IMO your job is easier the smaller you scope your releases.
[22:14:15] <jose_freitas> and then when it works on AS7, another version
[22:14:19] <ALR> Exactly
[22:14:30] <jose_freitas> ok
[22:15:02] <ALR> jose_freitas: Who physically performs that release?
[22:15:07] <jose_freitas> stan
[22:15:11] <jose_freitas> maybe aslak
[22:15:14] <ALR> Yep.
[22:15:18] <jose_freitas> that's why I was trying to reach him
[22:15:22] <ALR> I'd have guessed Stan.
[22:15:32] <jose_freitas> stan for sure
[22:15:38] <jose_freitas> but maybe aslak can do it too
[22:15:51] *** dabloem has quit IRC
[22:16:00] <ALR> Where's the repo?
[22:16:11] <jose_freitas> aslak gitfied it
[22:16:26] <jose_freitas> https://github.com/joserodolfofreitas/jsfunit/network
[22:16:45] <jose_freitas> but I guess that the release build is linked to svn repo
[22:16:50] <ALR> jose_freitas: No Authoritative Repo?
[22:16:57] <ALR> Just yours and Aslak's?
[22:17:00] <jose_freitas> yes
[22:17:07] <ALR> OK, this needs some admin love.
[22:17:12] <jose_freitas> oh yes
[22:17:17] <jose_freitas> :)
[22:17:24] <jose_freitas> aslak moved it from subversion
[22:17:26] <ALR> Is Stan now unreachable?
[22:17:34] <jose_freitas> I suppose so
[22:17:40] <ALR> How long have you been trying?
[22:17:59] <jose_freitas> aslak tried some times
[22:18:08] <jose_freitas> I never tried to reach him personally
[22:18:26] <ALR> OK, so you left off with Aslak and the intent was for him to release it?
[22:18:34] <jose_freitas> yes
[22:18:49] <ALR> Are there other associated projects/repos?
[22:18:57] <jose_freitas> no
[22:19:07] <jose_freitas> all projects are on this same repo tree
[22:19:16] <jose_freitas> https://github.com/joserodolfofreitas/jsfunit
[22:19:20] <ALR> Hmm.  Trying to determine where would be an appropriate GitHub "organization" nuder which to store this.
[22:19:41] *** jamezp_afk is now known as jamezp
[22:20:51] *** rruss has joined #jbosstesting
[22:20:51] <jose_freitas> hm
[22:20:53] <ALR> "arquillian" doesn't quite fit.
[22:20:56] <jose_freitas> nope
[22:21:05] <ALR> Let's talk about contribution.
[22:21:11] <ALR> Looks like Stan last committed here in march?
[22:21:20] <ALR> Aslak's done some, and recently it's mostly you?
[22:21:20] <jose_freitas> may
[22:21:24] <jose_freitas> yes
[22:21:40] <ALR> jose_freitas: Where in May? https://github.com/joserodolfofreitas/jsfunit/commits/master
[22:23:01] <ALR> jose_freitas: PM me your preferred email?
[22:23:49] <ALR> jose_freitas: Hehe, I see.
[22:23:59] <ALR> So the two forks have diverged.
[22:24:09] <jose_freitas> not too much I'd say
[22:24:11] <ALR> We need to get those in line to a central authoritative repo first.
[22:24:14] <jose_freitas> looking at the changes
[22:24:26] <ALR> No, it doesn't look like much, but still we need only one upstream.
[22:24:26] <jose_freitas> indeed
[22:25:14] <jose_freitas> yes
[22:25:51] <jose_freitas> so, I pull request to aslak fork
[22:25:58] <jose_freitas> and then we can make it the upstream
[22:26:14] <lightguard_jp> Drat, aslak is gone
[22:26:15] <jose_freitas> under jsfunit organization maybe
[22:27:09] <jose_freitas> there're other projects that we could put it in there, like a seam-forge pluginn that I plan to do e.g.
[22:28:13] <lightguard_jp> I imagine stuartdouglas is still asleep
[22:28:16] <ALR> jose_freitas: Mail sent.
[22:28:21] <ALR> lightguard_jp: What can I do ya for?
[22:28:42] <lightguard_jp> arquillian-weld-ee-embedded question
[22:28:59] <ALR> jose_freitas: If we don't hear back with some plan, I'll make a new org, manage the pull requests, massage and update the POM to use Git, and do the release.
[22:29:10] <lightguard_jp> ALR: not sure how familiar you are with it and how it works.
[22:29:19] <ALR> lightguard_jp: Technical or project management?
[22:29:29] <jose_freitas> ALR: awesome!
[22:29:31] <jose_freitas> thanks
[22:29:32] <lightguard_jp> ALR: technical
[22:29:41] <ALR> lightguard_jp: Not intimately familiar, no.
[22:30:01] <ALR> Only used it on an example once or twice before.
[22:30:40] <lightguard_jp> ALR: I think what I need to know is if it's running as if it were in an EE server or similiar to SE mode. I'm getting a context not active issue in a test in Seam Faces.
[22:31:01] <lightguard_jp> My assumption is it's essentially running in SE mode which doesn't allow for conversations
[22:31:30] <ALR> Yeah, Conversation scope bound to using JSF, right?
[22:32:18] <lightguard_jp> Unfortunately.
[22:40:45] <jose_freitas> ALR: weird that a rebase from aslak for, says that everything is up to date
[22:40:51] <jose_freitas> fork*
[22:41:30] <ALR> jose_freitas: Let me see what I can do
[22:42:01] <jose_freitas> (I normally rebase, so I felt weird that the branchs diverged
[22:42:05] <jose_freitas> )
[22:42:20] <jose_freitas> branchs => forks
[22:42:33] <jose_freitas> anyway, thanks for helping with this
[22:42:56] <jose_freitas> I think there'll be a lot of people happy with this
[22:43:28] <jose_freitas> happy people
[22:43:36] <ALR> Sure.
[22:43:50] <ALR> We'll just make sure I don't step on anyone's project in the meantime. :)
[22:45:52] <jose_freitas> :)
[22:54:47] <ALR> jose_freitas: Some rebase conflicts, working them
[22:56:02] <ALR> jose_freitas: Resolve this? https://gist.github.com/1171903
[22:56:28] <jose_freitas> don't need jetty conf
[22:58:58] <jose_freitas> hm, syncronizing shows a lot of conflicts
[23:03:40] <jose_freitas> want me to merge files?
[23:04:09] <jose_freitas> don't know if the commit history would show those last stan commits
[23:10:16] <ALR> jose_freitas: I wouldn't merge, I'd rebase if you can.
[23:10:23] <ALR> Basically:
[23:10:28] <ALR> Checkout your stuff.
[23:10:32] <ALR> rebase aslak
[23:10:38] <ALR> And quell all conflicts.
[23:16:51] *** ldimaggi has quit IRC
[23:25:47] *** kevinpollet has quit IRC
[23:25:53] <lightguard_jp> jose_freitas: just out of curiosity, why are you rebasing all the time instead of merging?
[23:29:48] <jose_freitas> lightguard_jp: https://sites.google.com/a/insoshi.com/insoshi-guides/Git-Guides/merge-vs-rebase
[23:30:01] <jose_freitas> I do a rebase and wait if rebase tells me if I have to merge something
[23:30:21] <jose_freitas> weirdly, my rebase was saying that nothing changed
[23:30:30] <jose_freitas> I have to hard reset to HEAD
[23:30:35] <jose_freitas> so rebase worked
[23:32:53] <lightguard_jp> eh.
[23:32:55] <lightguard_jp> okay
[23:33:38] <jose_freitas> what do you normally do
[23:33:41] <jose_freitas> ?
[23:33:43] <jose_freitas> merge?
[23:34:29] <lightguard_jp> Yeah
[23:34:34] <lightguard_jp> If I'm not sure then I do a log first
[23:34:47] <lightguard_jp> to see how far I'm behind.
[23:35:26] <lightguard_jp> Of course if I'm working on a branch then I'll merge from the remote to the branch I branched from
[23:35:43] <lightguard_jp> Then I'll rebase my working branch on top of the branch that's now up to date.
[23:35:47] <lightguard_jp> If that makes sense :)
[23:42:36] <jose_freitas> hm





top