I agree with using conventions, but putting Java source into src/main is not a convention. It goes into src/ or src/java/ by convention.
I recall reading that it was easy to change that convention, so hopefully the Java plugin can still be used. Here's why it is important to be able to change "conventions". Eclipse has the annoying habit of using different directories for its standard output directory depending on which kind of project it is. Java projects use bin/ and dynamic web projects use build/ by default. That means that your build script has to use different output directories for different Eclipse project types (or you change Eclipse standard output directory for the offending project type). Trying to force the multitude of existing projects to conform to a convention-that-is-not-really-a-convention is going to be a non-starter in many cases. I hope Gradle's support for conventions is flexible enough to accomodate reality. --- On Wed, 5/27/09, Hans Dockter <[email protected]> wrote: From: Hans Dockter <[email protected]> Subject: Re: [gradle-user] Is there an example for migrating a J2EE project from Ant to Gradle? To: [email protected] Date: Wednesday, May 27, 2009, 1:12 AM On May 27, 2009, at 2:16 AM, Dean Schulze wrote: > > Those links are the same material that is in the user guide, which I've read > twice and still don't have a clue about how to use gradle to build a j2ee > project. > > I've written many Ant builds, some very complex, but your documentation > doesn't give me a clue about how to do basic things like compile .java files. > > The problem is that chapter 6 is cryptic. A typical J2EE project has source > files that get compiled with javac, web artifacts like .html and .jsp pages > that simply get moved to a directory in the .war structure, and deployment > descriptors. > > I don't see any of that in your documentation. > > How do I compile my .java files? How do I specify the src/ and output > directories? How do I move artifacts into WEB-INF/lib, etc? > > Ant, for all of its shortcomings is at least intuitive. The attributes and > child elements of <javac>, <jar>, and <war> correspond to the underlying > tools. Ant falls flat on its face, however, with simple things like doing if > ... else... You can't change the value of a property, and lots of other > things. That's really what I'm looking for from gradle. I agree that the user's guide is not saying much about this use case. If this is the way you want to use Gradle, don't use the Java plugin. You still have to read the Java plugin chapter as it describes all the tasks you now have to create by yourself. For example: task compile(type:Compile) { <configuration> } In the Java plugin chapter there is a link to the Javadoc of each task. The API of the task is used to configure the task. The javadoc is not complete for every task yet but many of the properties are self-descriptive. Alternatively you could use the respective Ant tasks. There are many areas where Gradle does not provide a native Gradle task. And we don't have to, as there is the wealth of Ant tasks you can easily use from Gradle. We consider the ant tasks an integral part of Gradle. task myAntTask { ant.move(...) ant.delete(...) // or alternatively ant { move(...) delete(...) } } > > > If chapter 6 is the "normal" way to do things in gradle, then you've made > very straight forward things cryptic. We provide things out of the box. I personally would not call this cryptic. And we are very clear on the website that Gradle has optional build-by-convention functionality. And in fact that is a major reason why many people use Gradle. But Gradle can be used in many ways, from simple Ant scripting to very complex plugin-driven multi-project builds. > If I wanted that I'd use Maven. I wouldn't. - Hans > > > > > > --- On Sat, 5/23/09, Adam Murdoch <[email protected]> wrote: > > From: Adam Murdoch <[email protected]> > Subject: Re: [gradle-user] Is there an example for migrating a J2EE project > from Ant to Gradle? > To: [email protected] > Date: Saturday, May 23, 2009, 12:01 AM > > > > Dean Schulze wrote: >> >> I'd like to start adopting gradle by making a gradle build to parallel the >> Ant build*.xml files that I use for my J2EE projects. >> >> I've looked at the user guide and the java examples that come with gradle, >> but they're not much help. The 2 examples aren't remotely like a typical >> J2EE project, and the user guide isn't much better. >> > > The Java multi-project sample is intended to be a typical J2EE project - it > produces a WAR file and a bunch of JAR files. I'm surprised that you think it > isn't remotely like one. How can we improve things to make this more clear, > do you think? What's different to your J2EE project? > > There's a walk-through of this sample at > http://www.gradle.org/0.6/docs/userguide/tutorial_java_projects.html > > If you don't want to split your build up into multiple projects, you could > use the web application quick start sample. There's an (incomplete) > walk-through at > http://www.gradle.org/0.6/docs/userguide/web_project_tutorial.html > > One thing these samples don't do is produce an EAR task. You can either use > the Zip task, or Ant's Ear task in your build. You might want to have a look > at http://www.gradle.org/0.6/docs/userguide/java_plugin.html#N112B3 for > information about adding archives to a project. > >> Does anyone have an example of how to use Gradle to build typical J2EE >> project - a .ear containing multiple .wars and .jars? >> >> Thanks. >> > -- Hans Dockter Gradle Project Manager http://www.gradle.org --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
