[00:02:46] <aslak> mojavelinux, heya
[00:02:49] <mojavelinux> yo
[00:04:23] <aslak> question i nmy head came up reviewing the spring extension
[00:04:43] <aslak> the artifacts are called arquillian-service-deployer-spring-xxx
[00:05:13] <aslak> and they basically consist of 2 things.. Enricher support and Packaging support
[00:05:20] <aslak> similar to Seam2
[00:05:57] <aslak> they are in a repo called arquillian-container-spring
[00:07:05] <aslak> we have been talking about that extensions provide services
[00:07:16] <mojavelinux> yep
[00:07:51] <aslak> and the pureity of the repos are starting to tear down as we move onto some of these new advatures
[00:08:03] <aslak> android is the same
[00:08:22] <aslak> we have android as a webdriver, android as a container, android robotium
[00:09:42] <aslak> does a container integration provide a Container as a Service
[00:10:40] <mojavelinux> there are a couple of ways to look at this choice
[00:11:09] <mojavelinux> if we keep the existing repository suffixes
[00:12:20] <mojavelinux> then the question is
[00:12:20] <mojavelinux> a) does the embedded service container go in the repository *-extension
[00:12:20] <mojavelinux> b) does the service deployer go in the repository *-container
[00:12:34] <mojavelinux> i'm inclined to say (a)
[00:13:15] <aslak> everything is a extension
[00:13:20] <mojavelinux> however, that means that weld and openwebbeans doesn't fit the convention
[00:13:26] <aslak> yea
[00:13:39] <mojavelinux> well, sure, everything is an extension...-extension is just like "wildcard"
[00:13:57] <aslak> but weld could be both again.. a weld embedded container, and as a weld Packaging Service for weld-servlet
[00:14:18] <mojavelinux> yes, of course, but to me that's this new thingy
[00:14:32] <mojavelinux> meaning weld, openwebbeans, spring and (in the future) hibernate are all the same type of thingy
[00:15:16] <mojavelinux> i like to think of it as a service container, service integration or service deployer
[00:15:41] <aslak> integration = enricher, deployer = packager ?
[00:16:06] <mojavelinux> in my mind, enricher is just part of any integration potentially, and I don't see the need to call it out
[00:16:27] <aslak> no, this was just related back to the spring extension
[00:16:29] <mojavelinux> i look at the extension more of what it is providing in the way of availability
[00:16:41] <mojavelinux> enablement might be a better word
[00:17:29] <mojavelinux> inside the module it's reasonable to have an -enricher submodule, but at the top level I think we are dealing with something more broad
[00:18:04] <mojavelinux> so, for instance, if we were rethinking "container" for weld and spring, we might call the repository
[00:18:38] <mojavelinux> arquillian-weld-service or arquillian-spring-service
[00:18:49] <mojavelinux> I suppose those could be suffixed with -integration
[00:19:19] <mojavelinux> actually, if we step way back, the only -container is an embedded container, because anything else is actually a container-adapter
[00:19:46] <aslak> adapter.. service..
[00:20:09] <aslak> i guess it depends on how we see a Service
[00:20:30] <mojavelinux> before we move forward, I should mention that the name of the repository does not dictate or limit what we can call the modules inside the repository
[00:20:38] <mojavelinux> so perhaps we keep the repository name a bit simpler
[00:20:42] <aslak> is it a Service because it can't run on it's own, e.g. weld, spring.. or is it because it provided Core with a Service
[00:20:47] <mojavelinux> arquillian-weld-integration and arquillian-spring-integration
[00:21:30] <aslak> with a limited name i think it should limit the content, but yea
[00:21:32] <mojavelinux> (we don't have to change the weld repo, but that's just where it would go if we did)
[00:21:41] <aslak> e.g. a *container shouldn't be something else..
[00:22:32] <aslak> what else would we be doing then integrate.. so arquillian-weld would be simplified
[00:22:43] <mojavelinux> true
[00:22:53] <mojavelinux> that brings us back to extension, though
[00:23:19] <aslak> today extension is something that is not a container
[00:23:23] <mojavelinux> I think "extension" is important so that it's clear that it's not some part of core (as in weld providing something inside of arquillian itself)
[00:23:50] <aslak> right.. that's kinda where we have graphene and rusheye as well..
[00:24:00] <aslak> that's why they are not '*extension'
[00:24:04] <mojavelinux> ah
[00:24:05] <aslak> they can live without
[00:24:08] <aslak> core
[00:24:32] <mojavelinux> right, which only strengthens the point that arquillian-spring should have -extension at the end
[00:24:53] <mojavelinux> I think an -extension repository can provide a container adapter
[00:24:53] <aslak> i like it in the middle.. but beyond the point.. :)
[00:25:02] <mojavelinux> it's just that it's not only a container adapter
[00:25:18] <aslak> yea
[00:25:22] <mojavelinux> oh, right, whatever position is the standard, I wasn't trying to change that
[00:25:28] <mojavelinux> btw, about "service"
[00:25:59] <mojavelinux> what I was defining as service something that provides a service (or programming model)
[00:26:07] <mojavelinux> that service can be provided by bootstrapping it
[00:26:09] <mojavelinux> or by deploying it
[00:26:13] <mojavelinux> but either way, it makes the service avaialble
[00:26:22] <aslak> mm
[00:26:30] <mojavelinux> this is in contrast with a container, which to me is something that hosts services
[00:26:38] <mojavelinux> and may provide multiple out of the box
[00:26:50] <mojavelinux> technically openejb is a service under that definitino
[00:27:11] <mojavelinux> then, there are two types of services, as I mentioned
[00:27:17] <mojavelinux> service-container or service-deployer
[00:29:38] <mojavelinux> that was my line of thinking anyway
[00:30:06] <mojavelinux> thoughts?
[00:34:55] <aslak> yes, a few.. but not very well structured.. 2 sec :)
[00:43:46] <aslak> hmm.. a Service Container is what provides the Service standalone, while the Service Deployer provided the Service in another Container
[00:44:24] <aslak> and Service Integration should be reusable acorss a Container and a Service Container
[00:45:11] <mojavelinux> yes, correct
[00:45:24] <aslak> currently Core comes with 3 Service Integrations, cdi / ejb / resource.
[00:45:25] <mojavelinux> well stated
[00:45:48] <aslak> the Weld Service Container reuse the Core Service Integrations for CDI
[00:46:15] <aslak> and the Weld Service Deployer can provide Weld support in non supported Containers
[00:46:24] <mojavelinux> btw, those service integrations should probably be pulled out of core, but that wouldn't affect any users (it's just orgnaization)
[00:46:26] <aslak> while reusing the CDI Service Integration
[00:46:31] <mojavelinux> exactly
[00:47:21] <mojavelinux> (that one will get used a lot :))
[00:47:27] <mojavelinux> need cdi everywhere
[00:47:28] <mojavelinux> heheh
[00:47:43] <aslak> yea, been wondering about it.. just at the time, 32 repos sounded like enough 'normalization'
[00:47:53] <aslak> :)
[00:48:02] <mojavelinux> ah, what's interesting here is the cdi service integration does not depend on the service deployer impl (weld or openwebbeans)
[00:48:15] <mojavelinux> yeah.. perhaps something like
[00:48:19] <mojavelinux> arquillian-javaee-integration
[00:48:23] <mojavelinux> where integration is enrichers, etc
[00:48:30] <mojavelinux> of course, it could just be
[00:48:35] <mojavelinux> arquillian-javaee-enrichers
[00:48:44] <mojavelinux> though if there is at least one other thing, I'd say just group them
[00:49:11] <aslak> javaee-services would be doable
[00:49:15] <aslak> it's a scope
[00:49:15] <mojavelinux> by group them, I mean -integration (ignore my broken ordering)
[00:49:26] <mojavelinux> right
[00:49:51] <aslak> and that's where the 'specs' come from, wether they are usable outside of that i guess is not relevant
[00:51:35] <aslak> or hmm..
[00:51:48] <aslak> spec wise i guess they are standalone but get included in ee..
[00:52:26] <aslak> it's normally the other way around isn't it? even tho they are standalone specs, they are specs to be for ee
[00:52:44] <aslak> it's no, spec xxx looks nice, let's put that in ee
[00:53:36] <aslak> no/not
[00:54:01] <mojavelinux> I have no idea how they think, I gave up on that a long time ago :)
[00:54:43] <aslak> do we have jsr specs that are not in se or ee ?
[00:54:49] <aslak> with any backing / releases that is
[00:55:37] <aslak> joda-time, the currency/measurement stuff i guess.. but they are up for inclusion in se
[00:57:03] <mojavelinux> sure, there are quite a number of them
[00:57:08] <mojavelinux> of course, we don't really know or care about them, so....
[00:57:17] <mojavelinux> like the media jsr is one example
[00:57:34] <aslak> aa yes..
[00:57:37] <aslak> that's true
[00:57:50] <aslak> se 'extensions' :)
[00:58:32] <mojavelinux> yep, though it's interesting how they are finally dealing with things like jsr-310 correctly, they have a new type of "jsr" called a jep (double checking that acronym...)
[00:58:43] <mojavelinux> yep, jep
[00:58:45] <mojavelinux> jep 150
[00:58:51] <mojavelinux> http://openjdk.java.net/jeps/150
[00:59:09] <mojavelinux> jep == jsr for java se
[00:59:16] <aslak> aa
[00:59:27] <mojavelinux> where java se is "out of the box" java
[00:59:59] <aslak> so jeps are distributed in se ?
[01:00:24] <aslak> edition proposal ?
[01:00:44] *** csierra has left #jbosstesting
[01:02:31] <aslak> there we go: JDK Enhancement Proposal)
[01:05:13] <mojavelinux> yep, I just picked up on it from the java magazine
[01:05:17] <mojavelinux> pretty good content in that actually
[01:06:35] <mojavelinux> i think you worked out the naming quite nicely, exception for the name of the repository
[01:06:48] <mojavelinux> i think for spring we should have just one repository for now
[01:06:54] <mojavelinux> i'm find with arquillian-extension-spring
[01:06:57] <aslak> yea
[01:07:05] <aslak> not quite there yet..
[01:07:09] <mojavelinux> with modules for "integration", "service-deployers" and "service-container"
[01:07:11] <aslak> it's starts to get a bit mor emoddy
[01:08:18] <aslak> so, Persistence Extension in this alignment could be a DBUnit Service
[01:08:25] <aslak> but it's more then that
[01:08:47] <aslak> same with Drone, a Selenium Service integraiton, but it's more
[01:10:41] *** lfryc has quit IRC
[01:10:51] <aslak> and Graphene is a Selenium overbuilt, it does provide a Drone integration
[01:11:17] <mojavelinux> hmm, those get trickier
[01:11:50] <mojavelinux> I don't think we should take the "service" idea too far...because I sort of see a service more like the application services
[01:12:10] <mojavelinux> so for instance dbunit is a test service, not a main service...where as weld, openwebbeans, spring, hibernate...these are application services
[01:12:20] <mojavelinux> though, perhaps that just told us something
[01:12:33] <aslak> hmm yea
[01:12:39] <mojavelinux> to me, dbunit isn't a service, it's a....
[01:12:53] <mojavelinux> command, task, hmmm
[01:15:39] <mojavelinux> facility or utility (though something is on the tip of my mind that means something like scenario)
[01:16:18] <aslak> right, we have two top level types.. a Extension (something that require Core to run) and a 'Integration' (something that can optionally use Core+)
[01:16:49] *** mbg has joined #jbosstesting
[01:17:14] <aslak> persistence, drone, container, services being the first category, RushEye and Graphene on the other
[01:18:44] <aslak> not sure Service is the right word..
[01:19:09] <mojavelinux> so to me, graphene and warp are similar, in that they are test coordinators or overdrive :)
[01:19:18] <mojavelinux> i'm thinking about drone for a sec
[01:21:02] <mojavelinux> yeah, drone is actually similar in that regard...these are all extensions which are helping with coordinating the test scenario itself...they are enabling or empowering the test logic
[01:21:27] <mojavelinux> driving something or interweaving verifications
[01:21:38] <mojavelinux> but yes
[01:21:57] <mojavelinux> rusheye and graphene are special in that they can enhance an arquillian test, or they can be used independently
[01:22:02] <mojavelinux> they have arquillian integration
[01:22:05] <mojavelinux> instead of the other way around
[01:23:54] <mojavelinux> the way I define extension (in our world) is that it is building on core (not intertwined with core) and it enhances arquillian behavior as it's primary purpose (not a standalone library)
[01:24:28] <aslak> that's my definition of extension as well
[01:25:05] <aslak> we are talking about App Services and Test Services then..  where app provide something to the application you are writing and a test service provide something to help you test that applicatipon
[01:25:35] <aslak> so, drone is a service, but a Test Service.. redefining Service Deployer|Integration|Container to App Service xxx
[01:25:44] <aslak> app/frameworks
[01:25:53] <aslak> programming models
[01:26:01] <mojavelinux> exactly
[01:26:07] <mojavelinux> persistence is a test service as well
[01:26:11] <mojavelinux> as is performance
[01:26:12] <aslak> yes
[01:26:33] <aslak> so, Graphene provides a Test Service Integration for the Drone Test Service
[01:26:35] <mojavelinux> but to not overload "service", I think utility might be better terminology in this case
[01:26:45] <mojavelinux> besides, that's pretty traditional naming anyway
[01:26:57] <aslak> utillity?
[01:27:03] <mojavelinux> hence the predecessor of arquillian-extension-persistence, unitils
[01:27:28] <mojavelinux> a test service is often referred to as a test utility
[01:28:31] <aslak> hmm.. utillity to me is some random class that does a silly operation the 'language' makes to hard to repeat over and over
[01:28:54] <aslak> i guess it fits in that respect.. but
[01:28:58] <aslak> hehe
[01:31:31] <aslak> i find utility to be downgradinf
[01:31:33] <aslak> g
[01:32:35] <mojavelinux> we need to get on this page => http://java-source.net/open-source/testing-tools
[01:32:47] <mojavelinux> yeah, utility is crap, scratch that
[01:32:59] <mojavelinux> test service might be reasonable
[01:33:22] <mojavelinux> btw, I don't think we need to represent that in the repository name, but reasonable at least in the description
[01:33:54] <mojavelinux> btw, a nice extension for Arquillian is mock mail testing (things like dumpster or whatever alt cody uses for seam mail)
[01:34:04] <mojavelinux> that's a service container :)
[01:34:51] <mojavelinux> ah
[01:35:06] <mojavelinux> got another alternate for this terminology
[01:35:11] <mojavelinux> "test service" or "test support"
[01:35:31] <aslak> hmm.. yea that's another clash..
[01:36:34] <aslak> DeployableContainer should have a super class Service/Container that only support the lifecycle options.. while DeployableContianer adds deploy lifecycles
[01:36:56] <aslak> Mail, dataBase, Apache, FTP fall on the 'Service/Container' level
[01:36:58] <mojavelinux> I agree, i've been at least thinking that all along :)
[01:37:05] <mojavelinux> ...might have mentioned it ;)
[01:37:43] <mojavelinux> btw, I think we also need a teardown method...found a few cases w/ embedded glassfish where that would have been nice
[01:37:45] <aslak> can't do it all at once..
[01:37:52] <aslak> yea
[01:38:07] <mojavelinux> it's not stop since there might be an ensuing start
[01:38:22] <mojavelinux> teardown is like test suite is over
[01:38:34] <aslak> a counter part to setup you mean
[01:38:37] <mojavelinux> cleanup might be better name
[01:38:40] <mojavelinux> yep
[01:39:11] <mojavelinux> in embedded glassfish it would be nice for removing temporary domain instance...rather than using an VM hook
[01:39:19] <aslak> yea
[01:39:32] <mojavelinux> vm hook won't work if you have a long-running daemon, like gradle has
[01:39:39] <aslak> i know
[01:40:21] <mojavelinux> but yes, that would be a really nice progression at this point to have a Service or Container interface
[01:40:45] <mojavelinux> it's funny how well that applies even to embedded weld
[01:40:57] <mojavelinux> since start and deploy are really the same
[01:41:18] <mojavelinux> then you can just skip the idea of deployable container and just have Container
[01:41:32] <aslak> we have Container in spi
[01:42:34] <mojavelinux> ah, that actually brings me to the fact that this should be an adapter anyway, not just a container
[01:43:04] <mojavelinux> but that might be splitting hairs in the naming, at least until 2.0
[01:43:32] <mojavelinux> but a service is probably fine...that of course would be a service in the sense of an OS
[01:43:39] <mojavelinux> process?
[01:43:47] <mojavelinux> no, i like service
[01:43:55] <mojavelinux> maybe *service or service*
[01:43:59] <mojavelinux> need word at *
[01:44:02] <aslak> it was in the sence of os service i thought of it
[01:44:34] <mojavelinux> yep
[01:49:39] <mojavelinux> when the deployment fails, the tests are still run?
[01:50:07] <mojavelinux> ah, of course they are client tests...I guess that's reasonable
[01:50:28] *** PeteRoyle has joined #jbosstesting
[01:50:48] * aslak on phone
[01:53:12] <aslak> we've kinda touched upon the idea of having a 'Client Container' as well..
[01:53:39] <aslak> where you could deploy a javascript app to a seleneium container
[01:56:22] <mojavelinux> geez, AS 7 is logging a non-fatal exception that Weld can't load the test case as a bean because it can't find SW Asset.class
[01:56:25] <mojavelinux> what the hell is it doing?
[01:56:30] <mojavelinux> Weld! damn you
[02:00:29] <aslak> mojavelinux, still happy with the Yeti?
[02:01:28] <mojavelinux> oh yeah, support amazing quality
[02:01:40] <mojavelinux> we killed one, and they sent us another one
[02:01:42] <mojavelinux> awesome
[02:01:43] <aslak> wifes outside a best buy.. anything you need honey ?
[02:01:43] <aslak> hehe
[02:01:55] <mojavelinux> believe it or not, we managed to cause the microphone to lose its identity
[02:02:20] <aslak> identity?
[02:02:23] <mojavelinux> i don't know how the heck we managed to do that, but screwing with the virtual machines we managed to cause the kernel module to send it an unknown code that flipped a software switch inside of it
[02:02:29] *** konishi has joined #jbosstesting
[02:02:33] <mojavelinux> and it no longer identified itself to linux properly
[02:02:36] <mojavelinux> very strange
[02:02:40] <aslak> aa hehe funny
[02:02:43] <mojavelinux> hahahaha
[02:02:47] <mojavelinux> yeah, bring back the store
[02:03:42] <aslak> mojavelinux, you have pro?
[02:03:44] <aslak> the
[02:06:15] <mojavelinux> let me check
[02:07:40] <mojavelinux> nope, just yeti regular
[02:07:49] <mojavelinux> it's like hot dog shaped
[02:07:53] <aslak> yea
[02:08:08] <aslak> the pro v. seems to get worse reviews
[02:09:19] <aslak> hmm.. if we just apply 'stuff'' to our lingo.. it would be so much easier to categorise
[02:09:30] <aslak> cdi stuff, some weld stuff..
[02:09:46] *** abstractj is now known as abstractj|away
[02:15:23] <aslak> played with guava TypeToken yesterday..  so now everything in arq core is in Map<TypeToken<T>, T> maps instead of Class<T>, T as before.. meaning core has full generic support in Instance, Event, InstanceProducer, Observers etc
[02:16:05] <aslak> works nicely..
[02:16:21] <aslak> except that Guava is 1.7M library..
[02:16:26] <aslak> mb
[02:17:27] <aslak> tried to extract out the TypeToken part, but man is that library interwoven
[02:17:52] <aslak> Class level is no good, need to remove stuff on method level.. hehe
[02:19:45] <mojavelinux> hey, nice!
[02:19:53] <mojavelinux> eh, 1.7MB won't kill anyone
[02:20:01] <mojavelinux> won't even notice it when maven downloads itself :)
[02:20:20] <aslak> it's more on a pr test deployment issues
[02:20:50] <aslak> adding 1.7mb for basically one class is not acceptable.. :)
[02:22:04] <aslak> arq core should have no external deps
[02:22:28] <aslak> and i ran into the reasoning during this exercise
[02:23:07] <aslak> all tests in arq-core runs perfectly with the Guava lib added, except the CDI Enrichers, because it use Weld to run it's tests, which depend on their own version of Guava..
[02:25:12] *** mojavelinux has quit IRC
[02:39:42] *** mojavelinux has joined #jbosstesting
[02:39:42] *** mojavelinux has joined #jbosstesting
[02:42:56] *** os890 has quit IRC
[03:57:08] *** lightguard_jp has joined #jbosstesting
[03:58:12] *** konishi has quit IRC
[03:59:15] *** konishi has joined #jbosstesting
[04:02:13] *** rruss has joined #jbosstesting
[04:06:39] *** rruss has quit IRC
[04:12:23] *** rruss has joined #jbosstesting
[04:22:37] *** ldimaggi has joined #jbosstesting
[04:26:02] *** aslak has quit IRC
[04:48:12] *** rruss has quit IRC
[05:16:51] *** ldimaggi has quit IRC
[05:34:01] *** konishi has quit IRC
[05:47:13] *** konishi has joined #jbosstesting
[06:31:24] *** mbg has quit IRC
[06:33:40] *** mbg has joined #jbosstesting
[08:03:26] *** aaronwalker has joined #jbosstesting
[08:08:32] *** vnvarsete has joined #jbosstesting
[08:13:17] *** mojavelinux has quit IRC
[08:15:10] *** lightguard_jp has quit IRC
[08:15:39] *** baranowb has joined #jbosstesting
[08:28:45] *** jharting has joined #jbosstesting
[08:51:00] *** dabloem has joined #jbosstesting
[08:52:04] *** galderz has joined #jbosstesting
[08:52:53] *** maschmid has joined #jbosstesting
[08:57:29] *** mkouba has joined #jbosstesting
[09:05:18] *** kpiwko has joined #jbosstesting
[09:07:37] *** mnovak has joined #jbosstesting
[09:10:12] *** rbalent has joined #jbosstesting
[09:10:12] *** rbalent has quit IRC
[09:10:12] *** rbalent has joined #jbosstesting
[09:14:05] *** pilhuhn has joined #jbosstesting
[09:18:14] *** rmannibucau has joined #jbosstesting
[09:24:45] *** oskutka has joined #jbosstesting
[09:29:30] *** mbg has quit IRC
[09:36:32] *** baranowb_ has joined #jbosstesting
[09:38:51] *** baranowb has quit IRC
[09:41:04] *** ppitonak has joined #jbosstesting
[09:55:29] *** aaronwalker has quit IRC
[09:58:20] *** jean has joined #jbosstesting
[10:01:44] *** rbalent has quit IRC
[10:02:28] *** lkrejci has joined #jbosstesting
[10:02:28] *** lkrejci has joined #jbosstesting
[10:05:56] *** rbalent has joined #jbosstesting
[10:05:56] *** rbalent has quit IRC
[10:05:56] *** rbalent has joined #jbosstesting
[10:09:41] *** dabloem has quit IRC
[10:25:43] *** lfryc has joined #jbosstesting
[10:39:23] *** blabno has joined #jbosstesting
[10:44:03] *** dabloem has joined #jbosstesting
[10:45:01] *** blabno has quit IRC
[11:06:30] *** konishi has quit IRC
[11:16:22] *** vtunka has joined #jbosstesting
[11:30:04] *** maeste has joined #jbosstesting
[11:30:56] *** tombee has joined #jbosstesting
[11:39:12] *** sannegrinovero has joined #jbosstesting

top