(02:01:59 PM) mojavelinux: Are we ready to kickoff
(02:02:20 PM) ALR@Freenode: I think so. 2 minutes grace is about right.
(02:02:24 PM) aslak: mojavelinux, ok, you warm up the crowd with some jokes ?
(02:02:37 PM) mojavelinux: Please see this page for agenda: http://community.jboss.org/thread/147980
(02:03:38 PM) mojavelinux: What, I don't entertain you all enough on Twitter?
(02:03:40 PM) mojavelinux: Hehehe
(02:03:47 PM) aslak: hehe
(02:03:48 PM) jganoff: ^^
(02:03:55 PM) aslak: everyone had a look at the spi/apis ?
(02:04:09 PM) aslak: http://anonsvn.jboss.org/repos/common/arquillian/trunk/spi/src/main/java/org/jboss/arquillian/spi/
(02:04:25 PM) aslak: http://anonsvn.jboss.org/repos/common/arquillian/trunk/api/src/main/java/org/jboss/arquillian/api/
(02:04:43 PM) mojavelinux: That made me remember, we need to add a JavaDoc run to the build so that it's easier to browse them
(02:05:06 PM) ALR@Freenode: Is that covered in JIRA yet?
(02:05:14 PM) ALR@Freenode: I'll play secretary for today.
(02:05:45 PM) aslak: mojavelinux, your talking about a combines javadoc as part of ahte main build?
(02:05:49 PM) aslak: combined
(02:07:40 PM) mojavelinux: yeah, just so that they are created when the reference guide is created
(02:07:55 PM) kenglxn [~ken@c5E90BF51.dhcp.bluecom.no] entered the room.
(02:08:23 PM) ALR@Freenode: Do you guys mind if we start with JIRA "components" configuration?
(02:08:46 PM) pmuir [~pmuir@redhat/jboss/pmuir] entered the room.
(02:09:27 PM) aslak: ALR, you wanna go straight to jira ? no spi/api walk through ?
(02:09:42 PM) ALR@Freenode: aslak: Oh, that's the bread and butter!
(02:09:45 PM) pmuir: hi guys, sorry i'm a bit late
(02:09:47 PM) ALR@Freenode: aslak: You're the main event.
(02:09:54 PM) mojavelinux: Sure, I was just able to suggest that we select a starting topic...actually, if you want to estalish an order
(02:09:54 PM) aslak: heya pmuir
(02:10:04 PM) mojavelinux: @pmuir, the starting act I heard was bad anyway
(02:10:32 PM) ALR@Freenode: aslak: I noticed we'll be making some JIRAs today though, and the components in there don't match the project layout (should they?)
(02:10:43 PM) ALR@Freenode: Typically I equate "component" in JIRA with "module" in Maven
(02:11:08 PM) lightguard_jp: Yeah, makes things easier to see where the issues are in relation to the project.
(02:11:20 PM) aslak: ALR, ohh, those component.. i thought you meant the 'core' configuration jira issue..
(02:11:51 PM) ALR@Freenode: Ah no. Just administration stuff.
(02:12:04 PM) aslak: ALR, sure
(02:12:05 PM) pmuir: IMO the best way to organise components in JIRA is along logical lines, it makes it easier to organise the issues
(02:12:28 PM) pmuir: I would avoid categorizations like "Core" as they don't really mean much
(02:12:36 PM) mojavelinux: +1
(02:12:52 PM) ALR@Freenode: OK, a bit of a different setup you guys do then
(02:13:26 PM) ALR@Freenode: I track modules (which should also really be logical, when you think about it) so that if they ever go to their own release cycle I can move issues around easier.
(02:13:30 PM) mojavelinux: it would be somewhat of a hybrid
(02:14:05 PM) aslak: the way it is now, we ahve core that is 'Arquillian, TestNG and Junit which are the starting points, and Jobss Containers(a combinations of all jboss containers/versions)(should add GlassFish container etc as well)
(02:14:09 PM) mojavelinux: so TestNG integration, JUnit integration, Containers, Enricher, Protocol
(02:14:23 PM) ALR@Freenode: OK, I've made "Build Configuration"
(02:14:30 PM) mojavelinux: yes, if we break down TestNG and JUnit, then we should break down each container as well
(02:14:37 PM) pmuir: I would avoid independent release cycles for modules, it's a mess with maven
(02:14:41 PM) mojavelinux: easier to assign GlassFish issues to one set of people
(02:14:51 PM) pmuir: I suppose my point is just that a component might be finer grained than a module
(02:14:53 PM) ALR@Freenode: pmuir: Yeah I only do that when they graduate out of modules and into projects.
(02:15:03 PM) lightguard_jp: pmuir: +1 to making maven releases easier
(02:15:33 PM) pmuir: yup, TBH if we want graduate a module to a project, it makes sense to make a new JIRA project for it (something I am also guilty of not doing)
(02:15:46 PM) ALR@Freenode: pmuir: Ha, in EJB3 we'd have 50 projects.
(02:15:48 PM) pmuir: anyway, I like Dan's setup
(02:15:54 PM) ALR@Freenode: Yep.
(02:16:04 PM) ALR@Freenode: We can proceed I think.
(02:16:07 PM) mojavelinux: We could consider making containers a project in JIRA
(02:16:19 PM) ALR@Freenode: Would we like to start w/ aslak introducing the API, then SPI?
(02:18:27 PM) pmuir: Good idea
(02:18:43 PM) pmuir: or perhaps we should start with a 10 000 foot view
(02:18:46 PM) pmuir: if we have one
(02:19:04 PM) lightguard_jp: I say go for the global view, then dive down
(02:19:05 PM) ALR@Freenode: The end result of a 10000 foot view is always: splat.
(02:19:09 PM) ALR@Freenode:
(02:19:13 PM) ALR@Freenode: Dig it.
(02:19:15 PM) mojavelinux: we have worked to establish a mission statement in the reference guide and on this page
(02:19:20 PM) ALR@Freenode: mojavelinux: Take it away
(02:19:35 PM) mojavelinux: http://community.jboss.org/docs/DOC-14376?uniqueTitle=false
(02:19:54 PM) ALR@Freenode: Already I have a question
(02:20:00 PM) ALR@Freenode: Which has been on the forums a bit:
(02:20:03 PM) ALR@Freenode: "Arquillian provides a easy mechanism to test your application code inside a container"
(02:20:29 PM) mojavelinux: that mission statement isn't in stone yet, btw
(02:20:40 PM) aslak: .. trouble maker..
(02:20:50 PM) ALR@Freenode: I've got a few use cases that don't require (and shouldn't have actually) the test running in the container.
(02:21:16 PM) mojavelinux: it comes down to how you define the term "container" I think
(02:21:18 PM) mojavelinux: can you cite the case
(02:21:24 PM) aslak: ALR, this is where run locally' mode comes in.. Arquillian dpeloyes, but does not execute the testcase remote
(02:21:57 PM) aslak: ALR, need a jira on this btw..
(02:22:12 PM) ALR@Freenode: The case is: I have a @Deployment, and altering it causes the container to err out.
(02:22:12 PM) mojavelinux: as I defined it, the container can be a bootstrapped framework environment, such as Weld SE
(02:22:32 PM) ALR@Freenode: mojavelinux: Sure. But there's also Embedded containers.
(02:22:34 PM) mojavelinux: to Arquillian, it is still "deploying", in this case it is just setting up things locally
(02:22:38 PM) ALR@Freenode: Which are real containers.
(02:22:47 PM) ALR@Freenode: And the test case should be executed outside of the deployment.
(02:22:48 PM) mojavelinux: yes, I agree: see
(02:23:10 PM) aslak: ALR, that's a different issue then not running it in the container.. you don't want arquillian to do the touch the packaging
(02:23:10 PM) ALR@Freenode: Some talks aslak and I had earlier showed we may not have been in full agreement.
(02:23:32 PM) mojavelinux:
(02:23:34 PM) ALR@Freenode: aslak: I also want the test outside the container.
(02:23:40 PM) pmuir: ALR: yes, you need to deploy the artifact, and then execute the test in the local VM, somehow interacting with the deployed artifact (e.g. EJB 3 remote, htmlunit/jsf, WS), and then undeploy it when the test ends
(02:24:01 PM) mojavelinux: yes
(02:24:07 PM) ALR@Freenode: Yep, it's the simplest case I think.
(02:24:10 PM) aslak: pmuir, and in that case we don't have to add stuff to the deployment either
(02:24:13 PM) ALR@Freenode: And maybe the most frequent.
(02:24:15 PM) mojavelinux: @ALR, your point about not touching the packaging in cases was a good one
(02:24:16 PM) pmuir: ok, so what ALR is saying is that there are actually 3 levels:
(02:24:23 PM) pmuir: 1) remote test inside the container
(02:24:32 PM) pmuir: 2) local test, against a remote container
(02:24:39 PM) pmuir: 3) local test, against a local container
(02:24:51 PM) pmuir: only for (1) does the test case need packaging inside the artifact
(02:24:54 PM) ALR@Freenode: Right.
(02:24:55 PM) aslak: what is the diff between 2/3?
(02:25:07 PM) ALR@Freenode: So the only thing I think we need to clarify is our use of "local" and "remote".
(02:25:09 PM) mojavelinux: communication and deployment
(02:25:11 PM) pmuir: (when I say test case, I mean test class + supporting classes, libraries etc.)
(02:25:15 PM) ALR@Freenode: Proximity to JVM and to physical machine.
(02:25:34 PM) mojavelinux: keep in mind that there is a separate classification, which is spec compliance
(02:25:42 PM) pmuir: aslak: from a packaging perspective, none, but from a conceptual perspective, some
(02:25:50 PM) aslak: pmuir, right
(02:25:52 PM) mojavelinux: so container can be Java EE, servlet or bean
(02:26:32 PM) mojavelinux: @pmuir, good way of saying it
(02:26:34 PM) aslak: mojavelinux, container is 'anything' that supports a type of deployment
(02:27:02 PM) ALR@Freenode: Weld doesn't support deployments?
(02:27:09 PM) aslak: ALR, ohh?
(02:27:26 PM) ALR@Freenode: Weld ==Framework, not container.
(02:27:30 PM) mojavelinux: yes, you are deploying the beans....not a packaged deployment, but certainly a deployment
(02:27:42 PM) jganoff: WeldSE Container?
(02:27:45 PM) mojavelinux: or by deployment do we imply package
(02:28:00 PM) ALR@Freenode: jganoff: Yep, SE.
(02:28:09 PM) aslak: deployment we can say anything that lets you 'split' out from app claspath?
(02:28:36 PM) aslak: no..
(02:29:05 PM) pmuir: essentially I agree, you can't "deploy" to Weld in Java EE or Servlet
(02:29:16 PM) pmuir: but you can in Java SE OR a mock EE/Servlet environment
(02:29:17 PM) mojavelinux: deployment is really the process of handing off the code to be tested
(02:29:24 PM) aslak: deployment, something that lets you control what the container can see/use ?
(02:29:36 PM) ALR@Freenode: I might say:
(02:30:01 PM) mojavelinux: @aslak I see what you are saying about "splitting out" the classpath
(02:30:02 PM) ALR@Freenode: Deployment: the process of handing off an artifact to an environment; the test then depends upon the environment to make state changes
(02:30:28 PM) aslak: environment/container
(02:30:46 PM) mojavelinux: @ALR so the question is, can "artifact" be registering beans w/ Weld SE
(02:30:56 PM) mojavelinux: does that fit?
(02:31:05 PM) ALR@Freenode: I don't know
(02:31:13 PM) ALR@Freenode: Aren't you on the Weld team?
(02:31:21 PM) aslak: mojavelinux, it has to.. it does to day. if not, redefine..
(02:31:45 PM) ALR@Freenode: I'm wondering what the difference between "framework" and "container" modes we have are, really.
(02:31:50 PM) mojavelinux: I'm asking if it fits conceptually; I think it does
(02:31:51 PM) dhinojosa [~dhinojosa@c-68-35-42-36.hsd1.nm.comcast.net] entered the room.
(02:31:56 PM) ALR@Freenode: And how a framework is different from an Embedded container.
(02:31:57 PM) mojavelinux: ShrinkWrap is creating a bean archive
(02:31:58 PM) pmuir: do we have a difference?
(02:32:04 PM) ALR@Freenode: There's lifeycle, there's deployment.
(02:32:20 PM) mojavelinux: So I think this definition works:
(02:32:26 PM) mojavelinux: Deployment: the process of handing off an artifact to an environment; the test then depends upon the environment to make state changes
(02:32:51 PM) mojavelinux: then the question becomes, when does Arquillian enrich that archive?
(02:33:05 PM) mojavelinux: that would be all but #2
(02:33:10 PM) aslak: mojavelinux, that's a q for later..
(02:33:12 PM) ALR@Freenode: "enrich" and "archive"?
(02:33:19 PM) mojavelinux: enrich an archive
(02:33:24 PM) pmuir: right, let's stick to the mission statement for now
(02:33:28 PM) mojavelinux: which was your objection @ALR to some cases
(02:33:45 PM) mojavelinux: when you didn't want Arquillian getting its hands in the ShrinkWrap archive you created
(02:33:49 PM) ALR@Freenode: mojavelinux: Ah true.
(02:34:27 PM) aslak: mojavelinux, ALR.. there is a proposed fix for this coming in the spi walk through..
(02:34:27 PM) ALR@Freenode: So anyway I guess I bring this up to clarify that I'd really like to nail down these "run modes"/
(02:34:44 PM) pmuir: yeah
(02:34:58 PM) mojavelinux: I think we can address that in the mission statement but not being so vague
(02:35:03 PM) mojavelinux: how about we say....
(02:35:04 PM) pmuir: Do we want to include this as a second paragraph to the mission statement?
(02:36:26 PM) mojavelinux: to test the code from within the container or to test against the code deployed to a container
(02:36:48 PM) mojavelinux: a subtle difference, but it grabs all bullet points above
(02:36:49 PM) mojavelinux: assuming...
(02:37:00 PM) pmuir: mojavelinux: IO like that
(02:37:03 PM) mojavelinux: that container can be Weld SE too...and that deployment is handing those beans to Weld SE
(02:37:18 PM) pmuir: I also wonder if we want to enumerate examples of "containers" to show what we mean
(02:37:28 PM) mojavelinux: @pmuir yes
(02:37:30 PM) mojavelinux: for sure
(02:37:45 PM) mojavelinux: By container we mean...
(02:37:52 PM) mojavelinux: and I'll expand
(02:38:16 PM) aslak: Jboss AS, GlassFish, Weld SE, Spring, Guice, OpenEJB, Resin, MC, Jetty
(02:38:41 PM) lightguard_jp: tomcat
(02:38:49 PM) mojavelinux: yes and no
(02:38:53 PM) mojavelinux: yes I can cite specific examples
(02:38:56 PM) pmuir: ... containers (for example a Java EE container such as JBoss AS, a servlet container such as Tomcat, an embeddable container such as <whatever it is called this month> or a XXX)
(02:38:56 PM) aslak: Tomcat, GlassFish EMbedded, JBoss Embedded
(02:39:07 PM) mojavelinux: no, I mean I'll expand to the types of containers one can have
(02:39:09 PM) mojavelinux: not vendors
(02:39:28 PM) aslak: mojavelinux, sky's the limit..
(02:39:40 PM) pmuir: and XXX is where I fall down - I want to have a word for what the Weld SE container is - it doesn't deal with Jar based deployments so...
(02:39:55 PM) pmuir: what do Guice call themselves?
(02:40:03 PM) aslak: ioc framework ?
(02:40:03 PM) mojavelinux: remote, standalone container; local, managed container; embedded container; custom bean environment (still dont' have a good word for Weld SE)
(02:40:20 PM) ALR@Freenode: I think the word is "Framework".
(02:40:31 PM) aslak: Guice (pronounced 'juice') is a lightweight dependency injection framework
(02:40:32 PM) ALR@Freenode: Except for us it has no different semantics than "Embedded Container".
(02:40:42 PM) mojavelinux: emulated container?
(02:40:52 PM) pmuir: ALR: framework is *very* generic
(02:40:56 PM) ALR@Freenode: So it looks like they fit in the same category
(02:41:05 PM) aslak: pmuir, and container is not ? hehe
(02:41:06 PM) pmuir: yeah
(02:41:08 PM) ALR@Freenode: pmuir: So are we, though.
(02:41:08 PM) mojavelinux: in some sense, CDI alone (maybe w/ EL and BV thrown in there) is custom environment, simulated
(02:41:12 PM) mojavelinux: what about simulated
(02:41:19 PM) ALR@Freenode: What are we simulating?
(02:41:38 PM) pmuir: yeah, let's call it an Embedded Container, but say explicitly what we mean ;-)
(02:41:39 PM) mojavelinux: simulating the environment where you will be deploying...a partial simulation obviously
(02:42:09 PM) aslak: mojavelinux, isn't that part of our mission statement not to be.. we are the real thing, not a mock of it
(02:42:18 PM) mojavelinux: @pmuir okay, so we can say embedded container (partial, like CDI) or embedded container (full Java EE)
(02:43:06 PM) pmuir: mojavelinux: yeah, I think partial is quite good
(02:43:09 PM) mojavelinux: @aslak true, Weld SE can be considered a true embedded container, just not of the Java EE variety
(02:43:24 PM) mojavelinux: so I can just put weave partial in there to suggest it is partial of the Java EE spec
(02:43:29 PM) mojavelinux: servlet container is also partial
(02:43:53 PM) kenglxn: +1
(02:44:15 PM) mojavelinux: that makes a lot of sense...liking that
(02:44:16 PM) kenglxn: partial / full
(02:44:28 PM) aslak: mojavelinux, it feels unfair to me that only use cdi to call it a partial container
(02:44:28 PM) ALR@Freenode: If "partial" describes JEE, I think we should stay away from it.
(02:44:35 PM) ALR@Freenode: We're a deployment/lifecycle mechanism.
(02:44:43 PM) ALR@Freenode: What the container does for you is kinda out of scope.
(02:44:55 PM) mojavelinux: no, "full" is Java EE
(02:45:04 PM) ALR@Freenode: We could write a Java Logging container which "deployed" something to a log.
(02:45:05 PM) mojavelinux: partial is CDI alone or servlet alone (or w/ CDI)
(02:45:19 PM) aslak: mojavelinux, what is spring / guice then? partial ee ? hehe
(02:45:23 PM) pmuir: the reason Weld is partial is that it doesn't handle a real deployment like a JAR
(02:45:25 PM) pmuir: IMO
(02:45:26 PM) ALR@Freenode: I mean, "partial" is in respect to JEEE.
(02:45:51 PM) ALR@Freenode: So I guess I'm asking why we make explicit the relation with JEE.
(02:45:54 PM) pmuir: it essentially "enriches" the plain JVM
(02:45:59 PM) aslak: ALR, i agree
(02:46:00 PM) ALR@Freenode: When we are really more abstract.
(02:46:08 PM) ALR@Freenode: Like we run in SE alone.
(02:46:24 PM) aslak: weld se is capable of standing on it's own feet.. why say it's a partial something else
(02:46:40 PM) pmuir: well why not just call them all embeddable containers and explain through reference to examples
(02:46:42 PM) ALR@Freenode: aslak: Yep, that's what I'm very poorly trying to get across.
(02:46:50 PM) ALR@Freenode: pmuir: Yep.
(02:47:13 PM) dhinojosa: Hey everyone.
(02:47:17 PM) ALR@Freenode: Like if you put an EJB JAR into a Jetty container, that's not our problem
(02:47:23 PM) aslak: we've started this here:
(02:47:28 PM) mojavelinux: hmmm
(02:47:41 PM) aslak: hi dhinojosa
(02:47:53 PM) dhinojosa: Been lurking, but is WELD something that can have host?
(02:47:57 PM) mojavelinux: I guess I've been holding on to this "promise" of giving them the real Java EE deal
(02:48:03 PM) dhinojosa: or can exist on it's own
(02:48:13 PM) dhinojosa: is that what was trying to be conveyed?
(02:48:15 PM) mojavelinux: and trying to keep it clear when we are only partially delivering on that
(02:48:25 PM) pmuir: dhinojosa: what does "have host" mean?
(02:48:37 PM) mojavelinux: but there is one other distinction
(02:48:41 PM) mojavelinux: you see
(02:48:46 PM) aslak: mojavelinux, i think we should state that ee is only partial what we support..
(02:48:54 PM) dhinojosa: just trying to interpret what the words you're trying to complete.
(02:49:01 PM) mojavelinux: embedded GlassFish is really no different than a managed version of GlassFish
(02:49:03 PM) dhinojosa: so I can better understand
(02:49:10 PM) mojavelinux: all you are doing is changing how start and stop work
(02:49:22 PM) mojavelinux: you are still deploying "over the wire", correct?
(02:49:28 PM) mojavelinux: and testing through HTTP
(02:49:30 PM) kenglxn: testing for any environment, custom or full/partial EE
(02:49:40 PM) aslak: mojavelinux, not deploying over the wire, but testing via http yes
(02:49:55 PM) ALR@Freenode: For Embedded GlassFish I think that should change.
(02:50:03 PM) pmuir: well not really, in embeddable Blah, you would probably want to test directly
(02:50:05 PM) pmuir: not via http
(02:50:08 PM) ALR@Freenode: Right
(02:50:09 PM) mojavelinux: so to put Embedded GlassFish and Weld SE in the same classification just seems to me like really vague
(02:50:14 PM) ALR@Freenode: (Unless you're testing a Servlet)
(02:50:15 PM) aslak: mojavelinux, direct shrinwrap extension to handle glassfishs readablearchive
(02:50:23 PM) pmuir: yeah
(02:50:34 PM) pmuir: I think we have two types of container - remote and embeddable
(02:50:38 PM) mojavelinux: but how do you get the tests to run inside the container
(02:50:43 PM) mojavelinux: you have to work through the servlet, don't you?
(02:50:46 PM) pmuir: with emedded?
(02:50:47 PM) aslak: ALR, sure, serlvet is only one of multiple possible container protocols, jms, rmi etc
(02:50:48 PM) mojavelinux: the Arquillian servlet
(02:50:57 PM) aslak: jmx i mean..
(02:51:03 PM) mojavelinux: (right, alternatives exist too)
(02:51:40 PM) mojavelinux: so embedded glassfish is not really embedded at all
(02:51:48 PM) mojavelinux: it is only embedded in that you don't have to go download it
(02:51:57 PM) mojavelinux: same as JBoss Embedded AS
(02:52:02 PM) aslak: it just as embedded as weld se ?
(02:52:11 PM) mojavelinux: Weld SE is truly embedded
(02:52:14 PM) aslak: it's running off the same classpath
(02:52:16 PM) pmuir: no embedded glassfish runs in the same JVM as junit/testng
(02:52:21 PM) mojavelinux: because we are actually starting the environment and putting beans in there manually
(02:52:35 PM) mojavelinux: yes, it runs in the same JVM
(02:52:41 PM) ALR@Freenode: "Embedded" is a term I use with respect to JVM.
(02:52:57 PM) mojavelinux: hmmm
(02:52:58 PM) ALR@Freenode: So if they share a process, I've been calling that "Embedded".
(02:53:02 PM) pmuir: right, that is what Embedded is generally taken to mean
(02:53:11 PM) aslak: my understand as well
(02:53:46 PM) pmuir: and you would run the test the same way in Embedded JBoss AS as in Weld SE
(02:53:47 PM) aslak: using Jboss ServerManagement api, even thos the api is run 'embedded' the container is started remote
(02:54:06 PM) mojavelinux: okay, so this comes down to compliance
(02:54:08 PM) ALR@Freenode: aslak: I wouldn't say that.
(02:54:17 PM) pmuir: mojavelinux: compliance?
(02:54:18 PM) mojavelinux: they are both embedded, but have a different level of compliance
(02:54:20 PM) pmuir: with what?
(02:54:25 PM) pmuir: oic
(02:54:27 PM) mojavelinux: yes, Weld SE can provide all of CDI
(02:54:35 PM) ***ALR@Freenode still lost on "compliance"
(02:54:37 PM) mojavelinux: but embedded Glassfish can give you datasources, etc
(02:54:37 PM) pmuir: yes, one is spec'd, one isn;t
(02:54:45 PM) mojavelinux: what I'm saying is
(02:54:46 PM) aslak: ALR, does it go directly on Main ?
(02:54:48 PM) mojavelinux: if you wanted to group your tests
(02:55:01 PM) pmuir: well Weld SE only provides CDI services with no EE services
(02:55:09 PM) mojavelinux: you would say "this test requires Java EE compliance because it depends on managed resources that are going to be there in a real container"
(02:55:16 PM) mojavelinux: well, hopefully just a word for that
(02:55:23 PM) pmuir: whilst Embedded JBoss provides all services offered by Java EE
(02:55:25 PM) mojavelinux: then you might say that this test can be run on anything that provides CDI
(02:55:36 PM) pmuir: I think what they provide is fairly obvious from their name
(02:55:47 PM) mojavelinux: right
(02:55:50 PM) mojavelinux: I get it now
(02:55:56 PM) mojavelinux: embedded means same JVM
(02:56:11 PM) mojavelinux: then from there, you can think about what you are actually running on to group your tests appropariately
(02:56:14 PM) pmuir: yes
(02:56:19 PM) mojavelinux: woot
(02:56:21 PM) pmuir: they are orthogonal concerns really
(02:56:29 PM) ALR@Freenode: Yep.
(02:56:33 PM) lightguard_jp: Well all on the same page with wording now? I think we've digressed a bit from the outline
(02:56:38 PM) pmuir: embedded vs remote is about how you launch a test / where it runs
(02:56:47 PM) ALR@Freenode: Yep.
(02:56:56 PM) mojavelinux: got it
(02:56:57 PM) ALR@Freenode: So when we talk about physical locality, what language can we use?
(02:57:08 PM) pmuir: whilst capababilities is about what services the container offers
(02:57:13 PM) ALR@Freenode: "local and remote" to me, in EJB-land, are @Local and @Remote, by JVM
(02:57:20 PM) pmuir: (btw capabilities is a good word :-)
(02:57:30 PM) mojavelinux: capabilities is a much better word than compliance
(02:57:32 PM) mojavelinux: good call
(02:57:33 PM) pmuir: ALR: I prefer remote and embedded
(02:57:52 PM) ALR@Freenode: pmuir: "Remote" there meaning "another JVM"?
(02:58:04 PM) mojavelinux: remote and embedded work for me
(02:58:16 PM) pmuir: ALR: yes
(02:58:24 PM) mojavelinux: btw, just because Arquillian starts the container, doesn't mean that it isn't remote....I think you can have a remote, managed container
(02:58:30 PM) aslak: ok, we skip local then(remote with life cycle control) ?
(02:58:41 PM) ALR@Freenode: pmuir: Me too. aslak has some cases where we need to distinguish physical location
(02:58:48 PM) ALR@Freenode: (Due to unshared filesystem)
(02:58:49 PM) mojavelinux: the "managed" part just means "please start that container over there for me to save me the trouble"
(02:59:09 PM) mojavelinux: technically, you could start a container even on a different machine
(02:59:15 PM) ALR@Freenode: Though I think we should punt on this "starting physically remote" servers feature for the time being.
(02:59:18 PM) pmuir: mojavelinux: yes, that is a good use
(02:59:32 PM) pmuir: yes, physically remote is something for 1.1 IMO
(02:59:36 PM) mojavelinux: @ALR yeah, we don't need to try it now
(02:59:38 PM) ALR@Freenode: Like we could launch a few great alphas without it.
(02:59:40 PM) ALR@Freenode: OK cool.
(02:59:53 PM) aslak: hehe funny thing is that that's the only thing tha tworks..
(03:00:10 PM) ALR@Freenode: aslak: Hehe, implementation detail we'll make it all work.
(03:00:19 PM) aslak: hehe
(03:00:35 PM) mojavelinux: so just to sum up...hopefully not to go off track
(03:00:39 PM) mojavelinux: we have remote and embedded containers
(03:00:52 PM) mojavelinux: embedded containers are in the same JVM and are always managed (they have to be started/stopped)
(03:00:54 PM) dhinojosa left the room (quit: Quit: Java user signed off).
(03:01:21 PM) mojavelinux: remote containers which are in a separate JVM and may be managed, or Arquillian may just "bind" to them if they are assumed to be already running
(03:01:55 PM) mojavelinux: any container can be further classified by it's capabilities; don't assume that all embedded containers are equal in this regard
(03:02:19 PM) ALR@Freenode: mojavelinux: Ye.
(03:02:20 PM) ALR@Freenode: *es
(03:02:27 PM) ALR@Freenode: Darn *Yes
(03:02:51 PM) ALR@Freenode: mojavelinux: So long as we don't do any upfront validation to try and restrict users from deploying stuff into containers that don't support it.
(03:02:57 PM) ALR@Freenode: (I don't like trying to be too smart).
(03:03:00 PM) mojavelinux: and finally
(03:03:25 PM) mojavelinux: we can either test code from within the container or test code that is deployed to the container
(03:03:34 PM) aslak: ALR, agree.. if i want to deploy cdi to jboss 5 i should be allowed to.. (i just might have managed to get it to work.. )
(03:03:46 PM) pmuir: mojavelinux: that last sentence is confusing
(03:04:01 PM) ALR@Freenode: Yep. The command line won't stop me from copying an MP3 into JBossAS.
(03:04:03 PM) mojavelinux: @pmuir I'll find a way to bring out the difference
(03:04:11 PM) kenglxn: alr: +1 let the container throw the error if there is one
(03:04:17 PM) aslak: ALR, with dna that makes sense even.. hehe
(03:04:21 PM) mojavelinux: Arquillian is not in the business of validating what you are trying to run; that is for you to control via test groups
(03:04:29 PM) ALR@Freenode: Beautiful.
(03:04:33 PM) mojavelinux: what Arquillian needs to be good at...
(03:04:54 PM) mojavelinux: is passing back exceptions, whether deployment exceptions, CDI validation exceptions or regular broken code exceptions
(03:05:13 PM) ALR@Freenode: == don't swallow Exceptions
(03:05:22 PM) pmuir: it should be "the test case can either run inside the deployment, or connect to the deployment"
(03:05:31 PM) pmuir: that's not right still
(03:05:37 PM) aslak: mojavelinux, i'll make sure it blows up completely..
(03:05:41 PM) ALR@Freenode: Yeah, the test may not do anything with the deployment.
(03:05:49 PM) mojavelinux: well, it's not just swallowing exceptions...
(03:06:05 PM) mojavelinux: I had a case the other day where Arquillian was saying something about "cannot enrich"
(03:06:13 PM) ALR@Freenode: The test case may either run as part of the container, or interact as a normal client.
(03:06:13 PM) mojavelinux: on the server, I had two beans conflicting
(03:06:21 PM) pmuir: ALR: thats good
(03:06:41 PM) mojavelinux: so it's about recognizing that something went wrong, that the server is trying to communicate something and getting it back to the test failure report
(03:06:54 PM) mojavelinux: @pmuir did some nice stuff w/ this in the CDI TCK harness
(03:07:06 PM) ALR@Freenode: Cool.
(03:07:09 PM) mojavelinux: using an exception translator
(03:07:24 PM) mojavelinux: impl had to tap into JBoss ProfileConnector (or whatever it is called)
(03:07:50 PM) pmuir: though I would say something about the deployment still, as it reinforces the idea that the test runs inside the the environment of the artifact, not just in the whole of JBoss AS
(03:08:04 PM) pmuir: yes, it is useful to be able to see how a deployment failed, not just that it failed
(03:08:08 PM) aslak: mojavelinux, yea, we also need to be aware of ClassNotFound exceptions on returning exceptions..
(03:08:25 PM) mojavelinux: ProfileService was the right name
(03:08:28 PM) pmuir: but this is probably a feature for down the line
(03:08:56 PM) mojavelinux: sure, just something for the mission (actually the more technical direction of project)
(03:09:16 PM) mojavelinux: for the record org.jboss.testharness.api.DeploymentExceptionTransformer
(03:09:33 PM) pmuir: yup, "Arquillian allows you to inspect why your deployment failed"
(03:09:37 PM) ALR@Freenode: So regarding the missing statement:
(03:09:59 PM) ALR@Freenode: "Arquillian takes the plumbing out of integration testing" ?
(03:10:16 PM) ALR@Freenode: Or something with greater impact but same simplicity?
(03:10:27 PM) aslak: pmuir, another spi under control by the container i guess
(03:10:39 PM) mojavelinux: @ALR that would be a good sentence for "in other words...."
(03:10:55 PM) kenglxn: +1
(03:11:01 PM) ALR@Freenode: I'm looking at: http://community.jboss.org/docs/DOC-14376
(03:11:02 PM) mojavelinux: like a take away statement
(03:11:05 PM) pmuir: aslak: yeah, basically, except it's quite complex as there can be // failures
(03:11:18 PM) ALR@Freenode: We have 4 references to "testing in the container"
(03:12:12 PM) aslak: pmuir, yea, but the container should know how to desifre it's own exceptions, not a extension.
(03:12:19 PM) ALR@Freenode: Should we move to code?
(03:12:33 PM) ALR@Freenode: And make a JIRA item to update the Wiki, taking into consideration the discussions here?
(03:12:52 PM) pmuir: ALR: I'm good
(03:13:07 PM) mojavelinux: yep...keep in mind that the mission statement on the wiki is/should be a clone of what is in the reference guide
(03:13:12 PM) ALR@Freenode: pmuir: Only problem w/ Wiki updates in JIRA is that they make it into the release notes.
(03:13:20 PM) ALR@Freenode: OK, good point
(03:13:42 PM) mojavelinux: @ALR which is okay since it will be updating the reference guide at the same time, part of the release
(03:13:44 PM) aslak: ALR, with out a fixed v. as well?
(03:13:48 PM) pmuir: lol, ok, well mojavelinux can you take as an AI to update the wiki/ref guide based on discussion and then post when you have made the change
(03:13:54 PM) mojavelinux: done
(03:13:57 PM) mojavelinux: taken
(03:14:40 PM) ALR@Freenode: https://jira.jboss.org/jira/browse/ARQ-65
(03:15:04 PM) mojavelinux: we need a documentation component in JIRA
(03:15:17 PM) ALR@Freenode: OK, I put it under "Project Management"; will rename that.
(03:15:39 PM) ALR@Freenode: Done
(03:16:33 PM) mojavelinux: documentation issues always get targeted at the GA release in Seam and Weld, so I'll mark that (oh, I should have said GA, I might get a ruler to the knuckles)
(03:16:41 PM) mojavelinux: s/should/shouldn't/
(03:17:47 PM) pmuir: s/GA/Final/
(03:17:57 PM) ALR@Freenode: 1.0.0.Final ?
(03:17:58 PM) mojavelinux: @pmuir
(03:18:06 PM) mojavelinux: 1.0.0
(03:18:09 PM) mojavelinux: we just call it final
(03:18:13 PM) aslak: mojavelinux, weld/seam releases has stopped being general acceptable ?
(03:18:14 PM) ALR@Freenode: k
(03:18:20 PM) ALR@Freenode: What's the point of 1.0.0-alpha-2 ?
(03:18:22 PM) lightguard_jp: non-snapshot
(03:18:24 PM) ALR@Freenode: There are 4 issues assigned
(03:18:26 PM) mojavelinux: we aren't allow to use the term GA anymore
(03:18:34 PM) mojavelinux: politics
(03:18:38 PM) ALR@Freenode: Typically I keep everything thats unscheduled, well, unscheduled.
(03:18:41 PM) pmuir: thought police
(03:18:51 PM) pmuir: ALR: I agree with that tactic :-)
(03:18:55 PM) ALR@Freenode: And assign to a release when either done or required by a specific version
(03:18:57 PM) ALR@Freenode: k
(03:19:11 PM) pmuir: well, for feature requests, yes
(03:19:22 PM) pmuir: for bugs, I tend to put them for the next release, unless there is a good reason not to
(03:20:10 PM) ALR@Freenode: k, versions in JIRA should now be fixed up pretty good.
(03:20:17 PM) ALR@Freenode: Only 2 issues targeted for 1.0.0-alpha-1
(03:20:20 PM) ALR@Freenode: Rest unscheduled.
(03:20:24 PM) ALR@Freenode: And a 1.0.0 in the wings.
(03:22:10 PM) ***ALR@Freenode is ready for code!
(03:22:17 PM) pmuir: me too ;-)
(03:22:21 PM) mojavelinux: so we need to talk about the SPIs, but also we really need to get to the issue of a configuration too
(03:22:28 PM) ALR@Freenode: Agreed.
(03:22:28 PM) mojavelinux: let's move along
(03:22:32 PM) ALR@Freenode: APIs first?
(03:22:34 PM) ALR@Freenode: Then SPIs?
(03:22:48 PM) ALR@Freenode: I don't know how much time we realistically have today.
(03:22:53 PM) ALR@Freenode: Unless we make this openended.
(03:22:57 PM) mojavelinux: there is only one API, isn't there?
(03:23:00 PM) mojavelinux: @Deployment
(03:23:03 PM) ALR@Freenode: Yep.
(03:23:06 PM) ALR@Freenode: Config would be another
(03:23:10 PM) aslak: @RunWith / extends Arquillian
(03:23:25 PM) pmuir: ALR: let's call it a day in 37m time, and schedule another meeting for another day this week, same time?
(03:23:26 PM) aslak: hook more then api maybe
(03:23:34 PM) ALR@Freenode: pmuir: I like that
(03:23:45 PM) aslak: ok, we keep it 2 hours
(03:24:07 PM) pmuir: (not least as I need my tea and some phone calls)
(03:24:23 PM) mojavelinux: hehe
(03:24:47 PM) aslak: Open issue that involes @Deployment: https://jira.jboss.org/jira/browse/ARQ-30
(03:25:16 PM) ALR@Freenode: I'd say: out of scope for now
(03:25:29 PM) ALR@Freenode: Justification as feature we can live without for the time being.
(03:25:56 PM) aslak: ok
(03:26:01 PM) ALR@Freenode: I guess we haven't talked about release criteria for Alpha 1 yet
(03:26:07 PM) ALR@Freenode: I'd like to set the bar really, really low.
(03:26:21 PM) aslak: is this 'restricted' to alpha-1 ?
(03:26:31 PM) ALR@Freenode: If we support Embedded GFv3 and/or OpenEJB with manual deployments, I'd say that's a good target to ship
(03:26:33 PM) pmuir: yes, we can live without this in alpha 1
(03:26:39 PM) pmuir: but we need it for 1.90
(03:26:41 PM) mojavelinux: this might be out of scope, but personally I really don't like this in every test case: Archives.create("test.jar", JavaArchive.class)
(03:26:42 PM) pmuir: 1.0 even
(03:27:03 PM) mojavelinux: that seems so boilerplate for 80% of cases
(03:27:04 PM) aslak: pmuir, i agree.. right before the 2.0 release sounds good..
(03:27:20 PM) mojavelinux: I like the idea of injecting a default archive along the lines of the last comment in the issue
(03:27:22 PM) pmuir: mojavelinux: exactly
(03:27:34 PM) pmuir: but for alpha1 it's not important
(03:27:38 PM) ALR@Freenode: mojavelinux: Agree. With ARQ-30 we can do stuff like make an annotation API for archives.
(03:27:39 PM) mojavelinux: k
(03:27:44 PM) aslak: pmuir, mojavelinux, a default Archive of what?
(03:27:47 PM) ALR@Freenode: mojavelinux: Which could live in ShrinkWrap
(03:28:06 PM) ALR@Freenode: Like @Archive(@Classes({ClassA.class, ClassB.class}))
(03:28:10 PM) mojavelinux: @aslak it would be a JAR called "default.jar" or something
(03:28:21 PM) aslak: mojavelinux, what if i want to deploy a war?
(03:28:26 PM) aslak: or a rar
(03:28:40 PM) jganoff: Would be nice to have templates for deployments instead of always having to create a beans.xml
(03:28:41 PM) mojavelinux: you can set the extension using the fluent API, I would suppose
(03:28:45 PM) jganoff: e.g. for CDI deployments.
(03:28:47 PM) ALR@Freenode: mojavelinux: Behaviour in ShrinkWrap is actually different for WAR and RAR.
(03:28:48 PM) pmuir: ALR: i'm not sure we need that
(03:28:50 PM) mojavelinux: or annotated the injection point
(03:29:11 PM) ALR@Freenode: pmuir: Nor am I, really.
(03:29:14 PM) aslak: jganoff, https://jira.jboss.org/jira/browse/SHRINKWRAP-115
(03:29:16 PM) mojavelinux: @Web JavaArchive or something
(03:29:26 PM) pmuir: anyway, can we defer the design discussion for this until we need to do it :-p
(03:29:34 PM) aslak: hehe
(03:29:34 PM) mojavelinux: k
(03:29:37 PM) ALR@Freenode: Ew tongue.
(03:29:40 PM) pmuir: that is the reason I think we defer this, as we need time to design it right
(03:29:45 PM) jganoff: aslak: great, thanks!
(03:30:34 PM) aslak: ok.. then moving along down the call stack
(03:30:47 PM) aslak: we come to the arquillian runners on the client side
(03:31:12 PM) aslak: btw.. client side ws server/container side. describes where it is in use
(03:31:23 PM) aslak: http://community.jboss.org/wiki/ArquillianDesignOverview
(03:32:13 PM) ALR@Freenode: We talked a bit about this:
(03:32:30 PM) ALR@Freenode: Deployment should always be @BeforeClass/@AfterClass ?
(03:32:38 PM) aslak: ALR, no
(03:32:42 PM) ALR@Freenode: Ah cool.
(03:32:56 PM) ALR@Freenode: If we make it configurable to be @Before/@After that's awesome.
(03:33:03 PM) aslak: ALR, i'm sure you could up with some usecases if you really tried.. so i can give you that ..
(03:33:06 PM) ALR@Freenode: Helps users with their test layout
(03:33:24 PM) ALR@Freenode: aslak: Book Examples reveal all hidden cases
(03:33:49 PM) ALR@Freenode: Take us down the path.
(03:33:57 PM) aslak: but anyway.. that's how to works now
(03:34:14 PM) pmuir: yeah, I think allowing the deployment around a test method is another thing we should have but not necessarily for alpha 1
(03:34:30 PM) aslak: we need a configurable container controller, ForceRestart, RestartPrTest, NeverRestart etc
(03:34:40 PM) ALR@Freenode: Yup, just to be sure we don't limit ourselves in design, it's a feature
(03:34:43 PM) kenglxn: perhaps a bit off track, but test dependencies would be nice, like one test dependant on another, for integration tests
(03:34:43 PM) ALR@Freenode: (An easy one actually)
(03:34:59 PM) ALR@Freenode: kenglxn: I think that is an antipattern
(03:35:02 PM) aslak: kenglxn, between test cases or methods?
(03:35:16 PM) kenglxn: i think more in asynch world
(03:35:21 PM) lightguard_jp: kenglxn: That's the deal of the test framework, I don't think we should muck with that.
(03:35:33 PM) pmuir: kenglxn: lightguard_jp right, testng already supports this
(03:35:39 PM) ALR@Freenode: The idea is that tests should be written autonomously.
(03:35:53 PM) ALR@Freenode: And test state should be reset to between invocations.
(03:36:20 PM) pmuir: ALR: :-)
(03:36:25 PM) aslak: kenglxn, yea, testng has depend on method / groups etc.. does all the sorting before it reaches arquillian
(03:36:46 PM) aslak: we tho have this which is related: https://jira.jboss.org/jira/browse/ARQ-55
(03:37:32 PM) kenglxn: yea, that's it
(03:38:38 PM) aslak: ok, next in the stack is the packaging of the deployment
(03:38:42 PM) mojavelinux: the test frameworks already give you multiple ways to setup and teardown, which is all the dependence you should have
(03:38:54 PM) mojavelinux: anything else I think should be solved by multiple "requests" in the same method
(03:39:30 PM) mojavelinux: I'll get to that second part later on
(03:39:57 PM) aslak: I'm proposing 3 spis to handle this.. DeploymentAppender, DeploymentEnricher and DeploymentPackager
(03:40:00 PM) kenglxn: i'm thinking in lines of testing integration between systems, where there is no point in testing methody if methodx has failed, where the backend may be down for a longer period of time, but this may be better discussed later time
(03:40:02 PM) mojavelinux: @aslak here is where we need to be cognizant of whether we should be appending to the archive or not
(03:40:20 PM) pmuir: kenglxn: i think you can still use testng depends on stuff here
(03:40:26 PM) kenglxn: ok
(03:40:34 PM) pmuir: aslak: can you talk us through the proposed spis
(03:40:35 PM) pmuir: ?
(03:40:55 PM) aslak: pmuir, yes.. getting there
(03:41:13 PM) aslak: https://jira.jboss.org/jira/browse/ARQ-25
(03:42:04 PM) aslak: The requirement is.. we should support any type of container supporting any type of deployment. in some contianers we need to add some extras to the archives to function
(03:42:36 PM) aslak: so, DeploymentAppender: http://anonsvn.jboss.org/repos/common/arquillian/trunk/spi/src/main/java/org/jboss/arquillian/spi/DeploymentAppender.java
(03:43:02 PM) aslak: this is a dynamically loadded spi, the idea is that anyone can add to the deployment
(03:44:08 PM) aslak: examples of use, Arquillian JUnit adds junit pluss some classes(test runner), Arquillian Core adds core, Protocol Servlets add a servlet, test enrichers
(03:45:42 PM) mojavelinux: I believe that @ALR had some concerns here about modifying the archive and affecting the behavior of the code (JNDI module names for one)
(03:46:01 PM) ALR@Freenode: Mhmm
(03:46:04 PM) aslak: and to overcome that a container/technology needs something special added to the single deploymentappender artifacts(ie, cdi needs to add a beans.xml to the protocol servlet war), we have the DeploymentEnricher
(03:46:15 PM) aslak: ALR, mojavelinux; getting to that
(03:47:11 PM) aslak: DeploymentEnricher is a 'made' up spi as of now.. but something like void enrich(List<Archive<?>> deploymentParts)
(03:47:57 PM) aslak: these two spis are controlled by each module. next is the DeploymentPakcager spi
(03:48:02 PM) ALR@Freenode: I like the design. Can we consider renames maybe?
(03:48:41 PM) aslak: it has the responsibility of adding this up into a archive that the repective container can support..
(03:48:50 PM) ALR@Freenode: Sorry keep going
(03:49:31 PM) aslak: so this should be controlled by the contianer. in Andrews OpenEJB lay of my deployment case.. OpenEJB has it's own DeploymentPackager that ignores the DeploymentAppenders/Enrichers..
(03:50:56 PM) aslak: that in my mind should cover our needs for packaging etc.. with one problem, but i'll get to that later
(03:51:20 PM) aslak: ALR, renames, sure.. got any good names?
(03:52:48 PM) mojavelinux: DeploymentPackager is currently DeploymentAppenderArchiveGenerator (hardcoded impl)
(03:52:54 PM) aslak: yes
(03:52:55 PM) mojavelinux: fyi
(03:53:07 PM) aslak: mojavelinux, thanks. forgot to copy that in there
(03:53:18 PM) ALR@Freenode: aslak: Not yet. Gotta understand enrichers better first
(03:53:26 PM) aslak: http://anonsvn.jboss.org/repos/common/arquillian/trunk/impl-base/src/main/java/org/jboss/arquillian/impl/DeploymentAppenderArchiveGenerator.java
(03:53:38 PM) pmuir: I also like the overall design - it seems to cover the use cases I know of
(03:53:46 PM) ALR@Freenode: Yeah, it's good.
(03:53:55 PM) mojavelinux: enricher is what provides injection into the test case, amongst other things, right?
(03:54:00 PM) ALR@Freenode: I think the main goal now is to jump off it and make it all configurable.
(03:54:04 PM) mojavelinux: or is that TestEnricher
(03:54:10 PM) mojavelinux: not to be confused with DeploymentEnricher
(03:54:10 PM) aslak: ALR, Enrichers.. well.. due to a stupid miss conceptunal design between cdi and ee6, we need this..
(03:54:33 PM) pmuir: ok, I suggest we finish up now
(03:54:50 PM) pmuir: and have configuration as a first topic for the next meeting
(03:54:52 PM) aslak: mojavelinux, ALR, well.. that depends.. andrew you mean DeploymentEnrichers or TestEnrichers ?
(03:55:01 PM) pmuir: can everyone do the same timeslot tomorrow?
(03:55:22 PM) mojavelinux: I'm going to be in the air (weather permitting)
(03:55:28 PM) aslak: pmuir, can we discuss configuration before we know how it does what it does?
(03:55:29 PM) mojavelinux: Wedneday would be my first available
(03:55:30 PM) ALR@Freenode: pmuir: No, I'm going to see Dan.
(03:55:31 PM) lightguard_jp: Possibly, but I'm mostly lurking
(03:55:52 PM) pmuir: I can't do Weds
(03:55:58 PM) pmuir: how about thursday?
(03:56:05 PM) mojavelinux: thursday works too
(03:56:11 PM) mojavelinux: really anyting but tomorrow
(03:56:20 PM) pmuir: aslak: what do you mean?
(03:56:44 PM) ALR@Freenode: Thurs OK here
(03:56:45 PM) jganoff left the room (quit: Quit: Leaving).
(03:56:46 PM) mojavelinux: before we touch configuration, can you explain one more time what DeploymentEnrichers does?
(03:56:50 PM) pmuir: I mean configuration in general, not just of deployment enricher
(03:56:56 PM) mojavelinux: or what it lines up with right now in the code
(03:57:04 PM) pmuir: it's like Process* in CDI
(03:57:08 PM) aslak: pmuir, i mean, should we continnue through the spi before we discuss how to configure it ?
(03:57:11 PM) pmuir: as I understand it
(03:57:20 PM) pmuir: or not quite
(03:57:22 PM) pmuir: actually
(03:57:23 PM) pmuir: oops
(03:57:30 PM) pmuir: aslak: ok, yes, we should do that first :-)
(03:57:33 PM) aslak: mojavelinux, it's a Deployment ointerceptor ish
(03:57:46 PM) pmuir: yup
(03:57:57 PM) aslak: mojavelinux, with the intent of side effects hehe
(03:57:57 PM) mojavelinux: ah
(03:58:32 PM) aslak: anyone works for me btw
(03:58:33 PM) pmuir: aslak: have you looked at Process* in CDI?
(03:58:37 PM) aslak: any day even
(03:58:41 PM) pmuir: ok, it's thursday then :-)
(03:59:04 PM) ALR@Freenode: We'll pick up here then?
(03:59:07 PM) lightguard_jp: Will this meeting be put up on the wiki somewhere?
(03:59:11 PM) pmuir: ok, I'm dropping off, catch all tomorrow
(03:59:12 PM) ALR@Freenode: Yes, I'll post it now.
(02:02:20 PM) ALR@Freenode: I think so. 2 minutes grace is about right.
(02:02:24 PM) aslak: mojavelinux, ok, you warm up the crowd with some jokes ?
(02:02:37 PM) mojavelinux: Please see this page for agenda: http://community.jboss.org/thread/147980
(02:03:38 PM) mojavelinux: What, I don't entertain you all enough on Twitter?
(02:03:40 PM) mojavelinux: Hehehe
(02:03:47 PM) aslak: hehe
(02:03:48 PM) jganoff: ^^
(02:03:55 PM) aslak: everyone had a look at the spi/apis ?
(02:04:09 PM) aslak: http://anonsvn.jboss.org/repos/common/arquillian/trunk/spi/src/main/java/org/jboss/arquillian/spi/
(02:04:25 PM) aslak: http://anonsvn.jboss.org/repos/common/arquillian/trunk/api/src/main/java/org/jboss/arquillian/api/
(02:04:43 PM) mojavelinux: That made me remember, we need to add a JavaDoc run to the build so that it's easier to browse them
(02:05:06 PM) ALR@Freenode: Is that covered in JIRA yet?
(02:05:14 PM) ALR@Freenode: I'll play secretary for today.
(02:05:45 PM) aslak: mojavelinux, your talking about a combines javadoc as part of ahte main build?
(02:05:49 PM) aslak: combined
(02:07:40 PM) mojavelinux: yeah, just so that they are created when the reference guide is created
(02:07:55 PM) kenglxn [~ken@c5E90BF51.dhcp.bluecom.no] entered the room.
(02:08:23 PM) ALR@Freenode: Do you guys mind if we start with JIRA "components" configuration?
(02:08:46 PM) pmuir [~pmuir@redhat/jboss/pmuir] entered the room.
(02:09:27 PM) aslak: ALR, you wanna go straight to jira ? no spi/api walk through ?
(02:09:42 PM) ALR@Freenode: aslak: Oh, that's the bread and butter!
(02:09:45 PM) pmuir: hi guys, sorry i'm a bit late
(02:09:47 PM) ALR@Freenode: aslak: You're the main event.
(02:09:54 PM) mojavelinux: Sure, I was just able to suggest that we select a starting topic...actually, if you want to estalish an order
(02:09:54 PM) aslak: heya pmuir
(02:10:04 PM) mojavelinux: @pmuir, the starting act I heard was bad anyway
(02:10:32 PM) ALR@Freenode: aslak: I noticed we'll be making some JIRAs today though, and the components in there don't match the project layout (should they?)
(02:10:43 PM) ALR@Freenode: Typically I equate "component" in JIRA with "module" in Maven
(02:11:08 PM) lightguard_jp: Yeah, makes things easier to see where the issues are in relation to the project.
(02:11:20 PM) aslak: ALR, ohh, those component.. i thought you meant the 'core' configuration jira issue..
(02:11:51 PM) ALR@Freenode: Ah no. Just administration stuff.
(02:12:04 PM) aslak: ALR, sure
(02:12:05 PM) pmuir: IMO the best way to organise components in JIRA is along logical lines, it makes it easier to organise the issues
(02:12:28 PM) pmuir: I would avoid categorizations like "Core" as they don't really mean much
(02:12:36 PM) mojavelinux: +1
(02:12:52 PM) ALR@Freenode: OK, a bit of a different setup you guys do then
(02:13:26 PM) ALR@Freenode: I track modules (which should also really be logical, when you think about it) so that if they ever go to their own release cycle I can move issues around easier.
(02:13:30 PM) mojavelinux: it would be somewhat of a hybrid
(02:14:05 PM) aslak: the way it is now, we ahve core that is 'Arquillian, TestNG and Junit which are the starting points, and Jobss Containers(a combinations of all jboss containers/versions)(should add GlassFish container etc as well)
(02:14:09 PM) mojavelinux: so TestNG integration, JUnit integration, Containers, Enricher, Protocol
(02:14:23 PM) ALR@Freenode: OK, I've made "Build Configuration"
(02:14:30 PM) mojavelinux: yes, if we break down TestNG and JUnit, then we should break down each container as well
(02:14:37 PM) pmuir: I would avoid independent release cycles for modules, it's a mess with maven
(02:14:41 PM) mojavelinux: easier to assign GlassFish issues to one set of people
(02:14:51 PM) pmuir: I suppose my point is just that a component might be finer grained than a module
(02:14:53 PM) ALR@Freenode: pmuir: Yeah I only do that when they graduate out of modules and into projects.
(02:15:03 PM) lightguard_jp: pmuir: +1 to making maven releases easier
(02:15:33 PM) pmuir: yup, TBH if we want graduate a module to a project, it makes sense to make a new JIRA project for it (something I am also guilty of not doing)
(02:15:46 PM) ALR@Freenode: pmuir: Ha, in EJB3 we'd have 50 projects.
(02:15:48 PM) pmuir: anyway, I like Dan's setup
(02:15:54 PM) ALR@Freenode: Yep.
(02:16:04 PM) ALR@Freenode: We can proceed I think.
(02:16:07 PM) mojavelinux: We could consider making containers a project in JIRA
(02:16:19 PM) ALR@Freenode: Would we like to start w/ aslak introducing the API, then SPI?
(02:18:27 PM) pmuir: Good idea
(02:18:43 PM) pmuir: or perhaps we should start with a 10 000 foot view
(02:18:46 PM) pmuir: if we have one
(02:19:04 PM) lightguard_jp: I say go for the global view, then dive down
(02:19:05 PM) ALR@Freenode: The end result of a 10000 foot view is always: splat.
(02:19:09 PM) ALR@Freenode:
(02:19:13 PM) ALR@Freenode: Dig it.
(02:19:15 PM) mojavelinux: we have worked to establish a mission statement in the reference guide and on this page
(02:19:20 PM) ALR@Freenode: mojavelinux: Take it away
(02:19:35 PM) mojavelinux: http://community.jboss.org/docs/DOC-14376?uniqueTitle=false
(02:19:54 PM) ALR@Freenode: Already I have a question
(02:20:00 PM) ALR@Freenode: Which has been on the forums a bit:
(02:20:03 PM) ALR@Freenode: "Arquillian provides a easy mechanism to test your application code inside a container"
(02:20:29 PM) mojavelinux: that mission statement isn't in stone yet, btw
(02:20:40 PM) aslak: .. trouble maker..
(02:20:50 PM) ALR@Freenode: I've got a few use cases that don't require (and shouldn't have actually) the test running in the container.
(02:21:16 PM) mojavelinux: it comes down to how you define the term "container" I think
(02:21:18 PM) mojavelinux: can you cite the case
(02:21:24 PM) aslak: ALR, this is where run locally' mode comes in.. Arquillian dpeloyes, but does not execute the testcase remote
(02:21:57 PM) aslak: ALR, need a jira on this btw..
(02:22:12 PM) ALR@Freenode: The case is: I have a @Deployment, and altering it causes the container to err out.
(02:22:12 PM) mojavelinux: as I defined it, the container can be a bootstrapped framework environment, such as Weld SE
(02:22:32 PM) ALR@Freenode: mojavelinux: Sure. But there's also Embedded containers.
(02:22:34 PM) mojavelinux: to Arquillian, it is still "deploying", in this case it is just setting up things locally
(02:22:38 PM) ALR@Freenode: Which are real containers.
(02:22:47 PM) ALR@Freenode: And the test case should be executed outside of the deployment.
(02:22:48 PM) mojavelinux: yes, I agree: see
(02:23:10 PM) aslak: ALR, that's a different issue then not running it in the container.. you don't want arquillian to do the touch the packaging
(02:23:10 PM) ALR@Freenode: Some talks aslak and I had earlier showed we may not have been in full agreement.
(02:23:32 PM) mojavelinux:
(02:23:34 PM) ALR@Freenode: aslak: I also want the test outside the container.
(02:23:40 PM) pmuir: ALR: yes, you need to deploy the artifact, and then execute the test in the local VM, somehow interacting with the deployed artifact (e.g. EJB 3 remote, htmlunit/jsf, WS), and then undeploy it when the test ends
(02:24:01 PM) mojavelinux: yes
(02:24:07 PM) ALR@Freenode: Yep, it's the simplest case I think.
(02:24:10 PM) aslak: pmuir, and in that case we don't have to add stuff to the deployment either
(02:24:13 PM) ALR@Freenode: And maybe the most frequent.
(02:24:15 PM) mojavelinux: @ALR, your point about not touching the packaging in cases was a good one
(02:24:16 PM) pmuir: ok, so what ALR is saying is that there are actually 3 levels:
(02:24:23 PM) pmuir: 1) remote test inside the container
(02:24:32 PM) pmuir: 2) local test, against a remote container
(02:24:39 PM) pmuir: 3) local test, against a local container
(02:24:51 PM) pmuir: only for (1) does the test case need packaging inside the artifact
(02:24:54 PM) ALR@Freenode: Right.
(02:24:55 PM) aslak: what is the diff between 2/3?
(02:25:07 PM) ALR@Freenode: So the only thing I think we need to clarify is our use of "local" and "remote".
(02:25:09 PM) mojavelinux: communication and deployment
(02:25:11 PM) pmuir: (when I say test case, I mean test class + supporting classes, libraries etc.)
(02:25:15 PM) ALR@Freenode: Proximity to JVM and to physical machine.
(02:25:34 PM) mojavelinux: keep in mind that there is a separate classification, which is spec compliance
(02:25:42 PM) pmuir: aslak: from a packaging perspective, none, but from a conceptual perspective, some
(02:25:50 PM) aslak: pmuir, right
(02:25:52 PM) mojavelinux: so container can be Java EE, servlet or bean
(02:26:32 PM) mojavelinux: @pmuir, good way of saying it
(02:26:34 PM) aslak: mojavelinux, container is 'anything' that supports a type of deployment
(02:27:02 PM) ALR@Freenode: Weld doesn't support deployments?
(02:27:09 PM) aslak: ALR, ohh?
(02:27:26 PM) ALR@Freenode: Weld ==Framework, not container.
(02:27:30 PM) mojavelinux: yes, you are deploying the beans....not a packaged deployment, but certainly a deployment
(02:27:42 PM) jganoff: WeldSE Container?
(02:27:45 PM) mojavelinux: or by deployment do we imply package
(02:28:00 PM) ALR@Freenode: jganoff: Yep, SE.
(02:28:09 PM) aslak: deployment we can say anything that lets you 'split' out from app claspath?
(02:28:36 PM) aslak: no..
(02:29:05 PM) pmuir: essentially I agree, you can't "deploy" to Weld in Java EE or Servlet
(02:29:16 PM) pmuir: but you can in Java SE OR a mock EE/Servlet environment
(02:29:17 PM) mojavelinux: deployment is really the process of handing off the code to be tested
(02:29:24 PM) aslak: deployment, something that lets you control what the container can see/use ?
(02:29:36 PM) ALR@Freenode: I might say:
(02:30:01 PM) mojavelinux: @aslak I see what you are saying about "splitting out" the classpath
(02:30:02 PM) ALR@Freenode: Deployment: the process of handing off an artifact to an environment; the test then depends upon the environment to make state changes
(02:30:28 PM) aslak: environment/container
(02:30:46 PM) mojavelinux: @ALR so the question is, can "artifact" be registering beans w/ Weld SE
(02:30:56 PM) mojavelinux: does that fit?
(02:31:05 PM) ALR@Freenode: I don't know
(02:31:13 PM) ALR@Freenode: Aren't you on the Weld team?
(02:31:21 PM) aslak: mojavelinux, it has to.. it does to day. if not, redefine..
(02:31:45 PM) ALR@Freenode: I'm wondering what the difference between "framework" and "container" modes we have are, really.
(02:31:50 PM) mojavelinux: I'm asking if it fits conceptually; I think it does
(02:31:51 PM) dhinojosa [~dhinojosa@c-68-35-42-36.hsd1.nm.comcast.net] entered the room.
(02:31:56 PM) ALR@Freenode: And how a framework is different from an Embedded container.
(02:31:57 PM) mojavelinux: ShrinkWrap is creating a bean archive
(02:31:58 PM) pmuir: do we have a difference?
(02:32:04 PM) ALR@Freenode: There's lifeycle, there's deployment.
(02:32:20 PM) mojavelinux: So I think this definition works:
(02:32:26 PM) mojavelinux: Deployment: the process of handing off an artifact to an environment; the test then depends upon the environment to make state changes
(02:32:51 PM) mojavelinux: then the question becomes, when does Arquillian enrich that archive?
(02:33:05 PM) mojavelinux: that would be all but #2
(02:33:10 PM) aslak: mojavelinux, that's a q for later..
(02:33:12 PM) ALR@Freenode: "enrich" and "archive"?
(02:33:19 PM) mojavelinux: enrich an archive
(02:33:24 PM) pmuir: right, let's stick to the mission statement for now
(02:33:28 PM) mojavelinux: which was your objection @ALR to some cases
(02:33:45 PM) mojavelinux: when you didn't want Arquillian getting its hands in the ShrinkWrap archive you created
(02:33:49 PM) ALR@Freenode: mojavelinux: Ah true.
(02:34:27 PM) aslak: mojavelinux, ALR.. there is a proposed fix for this coming in the spi walk through..
(02:34:27 PM) ALR@Freenode: So anyway I guess I bring this up to clarify that I'd really like to nail down these "run modes"/
(02:34:44 PM) pmuir: yeah
(02:34:58 PM) mojavelinux: I think we can address that in the mission statement but not being so vague
(02:35:03 PM) mojavelinux: how about we say....
(02:35:04 PM) pmuir: Do we want to include this as a second paragraph to the mission statement?
(02:36:26 PM) mojavelinux: to test the code from within the container or to test against the code deployed to a container
(02:36:48 PM) mojavelinux: a subtle difference, but it grabs all bullet points above
(02:36:49 PM) mojavelinux: assuming...
(02:37:00 PM) pmuir: mojavelinux: IO like that
(02:37:03 PM) mojavelinux: that container can be Weld SE too...and that deployment is handing those beans to Weld SE
(02:37:18 PM) pmuir: I also wonder if we want to enumerate examples of "containers" to show what we mean
(02:37:28 PM) mojavelinux: @pmuir yes
(02:37:30 PM) mojavelinux: for sure
(02:37:45 PM) mojavelinux: By container we mean...
(02:37:52 PM) mojavelinux: and I'll expand
(02:38:16 PM) aslak: Jboss AS, GlassFish, Weld SE, Spring, Guice, OpenEJB, Resin, MC, Jetty
(02:38:41 PM) lightguard_jp: tomcat
(02:38:49 PM) mojavelinux: yes and no
(02:38:53 PM) mojavelinux: yes I can cite specific examples
(02:38:56 PM) pmuir: ... containers (for example a Java EE container such as JBoss AS, a servlet container such as Tomcat, an embeddable container such as <whatever it is called this month> or a XXX)
(02:38:56 PM) aslak: Tomcat, GlassFish EMbedded, JBoss Embedded
(02:39:07 PM) mojavelinux: no, I mean I'll expand to the types of containers one can have
(02:39:09 PM) mojavelinux: not vendors
(02:39:28 PM) aslak: mojavelinux, sky's the limit..
(02:39:40 PM) pmuir: and XXX is where I fall down - I want to have a word for what the Weld SE container is - it doesn't deal with Jar based deployments so...
(02:39:55 PM) pmuir: what do Guice call themselves?
(02:40:03 PM) aslak: ioc framework ?
(02:40:03 PM) mojavelinux: remote, standalone container; local, managed container; embedded container; custom bean environment (still dont' have a good word for Weld SE)
(02:40:20 PM) ALR@Freenode: I think the word is "Framework".
(02:40:31 PM) aslak: Guice (pronounced 'juice') is a lightweight dependency injection framework
(02:40:32 PM) ALR@Freenode: Except for us it has no different semantics than "Embedded Container".
(02:40:42 PM) mojavelinux: emulated container?
(02:40:52 PM) pmuir: ALR: framework is *very* generic
(02:40:56 PM) ALR@Freenode: So it looks like they fit in the same category
(02:41:05 PM) aslak: pmuir, and container is not ? hehe
(02:41:06 PM) pmuir: yeah
(02:41:08 PM) ALR@Freenode: pmuir: So are we, though.
(02:41:08 PM) mojavelinux: in some sense, CDI alone (maybe w/ EL and BV thrown in there) is custom environment, simulated
(02:41:12 PM) mojavelinux: what about simulated
(02:41:19 PM) ALR@Freenode: What are we simulating?
(02:41:38 PM) pmuir: yeah, let's call it an Embedded Container, but say explicitly what we mean ;-)
(02:41:39 PM) mojavelinux: simulating the environment where you will be deploying...a partial simulation obviously
(02:42:09 PM) aslak: mojavelinux, isn't that part of our mission statement not to be.. we are the real thing, not a mock of it
(02:42:18 PM) mojavelinux: @pmuir okay, so we can say embedded container (partial, like CDI) or embedded container (full Java EE)
(02:43:06 PM) pmuir: mojavelinux: yeah, I think partial is quite good
(02:43:09 PM) mojavelinux: @aslak true, Weld SE can be considered a true embedded container, just not of the Java EE variety
(02:43:24 PM) mojavelinux: so I can just put weave partial in there to suggest it is partial of the Java EE spec
(02:43:29 PM) mojavelinux: servlet container is also partial
(02:43:53 PM) kenglxn: +1
(02:44:15 PM) mojavelinux: that makes a lot of sense...liking that
(02:44:16 PM) kenglxn: partial / full
(02:44:28 PM) aslak: mojavelinux, it feels unfair to me that only use cdi to call it a partial container
(02:44:28 PM) ALR@Freenode: If "partial" describes JEE, I think we should stay away from it.
(02:44:35 PM) ALR@Freenode: We're a deployment/lifecycle mechanism.
(02:44:43 PM) ALR@Freenode: What the container does for you is kinda out of scope.
(02:44:55 PM) mojavelinux: no, "full" is Java EE
(02:45:04 PM) ALR@Freenode: We could write a Java Logging container which "deployed" something to a log.
(02:45:05 PM) mojavelinux: partial is CDI alone or servlet alone (or w/ CDI)
(02:45:19 PM) aslak: mojavelinux, what is spring / guice then? partial ee ? hehe
(02:45:23 PM) pmuir: the reason Weld is partial is that it doesn't handle a real deployment like a JAR
(02:45:25 PM) pmuir: IMO
(02:45:26 PM) ALR@Freenode: I mean, "partial" is in respect to JEEE.
(02:45:51 PM) ALR@Freenode: So I guess I'm asking why we make explicit the relation with JEE.
(02:45:54 PM) pmuir: it essentially "enriches" the plain JVM
(02:45:59 PM) aslak: ALR, i agree
(02:46:00 PM) ALR@Freenode: When we are really more abstract.
(02:46:08 PM) ALR@Freenode: Like we run in SE alone.
(02:46:24 PM) aslak: weld se is capable of standing on it's own feet.. why say it's a partial something else
(02:46:40 PM) pmuir: well why not just call them all embeddable containers and explain through reference to examples
(02:46:42 PM) ALR@Freenode: aslak: Yep, that's what I'm very poorly trying to get across.
(02:46:50 PM) ALR@Freenode: pmuir: Yep.
(02:47:13 PM) dhinojosa: Hey everyone.
(02:47:17 PM) ALR@Freenode: Like if you put an EJB JAR into a Jetty container, that's not our problem
(02:47:23 PM) aslak: we've started this here:
(02:47:28 PM) mojavelinux: hmmm
(02:47:41 PM) aslak: hi dhinojosa
(02:47:53 PM) dhinojosa: Been lurking, but is WELD something that can have host?
(02:47:57 PM) mojavelinux: I guess I've been holding on to this "promise" of giving them the real Java EE deal
(02:48:03 PM) dhinojosa: or can exist on it's own
(02:48:13 PM) dhinojosa: is that what was trying to be conveyed?
(02:48:15 PM) mojavelinux: and trying to keep it clear when we are only partially delivering on that
(02:48:25 PM) pmuir: dhinojosa: what does "have host" mean?
(02:48:37 PM) mojavelinux: but there is one other distinction
(02:48:41 PM) mojavelinux: you see
(02:48:46 PM) aslak: mojavelinux, i think we should state that ee is only partial what we support..
(02:48:54 PM) dhinojosa: just trying to interpret what the words you're trying to complete.
(02:49:01 PM) mojavelinux: embedded GlassFish is really no different than a managed version of GlassFish
(02:49:03 PM) dhinojosa: so I can better understand
(02:49:10 PM) mojavelinux: all you are doing is changing how start and stop work
(02:49:22 PM) mojavelinux: you are still deploying "over the wire", correct?
(02:49:28 PM) mojavelinux: and testing through HTTP
(02:49:30 PM) kenglxn: testing for any environment, custom or full/partial EE
(02:49:40 PM) aslak: mojavelinux, not deploying over the wire, but testing via http yes
(02:49:55 PM) ALR@Freenode: For Embedded GlassFish I think that should change.
(02:50:03 PM) pmuir: well not really, in embeddable Blah, you would probably want to test directly
(02:50:05 PM) pmuir: not via http
(02:50:08 PM) ALR@Freenode: Right
(02:50:09 PM) mojavelinux: so to put Embedded GlassFish and Weld SE in the same classification just seems to me like really vague
(02:50:14 PM) ALR@Freenode: (Unless you're testing a Servlet)
(02:50:15 PM) aslak: mojavelinux, direct shrinwrap extension to handle glassfishs readablearchive
(02:50:23 PM) pmuir: yeah
(02:50:34 PM) pmuir: I think we have two types of container - remote and embeddable
(02:50:38 PM) mojavelinux: but how do you get the tests to run inside the container
(02:50:43 PM) mojavelinux: you have to work through the servlet, don't you?
(02:50:46 PM) pmuir: with emedded?
(02:50:47 PM) aslak: ALR, sure, serlvet is only one of multiple possible container protocols, jms, rmi etc
(02:50:48 PM) mojavelinux: the Arquillian servlet
(02:50:57 PM) aslak: jmx i mean..
(02:51:03 PM) mojavelinux: (right, alternatives exist too)
(02:51:40 PM) mojavelinux: so embedded glassfish is not really embedded at all
(02:51:48 PM) mojavelinux: it is only embedded in that you don't have to go download it
(02:51:57 PM) mojavelinux: same as JBoss Embedded AS
(02:52:02 PM) aslak: it just as embedded as weld se ?
(02:52:11 PM) mojavelinux: Weld SE is truly embedded
(02:52:14 PM) aslak: it's running off the same classpath
(02:52:16 PM) pmuir: no embedded glassfish runs in the same JVM as junit/testng
(02:52:21 PM) mojavelinux: because we are actually starting the environment and putting beans in there manually
(02:52:35 PM) mojavelinux: yes, it runs in the same JVM
(02:52:41 PM) ALR@Freenode: "Embedded" is a term I use with respect to JVM.
(02:52:57 PM) mojavelinux: hmmm
(02:52:58 PM) ALR@Freenode: So if they share a process, I've been calling that "Embedded".
(02:53:02 PM) pmuir: right, that is what Embedded is generally taken to mean
(02:53:11 PM) aslak: my understand as well
(02:53:46 PM) pmuir: and you would run the test the same way in Embedded JBoss AS as in Weld SE
(02:53:47 PM) aslak: using Jboss ServerManagement api, even thos the api is run 'embedded' the container is started remote
(02:54:06 PM) mojavelinux: okay, so this comes down to compliance
(02:54:08 PM) ALR@Freenode: aslak: I wouldn't say that.
(02:54:17 PM) pmuir: mojavelinux: compliance?
(02:54:18 PM) mojavelinux: they are both embedded, but have a different level of compliance
(02:54:20 PM) pmuir: with what?
(02:54:25 PM) pmuir: oic
(02:54:27 PM) mojavelinux: yes, Weld SE can provide all of CDI
(02:54:35 PM) ***ALR@Freenode still lost on "compliance"
(02:54:37 PM) mojavelinux: but embedded Glassfish can give you datasources, etc
(02:54:37 PM) pmuir: yes, one is spec'd, one isn;t
(02:54:45 PM) mojavelinux: what I'm saying is
(02:54:46 PM) aslak: ALR, does it go directly on Main ?
(02:54:48 PM) mojavelinux: if you wanted to group your tests
(02:55:01 PM) pmuir: well Weld SE only provides CDI services with no EE services
(02:55:09 PM) mojavelinux: you would say "this test requires Java EE compliance because it depends on managed resources that are going to be there in a real container"
(02:55:16 PM) mojavelinux: well, hopefully just a word for that
(02:55:23 PM) pmuir: whilst Embedded JBoss provides all services offered by Java EE
(02:55:25 PM) mojavelinux: then you might say that this test can be run on anything that provides CDI
(02:55:36 PM) pmuir: I think what they provide is fairly obvious from their name
(02:55:47 PM) mojavelinux: right
(02:55:50 PM) mojavelinux: I get it now
(02:55:56 PM) mojavelinux: embedded means same JVM
(02:56:11 PM) mojavelinux: then from there, you can think about what you are actually running on to group your tests appropariately
(02:56:14 PM) pmuir: yes
(02:56:19 PM) mojavelinux: woot
(02:56:21 PM) pmuir: they are orthogonal concerns really
(02:56:29 PM) ALR@Freenode: Yep.
(02:56:33 PM) lightguard_jp: Well all on the same page with wording now? I think we've digressed a bit from the outline
(02:56:38 PM) pmuir: embedded vs remote is about how you launch a test / where it runs
(02:56:47 PM) ALR@Freenode: Yep.
(02:56:56 PM) mojavelinux: got it
(02:56:57 PM) ALR@Freenode: So when we talk about physical locality, what language can we use?
(02:57:08 PM) pmuir: whilst capababilities is about what services the container offers
(02:57:13 PM) ALR@Freenode: "local and remote" to me, in EJB-land, are @Local and @Remote, by JVM
(02:57:20 PM) pmuir: (btw capabilities is a good word :-)
(02:57:30 PM) mojavelinux: capabilities is a much better word than compliance
(02:57:32 PM) mojavelinux: good call
(02:57:33 PM) pmuir: ALR: I prefer remote and embedded
(02:57:52 PM) ALR@Freenode: pmuir: "Remote" there meaning "another JVM"?
(02:58:04 PM) mojavelinux: remote and embedded work for me
(02:58:16 PM) pmuir: ALR: yes
(02:58:24 PM) mojavelinux: btw, just because Arquillian starts the container, doesn't mean that it isn't remote....I think you can have a remote, managed container
(02:58:30 PM) aslak: ok, we skip local then(remote with life cycle control) ?
(02:58:41 PM) ALR@Freenode: pmuir: Me too. aslak has some cases where we need to distinguish physical location
(02:58:48 PM) ALR@Freenode: (Due to unshared filesystem)
(02:58:49 PM) mojavelinux: the "managed" part just means "please start that container over there for me to save me the trouble"
(02:59:09 PM) mojavelinux: technically, you could start a container even on a different machine
(02:59:15 PM) ALR@Freenode: Though I think we should punt on this "starting physically remote" servers feature for the time being.
(02:59:18 PM) pmuir: mojavelinux: yes, that is a good use
(02:59:32 PM) pmuir: yes, physically remote is something for 1.1 IMO
(02:59:36 PM) mojavelinux: @ALR yeah, we don't need to try it now
(02:59:38 PM) ALR@Freenode: Like we could launch a few great alphas without it.
(02:59:40 PM) ALR@Freenode: OK cool.
(02:59:53 PM) aslak: hehe funny thing is that that's the only thing tha tworks..
(03:00:10 PM) ALR@Freenode: aslak: Hehe, implementation detail we'll make it all work.
(03:00:19 PM) aslak: hehe
(03:00:35 PM) mojavelinux: so just to sum up...hopefully not to go off track
(03:00:39 PM) mojavelinux: we have remote and embedded containers
(03:00:52 PM) mojavelinux: embedded containers are in the same JVM and are always managed (they have to be started/stopped)
(03:00:54 PM) dhinojosa left the room (quit: Quit: Java user signed off).
(03:01:21 PM) mojavelinux: remote containers which are in a separate JVM and may be managed, or Arquillian may just "bind" to them if they are assumed to be already running
(03:01:55 PM) mojavelinux: any container can be further classified by it's capabilities; don't assume that all embedded containers are equal in this regard
(03:02:19 PM) ALR@Freenode: mojavelinux: Ye.
(03:02:20 PM) ALR@Freenode: *es
(03:02:27 PM) ALR@Freenode: Darn *Yes
(03:02:51 PM) ALR@Freenode: mojavelinux: So long as we don't do any upfront validation to try and restrict users from deploying stuff into containers that don't support it.
(03:02:57 PM) ALR@Freenode: (I don't like trying to be too smart).
(03:03:00 PM) mojavelinux: and finally
(03:03:25 PM) mojavelinux: we can either test code from within the container or test code that is deployed to the container
(03:03:34 PM) aslak: ALR, agree.. if i want to deploy cdi to jboss 5 i should be allowed to.. (i just might have managed to get it to work.. )
(03:03:46 PM) pmuir: mojavelinux: that last sentence is confusing
(03:04:01 PM) ALR@Freenode: Yep. The command line won't stop me from copying an MP3 into JBossAS.
(03:04:03 PM) mojavelinux: @pmuir I'll find a way to bring out the difference
(03:04:11 PM) kenglxn: alr: +1 let the container throw the error if there is one
(03:04:17 PM) aslak: ALR, with dna that makes sense even.. hehe
(03:04:21 PM) mojavelinux: Arquillian is not in the business of validating what you are trying to run; that is for you to control via test groups
(03:04:29 PM) ALR@Freenode: Beautiful.
(03:04:33 PM) mojavelinux: what Arquillian needs to be good at...
(03:04:54 PM) mojavelinux: is passing back exceptions, whether deployment exceptions, CDI validation exceptions or regular broken code exceptions
(03:05:13 PM) ALR@Freenode: == don't swallow Exceptions
(03:05:22 PM) pmuir: it should be "the test case can either run inside the deployment, or connect to the deployment"
(03:05:31 PM) pmuir: that's not right still
(03:05:37 PM) aslak: mojavelinux, i'll make sure it blows up completely..
(03:05:41 PM) ALR@Freenode: Yeah, the test may not do anything with the deployment.
(03:05:49 PM) mojavelinux: well, it's not just swallowing exceptions...
(03:06:05 PM) mojavelinux: I had a case the other day where Arquillian was saying something about "cannot enrich"
(03:06:13 PM) ALR@Freenode: The test case may either run as part of the container, or interact as a normal client.
(03:06:13 PM) mojavelinux: on the server, I had two beans conflicting
(03:06:21 PM) pmuir: ALR: thats good
(03:06:41 PM) mojavelinux: so it's about recognizing that something went wrong, that the server is trying to communicate something and getting it back to the test failure report
(03:06:54 PM) mojavelinux: @pmuir did some nice stuff w/ this in the CDI TCK harness
(03:07:06 PM) ALR@Freenode: Cool.
(03:07:09 PM) mojavelinux: using an exception translator
(03:07:24 PM) mojavelinux: impl had to tap into JBoss ProfileConnector (or whatever it is called)
(03:07:50 PM) pmuir: though I would say something about the deployment still, as it reinforces the idea that the test runs inside the the environment of the artifact, not just in the whole of JBoss AS
(03:08:04 PM) pmuir: yes, it is useful to be able to see how a deployment failed, not just that it failed
(03:08:08 PM) aslak: mojavelinux, yea, we also need to be aware of ClassNotFound exceptions on returning exceptions..
(03:08:25 PM) mojavelinux: ProfileService was the right name
(03:08:28 PM) pmuir: but this is probably a feature for down the line
(03:08:56 PM) mojavelinux: sure, just something for the mission (actually the more technical direction of project)
(03:09:16 PM) mojavelinux: for the record org.jboss.testharness.api.DeploymentExceptionTransformer
(03:09:33 PM) pmuir: yup, "Arquillian allows you to inspect why your deployment failed"
(03:09:37 PM) ALR@Freenode: So regarding the missing statement:
(03:09:59 PM) ALR@Freenode: "Arquillian takes the plumbing out of integration testing" ?
(03:10:16 PM) ALR@Freenode: Or something with greater impact but same simplicity?
(03:10:27 PM) aslak: pmuir, another spi under control by the container i guess
(03:10:39 PM) mojavelinux: @ALR that would be a good sentence for "in other words...."
(03:10:55 PM) kenglxn: +1
(03:11:01 PM) ALR@Freenode: I'm looking at: http://community.jboss.org/docs/DOC-14376
(03:11:02 PM) mojavelinux: like a take away statement
(03:11:05 PM) pmuir: aslak: yeah, basically, except it's quite complex as there can be // failures
(03:11:18 PM) ALR@Freenode: We have 4 references to "testing in the container"
(03:12:12 PM) aslak: pmuir, yea, but the container should know how to desifre it's own exceptions, not a extension.
(03:12:19 PM) ALR@Freenode: Should we move to code?
(03:12:33 PM) ALR@Freenode: And make a JIRA item to update the Wiki, taking into consideration the discussions here?
(03:12:52 PM) pmuir: ALR: I'm good
(03:13:07 PM) mojavelinux: yep...keep in mind that the mission statement on the wiki is/should be a clone of what is in the reference guide
(03:13:12 PM) ALR@Freenode: pmuir: Only problem w/ Wiki updates in JIRA is that they make it into the release notes.
(03:13:20 PM) ALR@Freenode: OK, good point
(03:13:42 PM) mojavelinux: @ALR which is okay since it will be updating the reference guide at the same time, part of the release
(03:13:44 PM) aslak: ALR, with out a fixed v. as well?
(03:13:48 PM) pmuir: lol, ok, well mojavelinux can you take as an AI to update the wiki/ref guide based on discussion and then post when you have made the change
(03:13:54 PM) mojavelinux: done
(03:13:57 PM) mojavelinux: taken
(03:14:40 PM) ALR@Freenode: https://jira.jboss.org/jira/browse/ARQ-65
(03:15:04 PM) mojavelinux: we need a documentation component in JIRA
(03:15:17 PM) ALR@Freenode: OK, I put it under "Project Management"; will rename that.
(03:15:39 PM) ALR@Freenode: Done
(03:16:33 PM) mojavelinux: documentation issues always get targeted at the GA release in Seam and Weld, so I'll mark that (oh, I should have said GA, I might get a ruler to the knuckles)
(03:16:41 PM) mojavelinux: s/should/shouldn't/
(03:17:47 PM) pmuir: s/GA/Final/
(03:17:57 PM) ALR@Freenode: 1.0.0.Final ?
(03:17:58 PM) mojavelinux: @pmuir
(03:18:06 PM) mojavelinux: 1.0.0
(03:18:09 PM) mojavelinux: we just call it final
(03:18:13 PM) aslak: mojavelinux, weld/seam releases has stopped being general acceptable ?
(03:18:14 PM) ALR@Freenode: k
(03:18:20 PM) ALR@Freenode: What's the point of 1.0.0-alpha-2 ?
(03:18:22 PM) lightguard_jp: non-snapshot
(03:18:24 PM) ALR@Freenode: There are 4 issues assigned
(03:18:26 PM) mojavelinux: we aren't allow to use the term GA anymore
(03:18:34 PM) mojavelinux: politics
(03:18:38 PM) ALR@Freenode: Typically I keep everything thats unscheduled, well, unscheduled.
(03:18:41 PM) pmuir: thought police
(03:18:51 PM) pmuir: ALR: I agree with that tactic :-)
(03:18:55 PM) ALR@Freenode: And assign to a release when either done or required by a specific version
(03:18:57 PM) ALR@Freenode: k
(03:19:11 PM) pmuir: well, for feature requests, yes
(03:19:22 PM) pmuir: for bugs, I tend to put them for the next release, unless there is a good reason not to
(03:20:10 PM) ALR@Freenode: k, versions in JIRA should now be fixed up pretty good.
(03:20:17 PM) ALR@Freenode: Only 2 issues targeted for 1.0.0-alpha-1
(03:20:20 PM) ALR@Freenode: Rest unscheduled.
(03:20:24 PM) ALR@Freenode: And a 1.0.0 in the wings.
(03:22:10 PM) ***ALR@Freenode is ready for code!
(03:22:17 PM) pmuir: me too ;-)
(03:22:21 PM) mojavelinux: so we need to talk about the SPIs, but also we really need to get to the issue of a configuration too
(03:22:28 PM) ALR@Freenode: Agreed.
(03:22:28 PM) mojavelinux: let's move along
(03:22:32 PM) ALR@Freenode: APIs first?
(03:22:34 PM) ALR@Freenode: Then SPIs?
(03:22:48 PM) ALR@Freenode: I don't know how much time we realistically have today.
(03:22:53 PM) ALR@Freenode: Unless we make this openended.
(03:22:57 PM) mojavelinux: there is only one API, isn't there?
(03:23:00 PM) mojavelinux: @Deployment
(03:23:03 PM) ALR@Freenode: Yep.
(03:23:06 PM) ALR@Freenode: Config would be another
(03:23:10 PM) aslak: @RunWith / extends Arquillian
(03:23:25 PM) pmuir: ALR: let's call it a day in 37m time, and schedule another meeting for another day this week, same time?
(03:23:26 PM) aslak: hook more then api maybe
(03:23:34 PM) ALR@Freenode: pmuir: I like that
(03:23:45 PM) aslak: ok, we keep it 2 hours
(03:24:07 PM) pmuir: (not least as I need my tea and some phone calls)
(03:24:23 PM) mojavelinux: hehe
(03:24:47 PM) aslak: Open issue that involes @Deployment: https://jira.jboss.org/jira/browse/ARQ-30
(03:25:16 PM) ALR@Freenode: I'd say: out of scope for now
(03:25:29 PM) ALR@Freenode: Justification as feature we can live without for the time being.
(03:25:56 PM) aslak: ok
(03:26:01 PM) ALR@Freenode: I guess we haven't talked about release criteria for Alpha 1 yet
(03:26:07 PM) ALR@Freenode: I'd like to set the bar really, really low.
(03:26:21 PM) aslak: is this 'restricted' to alpha-1 ?
(03:26:31 PM) ALR@Freenode: If we support Embedded GFv3 and/or OpenEJB with manual deployments, I'd say that's a good target to ship
(03:26:33 PM) pmuir: yes, we can live without this in alpha 1
(03:26:39 PM) pmuir: but we need it for 1.90
(03:26:41 PM) mojavelinux: this might be out of scope, but personally I really don't like this in every test case: Archives.create("test.jar", JavaArchive.class)
(03:26:42 PM) pmuir: 1.0 even
(03:27:03 PM) mojavelinux: that seems so boilerplate for 80% of cases
(03:27:04 PM) aslak: pmuir, i agree.. right before the 2.0 release sounds good..
(03:27:20 PM) mojavelinux: I like the idea of injecting a default archive along the lines of the last comment in the issue
(03:27:22 PM) pmuir: mojavelinux: exactly
(03:27:34 PM) pmuir: but for alpha1 it's not important
(03:27:38 PM) ALR@Freenode: mojavelinux: Agree. With ARQ-30 we can do stuff like make an annotation API for archives.
(03:27:39 PM) mojavelinux: k
(03:27:44 PM) aslak: pmuir, mojavelinux, a default Archive of what?
(03:27:47 PM) ALR@Freenode: mojavelinux: Which could live in ShrinkWrap
(03:28:06 PM) ALR@Freenode: Like @Archive(@Classes({ClassA.class, ClassB.class}))
(03:28:10 PM) mojavelinux: @aslak it would be a JAR called "default.jar" or something
(03:28:21 PM) aslak: mojavelinux, what if i want to deploy a war?
(03:28:26 PM) aslak: or a rar
(03:28:40 PM) jganoff: Would be nice to have templates for deployments instead of always having to create a beans.xml
(03:28:41 PM) mojavelinux: you can set the extension using the fluent API, I would suppose
(03:28:45 PM) jganoff: e.g. for CDI deployments.
(03:28:47 PM) ALR@Freenode: mojavelinux: Behaviour in ShrinkWrap is actually different for WAR and RAR.
(03:28:48 PM) pmuir: ALR: i'm not sure we need that
(03:28:50 PM) mojavelinux: or annotated the injection point
(03:29:11 PM) ALR@Freenode: pmuir: Nor am I, really.
(03:29:14 PM) aslak: jganoff, https://jira.jboss.org/jira/browse/SHRINKWRAP-115
(03:29:16 PM) mojavelinux: @Web JavaArchive or something
(03:29:26 PM) pmuir: anyway, can we defer the design discussion for this until we need to do it :-p
(03:29:34 PM) aslak: hehe
(03:29:34 PM) mojavelinux: k
(03:29:37 PM) ALR@Freenode: Ew tongue.
(03:29:40 PM) pmuir: that is the reason I think we defer this, as we need time to design it right
(03:29:45 PM) jganoff: aslak: great, thanks!
(03:30:34 PM) aslak: ok.. then moving along down the call stack
(03:30:47 PM) aslak: we come to the arquillian runners on the client side
(03:31:12 PM) aslak: btw.. client side ws server/container side. describes where it is in use
(03:31:23 PM) aslak: http://community.jboss.org/wiki/ArquillianDesignOverview
(03:32:13 PM) ALR@Freenode: We talked a bit about this:
(03:32:30 PM) ALR@Freenode: Deployment should always be @BeforeClass/@AfterClass ?
(03:32:38 PM) aslak: ALR, no
(03:32:42 PM) ALR@Freenode: Ah cool.
(03:32:56 PM) ALR@Freenode: If we make it configurable to be @Before/@After that's awesome.
(03:33:03 PM) aslak: ALR, i'm sure you could up with some usecases if you really tried.. so i can give you that ..
(03:33:06 PM) ALR@Freenode: Helps users with their test layout
(03:33:24 PM) ALR@Freenode: aslak: Book Examples reveal all hidden cases
(03:33:49 PM) ALR@Freenode: Take us down the path.
(03:33:57 PM) aslak: but anyway.. that's how to works now
(03:34:14 PM) pmuir: yeah, I think allowing the deployment around a test method is another thing we should have but not necessarily for alpha 1
(03:34:30 PM) aslak: we need a configurable container controller, ForceRestart, RestartPrTest, NeverRestart etc
(03:34:40 PM) ALR@Freenode: Yup, just to be sure we don't limit ourselves in design, it's a feature
(03:34:43 PM) kenglxn: perhaps a bit off track, but test dependencies would be nice, like one test dependant on another, for integration tests
(03:34:43 PM) ALR@Freenode: (An easy one actually)
(03:34:59 PM) ALR@Freenode: kenglxn: I think that is an antipattern
(03:35:02 PM) aslak: kenglxn, between test cases or methods?
(03:35:16 PM) kenglxn: i think more in asynch world
(03:35:21 PM) lightguard_jp: kenglxn: That's the deal of the test framework, I don't think we should muck with that.
(03:35:33 PM) pmuir: kenglxn: lightguard_jp right, testng already supports this
(03:35:39 PM) ALR@Freenode: The idea is that tests should be written autonomously.
(03:35:53 PM) ALR@Freenode: And test state should be reset to between invocations.
(03:36:20 PM) pmuir: ALR: :-)
(03:36:25 PM) aslak: kenglxn, yea, testng has depend on method / groups etc.. does all the sorting before it reaches arquillian
(03:36:46 PM) aslak: we tho have this which is related: https://jira.jboss.org/jira/browse/ARQ-55
(03:37:32 PM) kenglxn: yea, that's it
(03:38:38 PM) aslak: ok, next in the stack is the packaging of the deployment
(03:38:42 PM) mojavelinux: the test frameworks already give you multiple ways to setup and teardown, which is all the dependence you should have
(03:38:54 PM) mojavelinux: anything else I think should be solved by multiple "requests" in the same method
(03:39:30 PM) mojavelinux: I'll get to that second part later on
(03:39:57 PM) aslak: I'm proposing 3 spis to handle this.. DeploymentAppender, DeploymentEnricher and DeploymentPackager
(03:40:00 PM) kenglxn: i'm thinking in lines of testing integration between systems, where there is no point in testing methody if methodx has failed, where the backend may be down for a longer period of time, but this may be better discussed later time
(03:40:02 PM) mojavelinux: @aslak here is where we need to be cognizant of whether we should be appending to the archive or not
(03:40:20 PM) pmuir: kenglxn: i think you can still use testng depends on stuff here
(03:40:26 PM) kenglxn: ok
(03:40:34 PM) pmuir: aslak: can you talk us through the proposed spis
(03:40:35 PM) pmuir: ?
(03:40:55 PM) aslak: pmuir, yes.. getting there
(03:41:13 PM) aslak: https://jira.jboss.org/jira/browse/ARQ-25
(03:42:04 PM) aslak: The requirement is.. we should support any type of container supporting any type of deployment. in some contianers we need to add some extras to the archives to function
(03:42:36 PM) aslak: so, DeploymentAppender: http://anonsvn.jboss.org/repos/common/arquillian/trunk/spi/src/main/java/org/jboss/arquillian/spi/DeploymentAppender.java
(03:43:02 PM) aslak: this is a dynamically loadded spi, the idea is that anyone can add to the deployment
(03:44:08 PM) aslak: examples of use, Arquillian JUnit adds junit pluss some classes(test runner), Arquillian Core adds core, Protocol Servlets add a servlet, test enrichers
(03:45:42 PM) mojavelinux: I believe that @ALR had some concerns here about modifying the archive and affecting the behavior of the code (JNDI module names for one)
(03:46:01 PM) ALR@Freenode: Mhmm
(03:46:04 PM) aslak: and to overcome that a container/technology needs something special added to the single deploymentappender artifacts(ie, cdi needs to add a beans.xml to the protocol servlet war), we have the DeploymentEnricher
(03:46:15 PM) aslak: ALR, mojavelinux; getting to that
(03:47:11 PM) aslak: DeploymentEnricher is a 'made' up spi as of now.. but something like void enrich(List<Archive<?>> deploymentParts)
(03:47:57 PM) aslak: these two spis are controlled by each module. next is the DeploymentPakcager spi
(03:48:02 PM) ALR@Freenode: I like the design. Can we consider renames maybe?
(03:48:41 PM) aslak: it has the responsibility of adding this up into a archive that the repective container can support..
(03:48:50 PM) ALR@Freenode: Sorry keep going
(03:49:31 PM) aslak: so this should be controlled by the contianer. in Andrews OpenEJB lay of my deployment case.. OpenEJB has it's own DeploymentPackager that ignores the DeploymentAppenders/Enrichers..
(03:50:56 PM) aslak: that in my mind should cover our needs for packaging etc.. with one problem, but i'll get to that later
(03:51:20 PM) aslak: ALR, renames, sure.. got any good names?
(03:52:48 PM) mojavelinux: DeploymentPackager is currently DeploymentAppenderArchiveGenerator (hardcoded impl)
(03:52:54 PM) aslak: yes
(03:52:55 PM) mojavelinux: fyi
(03:53:07 PM) aslak: mojavelinux, thanks. forgot to copy that in there
(03:53:18 PM) ALR@Freenode: aslak: Not yet. Gotta understand enrichers better first
(03:53:26 PM) aslak: http://anonsvn.jboss.org/repos/common/arquillian/trunk/impl-base/src/main/java/org/jboss/arquillian/impl/DeploymentAppenderArchiveGenerator.java
(03:53:38 PM) pmuir: I also like the overall design - it seems to cover the use cases I know of
(03:53:46 PM) ALR@Freenode: Yeah, it's good.
(03:53:55 PM) mojavelinux: enricher is what provides injection into the test case, amongst other things, right?
(03:54:00 PM) ALR@Freenode: I think the main goal now is to jump off it and make it all configurable.
(03:54:04 PM) mojavelinux: or is that TestEnricher
(03:54:10 PM) mojavelinux: not to be confused with DeploymentEnricher
(03:54:10 PM) aslak: ALR, Enrichers.. well.. due to a stupid miss conceptunal design between cdi and ee6, we need this..
(03:54:33 PM) pmuir: ok, I suggest we finish up now
(03:54:50 PM) pmuir: and have configuration as a first topic for the next meeting
(03:54:52 PM) aslak: mojavelinux, ALR, well.. that depends.. andrew you mean DeploymentEnrichers or TestEnrichers ?
(03:55:01 PM) pmuir: can everyone do the same timeslot tomorrow?
(03:55:22 PM) mojavelinux: I'm going to be in the air (weather permitting)
(03:55:28 PM) aslak: pmuir, can we discuss configuration before we know how it does what it does?
(03:55:29 PM) mojavelinux: Wedneday would be my first available
(03:55:30 PM) ALR@Freenode: pmuir: No, I'm going to see Dan.
(03:55:31 PM) lightguard_jp: Possibly, but I'm mostly lurking
(03:55:52 PM) pmuir: I can't do Weds
(03:55:58 PM) pmuir: how about thursday?
(03:56:05 PM) mojavelinux: thursday works too
(03:56:11 PM) mojavelinux: really anyting but tomorrow
(03:56:20 PM) pmuir: aslak: what do you mean?
(03:56:44 PM) ALR@Freenode: Thurs OK here
(03:56:45 PM) jganoff left the room (quit: Quit: Leaving).
(03:56:46 PM) mojavelinux: before we touch configuration, can you explain one more time what DeploymentEnrichers does?
(03:56:50 PM) pmuir: I mean configuration in general, not just of deployment enricher
(03:56:56 PM) mojavelinux: or what it lines up with right now in the code
(03:57:04 PM) pmuir: it's like Process* in CDI
(03:57:08 PM) aslak: pmuir, i mean, should we continnue through the spi before we discuss how to configure it ?
(03:57:11 PM) pmuir: as I understand it
(03:57:20 PM) pmuir: or not quite
(03:57:22 PM) pmuir: actually
(03:57:23 PM) pmuir: oops
(03:57:30 PM) pmuir: aslak: ok, yes, we should do that first :-)
(03:57:33 PM) aslak: mojavelinux, it's a Deployment ointerceptor ish
(03:57:46 PM) pmuir: yup
(03:57:57 PM) aslak: mojavelinux, with the intent of side effects hehe
(03:57:57 PM) mojavelinux: ah
(03:58:32 PM) aslak: anyone works for me btw
(03:58:33 PM) pmuir: aslak: have you looked at Process* in CDI?
(03:58:37 PM) aslak: any day even
(03:58:41 PM) pmuir: ok, it's thursday then :-)
(03:59:04 PM) ALR@Freenode: We'll pick up here then?
(03:59:07 PM) lightguard_jp: Will this meeting be put up on the wiki somewhere?
(03:59:11 PM) pmuir: ok, I'm dropping off, catch all tomorrow
(03:59:12 PM) ALR@Freenode: Yes, I'll post it now.
Comments