[00:09:09] *** bleathem has quit IRC
[00:24:24] *** lightguard_jp has quit IRC
[00:32:10] *** stuartdouglas has quit IRC
[00:35:16] <aslak> ha, so much for the ExceptionProxy deserialization issue fix
[00:35:55] <aslak> not that it doesn't work, it's just that it needs to be a unknown exception during @Test. DeploymentException are still the same of course since they some in via a completely different api
[00:36:02] <aslak> e.g. JBoss ProfileService
[01:04:29] <jbossbot> git [arquillian] push master 1ada258.. Andy Gibson ARQ-299 Proxy server side exceptions and re-create them on the client if possible
[01:04:30] <jbossbot> jira [ARQ-299] Create a IN_CONTAINER Exception Proxy [Open (Unresolved) Feature Request, Major, Andy Gibson] https://issues.jboss.org/browse/ARQ-299
[01:04:30] <jbossbot> git [arquillian] push master f417aa6.. Andy Gibson ARQ-299 Proxy server side exceptions and re-create them on the client if possible  (removed debug material)
[01:04:31] <jbossbot> git [arquillian] push master f536d42.. Andy Gibson ARQ-299 Proxy server side exceptions and re-create them on the client if possible  (added JBoss header)
[01:04:31] <jbossbot> git [arquillian] push master db5044f.. Andy Gibson ARQ-299 Proxy server side exceptions and re-create them on the client if possible  (added JBoss header and class level comment)
[01:04:31] <jbossbot> git [arquillian] push master 7184879.. Aslak Knutsen ARQ-229 Set the stack trace of the non reconstructable exception when proxying so we dont lose it.
[01:04:36] 
[01:04:37] <jbossbot> git [arquillian] push master URL: http://github.com/arquillian/arquillian/compare/0e8594a...7184879
[01:05:48] <jbossbot> git [arquillian] push master e48f5dc.. Aslak Knutsen ARQ-299 Set the stack trace of the non reconstructable exception when proxying so we dont lose it.
[01:05:48] <jbossbot> jira [ARQ-299] Create a IN_CONTAINER Exception Proxy [Open (Unresolved) Feature Request, Major, Andy Gibson] https://issues.jboss.org/browse/ARQ-299
[01:05:49] <jbossbot> git [arquillian] push master URL: http://github.com/arquillian/arquillian/compare/7184879...e48f5dc
[01:09:27] *** aslak has quit IRC
[01:23:03] *** maeste is now known as maeste_zzzz
[01:34:24] *** michaelschuetz has quit IRC
[01:38:19] *** kpiwko has quit IRC
[02:00:28] *** jeand has quit IRC
[03:38:20] *** ldimaggi has quit IRC
[03:43:03] *** bgeorges has joined #jbosstesting
[03:59:29] *** lightguard_jp has joined #jbosstesting
[04:18:36] *** bgeorges has quit IRC
[04:21:42] *** bleathem has joined #jbosstesting
[04:22:05] <lightguard_jp> No aslak :(
[04:22:22] <lightguard_jp> Call called ProtocolMetaData with javadoc that says ProtocolMetaData does me no good.
[04:23:00] <lightguard_jp> Gah, we really have to work on javadoc in arquillian
[04:30:04] <bobmcw> lightguard_jp: we need more /** Fetches the value of foo. */ Foo getFoo();
[04:30:47] *** bgeorges has joined #jbosstesting
[04:32:42] <lightguard_jp> bobmcw: I dispise javadoc on getter and setter methods
[04:33:16] <lightguard_jp> mojavelinux: How familiar are you with the arquillian code?
[04:37:38] *** bobmcw has quit IRC
[06:05:25] *** bobmcw has joined #jbosstesting
[06:52:02] *** rruss has quit IRC
[07:37:32] *** oskutka has joined #jbosstesting
[07:41:21] *** bleathem has quit IRC
[07:44:38] <jbossbot> git [shrinkwrap] push master 38a2274.. Andrew Lee Rubinger [SHRINKWRAP-230] Create an integration point w/ the Descriptors project
[07:44:42] <jbossbot> jira [SHRINKWRAP-230] Create a ShrinkWrap Descriptors extension module [Open (Unresolved) Feature Request, Major, Andrew Rubinger] https://issues.jboss.org/browse/SHRINKWRAP-230
[07:44:42] <jbossbot> git [shrinkwrap] push master URL: http://github.com/shrinkwrap/shrinkwrap/compare/4cdd13b...38a2274
[07:45:20] *** mgoldmann has joined #jbosstesting
[07:50:46] <nickarls> goooood morning
[07:58:43] <jbossbot> git [descriptors] push master 36d443b.. Aslak Knutsen SHRINKDESC-38 Add support for Descriptor.getDescriptorName
[07:58:44] <jbossbot> jira [SHRINKDESC-38] Support Descriptor.name [Open (Unresolved) Feature Request, Major, Aslak Knutsen] https://issues.jboss.org/browse/SHRINKDESC-38
[07:58:44] <jbossbot> git [descriptors] push master URL: http://github.com/shrinkwrap/descriptors/compare/8ff7490...36d443b
[08:04:12] *** jharting has joined #jbosstesting
[08:05:51] *** Jaikiran has joined #jbosstesting
[08:47:39] *** ge0ffrey has joined #jbosstesting
[08:53:18] *** aslak has joined #jbosstesting
[08:58:19] *** lightguard_jp has quit IRC
[09:01:14] *** bgeorges has quit IRC
[09:10:38] *** michaelschuetz has joined #jbosstesting
[09:18:34] *** mgoldmann_ has joined #jbosstesting
[09:18:34] *** mgoldmann has quit IRC
[09:24:09] <nickarls> arq master appears to be working for jbossas-managed-6 again
[09:24:34] <nickarls> the test archive does contain a lot of maven and shrinkwrap stuff that can be left out, though.
[09:28:29] <aslak> maven?
[09:28:34] *** Jaikiran has quit IRC
[09:28:36] <aslak> nickarls,
[09:31:39] <nickarls> aslak,
[09:32:05] <nickarls> yes, I saw a bunch of maven stuff in the war
[09:32:14] <aslak> shrinkwrap-maven you mean?
[09:33:02] <nickarls> I thought the libs started with maven but it probably origins from the SW-maven resolves
[09:33:21] <aslak> i would hope so.. :)
[09:33:56] <aslak> in the deployment you should only a have a arq-core.jar tho. which is where arq and sw is bundled
[09:42:54] *** Jaikiran has joined #jbosstesting
[09:45:37] <nickarls> aslak: is there some way of outputting the final-final archive?
[09:47:01] <aslak> nickarls, https://github.com/arquillian/arquillian/blob/master/containers/glassfish-embedded-3.1/src/test/resources/arquillian.xml
[09:50:49] *** maeste_zzzz is now known as maeste
[09:53:45] <nickarls> aslak: I get http://pastebin.com/ZkbGv6hL
[09:53:54] *** kpiwko has joined #jbosstesting
[09:54:23] <aslak> ?
[09:54:48] <aslak> oh, your using the the MavenResolver
[09:54:53] <nickarls> (oracle-jdbc, jxl, poi, dbtesting are mine)
[09:54:54] <nickarls> yep.
[09:55:25] <aslak> pastebin your @Deployment setup
[09:56:04] <aslak> hey hey! not all bad. Atleast we have full maven resolve support, right ?!
[09:56:18] <aslak> getting a few extra libs along the way, that's the Maven way
[09:56:20] <aslak> ;)
[09:57:08] <kpiwko> nickarls: I missed the rest of the discussion, but you can either use StrictFilter or exclusion("*") to get the dependencies you specified only
[09:57:25] <nickarls> yep. it even includes an own maven in case you don't have one! ;-)
[09:57:28] <nickarls> aslak: http://pastebin.com/p9JC72u9
[09:57:59] <nickarls> ah, it pulls in the transitive deps?
[09:58:05] <kpiwko> nickarls: yes
[09:58:22] <aslak> nickarls, probably coming in from the dbtesting ?
[09:59:34] <aslak> kpiwko, should we stop the transitive deps madness, and have StrictFilter be default?
[10:00:11] <aslak> probably to much complaints..
[10:00:17] <kpiwko> aslak: hard to decide from mpov , I guess users should decide
[10:00:30] <kpiwko> aslak: if users are complaining, make strict default, yes
[10:01:21] <nickarls> aslak: I had arq as compile time dep, that shouldn't pull it in, right (even if test is better)?
[10:01:45] <aslak> compile means trans dep
[10:02:02] <nickarls> ok, that would explain it, have to give it a try
[10:02:24] <aslak> provided or test should fix it
[10:03:05] <aslak> wonder if, provided but atleast of v. X is a feature
[10:05:27] <nickarls> stilll huge archive with test scope in arq in dbtesting
[10:05:45] <aslak> nickarls, did you install it?
[10:05:53] <aslak> the new v. that is
[10:07:52] <aslak> 2.4 sec startup time on AS 7 beta-.. not bad
[10:08:33] <aslak> even with the arq subsystem: org.jboss.as.arquillian] Activating Arquillian Subsystem
[10:10:08] *** vtunka has joined #jbosstesting
[10:11:01] <nickarls> now I get a Can not get connection to server. Problem establishing socket connection for InvokerLocator [socket://FIKARLSNIC01:62394/]
[10:11:04] <nickarls> aslak: install what?
[10:11:19] *** wolfc has joined #jbosstesting
[10:11:25] <aslak> mvn install -f dbtests/pom.xml
[10:11:44] <nickarls> yep
[10:13:34] <aslak> sounds like the famous ubuntu issue.. does that HostName resolve to where jboss is running(ip), or should it be where the client is running.
[10:14:08] <aslak> brb, coffee
[10:14:32] *** alesj has joined #jbosstesting
[10:25:12] <nickarls> got it deploying, had to reboot since network got messed up when I tried the VPN client
[10:26:25] <nickarls> now I get a "Can't find a persistence unit named 'null' in AbstractVFSDeploymentContext"
[10:26:48] <nickarls> which is strange since I have a persistence.xml point at DefaultDS in META-INF
[10:34:15] <aslak> kpiwko, do you know this guy? http://www.jboss.org/events/JUDCon/day1track3.html#1030AM
[10:34:58] <kpiwko> aslak: never heard of him
[10:35:23] <aslak> kpiwko, wonderig if he's using Drone
[10:35:51] <alesj> aslak: I think that's the guy who won that "best spec" award
[10:35:59] <aslak> alesj, that i know.. :)
[10:36:33] <aslak> alesj, or was told yesterday.. hehe
[10:38:39] <aslak> nickarls, no idea why you get that btw.. probably something wrong with your deployment.. ;)
[10:38:40] <alesj> :-)
[10:41:54] <nickarls> it worked in alpha4(tm) ;-)
[10:46:55] <aslak> nickarls, aa, but do you have it where you think you do ?
[10:47:07] <aslak> nickarls, the SW API has changed a bit around WebArchives
[10:47:34] <aslak> addWebResource -> addAsWebInfResource /WEB-INF
[10:47:48] <aslak> addResource -> addAsResource /WEB-INF/classes
[10:48:14] <aslak> addManifestResource -> addAsManifestResource /META-INF
[10:48:46] <aslak> nickarls, your beans.xml should be addAsWebInfResource
[10:51:35] <nickarls> apparently in META-INF in root and not under WEB-INF/classes...
[10:52:21] * nickarls loves API changes but I guess thats what you have to live with with pre-final stuff...
[10:52:59] <aslak> yea..  there was some discussion there. i think Andrew found that /META-INF is a valid location for Wars as well pr spec, even tho WEB-INF/classes/META-INF is more commonly used, to the ManifestContainer is mapped against /META-INF
[10:53:23] <aslak> to/so
[10:54:48] <aslak> https://issues.jboss.org/browse/SHRINKWRAP-241
[10:54:50] <jbossbot> jira [SHRINKWRAP-241] remap targets for WebArchive add* methods [Closed (Done) Feature Request, Blocker, Andrew Rubinger] https://issues.jboss.org/browse/SHRINKWRAP-241
[10:55:44] <nickarls> umm, I guess I need a filter for my deps. With test scope, it doesn't compile, with compile scope, the deps are pulled in...
[10:55:58] <aslak> provided
[10:56:23] <nickarls> ah, yes, that's possible too
[11:02:22] <nickarls> addAsWebInf* drop it (surprise, surprise) directly into WEB-INF
[11:02:39] <nickarls> what's the correct way of getting it into WEB-INF/classes/META-INF?
[11:03:02] <kpiwko> aslak, is is possible to get classcontext for a different class is test? see http://pastebin.com/d0BJZFuX
[11:03:46] <kpiwko> * to get ClassContext for a different classs in test
[11:04:34] <aslak> kpiwko, for the sake of test?
[11:04:42] <kpiwko> yes
[11:05:07] <kpiwko> I've registered two class contexts in @Before method
[11:05:18] <kpiwko> I mean activated
[11:05:36] <aslak> InstanceProducer?
[11:06:12] <kpiwko> no, instance is written into context in TestEnricher
[11:06:46] <kpiwko> with AbstractTestCase
[11:07:20] <aslak> A line 24: AbstractManagerTestBase registeres and activates Suite|Class|Test contexts in @Before, the owning Class is the TestCase class
[11:08:02] <kpiwko> here's the whole class http://pastebin.com/hfvTyvgu
[11:08:39] <aslak> kpiwko, aa
[11:08:53] <aslak> you can only activate on type of context pr Thread
[11:09:00] <kpiwko> ah
[11:09:03] <kpiwko> ok, that will help
[11:09:21] <kpiwko> I'll rewrite that after lunch :)
[11:09:25] * kpiwko having lunch
[11:09:29] <aslak> :)
[11:16:09] *** timte has joined #jbosstesting
[12:03:50] * kpiwko beck
[12:03:54] * kpiwko back
[12:21:49] *** aslak has quit IRC
[12:22:43] *** aslak has joined #jbosstesting
[12:35:29] *** michaelschuetz has quit IRC
[12:35:42] <nickarls> is there a better approach than .addAsResource("persistence.xml", ArchivePaths.create("WEB-INF/classes/META-INF", "persistence.xml")); to get to that path?
[12:36:10] <nickarls> addAsWebInfResource and start one path element later?
[12:46:07] *** Jaikiran has quit IRC
[12:46:21] *** Jaikiran has joined #jbosstesting
[12:48:31] <nickarls> wohoo, server-side dbunit integration working with jbossas-managed-6 and maven resolving \o/
[12:49:03] <kpiwko> nickarls: that's great!
[13:18:33] <nickarls> BTW are people using JUnit or TestNG more?
[13:25:43] <aslak> nickarls, doesn't matter. build it on the Arq SPIs.. :)
[13:25:48] <aslak> nickarls, and woho! :)
[13:27:45] <nickarls> I mean, are there any ordering, groups etc. that can be more closely coordinated with TestNG?
[13:28:14] <nickarls> I use a JUnit @Rule and a @Data(xls = "Foo.xls", ds = "java:/DefaultDS") on the test
[13:28:46] <nickarls> I have to pack the data myself, though currently
[13:32:06] *** OndejZizka has quit IRC
[13:32:16] *** OndejZizka has joined #jbosstesting
[13:35:17] *** bgeorges has joined #jbosstesting
[13:37:45] *** michaelschuetz has joined #jbosstesting
[13:49:11] *** jeand has joined #jbosstesting
[13:49:39] *** rruss has joined #jbosstesting
[14:02:58] *** rruss has quit IRC
[14:04:26] *** ldimaggi has joined #jbosstesting
[14:18:56] <aslak> nickarls, you can order in testng, but that does not work in arq
[14:19:20] <aslak> nickarls, since we filter on single methods and reexecute the whole suite pr @test incontainer
[14:20:32] <nickarls> is there any way of running an entire test suite so that there are junit tests, in-container tests run with the embedded weld profile and in-container tests against embedded/managed jboss?
[14:20:43] <nickarls> the latter two cases being the most difficult, I guess?
[14:21:33] <nickarls> GF 3.1 is marketing the high availability cluster stuff, JBoss needs a counter-strike demo ;-)
[14:23:01] *** jeand has quit IRC
[14:24:04] <aslak> nickarls, i'm not quite following?
[14:24:40] *** jeand has joined #jbosstesting
[14:29:23] <nickarls> aslak: on the test-suit running?
[14:29:32] <aslak> nickarls, oh, you mean the same tests against both containers in same run?
[14:29:49] <nickarls> aslak: yes, I'd like to run the fastest one that can handle the test
[14:30:04] <nickarls> in some cases embedded weld would be fine
[14:31:09] <aslak> nickarls, you want normal junit tests and arq tests in the same run?
[14:31:34] <aslak> or you want arq tests ran both in embedded and managed in the same run?
[14:31:43] <aslak> or you want to switch between embedded and managed ?
[14:32:29] <nickarls> junit for some, embedded for some, managed for some ;-)
[14:33:18] <aslak> in theory you can
[14:34:14] <aslak> using the new multi container support you can deploy against 'named' containers. you can of course switch in config what type of server that named one is..
[14:34:58] <aslak> @Deployment @Target("full"), then in arq.xml define a jboss managed server to be named full
[14:35:07] <aslak> havn't tested that scenario, but should work
[14:35:39] <aslak> i doubt you get embedded to run in that mode tho, it's a bit tricky classloader wise. managed/remote should work. embedded tomcat works.
[14:36:11] <aslak> you then move the container deps from maven profiles to arq.xml
[14:36:25] <aslak> it's a bit experimental atm tho.. but it's there
[14:37:06] <aslak> see the infinispan demo, https://github.com/aslakknutsen/infinispan-intersite-demo/blob/arq-beta1/src/main/resources/arquillian.xml
[14:37:09] <nickarls> I usually run managed, I usually end up getting strange classloader issues with embedded
[14:37:17] <aslak> https://github.com/aslakknutsen/infinispan-intersite-demo/blob/arq-beta1/src/main/java/drumport/ContainerTestCase.java
[14:43:43] <jbossbot> git [arquillian] push master 937650b.. Aslak Knutsen ARQ-383 Rename maxDeploymentsBeforeRestart. With multiple deployments pr TestClass the option should be maxTestClassesBeforeRestart.
[14:43:46] <jbossbot> jira [ARQ-383] rename MaxDeploymentsBeforeRestart to maxTestClassesBeforeRestart [Open (Unresolved) Feature Request, Major, Aslak Knutsen] https://issues.jboss.org/browse/ARQ-383
[14:43:46] <jbossbot> git [arquillian] push master URL: http://github.com/arquillian/arquillian/compare/e48f5dc...937650b
[14:58:09] <aslak> i crazy love git
[15:07:31] <aslak> bobmcw, did you get it to work?
[15:10:35] <bobmcw> aslak: sorry, other yaks distracted me yesterday
[15:10:56] <aslak> ok
[15:25:19] *** timte has quit IRC
[15:37:10] *** oskutka has quit IRC
[15:37:16] *** alesj has left #jbosstesting
[15:39:31] *** Jaikiran is now known as Jaikiran|brb
[15:49:40] *** bgeorges has quit IRC
[15:53:10] *** bleathem has joined #jbosstesting
[16:01:17] *** ALR has joined #jbosstesting
[16:02:26] <ALR> Hello, all.
[16:02:45] <ALR> Let's go for Take Two of the ShrinkWrap Community Meeting, eh? :)
[16:03:10] <ALR> Let's go for an explicit roll-call before getting started.
[16:03:33] <ALR> aslak, mojavelinux, kpiwko.
[16:04:08] <kpiwko> ALR: I'm here and ready :)
[16:04:17] <ALR> Suhweet
[16:04:38] <ALR> Will wait a bit on the other guys to see if they're pulling a "me".
[16:04:48] *** rruss has joined #jbosstesting
[16:06:36] <aslak> ALR, yo
[16:06:46] <ALR> aslak: Amazing.
[16:09:19] <ALR> aslak, kpiwko: Should we consider this a quorum, then?
[16:10:26] <kpiwko> ALR: I can wait a bit
[16:11:20] <ALR> Another 3 minutes, then we'll dive in.  I can note Dan's issues specifically, and I know we were both up late into the night emailing/working.
[16:11:28] <ALR> So that may be a factor.
[16:12:38] <aslak> dan is awake, just not ir c
[16:13:07] <ALR> aslak, kpiwko: How do you feel about Skype voice-ing this?
[16:13:19] <aslak> ok with me
[16:13:44] <kpiwko> ALR: have no skype...forbidden here
[16:13:53] <ALR> Ah OK.
[16:14:01] <ALR> Technically I think we're all forbidden.
[16:14:05] <ALR> So let's dive in.
[16:14:14] <ALR> I'll cap this meeting at 1 hour to keep us in line.
[16:14:16] <aslak> gtalk?
[16:14:27] <ALR> BUt really I'd prefer we not stretch longer than 30 minutes if possible.
[16:14:34] <ALR> I've 2 objectives for today.
[16:14:47] <ALR> 1) Figure out what we *need* to get to Beta
[16:14:58] <ALR> 2) Generally map out the next N releases to get there
[16:15:21] <ALR> I think a good jumping-off point is to comb through JIRA
[16:15:34] <ALR> There are currently 35 open issues.
[16:16:01] <ALR> I'll post ones worth discussion here so we can update accordingly.
[16:16:09] <ALR> https://issues.jboss.org/browse/SHRINKWRAP-85
[16:16:11] <jbossbot> jira [SHRINKWRAP-85] Support Event/Listener style callbacks [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-85
[16:16:36] <ALR> And I'll ask:
[16:16:41] <ALR> "After Beta"?
[16:16:53] <aslak> ALR, should only add to api
[16:16:54] <ALR> If "For Beta", we'll assign it there.
[16:16:57] <ALR> Right
[16:17:17] *** Jaikiran|brb is now known as Jaikiran
[16:17:28] <ALR> So for instance, SW-85 can stay unassigned to any release
[16:17:46] <aslak> yea
[16:17:51] <ALR> 216
[16:17:57] <ALR> IMO Beta
[16:18:23] <kpiwko> yea
[16:18:24] <aslak> ALR, let's use the boot..  SHRINKWRAP-216
[16:18:25] <jbossbot> jira [SHRINKWRAP-216] Update javadoc in api classes to reflect the reworked configuration mechanism [Open (Unresolved) Task, Blocker, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-216
[16:18:52] <ALR> aslak: Boot?
[16:18:55] <aslak> bot
[16:19:17] <ALR> Ah yes
[16:19:19] <aslak> noone knows the issues by heart, and we all have to look them up so
[16:19:24] <ALR> SHRINKWRAP-58 : I'm making Beta
[16:19:26] <jbossbot> jira [SHRINKWRAP-58] Add overview.html, package.html for JavaDoc [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-58
[16:19:44] <ALR> SHRINKWRAP-88
[16:19:45] <aslak> i agree to both of those as beta
[16:19:45] <jbossbot> jira [SHRINKWRAP-88] Look at Import/Export API methods for consistency/convenience [Open (Unresolved) Task, Major, Aslak Knutsen] https://issues.jboss.org/browse/SHRINKWRAP-88
[16:19:51] <kpiwko> so do I
[16:19:52] *** lightguard_jp has joined #jbosstesting
[16:20:06] <kpiwko> is there a jira for docbook as well?
[16:20:13] <aslak> ALR, yea, was wondering about those. same with the unify importers etc.. you have done those with the StreamIMporter/Exporter right ?
[16:20:25] <aslak> kpiwko, should be one for docs
[16:20:53] <ALR> Also I'm unassigning these unless someone is currently working on it, or is definitely the best guy for the job
[16:21:03] <aslak> sure
[16:21:18] <ALR> SHRINKWRAP-110
[16:21:24] <jbossbot> jira [SHRINKWRAP-110] Code Review and Action Items on ExtensionLoader/ServiceExtensionLoader [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-110
[16:21:57] <ALR> This one is very outdated but still needs the review before completed.
[16:22:11] <ALR> The only question is if any of it leaks into the user API
[16:22:27] <aslak> ALR, some what via Configuraiton
[16:22:46] <ALR> aslak: Yeah, and ExtensionLoader
[16:23:00] <ALR> OK, so Beta
[16:23:11] <aslak> ServiceExtensionLoader is impl and expose a SPI for extension loading, ExtensionLoad is API i believe
[16:23:30] <ALR> SHRINKWRAP-112, SHRINKWRAP-113
[16:23:31] <jbossbot> jira [SHRINKWRAP-112] Create a Unified Importer API [Open (Unresolved) Feature Request, Major, Aslak Knutsen] https://issues.jboss.org/browse/SHRINKWRAP-112
[16:23:32] <jbossbot> jira [SHRINKWRAP-113] Create a Unified Exporter API [Open (Unresolved) Feature Request, Major, Aslak Knutsen] https://issues.jboss.org/browse/SHRINKWRAP-113
[16:23:47] <aslak> ALR, those are StreamExporter StreamImporter no?
[16:24:03] <ALR> Might just be, reading the full descriptions now
[16:24:43] <ALR> In your request you note some auto-knowing of what to do based on types
[16:24:47] <aslak> ALR, aa, well.. it has one more level. to remove the need to know the specific importer
[16:24:48] <aslak> yea
[16:24:51] <ALR> The StreamImporters are explicit.
[16:25:01] <ALR> Though they *do* have a unified entry point.
[16:25:15] <ALR> aslak: So the question is if you're satisfied w/ the current stuff
[16:25:27] <ALR> Or wanna add the bits which do the guesswork.
[16:25:58] <aslak> skip the guess work for beta atleat. it won't change anything
[16:27:12] <ALR> My feelings too
[16:27:33] <ALR> SHRINKWRAP-138: Leaving unsched
[16:27:34] <jbossbot> jira [SHRINKWRAP-138] Update 'Code Sample' and 'API Guide' sections of Wiki [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-138
[16:27:53] <aslak> mm
[16:28:11] <ALR> SHRINKWRAP-139: Unsched; or will it at all impact the core APIs?
[16:28:12] <jbossbot> jira [SHRINKWRAP-139] Ability to generate OSGi bundle headers [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-139
[16:28:23] <ALR> That's an extension, no?
[16:29:05] <aslak> yea would say so
[16:30:20] <ALR> SHRINKWRAP-172, SHRINKWRAP-175, SHRINKWRAP-179: Beta
[16:30:21] <jbossbot> jira [SHRINKWRAP-172] Clean up API [Open (Unresolved) Task, Major, Andrew Rubinger] https://issues.jboss.org/browse/SHRINKWRAP-172
[16:30:22] <jbossbot> jira [SHRINKWRAP-175] Review Filter usage in API for consistency and applicability [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-175
[16:30:23] <jbossbot> jira [SHRINKWRAP-179] Container.setXX methods should support the new Package construct [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-179
[16:30:50] <ALR> SHRINKWRAP-187: Unsched
[16:30:55] <jbossbot> jira [SHRINKWRAP-187] Existing folders will silently be overwritten by files [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-187
[16:31:12] <aslak> sure
[16:31:22] <ALR> SHRINKWRAP-188: Unsched
[16:31:31] <jbossbot> jira [SHRINKWRAP-188] WebArchive.addWebResource(File resource, ArchivePath target) doesn't create directory within WEB-INF and file is stored under target's name [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-188
[16:31:46] <ALR> SHRINKWRAP-191...thoughts?
[16:31:47] <jbossbot> jira [SHRINKWRAP-191] Automatic creation of MANIFEST.MF [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-191
[16:33:04] <aslak> extension, using dynamic registration of listeners or something.. :)
[16:34:17] <aslak> it's not required right? would be strange to force it i think
[16:34:21] <ALR> aslak: I don't think it's an extension
[16:34:36] <ALR> aslak: Though I don't think it breaks compatibility in any way, either
[16:34:59] <ALR> SHRINKWRAP-227
[16:35:01] <jbossbot> jira [SHRINKWRAP-227] Assignable#as() is confusing for Archive implementors [Open (Unresolved) Bug, Major, Aslak Knutsen] https://issues.jboss.org/browse/SHRINKWRAP-227
[16:35:09] <ALR> Umm...
[16:35:19] <aslak> javadoc
[16:35:51] <kpiwko> 227 should go to beta, it's javadoc
[16:36:47] <ALR> Ah OK
[16:36:54] <ALR> I was thinking more from a code standpoint
[16:37:04] <ALR> Where archive implementors extending from ArchiveBase have to do nothing
[16:37:08] <ALR> As it's implemented there
[16:37:56] <ALR> SHRINKWRAP-239
[16:37:57] <jbossbot> jira [SHRINKWRAP-239] Support the notion of shrinkwrap BundleArchive [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-239
[16:38:15] <kpiwko> btw, 191 it's not an extension but a good candidate for extension spi...I can imagine signing generated artifact ;)
[16:38:19] <ALR> Unsched, it's an add-on, not part of existing
[16:38:25] <aslak> mm
[16:38:54] <ALR> SHRINKWRAP-233
[16:38:57] <jbossbot> jira [SHRINKWRAP-233] addClass with DefaultPackage opens addPackage to null arguments [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-233
[16:38:58] <ALR> kpiwko: Yes, agree
[16:39:40] <ALR> aslak: For 233, does your proposed split of methods impact the user view/API?
[16:39:56] <aslak> ALR, no, impl detail.
[16:40:06] <ALR> aslak: OK
[16:40:09] <ALR> SHRINKWRAP-236
[16:40:12] <jbossbot> jira [SHRINKWRAP-236] Introduce content read criteria to find contents in Archive [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-236
[16:40:13] <aslak> possible javadoc with @throws illegalarguemnt on null
[16:40:20] <ALR> I say unschedule it
[16:41:45] <aslak> i like the idea of a more queriable archive, but there is nothing here that's can't be done as a extension. either passing the archive to the query or the query behave as a Filter
[16:44:22] <ALR> Not even an extension necessarily.
[16:44:37] <ALR> Remember we can ADD to the API just fine, bumping the "minor" release number when we do.
[16:44:50] <aslak> sure.. i ment to say, no change needed
[16:44:56] <ALR> SHRINKWRAP-244
[16:44:57] <jbossbot> jira [SHRINKWRAP-244] When calling JavaArchiveImpl.addClass(String, ClassLoader) the TCCL gets used instead [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-244
[16:45:09] <ALR> Unsched
[16:45:26] <ALR> SHRINKWRAP-245: Beta
[16:45:31] <jbossbot> jira [SHRINKWRAP-245] Evaluate the need for EnterpriseArchive.addApplicationResource [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-245
[16:46:08] <ALR> SHRINKWRAP-246: Thoughts?
[16:46:10] <jbossbot> jira [SHRINKWRAP-246] Shrinkwrap does not work in a modular environment [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-246
[16:47:29] <aslak> not sure about 245... addApplicationResource == addManifestResource
[16:47:51] <ALR> aslak: Don't need an answer, just need to know if it affects API potentially. :)
[16:47:53] <ALR> Which it does.
[16:47:58] <aslak> it does
[16:48:30] <ALR> 246...does this require API changes to fulfill?
[16:48:36] <ALR> I think not.
[16:48:40] <aslak> i would say probably
[16:48:46] <ALR> The OSGi stuff will bypass the ShrinkWrap.create() syntax
[16:48:59] <ALR> And we may *add* hooks to make archive creation more manual.
[16:49:10] <ALR> But we're not going to be changing the ShrinkWrap.create TCCL shorthand.
[16:49:17] <ALR> ........right?
[16:49:32] <aslak> well, that's the problem i think.
[16:49:39] <ALR> Good, let's talk.
[16:49:43] <ALR> What's the problem?
[16:49:49] <aslak> a dev will use SW.create(), then OSGi'ify his module and it will fail
[16:49:57] <ALR> Hrm.
[16:50:06] <aslak> or someone else will
[16:50:16] <ALR> OK, so we need to get this OSGi shit figured out ASAP
[16:50:24] <ALR> Like in the next Alpha or 2.
[16:50:33] <aslak> but if OSGi could hook into the background and overide the behavir, we shouldn't need api changes, but rather spi changes
[16:50:55] <ALR> Setting to Beta and Blocker
[16:51:08] <aslak> yea
[16:51:08] <ALR> Well, critical.
[16:52:44] <ALR> SHRINKWRAP-235 I wanna reject
[16:52:47] <jbossbot> jira [SHRINKWRAP-235] Add print methods to Archive [Open (Unresolved) Feature Request, Minor, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-235
[16:53:50] <aslak> ALR, maybe a bit odd, but archive.toString(Formatter.PRINT) ?
[16:54:01] *** jharting has quit IRC
[16:54:12] <ALR> aslak: Formatters don't print.
[16:54:22] <aslak> as i said.. a bit od
[16:54:23] <aslak> :)
[16:54:32] <ALR> aslak: Hehe, it'd be:
[16:54:53] <ALR> archive.toString(new Formatter.STOUT(Formatter formatter))
[16:54:58] <ALR> Like wrapping a Formatter in a Formatter
[16:55:10] <ALR> I say this one isn't our problem.
[16:55:23] <lightguard_jp> Why would you do that?
[16:55:26] <ALR> Anyone strongly disagree?
[16:55:30] <ALR> lightguard_jp: Do what?
[16:55:37] <ALR> I have no idea. I wouldn't.
[16:55:38] <lightguard_jp> It gives you a string, just put it in the log or sop
[16:55:42] <ALR> I'd do:
[16:55:50] <ALR> log.info(archive.toString(Formatter))
[16:55:51] <lightguard_jp> The Formatter.STOUT(formatter)
[16:55:54] <lightguard_jp> Right
[16:56:07] <lightguard_jp> That's what I'm saying the Formatter.STOUT(...) seems very odd
[16:56:10] <aslak> lightguard_jp, the point is it's easier to type war.print() then System.out.println(war.toString(Formatter.VERBOSE));
[16:56:11] <ALR> aslak: ^ Confirm reject?
[16:56:21] <ALR> aslak: That's true it is.
[16:56:28] <ALR> Easier and mixing concerns IMO
[16:56:42] <lightguard_jp> easier to type yes, but it's certainly more clear what's going on with the former.
[16:56:52] <aslak> yea.. :)
[16:56:56] <ALR> Rejecting.
[16:56:58] <aslak> sure
[16:56:59] <ALR> FU, Dan.
[16:57:03] <aslak> hehe
[16:57:11] <lightguard_jp> lol
[16:57:20] <aslak> he's not around to defend so.. reject
[16:57:21] <lightguard_jp> mojavelinux: Sorry, you lose on that one
[16:58:04] <mojavelinux> damnit, I finally realize i'm supposed to be paying attention
[16:58:06] <mojavelinux> and I get no love
[16:58:11] <ALR> Oooh, sorry.
[16:58:15] <mojavelinux> hehehe
[16:58:16] <ALR> mojavelinux: Make your case here.
[16:58:27] <ALR> It's not etched in stone.
[16:58:31] <mojavelinux> Java sucks so we try to fix it using shrinkwrap :)
[16:58:38] <mojavelinux> why can't we just do println()
[16:58:41] <mojavelinux> why the System.out business
[16:58:58] <mojavelinux> but yes, you are right, trying to shoehorn it into toString() just sounds bad
[16:59:18] <ALR> Hehe, everything's easier in a global namespac.
[16:59:20] <ALR> *namespace
[16:59:40] <ALR> "Why System.out.println()" was my first thought in my first CS101 class.
[16:59:42] <mojavelinux> one idea is toStream()
[16:59:48] <ALR> I was like, "Damn, that's a lot of shit to remember"
[16:59:58] <mojavelinux> where it takes a stream
[17:00:08] <mojavelinux> the idea is to avoid the wrapping of method calls
[17:00:10] <mojavelinux> and inline it
[17:00:12] <mojavelinux> so like
[17:00:19] <mojavelinux> toStream(true, System.out)
[17:00:26] <mojavelinux> writeToStream()
[17:00:27] <ALR> toStream(Formatter) I can get on board with
[17:00:28] <mojavelinux> something like that
[17:00:50] <mojavelinux> I'm okay with having to specify the System.out bit tooo
[17:00:54] <mojavelinux> it's just this I don't like
[17:00:55] <ALR> Excuse me: toStream(OutputStream,Formatter)
[17:01:01] <mojavelinux> System.out.println(archive.toString(true));
[17:01:05] <mojavelinux> right
[17:01:06] <mojavelinux> so like
[17:01:09] <lightguard_jp> I like writeTo (writeToStream is okay too)
[17:01:17] <mojavelinux> archive.toStream(System.out, Formatter.VERBOSE)
[17:01:23] <lightguard_jp> writeTo(Stream, Formatter)
[17:01:25] <mojavelinux> yep
[17:01:25] <aslak> just as much
[17:01:30] <ALR> writeTo(Stream,Formatter) it is
[17:01:32] <aslak> to type
[17:01:47] <ALR> mojavelinux: Reopen and change the title, description to match?
[17:02:03] <mojavelinux> it's not that we are cutting down on characters, java just seems to suck that that, it's that we are making the concerns not be like a reverse polish notation calculator
[17:02:03] <ALR> (Though IMO it's still superfluous)
[17:02:10] <lightguard_jp> Couldn't this also be used in place of things like ZipOutput?
[17:02:24] <lightguard_jp> We could have overrides.
[17:02:30] <aslak> sysout + ALT +space + jar.toString(true)
[17:02:42] <ALR> Crap, we're really burning through the hour.
[17:02:43] <mojavelinux> exactly, we do it that way for everything else, but to go to system.out we have to do this whole wrapping business, that's what I hate
[17:02:46] <ALR> Only 10 minutes left.
[17:02:54] <ALR> So I can handle the rest of the JIRA inventory
[17:02:59] <mojavelinux> anyway, I'll reopen with explaination...it's about fluedity, but not that critical
[17:03:01] <ALR> But what I really need from you guys now is:
[17:03:01] <mojavelinux> what's left
[17:03:13] <ALR> We've covered which API things may change
[17:03:19] <ALR> But there's also the module layout of SW
[17:03:32] <ALR> Beta means we gotta solidify groupIds,artifactIds
[17:03:39] <mojavelinux> yep
[17:03:46] <ALR> So we need to know our breakout strategy, if we have one.
[17:03:52] <ALR> Currently all is in the same release cycle.
[17:04:19] <ALR> So I'll propose a plan, and everyone can agree or not.
[17:04:23] <mojavelinux> go for it
[17:04:28] <ALR> General rule: All modules stay as-is.
[17:04:33] <ALR> Exceptions:
[17:04:38] <ALR> Container integrations
[17:04:45] <ALR> GFv3, OpenEJB, Tomcat, etc
[17:05:18] <ALR> And extension-descriptors has to come out too
[17:05:26] <ALR> Because Descriptors won't be locked API in time.
[17:05:30] <kpiwko> right
[17:05:34] <ALR> The rest can stay in place as part of the SW release cycle.
[17:05:37] <ALR> WDYT?
[17:06:02] <lightguard_jp> I'm fine with that
[17:06:09] <aslak> ALR, vdf vfs?
[17:06:13] <ALR> http://pastebin.com/2LTdft1n
[17:06:21] <ALR> aslak: The APIs there aren't changing really.
[17:06:30] <ALR> We can keep 'em or leave 'em, no matter to me really.
[17:07:32] <aslak> i was thinking put things with external deps/integrations on their own release cycle, but that might be taking it a bit to far
[17:07:55] <ALR> aslak: Right, I'd originally thought that too.  But now I think more about who's maintaining it.
[17:08:01] <ALR> In the VDF/VFS case...we do.
[17:08:06] <aslak> yea
[17:08:13] <ALR> But the containers, we want the other vendors to suck 'em in
[17:08:22] <ALR> So they eventually go byebye from our repos entirely.
[17:08:34] *** ldimaggi has quit IRC
[17:08:59] <ALR> But this brings up the point that aslak and mojavelinux and I have been discussing
[17:09:04] <ALR> Is our organization correct?
[17:09:09] <mojavelinux> one of the best things we did in seam 3 was make modules out of things
[17:09:17] <ALR> Should spec archives and spec descriptors be bundled in modules together?
[17:09:23] <aslak> ugh, fuck webex
[17:09:26] <ALR> And each module is web, ejb, cdi, etc specific?
[17:09:28] <mojavelinux> because then people were able to code to a fixed api and actually get out multiple releases
[17:09:33] <mojavelinux> even when the dep isn't changing
[17:09:41] <mojavelinux> sucks when you have to force a release to fix a container issue
[17:09:47] <ALR> Right now it's split up where all spec stuff for Descriptors is together, all spec stuff for archives is together....
[17:10:41] <lightguard_jp> Do we see that stuff changing much though?
[17:10:47] <lightguard_jp> Descriptors maybe but archives?
[17:10:54] <ALR> If we change the organization, yeah
[17:10:54] <lightguard_jp> We have all the basic archives right?
[17:11:10] <lightguard_jp> Okay, maybe I misunderstood something :)
[17:11:12] <ALR> We could organize it such that WebAppDescriptor is right next to WebArchive in the same module
[17:11:26] <lightguard_jp> Hm, that may make more sense.
[17:11:32] <ALR> But we need to pick a layout and stick with it.
[17:11:58] <ALR> And I think a lot of people will not like having to declare extra / more confusing module deps for their projects...
[17:12:10] <lightguard_jp> I would think a user would expect all war related stuff to be in a war module
[17:12:20] <mojavelinux> I don't see a problem with having the artifact and descriptors for each spec together
[17:12:20] <ALR> artifactId = shrinkwrap-api-web, shrinkwrap-api-ejb, shrinkwrap-api-cdi
[17:12:21] <mojavelinux> right
[17:12:24] <lightguard_jp> That logical grouping seems to make more sense to me
[17:12:53] <aslak> ???
[17:12:57] <aslak> including sw?
[17:13:02] <ALR> Yes.
[17:13:10] <aslak> what spec Archives do you have in api-ejb ?
[17:13:10] <ALR> Consider this case though:
[17:13:16] <lightguard_jp> ALR: That's more straightforward looking at poms / deps to see what's going on and what's really being used.
[17:13:17] <aslak> or cdi
[17:13:27] <ALR> SHRINKDESC is for Descriptors
[17:13:34] <ALR> We could use it as a model for AS.
[17:13:50] <ALR> It's currently spec'd out as being an object model view of descriptors.
[17:14:08] <ALR> If we go this route of reorganization, it loses that
[17:14:15] <ALR> And gets coupled in w/ ShrinkWrap
[17:14:22] <aslak> ALR, any feed back on that?
[17:14:29] <ALR> Making it a poor / overspecified metamodel
[17:14:46] <ALR> aslak: Yes.  They love it, but it's not done, tested, or even past prototyping phase to consider.
[17:14:56] <aslak> ok
[17:15:02] <ALR> Basically an awesome idea but too immature.  "Do it and we'll talk".
[17:15:13] <ALR> Which I said in the proposal, basically :)
[17:15:24] <aslak> ALR, i guess the need is more read oriented tho
[17:15:41] <mojavelinux> i think both are important
[17:16:44] <aslak> or read from spec descs, write to 'internal' descs
[17:17:54] <aslak> i think at least sw-spec-web can depend on sw-desc-web, it doesn't have to include it
[17:18:04] <ALR> Maybe we should take this one to the forums.
[17:18:09] <ALR> I want to stew on it a bit too.
[17:18:15] <ALR> But yeah, this is coming down the pipes.
[17:18:20] <ALR> We need to know this ASAP.
[17:19:33] <lightguard_jp> ALR: Take it to the forums and see what we get.
[17:19:38] <ALR> Yup.
[17:19:44] <ALR> Thus concludes my agenda.
[17:19:48] <ALR> And we're a bit over time.
[17:19:54] <kpiwko> ALR: one more thing about beta
[17:19:55] <lightguard_jp> We could also divide them up then offer jars which include everything in one.
[17:19:59] <ALR> Anyone else have anything they'd like to raise while we're all here?
[17:20:05] <kpiwko> what about code coverage?
[17:20:18] <kpiwko> for tests
[17:20:21] <ALR> kpiwko: Ah yes. I monitor that manually.
[17:20:42] <ALR> kpiwko: And we have reports on my Hudson, but the reporting engine has a bug and for some packages reads 0%
[17:20:46] <kpiwko> do you have a skeloton each module can add?
[17:20:56] <ALR> So I look every now and again in the IDE:
[17:21:02] <ALR> Clover plugin I think it is
[17:21:08] <ALR> Coverage As > JUNit
[17:21:14] <ALR> A skeleton for what?
[17:21:15] <kpiwko> hmm, I'm familiar with emma
[17:21:26] <ALR> kpiwko: I think Emma is what we're using in the build.
[17:21:33] <ALR> kpiwko: Check build/pom.xml
[17:21:36] <ALR> Under "reporting"
[17:21:39] <ALR> It's configured there.
[17:21:44] <ALR> And runs when you do "mvn site"
[17:21:44] <kpiwko> ok, I'll check it
[17:22:39] <ALR> Class dismissed. :P
[17:22:47] <ALR> Thanks mojavelinux, aslak, lightguard_jp, kpiwko
[17:23:06] <mojavelinux> onward
[17:23:19] <ALR> And Thanks, Sacha.
[17:23:26] *** bgeorges has joined #jbosstesting
[17:24:11] <mojavelinux> hahaha
[17:24:15] <mojavelinux> he's here in spirit
[17:24:19] <ALR> https://twitter.com/#!/ALRubinger/status/48056345949241344
[17:25:51] <mojavelinux> woot
[17:29:25] *** michaelschuetz has quit IRC
[17:29:53] *** ldimaggi has joined #jbosstesting
[17:31:50] <jbossbot> git [descriptors] push master b8173a1.. Andrew Lee Rubinger [maven-release-plugin] prepare release 0.1.3
[17:31:50] <jbossbot> git [descriptors] push master URL: http://github.com/shrinkwrap/descriptors/compare/36d443b...b8173a1
[17:31:53] <jbossbot> git [descriptors] push master 791bcfd.. Andrew Lee Rubinger [maven-release-plugin] prepare for next development iteration
[17:31:53] <jbossbot> git [descriptors] push master URL: http://github.com/shrinkwrap/descriptors/compare/b8173a1...791bcfd
[17:38:31] <aslak> ALR, mojavelinux: Werner is trying to push of the judcon talk on someone: http://twitter.com/#!/wernerkeil/status/48057305689886720 http://twitter.com/#!/wernerkeil/status/48057642156961792
[17:39:11] <mojavelinux> what the foo is that?
[17:39:18] <mojavelinux> hey, maybe we will get a better draft pick then
[17:41:21] <aslak> maybe
[17:41:45] <ALR> "I am too important and awesome to attend the talks I applied to attend"
[17:42:44] <mojavelinux> you should volunteer for the heck of it (aslak) then we can change the title of the talk too
[17:43:12] <mojavelinux> dig it! http://goo.gl/fb/7Si0i
[17:43:13] <mojavelinux> woot!
[17:45:37] <aslak> yea
[17:46:26] <aslak> mojavelinux, lightguard_jp: did you guys finish the gf remote 3.1 yesterday?
[17:47:00] <mojavelinux> JAX is swimming in arquillian articles
[17:47:04] <mojavelinux> almost
[17:47:15] <aslak> mojavelinux, hehe yea, every release now
[17:47:18] <mojavelinux> Arquillian
[17:47:18] <mojavelinux> Taking the Pain out of Integration Tests
[17:48:03] <mojavelinux> cool, there is an article in there from Ales!
[17:48:24] <aslak> mojavelinux, i liked the outline: There is nothing comparable in terms of seamless container integration
[17:49:00] <mojavelinux> I love the picture...follow my command you drones
[17:49:18] <aslak> :)
[17:49:22] <lightguard_jp> mojavelinux: What do we want to do with GF 3.1 remote? It works currently, the same as it did before, but do we want to do enhancements or save that for later?
[17:49:39] <mojavelinux> Now, Arquillian aims to make this task easier by offering the first complete and integrated test suite for integration testing.
[17:49:43] <aslak> kpiwko, you still working on arq-387 ? (ref your pull comment)
[17:49:45] <mojavelinux> that's right bitches
[17:50:07] <mojavelinux> I think as long as it's functional for the moment, that's a win
[17:50:13] <mojavelinux> we can enhance on the way to beta1
[17:50:40] <aslak> mojavelinux, lightguard_jp: you got the ProtocolMetaData down?
[17:50:41] <mojavelinux> the one thing missing is that currently a deployment error results in the container failing with 404s
[17:50:44] *** lfryc has joined #jbosstesting
[17:51:27] <aslak> or you had to if you tested it.. (unless you hardcoded it of course)
[17:51:33] <kpiwko> aslak: arq-387 is done...I added one integration test and tried manually, everything is working...I updated SecurityActions from your suggestion as well
[17:52:08] <mojavelinux> jason, perhaps try to run some of the solder tests on glassfish 3.1 container since that's all setup already
[17:52:19] <mojavelinux> or I can give it a go...same branch as before?
[17:52:37] <aslak> kpiwko, ok, we call that good to go for now.. ;)
[17:53:06] <kpiwko> aslak: so I'm only missing arq-393 for a5 release
[17:53:27] <aslak> ARQ-393
[17:53:28] <jbossbot> jira [ARQ-393] Update Arquillian Drone Docbook [Open (Unresolved) Task, Major, Karel Piwko] https://issues.jboss.org/browse/ARQ-393
[17:53:33] <aslak> right
[17:53:34] <kpiwko> aslak: will work on it in the evening
[17:53:35] *** bgeorges has quit IRC
[17:53:40] <aslak> excellent
[17:54:36] <lightguard_jp> mojavelinux: Yes, same branch
[17:54:41] <lightguard_jp> aslak: Yeah, I got it
[17:54:49] <lightguard_jp> The basic tests I had worked
[17:54:51] *** ldimaggi has quit IRC
[17:55:06] <lightguard_jp> We need to create a test in there for failing deployments... Can we do that Aslak?
[17:55:30] <aslak> lightguard_jp, sure
[17:55:43] <aslak> lightguard_jp, use the @Expected(Exception) annotation
[17:55:52] <aslak> on @Deployment
[17:56:11] <lightguard_jp> @Test @Exepcted(..) ?
[17:56:11] <aslak> will be renamed during the night but. :)
[17:56:20] <aslak> @Deployment @Expected
[17:56:30] <lightguard_jp> Oh. Interesting. Nice :)
[17:56:40] <lightguard_jp> mojavelinux: We don't really get a whole back from rest :(
[17:57:12] <aslak> lightguard_jp, might want to look into DeploymentExceptionTransformer as well
[17:57:27] *** rruss has quit IRC
[17:57:51] <mojavelinux> yeah, that feature of Arq is huge...the expected deployment exception
[17:57:54] <mojavelinux> totally needed that
[17:57:56] <lightguard_jp> mojavelinux: http://blogs.steeplesoft.com/2011/02/deploying-applications-to-glassfish-using-curl/ if you have a war that dies on deploy you can use the info there to see what you get
[17:58:01] <lightguard_jp> It's not very helpful
[17:58:30] <mojavelinux> hmm
[17:58:30] <lightguard_jp> Is there anything to test with that or it's just the deployment and the exception?
[17:59:00] <mojavelinux> well, we have solder tests that are known to fail on glassfish
[17:59:01] <mojavelinux> so....
[17:59:49] <mojavelinux> i really need to finish up this blog entry...it's sort of lingering in my todo list and strarting to make me feel anxious
[17:59:53] <mojavelinux> need to get the info out there
[18:00:35] <lightguard_jp> Okay
[18:03:26] *** rruss has joined #jbosstesting
[18:03:32] <mojavelinux> but i do plan on giving the glassfish 3.1 adapter a workout before days end
[18:03:46] <mojavelinux> i've only got about a 50% tank today after the last couple of days
[18:03:49] <mojavelinux> wearing thin
[18:04:39] <lightguard_jp> mojavelinux: I hear ya
[18:06:28] <lightguard_jp> Which goal is it to run the tests?
[18:06:34] <lightguard_jp> integration ?
[18:06:38] <lightguard_jp> integrate
[18:06:40] <lightguard_jp> Can't remember
[18:07:37] *** rruss has quit IRC
[18:07:56] <mojavelinux> mvn clean install -Dincontainer-glassfish-rest
[18:08:15] <mojavelinux> one of the things we are going to do after alpha5 is fix the bizarre setup of the tests in solder
[18:08:33] <mojavelinux> and generally align the commands across modules
[18:08:44] <mojavelinux> but again, no point in doing it until we have to upgrade arquillian anyway
[18:09:09] <lightguard_jp> 'dependencies.dependency.version' for org.jboss.spec:jboss-javaee-6.0:pom is missing. @ line 329, column 25 ????
[18:10:01] <mojavelinux> yep, that's because it got removed...see discussion earlier in the day
[18:10:04] <mojavelinux> it's in snapshot
[18:10:07] <mojavelinux> seam-bom snapshot
[18:10:15] <lightguard_jp> bah
[18:10:34] <lightguard_jp> I'm just using what's up in the seam repo, do I need a different repo that has more current code?
[18:11:32] *** ldimaggi has joined #jbosstesting
[18:11:49] <mojavelinux> change the seam-bom reference in solder to 3.0.0 SNAPSHOT
[18:12:02] <mojavelinux> oh, you might have to do mvn install on dist/pom.xml
[18:12:18] <mojavelinux> shane removed the depmgmt for it
[18:12:21] <mojavelinux> i added it back in
[18:12:28] <mojavelinux> but not in a release yet
[18:12:56] <lightguard_jp> Need to get dist
[18:13:03] <lightguard_jp> I haven't cloned it yet
[18:13:38] <mojavelinux> ah
[18:13:58] <mojavelinux> btw, you can run the CoreTest to verify...it's one of the ones that works
[18:14:02] <mojavelinux> not all the tests work on glassfish yet
[18:14:12] <mojavelinux> that's why we need some hudson action going on here
[18:14:19] <mojavelinux> so that's
[18:14:29] <mojavelinux> mvn install -Dincontainer-glassfish-rest -Dtest=CoreTest
[18:14:55] <mojavelinux> though you can try to run them all, though just know that they will fail not because of your adapter :)
[18:18:05] *** lincolnthree has joined #jbosstesting
[18:18:20] <lincolnthree> hey ALR, does descriptors have the ability to remove XML nodes?
[18:20:55] *** lfryc has quit IRC
[18:21:30] <lightguard_jp> mojavelinux: Sure, but I need one of them to fail so I can see what we get back from the rest call.
[18:24:01] *** jdewinne has joined #jbosstesting
[18:25:20] <mojavelinux> ah, UnwrapsTest fails
[18:25:44] <mojavelinux> also so does the org.jboss.seam.solder.test.compat.visibility.VisibilityOfAnnotatedTypesFromExtensionInBravoBeanArchiveTest
[18:26:48] *** jdewinne has left #jbosstesting
[18:27:54] <ALR> lincolnthree: Remove?
[18:28:07] <lincolnthree> yes
[18:28:11] <lincolnthree> i want to remove a configured element
[18:28:14] <lincolnthree> for instance
[18:28:28] <lincolnthree> <non-jta-data-source> should be removed when a <jta-data-source> is configured
[18:28:32] <lincolnthree> in the same persistence unit
[18:28:48] <lincolnthree> i figured out that you don't have a remove at this point
[18:28:55] <lincolnthree> figuring out how to add it to the NodeQuery API
[18:32:36] <ALR> aslak: Whoops.
[18:32:37] <ALR> Nexus
[18:32:42] <ALR> 0.1.3 Descriptors is out
[18:32:56] <lincolnthree> ALR is that for me?
[18:33:01] <lincolnthree> (your last statement)
[18:33:06] <ALR> lincolnthree: It's for aslak
[18:33:08] <lincolnthree> ok
[18:33:13] <aslak> ALR, excellent, thanks
[18:33:13] <ALR> lincolnthree: Looking for you.
[18:33:21] <lincolnthree> ALR, i just added remove(string) and remove(Query)
[18:33:23] <lincolnthree> to Node
[18:33:48] <lincolnthree> I might also add remove(Node)
[18:33:50] <lincolnthree> wdyt?
[18:34:01] <lincolnthree> the first two can remove multiples
[18:34:08] <lincolnthree> they will remove anything matching the query
[18:34:13] <ALR> lincolnthree: Yes, that's exactly iy
[18:34:17] <ALR> *it
[18:34:34] <lincolnthree> damn internet, i'd pastebin for you but....
[18:34:35] <ALR> lincolnthree: Also remove "String"
[18:34:42] <lincolnthree> remove String?
[18:35:00] <ALR> Sorry
[18:35:02] <ALR> remove(String)
[18:35:04] <ALR> I need sleep
[18:35:08] <ALR> :)
[18:36:46] <lincolnthree> http://pastebin.com/vfvPjZ2Y
[18:37:23] <ALR> lincolnthree: Precondition checks
[18:38:10] <lincolnthree> such as?
[18:38:48] <ALR> if null throw IllegalArgumentException
[18:39:02] <ALR> And that Strings aren't 0 length as well
[18:39:05] <ALR> Simple stuff
[18:39:06] <lincolnthree> none of your other methods do that
[18:39:12] <ALR> Yell at aslak
[18:39:15] <aslak> :)
[18:39:18] <lincolnthree> and this just passes through to the existing API in Query
[18:39:48] <ALR> lincolnthree: Are you mounting an argument where the basis is that we shouldn't be checking preconditions?
[18:39:51] <ALR> :P
[18:39:51] <lincolnthree> and that API does the checks :)
[18:40:14] <ALR> IMO Check soon as possible, fail fast as possible
[18:40:15] <aslak> yea, Queries checks
[18:40:32] <ALR> So I use for APIs: if null then IllegalArgument
[18:40:37] <lincolnthree> I'll add them if you like, but I'm just saying it's not consistent with what we have (or IMO necessary to duplicate the check since everything delegates to Queries
[18:40:39] <ALR> And for internal stuff:
[18:40:48] <ALR> "assert something!=null:"Message"
[18:41:03] <ALR> For small performance boost when not running in -ea
[18:41:26] <ALR> But yeah, all API stuff I like to have precondition stuff everywhere.  Half of what I write is to verify user input.
[18:41:40] <aslak> kpiwko, ContextPath supported both URI and URL ?
[18:42:05] <ALR> lincolnthree: Also keep in mind that what we have shouldn't always be emulated.
[18:42:10] <ALR> This is a serious prototype
[18:42:22] <ALR> And a lot of it hasn't gotten uniform design love yet
[18:42:28] <ALR> aslak and I did this w/ ShrinkWrap
[18:42:45] <ALR> There was a month or so in the beginning where we did a lot of rewriting and redesign
[18:42:53] *** lincolnthree1 has joined #jbosstesting
[18:42:56] <lincolnthree1> arg internet
[18:42:59] <ALR> Because the first stab was a proof-of concept
[18:43:07] <ALR> And we needed to understand the domain
[18:43:08] <lincolnthree1> i missed everything after my last statement
[18:43:12] <ALR> And the code reflected that
[18:43:15] <ALR> Will paste you :)
[18:43:33] <ALR> http://pastebin.com/Xs4Fuvaz
[18:43:49] <ALR> lincolnthree1: ^
[18:44:20] <ALR> Wow, I'm really getting on a pulpit today:
[18:44:28] <ALR> Also, "consistency" IMO is for APIs.
[18:44:37] <ALR> Internally, whatever's most correct should fly.
[18:44:51] <ALR> The old EJB stuff didn't have a single assertion anywhere.
[18:44:57] *** lincolnthree has quit IRC
[18:45:01] <ALR> But don't think we didn't sprinkle 'em about the place
[18:45:02] <ALR> :)
[18:45:19] <kpiwko> aslak, right, URI, URL and String
[18:45:21] * ALR done :)
[18:45:35] <aslak> kpiwko, String ? ok, dropping that support
[18:45:43] * ALR away for awhile.
[18:45:47] <ALR> Need.  Sleep.
[18:46:02] <ALR> Can't work w/ both the Europeans and the USers. :P
[18:46:09] <kpiwko> :)
[18:46:32] <aslak> we europeans do.. :)
[18:46:38] <kpiwko> yeah :)
[18:46:58] <ALR> It's easy in Europe.
[18:47:07] <ALR> You start work in the morning, and to midnight.
[18:47:29] <ALR> Here to meet you guys it's like a 03:00-08:00 thing
[18:47:51] <ALR> Wow, we need to get lives.
[18:47:59] <ALR> ;) Outee.
[18:48:03] <aslak> :)
[18:48:31] * kpiwko is leaving
[18:49:21] <lincolnthree1> Lives? hah
[18:50:41] *** lincolnthree has joined #jbosstesting
[18:51:05] *** kpiwko has quit IRC
[18:51:18] *** lincolnthree1 has quit IRC
[18:52:17] *** vtunka has quit IRC
[18:54:15] *** ALR has quit IRC
[19:06:11] *** lightguard_jp has quit IRC
[19:09:54] <jbossbot> git [arquillian] push master a697847.. Aslak Knutsen ARQ-367 Add @ArquillianResource injection support....
[19:09:55] <jbossbot> jira [ARQ-367] Add support for @ArquillianResource [Open (Unresolved) Feature Request, Major, Aslak Knutsen] https://issues.jboss.org/browse/ARQ-367
[19:09:56] <jbossbot> git [arquillian] push master URL: http://github.com/arquillian/arquillian/compare/937650b...a697847
[19:19:06] <mojavelinux> freakin' awesome
[19:23:06] <aslak> o crap
[19:23:12] <aslak> that did not do what i expected it to
[19:23:19] *** lightguard_jp has joined #jbosstesting
[19:24:49] <mojavelinux> oh, I was saying awesome to the feature coming in
[19:25:06] <mojavelinux> hey, andrew dinn is going to be at judcon! byteman+arquillian sitting in a bar
[19:25:22] <aslak> hehe got a demo impl of that already
[19:25:25] <aslak> and some open issues
[19:25:33] *** Jaikiran has quit IRC
[19:25:35] <mojavelinux> btw, I'm I crazy, or should we have a cool fail page for jboss as 7?
[19:25:39] <mojavelinux> everyone has one these days
[19:25:46] <aslak> no, my o crap was, git pull --rebase repo branch  did not behave as i expected
[19:25:47] <mojavelinux> and it should be ike
[19:26:02] <mojavelinux> and he should say "please tell my master to write more tests"
[19:26:03] <mojavelinux> hehehe
[19:26:16] <aslak> hehe
[19:26:47] <aslak> it rebases my current branch over the remote
[19:26:49] *** jeand has quit IRC
[19:27:54] <aslak> instead of the opposite as i thought..  i wanted the remote to come after current, not the other way around.. now half the history of master is rewritten.. hehe
[19:28:07] <aslak> let's see.. git magic where are tho
[19:33:32] <aslak> doh.. git reset --hard upstream/master fixes it of course
[19:33:58] *** alesj has joined #jbosstesting
[19:34:44] *** alesj has left #jbosstesting
[19:38:07] *** michaelschuetz has joined #jbosstesting
[19:49:22] <jbossbot> git [arquillian] push master 142cfb9.. Karel Piwko ARQ-387 Rewritten Drone Extension injection with TestEnricher
[19:49:23] <jbossbot> jira [ARQ-387] Selenium extension should use the TestEnricher SPI to do injection into the test case [Open (Unresolved) Feature Request, Major, Karel Piwko] https://issues.jboss.org/browse/ARQ-387
[19:49:24] <jbossbot> git [arquillian] push master 404acba.. Karel Piwko ARQ-387 Changed MethodContext API...
[19:49:24] <jbossbot> git [arquillian] push master 6721fdd.. Karel Piwko ARQ-387 Added method argument injection test, polished code
[19:49:24] <jbossbot> git [arquillian] push master 87a880c.. Karel Piwko ARQ-387 Updated SecurityActions to check superclasses as well
[19:49:24] <jbossbot> git [arquillian] push master f506144.. Karel Piwko ARQ-387 Moved MockDrone to its own test subpackage
[19:49:24] <jbossbot> git [arquillian] push master URL: http://github.com/arquillian/arquillian/compare/a697847...f506144
[19:51:17] *** rruss has joined #jbosstesting
[20:00:39] <lincolnthree> hey aslak. https://issues.jboss.org/browse/SHRINKDESC-39
[20:00:41] <jbossbot> jira [SHRINKDESC-39] Support removing properties from PersistenceUnitDefs [Open (Unresolved) Feature Request, Major, Lincoln Baxter III] https://issues.jboss.org/browse/SHRINKDESC-39
[20:00:48] <lincolnthree> I've implemented and sent a pull request
[20:00:52] <lincolnthree> think you could pull it in?
[20:01:07] <lincolnthree> I'll deploy a new snapshot if you do
[20:03:51] <aslak> lincolnthree, sorry, Andrew is repo god
[20:04:02] <lightguard_jp> mojavelinux: I think we're screwed with the reason behind deployment dying
[20:07:56] <lincolnthree> aslak: np
[20:09:10] *** twhitlock_ has joined #jbosstesting
[20:13:10] *** twhitlock_ has quit IRC
[20:14:19] *** twhitlock_ has joined #jbosstesting
[20:15:11] <lightguard_jp> lol, and ALR is gone
[20:15:39] <lightguard_jp> Andrew gone for the day?
[20:16:24] <aslak> who knows..
[20:16:24] <aslak> <ALR> It's easy in Europe.
[20:16:24] <aslak>  You start work in the morning, and to midnight.
[20:16:25] <aslak>  Here to meet you guys it's like a 03:00-08:00 thing
[20:16:25] <aslak>  Wow, we need to get lives.
[20:16:25] <aslak>  ;) Outee.
[20:16:38] <aslak> <ALR> Need.  Sleep.
[20:16:38] <aslak>  Can't work w/ both the Europeans and the USers. :P
[20:17:31] <lightguard_jp> Yeah, I remember that.
[20:18:06] <lightguard_jp> Too bad. twhitlock_ here applied for the "make it go faster" position. I wanted to introduce them, "officially", well, more official than twitter
[20:24:15] <aslak> lightguard_jp, aa :)
[20:24:22] <aslak> twhitlock_, welcome to jbosstesting ;)
[20:24:34] <twhitlock_> welcome
[20:25:17] <twhitlock_> I meant hello :)
[20:51:33] <lincolnthree> oy, aslak
[20:51:39] <lincolnthree> I think i messed up my pull request
[20:51:43] <lincolnthree> https://github.com/shrinkwrap/descriptors/pull/15
[20:51:48] <lincolnthree> it has a bajillion commits in it
[20:51:58] <lincolnthree> do you know how to rebase that down to 1?
[20:52:19] <aslak> lincolnthree, git rebase -i HEAD~7
[20:53:27] <lightguard_jp> Nothing wrong with all the commits really.
[20:53:36] <lincolnthree> lightguard_jp: ALR doesn't like them
[20:53:42] <lightguard_jp> Ah
[20:53:49] <lightguard_jp> One commit for a feature huh?
[20:53:52] <lincolnthree> I personally don't mind
[20:53:54] <lincolnthree> yes
[20:54:00] <lightguard_jp> I can see either way
[20:54:08] <aslak> lincolnthree, if you rebase interactive, remove the Merge brach commits, sqush the 3 others then rebase on master
[20:54:37] <lincolnthree> rebase on master?
[20:54:42] <lincolnthree> isn't rebasing horribly dangerous
[20:54:53] <aslak> git checkout topic & git rebase master
[20:55:17] <aslak> replays your topic branch on top of master in your topic branch
[20:55:59] <aslak> lincolnthree, it's something you shouldn't do if you have published that branch/commit and other ppl depend on it
[20:56:39] <lincolnthree> i guess im still having trouble wrapping my head around it
[20:56:50] <aslak> lincolnthree, you will be recreating your commits, but as long as noone else are using them.. who cares.. :)
[20:58:07] <aslak> lincolnthree, you should sit in on one of Matthew McCulloughs talks when you have a chance, he explains it all so nicly
[20:58:09] <aslak> :)
[20:59:00] <mojavelinux> +1
[20:59:01] *** michaelschuetz has quit IRC
[20:59:11] * aslak is now fearless :P
[20:59:57] <aslak> lincolnthree, as long as you don't fuck with the .git folder, there is basically nothing you can't recover from
[21:00:08] <lincolnthree> unless you rebase commits and delete them
[21:00:11] <lincolnthree> inwhich case they are gone
[21:00:17] <aslak> lincolnthree, not at all
[21:00:24] <aslak> git reflog
[21:00:50] <aslak> git reset HEAD{3}
[21:00:58] <aslak> or git reset upstream/master
[21:01:05] <lightguard_jp> Yeah, they're always there
[21:01:13] <lightguard_jp> May be a little hard to get at, but thy're all recorded
[21:02:41] <aslak> sorry, reset upstream/master won't help you there, but.. reset to a 'remote' known state
[21:03:56] <aslak> not sure if you can reset forward tho..
[21:04:17] <aslak> or if the reset is just another command you can reset.. probably is
[21:09:43] *** ge0ffrey has quit IRC
[21:10:21] <aslak> had to test.. reset is of course just another command in the ref log. so you can reset to before you reset
[21:16:49] *** mgoldmann_ has quit IRC
[21:21:16] *** rruss has quit IRC
[21:22:30] <lightguard_jp> aslak: The pull request for ARQ-323 has been updated with last night's work
[21:22:32] <jbossbot> jira [ARQ-323] Implement a GlassFish 3.1 remote container based on REST API [Open (Unresolved) Feature Request, Minor, Jason Porter] https://issues.jboss.org/browse/ARQ-323
[21:48:37] *** jeand has joined #jbosstesting
[21:58:19] *** jharting has joined #jbosstesting
[22:01:17] *** ldimaggi has quit IRC
[22:02:12] *** stuartdouglas has joined #jbosstesting
[22:40:51] *** michaelschuetz has joined #jbosstesting
[22:41:47] *** rruss has joined #jbosstesting
[22:41:53] <aslak> lightguard_jp, you mind adding some jiras for the gf 3.1 remote 'work needed' issues ?
[22:49:47] *** jeand has quit IRC
[22:57:39] <lightguard_jp> Sure, can do
[23:08:39] *** jharting has quit IRC
[23:15:29] *** ldimaggi has joined #jbosstesting
[23:19:48] <jbossbot> git [arquillian] push master 0a231cb.. LightGuard ARQ-323 Add GlassFish Remote 3.1 Container. (Work needed)...
[23:19:49] <jbossbot> jira [ARQ-323] Implement a GlassFish 3.1 remote container based on REST API [Open (Unresolved) Feature Request, Minor, Jason Porter] https://issues.jboss.org/browse/ARQ-323
[23:19:49] <jbossbot> git [arquillian] push master URL: http://github.com/arquillian/arquillian/compare/f506144...0a231cb
[23:22:56] <aslak> lincolnthree, did you see mt comment on SHRINKDESC-40
[23:22:58] <jbossbot> jira [SHRINKDESC-40] Properties on PersistenceUnitDefImpl should overwrite existing properties with the same name [Open (Unresolved) Enhancement, Major, Unassigned] https://issues.jboss.org/browse/SHRINKDESC-40
[23:23:01] <aslak> :)
[23:23:05] <lincolnthree> i did
[23:23:17] <lincolnthree> did you see mine? ;)
[23:24:11] <aslak> hehe
[23:24:19] <aslak> that's why it's there
[23:24:35] <aslak> the Query thing. to simplify 'shit' like that
[23:24:58] <lincolnthree> yeah
[23:25:01] <lincolnthree> its very nice
[23:25:13] <lincolnthree> im actually going to use it as the recommended forge XML manipulator, I think
[23:25:22] <lincolnthree> for when you need to parse XML :)
[23:25:35] <lincolnthree> might also pull it in to prettyfaces
[23:25:45] <aslak> hehe
[23:25:52] <lincolnthree> its really good
[23:28:40] <aslak> lincolnthree, ALR is gonna yell at you tomorrow.. :)
[23:28:58] <lincolnthree> Yeah I already emailed him
[23:29:18] <lincolnthree> at least i've been writing tests
[23:29:22] <lincolnthree> that's more than most can say!
[23:30:09] <aslak> was mostly referring to the chaotic pull request / branching.. hehe
[23:30:35] <lincolnthree> that's what i emailed him about
[23:30:45] <lincolnthree> im still a git n00b apparently
[23:31:16] <aslak> :)
[23:32:20] <aslak> lightguard_jp, mojavelinux: gf 3.1 remote pushed upstream. rebased, so pull upstream/master when continuing work .. thanks!
[23:36:20] <lightguard_jp> aslak: Okay, can do
[23:37:37] <lightguard_jp> aslak: Wait, do I need to rebase and commit again?
[23:38:34] <aslak> lightguard_jp, did you do it on your master?
[23:39:07] <aslak> lightguard_jp, no you had a branch right..  drop that branch.. git pull upstream master && git checkout -b NEW_JIRA
[23:39:09] <lightguard_jp> I think was in there an hour or two after I push to my master it was behind
[23:39:26] <lightguard_jp> Oh for the new jiras
[23:39:28] <lightguard_jp> Right
[23:39:36] *** maeste has quit IRC
[23:39:42] <lightguard_jp> I was talking about the initial gf 3.1 remote container.
[23:39:44] <aslak> lightguard_jp, i rebased your commits, so your branch is nonsense compared to master now.. ;)
[23:39:48] <lightguard_jp> You got that all pulled in.
[23:39:53] <lightguard_jp> Okay, good
[23:40:31] <aslak> https://github.com/arquillian/arquillian/commit/0a231cbf0f8ce2f90b2aa14d687974574365862c
[23:40:31] <jbossbot> git [arquillian] 0a231cb.. LightGuard ARQ-323 Add GlassFish Remote 3.1 Container. (Work needed)...
[23:40:32] <jbossbot> jira [ARQ-323] Implement a GlassFish 3.1 remote container based on REST API [Resolved (Done) Feature Request, Minor, Jason Porter] https://issues.jboss.org/browse/ARQ-323
[23:41:13] <mojavelinux> yeah!
[23:41:17] <mojavelinux> woot
[23:41:41] <mojavelinux> i'd do a backflip, but I"d throw out my back and then I wouldn't be able to get up and type anything :)
[23:43:24] <lightguard_jp> haha
[23:43:31] <lightguard_jp> Do one on the slopes
[23:52:28] *** michaelschuetz has quit IRC





top