Re: Mastodon presence for Apache Groovy

[Cédric Champeau]

>
> Speaking of which -- do you know of any good tools to do a sort of a
> multicast to twitter and mastodon?
>
>
You can use https://crossposter.masto.donte.com.br/

But we aware that such tools are not super well appreciated from the
Mastodon community (original contents is better).

Re: Welcome Remko Popma to the Apache Groovy PMC!

[Cédric Champeau]

Welcome, Remko!

Le mer. 13 juil. 2022 à 09:31, Guillaume Laforge  a
écrit :

> Welcome and congrats!
>
> On Wed, Jul 13, 2022 at 9:16 AM Mario Garcia  wrote:
>
>> Good news! Congratulations Remko!
>>
>> El mié, 13 jul 2022 a las 8:59, Paul King ()
>> escribió:
>>
>>> Remko Popma has been voted as an additional member to the Apache
>>> Groovy PMC. Congratulations Remko!
>>>
>>> Remko has been a committer for some time, and was the main contributor
>>> for the groovy-cli-picocli module. He is also on the PMC of Apache
>>> Logging.
>>>
>>> Cheers, Paul.
>>> On behalf of the Apache Groovy PMC.
>>>
>>
>
> --
> Guillaume Laforge
> Apache Groovy committer
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Twitter: @glaforge 
>

Build up-to-date/caching is broken!

[Cédric Champeau]

Hi folks,

It seems that since last time I updated the build, caching is broken: if
you run the same build twice, it's not fetching compileGroovy from cache,
which it should. If you update the build, please make sure that you don't
break caching by:

- running the same command twice in a row and making sure everything is
up-to-date
- running "clean whatever" and make sure it fetches everything from the
local cache

if it doesn't work, you broke something. As an example, I checked out the
GROOVY_4_0_0 tag and ran `./gradlew compileGroovy`.

Here's the first scan: https://scans.gradle.com/s/bo5tzjdgrvhrm

Then I'm doing the same again:
https://scans.gradle.com/s/2muqflkbj6iwo/timeline?details=ajpf6vqhnqhfc

You can see that everything gets recompiled because the bootstrap compiler
jar changed. This should never happen. I don't know how this got unnoticed,
since it's obviously dramatically increasing feedback time.

This is also particularly painful because the build OOMs when trying to
publish to a local repository. Because it has to restart from scratch, it's
a huge waste of time.

I'll try to find time to identify the problem. FWIW, this is why a Gradle
Enterprise partnership would be useful, since we'd get build data and the
problem would have been immediately identified.

Re: [VOTE] Release Apache Groovy 4.0.0-alpha-3

[Cédric Champeau]

Le mar. 13 avr. 2021 à 13:04, Paul King  a écrit :

> We don't use the keys file (being binary) for the source build. I guess we
> could offer a way to bootstrap that too like we do for gradlew. Then users
> could choose if they wanted to do the build with or without.
>

To me it feels a bit strange not to use this file because it's binary, when
we also happily use images... which are binary too :) Anyway the format is
a regular GPG keyring so it's easy to figure out what's inside.

>
> What would be good from the Gradle side is a better way to flush and
> restart verification when flakey key servers are stumbled across because
> there does seem to be some caching once the corruption occurs.
>

This is already the case: Gradle tries different key servers and
exponential backoff. When ultimately it fails there's nothing much we can
do. An option is to setup your own key server mirror.


> Or perhaps there is a way I haven't discovered yet.
>
> Cheers, Paul.
>
>
> On Tue, Apr 13, 2021 at 8:00 PM Cédric Champeau 
> wrote:
>
>> Technically it's not Gradle's dependency verification which is flaky,
>> it's the key servers. That's why you must, from time to time, update the
>> local keyring, using `--export-keys` as explained in
>> https://docs.gradle.org/current/userguide/dependency_verification.html#sec:local-keyring
>>
>> Then the builds wouldn't have to ping the remote servers on every build,
>> because the keys would be found in the local keystore.
>>
>> Le mar. 13 avr. 2021 à 11:56, Paul King  a écrit :
>>
>>>
>>> Oops, forgot the mailing list.
>>>
>>> -- Forwarded message -
>>> From: Paul King 
>>> Date: Tue, Apr 13, 2021 at 7:56 PM
>>> Subject: Re: [VOTE] Release Apache Groovy 4.0.0-alpha-3
>>> To: Guillaume Laforge 
>>>
>>>
>>> Gradle's dependency verification (incubating feature) does seem to be a
>>> little flakey sometimes. Hopefully it will improve over time. I have
>>> numerous other environments where that error doesn't show but Daniel had a
>>> similar but different error. Regenerating the verification metadata didn't
>>> change anything for him which indicates the metadata is probably okay as
>>> is. I'd suggest running with dependency verification set to lenient or off
>>> and see if that helps:
>>>
>>>
>>> https://docs.gradle.org/current/userguide/dependency_verification.html#sec:disabling-verification
>>>
>>> Cheers, Paul.
>>>
>>>
>>> On Tue, Apr 13, 2021 at 6:51 PM Guillaume Laforge 
>>> wrote:
>>>
>>>> I got a test failure (on Java 11):
>>>>
>>>> Execution failed for task ':groovy-testng:test'.
>>>>
>>>> > Dependency verification failed for configuration
>>>> ':groovy-testng:testRuntimeClasspath'
>>>>
>>>>   One artifact failed verification: jcommander-1.78.jar
>>>> (com.beust:jcommander:1.78) from repository MavenRepo
>>>>
>>>>   This can indicate that a dependency has been compromised. Please
>>>> carefully verify the signatures and checksums.
>>>>
>>>> Opening the report tells me:
>>>>
>>>> configuration ':groovy-testng:testRuntimeClasspath' 1 error
>>>> <#m_-7713695666752602976_m_8153075787925662056_m_-2671871127063042544_m_5361968448074506625_m_-8064841157445032086_>
>>>> MODULEARTIFACTPROBLEM(S)
>>>> com.beust:jcommander:1.78
>>>> jcommander-1.78.jar (.asc)
>>>>
>>>> Key 22e44ac0622b91c3 (not found) couldn't be found in any key server
>>>> so verification couldn't be performed
>>>>
>>>>
>>>> On Tue, Apr 13, 2021 at 6:58 AM Søren Berg Glasius 
>>>> wrote:
>>>>
>>>>> +1
>>>>>
>>>>> Med venlig hilsen / Best regards
>>>>>
>>>>> Søren Berg Glasius
>>>>>
>>>>> Sent from my phone, thus brief
>>>>>
>>>>> On Tue, Apr 13, 2021, 04:56 Paul King  wrote:
>>>>>
>>>>>> Dear development community,
>>>>>>
>>>>>> I am happy to start the VOTE thread for a Groovy 4.0.0-alpha-3
>>>>>> release!
>>>>>>
>>>>>> This release includes 152 bug fixes/improvements as outlined in the
>>>>>> changelog:
>>>>>>
>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12349469
>>>

Re: [VOTE] Release Apache Groovy 4.0.0-alpha-3

[Cédric Champeau]

Technically it's not Gradle's dependency verification which is flaky, it's
the key servers. That's why you must, from time to time, update the local
keyring, using `--export-keys` as explained in
https://docs.gradle.org/current/userguide/dependency_verification.html#sec:local-keyring

Then the builds wouldn't have to ping the remote servers on every build,
because the keys would be found in the local keystore.

Le mar. 13 avr. 2021 à 11:56, Paul King  a écrit :

>
> Oops, forgot the mailing list.
>
> -- Forwarded message -
> From: Paul King 
> Date: Tue, Apr 13, 2021 at 7:56 PM
> Subject: Re: [VOTE] Release Apache Groovy 4.0.0-alpha-3
> To: Guillaume Laforge 
>
>
> Gradle's dependency verification (incubating feature) does seem to be a
> little flakey sometimes. Hopefully it will improve over time. I have
> numerous other environments where that error doesn't show but Daniel had a
> similar but different error. Regenerating the verification metadata didn't
> change anything for him which indicates the metadata is probably okay as
> is. I'd suggest running with dependency verification set to lenient or off
> and see if that helps:
>
>
> https://docs.gradle.org/current/userguide/dependency_verification.html#sec:disabling-verification
>
> Cheers, Paul.
>
>
> On Tue, Apr 13, 2021 at 6:51 PM Guillaume Laforge 
> wrote:
>
>> I got a test failure (on Java 11):
>>
>> Execution failed for task ':groovy-testng:test'.
>>
>> > Dependency verification failed for configuration
>> ':groovy-testng:testRuntimeClasspath'
>>
>>   One artifact failed verification: jcommander-1.78.jar
>> (com.beust:jcommander:1.78) from repository MavenRepo
>>
>>   This can indicate that a dependency has been compromised. Please
>> carefully verify the signatures and checksums.
>>
>> Opening the report tells me:
>>
>> configuration ':groovy-testng:testRuntimeClasspath' 1 error
>> <#m_-2671871127063042544_m_5361968448074506625_m_-8064841157445032086_>
>> MODULEARTIFACTPROBLEM(S)
>> com.beust:jcommander:1.78
>> jcommander-1.78.jar (.asc)
>>
>> Key 22e44ac0622b91c3 (not found) couldn't be found in any key server so
>> verification couldn't be performed
>>
>>
>> On Tue, Apr 13, 2021 at 6:58 AM Søren Berg Glasius 
>> wrote:
>>
>>> +1
>>>
>>> Med venlig hilsen / Best regards
>>>
>>> Søren Berg Glasius
>>>
>>> Sent from my phone, thus brief
>>>
>>> On Tue, Apr 13, 2021, 04:56 Paul King  wrote:
>>>
 Dear development community,

 I am happy to start the VOTE thread for a Groovy 4.0.0-alpha-3 release!

 This release includes 152 bug fixes/improvements as outlined in the
 changelog:

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12349469

 Tag:
 https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_4_0_0_ALPHA_3
 Tag commit id: bdd219508feef5893372bf1b96ead893f2f2869b

 The artifacts to be voted on are located as follows (r47022).
 Source release:
 https://dist.apache.org/repos/dist/dev/groovy/4.0.0-alpha-3/sources
 Convenience binaries:
 https://dist.apache.org/repos/dist/dev/groovy/4.0.0-alpha-3/distribution

 Release artifacts are signed with a key from the following file:
 https://dist.apache.org/repos/dist/release/groovy/KEYS

 Please vote on releasing this package as Apache Groovy 4.0.0-alpha-3.

 Reminder on ASF release approval requirements for PMC members:
 http://www.apache.org/legal/release-policy.html#release-approval
 Hints on validating checksums/signatures (but replace md5sum with
 sha256sum):
 https://www.apache.org/info/verification.html

 The vote is open for the next 72 hours and passes if a majority of at
 least three +1 PMC votes are cast.

 [ ] +1 Release Apache Groovy 4.0.0-alpha-3
 [ ]  0 I don't have a strong opinion about this, but I assume it's ok
 [ ] -1 Do not release Apache Groovy 4.0.0-alpha-3 because...

 Here is my vote:

 +1 (binding)


>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer
>> Developer Advocate @ Google Cloud Platform
>>
>> Blog: http://glaforge.appspot.com/
>> Twitter: @glaforge 
>>
>

Re: build changes

[Cédric Champeau]

Hi folks,

"clean" shouldn't be necessary, it's Gradle after all ;) However, `clean`
won't delete the old "target" directories so something like:

find . -type d -name "target" -exec rm -rf {} \;

should do.


Le ven. 9 oct. 2020 à 14:45, Paul King  a écrit :

> Another recommendation is run the "clean" task before updating.
>
> On Fri, Oct 9, 2020 at 9:30 PM Paul King  wrote:
>
>>
>> Hi everyone, just to let you know I have merged Cédric's build changes!
>> Thanks again Cédric!
>>
>> There are still a few things to tidy up but shout if you spot anything
>> which seems out of the ordinary.
>>
>> I plan to add a "Notes for building Groovy" section to the Groovy 4
>> release notes when I find time to document a few of the important changes.
>> Just a couple of points until I get around to those notes:
>> * don't go looking in the "target" subdirectory for build artifacts
>> anymore, we now use "build"
>> * if you run "installGroovy", don't look for the locally built version
>> under "target/install" but now "subprojects/groovy-binary/build/install"
>>
>> Cheers, Paul.
>>
>>

Re: [VOTE] Release Apache Groovy 4.0.0-alpha-1

[Cédric Champeau]

Congrats on having the first alpha, team! I'm just re-instantiating that
because of the coordinates change, it would really be great if you could
leverage Gradle Module Metadata so that users are aware of a conflict, and
that Gradle can take care of it. This is basically about saying that
org.apache.groovy provides the same capabiliy as org.codehaus.groovy. Of
course requires you to update the build to use maven-publish, which you
have to do anyway before Gradle 7.0 is out

Le lun. 28 sept. 2020 à 09:46, Paul King  a écrit :

> Thanks for voting everyone. 24 hrs to go, though we have the required
> numbers if nothing changes.
>
> Here is a draft of the Groovy 4 release notes if anyone wants to check I
> haven't forgotten anything:
>
> http://groovy-lang.org/releasenotes/groovy-4.0.html
>
>
> Cheers, Paul.
>
>
> On Sat, Sep 26, 2020 at 11:19 PM Paul King  wrote:
>
>>
>> Dear development community,
>>
>> I am happy to start the VOTE thread for a Groovy 4.0.0-alpha-1 release!
>>
>> This release includes 252 bug fixes/improvements as outlined in the
>> changelog:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12346885
>>
>> Tag:
>> https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_4_0_0_ALPHA_1
>> Tag commit id: 9795452c58631d65e3b201682bc3c8343588710c
>>
>> The artifacts to be voted on are located as follows (r41591).
>> Source release:
>> https://dist.apache.org/repos/dist/dev/groovy/4.0.0-alpha-1/sources
>> Convenience binaries:
>> https://dist.apache.org/repos/dist/dev/groovy/4.0.0-alpha-1/distribution
>>
>> Release artifacts are signed with a key from the following file:
>> https://dist.apache.org/repos/dist/dev/groovy/KEYS
>>
>> Please vote on releasing this package as Apache Groovy 4.0.0-alpha-1.
>>
>> Reminder on ASF release approval requirements for PMC members:
>> http://www.apache.org/legal/release-policy.html#release-approval
>> Hints on validating checksums/signatures (but replace md5sum with
>> sha256sum):
>> https://www.apache.org/info/verification.html
>>
>> The vote is open for the next 72 hours and passes if a majority of at
>> least three +1 PMC votes are cast.
>>
>> [ ] +1 Release Apache Groovy 4.0.0-alpha-1
>> [ ]  0 I don't have a strong opinion about this, but I assume it's ok
>> [ ] -1 Do not release Apache Groovy 4.0.0-alpha-1 because...
>>
>> Here is my vote:
>>
>> +1 (binding)
>>
>>

Re: More inclusive naming

[Cédric Champeau]

+1

Le jeu. 11 juin 2020 à 16:56, Jeff Beck  a écrit :

> I find those aliases easier to understand. So I think it's a great
> improvement.
>
> Jeff
>
> On Thu, Jun 11, 2020, 9:50 AM Paul King  wrote:
>
>> Hi folks,
>>
>> Given recent world events, there are numerous projects that are taking
>> the opportunity to use more inclusive terminology especially in names
>> within APIs. E.g. getting rid of things like master/slave,
>> blacklist/whitelist, etc. While I have never witnessed any racist behavior
>> in the Groovy community, it seems worthwhile to be as inclusive as we can.
>> I scanned our codebase and it seems that the only potential candidate we
>> have for such a change would be in SecureASTCustomizer. But feel free to
>> chime in if you think there are others.
>>
>> For backwards compatibility, I wouldn't propose to remove the old names
>> in the first instance, just provide friendly aliases. We can deprecate
>> and/or remove the current names later if we feel the need. Some example
>> aliases could be something like:
>>
>> tokensWhitelist => allowedTokens
>> staticStarImportsWhitelist => allowedStaticStarImports
>> importsBlacklist => prohibitedImports (or disallowedImports)
>>
>> Thoughts?
>>
>> Cheers, Paul.
>>
>>

Re: Field order from traits

[Cédric Champeau]

Independently of reflection or not, the compiler should be reproducible. So
same sources -> same output, whatever the OS, whatever the time. This is
important for trust and cache-ability.
On this specific issue, the default mechanism is to use ASM which is
reproducible.

Le lun. 2 déc. 2019 à 10:06, Andres Almiray  a écrit :

> I need consistent field order to get around this problem ->
> https://github.com/gradle/gradle/issues/11522
>
> I'm aware that reflection does not guarantee order. I was under the
> impression that the compiler would use the AST which would have the correct
> order but that only works if the trait is compiled in the same session as
> the target code. The compiler would be forced to use reflection if the
> trait is found only in binary in the classpath. Anyway, I found a
> workaround which is to encapsulate the fields on another type and have that
> latter be injected by the trait.
>
> Thanks.
>
> ---
> Java Champion; Groovy Enthusiast
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary,
> and those who don't.
> To understand recursion, we must first understand recursion.
>
>
> On Mon, Dec 2, 2019 at 2:56 AM Jochen Theodorou  wrote:
>
>> Hi Andres,
>>
>> I think your expectations are wrong. To understand why it is important I
>> wonder though what you need it for
>>
>> bye Jochen
>>
>>
>> On 01.12.19 19:02, Andres Almiray wrote:
>> > Hello everyone,
>> >
>> > I've encountered a "problem" when using traits. Say you have a couple of
>> > traits that define fileds in the following order
>> >
>> > @CompileStatic
>> > trait CompartmentIdAwareTrait implements PathAware, ProjectAware {
>> > @Internal
>> > final Property compartmentId =
>> project.objects.property(String)
>> >
>> > @Input
>> > final Provider resolvedCompartmentId = stringProvider(
>> > 'OCI_COMPARTMENT_ID',
>> > 'oci.compartment.id ',
>> > getCompartmentId(),
>> > project)
>> > }
>> >
>> > and
>> >
>> > @CompileStatic
>> > trait InstanceNameAwareTrait implements PathAware, ProjectAware {
>> >  @Internal
>> >  final Property instanceName =
>> project.objects.property(String)
>> >
>> >  @Input
>> >  final Provider resolvedInstanceName = stringProvider(
>> >  'OCI_INSTANCE_NAME',
>> >  'oci.instance.name ',
>> >  getInstanceName(),
>> >  project)
>> > }
>> >
>> > As you can see there's a regular property field and a "resolved"
>> > provider field. I expected these fields to be copied in definition
>> > order, that is, resolved fields will always be second thus the reference
>> > to their corresponding property field will work.
>> >
>> > However that's not the case. I'm compiling code with Groovy 2.5.8 (I
>> > think that's the version used by Gradle 6.0.1) and I find the following
>> > fields in the bytecode of the target class that applies the traits
>> >
>> >private final org.gradle.api.provider.Provider
>> >
>> org_kordamp_gradle_plugin_oci_tasks_traits_InstanceNameAwareTrait__resolvedInstanceName;
>> >private final org.gradle.api.provider.Property
>> >
>> org_kordamp_gradle_plugin_oci_tasks_traits_InstanceNameAwareTrait__instanceName;
>> >private final org.gradle.api.provider.Property
>> >
>> org_kordamp_gradle_plugin_oci_tasks_traits_CompartmentIdAwareTrait__compartmentId;
>> >private final org.gradle.api.provider.Provider
>> >
>> org_kordamp_gradle_plugin_oci_tasks_traits_CompartmentIdAwareTrait__resolvedCompartmentId;
>> >
>> > The order of copied fields is not consistent either
>> >
>> >private final org.gradle.api.provider.Property
>> > org_kordamp_gradle_plugin_oci_tasks_traits_VerboseAwareTrait__verbose;
>> >private final org.gradle.api.provider.Provider
>> >
>> org_kordamp_gradle_plugin_oci_tasks_traits_VerboseAwareTrait__resolvedVerbose;
>> >private final
>> > org.gradle.api.provider.Provider
>> >
>> org_kordamp_gradle_plugin_oci_tasks_traits_UserDataFileAwareTrait__resolvedUserDataFile;
>> >private final org.gradle.api.file.RegularFileProperty
>> >
>> org_kordamp_gradle_plugin_oci_tasks_traits_UserDataFileAwareTrait__userDataFile;
>> >private final org.gradle.api.file.RegularFileProperty
>> >
>> org_kordamp_gradle_plugin_oci_tasks_traits_PublicKeyFileAwareTrait__publicKeyFile;
>> >private final
>> > org.gradle.api.provider.Provider
>> >
>> org_kordamp_gradle_plugin_oci_tasks_traits_PublicKeyFileAwareTrait__resolvedPublicKeyFile;
>> >private final org.gradle.api.provider.Provider
>> >
>> org_kordamp_gradle_plugin_oci_tasks_traits_ShapeAwareTrait__resolvedShape;
>> >private final org.gradle.api.provider.Property
>> > org_kordamp_gradle_plugin_oci_tasks_traits_ShapeAwareTrait__shape;
>> >private final 

Re: Upcoming releases

[Cédric Champeau]

Just saying that using external ASM is an option now. Back then we had to
repackage because ASM wasn't backwards compatible so triggered all sorts of
problems when another library used it with a different version.
This is not the case now since you always pass in the ASM version in the
constructor now, so ASM knows what visitor to use.

Le mar. 12 nov. 2019 à 03:56, Daniel.Sun  a écrit :

> Here is the PR "GROOVY-9262: Bump asm to 7.2":
> https://github.com/apache/groovy/pull/1081
>
>
> Cheers,
> Daniel.Sun
>
>
>
> -
> Apache Groovy committer & PMC member
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: [VOTE] Release Apache Groovy 3.0.0-rc-1 (take 2)

[Cédric Champeau]

Yeah I just find it funny, when you release a "release candidate" knowing
it's not a release candidate :)

Le mar. 22 oct. 2019 à 17:40, Daniel.Sun  a écrit :

> Hi Cédric,
>
> > To me, it _implies_ that there will be a 3.0 rc2 for Groovy.
> Yep ;-)   As Paul said, one part which has only recently been finished
> and still needs a bit more polishing is a revamped groovydoc. So 3.0.0-rc-2
> will be released after groovydoc has been polished.
> 3.0.0-rc-1 should be quite stable now, but we still wish we could get
> feedback if users find critical issues which will prevent Apache Groovy
> 3.0.0 from being used in production.
>
> Cheers,
> Daniel.Sun
>
>
>
> -
> Apache Groovy committer & PMC member
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: [VOTE] Release Apache Groovy 3.0.0-rc-1 (take 2)

[Cédric Champeau]

That's a bit surprising of a release candidate, IMO. A release candidate
should mean "hey if there's no bug report, that's _exactly_ that that we
publish as final". Here you're saying that in any case, you're going to
change the dependency to Ivy. To me, it _implies_ that there will be a 3.0
rc2 for Groovy.

Le mar. 22 oct. 2019 à 17:19, Daniel.Sun  a écrit :

> If Ivy 2.5.0 GA is not released before Groovy 3.0.0 GA, we have to
> downgrade
> Ivy to 2.4.0 GA.
>
> Cheers,
> Daniel.Sun
>
>
>
> -
> Apache Groovy committer & PMC member
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: [VOTE] Release Apache Groovy 3.0.0-rc-1

[Cédric Champeau]

As the README says, you need to use the Gradle version which is declared in
gradle.properties, which is 5.6.3 for this release.

Le mar. 22 oct. 2019 à 11:51, Guillaume Laforge  a
écrit :

> QQ, it's perhaps just a Gradle issue, but with the local version of Gradle
> I have (Gradle 5.3.1), I can't create the wrapper and I get:
>
>  ↳  gradle -b wrapper.gradle wrapper
>
>
> FAILURE: Build failed with an exception.
>
>
> * Where:
>
> Settings file
> '/Users/glaforge/Downloads/groovy-3.0.0-rc-1/settings.gradle' line: 60
>
>
> * What went wrong:
>
> A problem occurred evaluating settings 'groovy'.
>
> > There is no feature named GROOVY_COMPILATION_AVOIDANCE
>
> On Tue, Oct 22, 2019 at 11:19 AM Paul King  wrote:
>
>> Dear development community,
>>
>> I am happy to start the VOTE thread for a Groovy 3.0.0-rc-1 release!
>>
>> This release includes over 50 bug fixes/improvements as outlined in the
>> changelog:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12345982
>>
>> Groovy 3 is nearing lockdown status for final release.
>> One part which has only recently been finished and still needs a bit more
>> polishing is a revamped groovydoc. It no longer requires antlr2. Groovy
>> files are parsed using antlr4 and Java using com.github.javaparser. Because
>> this new version is less stable than the rest of the release it currently
>> is disabled by default and enabled with the 'preview.groovydoc.antlr4'
>> system property. The plan is for this property to be removed before final
>> release but feedback on existing functionality welcome. You might need to
>> include additional dependent jars on your classpath when using the current
>> version.
>>
>> Tag:
>> https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_3_0_0_RC_1
>> Tag commit id: 2ede5187ca8e6adf0986d8284009abfd48876998
>>
>> The artifacts to be voted on are located as follows (r36439).
>> Source release:
>> https://dist.apache.org/repos/dist/dev/groovy/3.0.0-rc-1/sources
>> Convenience binaries:
>> https://dist.apache.org/repos/dist/dev/groovy/3.0.0-rc-1/distribution
>>
>> Release artifacts are signed with a key from the following file:
>> https://dist.apache.org/repos/dist/dev/groovy/KEYS
>>
>> Please vote on releasing this package as Apache Groovy 3.0.0-rc-1.
>>
>> Reminder on ASF release approval requirements for PMC members:
>> http://www.apache.org/legal/release-policy.html#release-approval
>> Hints on validating checksums/signatures (but replace md5sum with
>> sha256sum):
>> https://www.apache.org/info/verification.html
>>
>> The vote is open for the next 72 hours and passes if a majority of at
>> least three +1 PMC votes are cast.
>>
>> [ ] +1 Release Apache Groovy 3.0.0-rc-1
>> [ ]  0 I don't have a strong opinion about this, but I assume it's ok
>> [ ] -1 Do not release Apache Groovy 3.0.0-rc-1 because...
>>
>> Here is my vote:
>>
>> +1 (binding)
>>
>>
>
> --
> Guillaume Laforge
> Apache Groovy committer
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Twitter: @glaforge 
>

Re: groovy project's src/main/* folders

[Cédric Champeau]

This is not just about Gradle, and not related to the build cache. There
are different things: mixing Java and Groovy sources in a single source
tree **only** makes sense for sources which are _joint compiled_. Otherwise
you're just slowing down your build arbitrarily, because Groovy has to
generate stubs for all Java classes just in case they would be used by
Groovy sources. The intuitive part to me is that Groovy sources should live
in `src/main/groovy`, the Java sources in `src/main/java`, and that joint
sources should be in another directory (we don't do this). Then it's also
about performance: it means we can use incremental Java compilation, and
soon Groovy incremental compilation too. So this is not just about what a
human would think, this is just about good separation of concerns, and
software architecture in general.

Le dim. 19 mai 2019 à 00:29, Paul King  a écrit :

> Yes, the split of java/groovy files into src/main[java|groovy] can be
> considered a bit of an anti-pattern for humans, it does help gradle. Gradle
> supports both but performs better when split strictly according to
> guidelines, e.g. for build caching purposes. All of the subprojects should
> be structured according to gradle guidelines but I don't think we quite
> ever got src/main and src/test in groovy to be fully compliant. We should
> probably look at that again.
>
> On Sun, May 19, 2019 at 5:35 AM Milles, Eric (TR Tech, Content & Ops) <
> eric.mil...@thomsonreuters.com> wrote:
>
>> I've been curious about the split made to the main sources for a while
>> now.  https://github.com/apache/groovy/tree/master/src/main
>>
>>
>> Since src/main/groovy can contain both java and groovy sources, why are
>> there any sources in src/main/java?  For me, it makes locating and
>> navigating cumbersome since I need to guess which folder a source is likely
>> to be in.  And I didn't expect to find any "org.codehaus" packages in
>> src/main/groovy, but there are some in there.  Could they be ported to Java
>> so that src/main/groovy only contains the groovy.* packages?  Or could all
>> the packages in src/main/java be moved to src/main/groovy?
>>
>

Re: Binary compatibility fixed + Kotlin DSL

[Cédric Champeau]

Well I think I disagree with most of what you just said. And Gradle Inc
will not deprecate the groovy support anytime soon. I'm well placed to know
it's not even in discussion. The only thing that I see could lead to such a
decision would be that groovy doesn't run on future versions of the JVM.
Let's not take decisions on speculations, but facts.

Le mer. 20 mars 2019 à 22:35, Sergio del Amo Caballero <
sergio.del...@softamo.com> a écrit :

> I don’t know what do you imply that I am trying to hide.
>
> I think:
>
> - Gradle Groovy DSL helps Groovy adoption and thus survival.
>
> same as Geb DSL on top of Selenium helps Groovy adoption and thus
> survival.
>
> I think if everyone moves to Kotlin DSL, Gradle Inc will lose interest in
> maintaining Groovy Gradle DSL and eventually deprecate the Groovy Gradle
> DSL and remove it and hurt Groovy adoption and thus survival .
>
> I think that Apache Groovy build transitions towards Kotlin DSL is a
> signal towards prompting that move.
>
>  About maintaining the build itself:
>
> - If the only person touching the build is going to be someone with Kotlin
> and Groovy knowledge, then I would say better to have the DSL in the
> language they are more productive with it.
> - If persons, who touch the build, don’t know Kotlin, I think that it is
> another barrier. I assume that someone with no Kotlin Knowledge but using
> the Kotlin DSL and assisted by the IDE support is going to do a worst job
> than someone with a lot of Groovy knowledge using the Groovy Gradle DSL.
>
> Sergio del Amo
>
> On 20 Mar 2019, at 21:50, Cédric Champeau 
> wrote:
>
> And do you honestly think that trying to hide that by not using the Kotlin
> DSL would change anything?
>
> Le mer. 20 mars 2019 à 21:45, Sergio Del Amo 
> a écrit :
>
>>
>> I do in fact see this as at least a minor threat.  If Groovy itself can't
>> even manage to use the Gradle Groovy DSL, what hope remains for the
>> survival of the Groovy DSL?
>>
>>
>> Agree. I see a threat at least to Gradle Groovy DSL survival and probably
>> to Groovy in general. One may reason: If the Groovy programming language
>> build, which is manipulated by the people with more Groovy knowledge in the
>> planet, moved to Kotlin DSL, why should anyone else keep using the Gradle
>> Groovy DSL.
>>
>> Sergio
>>
>> On 20 Mar 2019, at 16:00, Milles, Eric (TR Tech, Content & Ops) <
>> eric.mil...@thomsonreuters.com> wrote:
>>
>> I tried to get some info from Gradle on adding Eclipse DSLD for Gradle
>> and they scoffed at me.  They said it was a multi-person, multi-year effort
>> so why even try.  I was able to get some very basic support without that
>> much effort.  It could be moved forward and probably ported to IntelliJ as
>> well if there was some interest and support.
>>
>>
>> With regards to the change to the Groovy build script.  I'm not sure
>> newcomers are diving into the build scripts and making edits there.
>> My intuition is that they are running "./gradlew build" or whatever the
>> command is.  As long as the scripts run successfully, I'd posit a newcomer
>> is quite happy.
>>
>>
>> I do in fact see this as at least a minor threat.  If Groovy itself can't
>> even manage to use the Gradle Groovy DSL, what hope remains for the
>> survival of the Groovy DSL?
>>
>>

Re: Binary compatibility fixed + Kotlin DSL

[Cédric Champeau]

And do you honestly think that trying to hide that by not using the Kotlin
DSL would change anything?

Le mer. 20 mars 2019 à 21:45, Sergio Del Amo  a
écrit :

>
> I do in fact see this as at least a minor threat.  If Groovy itself can't
> even manage to use the Gradle Groovy DSL, what hope remains for the
> survival of the Groovy DSL?
>
>
> Agree. I see a threat at least to Gradle Groovy DSL survival and probably
> to Groovy in general. One may reason: If the Groovy programming language
> build, which is manipulated by the people with more Groovy knowledge in the
> planet, moved to Kotlin DSL, why should anyone else keep using the Gradle
> Groovy DSL.
>
> Sergio
>
> On 20 Mar 2019, at 16:00, Milles, Eric (TR Tech, Content & Ops) <
> eric.mil...@thomsonreuters.com> wrote:
>
> I tried to get some info from Gradle on adding Eclipse DSLD for Gradle and
> they scoffed at me.  They said it was a multi-person, multi-year effort so
> why even try.  I was able to get some very basic support without that
> much effort.  It could be moved forward and probably ported to IntelliJ as
> well if there was some interest and support.
>
>
> With regards to the change to the Groovy build script.  I'm not sure
> newcomers are diving into the build scripts and making edits there.
> My intuition is that they are running "./gradlew build" or whatever the
> command is.  As long as the scripts run successfully, I'd posit a newcomer
> is quite happy.
>
>
> I do in fact see this as at least a minor threat.  If Groovy itself can't
> even manage to use the Gradle Groovy DSL, what hope remains for the
> survival of the Groovy DSL?
>
>

Binary compatibility fixed + Kotlin DSL

[Cédric Champeau]

Hi folks,

Some of you have noticed that I have fixed the binary compatibility reports
on master. I also fixed checkstyle and CodeNarc, which were failing to
execute. I did not, however, fixed the many errors we see when running
those, nor the ones with spotbugs. It's a bit annoying because it makes the
"build" task fail, but we can live with that for some time.

Some of you noticed, because this is the first time I introduce a Gradle
Kotlin DSL script for this. Let me explain why: first, it gives a better
user experience: completion in the IDE is working, and you can navigate to
sources. Second, its syntax is so close to the Groovy one that if I had
replaced .kts with .groovy, I bet hardly anyone would have noticed.

To me it's a step towards a better build: we should'nt see this as a threat
to Groovy, and I'm not saying that it wouldn't have been possible to
achieve the same thing with Groovy, but this is the reality now: the Kotlin
DSL for Gradle gives a better UX than the Groovy one. I think it' going to
be particularly important for newcomers in the future. And as I am the main
maintainer of the build, it's also important to me, given the little amount
of time I can give to this project. My plan is to migrate the build to
Kotlin, slowly but surely, and as part of this effort, remove a lot of the
bad practices we're using, or internal APIs. Publishing for example is in a
terrible state.

But coming back to this build script: take a look at it and tell me if it's
not as clear, or even more readable than the Groovy one (you can compare
with the old binarycompatibility.groovy file). Also, I strongly believe
that's an opportunity for us to learn from Kotlin and maybe borrow some if
its features

So I'm asking you to vote on *keeping* this .kts file, and actually
migrating the build incrementally. If you see Kotlin as a threat, I'd
understand but would be disappointed.

Thanks,

Re: About polish the generics type syntax for closure

[Cédric Champeau]

I'm 100% sure a syntax like that has been discussed in the past, and
discarded for different reasons:

1. consistency between using annotations and a type-checking only feature
2. what about polymorphic closures (aka closures which accept different
kind of arguments)
3. the arrow syntax making it hard to read, in particular when the argument
types have generics themselves

Happy to reopen the discussion, but please keep this in mind.

Le mer. 13 févr. 2019 à 09:39, Daniel Sun  a
écrit :

> Hi Guillaume,
>
> > What about the various cases, like no-arg closures?
>   How about `Closure< -> V>` ?
>
>   It is similar to the syntax of closure. More examples:
>
> 1)
> `Closure< String, Number -> Date>`
>
> is responding to
>
> ```
> { String x, Number y ->
>  return new Date()
> }
> ```
>
> 2)
> `Closure<   -> Date>`
>
> is responding to
>
> ```
> {  ->
>  return new Date()
> }
> ```
>
> 3)
> `Closure` means argument generics type information is not available
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: Gant is to be deleted, or will someone preserve it?

[Cédric Champeau]

An alternative is to "archive" the project in GitHub. It's going to be
read-only (see the "settings" tab).

Le sam. 2 févr. 2019 à 09:46, Russel Winder  a écrit :

> On Sat, 2019-02-02 at 09:18 +0100, Guillaume Laforge wrote:
> > Why deleting it?
> > Keep it for posterity! :-)
>
> Someone, or some people, then needs to step up and volunteer to be an
> owner of
> the Gant organisation on GitHub.
>
> --
> Russel.
> ===
> Dr Russel Winder  t: +44 20 7585 2200
> 41 Buckmaster Roadm: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk
>
>

Re: About the lazy consensus on Pull Requests

[Cédric Champeau]

I agree that no "big change" should be merged without review. 72h may sound
a lot, but it's not.


Le dim. 27 janv. 2019 à 22:01, Daniel.Sun  a écrit :

> I agree with you on most of your opinions, but some of them are a bit ideal
> for an open source project such as Apache Groovy IMHO. I feel that it is
> really hard to please all...
>
> P.S. One of my big projects has already used groovy 3.0.0-alpha-4, so far
> so
> good.
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: [PROPOSAL]Provide an option to generate stubs in in-momery file system for better compiling performance

[Cédric Champeau]

It's an interesting idea. I like that it's hidden behind a flag, because
sometimes you want to keep the stubs. That must be the case for IDEs that
implement "some kind" of incremental compilation.

Le ven. 18 janv. 2019 à 09:44, Daniel Sun  a
écrit :

> Hi all,
>
> [Background]
>Groovy's joint compiler will generate a lot of stubs for groovy
> source files, many of the stubs are useless and written to disk and clean
> later. When project contains a lot of groovy source files, the performance
> of compiling is not good.
>
> [Proposal]
>   I propose to add an option(e.g. `groovy.generate.stubs.in.memory`)
> to
> generate stubs in in-momery file system[1]. We can get the generated stub
> files from the the in-memory file system with `StandardJavaFileManager`[2]
> .
> Here is the `JavaCompiler` usage[3].
>
> [Benefits]
>  We can avoid writing lots of stub files to disk and subsequent
> cleaning, in addition, reading stub files from memory will be much faster
> than reading from disk.
>
>
>   Any thoughts?
>
> Cheers,
> Daniel.Sun
> [1] https://github.com/google/jimfs
> [2]
>
> https://docs.oracle.com/javase/7/docs/api/javax/tools/StandardJavaFileManager.html
> [3]
>
> https://github.com/danielsun1106/SmartASMifier/blob/master/SmartASMifier.groovy#L81-L88
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: [PROPOSAL]About creating open collective for Groovy programming language in the name of Groovy Community

[Cédric Champeau]

My 2 cents: as a Groovy enthusiast, I like the idea and support it. As a
Groovy committer and PMC member, however, I have some things to say.

First, it's not very different to have one company paying one developer
full time to develop Groovy and contribute features than it is to have a
collective "sponsoring" Groovy. The process of integration is the same: we,
as PMC members, must make sure neutrality is followed and that no entity is
coercing Groovy for its own needs. That's why we try to have PMC members
from different companies. Second, Groovy is a brand name owned by the ASF.
As such, you should not use "Apache Groovy" without asking for permission
from legal. It should also be extremely clear that this collective is not
affiliated with the ASF in any way. The best way for me to do it is that
effectively no PMC member, and no committer is part of the collective,
otherwise there's a conflict of interest. Especially, the ASF itself is
looking for donations, and donations MUST NOT be directed at a specific
project. There are good reasons for this (in particular, we all benefit
from the same infrastructure, the same member affiliation, as any other
project). So it's clear to be that this collective must not be affiliated
to Groovy. Should you need sponsorship for developing Groovy, feel free to
do it, but it should never mention that it's an Apache thing. This can make
it rather complicated with open collective as it requires a GitHub
repository with stars. I feel you will NOT be allowed to use
`apache/groovy` for the reasons I described. `groovy/groovy` is an old
repo, and in any case, the ASF may want to make sure its trademarks are
respected by preventing you to use this repository.

Said differently: I like the idea, but you need to find a way to do it
which doesn't involve trademarks or ASF ownership.


Le jeu. 10 janv. 2019 à 02:05, Daniel.Sun  a écrit :

> My pleasure :-)
>
> Once the open collective created, we will discuss the rules to encourage
> people to involve the development of Groovy. They have no time on Groovy
> during work time and may be tired after work, but maybe they want to earn
> additional money for some reason.
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: [VOTE] Release Apache Groovy 2.5.5

[Cédric Champeau]

+1

Le dim. 23 déc. 2018 à 03:20, John Wagenleitner 
a écrit :

> +1 (binding)
>
> On Thu, Dec 20, 2018 at 4:28 PM Paul King  wrote:
>
>>
>> Dear development community,
>>
>> I am happy to start the VOTE thread for a Groovy 2.5.5 release!
>>
>> This release includes 20 bug fixes/improvements as outlined in the
>> changelog:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12344435
>>
>> Tag:
>> https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_5_5
>> Tag commit id: 5014d858d081ca463d03128e5d6eb2440184f492
>>
>> The artifacts to be voted on are located as follows (r31631).
>> Source release:
>> https://dist.apache.org/repos/dist/dev/groovy/2.5.5/sources
>> Convenience binaries:
>> https://dist.apache.org/repos/dist/dev/groovy/2.5.5/distribution
>>
>> Release artifacts are signed with a key from the following file:
>> https://dist.apache.org/repos/dist/dev/groovy/KEYS
>>
>> Please vote on releasing this package as Apache Groovy 2.5.5.
>>
>> Reminder on ASF release approval requirements for PMC members:
>> http://www.apache.org/legal/release-policy.html#release-approval
>> Hints on validating checksums/signatures (but replace md5sum with
>> sha256sum):
>> https://www.apache.org/info/verification.html
>>
>> The vote is open for the next 72 hours and passes if a majority of at
>> least three +1 PMC votes are cast.
>>
>> [ ] +1 Release Apache Groovy 2.5.5
>> [ ]  0 I don't have a strong opinion about this, but I assume it's ok
>> [ ] -1 Do not release Apache Groovy 2.5.5 because...
>>
>> Here is my vote:
>>
>> +1 (binding)
>>
>>

Re: [VOTE] Release Apache Groovy 2.4.16

[Cédric Champeau]

No time yet, I'll check tonight if I find time.

Le mer. 12 déc. 2018 à 14:39, Paul King  a écrit :

> Still needing one more vote on this release. Anyone got time to check?
>
> On Sun, Dec 9, 2018 at 9:59 PM Paul King  wrote:
>
>>
>> Dear development community,
>>
>> I am happy to start the VOTE thread for a Groovy 2.4.16 release! This is
>> a maintenance release of the 2.4 branch and the last planned release for
>> this branch.
>>
>> This release includes 17 bug fixes/improvements as outlined in the
>> changelog:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12342996
>>
>> Tag:
>> https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_4_16
>> Tag commit id: f800b9f8ba85b5e328b545c4d8880dd47ed514f3
>>
>> The artifacts to be voted on are located as follows (r31469).
>> Source release:
>> https://dist.apache.org/repos/dist/dev/groovy/2.4.16/sources
>> Convenience binaries:
>> https://dist.apache.org/repos/dist/dev/groovy/2.4.16/distribution
>>
>> Release artifacts are signed with a key from the following file:
>> https://dist.apache.org/repos/dist/dev/groovy/KEYS
>>
>> Please vote on releasing this package as Apache Groovy 2.4.16.
>>
>> Reminder on ASF release approval requirements for PMC members:
>> http://www.apache.org/legal/release-policy.html#release-approval
>> Hints on validating checksums/signatures (but replace md5sum with
>> sha256sum):
>> https://www.apache.org/info/verification.html
>>
>> The vote is open for the next 72 hours and passes if a majority of at
>> least three +1 PMC votes are cast.
>>
>> [ ] +1 Release Apache Groovy 2.4.16
>> [ ]  0 I don't have a strong opinion about this, but I assume it's ok
>> [ ] -1 Do not release Apache Groovy 2.4.16 because...
>>
>> Here is my vote:
>>
>> +1 (binding)
>>
>>

Re: About downgrading gradle to 4.10.3 on master

[Cédric Champeau]

The fix is not to use the internal APIs and rely on the "maven-publish"
plugin instead. Due to historical reasons, our publishing is a bit of a
mess, to say the least, so I was reluctant on changing it to avoid
breakages when publishing. One of the issues is that with our current
publishing strategy it's hard to get the generated POMs to compare with the
new strategy and make sure we miss nothing.

Le mar. 11 déc. 2018 à 18:47, Daniel.Sun  a écrit :

> Hi Andres,
>
> That's great :-)
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: About downgrading gradle to 4.10.3 on master

[Cédric Champeau]

It's not really surprising, the build has been using internal APIs for
years, I'm surprised it didn't break earlier :)

Le mar. 11 déc. 2018 à 17:08, Andres Almiray  a écrit :

> Hi Daniel,
>
> Can the failure be reproduced locally or is it. TeamCity specific issue?
>
> Best
> Andres
>
> Sent from my primitive tricorder
>
> > On Dec 11, 2018, at 17:04, Daniel.Sun  wrote:
> >
> > Hi all,
> >
> >  After upgrading gradle to 5.0, our build on teamcity has been
> > failing... Here is the error message:
> >
> > org.gradle.api.InvalidUserDataException: File
> >
> '/var/teamcity/buildagent-jdk8/work/cba52975ead8186f/target/poms/pom-groovy.xml'
> > specified for property 'mavenDescriptor' does not exist. [1]
> >
> >  As a result, groovy snapshots fails to publish to
> > https://oss.jfrog.org/oss-snapshot-local/ , and impacts some impatient
> users
> > who eagerly want to use the latest version of groovy 3.0.
> >
> >  To be honest, I'm not a gradle expert and failed to fix the build
> > issue, so I propose to downgrade gradle to 4.10.3 for the time being if
> the
> > build issue has not been fixed for a long time.
> >
> >  BTW, if gradle expert Cedric could set aside some spare time to look
> > into the build issue, that would be great :-)
> >
> > Cheers,
> > Daniel.Sun
> >
> > [1]
> >
> http://ci.groovy-lang.org/viewLog.html?buildId=53717=buildResultsDiv=Groovy_Jdk8Build_PlusSnapshotDeploy=1
> >
> >
> >
> >
> >
> > -
> > Daniel Sun
> > Apache Groovy committer
> > Blog: http://blog.sunlan.me
> > Twitter: @daniel_sun
> >
> > --
> > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: [VOTE] Move the Groovy repositories on git-wip-us.apache.org to gitbox.apache.org

[Cédric Champeau]

+1 you can use git remote seturl to avoid cloning again.

Le dim. 9 déc. 2018 à 05:52, John Wagenleitner 
a écrit :

> +1
>
> On Sat, Dec 8, 2018, 1:54 PM Paul King 
>> As per DanielG's attached email, we need to move our remaining git-wip
>> repos:
>> Apache Groovy
>> Repository name:Description:Last changed:Links:
>> groovy.git  Apache
>> Groovy < 2 days ago Summary
>>  | Short
>> Log 
>>  | Full Log
>>  | Tree
>> View 
>> groovy-examples.git
>>  Apache
>> Groovy examples 16 weeks ago Summary
>> 
>>  | Short Log
>> 
>>  | Full Log
>> 
>>  | Tree View
>> 
>> groovy-release.git
>>  Apache
>> groovy 27 days ago Summary
>> 
>>  | Short Log
>> 
>>  | Full Log
>> 
>>  | Tree View
>> 
>>
>>
>> The website related ones are already moved. It won't affect our workflow
>> but folks will most likely need to re-clone their local repo clones as a
>> one off activity since the urls will change.
>>
>> My vote:  +1 (binding)
>>
>> Cheers, Paul.
>>
>> On Sat, Dec 8, 2018 at 2:53 AM Daniel Gruno  wrote:
>>
>>> [IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE
>>>   DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS]
>>>
>>> Hello Apache projects,
>>>
>>> I am writing to you because you may have git repositories on the
>>> git-wip-us server, which is slated to be decommissioned in the coming
>>> months. All repositories will be moved to the new gitbox service which
>>> includes direct write access on github as well as the standard ASF
>>> commit access via gitbox.apache.org.
>>>
>>> ## Why this move? ##
>>> The move comes as a result of retiring the git-wip service, as the
>>> hardware it runs on is longing for retirement. In lieu of this, we
>>> have decided to consolidate the two services (git-wip and gitbox), to
>>> ease the management of our repository systems and future-proof the
>>> underlying hardware. The move is fully automated, and ideally, nothing
>>> will change in your workflow other than added features and access to
>>> GitHub.
>>>
>>> ## Timeframe for relocation ##
>>> Initially, we are asking that projects voluntarily request to move
>>> their repositories to gitbox, hence this email. The voluntary
>>> timeframe is between now and January 9th 2019, during which projects
>>> are free to either move over to gitbox or stay put on git-wip. After
>>> this phase, we will be requiring the remaining projects to move within
>>> one month, after which we will move the remaining projects over.
>>>
>>> To have your project moved in this initial phase, you will need:
>>>
>>> - Consensus in the project (documented via the mailing list)
>>> - File a JIRA ticket with INFRA to voluntarily move your project repos
>>>over to gitbox (as stated, this is highly automated and will take
>>>between a minute and an hour, depending on the size and number of
>>>your repositories)
>>>
>>> To sum up the preliminary timeline;
>>>
>>> - December 9th 2018 -> January 9th 2019: Voluntary (coordinated)
>>>relocation
>>> - January 9th -> February 6th: Mandated (coordinated) relocation
>>> - February 7th: All remaining repositories are mass migrated.
>>>
>>> This timeline may change to accommodate various scenarios.
>>>
>>> ## Using GitHub with ASF repositories ##
>>> When your project has moved, you are free to use either the ASF
>>> repository system (gitbox.apache.org) OR GitHub for your development
>>> and code pushes. To be able to use GitHub, please follow the primer
>>> at: https://reference.apache.org/committer/github
>>>
>>>
>>> We appreciate your understanding of this issue, and hope that your
>>> project can coordinate voluntarily moving your repositories in a
>>> timely manner.
>>>
>>> All settings, such as commit mail targets, issue linking, PR
>>> notification schemes etc will automatically be migrated to gitbox as
>>> well.
>>>
>>> With regards, Daniel on behalf of ASF Infra.
>>>
>>> PS:For inquiries, please reply to us...@infra.apache.org, not your
>>> 

Re: About the enhanced version of `Properties`, i.e. `GProperties`

[Cédric Champeau]

+1 to using a different file extension for gproperties

Le mar. 6 nov. 2018 à 11:32, Daniil Ovchinnikov <
daniil.ovchinni...@jetbrains.com> a écrit :

>  we can not replace Properties in existing groovy
> code easily because we have to change the file extension
>
>
> Exactly this.
>
> Also please consider tooling. We already have support for .properties in
> IntelliJ based on file extension.
> If .properties would be used for GProperties, then user should go in
> settings and change mapping for all .properties files to be handled as
> GProperties.
> And what if some file is actually Properties one and another is
> GProperties? It’s just confusing.
>
> Imagine you create a new language (say Groovy) which is syntax-compatible
> with Java and you use its default extension (.java), because why not,
> otherwise you should change file extension of your existing .java files.
>
> —
>
> Daniil Ovchinnikov
> JetBrains
>
> On 3 Nov 2018, at 07:11, Daniel.Sun  wrote:
>
> No. GProperties to Properties is similar with GString to String,
> GProperties
> is much more powerful than Properties, so I recommend groovy users use
> GProperties where Properties is used. If GProperties only process the file
> with new file extension, we can not replace Properties in existing groovy
> code easily because we have to change the file extension.
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
>
>

Can we get rid of illegal reflective access operation warnings?

[Cédric Champeau]

Hi,

It's long overdue, but the status quo is not really nice. Running Groovy on
Java 9+ gives warnings like this:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.codehaus.groovy.vmplugin.v7.Java7$1
(file:/tmp/groovy-2.5.3/target/groovy-2.5.3/lib/groovy-2.5.3.jar) to
constructor java.lang.invoke.MethodHandles$Lookup(java.lang.Class,int)
WARNING: Please consider reporting this to the maintainers of
org.codehaus.groovy.vmplugin.v7.Java7$1

Or

WARNING: Illegal reflective access by
org.codehaus.groovy.reflection.CachedClass
(file:/home/tcagent1/agent/work/668602365d1521fc/subprojects/ivy/build/integ%20test/lib/groovy-all-2.4.12.jar)
to method java.lang.Object.finalize()
WARNING: Please consider reporting this to the maintainers of
org.codehaus.groovy.reflection.CachedClass
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release

I know it's hard to get rid of those, but we have to do something.
Unfortunately I don't have the expertise here...

Re: [VOTE] Release Apache Groovy 2.5.3 (take 2)

[Cédric Champeau]

Indeed this works. Changing to +1 then.

Le ven. 12 oct. 2018 à 14:50, Paul King  a écrit :

> Yes works for me on 4 OSs so long as GROOVY_HOME isn't hard-coded to some
> other value.
> And I observe the same behavior as reported by Cédric with 2.5.2 when
> GROOVY_HOME is hard-coded.
>
> Cheers, Paul.
>
> On Fri, Oct 12, 2018 at 10:42 PM John Wagenleitner <
> john.wagenleit...@gmail.com> wrote:
>
>> This can be caused by having GROOVY_HOME pointing to a different release,
>> unsetting that environment variable or setting to the 2.5.3 directory
>> should fix it.
>>
>> On Fri, Oct 12, 2018 at 1:05 AM Cédric Champeau <
>> cedric.champ...@gmail.com> wrote:
>>
>>> At this point, -1. See below.
>>>
>>> $ gpg --verify apache-groovy-src-2.5.3.zip.asc
>>> gpg: assuming signed data in 'apache-groovy-src-2.5.3.zip'
>>> gpg: Signature made Thu 11 Oct 2018 07:34:42 AM CEST
>>> gpg:using RSA key 6A65176A0FB1CD0B
>>> gpg: Good signature from "Paul King " [unknown]
>>> gpg: aka "Paul King " [unknown]
>>> gpg: aka "Paul King "
>>> [unknown]
>>> gpg: aka "Paul King " [unknown]
>>> gpg: aka "keybase.io/paulk_asert "
>>> [unknown]
>>>
>>> $  sha256sum apache-groovy-src-2.5.3.zip
>>> 7fe017485a22afa1357bd5223872304ac04525474b9a68e84f57c522d9078380
>>> apache-groovy-src-2.5.3.zip
>>> $ cat apache-groovy-src-2.5.3.zip.sha256
>>> 7fe017485a22afa1357bd5223872304ac04525474b9a68e84f57c522d9078380
>>>
>>> $ cd groovy-2.5.3
>>> $ gradle -b wrapper.gradle wrapper
>>> $ ./gradlew dist --scan
>>>
>>> https://scans.gradle.com/s/pwkrb6rzrqzyu
>>>
>>> It seems the build needs to be fixed again: it's not fetched from cache
>>> after a "clean" anymore, so probably something broke caching. See
>>> https://scans.gradle.com/s/pwkrb6rzrqzyu/timeline?showCache=kd7f3knycujqg
>>>
>>> $ cd target
>>> $ unzip apache-groovy-binary-2.5.3.zip
>>> $ cd groovy-2.5.3
>>> $ bin/groovy -version
>>> Error: Could not find or load main class
>>> org.codehaus.groovy.tools.GroovyStarter
>>> Caused by: java.lang.ClassNotFoundException:
>>> org.codehaus.groovy.tools.GroovyStarter
>>>
>>> $ cd bin
>>> $ ./groovy -version
>>> Error: Could not find or load main class
>>> org.codehaus.groovy.tools.GroovyStarter
>>> Caused by: java.lang.ClassNotFoundException:
>>> org.codehaus.groovy.tools.GroovyStarter
>>>
>>> So it seems the start scripts are broken.
>>>
>>> Le ven. 12 oct. 2018 à 09:39, Andres Almiray  a
>>> écrit :
>>>
>>>> +1 (binding)
>>>>
>>>> All tests ran OK.
>>>> Tested local 2.5.3 with JaCoCo regarding a pending PR on @Gnenerated
>>>> support: all good as well.
>>>>
>>>> ---
>>>> Java Champion; Groovy Enthusiast
>>>> JCP EC Associate Seat
>>>> http://andresalmiray.com
>>>> http://www.linkedin.com/in/aalmiray
>>>> --
>>>> What goes up, must come down. Ask any system administrator.
>>>> There are 10 types of people in the world: Those who understand binary,
>>>> and those who don't.
>>>> To understand recursion, we must first understand recursion.
>>>>
>>>>
>>>> On Thu, Oct 11, 2018 at 5:55 AM Paul King  wrote:
>>>>
>>>>> Dear development community,
>>>>>
>>>>> I am happy to start the VOTE thread for a Groovy 2.5.3 release!
>>>>>
>>>>> This release includes 52 bug fixes/improvements as outlined in the
>>>>> changelog:
>>>>>
>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12343876
>>>>>
>>>>> Tag:
>>>>> https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_5_3
>>>>> Tag commit id: 676d5a7d66f540a831779c208878df39d08938b5
>>>>>
>>>>> The artifacts to be voted on are located as follows (r30001).
>>>>> Source release:
>>>>> https://dist.apache.org/repos/dist/dev/groovy/2.5.3/sources
>>>>> Convenience binaries:
>>>>> https://dist.apache.org/repos/dist/dev/groovy/2.5.3/distribution
>>>>>
>>>>> Release artifacts are signed with a key from the following file:
>>>>> https://dist.apache.org/repos/dist/dev/groovy/KEYS
>>>>>
>>>>> Please vote on releasing this package as Apache Groovy 2.5.3.
>>>>>
>>>>> Reminder on ASF release approval requirements for PMC members:
>>>>> http://www.apache.org/legal/release-policy.html#release-approval
>>>>> Hints on validating checksums/signatures (but replace md5sum with
>>>>> sha256sum):
>>>>> https://www.apache.org/info/verification.html
>>>>>
>>>>> The vote is open for the next 72 hours and passes if a majority of at
>>>>> least three +1 PMC votes are cast.
>>>>>
>>>>> [ ] +1 Release Apache Groovy 2.5.3
>>>>> [ ]  0 I don't have a strong opinion about this, but I assume it's ok
>>>>> [ ] -1 Do not release Apache Groovy 2.5.3 because...
>>>>>
>>>>> Here is my vote:
>>>>>
>>>>> +1 (binding)
>>>>>
>>>>>

Re: [VOTE] Release Apache Groovy 2.5.3 (take 2)

[Cédric Champeau]

We should add a distribution test as part of the release automation. I
wanted to do this but didn't find time...

Le ven. 12 oct. 2018 à 10:29, Andres Almiray  a écrit :

> Ah yes, indeed. Consuming Groovy 2.5.3 as a library is OK. Consuming it as
> a standalone distro is broken like Cedric shows.
>
> ---
> Java Champion; Groovy Enthusiast
> JCP EC Associate Seat
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary,
> and those who don't.
> To understand recursion, we must first understand recursion.
>
>
> On Fri, Oct 12, 2018 at 8:05 AM Cédric Champeau 
> wrote:
>
>> At this point, -1. See below.
>>
>> $ gpg --verify apache-groovy-src-2.5.3.zip.asc
>> gpg: assuming signed data in 'apache-groovy-src-2.5.3.zip'
>> gpg: Signature made Thu 11 Oct 2018 07:34:42 AM CEST
>> gpg:using RSA key 6A65176A0FB1CD0B
>> gpg: Good signature from "Paul King " [unknown]
>> gpg: aka "Paul King " [unknown]
>> gpg: aka "Paul King "
>> [unknown]
>> gpg: aka "Paul King " [unknown]
>> gpg: aka "keybase.io/paulk_asert "
>> [unknown]
>>
>> $  sha256sum apache-groovy-src-2.5.3.zip
>> 7fe017485a22afa1357bd5223872304ac04525474b9a68e84f57c522d9078380
>> apache-groovy-src-2.5.3.zip
>> $ cat apache-groovy-src-2.5.3.zip.sha256
>> 7fe017485a22afa1357bd5223872304ac04525474b9a68e84f57c522d9078380
>>
>> $ cd groovy-2.5.3
>> $ gradle -b wrapper.gradle wrapper
>> $ ./gradlew dist --scan
>>
>> https://scans.gradle.com/s/pwkrb6rzrqzyu
>>
>> It seems the build needs to be fixed again: it's not fetched from cache
>> after a "clean" anymore, so probably something broke caching. See
>> https://scans.gradle.com/s/pwkrb6rzrqzyu/timeline?showCache=kd7f3knycujqg
>>
>> $ cd target
>> $ unzip apache-groovy-binary-2.5.3.zip
>> $ cd groovy-2.5.3
>> $ bin/groovy -version
>> Error: Could not find or load main class
>> org.codehaus.groovy.tools.GroovyStarter
>> Caused by: java.lang.ClassNotFoundException:
>> org.codehaus.groovy.tools.GroovyStarter
>>
>> $ cd bin
>> $ ./groovy -version
>> Error: Could not find or load main class
>> org.codehaus.groovy.tools.GroovyStarter
>> Caused by: java.lang.ClassNotFoundException:
>> org.codehaus.groovy.tools.GroovyStarter
>>
>> So it seems the start scripts are broken.
>>
>> Le ven. 12 oct. 2018 à 09:39, Andres Almiray  a
>> écrit :
>>
>>> +1 (binding)
>>>
>>> All tests ran OK.
>>> Tested local 2.5.3 with JaCoCo regarding a pending PR on @Gnenerated
>>> support: all good as well.
>>>
>>> ---
>>> Java Champion; Groovy Enthusiast
>>> JCP EC Associate Seat
>>> http://andresalmiray.com
>>> http://www.linkedin.com/in/aalmiray
>>> --
>>> What goes up, must come down. Ask any system administrator.
>>> There are 10 types of people in the world: Those who understand binary,
>>> and those who don't.
>>> To understand recursion, we must first understand recursion.
>>>
>>>
>>> On Thu, Oct 11, 2018 at 5:55 AM Paul King  wrote:
>>>
>>>> Dear development community,
>>>>
>>>> I am happy to start the VOTE thread for a Groovy 2.5.3 release!
>>>>
>>>> This release includes 52 bug fixes/improvements as outlined in the
>>>> changelog:
>>>>
>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12343876
>>>>
>>>> Tag:
>>>> https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_5_3
>>>> Tag commit id: 676d5a7d66f540a831779c208878df39d08938b5
>>>>
>>>> The artifacts to be voted on are located as follows (r30001).
>>>> Source release:
>>>> https://dist.apache.org/repos/dist/dev/groovy/2.5.3/sources
>>>> Convenience binaries:
>>>> https://dist.apache.org/repos/dist/dev/groovy/2.5.3/distribution
>>>>
>>>> Release artifacts are signed with a key from the following file:
>>>> https://dist.apache.org/repos/dist/dev/groovy/KEYS
>>>>
>>>> Please vote on releasing this package as Apache Groovy 2.5.3.
>>>>
>>>> Reminder on ASF release approval requirements for PMC members:
>>>> http://www.apache.org/legal/release-policy.html#release-approval
>>>> Hints on validating checksums/signatures (but replace md5sum with
>>>> sha256sum):
>>>> https://www.apache.org/info/verification.html
>>>>
>>>> The vote is open for the next 72 hours and passes if a majority of at
>>>> least three +1 PMC votes are cast.
>>>>
>>>> [ ] +1 Release Apache Groovy 2.5.3
>>>> [ ]  0 I don't have a strong opinion about this, but I assume it's ok
>>>> [ ] -1 Do not release Apache Groovy 2.5.3 because...
>>>>
>>>> Here is my vote:
>>>>
>>>> +1 (binding)
>>>>
>>>>

Re: [VOTE] Release Apache Groovy 2.5.3 (take 2)

[Cédric Champeau]

At this point, -1. See below.

$ gpg --verify apache-groovy-src-2.5.3.zip.asc
gpg: assuming signed data in 'apache-groovy-src-2.5.3.zip'
gpg: Signature made Thu 11 Oct 2018 07:34:42 AM CEST
gpg:using RSA key 6A65176A0FB1CD0B
gpg: Good signature from "Paul King " [unknown]
gpg: aka "Paul King " [unknown]
gpg: aka "Paul King " [unknown]
gpg: aka "Paul King " [unknown]
gpg: aka "keybase.io/paulk_asert "
[unknown]

$  sha256sum apache-groovy-src-2.5.3.zip
7fe017485a22afa1357bd5223872304ac04525474b9a68e84f57c522d9078380
apache-groovy-src-2.5.3.zip
$ cat apache-groovy-src-2.5.3.zip.sha256
7fe017485a22afa1357bd5223872304ac04525474b9a68e84f57c522d9078380

$ cd groovy-2.5.3
$ gradle -b wrapper.gradle wrapper
$ ./gradlew dist --scan

https://scans.gradle.com/s/pwkrb6rzrqzyu

It seems the build needs to be fixed again: it's not fetched from cache
after a "clean" anymore, so probably something broke caching. See
https://scans.gradle.com/s/pwkrb6rzrqzyu/timeline?showCache=kd7f3knycujqg

$ cd target
$ unzip apache-groovy-binary-2.5.3.zip
$ cd groovy-2.5.3
$ bin/groovy -version
Error: Could not find or load main class
org.codehaus.groovy.tools.GroovyStarter
Caused by: java.lang.ClassNotFoundException:
org.codehaus.groovy.tools.GroovyStarter

$ cd bin
$ ./groovy -version
Error: Could not find or load main class
org.codehaus.groovy.tools.GroovyStarter
Caused by: java.lang.ClassNotFoundException:
org.codehaus.groovy.tools.GroovyStarter

So it seems the start scripts are broken.

Le ven. 12 oct. 2018 à 09:39, Andres Almiray  a écrit :

> +1 (binding)
>
> All tests ran OK.
> Tested local 2.5.3 with JaCoCo regarding a pending PR on @Gnenerated
> support: all good as well.
>
> ---
> Java Champion; Groovy Enthusiast
> JCP EC Associate Seat
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary,
> and those who don't.
> To understand recursion, we must first understand recursion.
>
>
> On Thu, Oct 11, 2018 at 5:55 AM Paul King  wrote:
>
>> Dear development community,
>>
>> I am happy to start the VOTE thread for a Groovy 2.5.3 release!
>>
>> This release includes 52 bug fixes/improvements as outlined in the
>> changelog:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12343876
>>
>> Tag:
>> https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_5_3
>> Tag commit id: 676d5a7d66f540a831779c208878df39d08938b5
>>
>> The artifacts to be voted on are located as follows (r30001).
>> Source release:
>> https://dist.apache.org/repos/dist/dev/groovy/2.5.3/sources
>> Convenience binaries:
>> https://dist.apache.org/repos/dist/dev/groovy/2.5.3/distribution
>>
>> Release artifacts are signed with a key from the following file:
>> https://dist.apache.org/repos/dist/dev/groovy/KEYS
>>
>> Please vote on releasing this package as Apache Groovy 2.5.3.
>>
>> Reminder on ASF release approval requirements for PMC members:
>> http://www.apache.org/legal/release-policy.html#release-approval
>> Hints on validating checksums/signatures (but replace md5sum with
>> sha256sum):
>> https://www.apache.org/info/verification.html
>>
>> The vote is open for the next 72 hours and passes if a majority of at
>> least three +1 PMC votes are cast.
>>
>> [ ] +1 Release Apache Groovy 2.5.3
>> [ ]  0 I don't have a strong opinion about this, but I assume it's ok
>> [ ] -1 Do not release Apache Groovy 2.5.3 because...
>>
>> Here is my vote:
>>
>> +1 (binding)
>>
>>

Re: Capturing GEPs better

[Cédric Champeau]

This is typically what should live at groovy.apache.org :)

Le jeu. 11 oct. 2018 à 16:54, Guillaume Laforge  a
écrit :

> +1
> I like the idea of having GEPs on the wiki side of the site.
>
> Le jeu. 11 oct. 2018 à 15:35, Paul King  a écrit :
>
>> This is an example of what I had in mind:
>> http://groovy-lang.org/wiki/GEP-1.html
>>
>> On Thu, Oct 11, 2018 at 6:21 PM Paul King  wrote:
>>
>>> One of the things which I don't believe we ever brought across from the
>>> codehaus move was the GEP part of the codehaus wiki:
>>>
>>>
>>> https://web.archive.org/web/20150504145954/http://docs.codehaus.org/display/GroovyJSR/Groovy+Enhancement+Proposal
>>>
>>> We certainly have merged the outcomes from the GEPs into the language as
>>> needed and parts of the doco and some tests capture bits of the GEP design
>>> and outcomes as does some of the issues in Jira but not the original GEPs.
>>>
>>> I was going to try to bring those across and convert to asciidoc on the
>>> way - for historical purposes but also to be in a better position to cater
>>> for new ones. We have made do with using Jira but I'm not sure that is the
>>> best way to capture this kind of information.
>>>
>>> I was thinking under groovy-website rather than the core repo. Thoughts?
>>>
>>> Cheers, Paul.
>>>
>>>

Re: Proposal groovy-bom

[Cédric Champeau]

Moving from the `dependencies` to `dependencyManagement` block is not
semantically equivalent. In the `dependencies` block you get all the
dependencies transitively, meaning that if you request groovy-all, you'd
get all the individual modules. If it's moved to ``
then you only get _recommendations_ for modules you actually use. That
said, I think having a "groovy-platform" module would be a good idea, as it
would also let Gradle align those modules.

Le lun. 17 sept. 2018 à 20:49, Leonard Brünings 
a écrit :

> Hi,
>
> as I said, it needs to be in the dependencyManagement section, to be
> importable into the dependencyManagement of another pom.
> You can add groovy-all to dependencyManagement, but that only affects
> the version of the artifact itself not the version of its transitive
> dependencies, which can be affected by transitive dependencies of other
> artifacts.
>
> If you don't want to add another project it is possible to add the
> dependencyManagement section into groovy-all and remove the version in
> the normal dependencies block.
>
> cheers
>
> Leonard
>
>
> Am 17.09.2018 um 20:42 schrieb Jochen Theodorou:
> > On 17.09.2018 02:44, Leonard Brünings wrote:
> >> Hi,
> >>
> >> the switch to fine grained artifacts with groovy-2.5 made it harder
> >> to consistently mange package versions.
> >>
> >> Many projects offer a bom pom
> >> (https://www.baeldung.com/spring-maven-bom), that manages all the
> >> packages so users of maven have to just import the bom pom instead of
> >> having to manage every artifact.
> >>
> >> So you can do just this
> >>
> >> 
> >>
> >>  
> >>org.codehaus.groovy
> >>groovy-bom
> >>${groovy-version}
> >>import
> >>  
> >>
> >> 
> >
> > what is wrong with this pom?
> >
> http://central.maven.org/maven2/org/codehaus/groovy/groovy-all/2.5.2/groovy-all-2.5.2.pom
> >
> > bye Jochen
> >
>
>

Re: About type inference of method return value

[Cédric Champeau]

Sorry I don't understand what you are saying. What I'm saying is that we
already had such an implementation, and we decided to _remove_ it. Are you
saying that you have a branch that reintroduces it, or that it's already on
master?

I disagree with the statement that the "users require smarter type
inference". Type inference is cool, but it's also hard to predict.
Sometimes you just don't understand why the compiler inferred something or
not. We explicitly chose not to be too smart here, because it can be
confusing to users.

Le mer. 5 sept. 2018 à 13:36, Daniel.Sun  a écrit :

> Hi Cédric,
>
>  > Basically, it's not easy to realize that when you have a non final
> methods, subclasses can override the method to return a different type.
>
>  As I proposed, the methods with smarter return type inference should
> match one of the following charactristics:
> 1) `final`
> 2) `private`
> 3) `static`
> 4)  method defined in Script
>
>  So these methods will not be overrided and the return type will be
> exact.
>
>  I will leave the implementation as it is util most of groovy users
> require the smarter type inference ;-)
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: About type inference of method return value

[Cédric Champeau]

Hi Daniel,

We discussed this when we implemented static compilation in the past. There
were 2 different relates cases discussed:

- smarter type inference for final fields
- smarter type inference for final methods

and decided not to implement them, so that it's not confusing for users
when the compiler can infer a type in one case and not the other. We can
revisit the decision, just want to give more context. Basically, it's not
easy to realize that when you have a non final methods, subclasses can
override the method to return a different type.


Le mer. 5 sept. 2018 à 06:50, Daniel Sun  a écrit :

> Hi all,
>
>   I am going to refine the type inference of method return value, the
> methods should match one of the following charactristics:
> 1) `final`
> 2) `private`
> 3) `static`
> 4)  method defined in Script
>
>   The above methods will not be overrided and have exact method return
> type.
>
>   Any thoughts?
>
>   P.S. Currently the following code will fail to compile, but it's
> obiviously valid.
> ```
> @groovy.transform.CompileStatic
> class Test {
> static m() {
> return 'abc'
> }
>
> static a() {
> return m().length()
> }
>
> static void main(String[] args) {
> assert 3 == a()
> }
> }
> ```
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: [VOTE] Release Apache Groovy 2.5.2

[Cédric Champeau]

+1

Le lun. 13 août 2018 à 10:09, Jochen Theodorou  a écrit :

> +1
>
> Am 10.08.2018 um 18:57 schrieb Paul King:
> > Dear development community,
> >
> > I am happy to start the VOTE thread for a Groovy 2.5.2 release!
> >
> > This release includes 20 bug fixes/improvements as outlined in the
> > changelog:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12343651
> >
> > Tag:
> >
> https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_5_2
> > Tag commit id: 0a2c398a56f4d7431a9878550523494b73043e1d
> >
> > The artifacts to be voted on are located as follows (r28654).
> > Source release:
> https://dist.apache.org/repos/dist/dev/groovy/2.5.2/sources
> > Convenience binaries:
> > https://dist.apache.org/repos/dist/dev/groovy/2.5.2/distribution
> >
> > Release artifacts are signed with a key from the following file:
> > https://dist.apache.org/repos/dist/dev/groovy/KEYS
> >
> > Please vote on releasing this package as Apache Groovy 2.5.2.
> >
> > Reminder on ASF release approval requirements for PMC members:
> > http://www.apache.org/legal/release-policy.html#release-approval
> > Hints on validating checksums/signatures (but replace md5sum with
> > sha256sum):
> > https://www.apache.org/info/verification.html
> >
> > The vote is open for the next 72 hours and passes if a majority of at
> > least three +1 PMC votes are cast.
> >
> > [ ] +1 Release Apache Groovy 2.5.2
> > [ ]  0 I don't have a strong opinion about this, but I assume it's ok
> > [ ] -1 Do not release Apache Groovy 2.5.2 because...
> >
> > Here is my vote:
> >
> > +1 (binding)
> >
> > P.S. Special thanks to Ken, Graeme and Jesper for trying out some macOS
> > fixes for me.
> >
> >
>

Re: Gradle build logs

[Cédric Champeau]

The message explains how you can make the choice persistent, and yes, CI is
exempt.

Le ven. 8 juin 2018 à 14:43, Russel Winder  a écrit :

> On Thu, 2018-06-07 at 13:20 +0200, Cédric Champeau wrote:
> > I have added an explicit opt-in :)
> >
>
> I believe this is a good choice.
>
> Will it be persistent for the user on a given machine or will the question
> be
> asked every time there is a build?
>
> I am guessing CI is exempt from this.
>
> --
> Russel.
> ===
> Dr Russel Winder  t: +44 20 7585 2200
> 41 Buckmaster Roadm: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk
>

Re: Gradle build logs

[Cédric Champeau]

I have added an explicit opt-in :)

Le jeu. 7 juin 2018 à 12:39, Cédric Champeau  a
écrit :

> Well, currently there's no way to tell that you don't want to expose
> _some_ of the data, so you need to opt-in (which is, AFAIK, GDPR compliant,
> see https://gradle.com/legal/privacy). The problem is that the Groovy
> build assumes the license has been accepted by everybody, which is not the
> case, so we should at least ask once.
>
> Le jeu. 7 juin 2018 à 12:26, Russel Winder  a
> écrit :
>
>> On Thu, 2018-06-07 at 12:12 +0200, Cédric Champeau wrote:
>> > I think you're right: currently the build uses `publishAlways()` and has
>> > license accept enabled, but it should be per person.
>>
>> Cédric,
>>
>> Thanks for picking up I was being serious but trying to avoid seeming like
>> "gammon".
>>
>>
>> I suggest the road to de-personalisation would be not to collect user
>> name,
>> machine names, and machine IP addresses. In terms of logs, I can't see
>> that
>> they add anything. Clearly the rest of the data could be useful, and so is
>> worth collecting. It is also nothing personal just data about a Groovy
>> build
>> on a particular machine, with machine details actually being important.
>>
>>
>> --
>> Russel.
>> ===
>> Dr Russel Winder  t: +44 20 7585 2200
>> 41 Buckmaster Roadm: +44 7770 465 077
>> London SW11 1EN, UK   w: www.russel.org.uk
>>
>

Re: Gradle build logs

[Cédric Champeau]

Well, currently there's no way to tell that you don't want to expose _some_
of the data, so you need to opt-in (which is, AFAIK, GDPR compliant, see
https://gradle.com/legal/privacy). The problem is that the Groovy build
assumes the license has been accepted by everybody, which is not the case,
so we should at least ask once.

Le jeu. 7 juin 2018 à 12:26, Russel Winder  a écrit :

> On Thu, 2018-06-07 at 12:12 +0200, Cédric Champeau wrote:
> > I think you're right: currently the build uses `publishAlways()` and has
> > license accept enabled, but it should be per person.
>
> Cédric,
>
> Thanks for picking up I was being serious but trying to avoid seeming like
> "gammon".
>
>
> I suggest the road to de-personalisation would be not to collect user name,
> machine names, and machine IP addresses. In terms of logs, I can't see that
> they add anything. Clearly the rest of the data could be useful, and so is
> worth collecting. It is also nothing personal just data about a Groovy
> build
> on a particular machine, with machine details actually being important.
>
>
> --
> Russel.
> ===
> Dr Russel Winder  t: +44 20 7585 2200
> 41 Buckmaster Roadm: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk
>

Re: Gradle build logs

[Cédric Champeau]

I think you're right: currently the build uses `publishAlways()` and has
license accept enabled, but it should be per person.

Le jeu. 7 juin 2018 à 12:09, Russel Winder  a écrit :

> Cédric,
>
> 
> I wonder if the Infrastructure section of the Gradle build log every Groovy
> build submits to Gradle constitutes personal information under the GDPR?
> 
>
> --
> Russel.
> ===
> Dr Russel Winder  t: +44 20 7585 2200
> 41 Buckmaster Roadm: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk
>

Re: Groovy build with Gradle 4.8

[Cédric Champeau]

\o/

Le jeu. 7 juin 2018 à 11:50, Russel Winder  a écrit :

> I think I lost an email, but I recollect Daniel asked me to build of Groovy
> master/HEAD with the new 4.8 Gradle. Tried it, seems to work fine. But it
> is
> now a matter of official record:
>
> https://gradle.com/s/eqtdqjr3nlagi
>
> --
> Russel.
> ===
> Dr Russel Winder  t: +44 20 7585 2200
> 41 Buckmaster Roadm: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk
>

Re: [ANNOUNCE] Apache Groovy 2.5.0 released

[Cédric Champeau]

Congrats to anyone involved in that long awaited release!

Le mer. 30 mai 2018 à 08:37, Paul King  a écrit :

> Dear community,
>
> The Apache Groovy team is pleased to announce version 2.5.0 of Apache
> Groovy!
> Apache Groovy is a multi-facet programming language for the JVM.
> Further details can be found at the http://groovy.apache.org website.
>
> We are sure you'll enjoy the features in this new version of Groovy.
> Your feedback on any unintentional glitches is welcome.
>
> This release includes 12 bug fixes/improvements since the last RC as
> outlined in the changelog:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12343341
>
> The full list of over 300 bug fixes/improvements since 2.4 can be found
> here:
> http://groovy-lang.org/changelogs/changelog-2.5.0.html
>
> The full release notes can be found here:
> http://groovy-lang.org/releasenotes/groovy-2.5.html
>
> 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.
>

Re: Groovy 2.5 @Macro ?

[Cédric Champeau]

It could very well be a packaging bug: if the macro transformation
descriptor is not on class path, it won't work. I'm on my phone now so I
can't check, but it would explain.

Le dim. 27 mai 2018 à 18:47, mg  a écrit :

> I saw that, but assertScript is used for many tests, outside of the
> special requirements of @Macro...
>
> I'll test the documentation, once you get round to doing that :-)
>
>  Ursprüngliche Nachricht 
> Von: Paul King 
> Datum: 27.05.18 04:20 (GMT+01:00)
> An: dev@groovy.apache.org
> Betreff: Re: Groovy 2.5 @Macro ?
>
> Actually, if you look at src/test in groovy-macro, you'll see that the
> macro methods and META-INF file are there. The deferred compilation
> is achieved using assertScript.
>
>
> On Sun, May 27, 2018 at 11:21 AM, Paul King  wrote:
>
>>
>> Macro expansion is done early (CONVERSION) and it expects to find the
>> method it
>> will be expanding into available on the classpath at that point.
>>
>> It is pretty much the same reasons as for extension modules:
>>
>> http://groovy-lang.org/metaprogramming.html#_extension_modules_and_classpath
>>
>>
>>
>> On Sun, May 27, 2018 at 10:02 AM, mg  wrote:
>>
>>> Hi Paul,
>>>
>>> why this restriction ? I thought this feature was here to e.g. simply
>>> support logging of the form
>>> "$variableExpression.name=$variableExpression.value", etc:
>>>
>>>
>>> https://github.com/bsideup/macro-methods-workshop/blob/master/src/test/groovy/com/example/SuperLoggerMacroTest.groovy
>>>
>>> ?
>>>
>>> Cheers,
>>> mg
>>>
>>>
>>>  Ursprüngliche Nachricht 
>>> Von: Paul King 
>>> Datum: 27.05.18 01:50 (GMT+01:00)
>>> An: dev@groovy.apache.org
>>> Betreff: Re: Groovy 2.5 @Macro ?
>>>
>>> Your best bet is to have the macro class and META-INF/services file
>>> under src/main and your usage under src/test.
>>> If you want to do it all in one file, you can create a temp directory,
>>> stuff the META-INF/services file in it, add that directory
>>> to the classpath dynamically and then run your code using the macro with
>>> a new GroovyShell().
>>>
>>> On Sun, May 27, 2018 at 1:15 AM, MG  wrote:
>>>
 I would have expected a quick "you can't use it like that / you just
 have to / here is some documentation" reply...
 Then let me rephrase my question: Why are these Groovy 2.5 tests green:

 https://github.com/apache/groovy/blob/GROOVY_2_5_X/subprojects/groovy-macro/src/test/groovy/org/codehaus/groovy/macro/MacroTransformationTest.groovy
 ?
 Cheers,
 mg


 On 26.05.2018 00:00, MG wrote:

 Hi guys,

 giving the new Groovy 2.5 macro functionality a spin, and would have
 expected the code below to replace the "call" to nv(x) with the AST
 expression created in the method, i.e. returning the name of the "passed"
 variable. Instead no macro magic happens, and the compilation accordingly
 fails with "groovy.lang.MissingMethodException: No signature of method:
 groovy.GroovyMacroSpike.nv() is applicable for argument types: (Integer)
 values: [123]":

 import org.codehaus.groovy.ast.expr.Expressionimport 
 org.codehaus.groovy.ast.expr.VariableExpressionimport 
 org.codehaus.groovy.macro.runtime.Macroimport 
 org.codehaus.groovy.macro.runtime.MacroContextimport 
 org.junit.Ignoreimport org.junit.Testimport static 
 org.codehaus.groovy.ast.tools.GeneralUtils.constX
 class GroovyMacroSpike {
   @Test  @Ignore  void nvTest() {
 final x = 123assert x == 123assert nv(x) == "x"  }

   @Macro  Expression nv(MacroContext ctx, VariableExpression variable) {
 return constX(variable.getName());
   }
 }

 What is missing to make this work ?
 mg




>>>
>>
>

Re: Performance of the compiler

[Cédric Champeau]

Tens of thousands of tests, and ~4 minutes compile time (with --parallel).

Le ven. 25 mai 2018 à 14:50, mg <mg...@arscreat.com> a écrit :

> Hi Cedric,
>
> to put this in context and to better understand the ongoing discussion:
> How many tests and what absolute compile time are we talking about here ?
>
> Cheers,
> mg
>
>
>  Ursprüngliche Nachricht 
> Von: Cédric Champeau <cchamp...@apache.org>
> Datum: 24.05.18 08:30 (GMT+01:00)
> An: dev@groovy.apache.org
> Betreff: Performance of the compiler
>
> Hi folks,
>
> I just wanted to share the result of profiling the performance of the
> compiler on "real world" classes, namely compiling the tests of Gradle. We
> have a lot of tests, so compilation times becomes really a pain point, so I
> have checked where we spend time. I have attached the export of hotspots
> from a real compilation session.
>
> It's no surprise to me, most of the time (70%) is spent in the resolve
> visitor, and most of this time itself is spent in loading classes. We made
> some improvements in the past, by not initializing those classes, but it's
> still a crazy amount of time.
>
> Similarly, we spend around 10% of our time in filling stack traces which
> are used for flow control. Unfortunately we don't have the opportunity to
> change this because it's either ClassNotFoundException (during resolution)
> sent by the classloader, or ANTLR recognition exception, used for flow
> control (duh!).
>
> I remember that for Gradle I had implemented a custom ResolveVisitor that
> adds some assumptions for Gradle scripts to avoid too many lookups for
> classes which would obvisouly not exist, and it significantly improved the
> performance of compiling scripts, but that was because there were lots of
> implicit imports. For regular classes I'm not sure it's as simple.
>
> Resolution is also very easy to break... Anyway, any change in this area
> would probably make the lives of our users better!
>
>
>

Re: Performance of the compiler

[Cédric Champeau]

The problem is not the performance of the test, it's the performance of
_compiling_ the test. @CompileStatic wouldn't help there.

Le ven. 25 mai 2018 à 14:24, Thibault Kruse  a
écrit :

> Would the test performance be improved if @CompileStatic were used? I
> think gradle uses Spock, and last time I checked Spock could not be
> used with @CompileStatic. But Spock could also be removed with some
> effort...
>
> On Fri, May 25, 2018 at 8:52 PM, Jochen Theodorou 
> wrote:
> >
> >
> > Am 25.05.2018 um 12:51 schrieb Daniel.Sun:
> >>
> >> Hi Cédric,
> >>
> >>   I am not going to cache ClassNode instance(just cache class names,
> >> which are `String`), but I want to add a check whether the name of the
> >> ClassNode being resolved is possibly in the default imported packages,
> >> e.g.
> >> If a ClassNode instance's name is `Foobar`(apparently it could not be in
> >> any
> >> default imported packages), then we can `return false` immediately and
> the
> >> further resolving can be eliminated.
> >
> >
> > but this means we will have to manually update the list for java.lang,
> > java.util, java.io and java.net
> >
> > Take for example Module. It is new in Java 9 and is in java.lang. If we
> had
> > this logic already in say Groovy 2.0 I am pretty sure the last versions
> till
> > Groovy 2.3 would not be able to resolve this class anymore then.
> >
> > I think there would be no problem with Java10, but think of Java 11...
> we do
> > not know yet.
> >
> > bye Jochen
>

Re: Performance of the compiler

[Cédric Champeau]

I have no idea!

Le ven. 25 mai 2018 à 11:05, Jesper Steen Møller <jes...@selskabet.org> a
écrit :

> Oh - I see now that this is implemented already (optimizationOptions
> w/asmResolvingin:true).
> Is there any reason this is not the default? Is it slower? Incorrect?
>
> -Jesper
>
> > On 24 May 2018, at 10.08, Jesper Steen Møller <jes...@selskabet.org>
> wrote:
> >
> > Interesting! So let me get this straight: Are we using an actual
> "in-JVM" classloader to load classes examined by the Groovy Compiler itself?
> > In the Eclipse Java compiler, we don't actually load the classes into
> the JVM, instead we have our own implementation of classpath traversal and
> read it using ClassFileReader. Would a similar approach not work for
> constructing ClassNodes in Groovy? (obviousluy using ASM to do the bytecode
> parsing instead of rolling it ourselves).
> >
> > JPMS would naturally make complicate things further, but again, ECJ has
> cracked this, too.
> >
> > -Jesper
> >
> >> On 24 May 2018, at 08.30, Cédric Champeau <cchamp...@apache.org> wrote:
> >>
> >> Hi folks,
> >>
> >> I just wanted to share the result of profiling the performance of the
> compiler on "real world" classes, namely compiling the tests of Gradle. We
> have a lot of tests, so compilation times becomes really a pain point, so I
> have checked where we spend time. I have attached the export of hotspots
> from a real compilation session.
> >>
> >> It's no surprise to me, most of the time (70%) is spent in the resolve
> visitor, and most of this time itself is spent in loading classes. We made
> some improvements in the past, by not initializing those classes, but it's
> still a crazy amount of time.
> >>
> >> Similarly, we spend around 10% of our time in filling stack traces
> which are used for flow control. Unfortunately we don't have the
> opportunity to change this because it's either ClassNotFoundException
> (during resolution) sent by the classloader, or ANTLR recognition
> exception, used for flow control (duh!).
> >>
> >> I remember that for Gradle I had implemented a custom ResolveVisitor
> that adds some assumptions for Gradle scripts to avoid too many lookups for
> classes which would obvisouly not exist, and it significantly improved the
> performance of compiling scripts, but that was because there were lots of
> implicit imports. For regular classes I'm not sure it's as simple.
> >>
> >> Resolution is also very easy to break... Anyway, any change in this
> area would probably make the lives of our users better!
> >>
> >>
> >> 
> >
>
>

Re: upcoming 2.5.0 release

[Cédric Champeau]

I realize I have pushed the groovydoc improvements to 2_5_X. This means the
branch differs from the last rc. Does it mean it's going to be in 2.5.1, or
that the final 2.5.0 is going to be different from the rc2 (uh!) or, that
we need rc3?

Le ven. 25 mai 2018 à 10:53, Paul King  a écrit :

>
> Last call for any additions - otherwise I hope to prepare a candidate over
> the weekend.
>
> Cheers, Paul.
>
>

Re: Performance of the compiler

[Cédric Champeau]

Be warned that caching may prove to be complicated: what if a class in the
same compile unit is named `List`, or a class in the same package? This is
one of the reasons the lookup is not cached for this.

Le ven. 25 mai 2018 à 10:17, Daniel.Sun  a écrit :

> I am going to cache the class names of default imported packages, e.g.
> `List`, `ArrayList`, `Map`, `HashMap`, etc.
>
> And try to find the name of ClassNode instance in the class names cache, if
> not found, `return false`(add the check at the line[1]). The polished logic
> can avoid unnecessary resolving and improve the resolving performance
> somehow.
>
> It's a pity that I have not found any approach to get all classes of the
> given package, e.g. `java.lang`, `java.util`
> Any help is appreciated. (Note: We can not use 3rd party library excluding
> antlr, asm, cli)
>
> Cheers,
> Daniel.Sun
> [1]
>
> https://github.com/apache/groovy/blob/master/src/main/java/org/codehaus/groovy/control/ResolveVisitor.java#L513
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Performance of the compiler

[Cédric Champeau]

Hi folks,

I just wanted to share the result of profiling the performance of the
compiler on "real world" classes, namely compiling the tests of Gradle. We
have a lot of tests, so compilation times becomes really a pain point, so I
have checked where we spend time. I have attached the export of hotspots
from a real compilation session.

It's no surprise to me, most of the time (70%) is spent in the resolve
visitor, and most of this time itself is spent in loading classes. We made
some improvements in the past, by not initializing those classes, but it's
still a crazy amount of time.

Similarly, we spend around 10% of our time in filling stack traces which
are used for flow control. Unfortunately we don't have the opportunity to
change this because it's either ClassNotFoundException (during resolution)
sent by the classloader, or ANTLR recognition exception, used for flow
control (duh!).

I remember that for Gradle I had implemented a custom ResolveVisitor that
adds some assumptions for Gradle scripts to avoid too many lookups for
classes which would obvisouly not exist, and it significantly improved the
performance of compiling scripts, but that was because there were lots of
implicit imports. For regular classes I'm not sure it's as simple.

Resolution is also very easy to break... Anyway, any change in this area
would probably make the lives of our users better!
CPU hot spots

+---++
|  
Method  
 |   Time (ms)|
+---++
|  java.net.URLClassLoader.findClass(String) URLClassLoader.java
|  
6,531   54 %  |
|  java.security.AccessController.doPrivileged(PrivilegedExceptionAction, 
AccessControlContext) AccessController.java (native)
  |  6,090   50 %  |
|  java.net.URLClassLoader$1.run() URLClassLoader.java  
|  
5,987   50 %  |
|  java.net.URLClassLoader$1.run() URLClassLoader.java  
|  
5,987   50 %  |
|  org.codehaus.groovy.control.ResolveVisitor.startResolving(ClassNode, 
SourceUnit) ResolveVisitor.java 
|  4,711   39 %  |
|  org.codehaus.groovy.control.ResolveVisitor.visitClass(ClassNode) 
ResolveVisitor.java 
|  4,711   39 %  |
|  org.codehaus.groovy.control.ResolveVisitor.resolve(ClassNode, boolean, 
boolean, boolean) ResolveVisitor.java   
  |  4,486   37 %  |
|  org.codehaus.groovy.control.ClassNodeResolver.findClassNode(String, 
CompilationUnit) ClassNodeResolver.java 
 |  4,363   36 %  |
|  org.codehaus.groovy.control.ClassNodeResolver.resolveName(String, 
CompilationUnit) ClassNodeResolver.java 
   |  4,363   36 %  |
|  
org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(String, 
CompilationUnit) ClassNodeResolver.java   |  
4,363   36 %  |
|  org.codehaus.groovy.control.ResolveVisitor.resolveToOuter(ClassNode) 
ResolveVisitor.java 
|  4,363   36 %  |
|  groovy.lang.GroovyClassLoader.loadClass(String, boolean, boolean, boolean) 
GroovyClassLoader.java| 
 4,183   35 %  |
|  groovy.lang.GroovyClassLoader.loadClass(String, boolean, boolean) 
GroovyClassLoader.java  
   |  3,984   33 %  |
|  org.codehaus.groovy.tools.javac.JavaAwareCompilationUnit$1.call(SourceUnit, 
GeneratorContext, ClassNode) JavaAwareCompilationUnit.java   |  
3,438   28 %  |
|  java.net.URLClassLoader.defineClass(String, Resource) URLClassLoader.java
|  
3,070   25 %  |
|  sun.misc.URLClassPath.getResource(String, boolean) URLClassPath.java 
|  
2,978   25 %  |
|  java.lang.ClassLoader.defineClass(String, byte[], int, int, 
ProtectionDomain) ClassLoader.java  
 |  2,292   19 %  |
|  java.lang.ClassLoader.defineClass1(String, byte[], int, 

Re: Troubles with IDEA setup

[Cédric Champeau]

Thanks for checking, Marcin. For reference, stub generation takes long but
passes. It's really the semantic analysis which gets stuck somehow.

Le mer. 23 mai 2018 à 13:32, Marcin Erdmann <marcin.erdm...@proxerd.pl> a
écrit :

> Cedric,
>
> I've just pulled master then I got rid of all idea config files and build
> direcotries to start with a clean state:
>
> rm groovy.i*
> find . -name "*.iml" -type f | xargs rm -f
> ./gradlew clean
>
> Then I run the same command as you:
> ./gradlew jar idea --rerun-tasks
>
> Finally I opened the project in IntelliJ and tried rebuilding it (Build >
> Rebuild project). The fan is spinning like crazy, CPU usage is high and it
> seems to be stuck on "Groovy stub generator: initialization [tests of
> groovy-xml and 8 more]". After then killing the IDE and trying to
> run DownUpStepTest I'm seeing the same symptoms as you are - stuck in
> "Groovyc: semantic analysis [tests of groovy-xml and 8 more]" with CPU is
> not busy.
>
> For reference, I'm using IntelliJ 2018.1 181.4203.550.
>
> On Tue, May 22, 2018 at 8:02 PM, Cédric Champeau <
> cedric.champ...@gmail.com> wrote:
>
>> Hi team,
>>
>> I've been trying to figure out what is happening for hours now, but I
>> cannot find any reason. I'm working on master, after removing all IDEA
>> state (.iml, .ipr, .iws), regenerating the IDEA files using:
>>
>> ./gradlew jar idea --rerun-tasks
>>
>> And then I open the project in IDEA and try to run a unit test. But then
>> the IDE is stuck in "Groovyc: semantic analysis [tests of groovy-xml and 8
>> more]". CPU is not busy, nothing happens.
>>
>> I thought it could be a CPU issue, so I increased the memory for the IDEA
>> compiler process, without success.
>>
>> Any idea what could be going on? Am I the only one seeing this?
>>
>>
>

Re: Breaking changes in 3.0 [was: Re: 2.5.0-rc-3]

[Cédric Champeau]

+1, regarding indy by default, I wonder if we could provide the "old" MOP
as a backward compatibility runtime jar...

Le mer. 23 mai 2018 à 13:11, Jesper Steen Møller  a
écrit :

>
> > On 23 May 2018, at 12.23, Russel Winder  wrote:
> >
> > On Wed, 2018-05-23 at 00:28 +1000, Paul King wrote:
> >> No plans to go to 18/19 model at this stage.
> >>
> >> If we push for an early 3.0, some of the breaking changes will have to
> be
> >> deferred.
> >> A very quick release after 3.0 could easily be a 3.1 if it was needed.
> >>
> >> The next major release (4.0) would be when we had tackled (a significant
> >> chunk of) the remaining breaking changes.
> >>
> >
> > I am not sure a very rapid 3.0 → 3.1 is actually any sort of problem per
> se.
> >
> > In the current climate is a 3.0 now, 4.0 in the next year actually a
> problem?
> >
> > Given the very volunteer nature of the Groovy project, pragmatism more
> than
> > anything has to be the order of the day. However I think there is a
> marketing
> > element here. Having new 2.4.X releases doesn't really achieve anything
> > marketing-wise. Releasing 2.5.0 actually doesn't much either really,
> though
> > clearly we do it as we are already at RC-3, and it can be "milked". But
> 2.5 is
> > just backward compatible extensions to 2.4, is this Groovy actually
> > progressing?
> >
> > I suggest we want to get a 3.0 out to show Groovy is progressing and
> with some
> > breaking changes, in particular JDK8+ only, not to mention a parser
> based on
> > somewhat newer technology!  "Groovy drops support for JDK7" is probably
> a good
> > thing marketing wise.
> >
> > My feeling is that Groovy does not have enough resource to go for big
> major
> > version number releases, but that it needs something to combat the "it's
> old
> > technology" feel given the rise of Kotlin. I'd push for a 3.0 release
> soon and
> > worry about the metamodel changes later – unless they are already in
> place?
> >
>
> I agree with the soft factors around numbering.
>
>
> As I understand, the metamodel changes are not in place yet, and not on
> anybody's immediate schedule.
>
> A) However, as I understand it, MOP2 could be made backwards compatible,
> so that a new MOP2 runtime could still honor the MOP1 protocol, from some
> version 3.x onwards. We could then deprecate the MOP1 way of doing things.
>
> B) As for the indy stuff, we should choose to produce indy-only bytecodes
> now that we require Java 8 for Groovy 3.0. Again, we still need runtime
> support for the existing CallSite caching, or we'd have to force everybody
> to recompile every Groovy library they use. That's hardly a good idea!
>
> C) Finally, for 3.0 we could switch generation of closures to be
> bootstrap-driven, i.e. by keeping the closure body as a method of the
> enclosing class, but by generating the closure in the fashion of
> LambdaMetafactory. That way, we would keep the Groovy semantics, but reduce
> the cost of using closures (all those extra classfiles). We could possibly
> introduce a ClosureInterface for forwards compatibility, and deprecate the
> use of the Closure class directly.
>
> Then, in some future majorversion 4.0, we could stop supporting MOP1, we
> could drop support for the old callsite caching, and we could make
>
> Was that about right?
>
> -Jesper
>
>
>

Re: Possible bug in AstBuilder Antlr4

[Cédric Champeau]

thanks!

Le mer. 23 mai 2018 à 09:48, Daniel.Sun  a écrit :

> It is fixed:
>
> https://github.com/apache/groovy/commit/a26c190f9a70b0c430004d80c56e37703c2edfe8
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: Possible bug in AstBuilder Antlr4

[Cédric Champeau]

It cannot. However the GString templates look like scripts, which is why I
added an import in the first place. But then the builder fails with a
ClassCastException. I would have expected it to fail with a better error
message in this case, like "You're not allowed to use an import in a method
body".

Le mer. 23 mai 2018 à 08:34, Daniel.Sun  a écrit :

> Hi Cédric,
>
>  `import` statement can appear in a block?
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: Troubles with IDEA setup

[Cédric Champeau]

That's what I meant with "native import".

Le mer. 23 mai 2018 à 08:28, Daniel.Sun  a écrit :

> Hi Cédric,
>
>Try to import as a gradle project?
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: Troubles with IDEA setup

[Cédric Champeau]

I managed to do something using the IDE native import (instead of using
./gradlew idea) and delegating all actions to Gradle. It's slower feedback,
but at least I can work.

Le mar. 22 mai 2018 à 23:37, Cédric Champeau <cedric.champ...@gmail.com> a
écrit :

> No luck, I'm still stuck :(
>
> Le mar. 22 mai 2018 à 21:23, Daniel.Sun <sun...@apache.org> a écrit :
>
>> Hi Cédric,
>>
>>   It's OK on my machine.
>>
>>   Usually I run `gradlew clean bootstrapJar --no-build-cache` before
>> running tests via IDEA.
>>
>>   Good luck.
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>> --
>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>
>

Re: Troubles with IDEA setup

[Cédric Champeau]

No luck, I'm still stuck :(

Le mar. 22 mai 2018 à 21:23, Daniel.Sun  a écrit :

> Hi Cédric,
>
>   It's OK on my machine.
>
>   Usually I run `gradlew clean bootstrapJar --no-build-cache` before
> running tests via IDEA.
>
>   Good luck.
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Troubles with IDEA setup

[Cédric Champeau]

Hi team,

I've been trying to figure out what is happening for hours now, but I
cannot find any reason. I'm working on master, after removing all IDEA
state (.iml, .ipr, .iws), regenerating the IDEA files using:

./gradlew jar idea --rerun-tasks

And then I open the project in IDEA and try to run a unit test. But then
the IDE is stuck in "Groovyc: semantic analysis [tests of groovy-xml and 8
more]". CPU is not busy, nothing happens.

I thought it could be a CPU issue, so I increased the memory for the IDEA
compiler process, without success.

Any idea what could be going on? Am I the only one seeing this?

Re: 2.5.0-rc-3

[Cédric Champeau]

Yeah. Doesn't prevent us from having a quick 4.0 with module revamp if
we're extremely good :)

Le mar. 22 mai 2018 à 13:29, Jesper Steen Møller <jes...@selskabet.org> a
écrit :

> And postpone module revamp?
>
> -Jesper
>
> On 22 May 2018, at 13.27, Cédric Champeau <cedric.champ...@gmail.com>
> wrote:
>
> I think we should slim down what Groovy 3 is, make it Parrot + JDK 8
> basically.
>
> Le mar. 22 mai 2018 à 13:22, Paul King <pa...@asert.com.au> a écrit :
>
>> The question is really (most of) Parrot on JDK7+ or Parrot on JDK8+
>> sooner.
>>
>>
>> On Tue, May 22, 2018 at 7:55 PM, Daniel.Sun <sun...@apache.org> wrote:
>>
>>> As a user, if you ask me whether I need the Parrot or not, my answer will
>>> always be yes even if I seldom use it ;-)
>>>
>>> Cheers,
>>> Daniel.Sun
>>>
>>>
>>>
>>>
>>> --
>>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>>
>>
>>
>

Re: 2.5.0-rc-3

[Cédric Champeau]

I think we should slim down what Groovy 3 is, make it Parrot + JDK 8
basically.

Le mar. 22 mai 2018 à 13:22, Paul King  a écrit :

> The question is really (most of) Parrot on JDK7+ or Parrot on JDK8+ sooner.
>
>
> On Tue, May 22, 2018 at 7:55 PM, Daniel.Sun  wrote:
>
>> As a user, if you ask me whether I need the Parrot or not, my answer will
>> always be yes even if I seldom use it ;-)
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>>
>> --
>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>
>
>

Re: [DISCUSS] Renumber Groovy 2.6 to 2.9

[Cédric Champeau]

2.99 or alike doesn't make sense. What if you have to release a bug fix
release. 2.99.1? That's nasty :)

I'm very much in favor of dropping 2.6 altogether because it's confusing as
possible. We don't have 2.5 yet, and we already have alphas for 3.0. This
mean we would live with 3 "live" branches for a while (2.5.x, 2.6.x and
3.x), which is too much overhead for my brain, and probably too much hassle
for the maintainers of Groovy. I reckon that people wanted to have the
ability to try the new parser on JDK 7. But seriously, a project release in
2018 that supports Java 7 is extraordinary. The future is JDK 11, not 7 :)

Le mar. 22 mai 2018 à 09:33, mg  a écrit :

> Good point.
>
> This is one reason why - under the given constraints - Russel's 2.99.x or
> my 2.97.x would be better choices than 2.9.x
> (once you get beyond "this is not how things are done").
>
> Also consider what happens if, for some reason, the current 2.5.x branch
> was to continue beyond 2.5.x (without switching to 2.6.x === 3.0-- , i.e.
> without breaking changes).
> Then you would have to skip 2.6.x , and go directly to 2.7.x, which would
> be much more confusing...
>
> The key sentence here is "under the given constraints". In a perfect,
> clean-room-world we would not be having this discussion...
>
>
>  Ursprüngliche Nachricht 
> Von: Thibault Kruse 
> Datum: 22.05.18 06:31 (GMT+01:00)
> An: dev@groovy.apache.org, pa...@asert.com.au
> Betreff: Re: [DISCUSS] Renumber Groovy 2.6 to 2.9
>
> If you go with 2.9 now, and for unforseeable reasons the 2.x branch
> continues, you will have 2.6, 2.7, 2.8 and then the prematurely added
> 2.9.
> What would you think about any other project versioning like that?
> Even with a given explanation, it looks weird and chaotic.
>
> On Tue, May 22, 2018 at 11:12 AM, Paul King  wrote:
> > 2.6/3.0-- has only undergone alpha releases. The fact that 2.7/2.8 are
> > missing and that people stop to think is a good thing.
> > We are planning breaking changes for 3 (and hence 2.6/3.0--). With
> semantic
> > versioning, 2.6/3.0-- should not have such changes.
> > So it really should be versions 3 and 4 but since we are going to drop
> > support for 2.6/3.0-- straight away, it hardly seems worthy
> > of a dedicated whole version. I think 2.9 is a good compromise version
> > number.
> >
> > Dropping it altogether is another option but if you remember it was
> > non-committer contributors that wanted this change and did
> > most of the (original at least) contributions. We've done all the work, I
> > say let's just release as 2.9 and then drop it. If outside
> > contributors want to continue bug fixes on it, so be it.
> >
> > Cheers, Paul.
> >
> > On Tue, May 22, 2018 at 1:12 AM, John Wagenleitner
> >  wrote:
> >>
> >> My opinion is that it should be left as 2.6. Since 2.6 has already
> >> undergone several pre-releases I think it will may be more confusing to
> >> re-number now. Renumbering may also give the impression that a 2.7 or
> 2.8
> >> might be coming or at least make some wonder what happened to those
> >> versions.
> >>
> >> On Sat, May 19, 2018 at 8:58 PM Paul King  wrote:
> >>>
> >>>
> >>> Hi,
> >>>
> >>> I was wondering what people thought about renumbering Groovy 2.6 to
> 2.9.
> >>> It is only a subtle change but I think better conveys that it isn't a
> >>> small step up
> >>> from 2.5 but rather something just a bit short of 3.
> >>>
> >>> Thoughts?
> >>>
> >>> Cheers, Paul.
> >>>
> >
>

Re: [DISCUSS] Renumber Groovy 2.6 to 2.9

[Cédric Champeau]

+1 but alternatively, we could just skip 2.6 and go straight to 3.0.

Le dim. 20 mai 2018 à 15:25, mg  a écrit :

> 2.9.0 could make people ask themselves where 2.6/2.7/2.8 went, whereas
> 2.97 is so far from 2.5, that I think people would get that it means more
> "3.0 minus small, but (significant) delta" (i.e. not just an epsilon, as
> with 2.99, which Russel suggested). Plus the "7" has a mnemonic quality,
> making it easier for everyone to remember what the main point of this
> release was...
>
> (2.9 would be much better than 2.6, though...)
>
>
>  Ursprüngliche Nachricht 
> Von: Andres Almiray 
> Datum: 20.05.18 15:11 (GMT+01:00)
> An: dev@groovy.apache.org
> Cc: pa...@asert.com.au
> Betreff: Re: [DISCUSS] Renumber Groovy 2.6 to 2.9
>
> I’d suggest to keep it simple, go with 2.9.0.
>
> Sent from my primitive Tricorder
>
> On 20 May 2018, at 21:50, mg  wrote:
>
> What about 2.97 ? Incorporates a JDK 7 reference, and is not too close to
> 3.0 (Bugfixes could go into 2.97.1 etc..., so the "7" could be kept).
>
>  Ursprüngliche Nachricht 
> Von: Russel Winder 
> Datum: 20.05.18 12:26 (GMT+01:00)
> An: pa...@asert.com.au, dev@groovy.apache.org
> Betreff: Re: [DISCUSS] Renumber Groovy 2.6 to 2.9
>
> On Sun, 2018-05-20 at 13:58 +1000, Paul King wrote:
> > Hi,
> >
> > I was wondering what people thought about renumbering Groovy 2.6 to 2.9.
> > It is only a subtle change but I think better conveys that it isn't a
> small
> > step up
> > from 2.5 but rather something just a bit short of 3.
> >
>
> If it is to be the last 2.X release why not 2.99 to make it more "in your
> face"?
>
> --
> Russel.
> ==
> Dr Russel Winder  t: +44 20 7585 2200
> 41 Buckmaster Roadm: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk
>
>

Re: About raw string and enhanced try-with-resource

[Cédric Champeau]

+1 for both. In particular I like that you can choose your own delimiter in
Java 11 raw strings.

2018-05-15 12:48 GMT+02:00 Jesper Steen Møller :

> On 15 May 2018, at 12.31, Paolo Di Tommaso 
> wrote:
>
>
> No. There's an important difference: raw strings do not escape any special
> character ie. backlashes, dollars, back-ticks, etc.
>
>
> Ah, I didn't actually realize that Groovy's current '''multiline''' style
> interpreted \ escapes. Haven't used it much, I suppose.
>
> This is very useful for DSLs when it's required to embed a piece of
> foreign code (think for example Bash) into a string. With groovy
> multi-line string you still need to escape a lot stuff, making very
> difficult for the user to handle it.
>
>
> I totally agree, I was just wrong about the semantics of the '''multiline,
> non-interpolation string'''.
>
> -Jesper
>
>

Re: What the... static compile by default

[Cédric Champeau]

Hi Daniel and sorry you are "tired". Maybe the tone I used was
inappropriate?, but it wasn't directed at you personally. I'm quite
surprised to see some things like that happening on master without any
discussion on the MLs. Maybe that's because I expect too much from the
developers of Groovy, but I strongly think we owe better to the community,
and in particular code quality. In that area, we don't have _any_ peer
review. Everybody works on master, and I think that's a bad idea. Things
like this happen, but we have to realize that Groovy is used by tens of
thousands of developers, so any choice we make has consequences. So, if we
had peer reviews, questions like this wouldn't happen. Should you want to
introduce a feature, it wouldn't go to master without a review from another
committer/PMC. Same for Paul, and same for me. I think it's too easy to
push to master today, and this bites us.

So to come back to the original topic of this thread, I never saw that
ticket, and, for one, don't read every ticket out there, I mostly have time
to follow discussions on the MLs. So I can react when I see something that
looks wrong to me. Here, I don't have the impression that the ticket even
comes to any conclusion, it just "happened". I still think the approach is
incorrect, I'd typically very much prefer a custom file extension for
example. And if it's just for internal testing, the compiler configuration
already has everything we need without having to rely on a system property.
We have to realize that adding a property without testing it in combination
with other flags is a problem too.

That said, since I'm not contributing code anymore (my last contribution
was rewriting most of the build, which I hope was helpful), I'm happy to
step down and let you work as you wish. I mostly want to make sure Groovy
goes in the right direction. If I'm a blocker, I have no problem with that.

2018-05-07 17:40 GMT+02:00 Jeff Scott Brown :

>
>
> On 2018/05/07 14:59:09, "Daniel.Sun"  wrote:
>
>> Hi Cédric,
>>
>>   Feel free to remove any code.
>>   To be honest, I am really tired.
>>   Bye Groovy community.
>>
>> Cheers,
>> Daniel.Sun
>>
>> }
>
> Daniel,
>
> Please reconsider.  I think the tone at the beginning of this thread was
> unfortunate and I expect that has contributed to your frustration.
>
> Your contributions are very much appreciated by the community and you
> should be proud of the work you are doing with Groovy.  It would be a real
> shame to lose your enthusiasm and contributions to this great language and
> great ecosystem.  I mean that sincerely.
>
> Let me know whatever I can do to help.
>
> Thanks for all of your great work.  Well done sir!
>
>
>
>
> JSB
> --
> Jeff Scott Brown
> OCI Partner and Principal Software Engineer
> OCI Grails Practice Lead
>
> Autism Strikes 1 in 166
> Find The Cause ~ Find The Cure
> http://www.autismspeaks.org/
>

What the... static compile by default

[Cédric Champeau]

Hi folks,

Sorry to be the bad cop again, but when the heck did this land into core:

https://github.com/apache/groovy/blob/5443e87882f9b88169876f6d043ed54b5ae9023b/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L943-L988

As much as I love static compilation, this should never have landed into
master, at least not without an agreement. I strongly believe enabling
static compilation by default using a system property is a bad thing. We
already have an official, supported mechanism for this, which is documented
[1], so adding one silently is not very nice. I reckon lots of users want
to have static compilation by default, but I don't think a system property
is the way to go.

[1]
http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default

Re: [VOTE] Release Apache Groovy 2.5.0-rc-2

[Cédric Champeau]

+1, even though some tests are not passing, see below, I think we should
take a look at them

gradle -b wrapper.gradle wrapper : ok
./gradlew clean dist: ok (https://scans.gradle.com/s/c7jwthugis7b2, we
seriously need to do something for the performance of Groovydoc...)
./gradlew testAll: ko (https://scans.gradle.com/s/wkyfhscuyzipy/tests/failed
)

Checksum ok:

$ sha256sum apache-groovy-src-2.5.0-rc-2.zip | cut -d" " -f1 | diff -
apache-groovy-src-2.5.0-rc-2.zip.sha256

< 913c59763d395d5e3cdd8296342f635d0a6786665b00b300149b06153364d9be
---
> 913c59763d395d5e3cdd8296342f635d0a6786665b00b300149b06153364d9be

Signature ok:

$ gpg --verify apache-groovy-src-2.5.0-rc-2.zip.asc
gpg: assuming signed data in `apache-groovy-src-2.5.0-rc-2.zip'
gpg: Signature made Thu 03 May 2018 09:40:34 AM CEST using RSA key ID
0FB1CD0B
gpg: Good signature from "Paul King "
gpg: aka "Paul King "
gpg: aka "Paul King "
gpg: aka "Paul King "
gpg: aka "keybase.io/paulk_asert "
...


2018-05-03 10:49 GMT+02:00 Paul King :

>
> Dear development community,
>
> I am happy to start the VOTE thread for a Groovy 2.5.0-rc-2 release!
>
> This release includes 16 bug fixes/improvements as outlined in the
> changelog:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12318123=12343030
>
> Tag: https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=
> tag;h=refs/tags/GROOVY_2_5_0_RC_2
> Tag commit id: 9ffe537eaa88ac6d944a4d3d8cd20c8cda86bc98
>
> The artifacts to be voted on are located as follows (r26677).
> Source release: https://dist.apache.org/repos/dist/dev/groovy/2.5.0-rc-2/
> sources
> Convenience binaries: https://dist.apache.org/repos/
> dist/dev/groovy/2.5.0-rc-2/distribution
>
> Release artifacts are signed with a key from the following file:
> https://dist.apache.org/repos/dist/dev/groovy/KEYS
>
> Please vote on releasing this package as Apache Groovy 2.5.0-rc-2.
>
> Reminder on ASF release approval requirements for PMC members:
> http://www.apache.org/legal/release-policy.html#release-approval
> Hints on validating checksums/signatures (but replace md5sum with
> sha256sum):
> https://www.apache.org/info/verification.html
>
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
>
> [ ] +1 Release Apache Groovy 2.5.0-rc-2
> [ ]  0 I don't have a strong opinion about this, but I assume it's ok
> [ ] -1 Do not release Apache Groovy 2.5.0-rc-2 because...
>
> Here is my vote:
>
> +1 (binding)
>
>

Re: [ANNOUNCE] Apache Groovy 2.5.0-rc-1 released

[Cédric Champeau]

2018-04-10 11:52 GMT+02:00 Marcin Erdmann :

> 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?
>

Yes, please :) Note that Maven behaves the same and tries to download the
jar too.

Re: [ANNOUNCE] Apache Groovy 2.5.0-rc-1 released

[Cédric Champeau]

There's a bug in the published pom: it says zip
instead of pom. We should fix this, thanks for the
report!



2018-04-09 23:15 GMT+02:00 Marcin Erdmann :

> 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-
> all: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-
> all: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  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=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.
>>
>
>

Re: [ANNOUNCE] Apache Groovy 2.5.0-rc-1 released

[Cédric Champeau]

Hi Paul,

Thanks for making this release. It would be nice to have _cummulative_
change log/release notes since 2.4. As they are now, the notes are pretty
useless as it doesn't indicate what changes from the last major release.

WDYT?

2018-04-09 8:07 GMT+02:00 Paul King :

> 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?
> projectId=12318123=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.
>

Re: About the Phoenix plan for Groovy

[Cédric Champeau]

I'm not sure how the API would look like either, but clearly the
"reflection approach" is not enough since it better represents runtime
types than compile time types. Just getting the relationships between the
things is hard to get today. We probably need something better for
synthetic union/intersection types, as it's very hackish today.

2018-04-08 20:57 GMT+02:00 Jochen Theodorou <blackd...@gmx.org>:

> On 08.04.2018 20:46, Cédric Champeau wrote:
> [...]
>
>> Honestly I don't have much time to work on Groovy. And if I had, the
>> generics STC bugs would be the last thing I'd like to get my hands into.
>> The ClassNode infrastructure was retrofitted to introduce generics back in
>> 1.5, but since it was for dynamic world, it wasn't really designed for what
>> we do now.
>>
>
> the structure was designed to closely represent what we get through
> reflection from Java, to make it easy to make this available. Of course in
> Java too generics are like an not so well fitting add-on. But since you
> keep coming with this I am curious in what you specifically miss, that must
> be in ClassNode
>
> So, every bugfix you make is likely to introduce another bug somewhere
>> else. That makes the process very painful. More so when type inference
>> enters the game. Jochen and I spent a lot of time writing, rewriting helper
>> methods to make this easier, but it's just too hard for the little time I
>> can afford.
>>
>
> fixing generics bugs usually takes long. But I really wonder how the API
> would have to look like to make this easy. I am not having enough fantasy
> for that it seems
>
> bye Jochen
>
>

Re: About the Phoenix plan for Groovy

[Cédric Champeau]

2018-04-08 19:31 GMT+02:00 Daniel.Sun :

> Hi Cédric,
>
>At first we all admit your effort on STC is great :-)
>
>I usually try to use STC for better performance, but sadly I have to
> turn to dynamic mode sometimes. Recently I wrote a hadoop example in Java,
> then copied the Java code as Groovy code and tried to compile with STC,
> failed to compile because of generics issue. So I believe STC had been
> tested for many scenario as you said, but it had not been tested with the
> code in some real projects, e.g. Spring, Hibernate, etc. The Phoenix plan
> tries to find a way to polish the STC and not to re-invent the wheels.
>

It was tested on real code too, I can assure you :)

>
>Finally we wish you could set aside some time to fix some existing
> bugs, some of which are hard for us to fix but may be not that hard for you
> - the creator of STC ;-)
>

Honestly I don't have much time to work on Groovy. And if I had, the
generics STC bugs would be the last thing I'd like to get my hands into.
The ClassNode infrastructure was retrofitted to introduce generics back in
1.5, but since it was for dynamic world, it wasn't really designed for what
we do now. So, every bugfix you make is likely to introduce another bug
somewhere else. That makes the process very painful. More so when type
inference enters the game. Jochen and I spent a lot of time writing,
rewriting helper methods to make this easier, but it's just too hard for
the little time I can afford.

off topic: why is incubator always in CC of the emails you write? Looks
like your email client is misconfigured somehow.

Re: Determining the registered DGM classes at runtime

[Cédric Champeau]

2018-04-06 22:42 GMT+02:00 Jochen Theodorou :

> ah sorry, I was not explaining right...
>
> I was going to suggest something similar to what you probably already have
> found, which is StaticTypeCheckingSupport.EXTE
> NSION_METHOD_CACHE.getExtensionMethods(ClassLoader)
> but for some reason I do not understand the constant is protected and the
> type for it is a private static inner class... which means nobody can use
> this really. bummer. So maybe patch that and make it public? See
> GROOVY-8536 for this
>
>
It is private because it was never meant for external consumption. It's
much easier to evolve an API/internals if things are kept private. Look at
the nightmare of people using internal APIs in Gradle and you'll understand
what I mean: the more the API is open, the bigger the surface is, and the
higher the risk to break consumers when you want to change an
implementation detail is.

So we _could_ make this API public, but then it means adding test coverage
and making sure we stabilize the API, if it ever makes sense.

Re: About the Phoenix plan for Groovy

[Cédric Champeau]

2018-04-08 3:58 GMT+02:00 Daniel Sun :

> Hi all,
>
>   I have a plan named "Phoenix" to share. As we all know, STC is buggy,
> one of reasons is that STC lacks tests during development.


It's interesting you put test coverage as one reason that the STC is buggy,
but the only reason you mention. As the author of most of the code here,
I'd argue that there are way more STC tests than any other feature in the
language :) Almost 1/3 of the test suite is about STC/static compilation. I
think the reasons it's buggy are not to be found here, but on the
complexity of building a type safe feature on top of an AST that was
primarily designed years ago for a dynamic language. In particular, the
ClassNode infrastructure, and the way it handles generics, was a true
nightmare. Second, type inference is extremely hard. Flow typing is also
something complex to get right, in particular discovering variable capture,
or "effectively final" variables. The last part, bytecode generation, is
very easy in comparison. Eventually, the STC was designed as an AST
visitor, which, unfortunately, doesn't allow to carry much context (the
various visit methods do not take a context argument, which would have
helped a lot).

So I'm all in for a new version, but that's not a simple task. Especially
when people disagree on what types should be inferred where. Look at what
happens with Java and the semantics of "var", or list literals, and lambda
type inference. This is the tricky part, which _always_ introduces bugs.
The Java compiler itself is not bug free...


> So I make a plan
> to let STC mature enough:
>
> 1) Make the Parrot parser be able to parse pure Java source to Groovy AST;
> 2) Use STC to analyze the AST and generate the bytecode;
> 3) Run the existing tests of some famous Java projects, e.g. Spring,
> Hibernate, Guava, Hadoop, etc. ;
> 4) Check the test result. If all tests pass, our Phoenix plan is completed.
>
> Another benefit of the plan is that we will have a brand new joint
> compiler, no stub generation is required :-)
>
> Any thoughts?
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: Returned post for annou...@apache.org

[Cédric Champeau]

Thanks, Paul!

2018-03-28 10:08 GMT+02:00 Paul King :

> Fixed.
>
> On Wed, Mar 28, 2018 at 1:47 AM, Paul King  wrote:
>
>>
>> Looks like we'll have to improve how we present our download information.
>> Even though the Apache release repo and bintray mirror have all the
>> necessary files and it's obvious during voting, that info is kind of lost
>> in our "prettified" download page. I've created GROOVY-8522 to track this.
>>
>> Paul.
>>
>>
>> -- Forwarded message --
>> From: 
>> Date: Wed, Mar 28, 2018 at 1:14 AM
>> Subject: Returned post for annou...@apache.org
>> To: pa...@apache.org
>>
>>
>>
>> Hi! This is the ezmlm program. I'm managing the
>> annou...@apache.org mailing list.
>>
>> I'm sorry, your message (enclosed) was not accepted by the moderator.
>> If the moderator has made any comments, they are shown below.
>>
>> >  >
>> The download page does not have any links to KEYS, sigs or hashes for the
>> sources.
>> AFAIK these are required:
>>
>> https://www.apache.org/dev/release-distribution#sigs-and-sums
>>
>> There should also be instructions on how to verify the download(s)
>>
>> <  <
>>
>>
>>
>> -- Forwarded message --
>> From: Paul King 
>> To: dev@groovy.apache.org, us...@groovy.apache.org, annou...@apache.org
>> Cc:
>> Bcc:
>> Date: Wed, 28 Mar 2018 00:28:14 +1000
>> Subject: [ANNOUNCE] Apache Groovy 2.4.15 released
>> Dear community,
>>
>> The Apache Groovy team is pleased to announce version 2.4.15 of Apache
>> Groovy.
>> Apache Groovy is a multi-facet programming language for the JVM.
>> Further details can be found at the http://groovy.apache.org website.
>>
>> This release is a maintenance release of the GROOVY_2_4_X branch.
>> It is strongly encouraged that all users using prior
>> versions on this branch upgrade to this version.
>>
>> This release includes 6 bug fixes/improvements as outlined in the
>> changelog:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
>> ctId=12318123=12342853
>>
>> Sources can be downloaded from: http://www.groovy-lang.org/download.html
>> Convenience binaries, SDK and documentation can be found at:
>> http://www.groovy-lang.org/download.html
>> Jars are also available within the major binary repositories.
>> We would like to thank all people who contributed to this release.
>>
>> We welcome your help and feedback. 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.
>>
>>
>>
>>
>

Re: [RFE] Methods as expressions

[Cédric Champeau]

It's funny to see arguments about compatibility with Java here. Groovy's
compatibility with Java is the promise that you can _almost_ copy and paste
Java code and it compiles in Groovy. Not the other way around ;)

In any case, I was doubtful as you are here before actually using it in
Kotlin. After a few weeks, it became clear to me this syntax was both more
concise and more self-explanatory.

2018-03-21 9:07 GMT+01:00 David Dawson :

> LOL. thanks, I probably deserved that being thrown back at me :-)
>
> I think that Jochen said it best "It seemed to be part of a bigger
> picture, but the bigger picture is missing."
>
> My CS background is on the weaker side, so I can't quite say what I want...
>
> Apart from Groovy, the two languages that I've *enjoyed* working with
> over the past few years are Clojure and Rust.  Of the things in them, "code
> as data" and pure functions from clojure and heavier expression usage in
> Rust (of course, the actual advanced thing in Rust, lifetimes, aren't
> applicable at all to the JVM) are what I miss from them in Groovy.  Still,
> Groovy does dominate my development when I have much choice in client
> projects.
>
> Echoing Jochen though, perhaps asking Cedric and Daniel, are these syntax
> suggestions picking around anything deeper?  I'd love there to be, in
> Groovy 4 or whatever.
>
> David.
>
>
> On 20 March 2018 at 23:16, MG  wrote:
>
>>
>>
>> On 20.03.2018 17:16, David Dawson wrote:
>>
>>> To give an alternate take on the topic.
>>>
>>> The best thing in Groovy when it first started gaining adoption was this
>>>
>>> ["hello"], "world"].collect {
>>>   it * 2
>>> }.each { println it }
>>>
>>> Utterly incompatible with Java, happily destroying its idioms.
>>> Collection literals, closures, removing parans, functional chaining. Source
>>> compatibility was nice, but proper two way interaction in the object models
>>> was better.
>>>
>>
>> I agree that that was one of the features that drew me to Groovy. But I
>> never felt that it did break with or deviate from Java syntax - quite the
>> contrary, I immediately felt at home using this syntax, since it felt like
>> a organic extension.
>> The syntax is in general one of the strenghts of Groovy for me: It has
>> "somehow" managed to avoid falling into the many syntax pitfalls that other
>> languages so often exhibit (e.g. var/val in Scala I have already posted;
>> Python is just weird, with its underscores and indentation having semantic
>> meaning; Ruby supports curly braces and Algol begin/end; Basic is a car
>> crash from start to finish; etc).
>> I have programmed in 6502/68000 assembler to Occam, and we could all be
>> programming in Brainfuck (https://en.wikipedia.org/wiki/Brainfuck) or
>> Whitespace (https://en.wikipedia.org/wiki/Whitespace_(programming_langu
>> age)). Humans are adaptable. But a powerful, clear, logical,
>> compact/concisce, while still well to comprehend/read syntax which helps in
>> minimizing programming errors is a clear advantage.
>>
>> I came to Groovy originally to gain access to the above, and stayed
>>> because I could go quicker and still read what I'd written afterwards. I've
>>> used a raft of languages and, to me at least, expression oriented syntax is
>>> a boon for lots of styles of development and problems. Adopting aspects of
>>> that into Groovy, in the pragmatic way that Groovy gives us, would be
>>> great, for me at least.
>>>
>>
>> The suggested extension as I understand it is only syntactic sugar, to be
>> able to write "= ..." instead of "{ ... }" to define simple function
>> bodies. It does not extend Groovy's capabilities in any way.
>> Are you thinking more along the line of first order functions support
>> (outside of Groovy's existing closures and upcoming Groovy 3.0 Java style
>> lambdas):
>> final handler = String fun(String s, int i, x) { ... }
>> or
>> final handler = String _(String s, int i, x) { ... }
>> ?
>>
>> This is broader than the email chain may warrant, sorry if it is and
>>> hopefully it doesn't drag things off track, but I always pay attention when
>>> I see someone proposing substantial new things in Groovy. Perhaps what's
>>> needed is a broader conversation on the philosophical direction of Groovy.
>>> Is it just to be Java+, or something else?   I'd like it to regain
>>> something of the lead it once had in raw productivity features and good,
>>> strong language features to adopt.I know that lambdas burned the
>>> community a bit by causing a break in compatibility with Java for so long,
>>> but since we've got Parrot integrated, and that gap closed, it strikes me
>>> that of all times, now is the time for the Groovy community to be bolder
>>> about the direction it can go in.
>>>
>>
>> Thinking/discussing is always good in my book: What big and bold
>> directions did you have in mind ? :-)
>>
>>
>>
>>
>>
>

Re: [RFE] Methods as expressions

[Cédric Champeau]

Again that's a declaration of intent (if you put apart the fact that you
can have style rules that force you to put the brackets on new lines).

When I write:

double surface(double x, double y) = x * y

It's very clear what the intent of this is. It's an expression, a
_function_. On the other hand, { ... } declares a block, that could
represent an expression, or a statement, or a list of statements, one of
them returning an expression. I like the declaration of intent.

2018-03-20 12:20 GMT+01:00 mg <mg...@arscreat.com>:

> Am having a migraine right now so hard to concentrate / think straight but
> it seems all that syntax does is getting rid of a single character ?
>
> Integer truth() { 42 }
>
> could then be written as
>
> Integer truth() = 42
>
>
> or
>
> String hello(String name) { "Hello $name" }
>
> String hello(String name) = Hello $name"
>
> (why did you use a return keyword in your sample ?)
>
> I dont see an improvement in readability here - the main "advantage" is
> that curly braces are annoying to input on non-US keyboard layouts ;-)
>
> mg
>
>
>
>  Ursprüngliche Nachricht 
> Von: Cédric Champeau <cedric.champ...@gmail.com>
> Datum: 20.03.18 11:41 (GMT+01:00)
> An: dev@groovy.apache.org
> Betreff: [RFE] Methods as expressions
>
> Hi,
>
> One of the Kotlin features I really like is the short-hand notation for
> simple expression methods:
>
> class Foo {
> fun truth(): Integer = 42
> }
>
> For example, in Groovy, you write:
>
> @Controller("/") class HelloController {
>
> @Get("/hello/{name}")
> String hello(String name) {
> return "Hello $name"
> }
> }
>
>
> but we could write:
>
> @Controller("/")
> class HelloController {
> @Get("/hello/{name}")
> String hello(String name) = "Hello $name"
> }
>
>
> It's more concise and makes the "functional style" more readable. Is this
> something Groovy users would appreciate?
>
>

Re: [RFE] Methods as expressions

[Cédric Champeau]

I agree, that's the syntax I use for now. But I like the expression syntax
`=` because of the explicitness of the expression (it's a function which
value is ...). It's less about saving characters than it is about
expressing the intent.

2018-03-20 12:08 GMT+01:00 Andres Almiray <aalmi...@gmail.com>:

> FYI you can also write it like
>
> @Controller("/") class HelloController {
> @Get("/hello/{name}")
> String hello(String name) { "Hello $name" }
> }
>
> So you're only saving 2 characters (space and closing brace) by following
> Kotlin/Scala syntax.
>
> Cheers,
> Andres
>
>
> ---
> Java Champion; Groovy Enthusiast
> JCP EC Associate Seat
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary,
> and those who don't.
> To understand recursion, we must first understand recursion.
>
> On Tue, Mar 20, 2018 at 11:41 AM, Cédric Champeau <
> cedric.champ...@gmail.com> wrote:
>
>> Hi,
>>
>> One of the Kotlin features I really like is the short-hand notation for
>> simple expression methods:
>>
>> class Foo {
>> fun truth(): Integer = 42
>> }
>>
>> For example, in Groovy, you write:
>>
>> @Controller("/") class HelloController {
>>
>> @Get("/hello/{name}")
>> String hello(String name) {
>> return "Hello $name"
>> }
>> }
>>
>>
>> but we could write:
>>
>> @Controller("/")
>> class HelloController {
>> @Get("/hello/{name}")
>> String hello(String name) = "Hello $name"
>> }
>>
>>
>> It's more concise and makes the "functional style" more readable. Is this
>> something Groovy users would appreciate?
>>
>>
>

[RFE] Methods as expressions

[Cédric Champeau]

Hi,

One of the Kotlin features I really like is the short-hand notation for
simple expression methods:

class Foo {
fun truth(): Integer = 42
}

For example, in Groovy, you write:

@Controller("/") class HelloController {

@Get("/hello/{name}")
String hello(String name) {
return "Hello $name"
}
}


but we could write:

@Controller("/")
class HelloController {
@Get("/hello/{name}")
String hello(String name) = "Hello $name"
}


It's more concise and makes the "functional style" more readable. Is this
something Groovy users would appreciate?

Re: [GEP]Lazy evaluation for Groovy 3

[Cédric Champeau]

-1, I also think this is confusing.

2018-03-17 13:30 GMT+01:00 Guillaume Laforge :

> I also find it confusing, in particular because it's not obvious, and
> there's some redundancy already with @Lazy (and Paolo has a good point as
> well as using closures are somewhat of a palliative as well)
> Perhaps we could think of ways to further improve / expand @Lazy perhaps?
> (rather than inventing something new / additional)
>
> On Sat, Mar 17, 2018 at 12:01 PM, Paolo Di Tommaso <
> paolo.ditomm...@gmail.com> wrote:
>
>> Frankly I found this confusing, it looks to me that the same concept can
>> be implemented just using a closure.
>>
>>
>> p
>>
>> On Sat, Mar 17, 2018 at 9:08 AM, Daniel.Sun  wrote:
>>
>>> Hi Guillaume,
>>>
>>> I planed to generate proxy for lazy evaluation, so even if the reference
>>> of
>>> object is accessed, evaluation will not be triggered either, which is
>>> different from @Lazy
>>>
>>> Cheers,
>>> Daniel.Sun
>>>
>>>
>>>
>>>
>>> --
>>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>>
>>
>>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge  / Google+
> 
>

Re: Stop maintaining 2.4.x?

[Cédric Champeau]

I don't think calling it 3.0-jdk7 is a good thing to do: the runtime would
be different, with different bugs. Plus, it would add confusion on some
build tools, with random dependencies on jdk7, or indy, or ...

I think we should focus on getting 2.5 out, and then go with 3.0 asap.

2018-03-12 17:58 GMT+01:00 Wilson MacGyver :

> Calling it 3.0.0-jdk7 would reduce confusion and increase 3.0 adaption
>
> On Mon, Mar 12, 2018 at 12:04 PM Russel Winder 
> wrote:
>
>> On Mon, 2018-03-12 at 12:23 +1000, Paul King wrote:
>> > 2.6 is just 3.0 backported to JDK7 (minus those features which don't
>> > backport easily without a JVM8).
>> > Most users should be skipping 2.6 and going straight to 3.0 which is
>> > where
>> > our focus should be ... soon.
>> > 2.6 is meant to help people start moving towards Parrot who are stuck
>> > on
>> > JDK7. Given it has limitations
>> > anyway, I wouldn't imagine we'd do anything more than a 2.6.0 release
>> > -
>> > unless other community
>> > members contributed the PRs to advance it.
>> >
>>
>> Sounds like it isn't a 2.6.0 at all then. Should it be called 3.0.0-
>> jdk7 so as to reflect what it actually is?
>>
>> > >
>> --
>> Russel.
>> ===
>> Dr Russel Winder  t: +44 20 7585 2200 <+44%2020%207585%202200>
>> 41 Buckmaster Road
>> 
>> m: +44 7770 465 077 <+44%207770%20465077>
>> London SW11 1EN, UK   w: www.russel.org.uk
>>
>

Re: Stop maintaining 2.4.x?

[Cédric Champeau]

I do. It's long overdue that 2.5 should be out. By working on 4 (!)
different branches, we just can't manage to publish 2.5, this is a shame.

2018-03-11 15:23 GMT+01:00 Mauro Molinari <mauro...@tiscali.it>:

> Il 11/03/2018 15:12, Cédric Champeau ha scritto:
>
>> Hi folks,
>>
>> I'm wondering if it's reasonable to continue maintaining 2.4.x. We have a
>> long standing 2.5 release waiting, as well as 2.6 and master. Given the
>> number of maintainers we have, I feel it's just slowing us down, and we
>> need to move forward. Honestly I'd be in favor of only maintaining 2
>> branches: 2.5.x and 3.0.x.
>>
>> WDYT?
>>
>> Isn't 2.5 still beta? Do you think to stop supporting any stable release?
>
> --
>
> Mauro Molinari
> E-mail: mauro...@tiscali.it
>
>

Stop maintaining 2.4.x?

[Cédric Champeau]

Hi folks,

I'm wondering if it's reasonable to continue maintaining 2.4.x. We have a
long standing 2.5 release waiting, as well as 2.6 and master. Given the
number of maintainers we have, I feel it's just slowing us down, and we
need to move forward. Honestly I'd be in favor of only maintaining 2
branches: 2.5.x and 3.0.x.

WDYT?

Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

[Cédric Champeau]

You have to be aware that this java syntax prepares the way for pattern
matching. I think we need to wait and see before doing it.

Le 1 mars 2018 17:45, "Paolo Di Tommaso"  a
écrit :

> I agree that groovy should continue to be compatible with java syntax as
> long as possible.
>
>
> Cheers,
> Paolo
>
>
> On Thu, Mar 1, 2018 at 5:28 PM, Guillaume Laforge 
> wrote:
>
>> 1) Very useful :-)
>> 2) I think we should continue the compatibility with Java, like we're
>> doing for Groovy 3, and add that syntax when it's finalized.
>> 3) It's too early to think about the implementation, let's wait till the
>> syntax is crystalized first!
>>
>> But yeah, I like the idea of supporting it.
>> (and we could potentially support it before the Java version containing
>> it is released)
>>
>> Guillaume
>>
>>
>> On Thu, Mar 1, 2018 at 4:39 PM, Jesper Steen Møller > > wrote:
>>
>>> Hi list
>>>
>>> Java 11 (or perhaps 12) might see a new functionality known as switch
>>> expressions (https://bugs.openjdk.java.net/browse/JDK-8192963).
>>>
>>> While the current Groovy implicit return functionality works with the
>>> switch statement as-is, the switch* expression* is a more general
>>> construct, basically it is to the conditional operator (a ? b : c) what the
>>> switch *statement* is to if/then/else-if/else. An example:
>>>
>>> int numLetters = switch (day) {
>>> case MONDAY, FRIDAY, SUNDAY -> 6;
>>> case TUESDAY -> 7;
>>> case THURSDAY, SATURDAY -> 8;
>>> case WEDNESDAY -> 9;
>>> };
>>>
>>> with
>>>
>>> case LABEL -> expression;
>>>
>>> essentially sugar for
>>>
>>> case LABEL: break expression;
>>>
>>> As I see it: It could add utility to the Groovy language, and adopting
>>> it would keep up the the Java-compatibility gap, which I think is a
>>> valuable gateway-drug to discovering the joys of Groovy. The "break
>>>  syntax isn't pretty, but the arrows look fine and incur no
>>> syntax compatibility problem, as far as I can see.
>>>
>>> Now, this being Groovy, the cases should surely support the extended
>>> "isCase"-support, as described so well here:
>>> http://mrhaki.blogspot.dk/2009/08/groovy-goodness-switch-statement.html
>>>
>>> So, three questions remain:
>>> 1) Useful or not?
>>> 2) This Java compatibility - is it still a thing? I remember a similar
>>> proposal a little while back, but this would align better with Java.
>>> 3) This could be implemented using existing AST's if we *really* want
>>> to, but it would be clumsy. This AST transformer compatibility - is it
>>> still a thing?
>>>
>>> -Jesper
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer & PMC Vice-President
>> Developer Advocate @ Google Cloud Platform
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge  / Google+
>> 
>>
>
>

Re: [VOTE] Release Groovy 2.5.0-beta-3

[Cédric Champeau]

+1 (binding).

Build successful: https://scans.gradle.com/s/raolpvm3dk5cm

Checksum ok:

> cat apache-groovy-src-2.5.0-beta-3.zip.sha256
700541e2c94f131f69d5ad3e9099819fc6375b84770d89539aee4a5e6fd636db
> sha256sum -b apache-groovy-src-2.5.0-beta-3.zip
700541e2c94f131f69d5ad3e9099819fc6375b84770d89539aee4a5e6fd636db
*apache-groovy-src-2.5.0-beta-3.zip

Signature ok:

> gpg --verify apache-groovy-src-2.5.0-beta-3.zip.asc
gpg: assuming signed data in `apache-groovy-src-2.5.0-beta-3.zip'
gpg: Signature made Tue 20 Feb 2018 05:25:50 AM CET using RSA key ID
0FB1CD0B
gpg: Good signature from "Paul King "
gpg: aka "Paul King "
gpg: aka "Paul King "
gpg: aka "Paul King "
gpg: aka "keybase.io/paulk_asert "


2018-02-20 6:36 GMT+01:00 Paul King :

>
> Dear development community,
>
> I am happy to start the VOTE thread for a Groovy 2.5.0-beta-3 release!
>
> There are still a few things we plan to work on before the final release
> but
> we anticipate this will be the last beta for the 2.5.0 release train. So
> we'd greatly
> appreciate as much testing as possible before we get the first RC ready
> shortly.
>
> This release includes 39 bug fixes/improvements as outlined in the
> changelog:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12318123=12341721
>
> Tag: https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=
> tag;h=refs/tags/GROOVY_2_5_0_BETA_3
> Tag commit id: 1f5ba16e86ebc2ed9146aab13304e316c812a838
>
> The artifacts to be voted on are located as follows (r25155).
> Source release: https://dist.apache.org/repos/
> dist/dev/groovy/2.5.0-beta-3/sources
> Convenience binaries: https://dist.apache.org/repos/
> dist/dev/groovy/2.5.0-beta-3/distribution
>
> (If building from the source zip, the bootstrapping details changed
> recently,
> make sure to read the README.adoc file to brush up on the details if
> needed.)
>
> Release artifacts are signed with a key from the following file:
> https://dist.apache.org/repos/dist/dev/groovy/KEYS
>
> Please vote on releasing this package as Apache Groovy 2.5.0-beta-3.
>
> Reminder on ASF release approval requirements for PMC members:
> http://www.apache.org/legal/release-policy.html#release-approval
>
> Hints on validating checksums/signatures (but replace md5sum with
> sha256sum):
> https://www.apache.org/info/verification.html
>
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
>
> [ ] +1 Release Apache Groovy 2.5.0-beta-3
> [ ]  0 I don't have a strong opinion about this, but I assume it's ok
> [ ] -1 Do not release Apache Groovy 2.5.0-beta-3 because...
>
> Here is my vote:
>
> +1 (binding)
>
>

Re: Groovy plugin for Eclipse 2.9.2 has been released

[Cédric Champeau]

Congrats, that's very important work indeed!

2018-01-09 12:32 GMT+01:00 Paul King :

> +1! Nice work Eric!
>
> On Tue, Jan 9, 2018 at 9:11 PM, Mauro Molinari 
> wrote:
>
>> Hello all,
>> I hope this message won't be considered inappropriate, but I would like
>> to say my personal big "Thank you!" to Eric Milles for the impressive work
>> he has done to revive the Groovy Eclipse plugin after Pivotal stopped to
>> support its development.
>>
>> After more than a year of work, he alone was able to provide to most
>> usable and reliable version of this Eclipse plugin ever.
>>
>> I think Eric's work is extremely important and valuable for both the
>> Eclipse and the Groovy communities.
>>
>> The 2.9.2 announcement and release notes page is available at:
>> https://github.com/groovy/groovy-eclipse/wiki/Groovy-Eclipse
>> -2.9.2-Release-Notes
>>
>> Happy new year to everyone!
>> Mauro
>>
>>
>

Re: [VOTE]Support package scope via `package` keyword

[Cédric Champeau]

I'd tend to be -1 on the name "package" and 0 on the feature. The -1 is
because "package" is not a modifier by itself. I'd prefer "package private"
(the official Java name for this). So it leads to the 0, because "package
private" is kind of verbose, and doesn't save much from "PackageScope".
However, it drives me to another topic that is related and that we talked
about a few years back: having the ability to use annotations without the
`@`. So you would say `compilestatic class Foo`, or `packagescope Foo foo`.

2017-12-29 12:35 GMT+01:00 Jochen Theodorou :

> On 29.12.2017 11:58, Paul King wrote:
> [...]
>
>> I am unsure if I made myself clear. I think the default should remain as
>> CLASS but there could be an additional ALL enum value. Then again we could
>> just have a PackageScopeTarget[] ALL constant (though we have an
>> outstanding issue around using constants in annotation attributes we'd have
>> to check didn't get in the way).
>>
>
> It doesn´t make sense on local variables, the package, parameters or
> parameter types... Maybe I misunderstood what you mean with "ALL"
>
>
> bye Jochen
>

Re: A reminder about how things are compiled

[Cédric Champeau]

Nope, but I see you're using JDK 9. Maybe that's the reason.

2017-12-28 17:21 GMT+01:00 Daniel Sun :

> Hi  Cédric,
>
>   I imported Groovy project into IntelliJ IDEA via opening
> build.gradle,
> but failed to run single test via click the "Run" button.
>
>   Here are the error message:
>
> Information:javac 9.0.1 was used to compile java sources
> Information:2017/12/29 0:06 - Compilation completed with 9 errors and 32
> warnings in 1m 31s 502ms
> Error:Groovyc: While compiling groovy_main: java.lang.RuntimeException:
> java.lang.NoClassDefFoundError: Unable to load class
> org.codehaus.groovy.runtime.DateGroovyMethods due to missing dependency
> java/sql/Date
>
>   Have you ever encountered some compilation issue like this?
>
> Cheers,
> Daniel.Sun
> ---
> Information:javac 9.0.1 was used to compile java sources
> Information:2017/12/29 0:06 - Compilation completed with 9 errors and 32
> warnings in 1m 31s 502ms
> Error:Groovyc: While compiling groovy_main: java.lang.RuntimeException:
> java.lang.NoClassDefFoundError: Unable to load class
> org.codehaus.groovy.runtime.DateGroovyMethods due to missing dependency
> java/sql/Date
> at
> org.codehaus.groovy.control.CompilationUnit.convertUncaughtExceptionToComp
> ilationError(CompilationUnit.java:1123)
> at
> org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(
> CompilationUnit.java:1101)
> at
> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(
> CompilationUnit.java:631)
> at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(
> CompilationUnit.java:609)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(
> CompilationUnit.java:586)
> at
> org.jetbrains.groovy.compiler.rt.GroovyCompilerWrapper.
> compile(GroovyCompilerWrapper.java:62)
> at
> org.jetbrains.groovy.compiler.rt.DependentGroovycRunner.runGroovyc(
> DependentGroovycRunner.java:115)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.
> invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at
> org.jetbrains.groovy.compiler.rt.GroovycRunner.intMain2(
> GroovycRunner.java:136)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.
> invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at
> org.jetbrains.jps.incremental.groovy.InProcessGroovyc.
> runGroovycInThisProcess(InProcessGroovyc.java:158)
> at
> org.jetbrains.jps.incremental.groovy.InProcessGroovyc.lambda$runGroovyc$0(
> InProcessGroovyc.java:88)
> at java.base/java.util.concurrent.FutureTask.run(
> FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.
> runWorker(ThreadPoolExecutor.java:1167)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$
> Worker.run(ThreadPoolExecutor.java:641)
> at java.base/java.lang.Thread.run(Thread.java:844)
> Caused by: java.lang.NoClassDefFoundError: Unable to load class
> org.codehaus.groovy.runtime.DateGroovyMethods due to missing dependency
> java/sql/Date
> at org.codehaus.groovy.vmplugin.v5.Java5.configureClassNode(
> Java5.java:400)
> at org.codehaus.groovy.ast.ClassNode.lazyClassInit(
> ClassNode.java:283)
> at org.codehaus.groovy.ast.ClassNode.getMethods(
> ClassNode.java:408)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport$
> ExtensionMethodCache.scanClassesForDGMMethods(StaticTypeCheckingSupport.
> java:2242)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport$
> ExtensionMethodCache.getDGMMethods(StaticTypeCheckingSupport.java:2233)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport$
> ExtensionMethodCache.access$100(StaticTypeCheckingSupport.java:2164)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport$
> ExtensionMethodCache$1.provide(StaticTypeCheckingSupport.java:2192)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport$
> ExtensionMethodCache$1.provide(StaticTypeCheckingSupport.java:2170)
> at
> org.codehaus.groovy.runtime.memoize.ConcurrentCommonCache.getAndPut(
> ConcurrentCommonCache.java:138)
> at
> org.codehaus.groovy.runtime.memoize.ConcurrentCommonCache.getAndPut(
> ConcurrentCommonCache.java:113)
> at
> 

Re: A reminder about how things are compiled

[Cédric Champeau]

Yes.

2017-12-27 14:24 GMT+01:00 Jochen Theodorou <blackd...@gmx.org>:

> On 27.12.2017 13:59, Cédric Champeau wrote:
>
>> Actually I just tested with the native IntelliJ import, that is to say
>> _without_ calling "gradle idea", and it just works out of the box (but
>> there seem to be a weird delay after the execution of a test).
>>
>
> you mean the intellij gradle import? Otherwise I do not get modules
>
> bye Jochen
>

Re: A reminder about how things are compiled

[Cédric Champeau]

I think the IDE setup can be improved. I didn't take at shot at this yet.

2017-12-27 13:22 GMT+01:00 Jochen Theodorou <blackd...@gmx.org>:

> On 27.12.2017 10:04, Cédric Champeau wrote:
> [...]
>
>> The consequence, however, is that any change to a Java class in Groovy
>> core is going to produce a different compiler.
>>
>
> This is fine in the IDE, as long as I do not have to bootstrap
> immediately... which I do not have to.
>
> But I must say the IDEA setup is still annoying as hell. I freshly
> generated the modules and ended up with a project I cannot compile, because
> of the examples. I then switched to build, but ignore errors, which
> resulted in my main (FileSystemCompiler, GroovyMain) classes not being
> found, because they have not been compiled and I did not add the Groovy
> global lib. Then I added the bootstrap and while the main classes now have
> been found, they have been of course from the bootstrap, not the source. I
> will always have to have a really, really, really good look at things to
> see if I am using bootstrap or not. I mean imagine you remove a class and
> then run from the IDE to see if your test still works. And it will, because
> the damn class is still in the bootstrap jar, which of course you did not
> create a new one. I easily lost more than half a day just trying to setup
> things again. Together with the installation and fixing of intellij
> itself... that was no fun day at all and lost time for Groovy development.
>
> For Gradle, which is aware of inputs/outputs, it means that the compiler
>> has changed, and that it needs to recompile downstream consumers
>> (subprojects) and, of course, re-execute their tests. This is the _correct
>> behavior_. Gradle is right to do so, because the compiler has changed, so
>> the bytecode generated might be different, but also since Groovy provides a
>> runtime, it also needs to re-execute the tests because the runtime has
>> changed.
>>
>> What I explain is also true of the other tasks we use, like groovydoc, or
>> docgenerator.
>>
>
> that part is perfectly fine.
>
> Now, let me explain why changing the strategy to use compiler N-1 is not
>> necessarily a good idea for us: as I explained, Groovy also comes with a
>> runtime. Say that in Groovy 3, we decide to get rid of call site caching,
>> to only use invokedynamic. Then it means that the runtime of Groovy 3 will
>> no longer include call site caching. However, the Groovy classes of the
>> compiler would have been compiled with call site caching, so a _consumer_
>> of the compiler would fail, because those classes would no longer be there
>> at runtime!
>>
>> Of course one might say "then you can use the invokedynamic version" of
>> Groovy to compile Groovy 3, which leads to the last bit of complexity of
>> our build.
>>
>
> What you normally do is compiler with N-1 to get a compiler for N' and
> then use that compiler to get the real N. Very common strategy. Of course
> that means in a build where we would depend on an older release (N-1), we
> not be able to use features in the new version (N') before we have created
> N', which can actually compile the new features. And only then N could be
> compiled using the new features from N'. Using Java is kind of like saying
> we stay with N'. So there are pros and cons to this approach, it surely
> does not make things more easy from the build side. It would make the
> program code more easy and would be better in terms of "eat you own dog
> food".
>
> what me really prevents from doing something like this is that the static
> compiler has to many fallbacks to dynamic code where I do not want them.
>
> Some would have noticed that we now have a "testAll" task for each
>> project. This task executes tests with the "indy" version of the compiler.
>> Which means that in practice, we produce 2 versions of the compiler, not
>> just one. This was the main reason for the complexity of the previous
>> build, that I recently got rid of by using a different strategy and
>> leveraging the Gradle build cache. So, instead of using the same outputs
>> for both compilers, they are now separate, and we can run the tests in 2
>> flavors. The consequence is that tests are executed twice (one for `test`,
>> the other for `testWithIndy`), but the outcome is much cleaner.
>>
>> I hope this clarifies things a bit. Now for daily development, you can
>> use:
>>
>> ./gradlew :test : will only execute the call site caching version of
>> tests for the "core" project
>> ./gradlew :testWithIndy : will only execute the indy version of tests for
>> the "core" project
>> ./gradlew :testAll : will execute both flavors of tests (indy and non
>> indy) for the "core" project
>>
>> And of course you can do the same for any subproject:
>>
>> ./gradlew :groovy-xml:test
>>
>> You can also choose precisely which test to execute by adding `--tests
>> *MyTest*` to the command line.
>>
>
> testAll and testWithIndy I did not realize,thanks.
>
> bye Jcohen
>

A reminder about how things are compiled

[Cédric Champeau]

Hi fellow Groovy contributors!

Given the recent question from Jochen about how to only execute tests from
the "core" project when you "know you only modified core" triggering
re-execution of tests for all modules, let me explain why this is like this.

Groovy is partially written in Groovy. It means that we have source code
written in Java, and source code written in Groovy. The code written in
Java is mostly, but not limited to, the "minimal compiler infrastructure".
This means that if you only compile the Java sources of the Groovy
codebase, what you obtain is something that is capable of compiling Groovy
code (and a bit more).

For this reason, we have decided, a few years back, to compile Groovy
sources using this "minimal compiler", that we call the "bootstrap
compiler". Said differently, not only Groovy is partially written in
Groovy, but we also compile the Groovy sources using the compiler generated
by the _current sources_.

Some other projects choose a different strategy: they compile, say, Java,
with version N-1 of Java. Groovy compiles itself with the _same_ version.
This has several advantages, like the fact that if Groovy N-1 produces
wrong bytecode, for some reason, we can immediately fix it. Similarly, the
generated bytecode is consistent with the bytecode that users will have
when using Groovy. Eventually, it also "accidentally" increases our test
coverage as a bug in the compiler is very likely to fail our build.

The consequence, however, is that any change to a Java class in Groovy core
is going to produce a different compiler. For Gradle, which is aware of
inputs/outputs, it means that the compiler has changed, and that it needs
to recompile downstream consumers (subprojects) and, of course, re-execute
their tests. This is the _correct behavior_. Gradle is right to do so,
because the compiler has changed, so the bytecode generated might be
different, but also since Groovy provides a runtime, it also needs to
re-execute the tests because the runtime has changed.

What I explain is also true of the other tasks we use, like groovydoc, or
docgenerator. Now, let me explain why changing the strategy to use compiler
N-1 is not necessarily a good idea for us: as I explained, Groovy also
comes with a runtime. Say that in Groovy 3, we decide to get rid of call
site caching, to only use invokedynamic. Then it means that the runtime of
Groovy 3 will no longer include call site caching. However, the Groovy
classes of the compiler would have been compiled with call site caching, so
a _consumer_ of the compiler would fail, because those classes would no
longer be there at runtime!

Of course one might say "then you can use the invokedynamic version" of
Groovy to compile Groovy 3, which leads to the last bit of complexity of
our build. Some would have noticed that we now have a "testAll" task for
each project. This task executes tests with the "indy" version of the
compiler. Which means that in practice, we produce 2 versions of the
compiler, not just one. This was the main reason for the complexity of the
previous build, that I recently got rid of by using a different strategy
and leveraging the Gradle build cache. So, instead of using the same
outputs for both compilers, they are now separate, and we can run the tests
in 2 flavors. The consequence is that tests are executed twice (one for
`test`, the other for `testWithIndy`), but the outcome is much cleaner.

I hope this clarifies things a bit. Now for daily development, you can use:

./gradlew :test : will only execute the call site caching version of tests
for the "core" project
./gradlew :testWithIndy : will only execute the indy version of tests for
the "core" project
./gradlew :testAll : will execute both flavors of tests (indy and non indy)
for the "core" project

And of course you can do the same for any subproject:

./gradlew :groovy-xml:test

You can also choose precisely which test to execute by adding `--tests
*MyTest*` to the command line.

Cheers,
Cédric

Re: Why no asm6 on Groovy2.4.x?

[Cédric Champeau]

FTR it's pretty easy to find out what brings the faulty dependency by
accessing the build scan:
https://scans.gradle.com/s/lz5mbozdytxtc/dependencies?dependencies=asm-all

2017-12-26 10:45 GMT+01:00 Jochen Theodorou :

> On 26.12.2017 00:54, Daniel.Sun wrote:
>
>> Hi Jochen,
>>
>>It seems that Groovy does not rely on asm-all:
>> https://github.com/apache/groovy/blob/e9b6bddda05165195db24d
>> 42ed3715e4752e0397/build.gradle#L178-L182
>>
>
> something seems to
>
>In addition, the asm's jar files can be downloaded properly(I could
>> not find "Gradle failure report"):
>> https://travis-ci.org/apache/groovy/jobs/321192018#L586-L596
>>
>>   Could you show me the link to the error messages?
>>
>
> See http://ci.groovy-lang.org/viewLog.html?buildId=45781
> peId=Groovy_Jdk8BuildWithSnapshotDeploy24x=buildLog#_
> state=80420,80433=80433
> failure is during :groidjar
>
> bye Jochen
>

Re: Why no asm6 on Groovy2.4.x?

[Cédric Champeau]

There's no such thing as asm-all. Just like us, they had to get rid of
their "all" artifact in 6.0. So we have to use the normal version.

Le 26 déc. 2017 00:54, "Daniel.Sun"  a écrit :

> Hi Jochen,
>
>   It seems that Groovy does not rely on asm-all:
> https://github.com/apache/groovy/blob/e9b6bddda05165195db24d42ed3715
> e4752e0397/build.gradle#L178-L182
>
>   In addition, the asm's jar files can be downloaded properly(I could
> not find "Gradle failure report"):
> https://travis-ci.org/apache/groovy/jobs/321192018#L586-L596
>
>  Could you show me the link to the error messages?
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: Gradle build updates

[Cédric Champeau]

Just run :subprojectname:test

Le 23 déc. 2017 1:13 PM, "Jochen Theodorou"  a écrit :

> hi all,
>
> is there an easy way to execute only the tests of the main module and not
> of any sub-module? I am asking because for development it was for me  first
> stage to get the tests of the main module running and then the sub modules.
> Now that all tests of all modules are executed in parallel and thus main is
> executed in something similar to a single thread mode, I have to wait much
> much longer for the main tests to get to the point of failure. Because
> otherwise the build became effectively slower for me
>
> bye Jochen
>

Re: Keeping DGM helper methods?

[Cédric Champeau]

+1

2017-12-12 17:42 GMT+01:00 Jochen Theodorou :

> Hi all,
>
>
> If we all agree on using only Indy in Groovy 3, we could get rid of all
> the DGM helper methods. What do you guys think?
>
> bye Jochen
>

Re: Building Groovy

[Cédric Champeau]

>
>
> I disagree. 99% of our users don't even know what call site caching is.
> They don't know what invokedynamic means,
>
>
> You think that 99% of Java professionals do not know what a feature that
> has been around since Java 7 is ?
> And even if that was the case: Google "java invoke dynamic" =>
> https://stackoverflow.com/questions/6638735/whats-
> invokedynamic-and-how-do-i-use-it from 2011
>

Of course. It's not a user facing feature. It's an internal implementation
detail of JVM languages. Even if you play with `MethodHandles`, you will
never deal directly with invoke dynamic.

Re: [GitHub] groovy pull request #:

[Cédric Champeau]

Don't forget that there's the build cache now. Look at the build scans to
check what was avoided.

Le 19 déc. 2017 6:29 PM, "paulk-asert"  a écrit :

> Github user paulk-asert commented on the pull request:
>
> https://github.com/apache/groovy/commit/047c8f29b1f7a1a98b2b003e4d09c1
> cef05feb0e#commitcomment-26370771
>
> Let's watch it a few more times ...
>
>
> ---
>

Re: Building Groovy

[Cédric Champeau]

2017-12-19 2:21 GMT+01:00 MG :

> Hmmm, I don't know if Paul has some comeback, but to me you make a very
> convincing point...
> In that case the best way forward to me seems to be to
> 1) Ask non-@CompileStatic Groovy users who can afford the time to switch
> to the invoke dynamic variety of the Groovy jars and report back on
> performance issues (tests that run much slower, etc)
>

This has been the case for years now, and almost nobody uses the
invokedynamic version. It's not just the fault of the users: when you have
a dependency on a library that is built to use the old call site caching
version, it's just not possible to "switch it to indy".


> 2) Add a clearly visible message to the Groovy distribution download
> section, Maven/etc URL spots that Groovy 3.0 will be invoke dynamic only,
> and again ask for people to use indy now & give feedback if code seems to
> be unusally slow
>

I disagree. 99% of our users don't even know what call site caching is.
They don't know what invokedynamic means, and they don't have to. It's an
internal implementation detail. What they care, on the other hand, is
performance. So "is it slow? yes -> report a bug". No one has to care about
the implementation detail, unless you're a language designer.


> 3) Start a competition who can come up with the most unexpectedly worst
> performing piece of Groovy indy code... ;-)
> (To be quite honest, I am wondering myself how invoke dynamic can be
> slower than the older, homebrewn approach, even if that is highly optimized
> - it seems to me like it should be a bit like a software renderer going up
> against a GPU...)
>

Again, I don't think optimizing the worst case is what we need to do. We
need to optimize the most common cases. If there are edge cases worth
optimizing, we can try, but we shouldn't compromise on the other cases for
a corner one.


>
> Cheers,
> mg
>
>
>
> On 18.12.2017 15:54, Jochen Theodorou wrote:
>
>> On 18.12.2017 01:01, MG wrote:
>>
>>> Just came across this as an example where using Groovy 2.4.6
>>> invokedynamic seems to have been much slower than the older callsite
>>> caching mechanism: https://www.linkedin.com/pulse
>>> /how-make-groovy-fast-java-david-e-jones (https://dzone.com/articles/ho
>>> w-to-make-groovy-as-fast-as-java)
>>>
>>
>> It is a chicken-egg problem. We still need to optimize indy in some
>> areas. But this does not happen if no users care to give detailed reports
>> which we can base optimizations on. They on the other hand simply switch to
>> static compilation or old callsite caching then. So in the end there is no
>> optimization, because optimizations tend to inflate and complicate code.
>>
>> And for the old callsite caching there is another part... I highly doubt
>> it is still well working with JDK9. Worse, I do not see how this can be
>> made work efficiently under JDK9. The preferred way in JDK9 is
>> invokedynamic after all. And while they (JDK developers) tend to increase
>> the capabilities of invokedynamic, it is the opposite story for reflection
>> (deep reflection, callsite sensitive rights made even worse through
>> modules, ...)
>>
>> So frankly I do not see much of a future for the old callsite caching
>>
>> bye Jochen
>>
>>
>

Re: Gradle build updates

[Cédric Champeau]

No there is not. But it should be pretty easy to do so, using Gradle shadow
plugin for example.

2017-12-18 16:59 GMT+01:00 :

> "The "all" sources is still produced. But there's no all jar anymore."
>
>
>
> Is there a way to get back to being able to produce an all jar?  I
> actually leverage the embeddable jar for embedding in another OSGi bundle.
> I was humming along with adding Groovy 2.5 support through beta2 and now it
> seems I would have to retool my single jar handling to deal with a number
> of module jars instead.
>

Re: Gradle build updates

[Cédric Champeau]

Alright folks, I have completed most of what I wanted to do. The
performance of the build is now much better. I have backported everything
to the 2.5 and 2.6 branches, and also updated CI.

> So is it still possible to produce the groovy-all.jar and
groovy-all-sources.jar from the SDK zip?

The "all" sources is still produced. But there's no all jar anymore.

2017-12-13 17:53 GMT+01:00 :

> So is it still possible to produce the groovy-all.jar and
> groovy-all-sources.jar from the SDK zip?
>

Re: CC and build revision

[Cédric Champeau]

My pleasure, Russel!

2017-12-15 10:52 GMT+01:00 Russel Winder :

> Thanks to Cédric for his time spent revising the Groovy build system. It is
> now much easier and simpler to build Groovy HEAD.
>
> I guess I am now under pressure to get GPars 2 out so Groovy can have a
> JDK8+
> compliant concurrency/parallelism system. Sadly though despite a few calls
> for
> help via email, no-one other than me actually seems to care enough to put
> some
> effort in, which has led to me not being as proactive as it would good to
> be –
> motivation dissipated.
>
> Is there organisation out there that depends on GPars that can allocate
> some
> development resource for me to work with?
>
> --
> Russel.
> ==
> Dr Russel Winder  t: +44 20 7585 2200
> 41 Buckmaster Roadm: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk
>