Thanks Luke for resurrecting it. Recently, I paired few times on challenges
with generated sources. It would be cool to have the "gradle & generated
sources" documented (along with some good patterns related src generation -
I've seen quite mad solutions).

Regarding your idiomatic example: From the standpoint of IDE integration,
it might be better to wire the generated source dir via:

sourceSets.main.java.srcDir generateSources.outputDir

However, we still need an explicit dependency between tasks:

compileJava.dependsOn generateSources

>adding an explicit dependency to the compileJava task which doesn't seem
right. I'd like to file a bug for this

I agree completely. We did some work not so long time ago around the
generated resources, it's simple, nevertheless very handy, eg:

sourceSets.main.output.dir(generatedResources, buildBy:
'generateMyResources')

Cheers!

On Sun, Oct 30, 2011 at 2:51 AM, Luke Daley <[email protected]>wrote:

> Resurrecting this due to
> http://forums.gradle.org/gradle/topics/source_code_generation
>
> Actually, my example doesn't work.
>
> > sourceSets {
> >       main {
> >               srcDir someGenerationTask.outputs.files
> >       }
> > }
>
> This doesn't work because the implementation for DefaultSourceDirectorySet
> effectively drops any “buildable” information from incoming locations.  At
> the moment I don't think there is anyway to solve this without adding an
> explicit dependency to the compileJava task which doesn't seem right. I'd
> like to file a bug for this.
>
> This is the most idiomatic example I could come up with that works:
>
>   apply plugin: "java"
>
>   task generateSources {
>     outputDir = file("$buildDir/generated-src")
>     outputs.dir outputDir
>
>     doFirst {
>       outputDir.exists() || outputDir.mkdirs()
>       new File(outputDir, "Generated.java").write("public class Generated
> {}")
>     }
>   }
>
>   compileJava.source generateSources.outputs.files, sourceSets.main.java
>
>
> I think the best thing we could do would be to make adding a Buildable
> file collection to a SourceDirectorySet make the SourceDirectorySet
> “inherit” the buildable information from the incoming file collection. This
> would make my original example work.
>
> On 19/07/2011, at 9:49 AM, Hans Dockter wrote:
>
> > You are right. I haven't thought about it properly.
> >
> > Thanks
> >
> > Hans
> >
> > --
> > Hans Dockter
> > Founder, Gradle
> > http://www.gradle.org, http://twitter.com/gradleware
> > CEO, Gradleware - Gradle Training, Support, Consulting
> > http://www.gradleware.com
> >
> >
> > On Mon, Jul 18, 2011 at 5:23 PM, Luke Daley <[email protected]>
> wrote:
> >
> > On 19/07/2011, at 4:52 AM, Hans Dockter wrote:
> >
> >> At the moment if you need to generate sources, you typically create a
> dependencies between the compile task of the java source set and the task
> that generates the sources. Our antlr plugin does the same. It is a very
> common use case in the enterprise. I think a SourceSet functionality like
> we have for generate resources would be a much nicer solution.
> >>
> >> Thoughts?
> >
> > I think source generation is slightly different in that it's likely to
> be more complex. I am also not sure what benefit it would have over…
> >
> > sourceSets {
> >       main {
> >               srcDir someGenerationTask.outputs.files
> >       }
> > }
> >
> > I have to admit that I don't know how this plays with directories vs
> files. That is, how the output of a task needs to be structured to spit out
> a root “srcDir”.
> >
> > --
> > Luke Daley
> > Principal Engineer, Gradleware
> > http://gradleware.com
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >   http://xircles.codehaus.org/manage_email
> >
> >
> >
>
> --
> Luke Daley
> Principal Engineer, Gradleware
> http://gradleware.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>


-- 
Szczepan Faber
Principal engineer@gradleware
Lead@mockito

Reply via email to