On Wed, May 27, 2009 at 9:44 PM, Dean Schulze <[email protected]>wrote:
> > 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. As stated in another mail from you it's actually src/main/java. That convention comes from Maven2. Changing from Maven to Maven2 they changed from (src/java, src/test) to (src/main/java, src/test/java). Probably because they realized that otherwise it's difficult to separate additional languages properly. (See the chapter on the groovy plugin, how it extends to another language). So basically every developer with Maven2 experience will feel at home. > > 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 think you're barking up the wrong tree (the only one that I can think of would be 'better documentation' for different users with different backgrounds). Gradle is insanely flexible. I'm sure someone more knowledgeable than me is going to answer your question, but there seem not to be a lot of places in Gradle where you cannot rewire stuff. And you can actually do it _in_ your build script and not going through the hassle of creating a Maven plugin. > 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]<http://mc/[email protected]>> > wrote: > > > > From: Adam Murdoch > > <[email protected]<http://mc/[email protected]> > > > > Subject: Re: [gradle-user] Is there an example for migrating a J2EE > project from Ant to Gradle? > > To: [email protected]<http://mc/[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#N112B3for > 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 > > > >
