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 04:18:59 GMT
On Apr 6, 2005 5:55 PM, Brett Porter <brett@apache.org> wrote:
> Chad Woolley wrote:
> >1. Plugins (jar/war/etc) which insist on running tests internally
> >before they will do anything, and don't provide an easy way to
> >override this:
> >
> >
> It sounds like you are using test:test for unit testing and integration
> testing? If so, m2 has a unit test (before packaging) and an integration
> test step (after packaging) - is that what you need? Currently there are
> no implementations for the integration testing, but it's anticipated
> that cactus and other such things would interact at this point (or just
> more junit tests).

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.

> >- First, in the case of AOP where you have circular dependencies
> >
> >
> Ok, I don't exactly what's going on here - I don't use AOP, so I might
> have to defer it to another person.

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.

> >- Second, in the case of code coverage tools or any other plugin which
> >
> >
> 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?

> 
> >3. Single-artifact per-project requirement
> >
> >
> Absolutey, in fact we're being even tougher than before. It is required
> for transitive dependencies to work effectively. However, the
> restriction is really only that you do one thing with a project - you
> can produce >1 artifact, but only in the sense that they are all tied to
> each other.

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.

> 
> >- Will maven2 still enforce the single-artifact-per-project rule?  One
> >place where this causes me problems is on web-service projects, where
> >I would like to generate a WAR, and also generate a jar or other
> >artifact containing web service stubs.  Multiproject is not really
> >applicable in this case, because the stubs are used both internally
> >(for integration testing of the webservice webapp itself) and as a
> >deployable (published in a jar for other projects which will be
> >clients of the webservice).
> >
> >
> This sounds a lot like the ejb use case where an EJB is produced, and so
> is an EJB-client JAR with the client stubs. In this case, one project
> produces both.

Yes, this sounds a lot like my situation.

> 
> 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.

> 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?

Thanks for the response,
Chad

Mime
View raw message