February 28, 2011  
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28

[00:00:03] *** michaelschuetz has quit IRC
[00:11:31] *** ldimaggi_ has joined #jbosstesting
[01:53:44] *** jdlee has quit IRC
[02:15:55] *** bobmcw has quit IRC
[02:16:03] *** bobmcw has joined #jbosstesting
[02:27:14] *** baaba has quit IRC
[02:41:53] *** bgeorges has joined #jbosstesting
[03:03:09] <bleathem> Anyone familiar with the arquillian examples at:
[03:03:11] <bleathem> https://github.com/arquillian/arquillian-examples
[03:05:45] <bleathem> I'm trying to update the jsfunit-servlet arquillian tests to work with WELD 1.1
[03:06:20] <bleathem> So that I can write tests for Seam Faces
[03:07:34] <bleathem> But as soon as I upgrade the weld-servlet to 1.1.0.Final in the pom.xml
[03:07:53] <bleathem> I get an Exception:
[03:07:56] <bleathem> java.lang.IllegalStateException: Singleton is not set
[03:08:13] <bleathem> at org.jboss.weld.bootstrap.api.helpers.IsolatedStaticSingletonProvider$IsolatedStaticSingleton.get(IsolatedStaticSingletonProvider.java:52)
[03:08:29] <bleathem> Is this a weld-servlet bug?
[03:08:36] <bleathem> an Arquillian bug?
[03:08:41] <bleathem> a Jetty bug?
[03:08:55] <bleathem> I'm not sure how I should proceed to get this resolved.
[03:09:02] <bleathem> Any insight would be appreciated.
[03:21:18] *** lincolnthree has joined #jbosstesting
[03:21:21] *** lincolnthree has left #jbosstesting
[03:42:51] *** johnament has joined #jbosstesting
[03:55:25] *** johnament has quit IRC
[04:07:16] *** johnament has joined #jbosstesting
[04:52:51] *** ldimaggi_ has quit IRC
[04:57:39] *** johnament has quit IRC
[05:55:57] *** jdlee has joined #jbosstesting
[07:16:13] *** nickarls has left #jbosstesting
[07:16:25] *** nickarls has joined #jbosstesting
[08:09:10] *** jharting has joined #jbosstesting
[08:13:37] *** oskutka has joined #jbosstesting
[08:27:26] *** michaelschuetz has joined #jbosstesting
[08:28:12] *** bgeorges has quit IRC
[08:55:14] *** ge0ffrey has joined #jbosstesting
[08:56:04] *** oskutka1 has joined #jbosstesting
[08:57:59] *** oskutka has quit IRC
[08:58:54] *** oskutka1 is now known as oskutka
[09:03:35] *** lfryc has joined #jbosstesting
[09:17:01] *** maeste has joined #jbosstesting
[09:27:48] *** GTobi has joined #jbosstesting
[09:49:07] *** mgoldmann has joined #jbosstesting
[09:49:11] *** mgoldmann has joined #jbosstesting
[10:04:04] *** vtunka has joined #jbosstesting
[10:17:23] *** oskutka has quit IRC
[10:34:23] *** oskutka has joined #jbosstesting
[10:54:32] *** alesj has joined #jbosstesting
[10:59:44] *** jeand has joined #jbosstesting
[11:30:05] *** wolfc has joined #jbosstesting
[12:01:13] *** kpiwko has joined #jbosstesting
[13:15:58] *** ldimaggi_ has joined #jbosstesting
[13:23:30] *** ldimaggi_ has quit IRC
[13:23:49] *** ldimaggi_ has joined #jbosstesting
[13:38:05] *** rruss has joined #jbosstesting
[13:38:18] *** rruss has quit IRC
[14:05:54] *** oskutka has quit IRC
[14:31:18] *** jharting has quit IRC
[14:38:09] *** bgeorges has joined #jbosstesting
[14:50:51] *** michaelschuetz has quit IRC
[15:19:07] *** jdlee has quit IRC
[15:55:14] *** tcunning has joined #jbosstesting
[15:55:54] *** jdlee has joined #jbosstesting
[15:57:14] *** bgeorges has quit IRC
[15:59:26] *** bgeorges has joined #jbosstesting
[16:34:08] *** jdlee has quit IRC
[16:35:14] *** jdlee has joined #jbosstesting
[16:35:15] *** jdlee has joined #jbosstesting
[16:41:38] *** ALR has joined #jbosstesting
[16:50:03] *** pmuir has joined #jbosstesting
[17:05:27] *** mgoldmann has quit IRC
[17:14:40] *** rruss has joined #jbosstesting
[17:22:45] *** kpiwko has quit IRC
[17:38:18] *** lincolnthree1 has joined #jbosstesting
[17:38:26] <lincolnthree1> hey ALR, you around?
[17:38:53] <ALR> lincolnthree1: Yup.
[17:38:58] <ALR> Mornin'.
[17:39:07] <lincolnthree1> http://pastebin.com/gzeeGAhX
[17:39:09] <lincolnthree1> hey :)
[17:39:27] <lincolnthree1> Looks like shrinkwrap is generating undeployable web.xml
[17:39:36] <lincolnthree1> JBossAS complains that it's not valid
[17:39:39] * ALR looking at the differences
[17:39:57] <lincolnthree1> it's the schema I believe
[17:39:58] <ALR> schemaLocation?
[17:40:01] <ALR> What's the error?
[17:40:02] <lincolnthree1> yeah
[17:40:14] <lincolnthree1> getting a fresh one for you
[17:40:49] <lincolnthree1> http://pastebin.com/5dkT5BK5
[17:41:45] <lincolnthree1> " Failed to parse schema for nsURI=http://java.sun.com/xml/ns/javaee, localName=web-app, schemaLocation=null"
[17:42:21] <ALR> lincolnthree1: Let's get a schemaLocation in there
[17:42:35] <lincolnthree1> aight
[17:46:43] <lincolnthree1> ALR, do you have a sec to explain the rebase procedure you'd requested a few days ago?
[17:47:01] <ALR> lincolnthree1: Yep, lemme try this patch first?
[17:47:15] <ALR> lincolnthree1: Are you using a SNAP now of SD, or the last release I gave you?
[17:47:35] <lincolnthree1> last release
[17:47:44] <ALR> lincolnthree1: How can I repro your errors?
[17:47:55] <lincolnthree1> ah, using forge
[17:47:58] <lincolnthree1> latest forge snap
[17:48:00] <lincolnthree1> should do it
[17:48:03] <ALR> lincolnthree1: Or if I push this, can you test the latest SNAP?
[17:48:08] <lincolnthree1> 'course :)
[17:48:11] <ALR> OIK
[17:48:12] <ALR> OK
[17:48:13] <lincolnthree1> i was doing it locally as well
[17:50:21] <ALR> https://issues.jboss.org/browse/SHRINKDESC-36
[17:50:22] <jbossbot> jira [SHRINKDESC-36] Add schemaLocation to WebAppDescriptor [Open (Unresolved) Task, Major, Andrew Rubinger] https://issues.jboss.org/browse/SHRINKDESC-36
[17:56:34] *** GTobi has quit IRC
[17:59:55] *** vtunka has quit IRC
[18:01:50] *** maeste is now known as maeste_away
[18:02:44] <ALR> lincolnthree1: Know anything about XPath?
[18:02:53] <ALR> Isn't this right?
[18:02:53] <ALR> /web-app[xsi:schemaLocation]
[18:02:55] <lincolnthree1> ALR not too much, why?
[18:03:01] <lincolnthree1> ah, for tests?
[18:03:23] <ALR> Yeah
[18:03:46] <lincolnthree1> I think: /web-app@xsi:schemaLocation
[18:04:13] <ALR> Invalid expression
[18:05:26] <lincolnthree1> web-app@xsi:schemaLocation ?
[18:05:33] <lincolnthree1> maybe the ':' is messing it up
[18:05:39] <ALR> That could be it.
[18:05:48] <ALR> Hmmm.
[18:07:44] *** tcunning has quit IRC
[18:08:26] <lincolnthree1> Hmm...
[18:09:09] *** tcunning has joined #jbosstesting
[18:09:26] <lincolnthree1> seeing some interesting posts about namespaces and referencing them
[18:11:30] <ALR> XPath doesn't inherit namespaces
[18:13:18] <lincolnthree1> "Finally, xmlns attributes are reported as  namespace nodes. They are not considered attribute nodes, though a  non-namespace aware parser will see them as such. Furthermore these  nodes are attached to every element and attribute node for which that  declaration has scope. They are not just attached to the single element  where the namespace is declared."
[18:14:20] <ALR> I saw that
[18:14:31] <ALR> AssertXPath is wrong.
[18:14:34] <ALR> In SD.
[18:14:40] <lincolnthree1> Ah
[18:14:47] <ALR> First, it can't accept namespaces in the XPath
[18:14:54] <ALR> Which is fine, I can just say:
[18:15:05] <ALR>  /web-app[@schemaLocation]
[18:15:07] <ALR> But.
[18:15:23] <lincolnthree1> hmm
[18:15:25] <ALR> The assertion incorrectly assumes we're looking for a text node value
[18:15:29] <ALR> Not an attribute
[18:15:35] <ALR> And here we want an attribute.
[18:15:38] <ALR> So fixing stuff up.
[18:27:07] <lincolnthree1> Hmm
[18:27:17] <lincolnthree1> Does SWD take schema into account when it creates nodes?
[18:27:18] <lincolnthree1> For instance
[18:27:27] <ALR> Account?
[18:27:29] <lincolnthree1> <name> must be before <description> and etc... in lots of the EE descriptors
[18:27:51] <ALR> It's DOM
[18:27:56] <ALR> ATM
[18:27:57] <ALR> this(new Node("web-app")
[18:27:57] <ALR>             .attribute("xmlns", "http://java.sun.com/xml/ns/javaee")
[18:28:12] <lincolnthree1> right, but does that handle ordering?
[18:28:28] <ALR> I do not know. :)
[18:28:31] <ALR> It must.
[18:28:34] <lincolnthree1> i guess we'll find out ;)
[18:28:35] <lincolnthree1> I hope so
[18:28:44] <ALR> So if it doesn't, that's something to address
[18:29:37] <lincolnthree1> Let me know when you want me to try the new snap
[18:39:27] *** lightguard_jp has joined #jbosstesting
[18:39:43] *** lightguard_jp has quit IRC
[18:40:02] *** lightguard_jp has joined #jbosstesting
[18:40:23] *** alesj has quit IRC
[18:51:33] *** lfryc has quit IRC
[19:03:19] *** Tashtego has joined #jbosstesting
[19:10:26] *** Tashtego has quit IRC
[19:17:48] *** ALR has left #jbosstesting
[19:18:11] *** ALR has joined #jbosstesting
[19:34:59] *** ge0ffrey has quit IRC
[19:39:57] *** alesj has joined #jbosstesting
[20:22:31] *** Tashtego has joined #jbosstesting
[20:22:43] *** Tashtego has joined #jbosstesting
[20:23:26] *** michaelschuetz has joined #jbosstesting
[20:26:18] *** jeand has quit IRC
[20:26:37] *** lfryc has joined #jbosstesting
[20:37:41] *** bgeorges_ has joined #jbosstesting
[20:40:07] *** bgeorges has quit IRC
[20:41:50] *** bleathem has quit IRC
[20:42:19] *** jeand has joined #jbosstesting
[20:52:07] *** mgoldmann has joined #jbosstesting
[20:53:39] *** jeand has quit IRC
[21:03:44] <jbossbot> git [descriptors] push master 9a5419d.. Andrew Lee Rubinger [SHRINKDESC-36] Add xsi:schemaLocation to WebAppDescriptorImpl
[21:03:46] <jbossbot> jira [SHRINKDESC-36] Add schemaLocation to WebAppDescriptor [Open (Unresolved) Task, Major, Andrew Rubinger] https://issues.jboss.org/browse/SHRINKDESC-36
[21:03:46] <jbossbot> git [descriptors] push master URL: http://github.com/shrinkwrap/descriptors/compare/8ef6f59...9a5419d
[21:03:54] <ALR> lincolnthree1: ^ Grab from upstream and try that SNAP
[21:08:22] <lincolnthree1> ALR: on it
[21:10:56] <ALR> lincolnthree1: Sorry that took a bit.  Had to figure out what Aslak's previous code was doing in XPath before changing it, didn't wanna change the way his tests previously worked without understanding why.
[21:11:10] <lincolnthree1> np, i went on to other things
[21:24:12] <lincolnthree1> ALR: looks good! cut away!
[21:27:05] *** pmuir has quit IRC
[21:33:54] <ALR> lincolnthree1: OK.
[21:34:02] <ALR> lincolnthree1: And then we can talk rebasing?
[21:34:09] <lincolnthree1> yeah please
[21:34:13] <lincolnthree1> i need to understand that
[21:34:37] <ALR> k
[21:34:44] <ALR> One sec, I'll cut first
[21:35:28] <jbossbot> git [descriptors] push master 5ae25b2.. Andrew Lee Rubinger [maven-release-plugin] prepare release 0.1.2
[21:35:28] <jbossbot> git [descriptors] push master URL: http://github.com/shrinkwrap/descriptors/compare/9a5419d...5ae25b2
[21:35:29] <jbossbot> git [descriptors] push master 8ff7490.. Andrew Lee Rubinger [maven-release-plugin] prepare for next development iteration
[21:35:30] <jbossbot> git [descriptors] push master URL: http://github.com/shrinkwrap/descriptors/compare/5ae25b2...8ff7490
[21:37:30] <ALR> lincolnthree1: Released.
[21:38:10] <lincolnthree1> thanks!
[21:42:09] <ALR> lincolnthree1: OK, so rebasing.
[21:42:14] <ALR> Are you familiar with it conceptually?
[21:42:29] <lincolnthree1> it merges two branch/tag histories into one line
[21:42:43] <ALR> Well, it's different from a merge
[21:42:43] <lincolnthree1> at a high level
[21:42:45] <lincolnthree1> right
[21:42:52] <lincolnthree1> Go ahead
[21:42:53] <ALR> As it replays your commits on top of the target
[21:42:53] <ALR> http://progit.org/book/ch3-6.html
[21:43:03] <ALR> I find the images there to be most illustrative
[21:43:34] <ALR> Very generally, what we're after is this:
[21:44:01] <ALR> All commits, before merged into upstream/master, should be rebased first in your local clone
[21:44:12] <ALR> So that when they hit upstream, it's like a new commit
[21:44:23] <ALR> Not work that's been done in tandem w/ many merge points along the way.
[21:44:28] <lincolnthree1> so if the master has passed *you*, you move your commits to where master is *now*
[21:44:33] <ALR> It keeps the source history cleaner and less tangled up that way
[21:44:40] <ALR> Exactly.
[21:44:51] <ALR> You bring your experimental/dev branch in line with master
[21:44:59] <ALR> And your work goes on top of it.
[21:45:17] <ALR> As upstream progresses, you can keep rebasing so your stuff lays over it.
[21:47:30] <lincolnthree1> got it
[21:47:35] <lincolnthree1> i think that might take some practice :)
[21:47:39] <ALR> It might.
[21:47:59] <ALR> Luckily it's really hard to mess stuff up beyond repair :P
[21:48:10] <ALR> So long as you don't reset uncommitted changes
[21:48:47] <lincolnthree1> thaaats the hard part
[21:48:55] <lincolnthree1> but also a reason why you have a remote fork
[21:49:00] <lincolnthree1> :)
[21:49:09] <lincolnthree1> can always go get it again if you are careful
[21:49:10] <stuartdouglas> incidentally you can also use rebase to merge commit, remove commits and re-order commits, so you can commit heaps while you are working and then just have one nice clean one for the pull request
[21:49:32] <lincolnthree1> stuartdouglas: have an example of that?
[21:49:41] <stuartdouglas> rebase -i origin/master
[21:49:52] <ALR> lincolnthree1: Interactive rebasing
[21:49:58] <stuartdouglas> the i is for interactive, and it will open up a text editor with your commits
[21:50:13] <stuartdouglas> and then you can re-order, squash or remove them
[21:50:41] <ALR> stuartdouglas, lincolnthree1: By putting each issue in its own branch, I'm able to avoid the reordering and interactive stuff
[21:50:43] <lincolnthree1> im guessing you have to list commit hashes there?
[21:50:57] <ALR> Because each branch gets isolated to the dev of only one issue.
[21:51:03] <stuartdouglas> git does it for you
[21:51:18] <ALR> Yet still when it's time for the pull request, yeah having just one incoming is great (depending upon the situation)
[21:51:22] <lincolnthree1> i got a vim file with "noop" as the contents when I used that command
[21:51:26] <ALR> So you can atomically pull in a feature, or not.
[21:51:42] <stuartdouglas> you are probably as origin/master
[21:51:48] <stuartdouglas> at orgin/master
[21:51:52] <lincolnthree1> ah, so you need to be on a branch?
[21:51:54] <stuartdouglas> you would need to do a few commits
[21:52:00] <stuartdouglas> try git rebase -i HEAD~4
[21:52:09] <stuartdouglas> that will let you mess with the last 4 commits
[21:52:18] <lincolnthree1> ah interesting
[21:52:25] <lincolnthree1> so if you remove one from the list, what happens?
[21:52:32] <stuartdouglas> it is gone
[21:52:38] <lincolnthree1> changes stay though, yes?
[21:52:53] <lincolnthree1> unless you delete the top?
[21:53:05] <lincolnthree1> in which case im guessing that entire commit goes away
[21:53:13] <lincolnthree1> along with the changes
[21:53:35] <stuartdouglas> no, the changes are gone
[21:54:00] <lincolnthree1> so if I delete a commit somewhere in the middle, the changes from that commit are gone and ripple up?
[21:54:19] <stuartdouglas> essentially it resets your branch to 4 commits ago, then goes through each commit that you left and applies it as a patch
[21:54:34] <stuartdouglas> the changes from that commit are gone
[21:54:55] <stuartdouglas> you can still get them back with some git black majic, as long as you don't garbage collect your repo
[21:55:00] <lincolnthree1> ah
[21:56:01] <lincolnthree1> so its literally changing history
[21:56:13] <lincolnthree1> i think I got it
[21:56:29] <stuartdouglas> yes, although your old branch is still there, there is just no branch pointer to it
[21:56:45] <stuartdouglas> if you do a git branch backupBranch before you rebase
[21:57:00] <stuartdouglas> your old commits will still be in backupBranch
[21:59:44] *** lfryc has quit IRC
[22:02:53] <lincolnthree1> hey ALR, I just realised that our change means that we have more work to do in order to get webApp.version("2.5") to work.
[22:03:05] <lincolnthree1> We should probably use an Enum for ServletVersion
[22:03:10] <ALR> lincolnthree1: Oh yeah, we actually need one per version
[22:03:20] <ALR> Fist off:
[22:03:24] <ALR> *First off:
[22:03:31] <ALR> Is 3.0 back-compat w. 2.5?
[22:03:34] <lincolnthree1> yes
[22:03:38] <ALR> Then we need:
[22:03:49] <ALR> WebAppDescriptor30 extends WebAppDescriptor25
[22:04:01] <lincolnthree1> oh crud
[22:04:03] <lincolnthree1> you're right
[22:04:05] <ALR> Mhmm
[22:04:07] <lincolnthree1> well...
[22:04:13] <ALR> Lessons from jboss-metadata :)
[22:04:14] <lincolnthree1> we could just say that SW only works on 3.0:)
[22:04:16] <ALR> I knew this was coming
[22:04:23] <ALR> What you're working with now is a proof-of-concept.
[22:04:28] <lincolnthree1> *nod*
[22:05:38] <ALR> lincolnthree1: I'm trying to get you some community contributors for SD
[22:05:48] <ALR> Some interested parties from Twitter looking to work on OSS
[22:06:00] <ALR> So we'll see if that pans out, I'll be emailing them w/ details tonight to see if anything sticks.
[22:06:04] <lincolnthree1> nice
[22:06:10] <lincolnthree1> it's a good project for OSS
[22:06:18] <lincolnthree1> simple concept nicely designed
[22:06:23] <ALR> Very, because it's isolated and has no dependencies.
[22:06:31] <ALR> Same as ShrinkWrap was a good intake project.
[22:06:34] <ALR> And still is.
[22:06:48] <ALR> Anyway, I'm wrapping up my emails/online portion of the day
[22:06:53] <ALR> So gonna dig into some coding.
[22:07:09] <lincolnthree1> I should try tyat.
[22:07:10] <lincolnthree1> that
[22:07:14] <ALR> :)
[22:08:24] *** ldimaggi_ has quit IRC
[22:23:10] *** tcunning has quit IRC
[22:29:28] *** michaelschuetz1 has joined #jbosstesting
[22:31:07] *** michaelschuetz has quit IRC
[22:36:49] *** michaelschuetz has joined #jbosstesting
[22:39:59] *** michaelschuetz1 has quit IRC
[23:17:41] *** mgoldmann has quit IRC
[23:31:36] *** wolfc has quit IRC
[23:35:51] *** michaelschuetz has quit IRC
[23:39:14] *** michaelschuetz has joined #jbosstesting
[23:43:31] *** michaelschuetz has quit IRC

top