(in future, please reply to dev@maven.apache.org as we are going to close this list - thanks)
Chad Woolley wrote: >Hmm, this may be what I'm talking about. My problem is that I >manually call war/jar goals during the build process (to generate >artifacts for integration testing), and these goals automatically run >the tests, and there's nothing to do short of hacking the plugin or >hacking the maven.test.skip property. > > Right - but in m2, the integration tests that require those files are run -after- they are generated. So: m2 integration-test would be equivalent to m2 [normal compile/resource goals] surefire:test war:war [goal to run integration tests] >OK, but I think this might be something to think about. Maybe >"circular" dependency is the wrong word, but in general, I'm talking >about situations where the standard "compile app to target/classes, >then compile tests to target/testclasses" doesn't work. > > Right - I'd like to get detailed examples of anything where it doesn't so we can work through how they should work. I don't understand AOP, but I should probably learn :) We don't have an aspectj plugin for m2 yet - if you are interested in helping out we'd welcome it. >>Yes, code coverage tools would grab the existing target/classes, modify >>them to say target/classes-emma and run the tests using that. We've got >>a fairly good idea for how this will all work, but it's not implemented yet. >> >> > >Cool. Any documentation links on this yet? > > There were some things sent to the list a while back - I'll try and get it together and updated again shortly. So no, nothing really up to date. >When you say "tied to each other", do you mean all versioned >identically at the same time? If so, then that works fine for me. > > Yes, and deployed as such. >>I'm pretty sure the WSDL plugin could do that, >> >> > >What WSDL plugin are you talking about? The only one I see related to >webservices is the Axis one on sourceforge. > > It was a theoretical example :) Something like that plugin, written for m2. >>and also define a type >>handler so that you could have <type>ws-client</type> and get the second >>JAR. Importantly, there'd be one project and the artifacts would always >>be deployed together. >> >>I think it's most likely that you'd have to produce two JARs though (the >>server side code and the client side code), and have the WAR separate. >> >> > >Not sure what you mean here. The main point is that the client jar >(generated from the running war using wsdl2java) would be available >for use during integration testing, as well as for deployment. Would >this be possible? > > If it were generated from the current project, yes, it will be available to integration testing and deployment. If you were to separate your WSDL generation into a separate JAR that deployed the server and client code, you could also use these from a different WAR project too. Cheers, Brett
