draft Nov board report

2018-11-05 Thread Paul King
Guillaume, draft info for the board report due next week. I haven't added
any download numbers.

cheers, Paul.

==

## Description:

Apache Groovy is a multi-faceted programming language for the Java platform.
Groovy is a powerful, optionally typed and dynamic language, with static-
typing and static compilation capabilities, aimed at multiplying developers’
productivity thanks to a concise, familiar and easy to learn syntax. It
integrates smoothly with any Java program, and immediately delivers to your
application powerful features, including scripting capabilities, Domain-
Specific Language authoring, first class functional programming support
and runtime and compile-time meta-programming.

## Issues:

 - There are no new issues requiring board attention at this time.
 - Outstanding issues: completion of the website migration is underway
again

## Activity:

 - This quarter, 213 commits were contributed from 14 contributors
including 8 non-committer contributors (5 new).

## Health report:

 - Committee Health score: 9.60 (Super Healthy)
 - Release train velocity and discussions within mailing list seem healthy

## PMC changes:

 - Currently 11 PMC members.
 - No new PMC members added in the last 3 months
 - Last PMC addition was Andres Almiray on Thu May 31 2018

## Committer base changes:

 - Currently 19 committers.
 - No new committers added in the last 3 months
 - Last committer addition was Remko Popma at Sat Jul 07 2018

## Releases:

 - 2.5.2 was released on Tue Aug 14 2018
 - 2.5.3 was released on Sun Oct 14 2018

## Mailing list activity:

 - Activity relatively stable

## JIRA activity:

 - 136 JIRA tickets created in the last 3 months
 - 113 JIRA tickets closed/resolved in the last 3 months


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

2018-11-05 Thread Daniel.Sun
Hi Jochen,

Agreed.
To be frank, I wish I could use Guava in apache groovy project, but I
have never proposed to use it because of its big size ;)

Cheers,
Daniel.Sun




-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html


Aw: Re: Remembering imports between script invocations

2018-11-05 Thread Jochen Theodorou
let us assume we add a setConfig method to GroovyScriptEngineImpl... how would you call it?

 


ScriptEngineManager factory = new ScriptEngineManager();
ScriptEngine engine = factory.getEngineByName("groovy");
GroovyScriptEngineImpl groovyEngine = (GroovyScriptEngineImpl) engine;
groovyEngine.setConfig(myConfig);

which means you will require Groovy specific code to do this. And in that case there is always the question why you are not using the Groovy classes directly then.

 

But frankly... how about instead writing a small wrapper for GroovyShell or GroovyScriptEngine, that does implement ScriptEngine and register a factory? If you do not need support for ScriptContext, then this would be easy.

 

And then there would be also the option to do it similar to #jsr223.groovy.engine.keep.globals and make a special attribute in the engine context for GroovyScriptEngineImpl to let it set the additional imports.

 

bye Jochen


 



Gesendet: Donnerstag, 01. November 2018 um 16:19 Uhr
Von: "Keith Suderman" 
An: dev@groovy.apache.org
Betreff: Re: Remembering imports between script invocations


Hi David,
 

I am not a Groovy committer and I am not that familiar with the Groovy code base so _I_ can't revise the JSR-223 implementation.  I did take a quick look at the code, and other than having "GroovyScriptEngine" in their names the two classes (GroovyScriptEngine and GroovyScriptEngineImpl) have nothing in common and parse/load Groovy code in completely different ways.  I suspect adding a feature like you want would be a non-trivial undertaking.  Maybe one of the active committers (Paul, Daniel, et al)  can comment.

 

However, I suspect that the GroovyScriptEngineImpl class is "crippled" by JSR-223 itself as it caters to the lowest common denominator

 

- Keith
 

On Oct 31, 2018, at 12:12 PM, David Ekholm  wrote:
 


Hi Keith,
 

I'm "resurrecting" this old thread in an attept to see if we can use Groovy as the next scritpting language in jAlbum. What I'd really want to achive is to supply a number of default star imports. This is expecially important as Groovy sadly doesn't remember imports between script invocations.

 

I looked at your code suggetion below and tried to fit it to JSR-223 (javax.script API) but it fails as the GroovyScriptEngineImpl class I get from that API doesn't extend the GroovyScriptEngine class. It's only the GroovyScriptEngine class that supplies the important setConfig method.

 

Could you revise the JSR-223 implementation so it isn't unnecessary crippled compared to the GroovyShell API, at very least add the setConfig method to the GroovyScriptEngineImpl class? If we're to use the GroovyShell API, then we need to introduce our own abstraction layer in order to continue supporting multiple scripting languages in jAlbum.

 

Regards

/David, jAlbum founder

 



On 10 Feb 2018, at 21:25, Keith Suderman  wrote:
 



Import statements are really just shortcuts to tell the compiler how to resolve class names so there is nothing to "remember" between invocations, that is, nothing gets added to the Binding.

 

I am not familiar with the javax.script API, but I suspect that you will have to provide your own ScriptEngine implementation as you will need to modify the CompilerConfiguration object the GroovyShell is using to compile the Groovy code.  For example:

 

        CompilerConfiguration configuration = new CompilerConfiguration()

        GroovyShell compiler = new GroovyShell(configuration)

        println compiler.evaluate('json=\'{"foo":"bar"}\'')

        println compiler.evaluate("groovy.json.JsonOutput.prettyPrint(json)")

 

        /* Fails: MissingPropertyException */

        /* println compiler.evaluate("JsonOutput.prettyPrint(json)") */

 

        ImportCustomizer imports = new ImportCustomizer()

        imports.addStarImports("groovy.json")

        configuration.addCompilationCustomizers(imports)

// Works, the compiler can now resolve groovy.json.JsonOutput

        println compiler.evaluate("JsonOutput.prettyPrint(json)")

 

The difficult part will be "hooking" into the compiler to know when an import statement is used so you can update your CompilerConfiguration object.  I am sure the really clever programmers here could come up with some sort of AST transform that would do this.  However, depending on what you are allowed to do one option would be to tell your users that you have a "Groovy DSL" and then implement an "include" method that users would use to "import" Java packages.

 

        println eval('json=\'{"foo":"bar"}\'')

        println eval('include "groovy.json"')

        println eval('JsonOutput.prettyPrint(json)')

 

    Object eval(String code) {

        Script script = compiler.parse(code)

        ExpandoMetaClass metaClass = new ExpandoMetaClass(script.class, false)

        metaClass.include = { String name ->

            ImportCustomizer includes = new ImportCustomizer()

            

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

2018-11-05 Thread Jochen Theodorou


> Gesendet: Sonntag, 04. November 2018 um 01:43 Uhr
> Von: "Thibault Kruse" 
> An: dev@groovy.apache.org
> Betreff: Re: About the enhanced version of `Properties`, i.e. `GProperties`
[...]
> If not, that would leave importing and interpolation, but as I said
> there is already an apache commons project doing exactly that, so
> reusing it instead of reinventing wheels may be the better approach,
> if this kind of feature should be offered by Groovy.

For me there are certain situations in which not reusing might be important:
(1) library size (common-configuration2 is 590K plus dependencies)
(2) requiring only a small part of the library
(3) special integration is targeted
(4) library is not keeping up with new versions in its dependencies
(5) dependencies are known to cause often conflicts


for example Guava is a nice library, but I would not want to add 2.6MB for a 
single feature of it. 

bye Jochen