Uhm, I don't like magic behind the scenes too much. Makes it awfully annoying to debug when something doesn't work. But I adore helpful failure messages. So if it would fail with something like:
Gradle detected that the build file project-dir/subproject-dir:build.gradle references (by convention, see http://www.gradle.org/doc/userguide...) a source directory (in file project-dir/subproject-dir/build.gradle) sourcesDir = src/main/java but we didn't find any sources to compile. Either disable compilation with (in file project-dir/subproject-dir/build.gradle add) compile.enabled = false or use the sources that Gradle found with (in file project-dir/subproject-dir/build.gradle add) sourcesDir = 'src/' That would rock my world. Cheers, Daniel On Wed, May 27, 2009 at 11:40 PM, David Hodge <[email protected]> wrote: > 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 >>> >>> >>> >>> >> >
