>In some ways it would be good if worked only with the DSL reference I was kind of thinking in the same direction, e.g. to push us to grow the DSL reference and update it's content gradually with incoming questions.
Cheers! On Tue, Oct 4, 2011 at 5:53 PM, Adam Murdoch <[email protected]>wrote: > > On 04/10/2011, at 8:42 AM, Szczepan Faber wrote: > > I think so, it would be cool if it worked with the DSL reference :) E.g. if > you need to show a javadoc for some class most likely this should be a part > of a DSL reference anyway. > > > In some ways it would be good if worked only with the DSL reference, and > not the javadocs or groovydocs. > > > Cheers! > > On Tue, Oct 4, 2011 at 1:54 PM, Luke Daley <[email protected]>wrote: > >> Is it worth adding automatic support for javadoc linking? >> >> For example, if you had the following in a post: >> >> org.gradle.api.tasks.Copy#setDestinationDir(java.io.File) >> >> It would become: >> >> <a href=" >> http://gradle.org/current/docs/javadoc/org/gradle/api/tasks/Copy.html#setDestinationDir(java.io.File) >> ">Copy#setDestination(java.io.File)</a> >> >> Or just: >> >> org.gradle.api.tasks.Copy >> >> would become >> >> <a href=" >> http://gradle.org/current/docs/javadoc/org/gradle/api/tasks/Copy.html >> ">Copy</a> >> >> >> One problem with this would be that we don't know what is Groovydoc and >> what is Javadoc. We could maybe use a g: prefix or something along those >> lines if we wanted to differentiate. >> >> It wouldn't take long to implement. Would it be worth it? >> >> -- >> 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 > > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > > -- Szczepan Faber Principal engineer@gradleware Lead@mockito
