(02:05:44 PM) ALR@Freenode: OK, welcome all to round two of the Arquillian Design Kickoff
(02:05:53 PM) ALR@Freenode: Last meeting's notes can be found: http://community.jboss.org/wiki/ArquillianMeetingLog20100215
(02:06:37 PM) mojavelinux [~mojavelin@pool-96-255-2-220.washdc.fios.verizon.net] entered the room.
(02:06:38 PM) ALR@Freenode: We left off on the topic of the User Configuration API
(02:07:01 PM) ALR@Freenode: A way for declarative container-specific properties to be passed along.
(02:07:13 PM) pmuir [~pmuir@redhat/jboss/pmuir] entered the room.
(02:07:14 PM) ALR@Freenode: Some discussion on this has started:
(02:07:18 PM) aslak: ALR, really?
(02:07:53 PM) aslak: ALR, wern't we in the middle of the Deployment spi ?
(02:08:11 PM) aslak: mojavelinux, pmuir heya
(02:08:27 PM) ALR@Freenode: aslak: If we're not done w/ Deployment SPI, sure.
(02:08:31 PM) mojavelinux: hey there...just finished scarfing down lunch. Figured I would need the energy
(02:08:32 PM) ALR@Freenode: I'm going from the notes:
(02:08:32 PM) ALR@Freenode: (03:54:50 PM) pmuir: and have configuration as a first topic for the next meeting
(02:08:52 PM) pmuir: hey, sorry for being late ;-)
(02:09:04 PM) aslak: 03:57:08 PM) aslak: pmuir, i mean, should we continnue through the spi before we discuss how to configure it ?
(02:09:05 PM) pmuir: ALR: aslak then pointed out we needed to finish the SPI walk through
(02:09:06 PM) aslak:
(02:09:19 PM) ALR@Freenode: Ah, carry on.
(02:09:52 PM) pmuir left the room (quit: Client Quit).
(02:10:02 PM) mojavelinux: for the record, I followed through on the action item to redraft the mission statement. After the meeting, just verify that it meets what we agreed on. It is kind of long, but I say let's just roll with the length for now.
(02:10:11 PM) aslak: me and dan ended in a little Deployment SPI naming discussion after the meeting
(02:10:39 PM) mojavelinux: the idea is that we want the pipeline to have names which people recognize and understand and know what they should extend
(02:10:55 PM) aslak: agreed
(02:10:56 PM) mojavelinux: for instead, we had DeploymentEnricher...which I suggested be DeploymentArchivePostProcessor
(02:11:07 PM) ALR@Freenode: Nice
(02:11:27 PM) mojavelinux: and for DeploymentAppender, a simple change to DeploymentArchiveAppender (btw, that comes first)
(02:11:41 PM) mojavelinux: and finally, DeploymentArchivePackager
(02:11:55 PM) mojavelinux: actually, the appender I'm not convinced is the right name
(02:11:58 PM) ALR@Freenode: What's the difference between appender and packager?
(02:12:01 PM) mojavelinux: but I like the other 2
(02:12:28 PM) aslak: ALR, appender is the spi for collecting the archives form the diff modules, packager mix them in a fashion the container can understand
(02:12:36 PM) pmuir [~pmuir@redhat/jboss/pmuir] entered the room.
(02:13:05 PM) lightguard_jp: Would collector or something similar make more sense than appender?
(02:13:34 PM) aslak: sorry, it's the spi the 'provider' has to impl for the packager to include/find them
(02:13:58 PM) aslak: so maybe DeploymentArchiveProvider is better
(02:14:34 PM) mojavelinux: actually, aslak...if you could mention the three SPIs with a very brief description of what they do, that might help direct this conversation
(02:14:39 PM) mojavelinux: just a glossary
(02:15:01 PM) aslak: sure.. i use the 'old' names just not to mix it to much
(02:15:02 PM) mojavelinux: then we can get the names right...or decide order or if we need them all
(02:15:22 PM) mojavelinux: k
(02:15:57 PM) aslak: DeploymentAppender: gives a module the possibility to 'add' a archive to the deployment. Archive<?> createArchive() http://anonsvn.jboss.org/repos/common/arquillian/trunk/spi/src/main/java/org/jboss/arquillian/spi/DeploymentAppender.java
(02:17:13 PM) aslak: DeploymentEnricher: gives a module the possibility to add to the 'Appended' archives. void enrich(List<Archive<?>> archives)
(02:17:31 PM) ALR@Freenode: What's an example of a "module"?
(02:17:53 PM) aslak: DeploymentPackager: creates a deployable Archive for the container to deploy based ont he 'Appender's and 'Enricher's
(02:18:25 PM) mojavelinux: fed into this pipeline is the archive defined in the @Deployment method
(02:18:29 PM) aslak: ALR, arquillian-junit, arquillina-core, container-jboss, cdi/ejb enrichment
(02:18:38 PM) aslak: mojavelinux, correct
(02:18:41 PM) ALR@Freenode: Ah OK, containers.
(02:18:52 PM) aslak: ALR, among others
(02:18:54 PM) ALR@Freenode: -slash framework deployers
(02:19:19 PM) ALR@Freenode: (Which I think in the last meeting we figured were essentially the same thing; lifecycle and deployment objects)
(02:19:36 PM) aslak: ALR, i believe the Arquillian core/spis should be written/configured in a way that anyone can extend them with any functionallty they want..
(02:19:39 PM) mojavelinux: yes, framework deployers are one flavor of a container
(02:20:12 PM) lightguard_jp is now known as lightguard_jp_aw
(02:21:13 PM) mojavelinux: okay, so appender adds an archive
(02:21:20 PM) mojavelinux: enricher adds things to an archive
(02:21:34 PM) mojavelinux: packager wires all these archives together into a single, deployable archive
(02:21:39 PM) mojavelinux: sound about right?
(02:22:39 PM) aslak: and while we're on it.. all of these(besides the @Deployment handler) are context unaware.. to support deployment enhancements to the user defined deployment, we need a spi like void enrich(Archive<?>, Class<?> testcase) to support 'helpers' on the client side. ie like test-harness @BeansXml @EjbJarXml http://anonsvn.jboss.org/repos/weld/cdi-tck/trunk/impl/src/main/java/org/jboss/jsr299/tck/tests/deployment/lifecycle/DeploymentTest.
(02:22:39 PM) aslak: java
(02:22:55 PM) aslak: mojavelinux, yea, sounds right
(02:23:41 PM) mojavelinux: ah
(02:23:46 PM) mojavelinux: so just to give an example
(02:24:21 PM) mojavelinux: the DeploymentAppender for TestNG adds the TestNG classes necessary to execute tests in the remote container...the test runner servlet invokes testng if you recall
(02:24:36 PM) mojavelinux: that's the type of thing being added
(02:24:50 PM) aslak: yea
(02:25:30 PM) aslak: basicly a way of adding stuff to the deployment that is needed for the test to be executed/enhanced on the contianer side
(02:26:02 PM) mojavelinux: the words that are coming to my mind are:
(02:26:07 PM) mojavelinux: SupplamentalDeployment
(02:26:10 PM) mojavelinux: SupportingDeployment
(02:27:18 PM) aslak: as a general description or for a specific spi?
(02:27:59 PM) mojavelinux: just to name the SPI right to capture it's real purpose
(02:28:21 PM) mojavelinux: Appender just seem like I'm tacking on some extra classes, but really I'm tacking on support infrastructure
(02:28:29 PM) mojavelinux: not for the test
(02:28:31 PM) pmuir: for DeploymentAppender?
(02:28:34 PM) mojavelinux: but for the execution environment
(02:28:50 PM) pmuir: I think appender is good name, as it captures you are adding things to the deployment
(02:29:20 PM) aslak: mojavelinux, yea, maybe DeploymentAppender is the client side user deployment enhancer spi.. that is actually meant to append to the users deployment
(02:31:22 PM) mojavelinux: basically, I don't really see that DeploymentAppender has much to do with the deployment that the user is defining...conceptually. It's almost that what the user defines is being added to this broader deployment...and without this nothing would work
(02:32:33 PM) mojavelinux: anyway, just some ideas...maybe the name is fine as it
(02:33:14 PM) ***ALR@Freenode lying down, lurking here though
(02:33:25 PM) aslak: DeploymentUserArchiveAppender, DeploymentSupportArchiveAppender ?
(02:33:31 PM) pmuir: I wonder if it should be ArtifactAppender
(02:33:35 PM) pmuir: as it is appending artifacts
(02:33:38 PM) pmuir: not deployments
(02:33:49 PM) aslak: pmuir, in that case, ArchiveAppender..
(02:33:57 PM) pmuir: ok, yes
(02:34:07 PM) mojavelinux: that's why I suggested DeploymentArchiveAppender earlier
(02:34:14 PM) mojavelinux: which could be shorted to ArchiveAppender
(02:34:19 PM) mojavelinux: I suppose
(02:34:34 PM) mojavelinux: TestExecutionArchiveAppender
(02:34:59 PM) pmuir: mojavelinux: you are kind of naming it after use cases, not what it does
(02:35:01 PM) aslak: mojavelinux, why limit the framework to testing ?
(02:35:05 PM) pmuir: which is my issue with those names
(02:35:44 PM) mojavelinux: ?
(02:36:08 PM) mojavelinux: ah
(02:36:58 PM) pmuir: btw I propose changing DeploymentEnricher's signature to enrich(Archive archive)
(02:36:58 PM) aslak: but we don't have to use all night on these names..
(02:37:08 PM) pmuir: and have it called per archive to enrich
(02:37:10 PM) pmuir: not with a list
(02:37:18 PM) pmuir: (unless there is specific need to see the whole list)
(02:38:08 PM) mojavelinux: so DeploymentArchiveAppender or just ArchiveAppender
(02:38:09 PM) mojavelinux: moving on
(02:38:40 PM) aslak: pmuir, only a hackish need so far.. in the cdi case, it needs to add beans.xml to a EE module.. so instead of being stateful between each call it could get the whole list and just append it to the one it finds.. but not sure it's a good use case
(02:39:20 PM) pmuir: aslak: sounds a bit hacky, and better to just be stateful IMO
(02:39:23 PM) mojavelinux: to restate, I like the name DeploymentArchivePostProcessor here...because enrich is just one thing you can do...heck, you could remove stuff if you wanted
(02:39:46 PM) aslak: mojavelinux, hehe true
(02:40:00 PM) aslak: PostProcessor is a more known name as well
(02:40:09 PM) pmuir: mojavelinux: drop the Deployment from it, and I'm with it
(02:40:15 PM) mojavelinux: fine with me
(02:40:41 PM) pmuir: why not have DeploymentPostProcessor (currently DeploymentAppender) and ArchivePostProcess
(02:40:42 PM) mojavelinux: and yes, I think it should just take one archive too...otherwise you just have extra work and potentially clashing behaviors
(02:40:43 PM) pmuir: or
(02:41:37 PM) aslak: pmuir, DeploymentPostProcessor is not post..
(02:41:49 PM) pmuir: when is it?
(02:41:50 PM) aslak: DeploymentAppender
(02:41:58 PM) aslak: it's during..
(02:42:08 PM) pmuir: right, but when during?
(02:42:14 PM) aslak: packaging
(02:42:26 PM) aslak: before the 'deployment' is created
(02:42:30 PM) mojavelinux: I can see Jason's point about calling it DeploymentCollector
(02:42:43 PM) mojavelinux: because you aren't really appending to anything yet, you are just building up a list
(02:42:52 PM) mojavelinux: the packager ultimately decides what to do with all this stuff, right?
(02:43:12 PM) aslak: yea, but it's the wrong side of it.. it's not the Collector, that is the Packager that 'colelcts' them.. the spi is only a 'provider' of archives that the packager can package
(02:43:16 PM) mojavelinux: or ArchiveCollector
(02:43:18 PM) pmuir: how can something which have a method called create() be called a collectior
(02:43:36 PM) mojavelinux: well, that wouldn't be the method anymore
(02:43:40 PM) mojavelinux: it would be like addArchive
(02:44:13 PM) mojavelinux: actually, you are right in that it isn't a collector, it is really a contributor
(02:44:18 PM) pmuir: yeah
(02:44:19 PM) mojavelinux: the other way around from what I was thinking
(02:44:20 PM) aslak: mm
(02:44:33 PM) mojavelinux: the idea is that you are giving
(02:44:39 PM) mojavelinux: not necessarily appending
(02:44:59 PM) aslak: you are adding/appending to the final deployment
(02:45:27 PM) mojavelinux: right, but append is really "to add to the end of a chain"
(02:45:29 PM) pmuir: right you are appending archives to the deployment
(02:45:46 PM) mojavelinux: we are really adding to a pool
(02:45:57 PM) mojavelinux: I'm parsing words a bit here
(02:45:59 PM) aslak: ArchiveSucker ?
(02:46:10 PM) mojavelinux: right, but the SPI is giving, you are taking
(02:46:13 PM) aslak: no, that would be the same as Collector..
(02:46:38 PM) pmuir: DeploymentPreProcessor then
(02:46:47 PM) germanescobar: hey guys ... but you are not adding/appending, you are just generating ... right?
(02:47:03 PM) germanescobar: the packager will decide if it is included or not?
(02:47:11 PM) aslak: DeploymentPreProcessor sounds to much like your going to change something..
(02:47:20 PM) aslak: germanescobar, yea
(02:47:55 PM) pmuir: aslak: well why not change the whole game a bit
(02:48:50 PM) pmuir: for now, this PreProcessor has only one method Collection<Archive> addToDeployment()
(02:49:56 PM) mojavelinux: okay I throw one more idea out there
(02:50:02 PM) pmuir: and the postProcessor has the the method enrich() as discussed
(02:50:11 PM) mojavelinux: DeploymentSubsidizer
(02:50:23 PM) mojavelinux: kind of like the gov't does to keep US businesses alive
(02:50:29 PM) aslak: hehe
(02:50:56 PM) pmuir: BTW I think having process events in general is a good idea
(02:50:59 PM) aslak: pmuir, ok, merge the two into one?
(02:50:59 PM) pmuir: like CDI has
(02:51:19 PM) germanescobar: can there be more than one DeploymentAppender?
(02:51:24 PM) aslak: germanescobar, yea
(02:51:26 PM) mojavelinux: yep
(02:51:30 PM) pmuir: maybe even we get rid of the DeploymentPostProcessor
(02:51:55 PM) pmuir: actually no
(02:52:15 PM) mojavelinux: I'm kind of liking subsidizer because the whole idea of a subsidy is to add something that makes it survive
(02:52:16 PM) pmuir: aslak: can you merge? I thought they were at different stages in the assembly lifecycle?
(02:52:55 PM) aslak: pmuir, no, same lifecycle.. just different ways of changing/adding
(02:53:09 PM) mojavelinux: aid
(02:53:11 PM) aslak: yes you can merge
(02:53:56 PM) pmuir: so just call it DeploymentProcessor?
(02:54:32 PM) pmuir: actually, maybe we can even take another idea from CDI
(02:54:43 PM) pmuir: or not
(02:54:47 PM) pmuir: ignore that
(02:54:50 PM) aslak:
(02:55:10 PM) aslak: we can of course make it one spi with multiple methods..
(02:55:18 PM) pmuir: yup
(02:55:42 PM) aslak: but if you want them in the same impl, you can just impl them all..
(02:55:52 PM) pmuir: exactly
(02:55:56 PM) pmuir: a no-op is v easy
(02:56:25 PM) pmuir: mojavelinux: wdyt?
(02:56:35 PM) pmuir: or are you still pretending to be an economist?
(02:56:58 PM) mojavelinux: hehehe, you've got to be in the US...if you are real one, it is too depressing
(02:57:02 PM) mojavelinux: um, yeah
(02:57:16 PM) mojavelinux: I was wondering from the start why we need to break it down so much
(02:57:42 PM) mojavelinux: and DeploymentProcessor is quite clear
(02:57:51 PM) aslak: DeploymentProcessor Collection<Archive<?>> addToDeployment(), addToUserDeployment(Archive<?, Class<?> testCase), changeDeployment(Archive<?>) ?
(02:58:26 PM) pmuir: aslak: can you explain again the difference between addToDeployment(), addToUserDeployment
(02:58:51 PM) aslak: addToUserDeployment is really, changeUserDeployment
(02:59:23 PM) aslak: the diff is, you create your own standalone archives you want to append, or you can change the user defined @Deployment by reading annotations of the testcase
(02:59:40 PM) pmuir: so what is the diff between changeDeployment and changeUserDeployment then?
(02:59:50 PM) mojavelinux: how about tweak*Deployment?
(03:00:26 PM) pmuir: mojavelinux: I like it
(03:00:32 PM) pmuir: but I want to understand the diff
(03:00:35 PM) aslak: pmuir, one is changing the deployment all the other deploymentprocessors have added, the other is changing hte user defined deployment
(03:00:43 PM) pmuir: aslak: got it
(03:00:56 PM) pmuir: so it's to do with ordering?
(03:00:57 PM) pmuir: or?
(03:01:04 PM) pmuir: actually still missing the use case for this
(03:01:15 PM) mojavelinux: I think it's just to differentiate it
(03:01:34 PM) mojavelinux: how do you know which archive you have anyway?
(03:01:47 PM) mojavelinux: or is there some other way to figure it out...
(03:01:53 PM) aslak: changeUserDeployment use case: read annotations defined on the test case so we can simplyfy adding @beansXml
(03:02:05 PM) mojavelinux: btw, I like better alter*Deployment or revise*Deployment
(03:02:20 PM) pmuir: aslak: so why have the other changeDeployment at all?
(03:02:23 PM) aslak: changingDeployment: need to change a infrastructure deployment for some reason
(03:02:37 PM) mojavelinux: change seems ambiguous (why are you changing) and typically you are changing to make it better suited
(03:02:52 PM) mojavelinux: alter and revise give an indication of the latter
(03:02:53 PM) lightguard_jp_aw is now known as lightguard_jp
(03:03:16 PM) mojavelinux: so alter, revise or tweak...take your pick
(03:03:17 PM) pmuir: alter is good
(03:03:31 PM) germanescobar: I like DeploymentProcessor for changeDeployment and changeUserDeployment ...
(03:04:01 PM) pmuir: aslak: aslak I'm still not getting the reason for needng both
(03:04:26 PM) mojavelinux: DeploymentProcessor Collection<Archive<?>> addToDeployment(), addToUserDeployment(Archive<?, Class<?> testCase), alterDeployment(Archive<?>), alterUserDeployment(Archive<?>)
(03:04:40 PM) mojavelinux: now just asking why we need both alterUserDeployment and alterDeployment
(03:04:55 PM) mojavelinux: if I'm in alterDeployment, can I know that I have the user's deployment in my hand?
(03:05:22 PM) germanescobar: but I would create another interface for the archive generation ... so, first it is generated, then processed (changed)
(03:05:45 PM) germanescobar: I just like the separation ...
(03:06:42 PM) aslak: i agree.. to me it feels like mixing different usecases into one just because we can
(03:07:21 PM) mojavelinux: Going on what german said, can we do DeploymentPackager followed by DeploymentProcessor?
(03:07:31 PM) mojavelinux: w/ ShrinkWrap, you are dealing w/ nested Archives
(03:07:41 PM) mojavelinux: so there is nothing to say you can't build it first, then modify it
(03:07:52 PM) germanescobar: but packaging is after processing right?
(03:08:09 PM) germanescobar: I would go with ArchiveGenerator ...
(03:08:13 PM) mojavelinux: I guess what I'm saying is that it isn't like we are compiling this thing
(03:08:15 PM) aslak: mojavelinux, you havn't used shrinkwrap that much eh? we're better at adding stuff then modifying
(03:08:21 PM) mojavelinux: turns out ArchiveGenerate is the current name of the class
(03:08:25 PM) mojavelinux: ah
(03:08:41 PM) aslak: mojavelinux, at the moment anyway.. hoping to fix that
(03:08:43 PM) pmuir: hold on
(03:08:49 PM) mojavelinux: so german, addToDeployment is just contributing to the pool then
(03:08:55 PM) mojavelinux: archiveGenerator (or packager) still comes last
(03:08:57 PM) mojavelinux: separate
(03:08:57 PM) pmuir: what is the difference between alterDeployment and alterUserDeployment
(03:09:08 PM) mojavelinux: that's what we are asking
(03:09:14 PM) mojavelinux: let's say I need to alter the user's deployment
(03:09:17 PM) mojavelinux: for some reason
(03:09:25 PM) mojavelinux: if I have alterDeployment(Archive<?>)
(03:09:32 PM) aslak: pmuir, it's altering 'system' rchives vs user archives
(03:09:37 PM) mojavelinux: do I know for a particular invocation that I have the user's archive?
(03:09:43 PM) pmuir: aslak: what is a system archive?
(03:09:52 PM) mojavelinux: I'm still not sure
(03:10:00 PM) mojavelinux: if the answer is yes
(03:10:03 PM) mojavelinux: then we don't need the extra method
(03:10:06 PM) aslak: pmuir, basicly on the user archive it's a spi for helping the user package the archive.. and the system side it's for a specific technology to help run on the container side
(03:10:08 PM) mojavelinux: if the answer is no, then it is our qualifier
(03:10:30 PM) mojavelinux: right, but Pete is asking why can't you just do any of that work in the same method
(03:10:39 PM) pmuir: so these are archives generated by addToDeployment()?
(03:10:47 PM) pmuir: these system archives
(03:10:56 PM) mojavelinux: in the case of alterDeployment, I believe so
(03:11:02 PM) aslak: yes
(03:11:02 PM) mojavelinux: they remain in parallel pipelines
(03:12:19 PM) aslak: i feel they are two different concerns..
(03:12:27 PM) mojavelinux: if it's necessary to keep separate pipelines (I'm not sure yet), then why not have SystemDeploymentProcessor and UserDeploymentProcessor and addArchive() and alterArchive()
(03:13:02 PM) mojavelinux: not sure if that's important
(03:14:21 PM) germanescobar: so, to be clear here ... there are really only those two sources ... what you call "system" archive and the user archive (the one of @Deployment) ...
(03:14:35 PM) germanescobar: and then, they both can be changed ...
(03:14:41 PM) aslak: yae
(03:14:50 PM) germanescobar: and finally, they are packaged and sent to the container ...
(03:14:55 PM) aslak: but for different reasons
(03:15:39 PM) germanescobar: if that's it, I would go with ArchiveAppender, ArchiveProcessor and DeploymentPackager ...
(03:15:43 PM) aslak: germanescobar, sounds right
(03:16:04 PM) pmuir: mojavelinux: for that to be useful, we should establish *who* is going to install these things
(03:16:32 PM) germanescobar: ArchiveAppender - Archive<?> create() ...
(03:16:34 PM) pmuir: aslak: who do you envisage using these calls?
(03:16:42 PM) aslak: germanescobar, ArchiveProcessor handling both changing of the User and System archives ?
(03:16:57 PM) germanescobar: ArchiveProcessor - alter() .. or whatever you want to call it ...
(03:17:00 PM) aslak: pmuir, me
(03:17:12 PM) germanescobar: you would have two different implementation ...
(03:17:19 PM) mojavelinux: can we mark the user's deployment somehow so that the processor can detect it?
(03:17:23 PM) germanescobar: one for altering system archive .. and other for the user archive
(03:17:24 PM) aslak: pmuir, it's container / exension developers
(03:17:26 PM) pmuir: aslak: yes, but what hats are you wearing?
(03:17:35 PM) germanescobar: but the signature should be the same ...
(03:17:45 PM) pmuir: right, but would one developer want all? or just one
(03:17:48 PM) pmuir: i.e. how do they group
(03:18:18 PM) pmuir: yeah, splitting them up is probably a good idea I guess
(03:18:45 PM) pmuir: so which one is DeploymentPackager
(03:18:53 PM) germanescobar: oh, and finally DeploymentPackager ...
(03:19:09 PM) germanescobar: that packages both archives together ...
(03:19:21 PM) germanescobar: and sends the result to the server
(03:19:40 PM) germanescobar: aslak, I'm missing something?
(03:20:16 PM) aslak: pmuir, that's why it's splitted now.. a extension module could provide implementations of all, but ie the ejb test enricher is only interested in the DeploymentAppender spi to append it's container side TestEnrichers... Cdi is interested in both DeploymentAppender and DeploymentEnrichers, appender to add cdi testenrichers for the container side and enricher to add beans.xml to 'some' EE module in the deployment
(03:21:10 PM) aslak: pmuir, and for instance the cdi-tck might only need to provide the DeploymentUserAlter, since it's intension is to help the user simplyfy it's deployment by adding support for @beansXml etc
(03:21:20 PM) pmuir: yeah, I was having momentary brain fart
(03:21:24 PM) pmuir: we need to split them p
(03:21:41 PM) pmuir: I like ArchiveAppender, UserArchiveProcesser, SystemArchiveProcessor
(03:21:56 PM) pmuir: but I'm lost as to what DeploymentPackager does now :-)
(03:22:36 PM) aslak: pmuir, it handles the output of them all and wrappes in up into a ear or war or what ever
(03:22:41 PM) mojavelinux: deployment package currently creates the test.ear
(03:22:43 PM) germanescobar: both archives (system and user) are separate when they get to the DeploymentPackager ... so, the DeploymentPackager "packs" them together
(03:22:53 PM) mojavelinux: obviously that needs to be more generic, but that is what it does today...I believe
(03:23:11 PM) germanescobar: and send them to the container ... which I would split also ...
(03:23:20 PM) pmuir: ok, so it's not a SPI then?
(03:23:34 PM) aslak: pmuir, atm no, but it should be
(03:23:39 PM) pmuir: ok
(03:23:41 PM) aslak: pmuir, only DeploymentAppender exists atm
(03:23:52 PM) pmuir: so I suggest we move on before we go around in another cicrcle
(03:23:57 PM) mojavelinux: yep
(03:23:57 PM) aslak: hehe
(03:23:59 PM) pmuir: lets go with german's names
(03:24:02 PM) mojavelinux: I think we are ready
(03:24:04 PM) pmuir: can we brieflyt
(03:24:26 PM) mojavelinux: we need to fill out the names and descriptions on this page => http://community.jboss.org/wiki/ArquillianDesignOverview
(03:24:48 PM) mojavelinux: The reference guide would have them in more detail...but that page helps us keep on track while developing
(03:25:07 PM) germanescobar: ArchiveGenerator, ArchiveProcessor and DeploymentPackager ...
(03:25:08 PM) aslak: mojavelinux, i will do that in the morning.. writing it down in reference now
(03:25:18 PM) mojavelinux: great
(03:25:49 PM) pmuir: what is the signature of DeploymentPacakager?
(03:26:19 PM) aslak: Archive<?> doStuff() i thinkl
(03:26:42 PM) aslak: sorry; Archive<?> doStuff(Class<?> testCase)
(03:26:42 PM) germanescobar: it must receive somehow both archives
(03:27:08 PM) aslak: pmuir, and not, it's not actually called doStuff..
(03:27:19 PM) aslak: not/no
(03:27:29 PM) aslak: Archive<?> generateArchive(Class<?> testCase)
(03:27:30 PM) pmuir: aslak: ok, so there would be a default, built in, impl
(03:27:34 PM) pmuir: and then you could replace it?
(03:27:46 PM) aslak: pmuir, no, it follows the container
(03:27:54 PM) aslak: i think
(03:28:01 PM) pmuir: beg pardon?
(03:28:05 PM) pmuir: you mean like a dog? or?
(03:28:26 PM) germanescobar: each container has its own DeploymentPackager, right?
(03:28:40 PM) pmuir: ok, i guess write it some wiki page
(03:28:41 PM) aslak: germanescobar, yes and now.. each container type would have one
(03:28:42 PM) pmuir: and I will read it
(03:28:46 PM) aslak: no
(03:29:17 PM) aslak: so a EE Container would reuse the same packager, but Weld-Se should not get a ear for instance so it will provide it's own packager impl
(03:29:27 PM) pmuir: aslak: ok, I got it
(03:29:30 PM) germanescobar: aslak ... right
(03:29:36 PM) pmuir: so actually it comes right at the beginning of the chain?
(03:29:40 PM) pmuir: it's where it all starts?
(03:30:20 PM) germanescobar: no, where it ends ... first the system and user archives are generated ... then processed (changed) and finally, DeploymentPackager packs everything together in a single archive
(03:30:27 PM) aslak: pmuir, it's in the @beforeClass cycle
(03:30:39 PM) aslak: ohh..
(03:30:54 PM) aslak: as it is now, it's both.. The packager is the start and end..
(03:31:41 PM) aslak: The packager is responsible for calling gathering the appenders etc
(03:32:40 PM) germanescobar: aslak, I would delegate the whole process to another component ...
(03:33:10 PM) pmuir: germanescobar: no, it's clearly not at the end
(03:33:19 PM) pmuir: it seems to be responsible for generating the user archive
(03:33:51 PM) pmuir: aslak: ok, but if you split it out to an spi, then you would need another class to tie it all together
(03:33:57 PM) aslak: germanescobar, the reason why it does all is so it can descide based on what type of container it supports what to add or not.
(03:34:00 PM) jesmon left the room (quit: Ping timeout: 260 seconds).
(03:34:16 PM) germanescobar: pmuir, aslka
(03:34:20 PM) germanescobar: ok
(03:34:52 PM) aslak: yea, maybe it should be Archive<?> generateArchive(Collection<Archive<?>> everything) instead..
(03:36:09 PM) mojavelinux: yeah, it has too much responsibility in that current impl
(03:36:21 PM) mojavelinux: it is grabbing the archives, building the user deployment, then assembling
(03:36:24 PM) pmuir: ok
(03:36:31 PM) pmuir: then yes that sig makes more sense :-)
(03:36:39 PM) pmuir: and i understand what it does
(03:36:54 PM) mojavelinux: +1
(03:37:04 PM) aslak: mojavelinux, hehe don't look at the current impl..
(03:37:12 PM) pmuir: ok good
(03:37:19 PM) pmuir: any more on this to discuss?
(03:37:31 PM) germanescobar: but who is responsible of passing the "everything?"
(03:37:51 PM) mojavelinux: we didn't get to the configuration API, which is unfortunate because we are having trouble moving forward w/o that one
(03:38:05 PM) aslak: germanescobar, the 'hardcoded' DeploymentArchiveGenerator/Manager/Something
(03:38:15 PM) pmuir: aka the blackbox :-)
(03:38:21 PM) pmuir: that bit doesn't need to be pluggable...
(03:38:26 PM) aslak: no
(03:38:42 PM) germanescobar: cool ...
(03:38:45 PM) aslak: ok.. next in the chain is of course the DeployableContainer..
(03:39:09 PM) aslak: http://anonsvn.jboss.org/repos/common/arquillian/trunk/spi/src/main/java/org/jboss/arquillian/spi/DeployableContainer.java
(03:39:36 PM) aslak: the only thing im unhappy with there is the ContainerMethodExecutor deploy(Archive<?>)
(03:39:40 PM) mojavelinux: definitely keep this meeting going, but Pete and I will need to juggle with another meeting at the top of the hour
(03:40:10 PM) pmuir: yes
(03:40:11 PM) germanescobar: why don't we keep it to 2 hours like last time?
(03:40:20 PM) pmuir: +1
(03:40:25 PM) pmuir: we can do another next week
(03:40:30 PM) aslak: agree.. two hours is enough
(03:41:02 PM) aslak: yea, we stick to two hours a meeting untill we're through the whole thing.. hehe
(03:41:09 PM) germanescobar: aslak, what is the problem with deploy?
(03:41:26 PM) aslak: http://anonsvn.jboss.org/repos/common/arquillian/trunk/spi/src/main/java/org/jboss/arquillian/spi/ContainerMethodExecutor.java
(03:41:36 PM) aslak: this is how Arquillian core communicates with the contianer
(03:41:47 PM) aslak: so, we ahve Serlvet and local impls atm
(03:41:50 PM) aslak: serlvet
(03:41:55 PM) aslak: servlet
(03:42:22 PM) aslak: jboss-60 can/should support more then just servlet.. it can have jmx, rmi, servlet
(03:42:40 PM) germanescobar: yea, right
(03:42:51 PM) pmuir: aslak: why do you rreturn this CME?
(03:43:47 PM) ***lightguard_jp finally read all the back log
(03:43:51 PM) aslak: pmuir, well.. two reasons.. lack of configuration to know host/port, but also the 'container' should know in what context this deployment can be reached
(03:43:55 PM) pmuir: lightguard_jp: are you dizzy?
(03:44:01 PM) pmuir: aslak: ok
(03:44:05 PM) germanescobar: aslak, but who should decide how to communicate with the server? should the user be aware of this?
(03:44:15 PM) lightguard_jp: pmuir: Yeah, pretty confusing I think I came out of it okay though
(03:44:41 PM) aslak: germanescobar, not sure.. maybe
(03:44:43 PM) pmuir: germanescobar: use case for not just having the container decide?
(03:45:06 PM) germanescobar: pmuir, no, I agree that the container should decide ...
(03:45:30 PM) pmuir: germanescobar: cool :-)
(03:45:46 PM) pmuir: aslak: what are you unhappy about?
(03:45:49 PM) pmuir: it seems ok to me
(03:45:54 PM) germanescobar: +1
(03:46:15 PM) pmuir: I am unsure about the TestMethodExecutor tho?
(03:46:25 PM) aslak: don't remember.. i'll bring it up again if i remember..
(03:46:39 PM) aslak: http://anonsvn.jboss.org/repos/common/arquillian/trunk/spi/src/main/java/org/jboss/arquillian/spi/TestMethodExecutor.java
(03:46:40 PM) mojavelinux: wasn't it not being able to have dependent methods?
(03:47:04 PM) pmuir: mojavelinux: thats a whole nother can of worms
(03:47:14 PM) pmuir: that basically requires some who new layer of integration IMO
(03:47:19 PM) pmuir: I mean level
(03:47:21 PM) pmuir: :-)
(03:47:37 PM) pmuir: ah, Arquillian implements TestMethodExecutor?
(03:47:50 PM) pmuir: or?
(03:47:58 PM) germanescobar: should be the container ...
(03:48:03 PM) aslak: pmuir, yes, it's the arquillian testng/junit test method info abstraction
(03:48:18 PM) pmuir: got it
(03:48:23 PM) pmuir: cool, that is fine then I guess
(03:48:28 PM) germanescobar: mojavelinux, right, I was missing that ... that should be supported
(03:48:29 PM) pmuir: good for an alpha
(03:48:34 PM) pmuir: we can change this api later
(03:48:38 PM) aslak: http://anonsvn.jboss.org/repos/common/arquillian/trunk/testng/src/main/java/org/jboss/arquillian/testng/Arquillian.java
(03:48:43 PM) pmuir: germanescobar: in alpha1000000
(03:48:44 PM) pmuir: perhaps ;-)
(03:48:50 PM) aslak: look in run(IHook...)
(03:50:03 PM) aslak: mojavelinux, that is based on not executing method pr method, but rather execute the whole test case and 'mix' in the results as they come back from the server or something.. diff story
(03:50:17 PM) mojavelinux: yep
(03:50:27 PM) mojavelinux: granularity
(03:50:34 PM) aslak: ok.. so now w'er over on the container side of things
(03:50:40 PM) germanescobar: aslak, so, the container now is started at the beginning of the class? test? and deployed for each method right ...
(03:51:01 PM) aslak: container is started pr test suite, and package/deployed pr test case
(03:51:10 PM) aslak: invoked pr test method
(03:52:03 PM) aslak: germanescobar, http://community.jboss.org/wiki/ArquillianDesignOverview look at the drawing.. max it to see it better
(03:52:41 PM) germanescobar: I think that's ok for now ... however, ALR wanted the user to have more control over the lifecycle ...
(03:52:43 PM) aslak: so. the container is invoked and we're now at the TestRunner spi, added to the deployment by the SystemDeploymentAppender
(03:52:47 PM) lightguard_jp: aslak: The drawing is very good and lays things out nicely. If it's not in the docs, it needs to be *looks at Dan*
(03:53:10 PM) pmuir: whwew is the drawing?
(03:53:14 PM) aslak: lightguard_jp, it's on it's way..
(03:53:23 PM) germanescobar: aslak: ok, clear ...
(03:53:25 PM) aslak: pmuir, http://community.jboss.org/wiki/ArquillianDesignOverview
(03:53:37 PM) aslak: germanescobar, yes, the whole lifecycle thing is a different story as well..
(03:53:55 PM) germanescobar: aslak, I agree ... not for now
(03:54:00 PM) aslak: http://anonsvn.jboss.org/repos/common/arquillian/trunk/spi/src/main/java/org/jboss/arquillian/spi/TestRunner.java
(03:54:06 PM) aslak: http://anonsvn.jboss.org/repos/common/arquillian/trunk/testng/src/main/java/org/jboss/arquillian/testng/TestNGTestRunner.java
(03:54:11 PM) aslak: spi and testng impl
(03:54:36 PM) aslak: pretty much a SPI for the container side of the ContainerMethodExecutor to reinvoke the test framework
(03:55:27 PM) aslak: not sure about the execution mode part, but tiny impl details
(03:55:49 PM) aslak: then we're back in Arquillian core all over again
(03:56:50 PM) aslak: the impl as of now loads up a InContainer container that does nothing when InContainer execution mode.. shoul dfind a nicer way but, impl details
(03:57:01 PM) pmuir: so the TestRunner is executing inside the container?
(03:57:03 PM) pmuir: aslak: yeah
(03:57:08 PM) aslak: yea
(03:57:11 PM) aslak: http://anonsvn.jboss.org/repos/common/arquillian/trunk/impl-base/src/main/java/org/jboss/arquillian/impl/DeployableTestBuilder.java
(03:57:25 PM) pmuir: aslak: ok, sounds good
(03:57:59 PM) aslak: the InContainer container reutrns a InContainer ContainerMethodExecutor that calls the TestEnrichers
(03:58:19 PM) aslak: http://anonsvn.jboss.org/repos/common/arquillian/trunk/spi/src/main/java/org/jboss/arquillian/spi/TestEnricher.java
(03:58:36 PM) aslak: in trunk now, TestEnricher only has void enrich(Object testCase);
(03:59:10 PM) aslak: do what ever you want to it.. examples of Enrichers are, @EJB /@Resource/@Inject injection
(03:59:52 PM) aslak: in a local v. to enrich with test method argument injection i've added: Object[] resolve(Method method);
(04:00:45 PM) aslak: should return a Object array of same size as method.getParameterTypes(), null if this enricher can't handle it.
(04:01:10 PM) aslak: so you can have @Test void myTest(@Ejb MyClass, @Resource resource)
(04:01:26 PM) germanescobar: enrichers would be only injection atm? what else could it be?
(04:01:27 PM) aslak: handled by two diff enrichers
(04:02:24 PM) aslak: i think we also need a test method invocation interceptor of some sort, to handle @TransactionAttribute or other @AroundInvoke style enhancments
(04:02:24 PM) mojavelinux: in this context, the term enricher fits
(04:02:53 PM) aslak: maybe even @Before/@After calls backs would be nice
(04:03:10 PM) pmuir: I think it's generic enough to do anything anyone wants
(04:03:38 PM) aslak: oh yea.. there is a bug now btw.. the enrichment is done on @Test, not on @Before.. so any calls to a @Injected resource in @Bfore results in NPE
(04:03:58 PM) pmuir: ok, lets call this a day
(04:04:04 PM) germanescobar: +1
(04:04:20 PM) aslak: so.. everythoing is clear now ?
(04:05:02 PM) pmuir: aslak: good idea
(04:05:02 PM) pmuir: monday next week work? same time?
(04:05:02 PM) pmuir: tho i may be worse for wear
(04:05:03 PM) pmuir: as I have to entertain ales
(04:05:32 PM) germanescobar: yes, I'll have to digest it a little more but anyway, awesome work aslak!
(04:05:34 PM) aslak: pmuir, good idea?
(04:06:21 PM) aslak: pmuir, next monday sametime is ok by me
(04:07:11 PM) aslak: mojavelinux, and as you might have seen.. we need to get the DeploymentPakcager part up and running before we can do the jetty container
(04:08:00 PM) lightguard_jp: Monday's good
(04:08:01 PM) pmuir: yup
(04:09:42 PM) aslak: ALR, stop log..
(02:05:53 PM) ALR@Freenode: Last meeting's notes can be found: http://community.jboss.org/wiki/ArquillianMeetingLog20100215
(02:06:37 PM) mojavelinux [~mojavelin@pool-96-255-2-220.washdc.fios.verizon.net] entered the room.
(02:06:38 PM) ALR@Freenode: We left off on the topic of the User Configuration API
(02:07:01 PM) ALR@Freenode: A way for declarative container-specific properties to be passed along.
(02:07:13 PM) pmuir [~pmuir@redhat/jboss/pmuir] entered the room.
(02:07:14 PM) ALR@Freenode: Some discussion on this has started:
(02:07:18 PM) aslak: ALR, really?
(02:07:53 PM) aslak: ALR, wern't we in the middle of the Deployment spi ?
(02:08:11 PM) aslak: mojavelinux, pmuir heya
(02:08:27 PM) ALR@Freenode: aslak: If we're not done w/ Deployment SPI, sure.
(02:08:31 PM) mojavelinux: hey there...just finished scarfing down lunch. Figured I would need the energy
(02:08:32 PM) ALR@Freenode: I'm going from the notes:
(02:08:32 PM) ALR@Freenode: (03:54:50 PM) pmuir: and have configuration as a first topic for the next meeting
(02:08:52 PM) pmuir: hey, sorry for being late ;-)
(02:09:04 PM) aslak: 03:57:08 PM) aslak: pmuir, i mean, should we continnue through the spi before we discuss how to configure it ?
(02:09:05 PM) pmuir: ALR: aslak then pointed out we needed to finish the SPI walk through
(02:09:06 PM) aslak:
(02:09:19 PM) ALR@Freenode: Ah, carry on.
(02:09:52 PM) pmuir left the room (quit: Client Quit).
(02:10:02 PM) mojavelinux: for the record, I followed through on the action item to redraft the mission statement. After the meeting, just verify that it meets what we agreed on. It is kind of long, but I say let's just roll with the length for now.
(02:10:11 PM) aslak: me and dan ended in a little Deployment SPI naming discussion after the meeting
(02:10:39 PM) mojavelinux: the idea is that we want the pipeline to have names which people recognize and understand and know what they should extend
(02:10:55 PM) aslak: agreed
(02:10:56 PM) mojavelinux: for instead, we had DeploymentEnricher...which I suggested be DeploymentArchivePostProcessor
(02:11:07 PM) ALR@Freenode: Nice
(02:11:27 PM) mojavelinux: and for DeploymentAppender, a simple change to DeploymentArchiveAppender (btw, that comes first)
(02:11:41 PM) mojavelinux: and finally, DeploymentArchivePackager
(02:11:55 PM) mojavelinux: actually, the appender I'm not convinced is the right name
(02:11:58 PM) ALR@Freenode: What's the difference between appender and packager?
(02:12:01 PM) mojavelinux: but I like the other 2
(02:12:28 PM) aslak: ALR, appender is the spi for collecting the archives form the diff modules, packager mix them in a fashion the container can understand
(02:12:36 PM) pmuir [~pmuir@redhat/jboss/pmuir] entered the room.
(02:13:05 PM) lightguard_jp: Would collector or something similar make more sense than appender?
(02:13:34 PM) aslak: sorry, it's the spi the 'provider' has to impl for the packager to include/find them
(02:13:58 PM) aslak: so maybe DeploymentArchiveProvider is better
(02:14:34 PM) mojavelinux: actually, aslak...if you could mention the three SPIs with a very brief description of what they do, that might help direct this conversation
(02:14:39 PM) mojavelinux: just a glossary
(02:15:01 PM) aslak: sure.. i use the 'old' names just not to mix it to much
(02:15:02 PM) mojavelinux: then we can get the names right...or decide order or if we need them all
(02:15:22 PM) mojavelinux: k
(02:15:57 PM) aslak: DeploymentAppender: gives a module the possibility to 'add' a archive to the deployment. Archive<?> createArchive() http://anonsvn.jboss.org/repos/common/arquillian/trunk/spi/src/main/java/org/jboss/arquillian/spi/DeploymentAppender.java
(02:17:13 PM) aslak: DeploymentEnricher: gives a module the possibility to add to the 'Appended' archives. void enrich(List<Archive<?>> archives)
(02:17:31 PM) ALR@Freenode: What's an example of a "module"?
(02:17:53 PM) aslak: DeploymentPackager: creates a deployable Archive for the container to deploy based ont he 'Appender's and 'Enricher's
(02:18:25 PM) mojavelinux: fed into this pipeline is the archive defined in the @Deployment method
(02:18:29 PM) aslak: ALR, arquillian-junit, arquillina-core, container-jboss, cdi/ejb enrichment
(02:18:38 PM) aslak: mojavelinux, correct
(02:18:41 PM) ALR@Freenode: Ah OK, containers.
(02:18:52 PM) aslak: ALR, among others
(02:18:54 PM) ALR@Freenode: -slash framework deployers
(02:19:19 PM) ALR@Freenode: (Which I think in the last meeting we figured were essentially the same thing; lifecycle and deployment objects)
(02:19:36 PM) aslak: ALR, i believe the Arquillian core/spis should be written/configured in a way that anyone can extend them with any functionallty they want..
(02:19:39 PM) mojavelinux: yes, framework deployers are one flavor of a container
(02:20:12 PM) lightguard_jp is now known as lightguard_jp_aw
(02:21:13 PM) mojavelinux: okay, so appender adds an archive
(02:21:20 PM) mojavelinux: enricher adds things to an archive
(02:21:34 PM) mojavelinux: packager wires all these archives together into a single, deployable archive
(02:21:39 PM) mojavelinux: sound about right?
(02:22:39 PM) aslak: and while we're on it.. all of these(besides the @Deployment handler) are context unaware.. to support deployment enhancements to the user defined deployment, we need a spi like void enrich(Archive<?>, Class<?> testcase) to support 'helpers' on the client side. ie like test-harness @BeansXml @EjbJarXml http://anonsvn.jboss.org/repos/weld/cdi-tck/trunk/impl/src/main/java/org/jboss/jsr299/tck/tests/deployment/lifecycle/DeploymentTest.
(02:22:39 PM) aslak: java
(02:22:55 PM) aslak: mojavelinux, yea, sounds right
(02:23:41 PM) mojavelinux: ah
(02:23:46 PM) mojavelinux: so just to give an example
(02:24:21 PM) mojavelinux: the DeploymentAppender for TestNG adds the TestNG classes necessary to execute tests in the remote container...the test runner servlet invokes testng if you recall
(02:24:36 PM) mojavelinux: that's the type of thing being added
(02:24:50 PM) aslak: yea
(02:25:30 PM) aslak: basicly a way of adding stuff to the deployment that is needed for the test to be executed/enhanced on the contianer side
(02:26:02 PM) mojavelinux: the words that are coming to my mind are:
(02:26:07 PM) mojavelinux: SupplamentalDeployment
(02:26:10 PM) mojavelinux: SupportingDeployment
(02:27:18 PM) aslak: as a general description or for a specific spi?
(02:27:59 PM) mojavelinux: just to name the SPI right to capture it's real purpose
(02:28:21 PM) mojavelinux: Appender just seem like I'm tacking on some extra classes, but really I'm tacking on support infrastructure
(02:28:29 PM) mojavelinux: not for the test
(02:28:31 PM) pmuir: for DeploymentAppender?
(02:28:34 PM) mojavelinux: but for the execution environment
(02:28:50 PM) pmuir: I think appender is good name, as it captures you are adding things to the deployment
(02:29:20 PM) aslak: mojavelinux, yea, maybe DeploymentAppender is the client side user deployment enhancer spi.. that is actually meant to append to the users deployment
(02:31:22 PM) mojavelinux: basically, I don't really see that DeploymentAppender has much to do with the deployment that the user is defining...conceptually. It's almost that what the user defines is being added to this broader deployment...and without this nothing would work
(02:32:33 PM) mojavelinux: anyway, just some ideas...maybe the name is fine as it
(02:33:14 PM) ***ALR@Freenode lying down, lurking here though
(02:33:25 PM) aslak: DeploymentUserArchiveAppender, DeploymentSupportArchiveAppender ?
(02:33:31 PM) pmuir: I wonder if it should be ArtifactAppender
(02:33:35 PM) pmuir: as it is appending artifacts
(02:33:38 PM) pmuir: not deployments
(02:33:49 PM) aslak: pmuir, in that case, ArchiveAppender..
(02:33:57 PM) pmuir: ok, yes
(02:34:07 PM) mojavelinux: that's why I suggested DeploymentArchiveAppender earlier
(02:34:14 PM) mojavelinux: which could be shorted to ArchiveAppender
(02:34:19 PM) mojavelinux: I suppose
(02:34:34 PM) mojavelinux: TestExecutionArchiveAppender
(02:34:59 PM) pmuir: mojavelinux: you are kind of naming it after use cases, not what it does
(02:35:01 PM) aslak: mojavelinux, why limit the framework to testing ?
(02:35:05 PM) pmuir: which is my issue with those names
(02:35:44 PM) mojavelinux: ?
(02:36:08 PM) mojavelinux: ah
(02:36:58 PM) pmuir: btw I propose changing DeploymentEnricher's signature to enrich(Archive archive)
(02:36:58 PM) aslak: but we don't have to use all night on these names..
(02:37:08 PM) pmuir: and have it called per archive to enrich
(02:37:10 PM) pmuir: not with a list
(02:37:18 PM) pmuir: (unless there is specific need to see the whole list)
(02:38:08 PM) mojavelinux: so DeploymentArchiveAppender or just ArchiveAppender
(02:38:09 PM) mojavelinux: moving on
(02:38:40 PM) aslak: pmuir, only a hackish need so far.. in the cdi case, it needs to add beans.xml to a EE module.. so instead of being stateful between each call it could get the whole list and just append it to the one it finds.. but not sure it's a good use case
(02:39:20 PM) pmuir: aslak: sounds a bit hacky, and better to just be stateful IMO
(02:39:23 PM) mojavelinux: to restate, I like the name DeploymentArchivePostProcessor here...because enrich is just one thing you can do...heck, you could remove stuff if you wanted
(02:39:46 PM) aslak: mojavelinux, hehe true
(02:40:00 PM) aslak: PostProcessor is a more known name as well
(02:40:09 PM) pmuir: mojavelinux: drop the Deployment from it, and I'm with it
(02:40:15 PM) mojavelinux: fine with me
(02:40:41 PM) pmuir: why not have DeploymentPostProcessor (currently DeploymentAppender) and ArchivePostProcess
(02:40:42 PM) mojavelinux: and yes, I think it should just take one archive too...otherwise you just have extra work and potentially clashing behaviors
(02:40:43 PM) pmuir: or
(02:41:37 PM) aslak: pmuir, DeploymentPostProcessor is not post..
(02:41:49 PM) pmuir: when is it?
(02:41:50 PM) aslak: DeploymentAppender
(02:41:58 PM) aslak: it's during..
(02:42:08 PM) pmuir: right, but when during?
(02:42:14 PM) aslak: packaging
(02:42:26 PM) aslak: before the 'deployment' is created
(02:42:30 PM) mojavelinux: I can see Jason's point about calling it DeploymentCollector
(02:42:43 PM) mojavelinux: because you aren't really appending to anything yet, you are just building up a list
(02:42:52 PM) mojavelinux: the packager ultimately decides what to do with all this stuff, right?
(02:43:12 PM) aslak: yea, but it's the wrong side of it.. it's not the Collector, that is the Packager that 'colelcts' them.. the spi is only a 'provider' of archives that the packager can package
(02:43:16 PM) mojavelinux: or ArchiveCollector
(02:43:18 PM) pmuir: how can something which have a method called create() be called a collectior
(02:43:36 PM) mojavelinux: well, that wouldn't be the method anymore
(02:43:40 PM) mojavelinux: it would be like addArchive
(02:44:13 PM) mojavelinux: actually, you are right in that it isn't a collector, it is really a contributor
(02:44:18 PM) pmuir: yeah
(02:44:19 PM) mojavelinux: the other way around from what I was thinking
(02:44:20 PM) aslak: mm
(02:44:33 PM) mojavelinux: the idea is that you are giving
(02:44:39 PM) mojavelinux: not necessarily appending
(02:44:59 PM) aslak: you are adding/appending to the final deployment
(02:45:27 PM) mojavelinux: right, but append is really "to add to the end of a chain"
(02:45:29 PM) pmuir: right you are appending archives to the deployment
(02:45:46 PM) mojavelinux: we are really adding to a pool
(02:45:57 PM) mojavelinux: I'm parsing words a bit here
(02:45:59 PM) aslak: ArchiveSucker ?
(02:46:10 PM) mojavelinux: right, but the SPI is giving, you are taking
(02:46:13 PM) aslak: no, that would be the same as Collector..
(02:46:38 PM) pmuir: DeploymentPreProcessor then
(02:46:47 PM) germanescobar: hey guys ... but you are not adding/appending, you are just generating ... right?
(02:47:03 PM) germanescobar: the packager will decide if it is included or not?
(02:47:11 PM) aslak: DeploymentPreProcessor sounds to much like your going to change something..
(02:47:20 PM) aslak: germanescobar, yea
(02:47:55 PM) pmuir: aslak: well why not change the whole game a bit
(02:48:50 PM) pmuir: for now, this PreProcessor has only one method Collection<Archive> addToDeployment()
(02:49:56 PM) mojavelinux: okay I throw one more idea out there
(02:50:02 PM) pmuir: and the postProcessor has the the method enrich() as discussed
(02:50:11 PM) mojavelinux: DeploymentSubsidizer
(02:50:23 PM) mojavelinux: kind of like the gov't does to keep US businesses alive
(02:50:29 PM) aslak: hehe
(02:50:56 PM) pmuir: BTW I think having process events in general is a good idea
(02:50:59 PM) aslak: pmuir, ok, merge the two into one?
(02:50:59 PM) pmuir: like CDI has
(02:51:19 PM) germanescobar: can there be more than one DeploymentAppender?
(02:51:24 PM) aslak: germanescobar, yea
(02:51:26 PM) mojavelinux: yep
(02:51:30 PM) pmuir: maybe even we get rid of the DeploymentPostProcessor
(02:51:55 PM) pmuir: actually no
(02:52:15 PM) mojavelinux: I'm kind of liking subsidizer because the whole idea of a subsidy is to add something that makes it survive
(02:52:16 PM) pmuir: aslak: can you merge? I thought they were at different stages in the assembly lifecycle?
(02:52:55 PM) aslak: pmuir, no, same lifecycle.. just different ways of changing/adding
(02:53:09 PM) mojavelinux: aid
(02:53:11 PM) aslak: yes you can merge
(02:53:56 PM) pmuir: so just call it DeploymentProcessor?
(02:54:32 PM) pmuir: actually, maybe we can even take another idea from CDI
(02:54:43 PM) pmuir: or not
(02:54:47 PM) pmuir: ignore that
(02:54:50 PM) aslak:
(02:55:10 PM) aslak: we can of course make it one spi with multiple methods..
(02:55:18 PM) pmuir: yup
(02:55:42 PM) aslak: but if you want them in the same impl, you can just impl them all..
(02:55:52 PM) pmuir: exactly
(02:55:56 PM) pmuir: a no-op is v easy
(02:56:25 PM) pmuir: mojavelinux: wdyt?
(02:56:35 PM) pmuir: or are you still pretending to be an economist?
(02:56:58 PM) mojavelinux: hehehe, you've got to be in the US...if you are real one, it is too depressing
(02:57:02 PM) mojavelinux: um, yeah
(02:57:16 PM) mojavelinux: I was wondering from the start why we need to break it down so much
(02:57:42 PM) mojavelinux: and DeploymentProcessor is quite clear
(02:57:51 PM) aslak: DeploymentProcessor Collection<Archive<?>> addToDeployment(), addToUserDeployment(Archive<?, Class<?> testCase), changeDeployment(Archive<?>) ?
(02:58:26 PM) pmuir: aslak: can you explain again the difference between addToDeployment(), addToUserDeployment
(02:58:51 PM) aslak: addToUserDeployment is really, changeUserDeployment
(02:59:23 PM) aslak: the diff is, you create your own standalone archives you want to append, or you can change the user defined @Deployment by reading annotations of the testcase
(02:59:40 PM) pmuir: so what is the diff between changeDeployment and changeUserDeployment then?
(02:59:50 PM) mojavelinux: how about tweak*Deployment?
(03:00:26 PM) pmuir: mojavelinux: I like it
(03:00:32 PM) pmuir: but I want to understand the diff
(03:00:35 PM) aslak: pmuir, one is changing the deployment all the other deploymentprocessors have added, the other is changing hte user defined deployment
(03:00:43 PM) pmuir: aslak: got it
(03:00:56 PM) pmuir: so it's to do with ordering?
(03:00:57 PM) pmuir: or?
(03:01:04 PM) pmuir: actually still missing the use case for this
(03:01:15 PM) mojavelinux: I think it's just to differentiate it
(03:01:34 PM) mojavelinux: how do you know which archive you have anyway?
(03:01:47 PM) mojavelinux: or is there some other way to figure it out...
(03:01:53 PM) aslak: changeUserDeployment use case: read annotations defined on the test case so we can simplyfy adding @beansXml
(03:02:05 PM) mojavelinux: btw, I like better alter*Deployment or revise*Deployment
(03:02:20 PM) pmuir: aslak: so why have the other changeDeployment at all?
(03:02:23 PM) aslak: changingDeployment: need to change a infrastructure deployment for some reason
(03:02:37 PM) mojavelinux: change seems ambiguous (why are you changing) and typically you are changing to make it better suited
(03:02:52 PM) mojavelinux: alter and revise give an indication of the latter
(03:02:53 PM) lightguard_jp_aw is now known as lightguard_jp
(03:03:16 PM) mojavelinux: so alter, revise or tweak...take your pick
(03:03:17 PM) pmuir: alter is good
(03:03:31 PM) germanescobar: I like DeploymentProcessor for changeDeployment and changeUserDeployment ...
(03:04:01 PM) pmuir: aslak: aslak I'm still not getting the reason for needng both
(03:04:26 PM) mojavelinux: DeploymentProcessor Collection<Archive<?>> addToDeployment(), addToUserDeployment(Archive<?, Class<?> testCase), alterDeployment(Archive<?>), alterUserDeployment(Archive<?>)
(03:04:40 PM) mojavelinux: now just asking why we need both alterUserDeployment and alterDeployment
(03:04:55 PM) mojavelinux: if I'm in alterDeployment, can I know that I have the user's deployment in my hand?
(03:05:22 PM) germanescobar: but I would create another interface for the archive generation ... so, first it is generated, then processed (changed)
(03:05:45 PM) germanescobar: I just like the separation ...
(03:06:42 PM) aslak: i agree.. to me it feels like mixing different usecases into one just because we can
(03:07:21 PM) mojavelinux: Going on what german said, can we do DeploymentPackager followed by DeploymentProcessor?
(03:07:31 PM) mojavelinux: w/ ShrinkWrap, you are dealing w/ nested Archives
(03:07:41 PM) mojavelinux: so there is nothing to say you can't build it first, then modify it
(03:07:52 PM) germanescobar: but packaging is after processing right?
(03:08:09 PM) germanescobar: I would go with ArchiveGenerator ...
(03:08:13 PM) mojavelinux: I guess what I'm saying is that it isn't like we are compiling this thing
(03:08:15 PM) aslak: mojavelinux, you havn't used shrinkwrap that much eh? we're better at adding stuff then modifying
(03:08:21 PM) mojavelinux: turns out ArchiveGenerate is the current name of the class
(03:08:25 PM) mojavelinux: ah
(03:08:41 PM) aslak: mojavelinux, at the moment anyway.. hoping to fix that
(03:08:43 PM) pmuir: hold on
(03:08:49 PM) mojavelinux: so german, addToDeployment is just contributing to the pool then
(03:08:55 PM) mojavelinux: archiveGenerator (or packager) still comes last
(03:08:57 PM) mojavelinux: separate
(03:08:57 PM) pmuir: what is the difference between alterDeployment and alterUserDeployment
(03:09:08 PM) mojavelinux: that's what we are asking
(03:09:14 PM) mojavelinux: let's say I need to alter the user's deployment
(03:09:17 PM) mojavelinux: for some reason
(03:09:25 PM) mojavelinux: if I have alterDeployment(Archive<?>)
(03:09:32 PM) aslak: pmuir, it's altering 'system' rchives vs user archives
(03:09:37 PM) mojavelinux: do I know for a particular invocation that I have the user's archive?
(03:09:43 PM) pmuir: aslak: what is a system archive?
(03:09:52 PM) mojavelinux: I'm still not sure
(03:10:00 PM) mojavelinux: if the answer is yes
(03:10:03 PM) mojavelinux: then we don't need the extra method
(03:10:06 PM) aslak: pmuir, basicly on the user archive it's a spi for helping the user package the archive.. and the system side it's for a specific technology to help run on the container side
(03:10:08 PM) mojavelinux: if the answer is no, then it is our qualifier
(03:10:30 PM) mojavelinux: right, but Pete is asking why can't you just do any of that work in the same method
(03:10:39 PM) pmuir: so these are archives generated by addToDeployment()?
(03:10:47 PM) pmuir: these system archives
(03:10:56 PM) mojavelinux: in the case of alterDeployment, I believe so
(03:11:02 PM) aslak: yes
(03:11:02 PM) mojavelinux: they remain in parallel pipelines
(03:12:19 PM) aslak: i feel they are two different concerns..
(03:12:27 PM) mojavelinux: if it's necessary to keep separate pipelines (I'm not sure yet), then why not have SystemDeploymentProcessor and UserDeploymentProcessor and addArchive() and alterArchive()
(03:13:02 PM) mojavelinux: not sure if that's important
(03:14:21 PM) germanescobar: so, to be clear here ... there are really only those two sources ... what you call "system" archive and the user archive (the one of @Deployment) ...
(03:14:35 PM) germanescobar: and then, they both can be changed ...
(03:14:41 PM) aslak: yae
(03:14:50 PM) germanescobar: and finally, they are packaged and sent to the container ...
(03:14:55 PM) aslak: but for different reasons
(03:15:39 PM) germanescobar: if that's it, I would go with ArchiveAppender, ArchiveProcessor and DeploymentPackager ...
(03:15:43 PM) aslak: germanescobar, sounds right
(03:16:04 PM) pmuir: mojavelinux: for that to be useful, we should establish *who* is going to install these things
(03:16:32 PM) germanescobar: ArchiveAppender - Archive<?> create() ...
(03:16:34 PM) pmuir: aslak: who do you envisage using these calls?
(03:16:42 PM) aslak: germanescobar, ArchiveProcessor handling both changing of the User and System archives ?
(03:16:57 PM) germanescobar: ArchiveProcessor - alter() .. or whatever you want to call it ...
(03:17:00 PM) aslak: pmuir, me
(03:17:12 PM) germanescobar: you would have two different implementation ...
(03:17:19 PM) mojavelinux: can we mark the user's deployment somehow so that the processor can detect it?
(03:17:23 PM) germanescobar: one for altering system archive .. and other for the user archive
(03:17:24 PM) aslak: pmuir, it's container / exension developers
(03:17:26 PM) pmuir: aslak: yes, but what hats are you wearing?
(03:17:35 PM) germanescobar: but the signature should be the same ...
(03:17:45 PM) pmuir: right, but would one developer want all? or just one
(03:17:48 PM) pmuir: i.e. how do they group
(03:18:18 PM) pmuir: yeah, splitting them up is probably a good idea I guess
(03:18:45 PM) pmuir: so which one is DeploymentPackager
(03:18:53 PM) germanescobar: oh, and finally DeploymentPackager ...
(03:19:09 PM) germanescobar: that packages both archives together ...
(03:19:21 PM) germanescobar: and sends the result to the server
(03:19:40 PM) germanescobar: aslak, I'm missing something?
(03:20:16 PM) aslak: pmuir, that's why it's splitted now.. a extension module could provide implementations of all, but ie the ejb test enricher is only interested in the DeploymentAppender spi to append it's container side TestEnrichers... Cdi is interested in both DeploymentAppender and DeploymentEnrichers, appender to add cdi testenrichers for the container side and enricher to add beans.xml to 'some' EE module in the deployment
(03:21:10 PM) aslak: pmuir, and for instance the cdi-tck might only need to provide the DeploymentUserAlter, since it's intension is to help the user simplyfy it's deployment by adding support for @beansXml etc
(03:21:20 PM) pmuir: yeah, I was having momentary brain fart
(03:21:24 PM) pmuir: we need to split them p
(03:21:41 PM) pmuir: I like ArchiveAppender, UserArchiveProcesser, SystemArchiveProcessor
(03:21:56 PM) pmuir: but I'm lost as to what DeploymentPackager does now :-)
(03:22:36 PM) aslak: pmuir, it handles the output of them all and wrappes in up into a ear or war or what ever
(03:22:41 PM) mojavelinux: deployment package currently creates the test.ear
(03:22:43 PM) germanescobar: both archives (system and user) are separate when they get to the DeploymentPackager ... so, the DeploymentPackager "packs" them together
(03:22:53 PM) mojavelinux: obviously that needs to be more generic, but that is what it does today...I believe
(03:23:11 PM) germanescobar: and send them to the container ... which I would split also ...
(03:23:20 PM) pmuir: ok, so it's not a SPI then?
(03:23:34 PM) aslak: pmuir, atm no, but it should be
(03:23:39 PM) pmuir: ok
(03:23:41 PM) aslak: pmuir, only DeploymentAppender exists atm
(03:23:52 PM) pmuir: so I suggest we move on before we go around in another cicrcle
(03:23:57 PM) mojavelinux: yep
(03:23:57 PM) aslak: hehe
(03:23:59 PM) pmuir: lets go with german's names
(03:24:02 PM) mojavelinux: I think we are ready
(03:24:04 PM) pmuir: can we brieflyt
(03:24:26 PM) mojavelinux: we need to fill out the names and descriptions on this page => http://community.jboss.org/wiki/ArquillianDesignOverview
(03:24:48 PM) mojavelinux: The reference guide would have them in more detail...but that page helps us keep on track while developing
(03:25:07 PM) germanescobar: ArchiveGenerator, ArchiveProcessor and DeploymentPackager ...
(03:25:08 PM) aslak: mojavelinux, i will do that in the morning.. writing it down in reference now
(03:25:18 PM) mojavelinux: great
(03:25:49 PM) pmuir: what is the signature of DeploymentPacakager?
(03:26:19 PM) aslak: Archive<?> doStuff() i thinkl
(03:26:42 PM) aslak: sorry; Archive<?> doStuff(Class<?> testCase)
(03:26:42 PM) germanescobar: it must receive somehow both archives
(03:27:08 PM) aslak: pmuir, and not, it's not actually called doStuff..
(03:27:19 PM) aslak: not/no
(03:27:29 PM) aslak: Archive<?> generateArchive(Class<?> testCase)
(03:27:30 PM) pmuir: aslak: ok, so there would be a default, built in, impl
(03:27:34 PM) pmuir: and then you could replace it?
(03:27:46 PM) aslak: pmuir, no, it follows the container
(03:27:54 PM) aslak: i think
(03:28:01 PM) pmuir: beg pardon?
(03:28:05 PM) pmuir: you mean like a dog? or?
(03:28:26 PM) germanescobar: each container has its own DeploymentPackager, right?
(03:28:40 PM) pmuir: ok, i guess write it some wiki page
(03:28:41 PM) aslak: germanescobar, yes and now.. each container type would have one
(03:28:42 PM) pmuir: and I will read it
(03:28:46 PM) aslak: no
(03:29:17 PM) aslak: so a EE Container would reuse the same packager, but Weld-Se should not get a ear for instance so it will provide it's own packager impl
(03:29:27 PM) pmuir: aslak: ok, I got it
(03:29:30 PM) germanescobar: aslak ... right
(03:29:36 PM) pmuir: so actually it comes right at the beginning of the chain?
(03:29:40 PM) pmuir: it's where it all starts?
(03:30:20 PM) germanescobar: no, where it ends ... first the system and user archives are generated ... then processed (changed) and finally, DeploymentPackager packs everything together in a single archive
(03:30:27 PM) aslak: pmuir, it's in the @beforeClass cycle
(03:30:39 PM) aslak: ohh..
(03:30:54 PM) aslak: as it is now, it's both.. The packager is the start and end..
(03:31:41 PM) aslak: The packager is responsible for calling gathering the appenders etc
(03:32:40 PM) germanescobar: aslak, I would delegate the whole process to another component ...
(03:33:10 PM) pmuir: germanescobar: no, it's clearly not at the end
(03:33:19 PM) pmuir: it seems to be responsible for generating the user archive
(03:33:51 PM) pmuir: aslak: ok, but if you split it out to an spi, then you would need another class to tie it all together
(03:33:57 PM) aslak: germanescobar, the reason why it does all is so it can descide based on what type of container it supports what to add or not.
(03:34:00 PM) jesmon left the room (quit: Ping timeout: 260 seconds).
(03:34:16 PM) germanescobar: pmuir, aslka
(03:34:20 PM) germanescobar: ok
(03:34:52 PM) aslak: yea, maybe it should be Archive<?> generateArchive(Collection<Archive<?>> everything) instead..
(03:36:09 PM) mojavelinux: yeah, it has too much responsibility in that current impl
(03:36:21 PM) mojavelinux: it is grabbing the archives, building the user deployment, then assembling
(03:36:24 PM) pmuir: ok
(03:36:31 PM) pmuir: then yes that sig makes more sense :-)
(03:36:39 PM) pmuir: and i understand what it does
(03:36:54 PM) mojavelinux: +1
(03:37:04 PM) aslak: mojavelinux, hehe don't look at the current impl..
(03:37:12 PM) pmuir: ok good
(03:37:19 PM) pmuir: any more on this to discuss?
(03:37:31 PM) germanescobar: but who is responsible of passing the "everything?"
(03:37:51 PM) mojavelinux: we didn't get to the configuration API, which is unfortunate because we are having trouble moving forward w/o that one
(03:38:05 PM) aslak: germanescobar, the 'hardcoded' DeploymentArchiveGenerator/Manager/Something
(03:38:15 PM) pmuir: aka the blackbox :-)
(03:38:21 PM) pmuir: that bit doesn't need to be pluggable...
(03:38:26 PM) aslak: no
(03:38:42 PM) germanescobar: cool ...
(03:38:45 PM) aslak: ok.. next in the chain is of course the DeployableContainer..
(03:39:09 PM) aslak: http://anonsvn.jboss.org/repos/common/arquillian/trunk/spi/src/main/java/org/jboss/arquillian/spi/DeployableContainer.java
(03:39:36 PM) aslak: the only thing im unhappy with there is the ContainerMethodExecutor deploy(Archive<?>)
(03:39:40 PM) mojavelinux: definitely keep this meeting going, but Pete and I will need to juggle with another meeting at the top of the hour
(03:40:10 PM) pmuir: yes
(03:40:11 PM) germanescobar: why don't we keep it to 2 hours like last time?
(03:40:20 PM) pmuir: +1
(03:40:25 PM) pmuir: we can do another next week
(03:40:30 PM) aslak: agree.. two hours is enough
(03:41:02 PM) aslak: yea, we stick to two hours a meeting untill we're through the whole thing.. hehe
(03:41:09 PM) germanescobar: aslak, what is the problem with deploy?
(03:41:26 PM) aslak: http://anonsvn.jboss.org/repos/common/arquillian/trunk/spi/src/main/java/org/jboss/arquillian/spi/ContainerMethodExecutor.java
(03:41:36 PM) aslak: this is how Arquillian core communicates with the contianer
(03:41:47 PM) aslak: so, we ahve Serlvet and local impls atm
(03:41:50 PM) aslak: serlvet
(03:41:55 PM) aslak: servlet
(03:42:22 PM) aslak: jboss-60 can/should support more then just servlet.. it can have jmx, rmi, servlet
(03:42:40 PM) germanescobar: yea, right
(03:42:51 PM) pmuir: aslak: why do you rreturn this CME?
(03:43:47 PM) ***lightguard_jp finally read all the back log
(03:43:51 PM) aslak: pmuir, well.. two reasons.. lack of configuration to know host/port, but also the 'container' should know in what context this deployment can be reached
(03:43:55 PM) pmuir: lightguard_jp: are you dizzy?
(03:44:01 PM) pmuir: aslak: ok
(03:44:05 PM) germanescobar: aslak, but who should decide how to communicate with the server? should the user be aware of this?
(03:44:15 PM) lightguard_jp: pmuir: Yeah, pretty confusing I think I came out of it okay though
(03:44:41 PM) aslak: germanescobar, not sure.. maybe
(03:44:43 PM) pmuir: germanescobar: use case for not just having the container decide?
(03:45:06 PM) germanescobar: pmuir, no, I agree that the container should decide ...
(03:45:30 PM) pmuir: germanescobar: cool :-)
(03:45:46 PM) pmuir: aslak: what are you unhappy about?
(03:45:49 PM) pmuir: it seems ok to me
(03:45:54 PM) germanescobar: +1
(03:46:15 PM) pmuir: I am unsure about the TestMethodExecutor tho?
(03:46:25 PM) aslak: don't remember.. i'll bring it up again if i remember..
(03:46:39 PM) aslak: http://anonsvn.jboss.org/repos/common/arquillian/trunk/spi/src/main/java/org/jboss/arquillian/spi/TestMethodExecutor.java
(03:46:40 PM) mojavelinux: wasn't it not being able to have dependent methods?
(03:47:04 PM) pmuir: mojavelinux: thats a whole nother can of worms
(03:47:14 PM) pmuir: that basically requires some who new layer of integration IMO
(03:47:19 PM) pmuir: I mean level
(03:47:21 PM) pmuir: :-)
(03:47:37 PM) pmuir: ah, Arquillian implements TestMethodExecutor?
(03:47:50 PM) pmuir: or?
(03:47:58 PM) germanescobar: should be the container ...
(03:48:03 PM) aslak: pmuir, yes, it's the arquillian testng/junit test method info abstraction
(03:48:18 PM) pmuir: got it
(03:48:23 PM) pmuir: cool, that is fine then I guess
(03:48:28 PM) germanescobar: mojavelinux, right, I was missing that ... that should be supported
(03:48:29 PM) pmuir: good for an alpha
(03:48:34 PM) pmuir: we can change this api later
(03:48:38 PM) aslak: http://anonsvn.jboss.org/repos/common/arquillian/trunk/testng/src/main/java/org/jboss/arquillian/testng/Arquillian.java
(03:48:43 PM) pmuir: germanescobar: in alpha1000000
(03:48:44 PM) pmuir: perhaps ;-)
(03:48:50 PM) aslak: look in run(IHook...)
(03:50:03 PM) aslak: mojavelinux, that is based on not executing method pr method, but rather execute the whole test case and 'mix' in the results as they come back from the server or something.. diff story
(03:50:17 PM) mojavelinux: yep
(03:50:27 PM) mojavelinux: granularity
(03:50:34 PM) aslak: ok.. so now w'er over on the container side of things
(03:50:40 PM) germanescobar: aslak, so, the container now is started at the beginning of the class? test? and deployed for each method right ...
(03:51:01 PM) aslak: container is started pr test suite, and package/deployed pr test case
(03:51:10 PM) aslak: invoked pr test method
(03:52:03 PM) aslak: germanescobar, http://community.jboss.org/wiki/ArquillianDesignOverview look at the drawing.. max it to see it better
(03:52:41 PM) germanescobar: I think that's ok for now ... however, ALR wanted the user to have more control over the lifecycle ...
(03:52:43 PM) aslak: so. the container is invoked and we're now at the TestRunner spi, added to the deployment by the SystemDeploymentAppender
(03:52:47 PM) lightguard_jp: aslak: The drawing is very good and lays things out nicely. If it's not in the docs, it needs to be *looks at Dan*
(03:53:10 PM) pmuir: whwew is the drawing?
(03:53:14 PM) aslak: lightguard_jp, it's on it's way..
(03:53:23 PM) germanescobar: aslak: ok, clear ...
(03:53:25 PM) aslak: pmuir, http://community.jboss.org/wiki/ArquillianDesignOverview
(03:53:37 PM) aslak: germanescobar, yes, the whole lifecycle thing is a different story as well..
(03:53:55 PM) germanescobar: aslak, I agree ... not for now
(03:54:00 PM) aslak: http://anonsvn.jboss.org/repos/common/arquillian/trunk/spi/src/main/java/org/jboss/arquillian/spi/TestRunner.java
(03:54:06 PM) aslak: http://anonsvn.jboss.org/repos/common/arquillian/trunk/testng/src/main/java/org/jboss/arquillian/testng/TestNGTestRunner.java
(03:54:11 PM) aslak: spi and testng impl
(03:54:36 PM) aslak: pretty much a SPI for the container side of the ContainerMethodExecutor to reinvoke the test framework
(03:55:27 PM) aslak: not sure about the execution mode part, but tiny impl details
(03:55:49 PM) aslak: then we're back in Arquillian core all over again
(03:56:50 PM) aslak: the impl as of now loads up a InContainer container that does nothing when InContainer execution mode.. shoul dfind a nicer way but, impl details
(03:57:01 PM) pmuir: so the TestRunner is executing inside the container?
(03:57:03 PM) pmuir: aslak: yeah
(03:57:08 PM) aslak: yea
(03:57:11 PM) aslak: http://anonsvn.jboss.org/repos/common/arquillian/trunk/impl-base/src/main/java/org/jboss/arquillian/impl/DeployableTestBuilder.java
(03:57:25 PM) pmuir: aslak: ok, sounds good
(03:57:59 PM) aslak: the InContainer container reutrns a InContainer ContainerMethodExecutor that calls the TestEnrichers
(03:58:19 PM) aslak: http://anonsvn.jboss.org/repos/common/arquillian/trunk/spi/src/main/java/org/jboss/arquillian/spi/TestEnricher.java
(03:58:36 PM) aslak: in trunk now, TestEnricher only has void enrich(Object testCase);
(03:59:10 PM) aslak: do what ever you want to it.. examples of Enrichers are, @EJB /@Resource/@Inject injection
(03:59:52 PM) aslak: in a local v. to enrich with test method argument injection i've added: Object[] resolve(Method method);
(04:00:45 PM) aslak: should return a Object array of same size as method.getParameterTypes(), null if this enricher can't handle it.
(04:01:10 PM) aslak: so you can have @Test void myTest(@Ejb MyClass, @Resource resource)
(04:01:26 PM) germanescobar: enrichers would be only injection atm? what else could it be?
(04:01:27 PM) aslak: handled by two diff enrichers
(04:02:24 PM) aslak: i think we also need a test method invocation interceptor of some sort, to handle @TransactionAttribute or other @AroundInvoke style enhancments
(04:02:24 PM) mojavelinux: in this context, the term enricher fits
(04:02:53 PM) aslak: maybe even @Before/@After calls backs would be nice
(04:03:10 PM) pmuir: I think it's generic enough to do anything anyone wants
(04:03:38 PM) aslak: oh yea.. there is a bug now btw.. the enrichment is done on @Test, not on @Before.. so any calls to a @Injected resource in @Bfore results in NPE
(04:03:58 PM) pmuir: ok, lets call this a day
(04:04:04 PM) germanescobar: +1
(04:04:20 PM) aslak: so.. everythoing is clear now ?
(04:05:02 PM) pmuir: aslak: good idea
(04:05:02 PM) pmuir: monday next week work? same time?
(04:05:02 PM) pmuir: tho i may be worse for wear
(04:05:03 PM) pmuir: as I have to entertain ales
(04:05:32 PM) germanescobar: yes, I'll have to digest it a little more but anyway, awesome work aslak!
(04:05:34 PM) aslak: pmuir, good idea?
(04:06:21 PM) aslak: pmuir, next monday sametime is ok by me
(04:07:11 PM) aslak: mojavelinux, and as you might have seen.. we need to get the DeploymentPakcager part up and running before we can do the jetty container
(04:08:00 PM) lightguard_jp: Monday's good
(04:08:01 PM) pmuir: yup
(04:09:42 PM) aslak: ALR, stop log..
Comments