Adam, Your "starting point" below is exactly what I need, and I think it is what others need too.
We must be living in different worlds (planet Maven and planet Earth). I've never worked on -- and can't even remember seeing -- a project with the structure src/main for Java code. Look at how eclipse creates projects for Java and J2EE. The source code goes in src/. Some projects that put it into src/java. (Yes, it is configurable in Eclipse, but src/ is the default.) Why not use the Eclipse defaults? It's the most widely used IDE. (I can't remember where IntelliJ and NetBeans put Java source by default.) Please expand more on your starting points. Some other immediate issues: Building .war files: How do I build a .war if my deployment descriptors are in etc/, conf/, or somewhere else? I use a convention for third party jar files that works like this: lib/vendor_name/product_name/version_number/something.jar How do I tell Gradle to put certain .jar files into WEB-INF/lib, but not others? That should get me started so I can ask better questions. --- On Fri, 6/5/09, Adam Murdoch <[email protected]> wrote: From: Adam Murdoch <[email protected]> Subject: Re: [gradle-user] A naive question To: [email protected] Date: Friday, June 5, 2009, 3:30 PM Dean Schulze wrote: "... I always end up just trying a bunch of stuff that looks like it should be right. Fortunately, within four or five tries I get it right." I share your pain. I haven't been able to figure out how to incorporate gradle into my existing projects either, and I don't have the time to futz with it. It would be really helpful if you could. One of the design goals of the Java plugin is that it must easily adapt to a wide range of project layouts. You should not have to change your layout at all in order to use the Java plugin - though the further you are away from the convention, the more work you will have to do in your build file. From what you've described so far, the Java plugin will handle your layout easily. It would be nice to prove that is the case, and to fix the plugin if it is not. Here's a starting point for you: usePlugin 'java' srcRootName = '' srcDirNames = ['src'] testSrcDirNames = ['src/tests'] compile.exclude 'tests/**' I don't know why gradle has to have this barrier to entry. An experienced Java/Ant developer should be able to pick up a groovy based build system quickly, but for some reason that isn't the case with gradle. Gradle has turned out to be more like Maven than Ant when it comes to learning curve. I wonder if the key to this problem is gradle's convention-based mentality. Most existing projects don't follow gradle's convention. They are all over the place. Refactoring existing projects to meet the gradle/Maven2 conventions is the tail wagging the dog and that will prevent gradle adoption and keep it a niche product. In this way convention based build tools have become an obstacle instead of a useful tool. I believe the problem is documentation. Gradle *is* extremely flexible, by design, and for exactly the reason you mention above. We just need to help you figure out how to tell Gradle where stuff is. You're right when you say we need non-trivial examples. Especially examples that don't follow the gradle/Maven2 convention. I've heard that it is easy to modify the Java plugin for other project structures - unless your tests are in the src/ directory. It sounds like what we need are real examples of modifying the Java plugin to work with some non-conventional project structures, or maybe even examples of how to write out own plugins for existing project structures. You, or anyone else, can help us out here. You can try to get Gradle working with one of your projects and you could then post an example to the wiki. From there, they can end up in the user guide. I also recently tried using the groovy AntBuilder tool as an alternative to Ant itself, but AntBuilder is broken. Instantiating an AntBuilder throws java.lang.NoClassDefFoundError: org/apache/tools/ant/DemuxInputStream http://www.groovy-forum.org/viewtopic.php?p=1128&sid=03569a338075bc1a5881a4eaa4e9222f#1128 This happnes in Eclipse. (Yes I've changed my Ant Home setting to Ant 1.7.1 instead of whatever version of Ant comes bundled with Eclipse.) Maybe it would work outside of Eclipse, but if I can't use it from within Eclipse it's no good for me. Other people have seen this Exception and I've posted it to the groovy forum, but no one responds. There was a Thread about this a couple of months ago where Guillaume Laforge finally asked if the poster if he had found a work around. The poster replied that his work around was to go back to the Java way: http://www.gg3721.com/list/49/74177.html Groovy-based build tools should be good, but they arent. Trying to adopt groovy-based build tools has been a waste of time. Maybe Ant is still the best build tool out there. --- On Thu, 6/4/09, Paul Speed <[email protected]> wrote: From: Paul Speed <[email protected]> Subject: Re: [gradle-user] A naive question To: [email protected] Date: Thursday, June 4, 2009, 12:44 PM Hans Dockter wrote: >> What the User's Guide doesn't explain is that Gradle is a convention-based build system. > > I see this differently. Gradle offers optional plugins that allow for convention based builds. You don't need to use and still have a powerful general purpose build tool. > I haven't looked at the latest docs so I'm only going from the 0.5.2 ones but maybe what is needed are a few non-plug-in, non-trivial examples. I know I can do everything in gradle that I could do in ANT but not being a groovy expert and not knowing ant builder well (or whatever the ant-groovy thing is), I always end up just trying a bunch of stuff that looks like it should be right. Fortunately, within four or five tries I get it right. Sometimes I can find a near enough example in the documentation but I almost have to completely re-read it to pick those gems out. Not trying to be overly critical... -Paul --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
