Re: Will these issues be addressed in Maven 2?
(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 ws-client 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
Re: Will these issues be addressed in Maven 2?
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 ws-client 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
Re: Will these issues be addressed in Maven 2?
Chad Woolley wrote: >Hi, > >I'm an avid Maven 1 user, but there are some things that cause me >consistent headaches. I'm wondering if they are being addressed in >Maven 2, and if not, whether a discussion can be opened about them. >This is a general list off the top of my head, I can provide more >description and details as requested. > > Just to be clear - Maven 2 is a rewrite, and not intended to be backwards compatible. A lot of things are completely different, however the principles are still the same. I'll walk through your points below - but our aims are to make solutions that are not hacks, but workable within the rest of the Maven architecture. The reason we don't allow flexibility in some areas is not just stubbornness about best practices, but also because allowing it would mean several plugins either fail to work correctly or get needlessly complicated because they can't make basic assumptions. > >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). >2. Forced and inflexible segregation of app and test classes: > > So you are ok with the separation of sources, but you want all the classes in one directory? They can't go into build.dest, or the packaging goals won't know what to package, and what not to package. I'll see if I can answer your specific use cases. >- 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. >- 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. >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. >- 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. I'm pretty sure the WSDL plugin could do that, and also define a type handler so that you could have ws-client 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. > >Thanks in advance. I'm looking forward to Maven2, keep up the good work. > > Thanks for your interest! Cheers, Brett
Will these issues be addressed in Maven 2?
Hi,
I'm an avid Maven 1 user, but there are some things that cause me
consistent headaches. I'm wondering if they are being addressed in
Maven 2, and if not, whether a discussion can be opened about them.
This is a general list off the top of my head, I can provide more
description and details as requested.
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:
- This causes problems when I want to build artifacts (jars/wars)
for integration testing, or during the build process (for example,
generating test webservice stubs by building a war, deploying in
jetty, and running wsdl2java against it). If I make pregoals to
test:compile to ensure the artifacts are built, then I get multiple
test runs, or even worse, endless loops. I've even gotten one project
so convoluted that it doesn't run the tests at all after a clean, but
will run them if you have not just done a clean (haven't had time to
figure that out yet).
- I have gotten around this by having 'disabletests' and enabletests'
goals, which manually set the maven.test.skip property (preserving
whatever the previous value is). Needless to say, this is painful and
error prone.
2. Forced and inflexible segregation of app and test classes:
- I know this has been the subject of flaming religious wars on the
maven user list, but I'm convinced that there are places where the
"just do it because that's the way it is" line doesn't cut it. Here
are some real cases where I wish I could flexibly control where the
compiled app/test classes are created and accessed:
- First, in the case of AOP where you have circular dependencies
between app and test classes. YES, there are legitimate reasons for
this (see note A below). To get around this, I currently have to
compile EVERYTHING (app and test classes/aspects) to target/classes
(${maven.build.dest}), and then have a custom goal which identifies
the test classes (which correspond to a test source file), and move
them to target/testclasses (${maven.build.dest}). In this case, it
would be simpler to just point maven.build.dest and maven.test.dest to
the same location for a test run, then clean and recompile just the
app classes to maven.build.dest for a deployement (to avoid including
test classes in the deployable).
- Second, in the case of code coverage tools or any other plugin which
instruments/weaves/modifies app classes in a way which you do not want
to deploy (I'm working on the EMMA plugin). For example, if you want
to instrument the classes to generate code coverage during tests, you
have to do a full recompile before deployment to avoid shipping
instrumented classes. The clover plugin gets around this by hacking
on the maven.build.dest value, and forcing the user to call clover:on
and clover:off goals (plugin.jelly, rev 1.28). However, this just
seems kind of ugly, and in need of a cleaner more standardized
approach.
- I realize that these problems may be unsurmountable while still
maintaining backward compatibility with other plugins, but I'm just
wondering if any thought has been put into these types of issues.
3. Single-artifact per-project requirement
- 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).
Thanks in advance. I'm looking forward to Maven2, keep up the good work.
Chad Woolley
NOTE A: Reasons why it is legitimate to have circular dependencies
between app and test classes:
1. There are test aspects that effect the app classes, because they
are overriding behavior to do mocking. Yes, I know jmock/easymock are
preferred, but they don't work for all cases, sometimes AOP is better.
2. There are non-production "stub" classes in the test tree, which
are used to test production aspects in the app tree. This is to unit
test the aspects, and verify that they have the intended effect on a
class, without using an actual production class, which would be more
complicated and mix the concerns of testing the class and testing the
aspect.
