[00:16:26] *** Elisha has quit IRC
[00:16:45] *** Elisha has joined #jbosstesting
[00:18:22] *** aslak has quit IRC
[01:18:59] *** johnament has joined #jbosstesting
[01:37:21] *** ldimaggi has joined #jbosstesting
[03:19:08] *** johnament has quit IRC
[03:32:43] *** bobmcw has joined #jbosstesting
[04:17:49] *** bobmcw has quit IRC
[04:17:53] *** bobmcw_ has joined #jbosstesting
[04:19:32] *** ldimaggi has quit IRC
[04:20:28] *** bobmcw_ has quit IRC
[04:21:12] *** bobmcw has joined #jbosstesting
[04:33:58] *** bgeorges has joined #jbosstesting
[04:46:59] *** bobmcw has quit IRC
[04:47:18] *** bobmcw has joined #jbosstesting
[05:00:44] *** rruss has joined #jbosstesting
[06:12:30] *** rruss has quit IRC
[06:59:24] *** kpiwko has joined #jbosstesting
[07:00:57] *** bleathem has quit IRC
[07:46:57] *** Elisha has quit IRC
[07:47:27] *** Elisha has joined #jbosstesting
[08:54:52] *** michaelschuetz has joined #jbosstesting
[09:00:22] *** ge0ffrey has joined #jbosstesting
[09:09:40] *** oskutka has joined #jbosstesting
[09:12:15] *** bgeorges has quit IRC
[09:12:31] *** bgeorges has joined #jbosstesting
[09:21:21] *** alesj has joined #jbosstesting
[09:25:32] *** maeste has joined #jbosstesting
[09:26:08] *** mgoldmann has joined #jbosstesting
[09:26:22] *** mgoldmann has quit IRC
[09:26:28] *** mgoldmann has joined #jbosstesting
[09:33:44] *** aslak has joined #jbosstesting
[09:35:26] *** lfryc has joined #jbosstesting
[09:42:17] *** jeand has joined #jbosstesting
[09:44:45] *** Jaikiran has joined #jbosstesting
[10:02:46] *** wolfc has joined #jbosstesting
[10:11:45] <aslak> lfryc, kpiwko, heya
[10:12:01] <lfryc> aslak: hi
[10:12:01] <kpiwko> aslak: hey
[10:12:21] <aslak> lfryc, kpiwko, could you guys cook up a nice little blog about Arq Drone and Arq Ajocado ?
[10:13:27] <aslak> the release notes only mention them by name, and not much more. we have some docs on Drone, but.. a little bit of what Drone is, what Ajocado is, and how to use them together. a couple of usecases + examples ?
[10:14:00] <lfryc> aslak: sounds good, I will work on it during this week
[10:14:31] <kpiwko> aslak: we have an auction example at github, it must be translated to english and update
[10:14:44] <kpiwko> aslak: it uses seam 3 and jsf 2, so a brand new one ;)
[10:14:58] <aslak> kpiwko, cool!
[10:15:44] <kpiwko> aslak, I have one unfinished article in my blog queue about arquillian selenium, I'll update it to Arquillian Drone :)
[10:15:56] <aslak> you guys have access to blog at the arq community space right? (i think everyone does)
[10:16:06] <aslak> kpiwko, hehe :)
[10:28:04] *** echelog-2 has joined #jbosstesting
[10:29:31] *** bgeorges has quit IRC
[10:48:41] <lfryc> kpiwko: aslak RichFaces will migrate to Ajocado / Arq also after Final released
[10:49:17] <kpiwko> lfryc: after RF final or Arq/Ajo final?
[10:49:45] <aslak> kpiwko, lfryc, we just need to 'monitor' the need they have, fix it and make sure they swap in the future.. :)
[10:49:49] *** alesj has left #jbosstesting
[10:58:16] *** kpiwko is now known as kpiwko_afk
[11:00:36] <lfryc> kpiwko_afk: RF Final :-)
[11:25:32] *** vtunka has joined #jbosstesting
[11:30:22] *** maeste has quit IRC
[11:30:59] *** maeste has joined #jbosstesting
[11:31:24] *** pmuir has joined #jbosstesting
[11:43:54] *** kpiwko_afk is now known as kpiwko
[11:57:02] *** ALR has joined #jbosstesting
[12:02:07] *** alesj has joined #jbosstesting
[12:14:33] *** ldimaggi has joined #jbosstesting
[12:22:46] *** Jaikiran is now known as Jaikiran|AFK
[12:39:51] *** bobmcw has quit IRC
[12:41:59] *** ALR has quit IRC
[13:24:27] *** Jaikiran|AFK is now known as Jaikiran
[13:37:54] <kpiwko> aslak: hey
[13:38:09] <aslak> kpiwko, heya
[13:40:01] <kpiwko> aslak: have you seen ARQ-375?
[13:40:02] <jbossbot> jira [ARQ-375] Support for the containers in JBoss products [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/ARQ-375
[13:40:15] <aslak> kpiwko, yea
[13:41:45] <kpiwko> kpiwko: from my point of view, jboss-remote/managed and tomcat-remote/managed will cover most of the use cases guys need
[13:41:54] <kpiwko> any plans to work on tomcat-remote?
[13:41:56] <aslak> kpiwko, EAP 5.1 was working, sorta. Needs a combination of the JBoss AS 6 container and 5.1 EAP libs.
[13:43:46] <aslak> kpiwko, agree.. i think we have a issue on both managed and remote for tomcat. i havn't looked much at the apis and what is possible yet
[13:44:20] <aslak> not sure how EWS's tomcat version is compared to normal tomcat either. i would suspect it's closer to EAP then Tomcat
[13:45:58] <kpiwko> aslak: hmm, I'll try to check and find somebody willing to implement it
[13:46:15] <aslak> kpiwko, cool
[13:48:14] <kpiwko> aslak: another request is AS 4...I expect JIRA will be overflooded soon :)
[13:49:07] <aslak> ARQ-238
[13:49:09] <jbossbot> jira [ARQ-238] Create a DeployableContainer integration for JBoss AS 4.2 [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/ARQ-238
[13:49:55] <aslak> kpiwko, needs to be upgraded to the new spis, but should be able to work a bit better now since we got the Descriptors to modify application.xml etc
[13:50:06] <aslak> ARQ-261 ARQ-262
[13:50:07] <jbossbot> jira [ARQ-261] Add a Tomcat managed container [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/ARQ-261
[13:50:08] <jbossbot> jira [ARQ-262] Add a Tomcat remote container [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/ARQ-262
[14:56:01] *** echelog-2 has joined #jbosstesting
[15:46:58] *** bleathem has joined #jbosstesting
[15:53:43] *** lightguard_jp has quit IRC
[16:01:04] *** bbrowning has joined #jbosstesting
[16:01:14] <bbrowning> aslak: This is ALR
[16:01:15] <bbrowning> Ping.
[16:03:04] <bbrowning> Was just looking for the ARQ code that finds duplicate containers on the CP.
[16:03:14] <bbrowning> Linky when you got a sec?  Thanks :) - ALR
[16:03:33] <aslak> bbrowning, heya
[16:04:11] <aslak> bbrowning, you want the exception handling ?
[16:07:11] *** aslak has quit IRC
[16:07:41] *** aslak has joined #jbosstesting
[16:09:38] <aslak> bbrowning, it's triggered during ContainerRegistry creation, but is thrown from ServiceLoader.onlyOne
[16:11:04] <aslak> https://github.com/arquillian/arquillian/blob/master/impl-base/src/main/java/org/jboss/arquillian/impl/client/container/ContainerRegistryCreator.java#L87
[16:11:09] <aslak> https://github.com/arquillian/arquillian/blob/master/impl-base/src/main/java/org/jboss/arquillian/impl/domain/ContainerRegistry.java#L73
[16:11:14] <aslak> https://github.com/arquillian/arquillian/blob/master/impl-base/src/main/java/org/jboss/arquillian/impl/DynamicServiceLoader.java#L88
[16:12:37] *** bbrowning has quit IRC
[16:12:52] *** bbrowning has joined #jbosstesting
[16:14:00] <aslak> bbrowning, ?
[16:16:50] *** thohawk has joined #jbosstesting
[16:18:09] <thohawk> help
[16:18:16] <thohawk> #help
[16:18:42] *** thohawk has quit IRC
[16:18:50] <aslak> Welcome to the JBoss Testing Support Center! How may I direct your call ?
[16:18:51] <aslak> :)
[16:19:05] <aslak> hung up.. how rude
[16:28:58] *** lightguard_jp has joined #jbosstesting
[16:48:09] <mojavelinux> holler folks...are we going to do the meeting in 10 mins, or is ALR busy at devnexus?
[16:49:30] <mojavelinux> btw, I was thinking, why do we need a remote and managed container (perhaps we discussed this already) it seems to me the "managed" part should be a setting of a remote container
[16:49:50] <mojavelinux> because code for many containers, for instance the glassfish one, is going to be otherwise the same
[16:50:05] <lightguard_jp> Was this on ARQ or SW?
[16:50:19] <mojavelinux> I suppose the managed container could just extend the remote container, but still seems more of a setting to me
[16:50:22] <mojavelinux> this is arq
[16:50:26] <lightguard_jp> I was thinking about that as well
[16:50:26] <mojavelinux> managed = start + stop
[16:50:41] <mojavelinux> which is implicit in an embedded container
[16:51:17] <lightguard_jp> Simplifying containers that are essentially the same is a good idea
[16:51:25] <lightguard_jp> Less copy / paste :)
[16:51:48] <mojavelinux> exactly
[16:52:03] <mojavelinux> this could happen as we split out the containers, which is on the agenda for meeting
[16:52:12] <mojavelinux> so perhaps we'll add this topic as well
[16:52:12] *** rruss has quit IRC
[16:53:12] <lightguard_jp> Where's meetbot :(
[16:53:19] <lightguard_jp> I've gotten use to it
[16:54:32] *** bbrowning has left #jbosstesting
[16:58:57] <aslak> heya guys
[16:59:16] <aslak> we have a meeting, and run it by alr when his back
[16:59:19] <aslak> he's
[17:00:25] *** alesj has left #jbosstesting
[17:04:17] <aslak> lightguard_jp, mojavelinux we getting the meeting bot or?
[17:04:54] <lightguard_jp> I can ask max
[17:04:59] <lightguard_jp> Well, see if he's around.
[17:05:17] <aslak> isn't he at eclipsecon or something
[17:05:36] <lightguard_jp> I don't see him, so no bot
[17:05:40] <aslak> ok
[17:05:52] <aslak> we can pretend then.. :)
[17:06:10] <aslak> #topic Modularize the build
[17:06:42] <aslak> #subtopic How to join them back
[17:08:17] <aslak> I think the first step is to split out extensions and containers
[17:08:32] <lightguard_jp> Extensions == ??
[17:08:42] <lightguard_jp> Enrichers, and what?
[17:09:03] <aslak> Arquillian Drone, Byteman, JSFUnit(already moved to jsfunit), Jacoco etc
[17:09:18] <aslak> no, enrichers stay
[17:10:08] <aslak> impl-base will be split up to configuration, container(what you know as arq, deployments etc) and core
[17:10:50] <lightguard_jp> Okay, that works
[17:11:04] <lightguard_jp> Just thinking about that Seam 2 enricher Michael was going to work on
[17:11:08] <aslak> as for the containers, i was thinking a repo pr 'provider'
[17:11:45] <aslak> enrichers belong to container i think. which needs a name btw so we don't confuse it with the containers
[17:12:16] <lightguard_jp> You'd have one repo for jboss6, one for glassfish, one for tomcat6, etc?
[17:12:35] <lightguard_jp> Then have different artifacts for remote, embedded, whatever?
[17:12:59] <aslak> one for jboss5,  5.1, 6, weld, one for gf 3.1, one for apache tomcat, openejb, openwebbeans
[17:13:30] *** kpiwko has quit IRC
[17:14:29] <mojavelinux> shoot, catching up...
[17:14:57] <mojavelinux> can we please rename testenrichers to enrichers
[17:15:02] <mojavelinux> I think "test" is assumed at this point
[17:15:32] <aslak> for the jboss as ones, it makes sense in the sense that when we add new features, they are mos likely all updated with more or less identical code. and they can share a lot so they can have the same release cycle. weld comes a bit outside of the same release cycle i would think, but is maintained by the same ppl
[17:15:45] <aslak> mojavelinux, sure, but stick to topic.. :)
[17:15:52] <mojavelinux> sorry, just a side note
[17:16:38] <mojavelinux> yeah, I think each container vendor should have it's own git repo
[17:16:49] <mojavelinux> and weld is an indepenent vendor from jboss as
[17:17:02] <mojavelinux> the vendor is the container brand in a sense
[17:17:09] <mojavelinux> so yes, I agree
[17:17:58] <aslak> og, so we have, JBoss AS, GlassFish, Resin, Tomcat, Jetty, OpenWebbeans, Weld, OpenEJB
[17:18:00] *** adriancole has joined #jbosstesting
[17:18:04] <lightguard_jp> Sounds like we all agree.
[17:18:25] <lightguard_jp> #agreed Each vendor will have it's own git repo: JBoss AS, GlassFish, Resin, Tomcat, Jetty, OpenWebbeans, Weld, OpenEJB
[17:18:55] *** maeste has quit IRC
[17:18:57] <mojavelinux> Websphere, Weblogic (one can dream)
[17:19:09] <aslak> mojavelinux, websphere we have working..
[17:19:19] <adriancole> I think they call that style of dream nightmare?
[17:19:28] <adriancole> :p
[17:19:43] <mojavelinux> hahaha
[17:19:53] <aslak> ok, then each repo has it's own release cycle
[17:20:13] <mojavelinux> yep, and it would depend on a release of Arquillian, no snapshots, ideally
[17:20:20] <adriancole> +1 also looking at things like cargo and whirr, people tend to mind their own flock, too
[17:20:38] <mojavelinux> right, this is the key of getting them to tend their adapter
[17:20:42] <adriancole> ex. glassfish guys will tend to work on glassfish
[17:20:47] <adriancole> yep
[17:20:52] <aslak> yea
[17:21:03] <aslak> #subtopic how to bring it all back
[17:21:15] <mojavelinux> you mean like a dist release?
[17:21:26] <aslak> by that i mean.. we have users who would want to use this..
[17:21:37] <lightguard_jp> Not holding my breath for a glassfish adapter from them though
[17:21:43] <lightguard_jp> Or Weblogic
[17:21:54] <mojavelinux> alr will work them down :)
[17:22:24] <aslak> lightguard_jp, if we just don't implement one. they will have to soon enought with arq being weld-core-tests and cdi-tck
[17:22:48] <aslak> if they share it or not is a different story
[17:22:57] <mojavelinux> exactly, we just keep sweeting the pot
[17:23:08] <mojavelinux> or, you get to the point of Mark the other day when he said
[17:23:15] <mojavelinux> "I'm not sure how to make #CODI work on GlassFish"
[17:23:22] <mojavelinux> yeah, the answer is written on the wall
[17:23:39] <mojavelinux> maintain your adapter :)
[17:24:03] <mojavelinux> and use arquillian
[17:24:13] <lightguard_jp> Oka
[17:24:22] <lightguard_jp> I'm all for forcing their hand.
[17:24:25] <mojavelinux> aslak what do you mean tie it together?
[17:24:34] <aslak> some background
[17:24:47] <mojavelinux> cause we basically do this in seam 3 with the dist/ module
[17:25:20] <aslak> one of the other steps, is to split up impl-base. it is now basically 3 different things mixed. it's the core event system to run it all. the Arq Descriptors configuration and the Container/Deployment extension
[17:25:22] <mojavelinux> much to the dismay of shane :)
[17:25:35] <mojavelinux> yep
[17:25:57] <aslak> i will keep them in the same repo for now, on the same release cycle
[17:26:31] <aslak> as well, the enrichers are currently tied to the Containers which will change, they will be dcoupled by Producers of types that the Enricher can depend on
[17:26:51] <aslak> so, e.g. the EJBEnricher will look for a InitialContext, if one found it can use it
[17:27:23] <aslak> the Producer of that InitialContext depends a bit.. either on Container or type etc. so we will have a InContainer producer, a JBoss specific producer
[17:27:43] <aslak> same with CDI, will depend on a BeanManager, we ahve a Weld specific or a EE6 standard way of fetching it
[17:27:54] <mojavelinux> right, fair enough, this is very similar in a sense to the weld integration api
[17:28:12] <aslak> Jboss 5 supports ejb and resources.. 6 supports cdi ejb resources.
[17:28:15] <mojavelinux> it's just going to assume at various points that the integrations are responsible for filling in the details, and it's going to progress as though it has what it needs
[17:28:58] <aslak> i was thinking instead of 'hardcoding' these in the containers, we can make 'Profile' poms for the containers. that add them all up with container deps etc that the user can include
[17:29:21] <mojavelinux> yes, precisely
[17:30:12] <mojavelinux> right now the we are half way in between, with the container adpater pulling in enrichers, but not the necessary container deps
[17:30:15] <aslak> we see some of the use for this when dealing with EAP, which is normally somewhere inbetween two AS releases but lacks features. SO a EAP 5.1 profile could include the jbossas-6 container, the ejb and resource enrichers pluss the initialcontext producers from jboss, but not the cdi enricher
[17:30:28] <mojavelinux> exactly
[17:30:47] <mojavelinux> we need to be able to define a cross section of dependencies and call that something
[17:30:53] <mojavelinux> this would be a pom import, correct?
[17:31:10] <mojavelinux> or what we call a bom
[17:31:27] <aslak> well, if it's a pom import yo uneed to define them all right? wouldn't it just be a pom you depend on?
[17:31:50] <mojavelinux> right, what you said
[17:32:21] <aslak> so far so good
[17:32:29] <aslak> then comes maintenance hell
[17:32:46] <aslak> and version naming
[17:33:40] <aslak> i don't like the idea of maintaining all these profile poms manually
[17:33:58] <aslak> well, we have to some extent, but not in the pom format
[17:34:12] <mojavelinux> ah, I see, you want them perhaps generated?
[17:34:23] <aslak> perhaps
[17:35:46] <aslak> but let's look at v. naming first..
[17:35:51] <mojavelinux> let's just feel that out as we go...perhaps even have some research projects for working it out
[17:36:37] <aslak> we ave Arq 1.0.0.Beta1, and Jboss AS 6 Remote 1.0.0.Beta1
[17:37:11] <aslak> should the next release of JBoss AS that confine to the Arq Beta1 API be Beta1.1 ?
[17:37:54] <mojavelinux> I think it should be like this...
[17:38:09] <mojavelinux> container 1.0.x uses arquillian 1.0.y
[17:38:18] <mojavelinux> container 1.1.x uses arquillian 1.1.y
[17:38:39] <mojavelinux> then x and y can be whatever
[17:38:52] <lightguard_jp> Maven doesn't really have a good way of doing this :(
[17:39:11] <aslak> does Ranges work in this case?
[17:39:25] <aslak> for the Profiles
[17:39:32] <mojavelinux> I think ranges are something for documentation only
[17:39:47] <mojavelinux> ranges explain our intent...the dependencies should be defined with the most recommended configuration
[17:40:09] <mojavelinux> my concern is that if you bump an arquillian version, likely you'll have to update the containers, and should bump them as well
[17:40:17] <mojavelinux> unless there is no api change, then the container can lag
[17:40:19] <aslak> wouldn't that be the lastest released matching v until otherwise proven wrong?
[17:40:25] <lightguard_jp> Version ranges are not a good way to go if we're talking about ranges in maven resolution.
[17:40:32] <mojavelinux> but when the container has to upgrade to align w/ arquillian api change, then it should match it's major/minor version
[17:40:43] <mojavelinux> ranges have no place in a maven build
[17:41:01] <mojavelinux> imho
[17:41:14] <aslak> so then we need a new Profile release for every Container release
[17:41:31] <mojavelinux> i think so, yes
[17:41:47] <mojavelinux> which is fine, it's part of the container really
[17:41:56] <mojavelinux> meaning, it's part of what it means to maintain a container
[17:42:31] <mojavelinux> and I think it's fine that we could have a profile generator (or updater) (forge plugin?)
[17:42:43] <mojavelinux> just takes the manual work out of it potentially
[17:43:08] *** oskutka has quit IRC
[17:44:01] <lightguard_jp> Having the profiles auto generated (somehow, perl script, groovy, Velocity / Freemarker, forge, I don't care) sounds like a good idea.
[17:45:11] <mojavelinux> the nice part is that someone could create their own local (or in-house) profile...so it makes the container definition a lot more flexible for custom use cases
[17:45:33] <mojavelinux> like, for instance, some hybrid container (suped up tomcat) or EAP
[17:45:55] <aslak> #agreed Use Profile poms to join Container, Enrichers, Producers and Container Deps
[17:46:27] <aslak> #action research if Profiles can be (auto)generated
[17:48:15] <aslak> mojavelinux, you have any topics?
[17:48:27] <mojavelinux> yes, quick question about extensions
[17:48:36] <mojavelinux> what is the difference between a framework an an extension?
[17:48:47] <mojavelinux> I think we should just make them all extensions
[17:48:56] <aslak> mojavelinux, yes
[17:48:57] <mojavelinux> and each extension is it's own repository?
[17:49:23] <mojavelinux> or not
[17:49:30] <aslak> well, if we say one repo one release i would say so
[17:50:00] <aslak> we will get a hack of a lot of repos if we keep this up tho.. :)
[17:50:29] <mojavelinux> can we rival seam's 30?
[17:50:32] <mojavelinux> hehehe
[17:50:33] <aslak> but if we don't, we never get to release. because there is always one of our deps that do a release
[17:50:58] <mojavelinux> yep...I think it's okay...the extensions grow a lot at first, but then it levels off for a while
[17:51:06] <mojavelinux> plus, extensions can be externally hosted
[17:51:26] *** pmuir has quit IRC
[17:51:29] <aslak> yea, speaking of that. we need to join all this into a common location as well
[17:51:45] <mojavelinux> the extensions under arquillian are mostly the extensions where one of us is directly involved
[17:51:47] <mojavelinux> case in point
[17:51:54] <mojavelinux> we aren't doing the concordian extension
[17:52:20] <aslak> no, but we should know of it and 'push the info'
[17:52:51] <mojavelinux> ah, yes, this brings us to the endless discussion about cdi extension repository :)
[17:52:52] <mojavelinux> hehehe
[17:52:58] <aslak> basically yes
[17:53:03] <mojavelinux> basically, we just need a directory of some sort
[17:53:12] <mojavelinux> and we can also maintain a dist/ build
[17:53:19] <mojavelinux> that keeps track of what is available
[17:53:37] <mojavelinux> can even bring it together into a single ref guide
[17:53:40] <aslak> well we have confluence now, which is a bit easier to do things with then sbs.. intended for docs, but we might be able to make a sub page there where we can add up these things
[17:54:08] <mojavelinux> yep, also the showcase is good for this
[17:54:08] <aslak> then for a ref guide, that's a export from confluence
[17:54:29] <mojavelinux> because it puts the third-party integrations on center stage somewhere
[17:54:44] <aslak> showcase is good for code examples
[17:54:56] <mojavelinux> if you forget about maven, and think about a dist build as being done by a real build framework, it's actually quite straightforward
[17:55:22] <lightguard_jp> "real build framework" lol, why not just say what you mean?
[17:55:23] <aslak> a real build system
[17:55:39] <mojavelinux> you pull things from here and there, merge and voila, you have a single view
[17:56:02] <lightguard_jp> Wondering if we could / should make use of git submodules
[17:56:25] <mojavelinux> as far as I know, the submodules are a layered solution
[17:56:39] <mojavelinux> meaning the modules don't know they are a submodules...rather you have supermodules
[17:56:46] <mojavelinux> that treat repositories as submodules, correct?
[17:57:13] <lightguard_jp> I believe so.
[17:57:18] <aslak> it's just a repo attached to a subpath
[17:57:19] <lightguard_jp> I've only read about them, haven't used them
[17:57:20] <mojavelinux> again, sounds like another research project
[17:59:00] <mojavelinux> okay, another topic choice
[17:59:08] <mojavelinux> test filters, pleeeeeeeeeeeeeeeeeeeeeeeeeeease
[17:59:11] <mojavelinux> ;)
[17:59:35] <mojavelinux> i'll link to jira rather than explain
[18:00:19] <mojavelinux> ARQ-287
[18:00:20] <jbossbot> jira [ARQ-287] Add support for filtering tests based on required execution environment [Coding In Progress (Unresolved) Feature Request, Major, Dan Allen] https://issues.jboss.org/browse/ARQ-287
[18:00:32] *** Jaikiran has quit IRC
[18:01:09] <mojavelinux> the idea is that I'm writing a test, and I just know that this test is only going to work on certain containers, and my test suite is intended to be used on multiple containers for portability testing, etc
[18:01:38] <mojavelinux> maybe I need to test something specifically on glassfish, or I need an EJB feature, or the embedded container just doesn't cut it
[18:01:56] <mojavelinux> I can use testng groups or hack up surefire, but then I'm stuck in the build again
[18:02:01] <mojavelinux> I want to stay in the IDE
[18:02:10] <mojavelinux> or just not have to worry about the build configuration at all
[18:02:14] <mojavelinux> so I just say something like
[18:02:20] <mojavelinux> @RequiresEJB
[18:02:29] <mojavelinux> or @RequiresEE6
[18:02:49] <mojavelinux> @RequiresWeb
[18:02:59] <mojavelinux> first would be filtering out containers like weld ee embedded
[18:03:08] <lightguard_jp> You'd key off the available enrichers for a container?
[18:03:08] <mojavelinux> second would require something real like jboss as or glassfish
[18:03:14] <mojavelinux> last would require a container offering a web component
[18:03:26] <mojavelinux> yep, so next question is how to link it up
[18:03:38] <mojavelinux> at first I was suggesting annotating these annotations with container IDs
[18:04:23] <mojavelinux> but having it auto-resolved would be even better....somehow we specify which features a container provides and these qualifiers can be a cross-section of those attributes
[18:05:07] <mojavelinux> so like jboss as remote would be like "ejb", "web", "jca", "jboss" etc
[18:05:19] <mojavelinux> but then that gets sort of out of hand, because you could get really fine grained
[18:05:33] <mojavelinux> aslak suggested this
[18:05:38] <mojavelinux> in arquillian.xml
[18:05:43] <mojavelinux> you associate qualifiers with containers
[18:05:56] <mojavelinux> so you use @RequiresWeb
[18:06:17] <lightguard_jp> Are the annotations going to be type safe?
[18:06:20] <mojavelinux> then in arquillian.xml in the jboss as configuration, you say something like <supports><RequiresWeb/></supports>
[18:06:26] <lightguard_jp> If so, they'll be finite.
[18:06:37] <lightguard_jp> Well, they'll have to be known and finite up front
[18:06:48] <mojavelinux> we would provide some convenience annotations out of the box, but the user could introduce their own
[18:07:03] <mojavelinux> or course, that would be more like
[18:07:12] <mojavelinux> <supports><a:RequiresWeb/></supports>
[18:07:23] <mojavelinux> so yes "type-safe" in the XML sense
[18:07:27] <mojavelinux> or namespace aware
[18:08:14] <mojavelinux> you have to do one-time setup of arquillian.xml, but I think this is pretty flexible
[18:08:23] <mojavelinux> because, as aslak pointed out
[18:08:38] <mojavelinux> even if you have tons of detail in how you associate an annotation w/ a container, for instance by the name of the container
[18:08:49] <mojavelinux> you may have a configuration of that container which isn't going to support a test
[18:09:00] <lightguard_jp> I was talk about the annotations
[18:09:07] <lightguard_jp> But if they're user defined, then no big deal
[18:09:11] <mojavelinux> for instance, you might require the HTTPS web container
[18:09:14] <lightguard_jp> Was thinking we were going to supply them
[18:09:18] <mojavelinux> if you define one that has HTTP and one that has HTTPS
[18:09:36] <mojavelinux> I just think we should define some major ones out of the box to save typing in 80% of the cases
[18:09:49] <mojavelinux> so we provide an annotation for all major specs and container variants
[18:10:08] <lightguard_jp> I'm good with that
[18:10:13] <mojavelinux> spec = cdi, ejb, servlet, jca and container variety = ee5, ee6
[18:10:43] <mojavelinux> spec would have versions too, like @RequiresCDI(min = "1.0")
[18:10:45] <mojavelinux> something like that
[18:10:49] <mojavelinux> jpa
[18:11:06] <mojavelinux> we could also do something like solder
[18:11:16] <mojavelinux> @Requires("org.hibernate.Session")
[18:11:19] <mojavelinux> just as an idea
[18:11:25] <mojavelinux> @RequiresClass()
[18:11:35] <aslak> mojavelinux, well, we don't really know that until we run tho
[18:11:37] <mojavelinux> @RequiresRuntimeClass()
[18:11:47] <mojavelinux> true, that might be harder
[18:11:56] <mojavelinux> just brainstorming there, that's not as critical
[18:12:30] <aslak> lets say we provide a API module for this, where is the backing information about what supports what?
[18:12:43] <mojavelinux> I'm just saying arquillian.xml
[18:12:46] <mojavelinux> we don't define it
[18:12:48] <mojavelinux> the user must
[18:12:55] <aslak> ok
[18:12:57] <mojavelinux> because in the end, they define what supports what feature
[18:12:59] <mojavelinux> think about tomcat
[18:13:04] <mojavelinux> I could say @RequiresCDI
[18:13:10] <mojavelinux> I added weld-servlet to tomcat
[18:13:18] <mojavelinux> so this is idea in that I define that my container is compliant
[18:13:27] <aslak> my point
[18:13:32] <mojavelinux> yes, a little more work, but not bad
[18:13:36] <mojavelinux> we could have defaults at the container
[18:13:46] <mojavelinux> so that <supports> has default values
[18:14:00] <mojavelinux> don't worry about the name right now of that element, just speaking in general terms
[18:14:16] <mojavelinux> so if we have built-in annotations, then <supports> could select from those built-in ones
[18:14:37] <aslak> that's where it gets iffy
[18:14:38] <mojavelinux> for instance, jboss as 6 might have @RequiresEJB, @RequiresCDI, @RequiresEE6, etc
[18:14:52] <mojavelinux> this would be an absolute convenience only, and htey can override at will
[18:15:05] <mojavelinux> or
[18:15:11] <mojavelinux> we can leave that out and let that come if requested
[18:15:21] <aslak> in a perfect world we would have one JBoss AS container, with support for 5.0 5.1 6 7 etc..
[18:15:25] <mojavelinux> so perhaps we start with no association
[18:15:31] <aslak> the only reason we have multiple, is because their api change
[18:15:48] <mojavelinux> right, right, good point
[18:15:57] <mojavelinux> again, making the case for <supports>
[18:16:05] <mojavelinux> ah yes
[18:16:10] <mojavelinux> and we can have stereotypes as well
[18:16:18] <mojavelinux> so <supports> can be simpler
[18:16:28] <mojavelinux> like @RequiresEE6 and that adds CDI, EJB, Web, etc
[18:16:46] <mojavelinux> again, we provide some out of the box, user can choose to use them or not
[18:17:04] <mojavelinux> this makes test filtering sooooooooooooooooo much cleaner
[18:17:13] <mojavelinux> because just looking at the few tests we have in seam, it's horrid
[18:17:21] <mojavelinux> we have these profiles with surefire filters based on test names
[18:17:25] <mojavelinux> yucky
[18:17:56] <mojavelinux> can we say...?
[18:18:44] <mojavelinux> #agreed allow tests to be qualified with filter annotations; arquillian.xml associates qualifiers with target container configuration(s)
[18:19:01] <lightguard_jp> +1
[18:19:18] <mojavelinux> and what's interesting about this, is that when you run the test, the unit test framework will report it as skipped
[18:19:32] <mojavelinux> imho, that's good because you don't want the test to just disappear
[18:19:42] <mojavelinux> from the list...it was skipped for a reason, it didn't apply
[18:19:59] <mojavelinux> unfortunately, we can't do much more than that...though I guess we could log why we are skipping the test
[18:20:06] <mojavelinux> I think the skip takes a reason, but I didn't dig into it
[18:21:17] <mojavelinux> I also think this makes it more comfortable for the developer to use container features, because they don't get torn between (should I make this test work on all environments?)
[18:21:52] <mojavelinux> we have this problem in the logging testing in solder...the test can't be run on the embedded container (at the time it has to do with a limitation of the embedded container, but nevermind the details)
[18:22:10] *** lightguard_jp is now known as lightguard_jp_aw
[18:22:52] <mojavelinux> so I get stuck on the fence as to what I'm supporting...but saying @RequiresEE6 just gives me the freedom to move forward and just write the test to target a specific environment
[18:23:34] <mojavelinux> want me to update the jira w/ a comment aslak?
[18:23:39] <aslak> mojavelinux, yea
[18:23:43] <mojavelinux> that way we steer this in the new direction
[18:23:50] <mojavelinux> cool
[18:24:04] <mojavelinux> that's all I had, any other topics?
[18:25:29] <aslak> mojavelinux, not for this meeting i think
[18:25:38] <mojavelinux> excellent...good meeting ;)
[18:25:47] <aslak> oh yea
[18:26:01] <aslak> more on a technical note.. how do we do the repo split
[18:26:25] <mojavelinux> so as not to lose history?
[18:27:10] <mojavelinux> I believe that emmanuel just did that
[18:27:15] <mojavelinux> might want to ping him
[18:27:17] <aslak> i can use filter-branch index-filter and remove everything that should not be in the individual repos, rebases everything so the history is there bu tnot the same
[18:27:27] <aslak> fitler-branch subdirectories only work for one directory
[18:27:47] <mojavelinux> i'd have to research it myself
[18:27:52] <mojavelinux> the other person to talk to is matthew
[18:28:02] <mojavelinux> see if he can give you pointers, he may have something up his sleeve
[18:28:14] <mojavelinux> he is at devnexus with alr right now
[18:28:19] <aslak> yea,
[18:29:04] <aslak> was googling a bit yesterday.. there are multiple ways, but..
[18:29:15] <mojavelinux> matthew is currently on stage :)
[18:29:34] <aslak> call in question?
[18:29:36] <aslak> :)
[18:30:03] <mojavelinux> I can't believe i missed devnexus, wasn't paying attention :)
[18:31:50] <aslak> mojavelinux, there is a mail for you @redhat
[18:37:13] *** lightguard_jp_aw is now known as lightguard_jp
[18:44:25] <mojavelinux> alr is going to come back with git mastery
[18:44:48] <mojavelinux> and sprinkle it over this channel ftw
[18:47:52] *** vtunka has quit IRC
[18:49:18] <aslak> :)
[18:51:39] *** lfryc has quit IRC
[18:54:31] <mojavelinux> i like the feature where you can run a build on each version in history until the build works
[18:54:40] <mojavelinux> forget what the command is though
[19:16:17] <lightguard_jp> bisect
[19:16:22] <lightguard_jp> Killer feature
[19:20:53] <aslak> possible features i just dreams up..  no idea how to implement but.. could be useful: https://gist.github.com/879884
[19:22:30] <aslak> dreamt even
[19:24:18] <lightguard_jp> Pretty cool idea
[19:31:12] <mojavelinux> where's the websphere container?
[19:33:03] <lightguard_jp> didn't know we had on
[19:33:05] <lightguard_jp> noe*
[19:33:06] <lightguard_jp> one*
[19:47:25] *** alesj has joined #jbosstesting
[19:47:52] <mojavelinux> it's in a branch, I found it
[19:48:46] *** alesj has left #jbosstesting
[19:52:04] *** ge0ffrey has quit IRC
[19:56:27] *** jdewinne has joined #jbosstesting
[20:11:08] <mojavelinux> aslak I like when you dream up shit ;)
[20:11:09] <mojavelinux> hehehe
[20:11:43] <mojavelinux> I was just thinking of something along these lines when I read through your release blog...that the ArquillianResource URL really needs to be something that is highly contextual
[20:11:48] <mojavelinux> so this definitely answers that need
[20:13:50] *** ldimaggi has quit IRC
[20:28:55] *** mgoldmann has quit IRC
[20:33:09] <aslak> mojavelinux, if you found the one in my branch that's the old not working on. Gerhard is working on a new updated v.  don't think he has pushed it yet
[20:34:31] <aslak> mojavelinux, and the ArquillianResource is contextual, it's bound to the context you have targeted your @Test. this new 'feature' is to bind that to a different context then the one your in
[20:35:13] <aslak> pushing contextual data for one container/deployment over to another,  from the client..
[20:35:36] *** lightguard_jp has quit IRC
[20:48:42] *** bobmcw has quit IRC
[20:48:58] *** jdewinne has quit IRC
[20:52:55] *** jdewinne has joined #jbosstesting
[20:54:09] *** bobmcw has joined #jbosstesting
[20:54:12] *** jdewinne has left #jbosstesting
[20:56:34] *** bobmcw has quit IRC
[21:05:13] *** rob0t7 has joined #jbosstesting
[21:15:34] *** michaelschuetz has joined #jbosstesting
[21:19:41] *** nickarls has joined #jbosstesting
[21:21:47] <nickarls> hmm, what could make mvn go "There are no tests to run"? There is one present, @RunWith on class and @Test on method. running the 1.0.0.Alpha5 jboss-managed-6 profile
[21:24:20] <mojavelinux> right, that what I was getting at aslak
[22:12:02] *** avogt has joined #jbosstesting
[22:23:46] *** avogt has quit IRC
[22:27:11] *** lightguard_jp has joined #jbosstesting
[22:28:40] *** rob0t7 has quit IRC
[22:34:26] *** jeand has quit IRC
[22:44:51] *** wolfc has quit IRC
[23:25:13] *** ldimaggi has joined #jbosstesting
[23:45:46] *** stuartdouglas has quit IRC
[23:53:39] *** stuartdouglas has joined #jbosstesting





top