On Thu, May 28, 2009 at 1:15 PM, Dean Schulze <[email protected]>wrote:
> > Most projects use something like this: > > Code goes in > > src/com/... > > Tests go in > > /src/test/func/... > src/test/unit/... > > I don't think most projects do anything of the sort. Every ant-based project I've seen has done something different from every other project. That's why conventions are useful. That said, I think Gradle can handle this (with one minor change probably being required depending what direction you want to go). See the user's guide section 15.4. There it describes the convention properties. If you use the "java" plugin, you get these Maven2 default conventions, but they can be easily changed. In your case, I would think putting this in your build.gradle would work (with the following caveat): convention.srcDirNames = ['.'] // i.e. source lives in the root src directory convention.testSrcDirNames = ['test/func', 'test/unit'] // and test source lives under the test directory I think you might run into problems because your production source code and test source code are colocated (if your production code when into src/main/com/... it would be cleaner). Therefore, when compiling production code javac will probably assume that you have a package called test.func... and test.unit... and will not like that. Of course, you can work around this by not using the "java" plugin. Then you can "hand-code" whatever logic you need. It provides unlimited (or nearly so) customization potential but at the cost of extra work that Gradle can do for you. But if restructuring your code is out of the picture, it's probably your only choice regardless of the build tool you pick. This is because those build tools designed around convention will probably pick the most common convention, and despite your opinion to the opposite, the most common convention is likely the Maven2 convention. Those build tools not designed around convention (like Ant) require you to specify *exactly* what to do anyway. Gradle lets you decide (this is one of it's many strengths). -- John Murph Automated Logic Research Team
