You don't have to write ext.FancyTask because the Gradle code that is
processing the script is checking the Extra properties to resolve property
values
(http://www.gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html)
--
John Engelman
On Wednesday, January 8, 2014 at 9:36 PM, Xavier Ducrohet [via Gradle] wrote:
> I find groovy to a bit too flexible sometimes, and this seems like another
> case of it.
>
> Why doesn't gradle require to write this (in build.gradle):
> task fancyTask(type: ext.FancyTask) {}
>
> I'm seeing quite a few users get bitten because Gradle is being too smart and
> sometimes hides what is really going on. Is this specific to Gradle or
> something about Groovy handling custom DSL. Would be possible to enable a
> more strict mode.
>
> Two examples:
>
> a developer wanted a flavor specific flavor and wrote
>
> productFlavors {
> pro {
> dependencies {
> compile project(':lib')
> }
> }
> }
>
>
> Of course 'dependencies' is not a properties for the flavor object, but of
> the project and gradle accept this and silently does the right thing.
>
> Another case was a developer writing something like this:
>
> def getVersionCode() {
> ...
> }
>
> android.defaultConfig {
> versionCode getVersionCode()
> }
>
> In this case it looks right. Except that getVersionCode() is actually the
> getter of the versionCode prop on the defaultConfig object so it does
> nothing. While it's not really groovy being too flexible, it's another case
> of deal with the scope of execution for each closure. A "strict" mode where
> Groovy/Gradle complains that there's two conflicting resolution would be
> good.
>
> Anyway, sorry for the rant and going off topic, I find there is a bit too
> much magic happening in Gradle files regarding scopes and visibility of
> different items in different cases and it's really difficult to keep track of
> them and, more importantly, to troubleshoot them when what is expected is not
> happening.
>
> To resolve my original question, we managed to get a buildSrc folder in the
> right place and we're moving all our logic there, which makes things a lot
> nicer imo.
>
> thanks!
>
>
> On Wed, Jan 8, 2014 at 12:34 PM, Luke Daley <[hidden email]
> (/user/SendEmail.jtp?type=node&node=5712182&i=0)> wrote:
> >
> > On 7 Jan 2014, at 6:37 pm, Xavier Ducrohet <[hidden email]
> > (/user/SendEmail.jtp?type=node&node=5712182&i=1)> wrote:
> >
> > > Hi,
> > >
> > > trying to refactor some internal code, I'm running into another issue
> > > with 'apply from'
> > >
> > > There's a foo.gradle file that only declares a new class extending
> > > DefaultTask, and we're trying to use it from another gradle file after
> > > doing 'apply from: foo.gradle' but it doesn't find the type.
> > >
> > > Is there a way to make this work?
> >
> > Kind of.
> >
> > Classes defined in script plugins are not visible to their “parents”. They
> > are not on the compile classpath, because script plugin application happens
> > at runtime. Moreover, class references in Groovy are not actually dynamic.
> > So, you have to manually export the class literal across classloader
> > boundaries, making a variable of type class available. This is usually done
> > as a project extra property
> >
> > build.gradle:
> > apply from: "someTaskDefinition.gradle"
> > task fancyTask(type: FancyTask) {}
> >
> > someTaskDefinition.gradle:
> > class FancyTask extends DefaultTask {}
> > ext.FancyTask = FancyTask
> >
> >
> > In build.gradle it looks like you're using a class literal, but it's a
> > project property whose value is a class.
> >
> > --
> > Luke Daley
> > Principal Engineer, Gradleware
> > http://gradleware.com
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> > http://xircles.codehaus.org/manage_email
> >
> >
>
>
>
> If you reply to this email, your message will be added to the discussion
> below:
> http://gradle.1045684.n5.nabble.com/declaring-a-class-in-a-gradle-file-and-using-it-through-apply-from-tp5712170p5712182.html
>
> To start a new topic under gradle-dev, email
> ml-node+s1045684n1436218...@n5.nabble.com
> (mailto:ml-node+s1045684n1436218...@n5.nabble.com)
> To unsubscribe from gradle-dev, click here
> (http://gradle.1045684.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=1436218&code=am9obi5yLmVuZ2VsbWFuQGdtYWlsLmNvbXwxNDM2MjE4fDIyMTUyNjEzNQ==).
> NAML
> (http://gradle.1045684.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml)
>
--
View this message in context:
http://gradle.1045684.n5.nabble.com/declaring-a-class-in-a-gradle-file-and-using-it-through-apply-from-tp5712170p5712184.html
Sent from the gradle-dev mailing list archive at Nabble.com.
