Yeah, I've noticed the zip packaging in pom but wasn't sure if that's the
reason why Gradle tries to resolve the jar for that artifact. Should I
create an issue for it?

I'll assume that this will be fixed in rc-2 and I will try again when it's
released.

On Tue, Apr 10, 2018 at 8:20 AM, Cédric Champeau <cedric.champ...@gmail.com>
wrote:

> There's a bug in the published pom: it says <packaging>zip</packaging>
> instead of <packaging>pom</packaging>. We should fix this, thanks for the
> report!
>
>
>
> 2018-04-09 23:15 GMT+02:00 Marcin Erdmann <marcin.erdm...@proxerd.pl>:
>
>> Paul,
>>
>> I'm having a go at giving this release a spin by updating Geb's build to
>> use it but unfortunately I'm not having any luck with trying to use the
>> groovy-all artifact. I understand from the earlier thread about updates to
>> the build on the dev list that the jar for that artifact is not published
>> and it's supposed to just be a dependency only aritfact which will be
>> useful for resolving all of Groovy's modules.
>>
>> To quote you:
>>
>> > The idea (once finished) is that you can still depend on a groovy-all 
>> > dependency
>> via Maven or Gradle and you'll automatically get the multiple required
>> equivalent jars of the current single groovy-all jar.
>>
>> Unfortunately this is not the case. Given a simple build like:
>>
>>
>> plugins {
>> id 'groovy'
>> }
>>
>> repositories {
>> mavenCentral()
>> }
>>
>> dependencies {
>> compile 'org.codehaus.groovy:groovy-all:2.5.0-rc-1'
>> }
>>
>>
>> and an empty Groovy class in the main source set when running `gradle
>> build` I'm getting:
>>
>>
>> Could not resolve all dependencies for configuration ':compileClasspath'.
>> > Could not find groovy-all.jar (org.codehaus.groovy:groovy-al
>> l:2.5.0-rc-1).
>>   Searched in the following locations:
>>       https://repo1.maven.org/maven2/org/codehaus/groovy/groovy-
>> all/2.5.0-rc-1/groovy-all-2.5.0-rc-1.jar
>>
>>
>> I tried changing the dependency to 'org.codehaus.groovy:groovy-al
>> l:2.5.0-rc-1@pom' but while in that case dependency resolution phase succeeds
>> the build itself then fails with:
>>
>>
>> Cannot infer Groovy class path because no Groovy Jar was found on class
>> path: configuration ':compileClasspath'
>>
>>
>> I do not see any of the modules apart from groovy-all itself being added
>> to the configuration when running `gradle dependencies --configuration
>> compile`:
>>
>>
>> compile - Dependencies for source set 'main'.
>> \--- org.codehaus.groovy:groovy-all:2.5.0-rc-1
>>
>>
>> Am I doing something wrong or is the way forward not using groovy-all
>> anymore and explicitly depending on only the used modules?
>>
>> Cheers,
>> Marcin
>>
>> On Mon, Apr 9, 2018 at 7:07 AM, Paul King <pa...@apache.org> wrote:
>>
>>> Dear community,
>>>
>>> The Apache Groovy team is pleased to announce version 2.5.0-rc-1 of
>>> Apache Groovy.
>>> Apache Groovy is a multi-faceted programming language for the JVM.
>>> Further details can be found at the http://groovy.apache.org website.
>>>
>>> This is a pre-release of a new version of Groovy.
>>> We greatly appreciate any feedback you can give us when using this
>>> version.
>>>
>>> This release includes 18 bug fixes/improvements as outlined in the
>>> changelog:
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
>>> ctId=12318123&version=12342817
>>>
>>> Sources, convenience binaries, downloadable documentation and an SDK
>>> bundle can be found at: http://www.groovy-lang.org/download.html
>>> We recommend you verify your installation using the information on that
>>> page.
>>>
>>> Jars are also available within the major binary repositories.
>>>
>>> We welcome your help and feedback and in particular want
>>> to thank everyone who contributed to this release.
>>>
>>> For more information on how to report problems, and to get involved,
>>> visit the project website at https://groovy.apache.org/
>>>
>>> Best regards,
>>>
>>> The Apache Groovy team.
>>>
>>
>>
>

Reply via email to