I've encountered some nigh-philosophical difficulties with the adoption of Maven, and I was wondering if anyone here could help me talk through them...?
I think Maven is a great idea, and adopting some of the best practices has made my life as the build developer a lot easier. I have been a Maven advocate at work since I started there last year, I've got the books, from O'Reilly and from Mergere. I love and embrace the best practices, but what do I do when our needs fall outside the bounds of Maven's well-established best practices? Here are 3 examples of concepts that my team uses, but fall outside the bounds: 1) Our "unit tests" also include hitting the database. I know that this is usually considered a part of the "integration tests", but we've had long discussions about this and we ended up agreeing that the benefit outweighs the fairly small costs. This only affects the Maven conversation when trying to deal with re-initializing the DB via the Hibernate3 plugin. What a pain in the arse! I have been through every single page of documentation for the plugin, and I think it has a LONG way to go... (Yes, I understand I can volunteer my time to help make it better, but let's keep this discussion framed in the present and near future, ok?) 2) Coverage. Not only do we want to know what our "unit test" coverages are, we want to know what our end-to-end coverage is. For us, end-to-end numbers include harnessing data on coverage from "unit testing" *and* "integration tests", which others may feel more comfortable calling "application tests". (For us, "integration tests" = actually deploying the app,and hitting it with HTMLUnit, etc...) I don't see how we can get these numbers for a n-tier project within the standard Maven multi-module build, and/or with using the Cobertura plugin. 3) While we do try to have our "unit tests" clean up afterthemselves in the database, we do need to seed data into the DB for the "integration tests", so there is actually something there for the "integration tests" to expect. Currently the reporting aspects seem to run seperately (and multiple times) per build, and/or "site" invocation. For tests that don't clean up, running multiple times is not really an option. The kicker is that I have implemented all of these concepts in our current ANT builds. I created a fairly standard-ish build process for our team, modeled on Maven that we tend to call "1/2 Maven". I dealt with #3 by creating another "module" that just has tests using the DAO's to put data into the DB. Then, the later module's tests are written expecting that data. #2 I deal with by creating extra Cobertura-instrumented artifacts, and passing those around. There's also a bit of finagling native to Cobertura involved with getting the coverage numbers off of an app- server. I was able to overcome this with ANT, but would it really work within the standard Maven process? - Nelz --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
