Just to chime in, many IDEs can "find" your src directories quite easily and I am wondering if that could be a feature in Gradle. I have an open source code generator and the generated java code needs to exist separately from the hand written code. I have been looking at Gradle because I think build files should be scripts and I am a fan of Apache Ivy. I am curious to hear thoughts on an autofind feature. Regards,
David Y. Hodge On Wed, May 27, 2009 at 12:08 PM, Daniel <[email protected]> wrote: > > > 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 >> >> >> >> >
