Olivier, +1 on Maven migration.
Thanks for doing this. I would prefer that we maintain the dual build systems (ant and maven together) until the migration is complete and all committers have successfully transitioned. Also, I think using profiles to group tests with a particular database is a good idea. So mysql profile would include MySQL tests for execution etc. Beyond that I would also suggest that there be a "full" profile that includes all the other profiles that are not activated by default. Thanks, Arvind On Tue, Aug 2, 2011 at 10:41 AM, Andrew Bayer <[email protected]> wrote: > What I've been suggesting for at least the tests is, as Olivier mentioned, > splitting out the non-unit tests into separate modules (a mysql test module, > an oracle test module, etc) so that they can then be specified in a profile > in the top-level POM. That'd let us do "builds" without needing to run all > the tests that require testing against actual DB instances. > > The RAT/Findbugs/Cobertura/Checkstyle are all easy, since there are Maven > plugins for all of 'em. For Eclipse project generation, I think that's > already in place by default. > > The docs will be a little hairy, though. > > A. > > On Tue, Aug 2, 2011 at 10:32 AM, Jonathan Hsieh <[email protected]> wrote: > >> Hey Olivier, >> >> Maven is a good thing -- but this is more than just compiling and unit >> testing the artifact. Let's make sure that we decide which pieces are in >> scope for the mavenization and at least have a story for if we port or not >> port certain build features. Having recently gone through (and still going >> through) an ant -> maven change with Flume, hopefully we can avoid some >> effort and save some time in the process. >> >> Here's a list from perusing the ant build.xml file. >> * Binary build vs release/source build >> * Properties or profiles for test vs perf-test >> * Docs build. Check out this link for how we converted the ant asciidoc >> build to a maven+ant asciidoc build: >> >> https://github.com/cloudera/flume/commit/7cb94837beedf2bdfd0245e0404f8855b259a274 >> . >> This requires external tools. >> * RAT (release audit tool)? >> * Findbugs? >> * Cobertura? >> * Checkstyle? (This has historically been strongly enforced with sqoop) >> * Eclipse project? (flume documented around this problem) >> >> Jon. >> >> On Tue, Aug 2, 2011 at 9:36 AM, Olivier Lamy <[email protected]> wrote: >> >> > BTW First I have to ask if you agree to move to a maven build. >> > Just chatted with Andrew and he has a good idea to move some tests in >> > modules activated tru a profile (yup some tests need a running mysql, >> > oracle instance etc..). >> > >> > Let me know before I break everything :-) >> > >> > 2011/8/2 Olivier Lamy <[email protected]>: >> > > Hi Folks, >> > > >> > > FYI I have started working on a maven build for sqoop (not yet finished >> > :-) ). >> > > I will probably move some unit tests with oracle jdbc driver to a >> > > profile (as this driver is not available in central repo). >> > > >> > > No objections if I move classes to package org.apache.sqoop (instead >> > > of com.cloudera.sqoop) ? >> > > I will fix license headers too (all contains : "Licensed to Cloudera, >> > > Inc. .... ") >> > > >> > > I have added a jenkins build >> > > (https://builds.apache.org/job/Sqoop-jdk-1.6/ ) (hehe @abayer I >> > > couldn't resist to do it before you :P ) >> > > I will add a sonar analysis too. >> > > >> > > Thanks, >> > > -- >> > > Olivier Lamy >> > > Talend : http://talend.com >> > > http://twitter.com/olamy | http://linkedin.com/in/olamy >> > > >> > >> > >> > >> > -- >> > Olivier Lamy >> > Talend : http://talend.com >> > http://twitter.com/olamy | http://linkedin.com/in/olamy >> > >> >> >> >> -- >> // Jonathan Hsieh (shay) >> // Software Engineer, Cloudera >> // [email protected] >> >
