[ https://issues.jboss.org/browse/ARQ-417?page=com.atlassian.jira.plugin.sy... ] Andrew Rubinger commented on ARQ-417: ------------------------------------- {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} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ARQ-417?page=com.atlassian.jira.plugin.sy... ] Karel Piwko edited comment on ARQ-417 at 4/17/11 8:17 AM: ---------------------------------------------------------- Initial prototype present at https://github.com/kpiwko/arquillian-extension-maven-deployer Usage {code} @Deployments(@MavenDeployment(value = "org.jboss.weld.examples.jsf:weld-jsf-login:war:1.1.1.Final", settings = "src/test/resources/settings.xml")) @RunWith(Arquillian.class) public class WarDeploymentTestCase { ... {code} It mirrors all the configuration available for @Deployment methods, such as @Protocol, @TargetsContainer, etc. If extension is activated but no @Deployments annotation is present, it reverts to default behavior. I'm falling into following issue with compilation from cmdline: http://bugs.sun.com/view_bug.do?bug_id=6512707 Somehow works only with OpenJDK, Sun (1.6.0_24) compilation fails. Have to figure it out. was (Author: kpiwko): Initial prototype present at https://github.com/kpiwko/arquillian-extension-maven-deployer Usage {code} @Deployments(@MavenDeployment(value = "org.jboss.weld.examples.jsf:weld-jsf-login:war:1.1.1.Final", settings = "src/test/resources/settings.xml")) @RunWith(Arquillian.class) public class WarDeploymentTestCase { ... {code} It mirrors all the configuration available for @Deployment methods, such as @Protocol, @TargetsContainer, etc. If extension is activated but no @Deployments annotation is present, it reverts to default behavior. I'm falling into following issue with Java 5 compilation from cmdline: http://bugs.sun.com/view_bug.do?bug_id=6512707 Could we make this extension JDK 6 only? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ARQ-417?page=com.atlassian.jira.plugin.sy... ] Karel Piwko commented on ARQ-417: --------------------------------- I managed to make it compile with Sun javac compiler disabling annotation processing in maven-compiler-plugin. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ARQ-417?page=com.atlassian.jira.plugin.sy... ] Aslak Knutsen commented on ARQ-417: ----------------------------------- completely forgotten to check this one.. On top of my head, setting the maven cords+version in source code doesn't sound to useful. Maybe a arq/extension config, replaceDeployment -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira