gradleApi() with 1.0.0-m4

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

gradleApi() with 1.0.0-m4

Meikel Brandmeyer-3
Hi,

I'm the author of clojuresque, a gradle plugin for Clojure. Up to milestone 3 I was able to build my plugin with

dependencies {
    compile gradleApi()
    groovy localGroovy()
}

in my build.gradle. But with milestone-4 this fails. Obviously because JavaPlugin in plugins/gradle-plugins-1.0-milestone-4.jar (and others?) is not on the classpath. eg. MavenPlugin and Jar task are also missing. Do I have to add another option?

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: gradleApi() with 1.0.0-m4

Adam Murdoch

On 02/08/2011, at 6:49 AM, Meikel Brandmeyer wrote:

Hi,

I'm the author of clojuresque, a gradle plugin for Clojure. Up to milestone 3 I was able to build my plugin with

dependencies {
   compile gradleApi()
   groovy localGroovy()
}

in my build.gradle. But with milestone-4 this fails. Obviously because JavaPlugin in plugins/gradle-plugins-1.0-milestone-4.jar (and others?) is not on the classpath. eg. MavenPlugin and Jar task are also missing. Do I have to add another option?

Not sure yet. The gradleApi() implementation did change for milestone-4, but this shouldn't have affected whether JavaPlugin is visible or not. I need to have a dig to see why this has happened, then we can look at how to fix it or work around it.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com

Reply | Threaded
Open this post in threaded view
|

Re: gradleApi() with 1.0.0-m4

evgenyg
Hi,

I think I experience the same issue. My Gradle task can't compile with  org.gradle.api.plugins.ProjectReportsPlugin any more after upgrading to m4: "unable to resolve class org.gradle.api.plugins.ProjectReportsPlugin".

After running "gradle idea" I see how only "gradle/lib/gradle-core-1.0-milestone-4.jar" and "gradle/lib/core-impl/gradle-core-impl-1.0-milestone-4.jar" are added to the project which explain the compilation failure, the plugin I need is located in "gradle/lib/plugins/gradle-plugins-1.0-milestone-4.jar", as Meikel mentioned above.

So it looks like in addition to gradleApi() something like gradlePlugins() compile dependency is required. Is there any workaround available ? (well, except grabbing the jar and pushing it to one of Artifactory repos manually)

Thanks!

Best regards,
Evgeny
evgeny-goldin.com
Reply | Threaded
Open this post in threaded view
|

Re: gradleApi() with 1.0.0-m4

Adam Murdoch

On 08/08/2011, at 5:50 AM, evgenyg wrote:

Hi,

I think I experience the same issue. My Gradle task can't compile with  
https://github.com/evgeny-goldin/gradle-plugins/blob/1624f39d8eb6c23d5be130267ec37bd60de42387/src/main/groovy/com/goldin/plugins/gradle/about/AboutTask.groovy#L6
org.gradle.api.plugins.ProjectReportsPlugin  any more after upgrading to m4:
"unable to resolve class org.gradle.api.plugins.ProjectReportsPlugin".

After running "gradle idea" I see how only
"gradle/lib/gradle-core-1.0-milestone-4.jar" and
"gradle/lib/core-impl/gradle-core-impl-1.0-milestone-4.jar" are added to the
project which explain the compilation failure, the plugin I need is located
in "gradle/lib/plugins/gradle-plugins-1.0-milestone-4.jar", as Meikel
mentioned above.

So it looks like in addition to *gradleApi()* something like
*gradlePlugins()* compile dependency is required. Is there any workaround
available ? (well, except grabbing the jar and pushing it to one of
Artifactory repos manually)

The gradleApi() dependency was never supposed to expose the plugins, only the core. The plugins were unintentionally included in previous versions, and in milestone-4, gradleApi() was changed to include only the core API (ignoring the fact that gradleApi() also includes all the runtime dependencies of core - that is a separate problem).

We'll probably do as you suggest, and add some methods to declare dependencies on the plugins. I think we should bust it up, so that you declare a dependency on particular plugins, rather than all the Gradle plugins lumped together. Perhaps something like:

dependencies {
    compile plugin('java')
}

Another option is to deprecate gradleApi() and localGroovy(), and replace them with a repository implementation that knows how to find stuff in $gradleHome/lib:

repositories {
    gradleDistro()
}

dependencies {
    compile 'org.gradle:gradle-core:${gradle.gradleVersion}'
    compile 'org.gradle:gradle-plugins:${gradle.gradleVersion}'
}

I don't think I like this approach.

Regardless of what we choose, in the meantime a workaround is:

dependencies {
    compile fileTree(dir: "${gradle.gradleHomeDir}/lib/plugins", include: '**/*.jar')
}


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com

Reply | Threaded
Open this post in threaded view
|

Re: gradleApi() with 1.0.0-m4

evgenyg
Yes, it helped, thank you! I like the second approach more but with a clear way to specify coordinates of Gradle components: "gradle-core", "gradle-plugins", "gradle-jetty", "gradle-tooling-api", following the existing file name convention.
Best regards,
Evgeny
evgeny-goldin.com
Reply | Threaded
Open this post in threaded view
|

Re: gradleApi() with 1.0.0-m4

Luke Daley-2
In reply to this post by Adam Murdoch

On 08/08/2011, at 10:24 AM, Adam Murdoch wrote:

The gradleApi() dependency was never supposed to expose the plugins, only the core. The plugins were unintentionally included in previous versions, and in milestone-4, gradleApi() was changed to include only the core API (ignoring the fact that gradleApi() also includes all the runtime dependencies of core - that is a separate problem).

We'll probably do as you suggest, and add some methods to declare dependencies on the plugins. I think we should bust it up, so that you declare a dependency on particular plugins, rather than all the Gradle plugins lumped together. Perhaps something like:

dependencies {
    compile plugin('java')
}

Another option is to deprecate gradleApi() and localGroovy(), and replace them with a repository implementation that knows how to find stuff in $gradleHome/lib:

repositories {
    gradleDistro()
}

dependencies {
    compile 'org.gradle:gradle-core:${gradle.gradleVersion}'
    compile 'org.gradle:gradle-plugins:${gradle.gradleVersion}'
}

I don't think I like this approach.

For my money, that's better than a special notation. 

-- 
Luke Daley
Principal Engineer, Gradleware 
http://gradleware.com

Reply | Threaded
Open this post in threaded view
|

Re: gradleApi() with 1.0.0-m4

Hani Suleiman
Why not just check in the gradle jars to maven central? That way you could even support oddball scenarios like building a plugin for 0.9.3 while using M4.

On Aug 9, 2011, at 1:52 AM, Luke Daley wrote:

>
> On 08/08/2011, at 10:24 AM, Adam Murdoch wrote:
>
>> The gradleApi() dependency was never supposed to expose the plugins, only the core. The plugins were unintentionally included in previous versions, and in milestone-4, gradleApi() was changed to include only the core API (ignoring the fact that gradleApi() also includes all the runtime dependencies of core - that is a separate problem).
>>
>> We'll probably do as you suggest, and add some methods to declare dependencies on the plugins. I think we should bust it up, so that you declare a dependency on particular plugins, rather than all the Gradle plugins lumped together. Perhaps something like:
>>
>> dependencies {
>>     compile plugin('java')
>> }
>>
>> Another option is to deprecate gradleApi() and localGroovy(), and replace them with a repository implementation that knows how to find stuff in $gradleHome/lib:
>>
>> repositories {
>>     gradleDistro()
>> }
>>
>> dependencies {
>>     compile 'org.gradle:gradle-core:${gradle.gradleVersion}'
>>     compile 'org.gradle:gradle-plugins:${gradle.gradleVersion}'
>> }
>>
>> I don't think I like this approach.
>
> For my money, that's better than a special notation.
>
> --
> Luke Daley
> Principal Engineer, Gradleware
> http://gradleware.com
>


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: gradleApi() with 1.0.0-m4

ansel1
Stale reply, but I'm with Hani.  Why not just resolve gradle and gradle plugins using normal dependency annotations, like everything else.

One drawback of gradleApi() I just in encountered, in M3, is that when using with the 'idea' plugin, it doesn't pull down any of the gradle sources.
Reply | Threaded
Open this post in threaded view
|

Re: gradleApi() with 1.0.0-m4

evgenyg
If Gradle jars are pushed to the Central repo and then every plugin can choose any Gradle version to depend upon, then there needs to be a way to make sure the proper Gradle version is used at run-time.

For example:
* If plugin doesn't specify any requirement then it runs with any Gradle version.
* If plugin specifies "same version" requirement then it can only be run with the Gradle version it was compiled with.
* Third option for a plugin is to specify a range of compatible versions.

It was previously discussed from the build script point of view. But plugins are in the same situation.
Best regards,
Evgeny
evgeny-goldin.com
Reply | Threaded
Open this post in threaded view
|

Re: gradleApi() with 1.0.0-m4

Hani Suleiman
I don't see why this is that important. The issue exists already in the current implementation, so there's no degradation or loss of functionality.

Sure, in an ideal world, you can define version ranges and all that fancy stuff.

In the real world however, it'd work the exact same way any app that depends on third party libs does, a note somewhere that says

'this only works on X.Y onwards, except for X.Y.Z which is broken'.

The goal isn't to have something perfect, it's to have something thats not as irritatingly broken as the current situation.

On Sep 5, 2011, at 7:03 PM, evgenyg wrote:

> If Gradle jars are pushed to the Central repo and then every plugin can
> choose any Gradle version to depend upon, then there needs to be a way to
> make sure the proper Gradle version is used at run-time.
>
> For example:
> * If plugin doesn't specify any requirement then it runs with any Gradle
> version.
> * If plugin specifies "same version" requirement then it can only be run
> with the Gradle version it was compiled with.
> * Third option for a plugin is to specify a range of compatible versions.
>
> It was
> http://gradle.1045684.n5.nabble.com/Verifying-Gradle-version-td4675891.html
> previously discussed  from the build script point of view. But plugins are
> in the same situation.
>
> -----
> Best regards,
>
> Evgeny
>
> evgeny-goldin.com
>
> --
> View this message in context: http://gradle.1045684.n5.nabble.com/gradleApi-with-1-0-0-m4-tp4656647p4772383.html
> Sent from the gradle-user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: gradleApi() with 1.0.0-m4

evgenyg
I see it somewhat differently. If someone declares a dependency on a third-party library, it normally gets downloaded by Maven or Ivy (+/- conflicts involved).

If Gradle plugin declares dependency on any specific Gradle version, and marks this dependency as "provided" then no dependency will be downloaded for it (I suppose nobody wants plugins to pull different Gradle versions from Maven repos when builds start). As a plugin author it will make me very unsure about run-time environment: being dependent on X when the plugin is built but running with God knows what, having no way to verify or enforce it.

Correct, this problem already exists today and I all was pointing out is that some kind of Gradle version enforcer will be very helpful (both for build scripts and plugins), especially when or if getting Gradle as a regular dependency will be made easier.
Best regards,
Evgeny
evgeny-goldin.com
Reply | Threaded
Open this post in threaded view
|

Re: gradleApi() with 1.0.0-m4

evgenyg
I think most of the time, people use "provided" scope for Java EE/Servlet-like dependencies which changed once in 5 years so it was safe to assume run-time version will match the expected one. Since Gradle versions change more rapidly than that (and thanks for that) - this case is significantly more risky to be handled with "provided" scope and no additional tools.
Best regards,
Evgeny
evgeny-goldin.com