Hi Cedric, On Mon, Dec 7, 2009 at 11:24 AM, Hans Dockter <[email protected]> wrote:
> Cedric had some issues with out mailing list, so I'm posting this on his > behalf: > > ------------------ > Hello Gradle users, > > As some of you know, I recently tried to convert my build ( > http://testng.org) to Gradle but I didn't make much progress after a few > hours, despite reading all the docs and mailing-list messages I could find, > so I thought I'd share my experience here. > > First of all, I have to say that I'm very impressed with the effort that > went into the user guide. The doc looks very professional and thorough, and > I especially like the "one big web page" format (I did the exact same thing > with TestNG and users absolutely love the fact they can do a search in the > entire documentation so quickly or that they can print it and take it home > with them). > > Having said that, I think this particular document is not a good > introduction for a couple of reasons: > > * It doesn't emphasize migration. I'm guessing most people who will > come across this document will want to convert an existing build (most > likely ant and sometimes Maven) to Gradle. This should be the first > chapter. > This is an important point we need to address. > * It's not high level enough. I've read the whole document maybe one > and half times now and I'm still not sure what the concepts and building > blocks are, what the difference between a module an a dependency is, what > names are reserved, which ones are examples, etc... I don't want to migrate > my build by doing copy/pastes that I don't understand, because this > guarantees that in a few months from now, I still won't understand how my > build works, much less how to modify it. I will only switch to a new build > system if I can completely understand how it works, philosophically and > technically. > Again I completely see your point. In particular regarding the philosophy. A high level article of the Gradle concepts and philosophy (together with examples) is work in progress. > > TestNG's build is pretty straightforward (although interestingly, Maven > can't achieve it, I can go into details if you're curious) and the two > things that I needed to get started are: > > * How do I change the default source directories? > I guess the best example would be to use your testng layout. Adam or me will post this sometimes today. > * How do I configure my classpath to point to local jar files? > compile files('somepath_absolute_or_relative_to_project_root') compile files(fileTree('lib').matching { include '**/*.jar', '**.*.zip' } > > I ended up reading about variables called srcDirNames or something such, > none of which are mentioned in that doc anywhere. I still wasn't able to > get these variables to work properly, by the way, so I'm still in the dark > as to how to do this. And I still don't know how to add local jar files to > my compile and runtime classpath. I'm guessing this involves specifying > artifacts with some file:/// tricks or something like that, but I couldn't > find any example anywhere (not just in your doc, I really mean anywhere in > my web searches). > > My ant build has been working flawlessly for years and I'm very happy with > it but I'm also always trying to streamline things and I think Gradle has > the power to trim down my build files considerably, so I'd really like to > get this working and see if I would be happy with the final result. > I agree, your ant build is well in shape. But you will see just with the upcoming source layout example that the Gradle build is more concise and expressive about your project structure. The incremental build feature is also a very nice to get used to (trunk feature). There is a lot of other stuff. Concurrent unit test execution is probably nothing you are in need of ;). BTW: Could you use the new TestNG scheduling engine also for running junit tests? Cheers, Hans
