maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chad Woolley <thewoolley...@gmail.com>
Subject Re: Will these issues be addressed in Maven 2?
Date Mon, 11 Apr 2005 22:33:51 GMT
Ok this all sounds good!  I'll send any future posts to the dev list.

Thanks,
Chad

On Apr 10, 2005 9:42 PM, Brett Porter <brett@apache.org> wrote:
> (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
> 
>

Mime
View raw message