On Apr 6, 2005 5:55 PM, Brett Porter [EMAIL PROTECTED] 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 typews-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
