I wouldn't consider Maven 2 to be the convention for anything. There are very few people using Maven. I've never worked on a project that uses Maven. I know of some projects that are thinking of using Maven, but they have never gotten past the initial evaluation phase with Maven.
Ant (which is almost universally used at this point) has no problem with a project structure like src/ com/... test/func/... test/unit/... You just tell the <javac ...> command to exclude test/**/*.* It's good to hear the it is easy to re-configure or override the Java plugin. --- On Thu, 5/28/09, John Murph <[email protected]> wrote: From: John Murph <[email protected]> Subject: Re: [gradle-user] Is there an example for migrating a J2EE project from Ant to Gradle? To: [email protected] Date: Thursday, May 28, 2009, 4:16 PM 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
