Re: Update the Groovy color used on github.

[Mario Garcia]

+1

El mié, 16 jun 2021 a las 1:15, Paul King () escribió:

> +1
>
> On Fri, Jun 11, 2021 at 3:24 PM Michael Bailey 
> wrote:
>
>> I opened a PR to get the Groovy color on Github updated to the blue from
>> the logo.
>> See https://github.com/github/linguist/pull/5418
>>
>> If you would like to see Github use the color from the Groovy logo,
>> please reply with a +1 to this thread and give a thumbs up on this PR ->
>> https://github.com/github/linguist/pull/5418
>>
>> The plus one on this thread will help show community support.
>>
>

Re: Groovy and Java's JShell scripting in Groovylab

[Mario Garcia]

I'm sorry I haven't had the time to play with GroovyLab yet and a little
bit outdated about jshell capabilities but I'm curious, How Jshell use
could have better experience  than lets say using Groovy shell directly ?



El jue., 27 jun. 2019 15:42, sterg  escribió:

> Hi all,
>
>
> I started to introduce Java's 9+ JShell based scripting in GroovyLab
>
> (https://github.com/sterglee/GroovyLab)
>
> and I think that it can enhance significantly the utility of the tool
> for a programmer that
>
> has to do scientific programming in the Groovy/Java ecosystem.
>
>
> I look forward for opinions/suggestions/cooperation from other
> interested users.
>
>
> Best Regards
>
>
> Stergios
>
>
>
>

Re: requesting your advice on picocli modules

[Mario Garcia]

+ 1 picoli-groovy.jar

Great project BTW!

El jue., 30 may. 2019 a las 14:51, Remko Popma ()
escribió:

> Hi,
>
> I maintain the picocli library for creating command line applications in
> Groovy, Java, and other JVM languages.
> I have a question for the Groovy community (both users and developers):
>
> Currently, the picocli main jar contains both the core `picocli` package
> and a `picocli.groovy` package with classes that make it easy for Groovy
> scripts to use picocli annotations. I'm considering splitting up this jar.
>
> In an upcoming major release of the library I plan to provide a Java 9
> JPMS modular jar containing just the core `picocli` package and
> additionally a `module-info.class` to make this jar a full-fledged Java
> module.
>
> The question is what to do with the picocli.groovy package. I see two
> options:
> 1) have a `picocli-groovy` jar containing _only_ the picocli.groovy
> package - this jar would require (have a dependency on) the core picocli
> jar (the JPMS modular jar). Ideally this `picocli-groovy` jar would also be
> a JPMS module, but not sure if that's possible.
> 2) have a `picocli-legacy?` (name TBD) jar containing both the core
> picocli package and the picocli.groovy package - similar to the current
> picocli-3.9.x jar
>
> I believe the first option may be cleanest. Scripts would need to change
> their grape module from @Grab('info.picocli:picocli:$version') to
> @Grab('info.picocli:picocli-groovy:4.0.0') and that would bring in the
> transitive dependency on 'info.picocli:picocli:4.0.0', if my understanding
> is correct.
>
> Can anyone see any drawbacks with this approach?
> Would there be any point in additionally providing a `picocli-legacy`
> (name TBD) jar containing both the core picocli package and the
> picocli.groovy package, similar to the current picocli-3.9.x jar?
>
> On a side-note, has anyone had any issues with putting the
> `module-info.class` in the root of the modular jar versus putting it in
> META-INF/versions/9/ in the jar?
> Some people  use
> META-INF/versions/9/ as a way to (hopefully) avoid issues with older tools
> unable to cope with the `module-info.class`. Does anyone have any
> experience with this?
>
> Remko
>
>

Re: [ANN] Announcing CodeNarc 1.3

[Mario Garcia]

Great! Keep up with the good work! I think Codenarc is one of the most
useful projects in the Groovy ecosystem.

El mar., 29 ene. 2019 a las 19:00, Daniel.Sun ()
escribió:

> Nice work!
>
>
>
>
>
> -
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>

Re: What is the best replacement for running scripts using groovy-all?

[Mario Garcia]

BTW about @Grab, bear in mind that you can tell @Grab where to put/take its
dependencies from:

groovy -Dgrape.root=./lib my_script.groovy

So every project can have its dependencies in the project's structure.

Regards
Mario

El jue., 20 dic. 2018 a las 10:44, Paul Moore ()
escribió:

> I can understand that logic - there are quirks I've hit with the fat
> jar approach, but because I made the fat jar myself, I'm OK with just
> assuming it's a weirdness that I can either live with or investigate.
> But if it happened with a supplied jar, I'd feel that I should report
> the problem (even if I could work around it) in case it hit others,
> too. So that's an extra burden on the developers, as you say.
>
> Having an uber jar in the zip distribution would have solved my use
> case. Or even just a recipe in the documentation explaining how to
> build an uber jar for yourself. If the Gradle script I posted here
> earlier is of any help, feel free to use it.
>
> Paul
>
> On Thu, 20 Dec 2018 at 00:44, Paul King  wrote:
> >
> > We don't want to publish a fat jar to maven because it will cause
> problems that we will continually be asked about but perhaps having an uber
> jar within the zip distribution might be something we could look at. I
> suspect over time though that even that could be problematic.
> >
> > On Thu, Dec 20, 2018 at 8:46 AM MG  wrote:
> >>
> >> Hi,
> >>
> >> out of curiosity (and because having a fat jar again might be
> >> conventient at some point in the future in my work environment (also no
> >> internet access)):
> >>
> >> This solution proposed by Keith does not work
> >> https://github.com/gradle/gradle-groovy-all
> >> ?
> >>
> >> Cheers,
> >> mg
> >>
> >>
> >>
> >> Am 19.12.2018 um 23:33 schrieb Paul Moore:
> >> > On Wed, 19 Dec 2018 at 21:23, James Kleeh 
> wrote:
> >> >> Paul,
> >> >>
> >> >> The best solution is to use Maven or Gradle to create an all-in-one
> (fat) jar that you can ship and run with java -jar
> >> >>
> >> >> Gradle has a shadow plugin and Maven has a shade plugin to do just
> that.
> >> > Thanks. I'd come to the conclusion that Gradle was likely the solution
> >> > I should be looking at, and I've spent the evening trying to set up a
> >> > basic Gradle script that does what I want. After a lot of
> >> > experimentation, I came up with the following, which seems to do what
> >> > I want:
> >> >
> >> > -- start build.gradle --
> >> >
> >> > version = "0.1"
> >> >
> >> > configurations {
> >> >  deploy
> >> > }
> >> >
> >> > dependencies {
> >> >  deploy 'org.codehaus.groovy:groovy-all:2.5.4'
> >> > }
> >> >
> >> > repositories {
> >> >  jcenter()
> >> > }
> >> >
> >> > task copyDeps(type:Copy, group: "Custom", description: "Copies project
> >> > dependencies") {
> >> >  from configurations.deploy.collect { it.absolutePath }
> >> >  into "dest/lib"
> >> > }
> >> >
> >> > task copy(type: Copy, group: "Custom", description: "Copies sources to
> >> > the dest directory") {
> >> >  from "src"
> >> >  include "*.groovy"
> >> >  into "dest"
> >> > }
> >> >
> >> > task deploy(type:Zip, group: "Custom", description: "Build a
> deployment zip") {
> >> >  dependsOn copyDeps
> >> >  dependsOn copy
> >> >  from "dest"
> >> >  setArchiveName "${project.name}-${project.version}.zip"
> >> > }
> >> >
> >> > -- end build.gradle --
> >> >
> >> > It doesn't create a fat jar yet, but I can look into setting that up.
> >> > The various existing plugins seem to be dependent upon the
> >> > infrastructure set up by the java plugin, which I don't really
> >> > understand (or need, as far as I can tell) so they may not be of much
> >> > help. But I'm not sure what I need to do yet to write my own.
> >> > Something simple like
> >> >
> >> > task customFatJar(type: Jar) {
> >> >  dependsOn copyDeps
> >> >  baseName = 'all-in-one-jar'
> >> >  from "dest/lib"
> >> > }
> >> >
> >> > gives me an "all-in-one-jar.jar" that contains the dependency jars
> >> > directly included, rather than being unpacked. So there's more I need
> >> > to do here...
> >> >
> >> > Paul
> >> >
> >>
>

Re: [DISCUSS] Groovy 2.6 potential retirement to focus on Groovy 3.0

[Mario Garcia]

I would say 3 as well

2018-06-13 10:04 GMT+02:00 Robert Oschwald :

> Same with me. Option 3 seems best, even when some of our projects are
> still on Grails 2.
>
>
> Am 13.06.2018 um 09:50 schrieb Søren Berg Glasius :
>
> While the project I'm on is still on JDK 7, but due to Grails 2.x I think
> that option 3 is the best way to move forward (and nudge projects on to a
> higher version of Grails as well).
>
> /Søren
>
> On Wed, 13 Jun 2018, 09.42 ,  wrote:
>
>> I agree on option 3 (abandon 2.6 immediately).
>>
>>
>>
>> JDK 6 or 7 is not in use anywhere that I have project visibility.
>>
>>
>>
>> Full support for JKD9+ is becoming a pressing issue. Users are concerned
>> about the ability of Groovy to run on future JDK releases (including
>> GraalVM), more than legacy support.
>>
>>
>>
>> Best Regards
>>
>>
>>
>> *From:* Paolo Di Tommaso [mailto:paolo.ditomm...@gmail.com]
>> *Sent:* Wednesday, June 13, 2018 3:18 AM
>> *To:* users@groovy.apache.org
>> *Subject:* Re: [DISCUSS] Groovy 2.6 potential retirement to focus on
>> Groovy 3.0
>>
>>
>>
>> I agree on option 3 (abandon 2.6 immediately).
>>
>>
>>
>> Full support for JKD9+ is becoming a pressing issue. Users are concerned
>> about the ability of Groovy to run on future JDK releases (including
>> GraalVM), more than legacy support.
>>
>>
>>
>>
>>
>> Cheers,
>>
>> p
>>
>>
>>
>> On Wed, Jun 13, 2018 at 9:11 AM, David Dawson > simplicityitself.com> wrote:
>>
>> I would vote 2.
>>
>>
>>
>> Actually, i would vote 3) abandon 2.6 immediately.
>>
>>
>>
>> No projects I have any knowledge of still use jdk 7.
>>
>>
>>
>> *From:* pa...@asert.com.au
>>
>> *Sent:* 13 June 2018 08:06
>>
>> *To:* users@groovy.apache.org
>>
>> *Reply to:* users@groovy.apache.org
>>
>> *Subject:* [DISCUSS] Groovy 2.6 potential retirement to focus on Groovy
>> 3.0
>>
>>
>>
>>
>>
>> Hi everyone,
>>
>>
>>
>> There was some discussion at gr8conf about how to speed up delivery of
>> Groovy 3.0. Some of that discussion was around the scope of what we want to
>> include and have yet to complete in 3.0 but I won't discuss that right now.
>>
>>
>>
>> One of the other discussion points was Groovy around 2.6. As many of you
>> know, we have released alpha versions of Groovy 2.6. That version is a
>> backport of most but not all of Groovy 3.0 to JDK7 including the Parrot
>> parser (though it isn't enabled by default). The purpose of this version
>> has always been to assist people/projects wanting to use the Parrot parser
>> but who might be stuck on JDK7. So in some sense it is an intermediate
>> version to assist with porting towards Groovy 3.0. While that is still a
>> noble goal in theory, in practice, many of our users are already on JDK8
>> and we have limited resources to work on many potential areas.
>>
>>
>>
>> With that in mind, we'd like to understand the preferences in our user
>> base for the following two options:
>>
>>
>>
>> Option 1: please continue releasing the best possible 2.6 even if that
>> slows down the final release of Groovy 3.0 and delays further work on
>> better support for JDK9+.
>>
>>
>>
>> Option 2: please release one more alpha of 2.6 over the next month or so
>> which will become the best version to use to assist porting for users stuck
>> on JDK7 and then focus on 3.0. The 2.6 branch will essentially be retired
>> though we will consider PRs from the community for critical fixes.
>>
>>
>>
>> Feedback welcome.
>>
>>
>>
>> Cheers, Paul.
>>
>>
>>
>>
>>
>>
>>
> --
>
> Best regards / Med venlig hilsen,
>
> Søren Berg Glasius
>
> Hedevej 1, Gl. Rye, 8680 Ry, Denmark
> Mobile: +45 40 44 91 88, Skype: sbglasius
> --- Press ESC once to quit - twice to save the changes.
>
>
>

Re: AST to replace `==` with `equals` method invocation

[Mario Garcia]

Hi Paolo:

A couple of years ago I created Asteroid (
https://github.com/grooviter/asteroid) a library to deal with AST
transformations. I needed to create a minor release so I've taken the
oportunity to solve this problem and I think is pretty easy.

   - Create a Transformer. A transformer is just a class transforming a
   specific type of node, and it uses a criteria to filter nodes.
   - Create a Global transformation that includes the previous transformer
   to apply it to the whole codebase
   - Test that the AST generated has changed from a BinaryExpression to a
   MethodCallExpression
   - Profit :)

You can find the source code here:

   - Transformer:
   
https://github.com/grooviter/asteroid/blob/master/asteroid-test/src/main/groovy/asteroid/global/samples/ChangeEqualsTransformer.groovy

   - Transformation:
   
https://github.com/grooviter/asteroid/blob/master/asteroid-test/src/main/groovy/asteroid/global/samples/ChangeEqualsTransformation.groovy
   - Test:
   
https://github.com/grooviter/asteroid/blob/master/asteroid-test/src/test/groovy/asteroid/global/samples/ChangeEqualsTransformationSpec.groovy

You can find also some documentation at:
http://grooviter.github.io/asteroid/

Of course any feedback on the library is appreciated :)

I hope this helps
Mario

2018-06-10 21:27 GMT+02:00 MG :

> Hi Paolo,
>
> I have not used it myself, but have you had a look at the new Groovy 2.5
> "abstract syntax tree search and replace"-feature (http://groovy-lang.org/
> releasenotes/groovy-2.5.html & search for "AST matching") ?
>
> Cheers,
> mg
>
>
>
> On 10.06.2018 16:55, Paolo Di Tommaso wrote:
>
> Dear all,
>
> I'm trying to implement an AST transformation to replace any `==` binary
> expression with a equals method call invocation as suggested here
> 
> .
>
>
> My understanding is that it's required to override each the visitor for
> each node where a binary expression can appear ie. if statement, while
> statement, assignment, for loop, method call, etc.
>
> That looks a bit overkill. I was wondering if there's a better way to
> replace globally all `==` binary expressions with `equals` method
> invocations.
>
>
> Cheers,
> Paolo
>
>
>

Re: [ANNOUNCE] BeakerX: Groovy support for Jupyter Notebooks

[Mario Garcia]

Looks awesome thanks :)

El mié., 18 abr. 2018 18:50, Daniel.Sun  escribió:

> Nice
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>

Re: @Groovy Champions: Groovy Development Funding ?

[Mario Garcia]

Yes MG, that's right, it wouldn't be like a crowd funding, but a one-on-one
relationship. I guess this solution would work only if there is like a
Groovy foundation managing the tasks/money.

Mario

2018-02-22 0:00 GMT+01:00 MG <mg...@arscreat.com>:

> Hi Mario,
>
> thank you for the input. If I interpret the information on the webpage
> correctly, the system works for one-on-one funding of tasks between e.g. a
> developer and a stakeholder for specific tasks of a project. I don't know
> if this would work in the case of Groovy, because here we would probably
> have a larger number of  people giving smaller amounts to fund a
> development goal together...
>
> Cheers,
> mg
>
>
>
> On 21.02.2018 15:50, Mario Garcia wrote:
>
> I thought this could be worth sharing.
>
> The company I work for developed some time ago, Tribe (
> https://tribe.taiga.io/)
>
> Tribe is a task-based employment marketplace for product development. It
> was created with software development in mind. The tasks can be managed
> through the open sourced Taiga management platform (https://taiga.io/).
> So tasks could be managed in the context of a project.
>
> More details about Tribe (how it works, payments...) :
>
> https://tribe.taiga.io/help/how-it-works
>
> I hope this helps
> Mario
>
> 2018-02-18 17:17 GMT+01:00 MG <mg...@arscreat.com>:
>
>> Hi Eric,
>>
>> thank you for the suggestion. Do you know how much money they take for
>> their service and if they accept Paypal (I just thought about this, and not
>> accepting Paypal is imho close to a knockout, to keep the entry barrier as
>> low as possible; that would exclude Kickstarter according to their FAQ, but
>> here one could probably assume that many potential Groovy backers would
>> already have an account...).
>>
>> Do they support specific funding foals also (which typically attract more
>> funding), or is a subscription only model ?
>>
>> Cheers,
>> mg
>>
>>
>>
>> On 18.02.2018 14:15, Eric Kinsella wrote:
>>
>> I know of some indie game developers and podcasters that are using
>> Patreon. A possible alternative to something like KickStarter/Indiegogo
>> with more of a subscription model which could even be $1/month.
>>
>> https://www.patreon.com
>>
>> What is Patreon? - video
>> https://www.youtube.com/watch?time_continue=1=rwvUjAv6pxg
>>
>> Cheers,
>> Eric Kinsella
>>
>>
>> On Fri, Feb 16, 2018 at 12:37 PM, MG <mg...@arscreat.com> wrote:
>>
>>> That should be no problem, I would be happy to do a Groovy "thank you"
>>> mug o.s.  :-)
>>>
>>>
>>> On 16.02.2018 17:11, Mario Garcia wrote:
>>>
>>> +1 but also keep in mind that sometimes could be also something as
>>> simple as a "grateful box pack" with a T-shirt, sticker or a mug. I would
>>> love that too.
>>>
>>> Mario
>>>
>>> El 16 feb. 2018 11:49 a. m., "Jochen Theodorou" <blackd...@gmx.org>
>>> escribió:
>>>
>>>>
>>>>
>>>> Am 16.02.2018 um 03:27 schrieb Paul King:
>>>>
>>>>> Actually, Apache also accept donations but I think the standard policy
>>>>> is that it isn't then directed back to a specific project.
>>>>>
>>>>
>>>> I actually am of the impression that this is the only policy... might
>>>> be wrong here.
>>>>
>>>> I think in general we would be in favor of doing this so long as it was
>>>>> done well - and most of us wonder whether we have the time to
>>>>> market/advertise it well. I also suspect that having a well-defined goal
>>>>> (like what JUnit 5 did to some degree) greatly helps to attract some
>>>>> one-off investment interest.
>>>>>
>>>>
>>>> +1
>>>>
>>>> bye Jochen
>>>>
>>>
>>>
>>
>>
>
>

Re: @Groovy Champions: Groovy Development Funding ?

[Mario Garcia]

I thought this could be worth sharing.

The company I work for developed some time ago, Tribe (
https://tribe.taiga.io/)

Tribe is a task-based employment marketplace for product development. It
was created with software development in mind. The tasks can be managed
through the open sourced Taiga management platform (https://taiga.io/). So
tasks could be managed in the context of a project.

More details about Tribe (how it works, payments...) :

https://tribe.taiga.io/help/how-it-works

I hope this helps
Mario

2018-02-18 17:17 GMT+01:00 MG <mg...@arscreat.com>:

> Hi Eric,
>
> thank you for the suggestion. Do you know how much money they take for
> their service and if they accept Paypal (I just thought about this, and not
> accepting Paypal is imho close to a knockout, to keep the entry barrier as
> low as possible; that would exclude Kickstarter according to their FAQ, but
> here one could probably assume that many potential Groovy backers would
> already have an account...).
>
> Do they support specific funding foals also (which typically attract more
> funding), or is a subscription only model ?
>
> Cheers,
> mg
>
>
>
> On 18.02.2018 14:15, Eric Kinsella wrote:
>
> I know of some indie game developers and podcasters that are using
> Patreon. A possible alternative to something like KickStarter/Indiegogo
> with more of a subscription model which could even be $1/month.
>
> https://www.patreon.com
>
> What is Patreon? - video
> https://www.youtube.com/watch?time_continue=1=rwvUjAv6pxg
>
> Cheers,
> Eric Kinsella
>
>
> On Fri, Feb 16, 2018 at 12:37 PM, MG <mg...@arscreat.com> wrote:
>
>> That should be no problem, I would be happy to do a Groovy "thank you"
>> mug o.s.  :-)
>>
>>
>> On 16.02.2018 17:11, Mario Garcia wrote:
>>
>> +1 but also keep in mind that sometimes could be also something as simple
>> as a "grateful box pack" with a T-shirt, sticker or a mug. I would love
>> that too.
>>
>> Mario
>>
>> El 16 feb. 2018 11:49 a. m., "Jochen Theodorou" <blackd...@gmx.org>
>> escribió:
>>
>>>
>>>
>>> Am 16.02.2018 um 03:27 schrieb Paul King:
>>>
>>>> Actually, Apache also accept donations but I think the standard policy
>>>> is that it isn't then directed back to a specific project.
>>>>
>>>
>>> I actually am of the impression that this is the only policy... might be
>>> wrong here.
>>>
>>> I think in general we would be in favor of doing this so long as it was
>>>> done well - and most of us wonder whether we have the time to
>>>> market/advertise it well. I also suspect that having a well-defined goal
>>>> (like what JUnit 5 did to some degree) greatly helps to attract some
>>>> one-off investment interest.
>>>>
>>>
>>> +1
>>>
>>> bye Jochen
>>>
>>
>>
>
>

Re: @Groovy Champions: Groovy Development Funding ?

[Mario Garcia]

+1 but also keep in mind that sometimes could be also something as simple
as a "grateful box pack" with a T-shirt, sticker or a mug. I would love
that too.

Mario

El 16 feb. 2018 11:49 a. m., "Jochen Theodorou" 
escribió:

>
>
> Am 16.02.2018 um 03:27 schrieb Paul King:
>
>> Actually, Apache also accept donations but I think the standard policy is
>> that it isn't then directed back to a specific project.
>>
>
> I actually am of the impression that this is the only policy... might be
> wrong here.
>
> I think in general we would be in favor of doing this so long as it was
>> done well - and most of us wonder whether we have the time to
>> market/advertise it well. I also suspect that having a well-defined goal
>> (like what JUnit 5 did to some degree) greatly helps to attract some
>> one-off investment interest.
>>
>
> +1
>
> bye Jochen
>

Re: Groovy Champions proposal feedback

[Mario Garcia]

Of course +1000 to the idea :)

2018-02-14 4:39 GMT+01:00 Andres Almiray :

> Groovy Star has a nice ring to it, specially if the logo of the program
> links to the Groovy logo :-)
>
> ---
> 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, Feb 13, 2018 at 5:13 AM, Søren Berg Glasius 
> wrote:
>
>> +1 on the name!
>>
>> I think it's cool to differentiate the Groovy award from other awards
>> like Java Rock-stars and Java Champions, Grails Rock-stars, and more!
>>
>>
>> On Tue, 13 Feb 2018 at 14:09 Guillaume Laforge 
>> wrote:
>>
>>> It's funny, I think we didn't think about "stars" in our previous
>>> conversations, and I must say I quite like it, and it makes sense
>>> considering our logo :-D
>>>
>>> On Tue, Feb 13, 2018 at 1:58 PM, Jennifer Strater <
>>> jenn.stra...@gmail.com> wrote:
>>>
 +1 for the proposal and +1 for "Groovy Stars"

 On Tue, Feb 13, 2018 at 1:54 PM, Paul King  wrote:

> I don't mind "Groovy Stars" as a name!
>
> Of course it begs the question "Star trek" or "Star Wars" - the long
> journey
> of programming language design vs the language wars! :-)
>
>
> On Tue, Feb 13, 2018 at 9:46 PM, Dierk König 
> wrote:
>
>> I’m all for honoring contributions to the
>> language/ecosystem/community.
>> Given our logo, „Groovy Star“ comes to mind :-)
>>
>> Cheers
>> Dierk
>>
>> sent from:mobile
>>
>> Am 13.02.2018 um 12:29 schrieb Paolo Di Tommaso <
>> paolo.ditomm...@gmail.com>:
>>
>> It sound a nice idea also to promote the visibility of the groovy
>> community.
>>
>>
>> p
>>
>> On Tue, Feb 13, 2018 at 12:18 PM, Søren Berg Glasius <
>> soe...@glasius.dk> wrote:
>>
>>> I'm definitely +1
>>>
>>> It is always important to recognize and encourage the ones making a
>>> difference to the community.
>>>
>>> On Tue, 13 Feb 2018 at 11:32 Schalk Cronjé  wrote:
>>>

 That's a +1 from me for the concep.


 On 13/02/2018 10:58, Paul King wrote:
 >
 > Hi everyone,
 >
 > A few of us have had various discussions (in fact over many years)
 > about having a recognition scheme similar to Java Champions,
 > perhaps called "Groovy Champions" or "Apache Groovy Champions"
 > or something else entirely if we think of a better name.
 >
 > I think the idea has always been to recognize contribution within
 the
 > whole Groovy ecosystem not just the Apache Groovy project. The
 many
 > tens of projects within the ecosystem are often where many ideas
 come
 > from for the project's future evolution and also where future
 contributors
 > may arise. And in any case, Groovy has always been about making
 > coding productive and fun and we should celebrate that widely!
 >
 > There are various questions to ask like should such a scheme
 > be formally coordinated by the project/by Apache or should it be
 run as a
 > community-driven unsanctioned activity and if so what guidelines
 should
 > be in place. Also, there are many details like how will the scheme
 > operate?
 > How are new members elected? Is it a lifetime recognition or is
 there
 > an "emeritus" status? And so forth. Java Champions vote themselves
 > on new champions and the recognition has a lifetime status for
 instance.
 > if we progress this idea, we'd need to make that all clear but
 that isn't
 > the purpose of this email - we need to first decide if we like
 the idea.
 >
 > Even if we like the idea, there are still some hurdles to step
 through.
 > We've already sought some informal feedback from other parts of
 > Apache and other projects within the Groovy Ecosystem and we'll
 > likely need further discussions. We want something that embraces
 > the whole community but fits in with Apache project governance
 > around trademarks/branding.
 >
 > So, the first question is: are we as a project in favor of such a
 scheme?
 >
 > Cheers, Paul.


 --
 Schalk W. Cronjé
 Twitter / Ello / Toeter : @ysb33r

 --
>>> Best regards / Med venlig hilsen,
>>> Søren Berg 

Re: Upcoming releases

[Mario Garcia]

That's good News :)

2018-02-06 8:19 GMT+01:00 Paul King :

>
> I am planning to prepare a 2.5.0-beta-3 release towards the end of this
> week and 2.4.14 not long after. Now's a good time to let us know if there
> is something critical you need for those releases.
>
> I am expecting 2.5.0-beta-3 to be the last beta for 2.5.0 and while there
> are a couple of things we are still planning to finish for 2.5.0, I am
> expecting the next release to kick off the RC release(s), so a final
> release shouldn't be too far away!
>
> Thanks, Paul.
>
>

Re: [ANNOUNCE] MirComp 1.0.0-alpha.1 Released

[Mario Garcia]

It looks amazing. I may get back to music as well  ;)

Great work :)

2017-04-23 14:24 GMT+02:00 Guillaume Laforge :

> Congrats on the release!
> I need to get back into music :-)
>
> On Sat, Apr 22, 2017 at 5:21 PM, Mirco  wrote:
>
>> Hi Apache Groovy community,
>> I have the pleasure to announce the release of the first alpha version of
>> MirComp, the framework for algorithmic and assisted music composition.
>> The new website is online with some basic information on how to download,
>> install and launch the application:
>>
>> https://mcolletta.github.io/mircomp
>>
>> Some notes (not in particular order):
>>
>> The application is still not completely stable and has some issues but it
>> is usable and I was eager to release the prototype :-)
>> Even developers without an interest in music can use MirIDE, the main
>> application of MirComp, as a multitab alternative to the groovy console by
>> simply creating new scripts from the main menu (or from a project) and
>> using the "Run" action to execute groovy code (however in case you want
>> full control as in the groovyConsole you have to switch off the sandbox and
>> compilestatic options by uncheck the voices in the menu). Moreover, since
>> my neural network library MiRNN is included in the distribution it is
>> possible to make general AI test (even unrelated to music).
>> I wish that thanks to MirComp the Groovy language could play an important
>> role in the algorithmic music field. Indeed, since when I started designing
>> the framework I have always seen mirchord/groovy as a loose analogy of
>> html/javascript: MirChord is a declarative notation language while groovy
>> should be used for music logic.
>> Moreover, my hope is that MirComp could let musicians to gently approach
>> the amazing world of computer programming in a fascinating and artistic
>> context.
>>
>> MirComp has beeen tested under Ubuntu 16.04 and Windows 10 but should
>> work under OSX as well so a feedbak from Mac users would be very
>> appreciated. For example I noted during the development several different
>> behaviors in Windows and Linux (just as an example the cut/paste of text
>> with ctrl+c/v in the code editor needed some more hacking on Linux).
>> You know, as an old joke said: "Write once, debug everywhere!"
>> Actually, any kind of feedback is welcome.
>> MirComp  requires a recent version Java 8 (preferably >= 1.8.0_74) and
>> uses the indy version of Groovy (2.4.10) even if most of the code is
>> statically compiled.
>>
>> Enjoy groovy music (and AI)... in Groovy!
>>
>> Mirco
>>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge  / Google+
> 
>

Re: compile vs compileOnly in Gradle projects for Groovy LIbraries

[Mario Garcia]

I agree with Thibault, *compileOnly* and *provided* have specific
objectives.

Besides you can always tell Gradle to force a specific version of a given
module
https://docs.gradle.org/current/userguide/dependency_management.html#sec:finetuning_the_dependency_resolution_process

2017-04-22 2:48 GMT+02:00 Thibault Kruse :

> You do not really offer 'more control' that way, as build systems
> today already offer full control over transitive dependencies.
> Instead, what you do is to force users to handle transitive
> dependencies to groovy in an explicit way (unless they happen to have
> a groovy version from somewhere else), possibly helping users in
> failing fast when no explicit dependency resolution exists. That may
> be good or bad.
>
> IMO you are abusing compileOnly/provided scopes. compileOnly is meant
> for things like marker annotations that will not go into the generated
> bytecode. provided is meant for Containers such as in Java EE.
> And abusing concepts is never a good thing.
>
> What can happen to users I guess is that they end up with a classpath like:
> groovy-sql:2.1.6;groovy-all:2.4.6;groovy-nio:2.1.6
>
> So probably it would be better for libraries to declare compile
> dependencies, but not on groovy-all.
>
> And groovy should define at least documentation for how to handle such
> conflicts in the best way.
>
> I also believe gradle has new features for dependency resolution
> coming up, where groovy might also offer resolution rules to import
> into gradle.
>
>
> Also, BTW, I noticed the individual groovy POMs on maven central all
> have the same description: 'Groovy: A powerful, dynamic language for
> the JVM'. https://mvnrepository.com/artifact/org.codehaus.groovy
>
> Might be nicer to have individual descriptions, as a little finishing
> touch.
>
>
> On Mon, Apr 17, 2017 at 6:38 AM, Schalk Cronjé  wrote:
> > I am wondering what people's approach is to build Groovy libraries with
> > Gradle. Most people will probably use something like
> >
> > dependencies {
> > compile 'org.codehaus.groovy:groovy-all:2.4.7'
> > }
> >
> > which will set the appropriate Groovy version as a dependency. This can
> > obvisously lead to some interestign Groovy version resslution when
> combining
> > multiple libraires with different Groovy versions as dependencies.
> >
> > For a number of projects I have worked on, I have adopted the 'provided'
> > scope via the Nebula plugin, or since 'compileOnly' has become available
> in
> > Gradle defaulted to that i.e.
> >
> > dependencies {
> > compileOnly 'org.codehaus.groovy:groovy-all:2.4.7'
> > }
> >
> > This obviously means that the consumer of one of my Groovy libraries has
> to
> > explicitly state which version of Groovy they require, but IMO it is
> better
> > that way as it gives them more control.
> >
> > Thoughts?
> >
> > --
> > Schalk W. Cronjé
> > Twitter / Ello / Toeter : @ysb33r
>

Re: Custom implicit type conversion on assignment

[Mario Garcia]

Yes, the only "native" mechanism I know to do coertion in Groovy (without
applying metaprogramming) is to overwrite the asType method and apply it
explicitly.

For me creating an AST transform it's a very cool idea. Maybe, we could
come up with a library having a configuration file with predefined
coertions, like:

groovyx:
   coertions:
 Money:
   - BigDecimal: groovyx.coertions.money.BigDecimalToMoney //
BigDecimal -> Money using this implementation
   - String: groovyx.coertions.money.StringToMoney
   - Person: groovyx.coertions.money.StringToMoney

Cheers

On 31 Mar 2017 17:43, "Marcin Zajączkowski"  wrote:

> Dnia Piątek, 31 Marca 2017 16:02 Marcin Zajączkowski 
> napisał(a)
> > Hi,
> >
> > To simplify initialization of my production Money object in tests I've
> written an extension module to use explicit coercion:
> >
> > > Money tenDolars = 10.0 as Money //works fine, but could be shorter
> >
> > It works fine, but it's Groovy so I would like to achieve more :).
> >
> > My idea is to be able to write:
> >
> > > Money tenDolars = 10.0  //desired construction
> >
> > I was thinking about AST transformation (global or annotation based) to
> modify assignments like those (with Money on the left side and BigDecimal
> on the right) in a given class (or globally in a test context) to add
> explicit coercion automatically.
> >
> > Unfortunately, usually AST transformations I've found deal with adding
> methods or statements in a method.
> >
> >
> > Could you point a Groovy build-in transformation or a place in Groovy
> code which deals with implicit coercion?
>
> Thanks to Groovy AST browser and debugger I was able to reach my goal for
> simple cases and in my AST transformation detect situations where right
> expression is ConstanstExpression with String type and replace it with
> CastExpression. Nevertheless, it seems to be very low level approach.
>
> Maybe it is possible to reuse some mechanisms available in Groovy to just
> extend existing coercion with new types?
>
> Marcin
>
> --
> http://blog.solidsoft.info/ - Working code is not enough
>
>
>
>

Trying to understand why groovydoc task needs groovy-all in Gradle 2.13 / 2.14

[Mario Garcia]

I'm trying to execute a project using gradle 2.13 / 2.14 and it fails when
executing groovydoc saying:

groovydoc doesn't support the "noTimestamp" attribute

Checking gradle documentation it's saying you should be using groovy-all,
but sometimes I may not want to use the whole groovy-all jar.

Does anyone know why is this ? Is this a Gradle bug, it's something that
changed in groovydoc ?

Mario

Re: groovy-lang.org down for now

[Mario Garcia]

It seems to be responding now, yeah!! :)

2016-05-22 19:12 GMT+02:00 Andrew Bayer :

> We're waiting on the ASF's upstream DNS providers to get everything
> updated.
>
>
> On Sunday, May 22, 2016, Suderman Keith  wrote:
>
>>
>> On May 22, 2016, at 5:58 PM, Jochen Theodorou  wrote:
>>
>> The question is what we can do here. The domain is in the hands of the
>> ASF. I don´t even know how to directly reach someone of the infrastructure
>> team.
>>
>>
>> Maybe someone could reach out to one of the Groovy mentors?  Groovy isn’t
>> in an incubator project any more, but they were always eager to help and
>> seemed to have all the right contacts to get things done.
>>
>> Keith
>>
>> --
>> Research Associate
>> Department of Computer Science
>> Vassar College
>> Poughkeepsie, NY
>>
>>

Re: groovy-lang.org down for now

[Mario Garcia]

148.251.23.208 www.groovy-lang.org is working for me, thanks Jochen.

I would post the temporary mapping in users list in case anybody else needs
to access documentation/etc specially if the problem persists tomorrow (I
really hope not!!)
Mario

2016-05-22 18:41 GMT+02:00 Jochen Theodorou :

> On 22.05.2016 18:10, Steve Byrne wrote:
> [...]
>
>> You can add
>>>
>>> 148.251.23.208 groovy-lang.org
>>>
>>> to your hosts file to get the DNS entry right. It is important to
>>> mention its temporary nature though. This bypasses the DNS system, and the
>>> IP will change in the future.
>>>
>>
> maybe notwrorthy... groovy-lang.org and www.groovy-lang.org are different
> domain entries (www) is the subdomain. With only this entry
> www.groovy-lang.org won´t be resolved, only the version without www. So
> maybe add
>
> 148.251.23.208 www.groovy-lang.org
>
> as well... and for every subdomain you need (there is ci and beta, but
> most people do not need those)
>
> bye Jochen
>

Re: groovy-lang.org down for now

[Mario Garcia]

Any update on this ? It's been two days now :(

Mario

2016-05-20 22:21 GMT+02:00 Guillaume Laforge :

> Hi all,
>
> FYI, the Groovy website is currently down.
>
> We're migrating the domain-name to the Apache foundation, but it looks
> like there are some issues with the transfer.
> The Apache infrastructure team is investigating this, and hopefully it'll
> be back soon.
> But till the DNS changes propagate and so on, it might take a little while
> till it's back.
> Fingers crossed.
>
> In the meantime, sorry for the inconvenience :-(
> Thanks for your understanding.
>
> Guillaume
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Product Ninja & Advocate at Restlet 
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge  / Google+
> 
>

Re: Spring Groovy application context and creating @Immutable class beans

[Mario Garcia]

Although I think It should be better to discuss this in the Grails mailing
list (they sure have much more experience in Spring+Groovy) I have done a
little test in a Grails app with an immutable (@Immutable) bean:

package a.b.c

@Immutable
class Pagination {
   Integer max
}

myBean(a.b.c.Pagination, [max:1001])

and it seems to be working.
Mario

2016-04-11 22:47 GMT+02:00 Rick Venutolo :

> Hi all,
>
> As a fun learning experience I am attempting to move an application's
> Spring configuration from XML to Groovy. I need to create a bean for a
> Groovy class that is annotated with @Immutable.
>
> Let's say my class is this:
>
> @Immutable
> class MyImmutableClass {
> String someString
> String otherString
> String anotherString
> }
>
>
> And I attempt to create a bean like so:
>
> beans {
> myImmutableClass(
> MyImmutableClass,
> someString: 'some',
> otherString: 'other',
> anotherString: 'another'
> )
> }
>
> It fails:
> Invalid property 'someString' of bean class [MyImmutableClass]: Bean
> property 'someString' is not writable or has an invalid setter method. Does
> the parameter type of the setter match the return type of the getter?
>
> I can do the following, but I then lose the parameter name information
> that tells me which fields are set to which values:
>
> beans {
> myImmutableClass(
> MyImmutableClass,
> 'some',
> 'other',
> 'another'
> )
> }
>
>
> I can also remove the @Immutable annotation from the class. But let's
> assume this class comes from somewhere else and I cannot modify it.
>
> So what are my options here that combine not modifying the @Immutable
> class and keeping the parameter names? I know I can combine Groovy and XML
> configuration and define the bean in XML and then use importBeans in my
> Groovy code, but is there something I can do that is purely Groovy?
>
> I found this issue, which describes my problem:
> https://issues.apache.org/jira/browse/GROOVY-7078
>
> Thanks,
> Rick
>
>
>