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 <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. > >Thanks in advance. I'm looking forward to Maven2, keep up the good work. > > Thanks for your interest! Cheers, Brett
