[arquillian-issues] [JBoss JIRA] Commented: (ARQ-417) Support maven deployments

Fri Apr 15 07:37:37 EDT 2011

    [ https://issues.jboss.org/browse/ARQ-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595836#comment-12595836 ] 

Andrew Rubinger commented on ARQ-417:
-------------------------------------

>From IRC: 

{code}(06:37:24 AM) aaddriancole: so. on arq ... add a @Maven annotation to the arq createArchive methds
(06:37:41 AM) aaddriancole: with coordinates as params
(06:37:44 AM) ALR: Instead of @Deployment?
(06:37:47 AM) ALR: Yeah, that's hot.
(06:38:03 AM) ALR: ARQ could internally use the MavenResolver API to work out the details.
(06:38:03 AM) aaddriancole: yep... this will force either through instlal or deploy
(06:38:07 AM) aaddriancole: yep
(06:38:18 AM) aaddriancole: so in xml or whatever, you could change to deploy
(06:38:24 AM) aaddriancole: or whatev
(06:38:34 AM) aaddriancole: but the point is that you'd have a releaseable artifact
(06:38:44 AM) ALR: IMO we still have some work to do regarding defining N deployments and *when* they're deployed.
(06:38:52 AM) ALR: But I know aslak has some ideas there
(06:39:05 AM) aaddriancole: yeah. this is a good point
(06:39:07 AM) ALR: Though the @Maven thing may not help with the "current" artifact.
(06:39:15 AM) ALR: We still don't have a great solution for the "current"
(06:39:23 AM) ALR: Because "current" may not be built/installed!
(06:39:31 AM) aaddriancole: well, it could help in a way..
(06:39:35 AM) aaddriancole: here's one idea
(06:39:38 AM) aaddriancole: after tests pass
(06:39:41 AM) aaddriancole: it is published
(06:39:46 AM) aslak: ALR, well, current would be bind to integration-phase and import your builds output
(06:39:56 AM) ALR: aslak: integration-test is *before* install.
(06:40:08 AM) ALR: Yet after package.
(06:40:15 AM) aaddriancole: oh yeah.. well this is a good point
(06:40:23 AM) aslak: ALR, aa, for using the Resolver sure, but you can still import the packaged artifact
(06:40:26 AM) aaddriancole: I mean most projects are running maven so there's overlap on this thing
(06:41:01 AM) ALR: Alternatively, bind the test lifecycle to "validate" or "verify", whichever of those is the really late-running one after install.
(06:41:15 AM) ALR: But no one's gonna wanna put that in the Surefire config in the POM.
(06:41:20 AM) aaddriancole: heh
(06:41:36 AM) aaddriancole: maybe you can have a sneaky arq agent :)
(06:41:46 AM) ALR: aaddriancole: An aside, you been following AS7 at all?
(06:41:47 AM) aslak: true, but i'm not a fan of making arq your build tool either
(06:41:58 AM) ALR: aslak: +1.  Arq ain't a build tool.
(06:42:25 AM) aaddriancole: yeah. but I like the idea of getting tested components releasable
(06:42:32 AM) aaddriancole: even if it isn't a good idea :p
(06:42:47 AM) ALR: aaddriancole: IMO the testsuite would be in a separate module
(06:42:55 AM) ALR: Which would then depend upon the components you're looking to test
(06:43:17 AM) aaddriancole: ALR p.s. haven't been following too closely AS7, except mopping up aslak's puddle of drool related to how fast it is
(06:43:18 AM) ALR: So like the testsuite module would depend on the CDI or EJB module
(06:43:25 AM) ALR: And just deploy the @Maven thing.
(06:43:42 AM) aaddriancole: yeah that's a good way out
(06:43:47 AM) ALR: aaddriancole: It gives us what's shaping up to be the fastest EE runtime.  We're very excited.
(06:44:14 AM) ALR: So yeah, I'd say for best practices: Make an EJB module, a WAR module, whatever.  And the testsuite depends upon and deploys those.
(06:44:28 AM) aaddriancole: sounds good to me
(06:44:37 AM) ALR: In that sense the ARQ test would mimick the *real* thing you're gonna deploy
(06:44:42 AM) ALR: Not a manual ShrinkWrap deployment
(06:44:54 AM) ALR: (Which I still love for its explicit nature and simplicity)
(06:44:56 AM) aaddriancole: yeah well this could be the next layer as well
(06:45:07 AM) aaddriancole: I mean you could extend the integration test classes
(06:45:10 AM) aaddriancole: and override somehow
(06:45:20 AM) aaddriancole: instead of the shrink ones, use maven
(06:45:31 AM) ALR: Why bother extending them
(06:45:33 AM) ALR: ?
(06:45:52 AM) aaddriancole: well, I suppose the point would be being able to rerun the regression tests 
(06:45:52 AM) ALR: When you can just move the int-tests into another module?
(06:46:04 AM) aaddriancole: oh all of them?
(06:46:11 AM) aaddriancole: well... maybe you're right
(06:46:12 AM) ALR: I suppose so.
(06:46:14 AM) ALR: Yeah.
(06:46:20 AM) aaddriancole: just that shrink is still more nimble
(06:46:20 AM) ALR: Unit tests in the component modules.
(06:46:28 AM) ALR: ARQ integration tests in a separate module.
(06:46:36 AM) ALR: And that becomes our recommendation for best practices.
(06:46:45 AM) ALR: For testing real build artifacts
(06:46:45 AM) aaddriancole: you don't have to build dependency graph to test minor bits if you keep some shrink in
(06:46:50 AM) ALR: Otherwise assemble on your own
(06:46:54 AM) ALR: "Microdeployment"
(06:46:57 AM) aaddriancole: not sure yet if the combination is too complicated
(06:47:00 AM) ALR: And you can test those wherever you want.
(06:47:14 AM) ALR: Right, minor bits == microdeployments.
(06:47:16 AM) aaddriancole: unit being microdeployment?
(06:47:18 AM) aaddriancole: yeah
(06:47:21 AM) ALR: No big bang testing.
(06:47:31 AM) ALR: Well, microdeployment is still integration.
(06:47:34 AM) ALR: For instance:
(06:47:40 AM) ALR: Your EAR is the big kahuna.
(06:47:52 AM) ALR: The EAR may have web, EJB, CDI, etc....lots of stuff.
(06:48:02 AM) ALR: But microdeployments, maybe you just test the EJB on its own.
(06:48:19 AM) ALR: I have some slides on this.
(06:48:24 AM) ALR: You're a musician, right
(06:48:24 AM) ALR: ?
(06:48:27 AM) aaddriancole: :)
(06:48:29 AM) aslak: the question on how to run your arq tests on your final deployment has come up, as in you have a bunch of microdeployments that run fine, but you also want to run the same ones on the final deployment. i hvae some thought on it, but not 100%
(06:48:46 AM) ALR: Microdeployments: Test that your phaser pedal, your tuner is working.
(06:48:58 AM) ALR: Full integration: Test that your whole pedalboard is wired up to the amp.
(06:49:28 AM) ALR: aslak: I think this is the missing gap for the "final" deployment case.
(06:49:34 AM) aaddriancole: yeap
(06:49:36 AM) ALR: 1) Make a separate module
(06:49:44 AM) ALR: 2) Define deployment by resolving through Maven.
(06:49:49 AM) ALR: Giving you the "real" stuff.
(06:49:55 AM) ALR: As generated by the build system.
(06:50:45 AM) aslak: sure, but using the same tests
(06:51:04 AM) aaddriancole: well this is the crux of the talk.. should this run the same tests again?
(06:51:05 AM) ALR: Where does @Maven go?
(06:51:15 AM) ALR: Not on a method, I wouldn't think.
(06:51:15 AM) aslak: it can be done by having a separate module, extending a base test that defines the test assertons and in each module define the deployment etc, but it's not very pretty
(06:51:20 AM) ALR: On the test class?
(06:51:38 AM) aaddriancole: well, this is a tricky annotation isn't it
(06:51:40 AM) ALR: @Deployments({@Maven(gav1), @Maven(gav2)})
(06:51:51 AM) aaddriancole: oh
(06:52:18 AM) aslak: would be on the Class i think. seems silly to make a method just for the annotation
(06:52:26 AM) ALR: In this sense, no @Deployment static method in the test class, it'd just be an annotation of deployments upon the test class
(06:52:30 AM) ALR: Right.
(06:52:40 AM) ALR: @Deployments(array)
(06:52:48 AM) aaddriancole: yeah I mean ARQ could make some assumptions right?
(06:52:50 AM) ALR: @Maven is a fully-declarative deployment
(06:52:57 AM) aaddriancole: if @Deployments on class, ignore static
(06:53:03 AM) ALR: And actually...
(06:53:13 AM) ALR: @Maven should have @Deployment as a meta-annotation in it.
(06:53:28 AM) ALR: So that users could put in ANY user-defined special annotation 
(06:53:39 AM) ALR: So long as it was itself @Deployment
(06:53:41 AM) aslak: it's no biggy to impl. the extension point is there. you can override the whole @Deployment method handling using the DeploymentScenarioGenerator. 
(06:53:42 AM) aaddriancole: makes sense.. I mean we may need to have @OSGi at some point
(06:54:06 AM) ALR: @Deployment
(06:54:06 AM) ALR: @interface OSGi{}
(06:54:09 AM) ALR: Same deal.
(06:54:16 AM) aaddriancole: aslak I'm not surprised you have a means of handling this cleanly :){code}

> Support maven deployments
> -------------------------
>
>                 Key: ARQ-417
>                 URL: https://issues.jboss.org/browse/ARQ-417
>             Project: Arquillian
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Configuration
>            Reporter: Adrian Cole
>            Assignee: Karel Piwko
>
> Microdeployments via ShrinkWrap are a nimble deployment mechanism that allows developers to test bytecode skipping the build.  Another usecase is to have ARQ in a CI loop, testing artifacts post-deploy.  For this sort of scenario, it would be useful to reuse test cases from the microdeployments, but have them leveraged against code pulled from maven artifacts published in a prior step.  
> For example, we could have an @Maven annotation which could define the coordinates of an ear file, and place that on a test scenario that performs the war, ejb, cdi, etc tests of from the dependent modules.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira