Re: GPars and versions of Groovy

[Jim Northrop]

Thanks to you for this -

Does this mean that GPars will no longer work on JDK1.7 ? What is the minimum 
jdk that we require for GPars, please ?
Thx
Jim

> On 6 Mar 2018, at 18:04, Russel Winder  wrote:
> 
> On Tue, 2018-03-06 at 16:43 +, Kerridge, Jon wrote:
>> Hi,
> 
> Hi Jon,
> 
>> I am having the same problems with the JCSP and GroovyJCSP libraries
>> as well!
> 
> It has been a very long while since I created the JCSP-1.1-rc5 artefact
> and put it into Maven Central. I can't remember which Java I used to
> build it. I am not sure I still have the Git repository with all the
> changes I needed to create the artefact.
> 
>> Currently I have compilations for 2.4.14 and 2.5.x
> 
> For Gant (a now useless project except for GINT) I have a Gradle build
> that builds for whichever Groovy versions I choose. Currently I assume:
> 
> 2.4: 2.4.14
> 2.5: 2.5.0-beta-3
> 2.6: 2.6.0-alpha-3
> 3.0: 3.0.0-alpha-1
> 
> except it doesn't build just now as I haven't upgraded the build to
> Gradle 4.6. I'll fix this. The core idea is to set Gradle to build
> multiple projects but all using the same source just with different
> dependencies. Naming is the big issue. I have gone with:
> 
> gant_groovy2.4
> gant_groovy2.5
> gant_groovy2.6
> gant_groovy3.0
> 
>> I am then coping with the various versions of Java as well J8, 9 10
>> and 11 before the end of this year!
> 
> I am assuming a JDK8 target even though I am using JDK9. I have not
> done this as yet, but I am guessing that my one-dimensional structure
> can be extended to two dimensions by changing the path to the JDK
> version. This I think would be an excellent extension of the build
> matrix.
> 
> If we need to do for GPars what I did for Gant, it would be a good
> opportunity to revise that whole build, indeed start from scratch. The
> Gant build has the added complexity of being able to build against a
> locally installed Groovy (built from Groovy master/HEAD usually).
> 
> -- 
> 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 updates

[Jim Northrop]

Good morning Cedric
Wanted to ask if the removal of the jdk9 version of groovy-all jar will also 
mean that all us stuck on jdk1.7 will not have newer versions of groovy 
features? It would seem i would need to revise my gradles to include needed 
dependencies that groovy-all used to have but not now?
Thanx Jim

Sent from my iPad

> On 11 Dec 2017, at 01:32, Daniel.Sun  wrote:
> 
> Hi  Cédric,
> 
>  It looks fine to me.
> 
>  BTW,  the following commit will break the build(my bad...), please
> pull the latest code.
> https://github.com/melix/groovy-core/commit/fb00a0465e378bc9070f1e7dec4550fb778812ae
> 
> Cheers,
> Daniel.Sun
> 
> 
> 
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: identifying low-hanging fruit tasks for the community

[jim northrop]

+1 for Daniel & Paul's idea
sometimes my few spare hours can be devoted to improving Groovy to
everyone's benefit but we need an easier way to identify low-hanging fruit
*;-)*
thx
jim

On 3 May 2017 at 02:23, Daniel Sun  wrote:

> Hi Paul,
>
>  Apache Groovy really needs more help from community.
>  I like your idea :)
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/identifying-low-hanging-fruit-tasks-for-the-
> community-tp5740572p5740578.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.
>

Re: Welcome John Wagenleitner to the Groovy PMC

[jim northrop]

Welcome aboard John! 

Sent from my iPad

> On 2 Apr 2017, at 11:11, Daniel Sun  wrote:
> 
> Congratulations to John :)
> 
> Cheers,
> Daniel.Sun
> 
> 
> 
> --
> View this message in context: 
> http://groovy.329449.n5.nabble.com/Welcome-John-Wagenleitner-to-the-Groovy-PMC-tp5739577p5739582.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Groovy getting Fat?

[jim northrop]

we try to keep GPars docs separate from GPars codebase and/or have the docs
as separate downloadable if/when ppl want them.


On 18 March 2017 at 13:21, Cédric Champeau 
wrote:

> Actually I missed that. I don't think we should ship the docs with the
> distribution. Or, remove the docs zip altogether. It's redundant
>
> Le 18 mars 2017 10:29, "Paul King"  a écrit :
>
>> There have been requests to include the docs in the release which
>> explains the difference in size. I was going to include a note on that
>> when I send out the announce email shortly asking for feedback. If
>> folks don't like the extra size, we'll need to create a groovy-extras
>> or groovy-docs separate item to install.
>>
>> Cheers, Paul.
>>
>> On Sat, Mar 18, 2017 at 6:33 PM, Russel Winder 
>> wrote:
>> > I just noticed that the Groovy 2.4.10 distribution on SDKMAN! is 58MB
>> > where the 2.4.9 one was 36MB. I am surprised at such a difference for a
>> > debug release.
>> >
>> > --
>> > Russel.
>> > 
>> =
>> > Dr Russel Winder  t: +44 20 7585 2200   voip:
>> sip:russel.win...@ekiga.net
>> > 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
>> > London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>>
>

Re: GPars 1, 2, and 3

[jim northrop]

if you need more recent gpars documentation, i'm working on v2.0 of it that
you can see here: http://gpars.aws.ie.a9sapp.eu
 the download page does show gpars 2.0 but it's just copies of 1.2.1 that
i've renamed as placeholders.
since jsr-166Y may be dropped there are a number of gpars features that may
disappear, so we're hoping to clarify this issue before summer release.


On 16 March 2017 at 23:13, Jochen Theodorou  wrote:

> On 16.03.2017 22:54, Jochen Theodorou wrote:
>
>> On 14.03.2017 12:06, Russel Winder wrote:
>> [...]
>>
>>> It might be worth thinking about whether GPars has a real future since
>>> so few people seem to be interested in actively working on it. With
>>> Quasar (Parallel Universe thing not Quasar Framework) there is a
>>> fibers, actors, CSP framework with resources behind it. OK so no proper
>>> dataflow out of the box, but it could be added.
>>>
>>
>> you mean http://www.paralleluniverse.co/quasar/ ?
>> Fibers there work based on agents and bytecode rewriting? CSP I have not
>> seen, but I did not look to closely. License wise it might be ok, since
>> it offers EPL 1.0 dual with GPL3 (the later would not be ok for us).
>>
>> But frankly, if I am right about the fibers, then this part is no option
>> for me. That leaves the CSP part, which I did not see and actors. Is it
>> really worth it then?
>>
>
> found Dataflow, reactive streams and channels now... also that it seems to
> have a dependency on Guava... nothing against Guava itself, but there are
> too many incompatible version going around and it is a big dependency of
> over 1MB
>
> bye Jochen
>
>

Re: About a new annotation Groovydoc

[jim northrop]

So would dev.s need to add this annotation on EVERY method and property? Or 
only a single point in our groovy source?
Thx

Sent from my iPad

> On 24 Feb 2017, at 07:18, Guillaume Laforge  wrote:
> 
> Instead of a compilation flag... what about a special GroovyDoc annotation?
> 
> /** Foo Bar Baz @runtime-retention */
> def mymethod() {}
> 
> Because otherwise it's all or nothing, not very granular.
> 
> Guillaume
> 
>> On Fri, Feb 24, 2017 at 5:08 AM, Paul King  wrote:
>> I like the idea. I thought perhaps groovy.attach.annotation.groovydoc
>> was a bit of a long prop name but I haven't thought of a better one
>> yet.
>> 
>> Cheers, Paul.
>> 
>> On Fri, Feb 24, 2017 at 12:46 PM, Daniel Sun  wrote:
>> > Hi all,
>> >
>> >   I am going to add a new annotation Groovydoc(Retention: RUNTIME),
>> > which is configurable(e.g. -Dgroovy.attach.annotation.groovydoc=true) and
>> > can be attached to target element at compilation time automatically.
>> >
>> >   Groovydoc can be got easily even if Groovy source code is compiled
>> > into class files, it is a bit like Python's Documentation Strings and will
>> > be useful for IDE and developers who set a high value on documentations.
>> > BTW, currently groovydoc is attached as metadata of AST node, which is only
>> > avaliable at compilation time and is a bit hard to get(we have to use
>> > CompilationUnit, which is not familiar and friendly to most of Groovy
>> > developers)
>> >
>> > # demo for Python's Documentation Strings
>> > def my_function():
>> > """Do nothing, but document it.
>> >  No, really, it doesn't do anything.
>> > """
>> > pass
>> > print(my_function.__doc__)  # print the Documentation Strings of the
>> > function
>> >
>> >
>> >   Any thoughts?
>> >
>> > Cheers,
>> > Daniel.Sun
>> >
>> >
>> >
>> > --
>> > View this message in context: 
>> > http://groovy.329449.n5.nabble.com/About-a-new-annotation-Groovydoc-tp5738721.html
>> > Sent from the Groovy Dev mailing list archive at Nabble.com.
> 
> 
> 
> -- 
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
> 
> Blog: http://glaforge.appspot.com/
> Social: @glaforge / Google+

Re: Traits and protected properties

[Jim Northrop]

Russel is looking to build GPars V2.0 as JDK8+ later this year, so timing for 
Groovy 3 would be nice. 

Sent from my iPad

> On 25 Jan 2017, at 16:43, Cédric Champeau  wrote:
> 
> That's only ok once we generate Java 8+ class files only. Otherwise, you 
> create a language that, syntactically, supports static methods on interfaces, 
> but cannot compile them for older JDKs. Since we generate JDK 5+ class 
> formats, we cannot do this without upgrading our requirements, or adding 
> "conditional features".
> 
> 2017-01-25 16:37 GMT+01:00 Daniel Sun :
>> Hi  Cédric,
>> 
>> > oh and that's written in the docs
>> Groovy's documentation is so detail... it's hard for me to believe ;)
>> 
>> BTW, Java 8 supports static methods and default methods in the interfaces,
>> how about refining the implementation of traits based on the enhanced
>> interfaces? then traits can have its own static methods and method
>> implementation(based on the default method).
>> 
>> Cheers,
>> Daniel.Sun
>> 
>> 
>> 
>> --
>> View this message in context: 
>> http://groovy.329449.n5.nabble.com/Traits-and-protected-properties-tp5738002p5738028.html
>> Sent from the Groovy Dev mailing list archive at Nabble.com.
> 

Re: [VOTE] Release Groovy 2.4.8 - take 3

[Jim Northrop]

Do we have an ETA date when we can chg our gradle configs to pull 2.4.8 please?

Sent from my iPad

> On 10 Jan 2017, at 14:06, Paul King  wrote:
> 
> [Hopefully for real this time]
> 
> Dear community,
> 
> I am happy to start the VOTE thread for a Groovy 2.4.8 release!
> 
> This release includes 85 bug fixes/improvements as outlined in the changelog:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12335950
> 
> Tag: 
> https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_4_8
> Tag commit id: c94d839d7bf6e15377b0c355acf8087295273ff3
> 
> The artifacts to be voted on are located as follows (r17747).
> Source release: https://dist.apache.org/repos/dist/dev/groovy/2.4.8/sources
> Convenience binaries:
> https://dist.apache.org/repos/dist/dev/groovy/2.4.8/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.8.
> 
> Given that the source code used to build binary artifacts hasn't been
> touched and those artifacts have gone through quite a bit of scrutiny
> in the previous attempt, I'll keep the vote open for the next 48
> hours. It passes if a majority of at least three +1 PMC votes are
> cast.
> 
> [ ] +1 Release Apache Groovy 2.4.8
> [ ]  0 I don't have a strong opinion about this, but I assume it's ok
> [ ] -1 Do not release Apache Groovy 2.4.8 because...
> 
> Here is my vote:
> 
> +1 (binding)

Re: Old Groovy Stuff on Maven2

[Jim Northrop]

Ok, so basically, we let sleeping dogs lie. ✅☺️

Sent from my iPad

> On 9 Jan 2017, at 10:59, Cédric Champeau  wrote:
> 
> I see no good reason to remove any published artifact from a public 
> repository. This would cause more troubles than benefits (I look at you, 
> npm!).
> 
> 2017-01-09 10:58 GMT+01:00 jn0rthr :
>> Have found this old groovy download package on maven2:
>> 
>> http://repository.jboss.org/maven2/groovy/groovy-all/1.1-BETA-1/
>> 
>> and wonder if we have any responsibility to remove obsolete items like this
>> ?
>> 
>> 
>> 
>> --
>> View this message in context: 
>> http://groovy.329449.n5.nabble.com/Old-Groovy-Stuff-on-Maven2-tp5737613.html
>> Sent from the Groovy Dev mailing list archive at Nabble.com.
> 

Re: About actor syntax for Groovy 3

[jim northrop]

Deep apologies for including this here, but when we look into the realms of
parallel and concurrent processing, The Lawrence Livermore Institute has
given us a super review of this topic here:
https://computing.llnl.gov/tutorials/parallel_comp/  and gives us more
food-for-thought as we implement syntax within our  chosen language to
achieve this feat.


On 7 January 2017 at 18:58, Andres Almiray  wrote:

> You do know that Eclipse bears that name to signal the demise of Sun
> Microsystems, don't you? ;-)
>
> We also had a long standing rivalry/quarrel with JRuby in the early days.
> We're friends now. Clojure, Kotlin, Frege appear to be neutral. Scala
> lashes out at anything that's not Scala, I wouldn't like to give them more
> reasons to hate us.
>
> I'm all for learning from other languages but I'm reluctant to change the
> core syntax in order to support a niche usage (actors in this case). I
> prefer prototyping with ASTs or like Jesper suggests, figure out if an
> existing construct may fit the bill. Looks like << may be a good fit until
> you realize the method naming conventions
>
>  actor << message
>  actor.add(message)
>  actor.send(message)
>
> Yup, "add" does stand out but not in a very good way if I may say so.
>
> Cheers
> Andres
>
> Sent from my primitive Tricorder
>
> On Jan 7, 2017, at 6:46 PM, Daniel Sun  wrote:
>
> Hi Andres,
>
>   If Scala was the sun, I wish Groovy was an eclipse ;)
>
>   Maybe adding custom syntax for actor is not good idea for a
> programming language. But as a programming language, Groovy should learn
> good things from others to keep evolving and competitiveness. (like C# and
> Java)
>
> Cheers,
> Daniel.Sun
>
>
>
> 在 "Andres Almiray [via Groovy]"  >，2017年1月8日
> 上午1:28写道：
>
> This is a slippery slope IMHO.
>
> Adding custom syntax support in core for GPars might sound like a good
> idea given the fact that GPars is bundled with core. OTOH what about Spock,
> Grails, Ratpack and others? Wouldn't they benefit from custom syntax too?
> probably yes. Are they bundled with core? no, and they shouldn't.
>
> My recommendation would be to prototype an AST transformation that can
> support the syntax, just like Spock does it.
>
> One more thing, I would be very sad to see Groovy become a pale shade of
> Scala. Custom syntax and new operators are pushing Groovy in that
> direction.
>
> Cheers
> Andres
>
> Sent from my primitive Tricorder
>
> > On Jan 7, 2017, at 6:21 PM, Daniel Sun <[hidden email]> wrote:
> >
> > class ActorTest  {
> >def counter = new Counter()
> >counter.start()
> >
> >for (i in 0 .. 10) {
> >counter <- i// send message to the counter actor
> >}
> > }
> >
> > should be modified as:
> >
> > class ActorTest  {
> >public static void main(String[] args) {
> >def counter = new Counter()
> >counter.start()
> >
> >for (i in 0 .. 10) {
> >  counter <- i// send message to the counter actor
> >}
> >}
> > }
> >
> >
> >
> > --
> > View this message in context: http://groovy.329449.n5.
> nabble.com/About-actor-syntax-for-Groovy-3-tp5737574p5737575.html
> > Sent from the Groovy Dev mailing list archive at Nabble.com.
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://groovy.329449.n5.nabble.com/About-actor-syntax-for-Groovy-3-
> tp5737574p5737576.html
> To unsubscribe from About actor syntax for Groovy 3, click here.
> NAML
> 
>
>
> --
> View this message in context: Re: About actor syntax for Groovy 3
> 
> Sent from the Groovy Dev mailing list archive
>  at Nabble.com
> .
>
>

Re: About actor syntax for Groovy 3

[jim northrop]

Have found this Actor slideshow that may help us a bit ?
http://www.slideshare.net/drorbr/the-actor-model-towards-better-concurrency


On 7 January 2017 at 18:30, Jesper Steen Møller 
wrote:

> But
>
> Wouldn’t << be a natural choice which would work today?
>
> -Jesper
>
> > On 7 Jan 2017, at 18.16, Daniel Sun  wrote:
> >
> > Hi all,
> >
> >  As we all know, GPars is awesome in concurrency programming. How
> about
> > introducing a new syntax for GPars's
> > actor(http://www.gpars.org/guide/guide/actors.html) to support
> concurrency
> > programming better like Erlang and
> > Scala(https://rocketeer.be/articles/concurrency-in-erlang-scala/)? We
> can
> > use <- to indicate sending messages(Erlang and Scala uses !). The initial
> > idea is shown as follows:
> >
> > // groovy.actor.Actor extends groovyx.gpars.actor.DefaultActor
> > class Counter extends groovy.actor.Actor {
> >int counter = 0;
> >
> >void act() {
> >react { int num ->
> >  ...
> >}
> >}
> > }
> >
> > class ActorTest  {
> >def counter = new Counter()
> >counter.start()
> >
> >for (i in 0 .. 10) {
> >counter <- i// send message to the counter actor
> >}
> > }
> >
> >   Any thoughts?
> >
> > Cheers,
> > Daniel.Sun
> >
> >
> >
> > --
> > View this message in context: http://groovy.329449.n5.
> nabble.com/About-actor-syntax-for-Groovy-3-tp5737574.html
> > Sent from the Groovy Dev mailing list archive at Nabble.com.
>
>

Re: This was a surprise…

[jim northrop]

hence why UK gov.want to hire 3,500 cyber-warriors ?  ;-}

On 19 December 2016 at 07:38, Russel Winder  wrote:

> On Sun, 2016-12-18 at 23:39 +0100, Cédric Champeau wrote:
> > This looks to be related to the recent changes by Paul for the new
> > release
> > process. Probably an overlook.
>
> I suspect you meant oversight rather than overlook there.
>
> > Gradle records all Groovy builds, yes. Typically here you could have
> > shared
> > the URL only (and maybe clicked on it since it now shows my face
> > instead of
> > yours ;)) and it would tell what tasks you executed, on which
> > environment,
> > the full stack trace, ... ;)
>
> Big Brother is watching you.
>
> :-)
>
> Highly topical just now in the UK as, given the Investigatory Powers
> Act 2016, the UK is now officially a police state. :-(
>
> --
> Russel.
> 
> =
> Dr Russel Winder  t: +44 20 7585 2200   voip:
> sip:russel.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Re: replacing jarjar by gradle shadow plugin

[jim northrop]

Merci Cedric-
Was fighting this problem only yesterday, so your tip will save me beaucoup
work. -
Jim

On 28 October 2016 at 09:03, Cédric Champeau 
wrote:

> Yes, the shadow plugin is also one of the most used Gradle plugins out
> there. It's rock solid :)
>
> 2016-10-28 0:12 GMT+02:00 Guillaume Laforge :
>
>> Right, that's what it says on the tin:
>> https://github.com/johnrengelman/shadow
>>
>> On Fri, Oct 28, 2016 at 12:01 AM, Jochen Theodorou 
>> wrote:
>>
>>> On 27.10.2016 21:58, Guillaume Laforge wrote:
>>>
 Does it do package translation too?

>>>
>>> afaik yes
>>>
>>> bye Jochen
>>>
>>>
>>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer & PMC Vice-President
>> Developer Advocate @ Google Cloud Platform
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge  / Google+
>> 
>>
>
>

Re: http://www.groovy-lang.org/ down

[Jim Northrop]

Would love to see a mirror groovy doc.s site like say, groovy-lang.net so if 
one is down we have a spare. Doc.s publish would push to two targets but quite 
do-able.

Sent from my iPad

> On 22 May 2016, at 20:36, Mario Garcia  wrote:
> 
> Thanks for the explanation Guillaume.
> 
> Just a quick question. I was wondering if, the same way Groovy has a mirror 
> in Github, could it be possible to have the Groovy site published as a 
> gh-pages? That would work as a possible documentation back-up in the future. 
> Of course I don't mean to do it any time soon, but it could be a nice 
> (partial) solution if any of this happens again in the future.
> 
> Mario
> 
> 2016-05-22 20:20 GMT+02:00 Guillaume Laforge :
>> And... it's back now!
>> 
>> Sorry again for the inconvenience, but this was really beyond our control 
>> unfortunately.
>> 
>> Regarding your points, Steve:
>> 
>> 1) If a company is stupid to "abandon" a great language like Groovy, too bad 
>> for them ;-)
>> 
>> 2) Well, we can't control perception obviously, and I didn't envision a 
>> simple DNS domain name transfer would fail so bad. Normally, this kind of 
>> process should really be smooth. So it's really really unfortunate that the 
>> ASF infra couldn't handle that appropriately and timely. To their defense, 
>> it's mostly a team of non-paid volunteers, relying on services granted for 
>> free by third-parties, and in this instance, it was really not a smooth and 
>> reliable process. 
>> 
>> 3) We're at the wheel, don't worry, even if not full time like we used to.
>> Reverting the process wasn't possible, as once you've made the move to 
>> transfer a domain name, you can't take it back, so I couldn't have been able 
>> to reclaim it. And since the Apache foundation mandates that such domain 
>> names be in their control, we would have had to go through that process 
>> anyway. So reverting to try again later would have run the risk of two such 
>> downtimes, which would be even worse.
>> 
>> Guillaume
>> 
>>> On Sun, May 22, 2016 at 4:39 PM, Steve Byrne  wrote:
>>> What about backing out the change for now?  This is looking really 
>>> bad...think about how it looks from the outside:
>>> 
>>> 1) Pivotal appears to "abandon" Groovy as a language -- does not send a 
>>> positive signal about the language's future prospects
>>> 
>>> 2) _Without warning_ the groovy-lang.org site *DISAPPEARS*.   "Oh well,", 
>>> people think, "looks like Groovy is done for.  _Glad we did not make that 
>>> decision to depend on Groovy for our go-forward technology_"
>>> 
>>> 3) The problem isn't being corrected.  This looks like either a) nobody is 
>>> "a the wheel" (of the car), or b) the folks behind Groovy (whomever they 
>>> are, again I am speaking as it would appear to the outside) are just really 
>>> incompetent, and again "we're glad we did not decide to invest development 
>>> resources into using Groovy", or, "Wow, after Pivotal abandoning Groovy, 
>>> and now the whole Groovy lang site disappearing _in the middle of the 
>>> night_", we'd better move off Groovy -- too much risk"
>>> 
>>> *It's time to back out this change*.  Get groovy-lang.org back on the air 
>>> ASAP!  Let Apache figure out their issue in parallel, but don't leave this 
>>> gaping and bleeding wound untreated any longer.  It really looks bad, and I 
>>> think still at this point, Groovy as a language/runtime/technology cannot 
>>> afford to look bad, after item 1 above happened.
>>> 
>>> I really like Groovy and would hate to lose it because of this silly 
>>> indecent.  And, not having access to groovy-lang.org (and all the docs 
>>> about the GDK) is hampering my development (yeah, I could have a local 
>>> copy, that I replicate onto _each_ of my machines and keep up to date, but 
>>> why bother?).
>>> 
>>> Here's hoping you make the right decision,
>>> Steve
>>> 
 On May 22, 2016, at 5:11 AM, Guillaume Laforge  wrote:
 
 Hi Pascal,
 
 Yes, please see my messages to the users list.
 
 Here's the Apache Infra ticket tracking this:
 https://issues.apache.org/jira/browse/INFRA-11843
 
 We've launched the transfer of the domain name to the ASF, but 
 unfortunately, this is not yet resolved :-(
 
 It's becoming painful, to say the list, and I get inquiries through 
 emails, twitter and elsewhere about it... I hope the Infra team will be 
 able to resolve that soon. It's already been so long :-(
 
 Guillaume
 
> On Sun, May 22, 2016 at 2:08 PM, Pascal Schumacher 
>  wrote:
> Hello everybody,
> 
> http://www.groovy-lang.org/ seems down since Friday?
 
 
 
 -- 
 Guillaume Laforge
 Apache Groovy committer & PMC Vice-President
 Product Ninja & Advocate at Restlet
 
 Blog: http://glaforge.appspot.com/
 Social: @glaforge / Google+
>> 
>> 
>> 
>> 

Re: http://www.groovy-lang.org/ down

[Jim Northrop]

Just did 2 DNS name changes this afternoon using goDaddy and worked flawlessly 
with no changed required to my internal server. So i'm a bit puzzled why this 
should be a biggie 

Sent from my iPad

> On 22 May 2016, at 20:20, Guillaume Laforge  wrote:
> 
> And... it's back now!
> 
> Sorry again for the inconvenience, but this was really beyond our control 
> unfortunately.
> 
> Regarding your points, Steve:
> 
> 1) If a company is stupid to "abandon" a great language like Groovy, too bad 
> for them ;-)
> 
> 2) Well, we can't control perception obviously, and I didn't envision a 
> simple DNS domain name transfer would fail so bad. Normally, this kind of 
> process should really be smooth. So it's really really unfortunate that the 
> ASF infra couldn't handle that appropriately and timely. To their defense, 
> it's mostly a team of non-paid volunteers, relying on services granted for 
> free by third-parties, and in this instance, it was really not a smooth and 
> reliable process. 
> 
> 3) We're at the wheel, don't worry, even if not full time like we used to.
> Reverting the process wasn't possible, as once you've made the move to 
> transfer a domain name, you can't take it back, so I couldn't have been able 
> to reclaim it. And since the Apache foundation mandates that such domain 
> names be in their control, we would have had to go through that process 
> anyway. So reverting to try again later would have run the risk of two such 
> downtimes, which would be even worse.
> 
> Guillaume
> 
>> On Sun, May 22, 2016 at 4:39 PM, Steve Byrne  wrote:
>> What about backing out the change for now?  This is looking really 
>> bad...think about how it looks from the outside:
>> 
>> 1) Pivotal appears to "abandon" Groovy as a language -- does not send a 
>> positive signal about the language's future prospects
>> 
>> 2) _Without warning_ the groovy-lang.org site *DISAPPEARS*.   "Oh well,", 
>> people think, "looks like Groovy is done for.  _Glad we did not make that 
>> decision to depend on Groovy for our go-forward technology_"
>> 
>> 3) The problem isn't being corrected.  This looks like either a) nobody is 
>> "a the wheel" (of the car), or b) the folks behind Groovy (whomever they 
>> are, again I am speaking as it would appear to the outside) are just really 
>> incompetent, and again "we're glad we did not decide to invest development 
>> resources into using Groovy", or, "Wow, after Pivotal abandoning Groovy, and 
>> now the whole Groovy lang site disappearing _in the middle of the night_", 
>> we'd better move off Groovy -- too much risk"
>> 
>> *It's time to back out this change*.  Get groovy-lang.org back on the air 
>> ASAP!  Let Apache figure out their issue in parallel, but don't leave this 
>> gaping and bleeding wound untreated any longer.  It really looks bad, and I 
>> think still at this point, Groovy as a language/runtime/technology cannot 
>> afford to look bad, after item 1 above happened.
>> 
>> I really like Groovy and would hate to lose it because of this silly 
>> indecent.  And, not having access to groovy-lang.org (and all the docs about 
>> the GDK) is hampering my development (yeah, I could have a local copy, that 
>> I replicate onto _each_ of my machines and keep up to date, but why bother?).
>> 
>> Here's hoping you make the right decision,
>> Steve
>> 
>>> On May 22, 2016, at 5:11 AM, Guillaume Laforge  wrote:
>>> 
>>> Hi Pascal,
>>> 
>>> Yes, please see my messages to the users list.
>>> 
>>> Here's the Apache Infra ticket tracking this:
>>> https://issues.apache.org/jira/browse/INFRA-11843
>>> 
>>> We've launched the transfer of the domain name to the ASF, but 
>>> unfortunately, this is not yet resolved :-(
>>> 
>>> It's becoming painful, to say the list, and I get inquiries through emails, 
>>> twitter and elsewhere about it... I hope the Infra team will be able to 
>>> resolve that soon. It's already been so long :-(
>>> 
>>> Guillaume
>>> 
 On Sun, May 22, 2016 at 2:08 PM, Pascal Schumacher 
  wrote:
 Hello everybody,
 
 http://www.groovy-lang.org/ seems down since Friday?
 
>>> 
>>> 
>>> 
>>> -- 
>>> Guillaume Laforge
>>> Apache Groovy committer & PMC Vice-President
>>> Product Ninja & Advocate at Restlet
>>> 
>>> Blog: http://glaforge.appspot.com/
>>> Social: @glaforge / Google+
>> 
> 
> 
> 
> -- 
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Product Ninja & Advocate at Restlet
> 
> Blog: http://glaforge.appspot.com/
> Social: @glaforge / Google+

Re: [GitHub] groovy pull request: Link to MrHaki's blog in TupleConstructor jav...

[jim northrop]

was thinking of the same problem with our http://gpars.website. Do we
include code samples or not ? or only links to external sites ? i like the
idea of "live" code fragments within the doc.s  that are compiled/tested as
a part of document generation. this guarantees that code in our docs works
as stated. Users can then cut-n-paste with assurance.

On 27 February 2016 at 09:48, mrhaki  wrote:

> I think it is better to have very complete documentation at GroovyDoc
> level,
> without the need to follow external links.  My experience with the Ratpack
> Javadoc documentation is that with all example code and snippets included
> at
> Javadoc level that it is very easy to use as reference.
>
> It is no problem to use the snippets from my blog in the documentation.
>
> I like Guillaume's mention that the code could even be tested if it is
> included in the GroovyDoc, which makes at least sure the code works.
>
> In the nearby future I certainly want to contribute to adding snippets to
> the existing Groovydoc sources.
>
> Hubert Klein Ikkink 
> @mrhaki
> www.mrhaki.com
>
>
>
>
> --
> View this message in context:
> http://groovy.329449.n5.nabble.com/Re-GitHub-groovy-pull-request-Link-to-MrHaki-s-blog-in-TupleConstructor-jav-tp5731382p5731443.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.
>

Re: Preparing for a release

[jim northrop]

Hurrah ! Thank YOU John !
thx jim

On 16 February 2016 at 21:02, John Wagenleitner <john.wagenleit...@gmail.com
> wrote:

> Hi Jim,
>
> I think the file you might be looking for is:
>
> src/main/org/codehaus/groovy/runtime/StringGroovyMethods.java
>
>
> On Tue, Feb 16, 2016 at 10:36 AM, Pascal Schumacher <
> pascalschumac...@gmx.net> wrote:
>
>> Hi Jim,
>>
>> not sure what you mean by "String.metadata function"?
>>
>> If you like to contribute code to groovy open a jira ticket and send us a
>> pull request.
>>
>> Cheers,
>> Pascal
>>
>>
>> Am 16.02.2016 um 10:18 schrieb jim northrop:
>>
>> Hi Pascal
>> could you pls point me to where i can donate a tiny piece of
>> String.metadata function ?
>>
>> thx
>> ​jim
>> ​
>>
>> On 16 February 2016 at 08:12, Pascal Schumacher <pascalschumac...@gmx.net
>> > wrote:
>>
>>> I fixed https://issues.apache.org/jira/browse/GROOVY-7742 by reverting
>>> as Shils and John suggested in the discussion of
>>> https://github.com/apache/groovy/pull/253
>>>
>>> Am 15.02.2016 um 22:12 schrieb Pascal Schumacher:
>>>
>>>> Hi Cédric,
>>>>
>>>> great news. :)
>>>>
>>>> I think before https://issues.apache.org/jira/browse/GROOVY-7742
>>>> should be resolved, by either applying
>>>> <https://github.com/apache/groovy/pull/253>
>>>> https://github.com/apache/groovy/pull/253 or reverting
>>>> https://github.com/apache/groovy/commit/fae29119a1102393ae5d1645c3fc1e06547b0ad8
>>>>
>>>> If nobody more qualified offers his opinion on how to handle this I
>>>> would just revert, so we can release.
>>>>
>>>> Thanks,
>>>> Pascal
>>>>
>>>> Am 15.02.2016 um 10:45 schrieb Cédric Champeau:
>>>>
>>>>> Hi guys,
>>>>>
>>>>> As promised, I will try to find some time to perform a release this
>>>>> week. The last one is months ago already, and even if we had decided to
>>>>> migrate to a smoother process, nobody managed to made the modifications 
>>>>> yet.
>>>>>
>>>>> As such and if nobody disagrees, I will perform a release this week
>>>>> using the "old" incubating process.
>>>>>
>>>>> Please backport every fix you think is worth having on the 2.4.x
>>>>> branch asap.
>>>>>
>>>>> Thanks!
>>>>>
>>>>
>>>>
>>>
>>
>>
>

Re: Preparing for a release

[jim northrop]

Be glad to open a JIRA - once i learn how ;-}
must do some homework !
thanx
jim

On 16 February 2016 at 19:36, Pascal Schumacher <pascalschumac...@gmx.net>
wrote:

> Hi Jim,
>
> not sure what you mean by "String.metadata function"?
>
> If you like to contribute code to groovy open a jira ticket and send us a
> pull request.
>
> Cheers,
> Pascal
>
> Am 16.02.2016 um 10:18 schrieb jim northrop:
>
> Hi Pascal
> could you pls point me to where i can donate a tiny piece of
> String.metadata function ?
>
> thx
> ​jim
> ​
>
> On 16 February 2016 at 08:12, Pascal Schumacher <pascalschumac...@gmx.net>
> wrote:
>
>> I fixed https://issues.apache.org/jira/browse/GROOVY-7742 by reverting
>> as Shils and John suggested in the discussion of
>> https://github.com/apache/groovy/pull/253
>>
>> Am 15.02.2016 um 22:12 schrieb Pascal Schumacher:
>>
>>> Hi Cédric,
>>>
>>> great news. :)
>>>
>>> I think before https://issues.apache.org/jira/browse/GROOVY-7742 should
>>> be resolved, by either applying
>>> <https://github.com/apache/groovy/pull/253>
>>> https://github.com/apache/groovy/pull/253 or reverting
>>> https://github.com/apache/groovy/commit/fae29119a1102393ae5d1645c3fc1e06547b0ad8
>>>
>>> If nobody more qualified offers his opinion on how to handle this I
>>> would just revert, so we can release.
>>>
>>> Thanks,
>>> Pascal
>>>
>>> Am 15.02.2016 um 10:45 schrieb Cédric Champeau:
>>>
>>>> Hi guys,
>>>>
>>>> As promised, I will try to find some time to perform a release this
>>>> week. The last one is months ago already, and even if we had decided to
>>>> migrate to a smoother process, nobody managed to made the modifications 
>>>> yet.
>>>>
>>>> As such and if nobody disagrees, I will perform a release this week
>>>> using the "old" incubating process.
>>>>
>>>> Please backport every fix you think is worth having on the 2.4.x branch
>>>> asap.
>>>>
>>>> Thanks!
>>>>
>>>
>>>
>>
>
>

Re: Release 2.4.6 and 2.5.0-beta?

[jim northrop]

Russel was looking into 1.3.0 snapshot but we need a host so we keep
our GPars snapshot fore testing before it gets out the door. Schalk was
looking@something like this a yr ago , think it was artifactory or
bintray?  Trying to nail this down now.

On Wednesday, 6 January 2016, Guillaume Laforge  wrote:

> We'll also need to see if / how this can be done.
>
> Perhaps our mentors know how this works?
> Le 6 janv. 2016 09:56, "Jochen Theodorou"  > a écrit :
>
>> Am 05.01.2016 um 15:24 schrieb Russel Winder:
>> [...]
>>
>>> Obviously we have not released a GPars since the demise of Codehaus so
>>> we need to try creating a SNAPSHOT and/or RC release that is not a
>>> formal release for people to try and then do a formal 1.3.0 release.
>>>
>>
>> which reminds me... I think I asked this already in another thread, but
>> got no answer.. well so again..
>>
>> I remember we have been discussing adding GPars to Groovy as
>> subproject/module/something. This means the code would go to Apache and
>> Apache rules will apply
>>
>> Is this still planed on the GPars side?
>>
>> bye Jochen
>>
>

Re: Release 2.4.6 and 2.5.0-beta?

[jim northrop]

1.  Have done another doc upload. Spent time getting all the *.jar and 
*.zip files from gpars.org to include here: 
http://gparsdocs.de.a9sapp.eu/Download.html
Did not do the RCs as limited disk space on CloudFoundry target.

2. i need to see what changes you want to make here: 
http://gparsdocs.de.a9sapp.eu/Integration.html for 1.3.0

3. am working on a document to describe how to update/maintain our website 
here: http://gparsdocs.de.a9sapp.eu/WebsiteStructure/index.html 

4. added a stock privacy/copyright page here: 
http://gparsdocs.de.a9sapp.eu/Privacy.html  but we have copyright conflicts 
with Vaclav's and yours so would need to resolve those.

more soon !


On Tuesday, 5 January 2016 15:24:11 UTC+1, Russel Winder wrote:
>
> Groovy currently ships with GPars 1.2.1, I wonder if we should 
> contemplate switching to 1.3.0 (not as yet released) for the Groovy 
> 2.5.0 release. Not the 2.4.6 release obviously since a change of 
> dependency not driven by a bug fix is probably not a good thing. 
>
> Obviously we have not released a GPars since the demise of Codehaus so 
> we need to try creating a SNAPSHOT and/or RC release that is not a 
> formal release for people to try and then do a formal 1.3.0 release. 
>
> I tried to do something on this last year but stuff got in the way. I 
> fully expect to have lots of time on my hands for the next couple of 
> months… 
>
> -- 
> Russel. 
> = 
>
> Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russ...@ekiga.net 
>  
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk 
>  
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder 
>
>