[00:07:58] *** alesj has joined #jbosstesting
[00:25:21] *** aaronwalker has quit IRC
[00:25:59] *** alesj has quit IRC
[02:17:38] *** rachmatowicz_ has quit IRC
[02:31:09] *** rachmatowicz_ has joined #jbosstesting
[03:07:08] *** ldimaggi has joined #jbosstesting
[03:22:33] *** bobmcw has joined #jbosstesting
[05:29:22] *** bleathem has joined #jbosstesting
[05:32:34] *** ldimaggi has quit IRC
[06:01:46] *** rruss has joined #jbosstesting
[06:13:56] *** aaronwalker has joined #jbosstesting
[06:32:48] *** bgeorges has joined #jbosstesting
[07:14:18] *** aaronwalker has quit IRC
[08:11:10] *** jhuska has joined #jbosstesting
[08:18:15] *** jbott has joined #jbosstesting
[08:25:35] *** mgoldmann has joined #jbosstesting
[08:27:24] *** kpiwko has joined #jbosstesting
[08:32:59] *** ge0ffrey has joined #jbosstesting
[08:43:20] *** bleathem has quit IRC
[08:54:16] *** vnvarsete has joined #jbosstesting
[08:57:06] *** oskutka has joined #jbosstesting
[09:03:09] *** maschmid has joined #jbosstesting
[09:21:04] *** lfryc has joined #jbosstesting
[09:25:26] *** aaronwalker has joined #jbosstesting
[09:34:35] *** maeste has joined #jbosstesting
[09:49:16] *** rruss has quit IRC
[10:14:26] *** bgeorges has quit IRC
[10:37:30] *** vtunka has joined #jbosstesting
[10:53:24] *** oskutka has quit IRC
[11:35:39] *** mgoldmann_ has joined #jbosstesting
[11:36:13] *** mgoldmann has quit IRC
[11:49:51] *** Jaikiran has joined #jbosstesting
[11:56:36] *** oskutka has joined #jbosstesting
[11:57:43] *** oskutka has joined #jbosstesting
[12:25:33] *** maeste has quit IRC
[12:28:34] *** oskutka has quit IRC
[12:29:45] *** oskutka has joined #jbosstesting
[13:06:29] *** aslak has joined #jbosstesting
[13:38:26] *** galderz has joined #jbosstesting
[13:41:47] *** jose_freitas has joined #jbosstesting
[13:44:12] <jose_freitas> hey kpiwko :)
[13:44:13] *** rruss has joined #jbosstesting
[13:44:31] <jose_freitas> about formatting the code, that's great news :)
[13:44:36] *** rruss has quit IRC
[13:46:13] <kpiwko> hi jose_freitas, yep it will help a lot
[13:53:10] <kpiwko> jose_freitas: btw, I have a branch for SHRINKWRAP-322 ready, so I'll wait until you make the pull request and rebase it on that
[13:53:17] <jbossbot> jira [SHRINKWRAP-322] Update Aether dependency and flatten pom.xml [Open (Unresolved) Component  Upgrade, Major, Karel Piwko] https://issues.jboss.org/browse/SHRINKWRAP-322
[13:53:33] <kpiwko> aslak: hey
[14:12:27] <aslak> kpiwko, heya
[14:13:28] <kpiwko> aslak: I noticed you've spoken with Jura about Arquillian Tomcat containers...do plan to release them any time soon? I'd like to refactor them a bit, e.g. make tomcat-common, move the deployer/protocol metadata stuff there and create managed/remote container for 5.5, 6.0 and 7.0 ... cargo plugin is quite handy source :)
[14:14:09] <aslak> kpiwko, Jura was going to make some changes i pointed out, but was on PTO last ween or this week or so..
[14:15:02] <aslak> kpiwko, sure, that sounds good to me..  just make sure tomcat-common don't end up being a big if(6) do x if 7 do y etc.. :)
[14:15:20] <kpiwko> aslak: sure thing, no ifs are allowed
[14:15:24] <aslak> :)
[14:15:42] <aslak> meaning, rather make extension points then ifs.. :)
[14:15:46] <jose_freitas> kpiwko: how can I do this cherrypick thing?
[14:16:33] <kpiwko> aslak: so I wait until Jura's change is in upstream
[14:16:56] <aslak> kpiwko, sure..
[14:17:21] <kpiwko> jose_freitas: make a clean branch from resolver/master
[14:17:34] <jose_freitas> yeah, I have three branches now
[14:17:47] <jose_freitas> master (mirror from upstream)
[14:17:49] <kpiwko> jose_freitas: than you make a git log of you modifed branch
[14:17:54] <jose_freitas> cpload (with my changes)
[14:18:00] <jose_freitas> and cploadmerge
[14:18:05] <kpiwko> so you'll get sha ids
[14:18:08] <jose_freitas> that I'm going to use for cherrrypicin
[14:18:13] <jose_freitas> picking
[14:19:04] <kpiwko> then in your new branch, e.g. cploadmerge if I got that right, you do git cherry-pick -n ssh-id
[14:19:51] <kpiwko> after you include all the changes in cploadmerge, you can do a commit a push and ask for pull request
[14:20:29] <kpiwko> jose_freitas: just make sure that you cploadmerge branch is really based on resolver/master, so it can be merged after your modification are done
[14:20:37] <aslak> Jaikiran, ping
[14:20:43] <jose_freitas> ok
[14:20:51] <Jaikiran>  hi aslak
[14:21:10] <aslak> Jaikiran, hey, quick ear module classloader question..
[14:21:16] <Jaikiran> sure
[14:21:51] <kpiwko> aslak: by chance, do you know if Andrew has a jenkins/cloudbees job for ShrinkWrap Dependency Resolver?
[14:22:24] *** maeste has joined #jbosstesting
[14:22:27] <aslak> Jaikiran, a EJB module deployed in a EAR, are only the 'exposed' views available to a WAR in the same EAR? or is the whole EJB module available (including other classes in the same ejb module)?
[14:23:06] <Jaikiran> aslak: all the classes in that ejb jar are available (by default) to that war
[14:23:28] <Jaikiran> we have a config which controls whether or not to expose those classes. by default it's true
[14:23:39] <aslak> Jaikiran, right, that's what i thought..
[14:24:08] <Jaikiran> aslak: overall, it's per module level and not per class level. so all classes in that ejb module are exposed
[14:24:26] <aslak> Jaikiran, these should be available via TCCL in AS7 right ? the TCCL bound when executing a Servlet
[14:25:20] <Jaikiran> aslak: yes, the tccl should correspond to the deployment unit (module) cl and should have access to that ejb jar's module cl
[14:27:31] <aslak> Jaikiran, ok thanks.
[14:27:41] <Jaikiran> you're welcome!
[14:28:15] <aslak> Jaikiran, someone seeing a CNFE with Arq Servlet Protocol on AS7 with this kind of setup. i'll ask them to provide a example project a
[14:28:23] <aslak> and debug a little
[14:28:30] <Jaikiran> aslak: sure. on some forum thread?
[14:28:37] <aslak> http://community.jboss.org/message/622940
[14:29:02] * Jaikiran looks
[14:29:33] <aslak> a sigh..  forums just went down then responding..
[14:29:43] <aslak> kpiwko, not sure.. i th
[14:29:54] <aslak> damn popups.
[14:30:30] <Jaikiran> hmm forums are down for me too. will wait a while
[14:30:58] <aslak> kpiwko, he dosn't have a cloudbees account  to my knowledge, uses his own jenkins instance running on his machine i believe. not sure if he has a resolver job tho
[14:31:31] <kpiwko> aslak: hmm, do you know if he'll be around in the evening?
[14:31:40] <aslak> kpiwko, most likely
[14:31:44] <kpiwko> aslak: great
[14:32:07] <aslak> kpiwko, http://jboss.hudson.alrubinger.com/
[14:32:17] <aslak> http://jboss.hudson.alrubinger.com/job/ShrinkWrap_Resolver/
[14:32:19] <aslak> :)
[14:32:46] <kpiwko> aslak: great work with either google or bookmarks manager :)
[14:33:18] <aslak> http://www.google.com/search?cx=w&sourceid=chrome&client=ubuntu&channel=cs&ie=UTF-8&q=alrrubinger+jboss+hudson&qscrl=1
[14:33:32] <aslak> that got me ALR Development Server
[14:33:32] <aslak> :)
[14:33:57] <kpiwko> aslak: one more thing...I'd like to release CR2 of drone in a short time...the main reason are update to Selenium version and updates to selenium-server and webdriver configurations
[14:34:23] <aslak> kpiwko, sure
[14:34:26] <kpiwko> aslak: as for Final, we'll likely wait for Arquillian to become final
[14:34:33] <aslak> kpiwko, yea
[14:35:05] <kpiwko> aslak: so can you create me a version in jira? I'll let you know once this should be released, likely tomorrow
[14:35:26] <aslak> kpiwko, slowly coming in some feedback from the EAP test guys so.. few things to fix then we move to final. + docs work basically
[14:35:38] <kpiwko> aslak: yep
[14:36:19] <aslak> kpiwko, drone_1.0.0.CR2 added
[14:38:05] *** dabloem has joined #jbosstesting
[14:38:06] *** duncan_ has joined #jbosstesting
[14:38:15] <kpiwko> aslak: thanks...and one more thing, I've updated the arquillian-showcase to CR4...it would be great if you can check it and push upstream if it is ok
[14:38:46] <aslak> sure, did you do a PR?
[14:39:20] <kpiwko> aslak: what's PR?
[14:39:26] <aslak> pull request :)
[14:39:37] <kpiwko> aslak: afaik yes
[14:40:00] <aslak> ok, just haven't seen it yet. still going through the mail backlog
[14:40:25] <kpiwko> aslak: you've been on vacation?
[14:41:42] <aslak> kpiwko, not really vacation, but was in Danmark on a Stammering course from Wednesday last week
[14:42:23] <aslak> kpiwko, saw you picked up on a few of the forum posts, thanks!
[14:43:02] <kpiwko> aslak: yw, I'm working on my karma :)
[14:43:10] <aslak> hehe
[14:44:33] *** rachmatowicz has joined #jbosstesting
[14:46:21] *** dabloem has quit IRC
[14:52:36] <jose_freitas> aslak: do you stammer?
[14:54:33] <jose_freitas> good morning and welcome back btw
[14:54:34] <jose_freitas> :)
[14:55:12] <aslak> jose_freitas, hey! yes i do
[14:55:40] <jose_freitas> I thought that you've already did some presentations
[14:55:51] <aslak> jose_freitas, yea, all the time.. :)
[14:56:08] <aslak> jose_freitas, it's good practice in controlling it
[14:56:15] <jose_freitas> nice :)
[14:56:24] *** maeste has quit IRC
[14:56:28] <jose_freitas> I have some problems too
[14:56:53] <aslak> really? interesting
[14:57:32] *** duncan_ has quit IRC
[14:57:53] <aslak> jose_freitas, how does it effect you ?
[14:58:53] <jose_freitas> well, when I'm nervous or anxious, I cut some words off the phrases, and my tongue get a little bit uncontrolled.
[14:59:18] <jose_freitas> but I learned to manage it
[14:59:58] <aslak> the fear gets to you ? :)
[15:00:38] <jose_freitas> I wouldn't say fear. sometimes I even don't realize that I'm speaking that way
[15:00:39] <jose_freitas> hehehe
[15:01:27] <jose_freitas> so people have to warn me and I have to take deep breath
[15:01:33] <jose_freitas> and say it again slowly
[15:01:50] <jose_freitas> I'm doing theater class
[15:02:06] <jose_freitas> it's helping a lot being comfortable when talking in public
[15:02:07] <aslak> jose_freitas, that's a lot of what we work with on these courses is working with fear. two days we walk around town asking random ppl random question. and every now and then disclouse our self to what we are doing (we're on a stammering course out working with our fear bla bla..).. the goal is 100 contacts each day
[15:02:13] <aslak> quite fun.. :)
[15:02:48] <jose_freitas> hahaha
[15:02:56] <jose_freitas> yeah, certainly fun
[15:04:55] *** pgmjsd has joined #jbosstesting
[15:05:54] <aslak> it's a thursday to sunday course. the new students that come in on each course, normally have severe stammers and can not even say their own name the first day. but they are all standing proudly on the down town main square on a box, having their first public speech ever on Saturday, speaking fluently
[15:05:59] <aslak> very touching..
[15:07:26] <aslak> one student said in his speech: He had never imagined he would ever be able to read bed time stories for his future kids, but now he can..
[15:09:46] <jose_freitas> wow
[15:10:08] <aslak> http://www.mcguireprogramme.com/ if interested
[15:10:43] <jose_freitas> did you improve you speaking abilities?
[15:11:21] <aslak> jose_freitas, oh yea, very much so.
[15:12:18] <aslak> block are getting further and further apart and the block that come are normally a lot milder
[15:12:49] *** maeste has joined #jbosstesting
[15:12:57] <aslak> takes a lot of practice, but its well worth it
[15:13:37] <aslak> when my "head is in the game", i'm quite fluent these days
[15:13:48] *** vnvarsete has quit IRC
[15:16:03] <jose_freitas> :)
[15:18:08] *** dabloem has joined #jbosstesting
[15:19:19] <jose_freitas> nice to hear that
[15:22:44] *** aaronwalker has quit IRC
[15:24:06] *** aaronwalker has joined #jbosstesting
[15:24:11] <aslak> kpiwko, ARQ-565 ?
[15:24:13] <jbossbot> jira [ARQ-565] Triage Arquillian JIRA before 1.0.0.Final [Open (Unresolved) Task, Major, Aslak Knutsen] https://issues.jboss.org/browse/ARQ-565
[15:24:57] *** dabloem has quit IRC
[15:25:40] <kpiwko> aslak: the main reason why I created is that CR1 is already out but there are still some jiras unresolved for it
[15:25:57] <aslak> kpiwko, i can't find any?
[15:26:06] <aslak> kpiwko, you looking at 1.1.0.CR1 ?
[15:26:20] <aslak> https://issues.jboss.org/browse/ARQ/fixforversion/12314608
[15:26:40] <aslak> vs 1.1.0.CR1  https://issues.jboss.org/browse/ARQ/fixforversion/12314610
[15:26:58] <kpiwko> aslak: hmm, it is possible :(
[15:27:04] <kpiwko> aslak: here's the thread http://community.jboss.org/thread/170673
[15:27:52] <aslak> yea, i saw the thread.. but..
[15:30:04] *** maeste has quit IRC
[15:32:14] <kpiwko> aslak: feel free to close, I must have opened some extra bad filter thinking that open issues are the same as fixforversion issues
[15:32:27] <aslak> ok
[15:38:10] *** dabloem has joined #jbosstesting
[15:42:30] <aslak> kpiwko, where did you get this file from? https://github.com/arquillian/arquillian-container-tomcat/pull/6/files#r105048
[15:43:14] <kpiwko> aslak, maven cargo plugin
[15:43:30] <kpiwko> aslak: its apache license as well
[15:43:35] <kpiwko> *it's
[15:44:05] <kpiwko> aslak: so basically we keep the header intact as I did for ShrinkWrap Resolver
[15:44:27] <aslak> it contains no CopyRight notice?
[15:44:54] <kpiwko> aslak: @author tags are not enough?
[15:44:57] <aslak> i mean, contained
[15:45:43] <aslak> ASL states any copyright/ trademark notices should stay as is when redistributed
[15:46:31] *** maeste has joined #jbosstesting
[15:47:27] <aslak> "You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and .. "
[15:47:31] <kpiwko> ow, this is io utils, not the deployer
[15:47:40] <kpiwko> let me check
[15:48:44] <aslak> kpiwko, you could probably replace it with this: https://github.com/shrinkwrap/shrinkwrap/blob/master/impl-base/src/main/java/org/jboss/shrinkwrap/impl/base/io/IOUtil.java
[15:49:24] *** aaronwalker has quit IRC
[15:50:11] <kpiwko> aslak: well, I can
[15:50:34] *** lincolnthree has joined #jbosstesting
[15:50:43] *** lincolnthree has left #jbosstesting
[15:51:07] *** ldimaggi has joined #jbosstesting
[15:51:21] <kpiwko> aslak: it contained only the Apache license header
[15:51:40] <aslak> ok
[15:52:52] <kpiwko> aslak: I'm not sure if I used 1.4 or 2.x, but here's the file for 1.4 http://pastebin.com/0g6DnMkT
[15:52:53] <Jaikiran> aslak: replied
[15:55:10] <kpiwko> aslak: there is actually a ASF licensed, but no copyright...I'll replace it with shrinkwrap ioutil just to be sure
[15:55:34] <kpiwko> a "ASF licensed" sentence
[15:55:57] <aslak> :)
[15:56:45] <kpiwko> aslak: or I/Jura can simply return ASF licensed text back
[15:57:32] <kpiwko> this is the way suggested by mojave we had the same problem in swr: http://pastebin.com/vJ07CSS0
[15:57:53] <kpiwko> aslak: the latter is less work, so I prefer it :)
[15:58:32] *** galderz has quit IRC
[15:59:08] *** galderz has joined #jbosstesting
[15:59:38] <aslak> kpiwko, well the header is the same isn't it.
[15:59:55] <aslak> kpiwko, besides the copyright notice from jboss.
[16:00:10] <aslak> kpiwko, it's just a question about retaining the orginal copyright notices if any
[16:00:13] <kpiwko> aslak: yep, there should be original and jboss copyringh
[16:00:18] <kpiwko> aslak: exactly
[16:00:38] <aslak> kpiwko, did you change the file in anyway? besides package name ?
[16:00:54] <kpiwko> I misread the beginning thinking all the head header is the license
[16:02:14] *** bgeorges has joined #jbosstesting
[16:02:17] <kpiwko> aslak: afaik not, maybe I deleted some methods
[16:03:47] *** lincolnthree has joined #jbosstesting
[16:07:33] <jose_freitas> kpiwko
[16:07:43] <aslak> Jaikiran, aa yes. nice catch.
[16:15:46] <kpiwko> jose_freitas: yes?
[16:19:05] *** oskutka has quit IRC
[16:20:56] <jose_freitas> kpiwko: I push my changes to a branch, but I force an update and there's now a commit of yours on my pull request
[16:21:11] <kpiwko> aslak: btw, are you using the github ui to merge a request? or you do it some other way? because github ui creates a merge commit I don't like
[16:21:41] <kpiwko> jose_freitas: can you send me a link to that branch?
[16:22:23] <jose_freitas> https://github.com/joserodolfofreitas/resolver/commits/cploadfeaturemerge
[16:22:29] *** rruss has joined #jbosstesting
[16:22:37] <kpiwko> jose_freitas: I have think you just wrongly rebased so the includes a commit which is already in resolver master
[16:23:19] <jose_freitas> hm
[16:24:25] <jose_freitas> yes]
[16:25:07] <kpiwko> jose_freitas: well, it can't be merged against master
[16:26:22] <aslak> kpiwko, i don't use the gui. i normally do, git fetch kipwko && git checkout kpiwko/ARQ-XX && git rebase master && git check -b ARQ-XX && git merge ARQ-XXX && git push upstream master && git branch -d ARQ-XXX
[16:26:39] <aslak> check -b should be checkout -b
[16:27:27] <aslak> kpiwko, if i know the pr is ontop of matser, i might just do, git fetch kpiwko && git merge kpiwko/ARQ-XXX
[16:27:34] <aslak> master even
[16:28:15] <kpiwko> jose_freitas: i checked the content you your commits
[16:28:55] <kpiwko> jose_freitas: if I read that correctly, the 3 top commits are where the work is done, right?
[16:29:18] <kpiwko> the first and the latest cannot be cherry-picked on master
[16:29:59] <jose_freitas> hm
[16:30:08] <jose_freitas> I'm trying it in a new branch
[16:31:14] <kpiwko> jose_freitas: is this the original branch?
[16:31:16] <kpiwko> https://github.com/joserodolfofreitas/resolver/commits/cploadmerge
[16:31:22] <aslak> Jaikiran, congrats! :)
[16:31:38] <Jaikiran> aslak: thank you! :)
[16:31:47] <jose_freitas> kpiwko: this was already a merged one
[16:32:05] <jose_freitas> fixed some lines
[16:32:16] <jose_freitas> so it could seem untouched on the pull request
[16:32:38] <jose_freitas> I tried again on https://github.com/joserodolfofreitas/resolver/tree/cploadfeature
[16:34:27] <kpiwko> jose_freitas: still the same
[16:34:51] <jose_freitas> yea
[16:36:51] <kpiwko> jose_freitas: it think you should do the following
[16:36:51] <kpiwko> 1/ checkout resolver/master -b new-checkpoint
[16:36:52] <kpiwko> 2/ checkout jose/master - b feature
[16:36:52] <kpiwko> 3/ rebase new-checkpoint
[16:36:52] <kpiwko> 4/ fix conflicts by hand
[16:36:52] <kpiwko> 5/ rebase --continue
[16:36:52] <kpiwko> 6/ commit
[16:36:53] <kpiwko> 7/ push and ask for pull
[16:39:26] *** ALR has joined #jbosstesting
[16:40:52] *** bleathem has joined #jbosstesting
[16:44:10] <jose_freitas> kpiwko: if I send a pull on https://github.com/joserodolfofreitas/resolver/commits/cploadfeature it cannot be merged?
[16:44:17] <jose_freitas> pull request*
[16:45:24] <kpiwko> jose_freitas: nope, I already tried it by hand
[16:46:48] <jose_freitas> what files conflicted?
[16:47:30] <kpiwko> #       both modified:      api-maven/src/main/java/org/jboss/shrinkwrap/resolver/api/maven/MavenDependencyResolver.java
[16:47:30] <kpiwko> #       both modified:      impl-maven/src/main/java/org/jboss/shrinkwrap/resolver/impl/maven/MavenBuilderImpl.java
[16:47:31] <kpiwko> #       both modified:      impl-maven/src/test/java/org/jboss/shrinkwrap/resolver/impl/maven/ArtifactDependenciesUnitTestCase.java
[16:47:34] <kpiwko> jose_freitas: ^
[16:47:40] <kpiwko> jose_freitas: have you tried to rebase?
[16:47:50] <jose_freitas> yes
[16:48:09] <kpiwko> was that working?
[16:48:16] <kpiwko> no conflicts?
[16:48:32] <jose_freitas> not on my branch
[16:48:49] <jose_freitas> let me try from zero again
[16:48:54] <kpiwko> jose_freitas: are you sure you have latest resolver/master
[16:49:07] *** Jaikiran is now known as Jaikiran|AFK
[16:49:29] <jose_freitas> yes
[16:49:42] <kpiwko> you should do git fetch resolver && git checkout resolver/master -b the-checkpoint
[16:50:12] <kpiwko> I don't get how is it possible that you can rebase without conflicts but I do have them
[16:50:21] <jose_freitas> last commit I have on my master is this
[16:50:22] <jose_freitas> https://github.com/shrinkwrap/resolver/commit/5b2e770272e468e34965eae2a74bf22438b3de58
[16:50:25] <jbossbot> git [resolver] 5b2e770.. Karel Piwko SHRINKWRAP-309 Ensuring tests for offline repository have clean environment
[16:50:25] <jose_freitas> so I have it ok
[16:50:26] <jbossbot> jira [SHRINKWRAP-309] Ensure test runs can be repeated from an IDE [Resolved (Done) Bug, Minor, Karel Piwko] https://issues.jboss.org/browse/SHRINKWRAP-309
[16:50:30] <kpiwko> yep
[16:50:42] <jose_freitas> I created a new branch from it
[16:50:49] <kpiwko> so if you rebase all your commits should be on top of this commit
[16:50:52] <jose_freitas> to use as merge holder
[16:51:06] <kpiwko> so it won't get in middle causing conflicts
[16:51:14] <jose_freitas> ok
[16:51:35] <kpiwko> you can use gitk tool to check visually
[16:52:24] <lincolnthree> hey ALR, morning, any chance I could beg you to release a SNAPSHOT or Alpha of SD 1.2.x ?
[16:52:32] <ALR> lincolnthree: Morning
[16:52:35] <lincolnthree> So my forge hudson job will work ? :)
[16:52:36] <jose_freitas> I use egit for eclipse kpiwko
[16:52:57] <ALR> lincolnthree: That'll depend on aslak's review of the SPI changes that just went into 1.1.0-alpha-3
[16:53:00] <kpiwko> jose_freitas: ok
[16:53:04] <jose_freitas> going for lunch, I'll be back in 40 min
[16:53:19] <ALR> Though I suppose I *could* start releasing two streams simultaneously.
[16:53:24] <ALR> 1.1.x and 1.2.x
[16:53:52] <ALR> lincolnthree: You understand all the new spec APIs are very likely to change?
[16:56:57] <lincolnthree> ALR: in that case, nevermind :)
[16:57:08] <lincolnthree> I'll go back to 1.1.x
[16:57:11] <ALR> lincolnthree: Nevermind on the changing APIs?
[16:57:34] <ALR> Also in 1.1.x there may not be something to go back *to*
[16:57:45] <ALR> Once the classes you're relying on in impl module get deleted.
[16:57:46] <lincolnthree> ALR, if the APIs are going to change, I can't depend on them for a forge release.
[16:57:57] <ALR> You expose them out to users?
[16:58:09] <lincolnthree> To plugin writers.
[16:58:19] <ALR> Yeah, those can't go out.
[16:58:26] <ALR> But what classes do you need to expose?
[16:58:31] <lincolnthree> The descriptors
[16:58:33] <lincolnthree> and Node
[16:58:36] <ALR> To plugin writers?  Spec metadata APIs?
[16:58:41] <ALR> Ir Descriptor and Node?
[16:58:50] <ALR> Node may still change even in 1.1.x
[16:59:08] <ALR> 1.1.x series is to stabilize and define the SD SPI.
[16:59:12] <ALR> Node is a part of that SPI.
[16:59:19] <ALR> And 1.1.x is still on Alpha.
[16:59:27] <ALR> It'll be back compat once 1.1.x is Beta.
[16:59:46] <lincolnthree> yep, i don't have much choice :) unless I want to wrap your code
[17:00:00] <lincolnthree> and then maintain that wrapper going forward
[17:01:13] <lincolnthree> I'm trying not to be the guy who re-invents the wheel to avoid dependencies
[17:01:24] *** dblevins has joined #jbosstesting
[17:05:19] <aslak> ALR, not quite following the changes you've done in Node SPI in regards to the Descriptor vs Importer creators ?
[17:05:56] <ALR> aslak: None really.
[17:06:11] <ALR> At construction we still need to know what importer to use
[17:06:14] <aslak> ALR, right, that's what i was seeing.. hehe
[17:06:21] <ALR> And having the user supply it seems verbose
[17:06:32] <lincolnthree> uh oh, when aslak doesn't follow, something is wrong with the world! perish and flee!!
[17:06:37] <ALR> (Though I've had a mind to make it an option to pass in)
[17:07:17] <aslak> ALR, well.. my point was.. as a Importer, i don't care about the endUserViewImplType, that's the Descriptors issue
[17:07:44] <aslak> I care only about the InputStream of data to Import, and i will return you the Root Node of that InputStream
[17:07:57] <ALR> lincolnthree: In this case I think you either have to reinvent the wheel or don't expose the feature to users :)  But that's what we're on now with these SPI talks.  Getting something back-compat done.
[17:08:00] <ALR> Which is close.
[17:08:19] <ALR> aslak: One sec
[17:08:44] <kpiwko> ALR: hi there
[17:09:46] <ALR> aslak: You just mean: https://github.com/ALRubinger/descriptors/blob/master/spi/src/main/java/org/jboss/shrinkwrap/descriptor/spi/DescriptorImporterBase.java#L46
[17:10:14] <ALR> aslak: Which is really there only to preserve the type safety when "importAs(type).from(source)" returns.
[17:10:21] <kpiwko> jose_freitas: any progres?
[17:10:26] <kpiwko> *progress
[17:10:27] <ALR> kpiwko: What's up?
[17:10:34] <kpiwko> ALR: is it possible for me to get access to http://jboss.hudson.alrubinger.com/job/ShrinkWrap_Resolver/ ? or should I use jboss.org jenkins instance?
[17:10:48] <ALR> kpiwko: You wanna fire jobs?
[17:11:14] <aslak> ALR, i mean, a NodeImporter should be hidden behind DescriptorImporter, not extend.
[17:11:25] <kpiwko> ALR: yes...or even better fire jobs agains different branch before I merge the pull
[17:11:43] <aslak> ALR, a NodeImporter should care about the InputStream and converting that to a Node. the DescriptorImporter should care about converting that Node to a Descriptor
[17:11:59] <ALR> aslak: aha.
[17:12:04] <ALR> aslak: That's where we disagree.
[17:12:11] <ALR> kpiwko: PM me desired password?
[17:12:21] <ALR> aslak: DescriptorImporter cannot take in a Node.
[17:12:31] <ALR> Because DescriptorImporter should not know what a Node is.
[17:12:44] <ALR> I've separated things out that way.
[17:13:00] <ALR> To the point even where spi-base could be a parent of spi-node
[17:13:20] <ALR> We'd previously had an assumption that all descriptors were hierarchal.
[17:13:25] <ALR> I removed that assumption,
[17:13:36] <ALR> By putting that spi.node package in place.
[17:13:42] <ALR> And spi.* doesn't know about spi.node
[17:15:12] <ALR> kpiwko: Try logging in.
[17:15:27] *** mgoldmann_ has quit IRC
[17:15:51] <kpiwko> ALR: awesome, thanks!
[17:16:25] <aslak> ALR, sure.. Descriptor don't care about Node, same way Importer does not care about the Endview. we're missing a layer
[17:16:58] <ALR> aslak: Importer does care about end view now only for the type cast on return from "from", yes?
[17:17:18] <ALR> If so I can just insert some adaptor into API and be done w/ it.
[17:17:27] <aslak> my assumption was always that any Importer of any type would be presented as a Node, wheter hirartical or not. maybe a different type of node
[17:17:33] <ALR> But still that adaptor would need to know.
[17:17:39] <ALR> The end view type
[17:18:18] <ALR> Hmm, as it stands Node is defined as always hierarchal.
[17:18:37] <aslak> ALR, it cares by extension
[17:18:58] <ALR> aslak: What cares by extension?
[17:19:25] <ALR> Importer cares about end user view impl type?  Yeah, only for "from" return value.
[17:19:40] <aslak> ALR, in the XImporter extends NodeImporter extends DescriptorImporter.. XImpoter now cares about all it's parents
[17:20:08] <aslak> which gets the Constructor and creates the end view
[17:20:45] <ALR> aslak: Huh?
[17:20:50] <aslak> ALR, NodeImporter IF should be:  Node importRootNode(final InputStream stream); No need for extending any baseclass that handles 'other' stuff for you
[17:20:54] <ALR> https://github.com/ALRubinger/descriptors/blob/master/spi/src/main/java/org/jboss/shrinkwrap/descriptor/spi/DescriptorImporterBase.java
[17:21:21] <ALR> That there has no *other* stuff, just base support.
[17:21:27] <aslak> ALR, https://github.com/ALRubinger/descriptors/blob/master/spi/src/main/java/org/jboss/shrinkwrap/descriptor/spi/node/NodeDescriptorImporterBase.java#L75
[17:22:15] <aslak> ALR, base support for what? creating the EndView which is irelevant for the Importer
[17:22:22] <ALR> Ooh.
[17:22:41] <ALR> Yeah OK
[17:22:48] <ALR> I can rework that line out.
[17:22:53] <ALR> I see what you're after now.
[17:23:03] <ALR> And you see why I separated out spi.* from spi.node ?
[17:23:25] <ALR> We just need an adaptor layer in the middle.
[17:23:32] <ALR> It's closer now.
[17:23:57] <aslak> ALR, this should be the Importer IF, https://github.com/ALRubinger/descriptors/blob/master/spi/src/main/java/org/jboss/shrinkwrap/descriptor/spi/node/dom/XmlDomDescriptorImporterImpl.java#L76 which no need extending a Base
[17:24:01] <aslak> which/with
[17:24:34] <ALR> NodeImporter IF you mean
[17:24:41] <aslak> yes
[17:25:12] <ALR> The IF won't extend anything
[17:25:17] <ALR> I'm not sure about the impl yet
[17:25:27] <ALR> But yeah, I can decouple that stuff
[17:25:37] <ALR> And still preserve the desired code use:
[17:25:44] <ALR> importAs().from()
[17:25:47] <aslak> yea
[17:26:07] <ALR> aslak: Actually, I can't!
[17:26:08] <aslak> you don't expose the actual Importer at that stage anyway
[17:26:10] <ALR> importAs() is API
[17:26:26] <aslak> ?
[17:26:43] <ALR> Contracted to return a DescriptorImporter
[17:26:51] <ALR> Meaning it's locked.
[17:27:14] <aslak> sure, but the API doesn't have to change
[17:27:40] <ALR> The adaptor layer will have to live in the SPI
[17:27:51] <aslak> DescriptorImporter is still relevant.. it just needs to be wrapped differently in the brackground
[17:27:55] <ALR> And be a bridge between DescriptorImporter and NodeImporter
[17:28:16] <ALR> I'll play with it
[17:28:17] <aslak> NodeImporter should not be seen by the user anyway. that's all SPI
[17:28:26] <ALR> It wouldn't be seen by the user.
[17:28:39] <ALR> But still I'd have chosen a different return type in the API
[17:28:41] <ALR> No matter
[17:28:44] * ALR off
[17:28:47] <ALR> For coding.
[17:30:13] <aslak> ALR, why is API locked btw? their all in Alpha3.. :)
[17:30:51] <ALR> aslak: https://github.com/ALRubinger/descriptors/blob/1.0.0-beta-1/
[17:31:02] <ALR> 1.0.0, to define the API, went Beta.
[17:31:08] <aslak> aa yes.. 1.0
[17:32:09] *** jamezp_afk is now known as jamezp
[17:43:24] *** galderz has quit IRC
[17:45:22] *** bleathem has quit IRC
[17:45:53] *** bgeorges has quit IRC
[17:46:54] *** ALR has quit IRC
[17:48:08] *** ALR has joined #jbosstesting
[17:52:33] *** rachmatowicz has quit IRC
[18:10:18] *** ALR has quit IRC
[18:12:34] *** duncan_ has joined #jbosstesting
[18:12:39] *** ALR has joined #jbosstesting
[18:13:23] *** dabloem has quit IRC
[18:21:06] *** ALR has quit IRC
[18:22:16] *** kpiwko has quit IRC
[18:25:03] *** lfryc has quit IRC
[18:31:44] *** ianbrandt has joined #jbosstesting
[18:32:01] *** Jaikiran|AFK is now known as Jaikiran
[18:39:30] *** maschmid has quit IRC
[18:44:13] *** ge0ffrey has quit IRC
[18:46:45] *** jamezp has quit IRC
[19:01:40] *** jhuska has quit IRC
[19:02:09] *** jamezp has joined #jbosstesting
[19:04:16] *** jhuska has joined #jbosstesting
[19:27:02] *** lincolnthree has quit IRC
[19:29:30] *** jhuska has quit IRC
[19:30:49] *** maeste has quit IRC
[19:31:54] *** Jaikiran has quit IRC
[19:37:57] *** ALR has joined #jbosstesting
[19:56:59] *** rachmatowicz_ has quit IRC
[20:01:49] *** rbattenfeld has joined #jbosstesting
[20:10:47] *** galderz has joined #jbosstesting
[20:16:30] *** rbattenfeld has left #jbosstesting
[20:42:53] *** kevinpollet has joined #jbosstesting
[20:50:52] *** galderz1 has joined #jbosstesting
[20:52:09] *** galderz has quit IRC
[20:52:26] *** galderz1 has quit IRC
[20:56:28] *** alesj has joined #jbosstesting
[21:33:55] *** dblevins has quit IRC
[21:41:21] *** dblevins has joined #jbosstesting
[21:56:33] <ALR> aslak: Yeah, having a problem.
[21:56:37] <ALR> Maybe you had an idea in mind.
[21:56:57] <ALR> Removing the endUserViewImpl from the Importer  isn't the issue
[21:57:10] <ALR> The issue is that the Importer by contract in the API is the return value from importAs
[21:57:25] <ALR> And I need some way to hang onto that endUserViewImpl
[21:57:35] <ALR> Now ordinarily I'd make some layer and stick that in the middle
[21:57:47] <ALR> But I can't do that, by API contracts which is now immutable
[22:05:48] <ALR> So anyway, the DescriptorImporter impl can carry around the endUserViewImplType thing.
[22:05:55] <ALR> And the NodeImporter need not.
[22:18:15] *** tommysdk has joined #jbosstesting
[22:31:20] *** lightguard_jp has joined #jbosstesting
[22:36:05] *** tommysdk has quit IRC
[22:38:18] <aslak> ALR, yea, the Contract is DescriptorImporter, NodeImporter is a background thing, hidden in SPI
[22:38:30] <ALR> aslak: OK, then I have it
[22:38:34] <ALR> aslak: Approve this?
[22:38:38] <aslak> a NodeImporter does not need to be a DescriptorImporter
[22:39:21] <ALR> aslak: https://gist.github.com/1179355
[22:39:25] <ALR> aslak: It' not
[22:39:26] <ALR> It's not.
[22:39:42] <ALR> The endUserViewImpl crap is still in that base DescriptorImporter impl
[22:40:29] <ALR> aslak: Line 166 is what brings both views together
[22:40:41] <ALR> But this way you can use a NodeImporter standalone from a DescriptorImporter
[22:40:43] <ALR> Like:
[22:41:01] <ALR> private Node load()    {    return XmlDomNodeImporter.INSTANCE.importAsNode(new ByteArrayInputStream(SOURCE.getBytes()), true);   }
[22:42:11] <aslak> not sure why you need XmLDomNodeDescriptorImporterImpl
[22:42:24] <aslak> as something specific to XmlDom that is
[22:42:53] <ALR> aslak: In case we ever want to use a strategy for importing a Descriptor that's not based in org.w3c.Document
[22:43:12] <aslak> well, Document is not exposed anywhere
[22:43:17] <ALR> We'd just swap in another impl of that bridge class.
[22:43:25] <ALR> It's not about exposing it anywhere.
[22:43:39] <ALR> Only about making an impl for org.w3c.
[22:43:45] <aslak> sure, but wouldn't NodeDescriptorImporterBase alone with access to the Descriptor SPI file work just as well ?
[22:43:48] <ALR> And leaving room for alternate impls in an easy way
[22:43:54] <aslak> you have which DescriptorImpl to load and which Improter to use
[22:44:10] <aslak> why do you need a special 'mixer' class for the Importer type
[22:44:47] <ALR> So I could easily add XmLStaxNodeDescriptorImporterImpl
[22:45:19] <aslak> ALR, sure, but how do you choose XmlDomNodeDescriptorImporterImpl ?
[22:45:24] <OndrejZizka> aslak: ping
[22:45:41] <ALR> aslak: It's in the services file for each descriptor type.
[22:45:57] <aslak> ALR, right.. so why not add the Importer there instead of the mixer class
[22:46:00] <ALR> But I was also considering adding an extension to the SD API to define what to use.
[22:46:16] *** duncan_ has quit IRC
[22:46:22] <ALR> aslak: Potato/potato.
[22:46:34] <ALR> aslak: Mostly because I don't like adding stuff to that services file.
[22:47:10] <aslak> ALR, you have already choosen to use the XmlDomNodeDescriptorImporter which is hardcoded to use the XmlDomImporter.. why not just choose XmlDomImporter and get rid of the XmlDomNodeDescriptorImporter altogather
[22:47:43] <aslak> ALR, the info is already in the file
[22:48:22] <ALR> To what benefit?
[22:48:39] <ALR> Something's got to be in there.  So you ask why I've got the way it is; why change it?
[22:48:46] <ALR> To invert your question. :)
[22:49:23] *** rbattenfeld has joined #jbosstesting
[22:49:44] <rbattenfeld> ALR: Hi Andrew
[22:51:53] <ALR> rbattenfeld: Hiya
[22:52:24] <rbattenfeld> ALR: I analyzed the issue...
[22:52:35] <ALR> rbattenfeld: Attributes and elements?
[22:52:36] *** dblevins has quit IRC
[22:52:41] <ALR> Find anything fun?
[22:52:50] <rbattenfeld> ALR: yes, this one
[22:53:33] <rbattenfeld> ALR: it is an enumeration and an attribute at the same time. I will fix that
[22:53:40] <ALR> Superdooper.
[22:53:48] <rbattenfeld> ALR: when do you need it?
[22:54:01] <ALR> "Need" is strong.
[22:54:09] <ALR> Whatever we fix makes the next release.
[22:54:14] <ALR> Whatever doesn't, doesn't.
[22:54:17] <ALR> And makes the next one.
[22:54:26] <ALR> In Alpha releases we make no promises WRT the API.
[22:55:14] <rbattenfeld> ALR: it is not difficult but I am afraid not to be in sync with upstream. did you had problems with my last pull request?
[22:55:42] <ALR> rbattenfeld: Well, I don't have problems with your pull requests, but your branch is definitely out of sync
[22:55:59] <ALR> When I pull your stuff in, I cherry-pick it into the clean upstream copy
[22:56:19] <ALR> What you should probably do is make a 1.2.0-X branch which never takes any commits from you
[22:56:24] <ALR> And is used only to pull in from upstream
[22:56:34] <ALR> Then you can make topic branches which are rebased off of that.
[22:57:00] <rbattenfeld> ALR: hmm. I always delete master and create it new from upstream...
[22:57:06] *** dblevins has joined #jbosstesting
[22:57:08] <ALR> And get better isolation.  As it is it looks like you're putting commits over a branch with commits that may have never gone upstream, or been squashed/modified first
[22:57:17] <ALR> rbattenfeld: master is master - 1.1.x
[22:57:38] * ALR has to come back in like 10
[22:57:43] <ALR> Lucy really needs a walk :)
[23:04:05] *** rruss has quit IRC
[23:05:41] <nickarls> ALR: when the dogs eyes start to look yellow, your carpet is in danger...
[23:06:35] <ALR> :)
[23:06:37] * ALR back
[23:08:50] <ALR> rbattenfeld: So https://github.com/rbattenfeld/descriptors doesn't look to have a 1.2.0-X branch which is just mirroring upstream
[23:09:15] <rbattenfeld> ALR: I thought, this command will create a new branch synced with upstream: git checkout -b SHRINKDESK-82 remotes/upstream/1.2.0-X
[23:09:17] <ALR> aslak: And to our discussion, I'm not seeing exactly what you want to accomplish yet
[23:09:31] <ALR> rbattenfeld: Ah yes that should.
[23:09:45] <ALR> rbattenfeld: BTW the project key is "SHRINKDESC" with a "C"
[23:10:15] <rbattenfeld> ALR: oh !
[23:10:33] <ALR> jose_freitas: here?
[23:11:58] <jose_freitas> ALR: yap
[23:12:30] <ALR> jose_freitas: https://github.com/shrinkwrap/resolver/pull/4
[23:12:35] <ALR> You want all of those commits in?
[23:13:09] <ALR> Or are some of those older which were already commited upstream in some other fashion, ie: squashed
[23:13:11] <ALR> ?
[23:13:27] <jose_freitas> no, they are all part of my try to fix code format
[23:13:53] <ALR> jose_freitas: Why is fixing code format related to SHRINKWRAP-288? :)
[23:13:54] 
[23:13:55] <OndrejZizka> aslak:  How about adding test grouping functionality to Arquillian?  So we could group JUnit tests like with TestNG.
[23:13:55] <OndrejZizka> aslak: And since Arquillian.class is used as runner, that would be a nice bonus
[23:14:04] <jose_freitas> well, because I coded 288
[23:14:16] <jose_freitas> and then I have to rewrite it to add another feature
[23:14:29] <aslak> ALR, i wanted to decouple the specific Importer from the specific Descriptor. what you proposed here just couples them on a different level
[23:14:38] <ALR> jose_freitas: Yes, so theres 2 features and a code format mixed together in these?
[23:14:42] <jose_freitas> ALR: and because I used a code formatter tool, it formatted a lot of lines
[23:14:53] <ALR> aslak: They need to be coupled together at some point.
[23:14:57] <jose_freitas> and for you guys to see what I really changed
[23:15:00] <ALR> I just couple them at the highest level up.
[23:15:03] <jose_freitas> I had to remove white spaces and etc
[23:15:16] <jose_freitas> to let it "clean"
[23:15:41] <ALR> jose_freitas: Is it a significant amount of work to ask for commits to isolate these issues?
[23:15:50] <ALR> ie. A JIRA specifically for code formatting?
[23:15:57] <ALR> Then 288.  Then something else?
[23:16:05] <ALR> With commits that note the JIRA in the message?
[23:16:16] * ALR really likes to keep things separated and atomic.
[23:16:31] <ALR> Such that we can easily audit or revert changes later in singular fashion
[23:16:55] <ALR> aslak: So if you propose some other way of bringing the whole picture together I'm all ears.
[23:16:56] <jose_freitas> ALR, well, I have no problem with that, but how can I remove those commits on a pull request?
[23:17:03] <jose_freitas> is it possible?
[23:17:11] <ALR> jose_freitas: Changing the branch changes the pull request.
[23:17:27] <rbattenfeld> See you tomorrow. It's late. Cheers to everyone
[23:17:28] <ALR> Or we could close the pull request alltogether and start fresh
[23:17:31] <ALR> rbattenfeld: Night
[23:17:40] *** rbattenfeld has left #jbosstesting
[23:17:45] <ALR> jose_freitas: And then introduce new branches, one for each issue.
[23:18:57] <jose_freitas> hm
[23:19:18] <jose_freitas> yea, but from my branch now
[23:19:31] <jose_freitas> is it possible to remove commits?
[23:19:44] <aslak> ALR, they need to be coupled sure, but not pr importer
[23:20:03] <jose_freitas> or should I start a brand new branch and start coding on that?
[23:20:12] <jose_freitas> yeah, I'll recode it
[23:20:16] <jose_freitas> it'll be easier
[23:20:47] <jose_freitas> I was the whole morning struggling with those commits hehehe, starting from zero will be definitelly easier.
[23:22:07] <jose_freitas> and then I'll don't even need a code format commit
[23:22:13] <jose_freitas> won't
[23:24:42] <ALR> aslak: So you want what?  Another layer of indirection?
[23:24:56] <ALR> Some layer to combine the NodeImporter and the DescriptorImporter together?
[23:25:16] <ALR> jose_freitas: hehe, sorry about that.
[23:25:33] <ALR> jose_freitas: Yeah, I find that keeping all commits isolated in branch-per-issue helps a lot
[23:25:55] <ALR> And if code format is a problem, we can introduce checkstyle and do one massive code reformat commit to get consistency from here forward
[23:28:06] *** rachmatowicz has joined #jbosstesting
[23:28:59] <alesj> aslak: yt?
[23:32:13] <aslak> ALR, well, i don't think we need another layer, it's more about removing one at this point. DescriptorImporter can read the SPI file, load the importer, create the endUserView
[23:32:42] <ALR> aslak: What's the SPI file?
[23:32:54] <aslak> META-INF/Descriptor
[23:32:58] <ALR> DescriptorImporter can load the Importer?  huh?
[23:33:03] <ALR> Load the NodeImporter?
[23:33:07] <aslak> NodeImporter
[23:33:09] <ALR> Damn IRC
[23:33:15] <ALR> This would take 10 seconds in person :)
[23:33:27] <aslak> hehe
[23:34:04] <aslak> OndraZizka, JUnit support this already
[23:35:13] <jose_freitas> ALR: np, you're right in worrying about that.
[23:35:42] <ALR> jose_freitas: Yeah, doesn't make it any less annoying.  Code maintenance ain't interesting.
[23:35:49] <ALR> But thanks for agreeing.
[23:37:05] *** OndrejZizka has quit IRC
[23:37:14] <aslak> OndraZizka, https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/NormalSuite.java
[23:37:30] *** OndrejZizka has joined #jbosstesting
[23:38:47] <aslak> OndraZizka, https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/NormalSuite.java
[23:38:58] <aslak> alesj, yo
[23:39:19] <alesj> aslak: i have 2 more GAE containers for you ;-)
[23:39:26] <alesj> w/o hacks this time :-)
[23:40:07] <aslak> alesj, without hacking ? !
[23:40:08] <aslak> :)
[23:40:30] <alesj> hehe, well, it happens :-)
[23:40:58] <aslak> aa, never made a gae repo..
[23:41:49] <jose_freitas> ALR: at least I've learned a lot about branching and how to deal with them in git :)
[23:43:33] <aslak> alesj, https://github.com/arquillian/arquillian-container-gae
[23:44:10] <alesj> aslak: merge it with my?
[23:44:21] <OndrejZizka> aslak: Well Actually I found that Categories runner
[23:44:51] <OndrejZizka> but it's JUnits one, isn't it? It's not imported though, so perhaps arq has same named runner?
[23:45:16] <OndrejZizka> I'll check the source
[23:45:23] <aslak> OndraZizka, not imported ?
[23:46:51] <jose_freitas> ALR: done
[23:47:02] <jose_freitas> ALR: it wasn't that bad
[23:47:04] <aslak> alesj, which of them work and which does not ?  what should be imported
[23:47:07] <OndrejZizka> imported by java import
[23:47:18] <OndrejZizka> I mean, it must be in the package of the test then
[23:47:18] <alesj> aslak: all 3 work
[23:47:34] <alesj> but you know how embedded works ;-)
[23:47:47] <aslak> right, that's the one we can't use
[23:47:48] *** kevinpollet has quit IRC
[23:48:01] <aslak> cli and common is used by remote and local ?
[23:48:07] <alesj> yes
[23:48:12] <alesj> it's just abstract classes
[23:48:19] <aslak> ok
[23:48:56] <aslak> alesj, sure.. i'll purge embedded and merge it into upstream
[23:51:15] *** rachmatowicz has quit IRC
[23:51:35] <alesj> ok, cool
[23:51:54] <alesj> aslak: ^
[23:52:51] <jose_freitas> aslak: shouldn't undeploy on jboss7 delete content file?
[23:53:07] <aslak> jose_freitas, ?
[23:53:27] *** rachmatowicz has joined #jbosstesting
[23:53:51] <ALR> jose_freitas: Nice, on the same branch?
[23:54:01] <jose_freitas> nope, I created a new one
[23:54:14] <ALR> jose_freitas: I see it https://github.com/joserodolfofreitas/resolver/commit/efbdfcefee263ecd0b540e7658e5c4d800dd1f8f
[23:54:15] <jbossbot> git [resolver] efbdfce.. joserodolfofreitas SHRINKWRAP-288 - I've added before the possibility to add a file in...
[23:54:16] 
[23:54:59] <jose_freitas> aslak: my standalone/data folder keeps getting bigger.
[23:55:09] <jose_freitas> with deploys data
[23:55:16] <aslak> hehe
[23:55:19] <aslak> as7?
[23:55:22] <jose_freitas> yes
[23:55:32] <jose_freitas> content is actually the war
[23:55:40] <jose_freitas> and its never get deleted
[23:55:49] <aslak> but it gets undeployed ?
[23:55:52] <jose_freitas> yes
[23:55:56] <jose_freitas> but not deleted
[23:56:04] <aslak> sounds like a as7 'feature'
[23:56:13] <jose_freitas> so, from time to time I have to go there and clean it up
[23:56:22] <aslak> arq just calls the ManagementAPI..
[23:56:34] <jose_freitas> aslak: hm, ok
[23:56:42] <aslak> maybe there is delete content option..
[23:57:59] <jose_freitas> yeah, it'd be nice
[23:58:16] <jose_freitas> because for instance if I let a jboss running nightly builds testing with a lot of deployments
[23:58:21] <aslak> jose_freitas, builder.undeploy(runtimeName).remove(runtimeName).build()
[23:58:43] <jose_freitas> at the end of a week I'll have like 300M
[23:58:46] <jose_freitas> on the data folder
[23:58:50] <aslak> remove states pr javadoc: Indicates the specified deployment content should be removed from the content repository..
[23:59:11] <jose_freitas> where can I call that?
[23:59:24] <aslak> jose_freitas, no, that's what's being called..
[23:59:35] <jose_freitas> ahn, so it should be deleting?
[23:59:57] <aslak> as far as i can tell.. :)





top