Declaring build logic dependencies.

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Declaring build logic dependencies.

Luke Daley-2
Hi,

In working on the new plugin support, I think we might have overlooked plain java module build logic dependencies. Really, these are very much like plugins except there is no initialisation logic (i.e. plugin impl that we implicitly invoke). We have the same API compatibility and exporting concerns with these guys.

One of the key characteristics of the new plugin mechanism is that each plugin (build scripts are just plugins too) explicitly declare what they depend on (java libraries, gradle plugins, and maybe other things in the future). We have a new DSL for declaring plugin dependencies…

plugins {
  id “«some plugin id»
}

Given:

1. All build logic is specified via plugins 
2. Plugins can be implemented in different forms (e.g. Class vs. Script)
3. Certain domain objects have implicitly applied plugins (e.g. build.gradle)
4. Plugins depend on other plugins *and java libraries*

I think the plugins {} block is wrong. We probably need one block that encompasses all of the build logic dependencies (i.e. plugins and java libraries).

We probably want something closer to:

buildLogic {
  plugin “org.gradle.java”
  library “commons-collections:commons-collections:1.2.3"
}

Or,

buildLogic {
  plugins {
    id “org.gradle.java”
  }
  libraries {
    java “commons-collections:commons-collections:1.2.3”
  }
}

This would be the same construct that “script plugins” and “build scripts” use to declare their dependencies (because they are exactly the same thing).

But, while this is probably more conceptually correct, it makes the common case more verbose.

plugins {
  id “com.google.android"
}

vs.

buildLogic {
  plugin “com.google.android"
}

or,

buildLogic {
  plugins {
    id “com.google.android"
  } 
}


The term “buildLogic” is less than great. I don’t think that’s how users think of it. In a way `dependencies {}` at the top of the script is pretty good, but obviously that’s a non starter.

While this unification of “build scripts” as anonymous and implicit “script plugins” is nice for us, I don’t think that’s the mental model for users. This might be one of those unifications that makes things less intuitive.

The immediate concern is whether we are introducing doomed syntax with the `plugins {}` block. Some options:

1. Proceed with plugins {}, add another block/construct later (which might be adding some more bits to buildscript {}) 
2. Proceed with plugins {}, deprecate it later and move it to a new construct that supports plugin and library dependencies
3. Try to introduce something more evolvable now

I don’t like #1 very much, and #2 isn’t nice either. My ideas for #3 suffer from the, perhaps, needless verbosity as described above.

The problem with #1 (or two constructs in general) is that these things are inextricably connected. The public API exposed by the plugin dependencies and library dependencies must be compatible (i.e. resolved together, in a sense). Having one block for the specification of all build logic dependencies feels much better.


There is another option. We could allow a plugin implementation to be specified as one or more Java libraries, with effectively a noop implementation. From a conceptual and syntactic point of view, that leaves us with just plugins depending on other plugins (where plugins can be these weird java library only plugins). That might get us to a syntax like:

plugins {
  id “org.gradle.java”
  library “commons-collections:commons-collections:1.2.3"
}

Still doesn’t feel quite right though.

Any thoughts?

— 

Luke Daley
Gradleware
Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA: http://www.gradlesummit.com
Reply | Threaded
Open this post in threaded view
|

Re: Declaring build logic dependencies.

pledbrook
> We probably want something closer to:
>
> buildLogic {
>   plugin “org.gradle.java”
>   library “commons-collections:commons-collections:1.2.3"
> }

This raises the question of why not just use buildscript {}? Are the
repository definitions for resolving plugins and JARs still supposed
to go into the buildscript {} block, or should they go in buildLogic
{}?

Also, can build files in sub-projects now have their own buildscript {} blocks?

One other option is for the plugins {} block to be something like an
alias to plugin declarations in buildscript {}. So buildscript {}
would still be the authority, but you just include a shortcut for
convenience.

Peter

--
Peter Ledbrook
t: @pledbrook

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Declaring build logic dependencies.

Luke Daley-2


On 11 June 2014 at 4:11:32 am, Peter Ledbrook ([hidden email]) wrote:

> We probably want something closer to: 
> 
> buildLogic { 
> plugin “org.gradle.java” 
> library “commons-collections:commons-collections:1.2.3" 
> } 

This raises the question of why not just use buildscript {}? 

Simpler to understand if there is a clean break, and the term ‘buildscript’ isn’t very meaningful.

Are the 
repository definitions for resolving plugins and JARs still supposed 
to go into the buildscript {} block, or should they go in buildLogic 
{}? 

They will be somewhere else entirely. Scripts declare what they need in terms of identity, how that is mapped to an implementation is the business of something else.

Also, can build files in sub-projects now have their own buildscript {} blocks? 

They’ve always been able to.

One other option is for the plugins {} block to be something like an 
alias to plugin declarations in buildscript {}. So buildscript {} 
would still be the authority, but you just include a shortcut for 
convenience. 

Not big on this. The way we use buildscript {} is broken and we need to work towards removing it. Part of the new system is that plugins are isolated and class paths are not inherited. 



Peter 

-- 
Peter Ledbrook 
t: @pledbrook 

--------------------------------------------------------------------- 
To unsubscribe from this list, please visit: 

http://xircles.codehaus.org/manage_email 





— 

Luke Daley
Gradleware
Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA: http://www.gradlesummit.com
Reply | Threaded
Open this post in threaded view
|

Re: Declaring build logic dependencies.

pledbrook
>> We probably want something closer to:
>>
>> buildLogic {
>> plugin “org.gradle.java”
>> library “commons-collections:commons-collections:1.2.3"
>> }
>
> This raises the question of why not just use buildscript {}?
>
> Simpler to understand if there is a clean break, and the term ‘buildscript’
> isn’t very meaningful.

In which case, I prefer something like buildDependencies {} or
buildDeps {} to make it shorter. Assuming that this block only
includes build dependencies of course.

So maybe

  buildDeps {
      plugin id: "org.gradle.java”
      lib "commons-collections:commons-collections:1.2.3"
  }

Or does this not tackle the issues that concern you? Is the main issue
verbosity?

Peter

--
Peter Ledbrook
t: @pledbrook

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email