Re: REMINDER: Apache EU Roadshow 2018 in Berlin is less than 2 weeks away!

[Mauro Sanna]

please delete me from all lists.

On 31 May 2018 at 22:54,  wrote:

> Hello Apache Supporters and Enthusiasts
>
> This is a reminder that our Apache EU Roadshow in Berlin is less than two
> weeks away and we need your help to spread the word. Please let your work
> colleagues, friends and anyone interested in any attending know about our
> Apache EU Roadshow event.
>
> We have a great schedule including tracks on Apache Tomcat, Apache Http
> Server, Microservices, Internet of Things (IoT) and Cloud Technologies. You
> can find more details at the link below:
>
> https://s.apache.org/0hnG
>
> Ticket prices will be going up on 8th June 2018, so please make sure that
> you register soon if you want to beat the price increase.
> https://foss-backstage.de/tickets
>
> Remember that registering for the Apache EU Roadshow also gives you access
> to FOSS Backstage so you can attend any talks and workshops from both
> conferences. And don’t forget that our Apache Lounge will be open
> throughout the whole conference as a place to meet up, hack and relax.
>
> We look forward to seeing you in Berlin!
>
> Thanks
> Sharan Foga,  VP Apache Community Development
>
> http://apachecon.com/
> @apachecon
>
> PLEASE NOTE: You are receiving this message because you are subscribed to
> a user@ or dev@ list of one or more Apache Software Foundation projects.
>

REMINDER: Apache EU Roadshow 2018 in Berlin is less than 2 weeks away!

[sharan]

Hello Apache Supporters and Enthusiasts

This is a reminder that our Apache EU Roadshow in Berlin is less than 
two weeks away and we need your help to spread the word. Please let your 
work colleagues, friends and anyone interested in any attending know 
about our Apache EU Roadshow event.


We have a great schedule including tracks on Apache Tomcat, Apache Http 
Server, Microservices, Internet of Things (IoT) and Cloud Technologies. 
You can find more details at the link below:


https://s.apache.org/0hnG

Ticket prices will be going up on 8^th June 2018, so please make sure 
that you register soon if you want to beat the price increase. 
https://foss-backstage.de/tickets


Remember that registering for the Apache EU Roadshow also gives you 
access to FOSS Backstage so you can attend any talks and workshops from 
both conferences. And don’t forget that our Apache Lounge will be open 
throughout the whole conference as a place to meet up, hack and relax.


We look forward to seeing you in Berlin!

Thanks
Sharan Foga,  VP Apache Community Development

http://apachecon.com/
@apachecon

PLEASE NOTE: You are receiving this message because you are subscribed 
to a user@ or dev@ list of one or more Apache Software Foundation projects.

Re: New release of JCSP - (part of GPars) and groovyJCSP

[Russel Winder]

Jon,

> I have yet to create a version of the library that is compiled for
> anything other than groovy-2.4.12 and jdk8.
> The former because in other work I am doing I cannot use any version
> above groovy2.4.12 due to a bug I found.  JDK 8 because I am lazy and
> waiting for JDK 11 before doing any further recompilations in
> preparation for teaching!!

No problem. JDK10 and JDK11 (I'll try it as well) shouldn't (!) be a
problem for this code. Groovy 2.5, and 3.0 may be. Worth investigating.

> With regard your last point putting it onto Maven Central: I have
> never used that repo, putting it onto jcenter has taken a lot of
> effort because I was getting to grips with gradle and intellij as
> well.  Send me a hint or a web page that tells me how to do it
> please!!

You are already ahead of me. I have failed to publish anything to
JCenter or Maven Central since the demise of Codehaus, despite support
by Schalk Cronjé. I drifted away to D and Rust for some GTK+3/GStreamer
stuff, and haven't found the energy to try and actually publish Gant or
GPars despite the fact that both need it.

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


signature.asc
Description: This is a digitally signed message part

Re: Java NIO2 and the Groovy ClassLoader conundrum

[Schalk Cronjé]

Actually I found an issue in the example which incorrectly make it point 
to RootLoader. A better example is this


   @Grab('org.ysb33r.nio:nio-gz-provider-commons:0.1')
   @Grab('org.slf4j:slf4j-simple:1.7.5')

   import java.nio.file.*

   URI gzURI = "gz:/path/to/compressed.gz".toURI()

   FileSystem fs

   def cl = this.class.classLoader
   while( fs == null && cl != null ) {
    println "Trying ${cl}"
    try {
    fs = FileSystems.getFileSystem(gzURI)
    } catch(FileSystemNotFoundException) {
    fs = FileSystems.newFileSystem(gzURI,[:],cl)
    }
    cl = cl.parent
   }

   println "Loaded filesystem '${fs}' using ${cl}"
   Path gzPath = fs.provider().getPath(gzURI)

This produces the following output

   Trying groovy.lang.GroovyClassLoader$InnerLoader@38831718
   Loaded filesystem 'org.ysb33r.nio.provider.gz.GzFileSystem@615091b8'
   using groovy.lang.GroovyClassLoader@481a996b

which shows that GroovyClassLoader can be used to load the 
FileSystemProvider whereas the


On 31/05/2018 08:53, Schalk Cronjé wrote:


HI all,

Java NIO2 providers 
(https://docs.oracle.com/javase/8/docs/api/java/nio/file/spi/FileSystemProvider.html) 
works by providing filesystems via SPI. Ideally one would just write 
the appropriate classes and drop them on the classpath . This allows 
somebody does to write something like:


    Paths.get('gz:/path/to/compressed.gz')

This all works fine when done within a normal application but it fails 
when used within GroovyConsole or just running a normal Groovy script. 
ONe would expect the following just to work


@Grab('org.ysb33r.nio:nio-gz-provider-commons:0.1')
@Grab('org.slf4j:slf4j-simple:1.7.5')

import java.nio.file.*

Paths.get('gz:/path/to/compressed.gz')

However the following workaround is required

@Grab('org.ysb33r.nio:nio-gz-provider-commons:0.1')
@Grab('org.slf4j:slf4j-simple:1.7.5')

import java.nio.file.*

FileSystem fs

try {
    fs = FileSystems.getFileSystem(gzURI)
} catch(FileSystemNotFoundException) {
    fs =
FileSystems.newFileSystem(gzURI,[:],this.class.classLoader.parent.parent)
}

Path gzPath = fs.provider().getPath(gzURI)

NOTE: Using 
@GrabConfig(initContextClassLoader=true,systemClassLoader=true) does 
not solve the problem in this case



At Gr8Conf I sat with with Andres, Jochen and Guillaume to work 
through this. The issue that that providers are loaded via the system 
class loader, whereas with GroovyConsole and command-line Groovy it 
will be loaded via an instance of RootLoader. This leads to one having 
to manually loading the filesystem.


From the point of view of someone using NIO2 providers this is 
surprising behaviour. One would expect it just to work out of the box 
(as per the Javadoc for FileSystemProvider).


My question is now. Is there something that can be done to way 
GroovyConsole and Groovy scripts are started so that the expectd 
behaviour of NIO2 providers can be obtained? (Maybe adding an 
additional method to GrabConfig?).


Groovy luck.

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



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

RE: New release of JCSP - (part of GPars) and groovyJCSP

[Kerridge, Jon]

Russel

I have yet to create a version of the library that is compiled for anything 
other than groovy-2.4.12 and jdk8.
The former because in other work I am doing I cannot use any version above 
groovy2.4.12 due to a bug I found.  JDK 8 because I am lazy and waiting for JDK 
11 before doing any further recompilations in preparation for teaching!!

With regard your last point putting it onto Maven Central: I have never used 
that repo, putting it onto jcenter has taken a lot of effort because I was 
getting to grips with gradle and intellij as well.  Send me a hint or a web 
page that tells me how to do it please!!
Cheers
Jon

-Original Message-
From: Russel Winder 
Sent: 31 May 2018 15:16
To: Kerridge, Jon ; users@groovy.apache.org; GPars 
Developers ; d...@groovy.apache.org
Subject: Re: New release of JCSP - (part of GPars) and groovyJCSP

On Thu, 2018-05-31 at 10:44 +, Kerridge, Jon wrote:
> The JCSP library (Communicating Sequential Processes for Java) is now
> available from the jcentre repository as follows:
>
> compile 'cspforjava:jcsp:1.1.0'
>
> The associated Github location is https://github.com/CSPforJAVA/jcsp
> .

Jon,

This is great news, my hacked org.codehaus.jcsp:jcsp:1.1-rc-5 from
2010-08-07 can now be properly forgotten. I'll test out using
cspforjava:jcsp:1.1.0 on a build of GPars 2.0 with Groovy 3 and JDK 10.

I wonder if the JCenter artefact should be copied over to Maven Central?

[…]

--
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
This message and its attachment(s) are intended for the addressee(s) only and 
should not be read, copied, disclosed, forwarded or relied upon by any person 
other than the intended addressee(s) without the permission of the sender. If 
you are not the intended addressee you must not take any action based on this 
message and its attachment(s) nor must you copy or show them to anyone. Please 
respond to the sender and ensure that this message and its attachment(s) are 
deleted.

It is your responsibility to ensure that this message and its attachment(s) are 
scanned for viruses or other defects. Edinburgh Napier University does not 
accept liability for any loss or damage which may result from this message or 
its attachment(s), or for errors or omissions arising after it was sent. Email 
is not a secure medium. Emails entering Edinburgh Napier University's system 
are subject to routine monitoring and filtering by Edinburgh Napier University.

Edinburgh Napier University is a registered Scottish charity. Registration 
number SC018373

Re: New release of JCSP - (part of GPars) and groovyJCSP

[Russel Winder]

On Thu, 2018-05-31 at 10:44 +, Kerridge, Jon wrote:
> The JCSP library (Communicating Sequential Processes for Java) is now
> available from the jcentre repository as follows:
> 
> compile 'cspforjava:jcsp:1.1.0'
> 
> The associated Github location is https://github.com/CSPforJAVA/jcsp
> .

Jon,

This is great news, my hacked org.codehaus.jcsp:jcsp:1.1-rc-5 from
2010-08-07 can now be properly forgotten. I'll test out using
cspforjava:jcsp:1.1.0 on a build of GPars 2.0 with Groovy 3 and JDK 10.

I wonder if the JCenter artefact should be copied over to Maven
Central?
 
[…]

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


signature.asc
Description: This is a digitally signed message part

New release of JCSP - (part of GPars) and groovyJCSP

[Kerridge, Jon]

The JCSP library (Communicating Sequential Processes for Java) is now available 
from the jcentre repository as follows:

compile 'cspforjava:jcsp:1.1.0'

The associated Github location is https://github.com/CSPforJAVA/jcsp .

There is a set of demonstrations of the library, that use multi-core machines 
and distributed networks at: https://github.com/CSPforJAVA/jcspDemos .

The JCSP library is part of the original GPars Groovy parallelism 
infrastructure.

In addition, the groovyJCSP library provides a set of Groovy helper classes, 
that make the use of the JCSP library much easier by reducing the amount of 
code that must be written to build parallel systems.

These classes are used extensively in the books

"Using Concurrency and Parallelism Effectively parts i & ii" by Jon Kerridge 
published by Bookboon, free of charge.

http://bookboon.com/en/using-concurrency-and-parallelism-effectively-i-ebook

http://bookboon.com/en/using-concurrency-and-parallelism-effectively-ii-ebook

The library is available from 
https://github.com/JonKerridge/groovyJCSP/tree/2.4.12-1.1.0 .  This version was 
generated using groovy-2.4.12 and jcsp-1.1.0.

The software used in the books is available at 
https://github.com/JonKerridge/UCaPE

The libraries and related codes are available under the Apache 2.0 Licence.

Contacts j.kerri...@napier.ac.uk , 
p.h.we...@kent.ac.uk , 
k.chalm...@napier.ac.uk , 
me...@alumni.stanford.edu and 
n...@kentforlife.net .
Jon

Professor Jon Kerridge PhD FBCS FHEA CITP CEng
School of Computing
Edinburgh Napier University
Merchiston Campus
10 Colinton Road
Edinburgh
EH10 5DT

O1314552777
j.kerri...@napier.ac.uk


This message and its attachment(s) are intended for the addressee(s) only and 
should not be read, copied, disclosed, forwarded or relied upon by any person 
other than the intended addressee(s) without the permission of the sender. If 
you are not the intended addressee you must not take any action based on this 
message and its attachment(s) nor must you copy or show them to anyone. Please 
respond to the sender and ensure that this message and its attachment(s) are 
deleted.

It is your responsibility to ensure that this message and its attachment(s) are 
scanned for viruses or other defects. Edinburgh Napier University does not 
accept liability for any loss or damage which may result from this message or 
its attachment(s), or for errors or omissions arising after it was sent. Email 
is not a secure medium. Emails entering Edinburgh Napier University's system 
are subject to routine monitoring and filtering by Edinburgh Napier University.

Edinburgh Napier University is a registered Scottish charity. Registration 
number SC018373

Re: Java NIO2 and the Groovy ClassLoader conundrum

[Schalk Cronjé]

On 31/05/2018 09:26, Paolo Di Tommaso wrote:

The NIO api can be very annoying.

Hover I think here the problem is that Paths.get() is 
designed to only return default file (local) system path objects.


Instead Paths.get() allows the automatic creation of a new file 
system as stated by the documentation 
. 



/Throws /
/FileSystemNotFoundException - The file system, identified by the
URI, does not exist and cannot be created *automatically*, or the
provider identified by the URI's scheme component is not installed/



However is role of FileSystemProvider implementation to automatically 
create a new file system if does not exist and, I think, the 
ZipFileSystemProvider is not doing that.


You are correct. It is my typo in the code and a common mistake that is 
made. The code should read:


   Paths.get('gz:/path/to/compressed.gz'.toURI())



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

Re: Java NIO2 and the Groovy ClassLoader conundrum

[Paolo Di Tommaso]

The NIO api can be very annoying.

Hover I think here the problem is that Paths.get() is designed
to only return default file (local) system path objects.

Instead Paths.get() allows the automatic creation of a new file system
as stated by the documentation

.

*Throws *
*FileSystemNotFoundException - The file system, identified by the URI, does
not exist and cannot be created *automatically*, or the provider identified
by the URI's scheme component is not installed*



However is role of FileSystemProvider implementation to automatically
create a new file system if does not exist and, I think, the
ZipFileSystemProvider is not doing that.



p


On Thu, May 31, 2018 at 8:53 AM, Schalk Cronjé  wrote:

> HI all,
>
> Java NIO2 providers (https://docs.oracle.com/javase/8/docs/api/java/nio/
> file/spi/FileSystemProvider.html) works by providing filesystems via SPI.
> Ideally one would just write the appropriate classes and drop them on the
> classpath . This allows somebody does to write something like:
>
> Paths.get('gz:/path/to/compressed.gz')
>
> This all works fine when done within a normal application but it fails
> when used within GroovyConsole or just running a normal Groovy script. ONe
> would expect the following just to work
>
> @Grab('org.ysb33r.nio:nio-gz-provider-commons:0.1')
> @Grab('org.slf4j:slf4j-simple:1.7.5')
>
> import java.nio.file.*
>
> Paths.get('gz:/path/to/compressed.gz')
>
> However the following workaround is required
>
> @Grab('org.ysb33r.nio:nio-gz-provider-commons:0.1')
> @Grab('org.slf4j:slf4j-simple:1.7.5')
>
> import java.nio.file.*
>
> FileSystem fs
>
> try {
> fs = FileSystems.getFileSystem(gzURI)
> } catch(FileSystemNotFoundException) {
> fs = FileSystems.newFileSystem(gzURI,[:],this.class.
> classLoader.parent.parent)
> }
>
> Path gzPath = fs.provider().getPath(gzURI)
>
> NOTE: Using @GrabConfig(initContextClassLoader=true,
> systemClassLoader=true) does not solve the problem in this case
>
>
> At Gr8Conf I sat with with Andres, Jochen and Guillaume to work through
> this. The issue that that providers are loaded via the system class loader,
> whereas with GroovyConsole and command-line Groovy it will be loaded via an
> instance of RootLoader. This leads to one having to manually loading the
> filesystem.
>
> From the point of view of someone using NIO2 providers this is surprising
> behaviour. One would expect it just to work out of the box (as per the
> Javadoc for FileSystemProvider).
>
> My question is now. Is there something that can be done to way
> GroovyConsole and Groovy scripts are started so that the expectd behaviour
> of NIO2 providers can be obtained? (Maybe adding an additional method to
> GrabConfig?).
>
> Groovy luck.
>
> --
> Schalk W. Cronjé
> Twitter / Ello / Toeter : @ysb33r
>
>

Java NIO2 and the Groovy ClassLoader conundrum

[Schalk Cronjé]

HI all,

Java NIO2 providers 
(https://docs.oracle.com/javase/8/docs/api/java/nio/file/spi/FileSystemProvider.html) 
works by providing filesystems via SPI. Ideally one would just write the 
appropriate classes and drop them on the classpath . This allows 
somebody does to write something like:


    Paths.get('gz:/path/to/compressed.gz')

This all works fine when done within a normal application but it fails 
when used within GroovyConsole or just running a normal Groovy script. 
ONe would expect the following just to work


   @Grab('org.ysb33r.nio:nio-gz-provider-commons:0.1')
   @Grab('org.slf4j:slf4j-simple:1.7.5')

   import java.nio.file.*

   Paths.get('gz:/path/to/compressed.gz')

However the following workaround is required

   @Grab('org.ysb33r.nio:nio-gz-provider-commons:0.1')
   @Grab('org.slf4j:slf4j-simple:1.7.5')

   import java.nio.file.*

   FileSystem fs

   try {
    fs = FileSystems.getFileSystem(gzURI)
   } catch(FileSystemNotFoundException) {
    fs =
   FileSystems.newFileSystem(gzURI,[:],this.class.classLoader.parent.parent)
   }

   Path gzPath = fs.provider().getPath(gzURI)

NOTE: Using 
@GrabConfig(initContextClassLoader=true,systemClassLoader=true) does not 
solve the problem in this case



At Gr8Conf I sat with with Andres, Jochen and Guillaume to work through 
this. The issue that that providers are loaded via the system class 
loader, whereas with GroovyConsole and command-line Groovy it will be 
loaded via an instance of RootLoader. This leads to one having to 
manually loading the filesystem.


From the point of view of someone using NIO2 providers this is 
surprising behaviour. One would expect it just to work out of the box 
(as per the Javadoc for FileSystemProvider).


My question is now. Is there something that can be done to way 
GroovyConsole and Groovy scripts are started so that the expectd 
behaviour of NIO2 providers can be obtained? (Maybe adding an additional 
method to GrabConfig?).


Groovy luck.

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