You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Paul King <pa...@asert.com.au> on 2018/11/01 21:22:25 UTC
Groovy 2.5.4 planning
Just a little bit of advance warning. I'm still working on a few bug fixes
but I'll aim to prepare a new release next week. If you have any pending
changes, please get them in and/or let me know your plans. The release date
isn't super urgent if there are other fixes we should be waiting for but
I'd like to get the non-beta version of ASM 7 incorporated and a few other
important fixes.
Cheers, Paul.
Re: Groovy 2.5.4 planning
Posted by Guillaume Laforge <gl...@gmail.com>.
I was also thinking of a Boolean in a constructor.
Le ven. 2 nov. 2018 à 07:23, Paul King <pa...@asert.com.au> a écrit :
> While I think security is very important to consider, I am unsure whether
> the switch is the way to go. Such switches are global in nature and that
> means you can't as easily as you might like use different GProperty
> instances in different contexts with different security contexts.
>
> Given use of GProperties is totally opt-in, I am wondering if a switch is
> needed but I am open to others thoughts on this topic. If a switch is
> needed, my suggestion would be different constructors with some boolean
> flags to indicate what features are enabled for a particular instance.
>
> Cheers, Paul.
>
>
> On Fri, Nov 2, 2018 at 1:15 PM Daniel Sun <re...@hotmail.com> wrote:
>
>> Hi Andres,
>>
>> > if GProperties is added to core I’d suggest to set that flag to
>> false as default.
>> Agreed :)
>>
>> > Additionally, couldn’t this behavior be added to ConfigSlurper?
>> As you can see, `GProperties` is a subclass of `Properties`, I
>> recommend groovy users to use the enhanced `Properties` by
>> default(`GProperties` to `Properties` is similar with `GString` to
>> `String`), which can handle properties smartly and handle input
>> stream/reader properly
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>> --
>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>
>
Re: Groovy 2.5.4 planning
Posted by Paul King <pa...@asert.com.au>.
While I think security is very important to consider, I am unsure whether
the switch is the way to go. Such switches are global in nature and that
means you can't as easily as you might like use different GProperty
instances in different contexts with different security contexts.
Given use of GProperties is totally opt-in, I am wondering if a switch is
needed but I am open to others thoughts on this topic. If a switch is
needed, my suggestion would be different constructors with some boolean
flags to indicate what features are enabled for a particular instance.
Cheers, Paul.
On Fri, Nov 2, 2018 at 1:15 PM Daniel Sun <re...@hotmail.com> wrote:
> Hi Andres,
>
> > if GProperties is added to core I’d suggest to set that flag to
> false as default.
> Agreed :)
>
> > Additionally, couldn’t this behavior be added to ConfigSlurper?
> As you can see, `GProperties` is a subclass of `Properties`, I
> recommend groovy users to use the enhanced `Properties` by
> default(`GProperties` to `Properties` is similar with `GString` to
> `String`), which can handle properties smartly and handle input
> stream/reader properly
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
Re: Groovy 2.5.4 planning
Posted by Daniel Sun <re...@hotmail.com>.
Hi Andres,
> if GProperties is added to core I’d suggest to set that flag to
false as default.
Agreed :)
> Additionally, couldn’t this behavior be added to ConfigSlurper?
As you can see, `GProperties` is a subclass of `Properties`, I
recommend groovy users to use the enhanced `Properties` by
default(`GProperties` to `Properties` is similar with `GString` to
`String`), which can handle properties smartly and handle input
stream/reader properly
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Groovy 2.5.4 planning
Posted by Andres Almiray <aa...@gmail.com>.
Hi Daniel,
Then so, if GProperties is added to core I’d suggest to set that flag to false as default.
Additionally, couldn’t this behavior be added to ConfigSlurper?
Cheers
Andres
Sent from my primitive tricorder
> On Nov 1, 2018, at 10:49 PM, Daniel Sun <re...@hotmail.com> wrote:
>
> Hi Andres,
>
> We can disable running code feature by default(enabled by a switch,
> e.g. -Dgroovy.properties.evaluate.code=true).
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Groovy 2.5.4 planning
Posted by Daniel Sun <re...@hotmail.com>.
Hi Andres,
We can disable running code feature by default(enabled by a switch,
e.g. -Dgroovy.properties.evaluate.code=true).
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Groovy 2.5.4 planning
Posted by Andres Almiray <aa...@gmail.com>.
FWIW enabling arbitrary code on a properties file sounds like a risk to me.
What if this be released as a standalone library for people to try it out first? Remember once added to Groovy core it’ll be hard to remove later.
Best
Andres
Sent from my primitive tricorder
> On Nov 1, 2018, at 7:46 PM, Daniel.Sun <su...@apache.org> wrote:
>
> Hi Paul,
>
> I wish GProperties could be included in 2.5.4. Here is the relevant
> PR: https://github.com/apache/groovy/pull/818
>
> Cheers,
> Daniel.Sun
>
>
>
> -----
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Groovy 2.5.4 planning
Posted by Daniel Sun <re...@hotmail.com>.
Gotcha.
The `GProperties` will be included in 3.0.0.
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Groovy 2.5.4 planning
Posted by Guillaume Laforge <gl...@gmail.com>.
Agreed, we normally don't add new features in bug fix releases, but only in
main releases.
On Fri, Nov 2, 2018 at 10:07 AM Cédric Champeau <ce...@gmail.com>
wrote:
> -1 to including GProperties in a bugfix release. There's apparently
> discussion about the implication of doing this, and a bugfix release is not
> meant to add new features.
>
> Le ven. 2 nov. 2018 à 00:46, Daniel.Sun <su...@apache.org> a écrit :
>
>> Hi Paul,
>>
>> I wish GProperties could be included in 2.5.4. Here is the relevant
>> PR: https://github.com/apache/groovy/pull/818
>>
>> 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
>>
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Twitter: @glaforge <http://twitter.com/glaforge>
Re: Groovy 2.5.4 planning
Posted by Cédric Champeau <ce...@gmail.com>.
-1 to including GProperties in a bugfix release. There's apparently
discussion about the implication of doing this, and a bugfix release is not
meant to add new features.
Le ven. 2 nov. 2018 à 00:46, Daniel.Sun <su...@apache.org> a écrit :
> Hi Paul,
>
> I wish GProperties could be included in 2.5.4. Here is the relevant
> PR: https://github.com/apache/groovy/pull/818
>
> Cheers,
> Daniel.Sun
>
>
>
> -----
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
Re: Groovy 2.5.4 planning
Posted by "Daniel.Sun" <su...@apache.org>.
Hi Paul,
I wish GProperties could be included in 2.5.4. Here is the relevant
PR: https://github.com/apache/groovy/pull/818
Cheers,
Daniel.Sun
-----
Daniel Sun
Apache Groovy committer
Blog: http://blog.sunlan.me
Twitter: @daniel_sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Groovy 2.5.4 planning
Posted by "Milles, Eric (TR Tech, Content & Ops)" <er...@thomsonreuters.com>.
Paul,
I have been working on a patch for debugger stepping issues described in GROOVY-4063, GROOVY-7647, GROOVY-7918 and GROOVY-8742. I am currently testing this patch to StatementWriter. Could you give this a quick try with the core project's tests? Can you see any problems with this approach?
public void writeBlockStatement(BlockStatement block) {
writeStatementLabel(block);
int mark = controller.getOperandStack().getStackLength();
CompileStack compileStack = controller.getCompileStack();
compileStack.pushVariableScope(block.getVariableScope());
for (Statement statement : block.getStatements()) {
statement.visit(controller.getAcg());
}
compileStack.pop();
// GRECLIPSE add
if (block.getLastLineNumber() > 0) {
MethodVisitor mv = controller.getMethodVisitor();
Label blockEnd = new Label(); mv.visitLabel(blockEnd);
mv.visitLineNumber(block.getLastLineNumber(), blockEnd);
}
// GRECLIPSE end
controller.getOperandStack().popDownTo(mark);
}
________________________________
From: Paul King <pa...@asert.com.au>
Sent: Thursday, November 1, 2018 4:22 PM
To: dev@groovy.apache.org
Subject: Groovy 2.5.4 planning
Just a little bit of advance warning. I'm still working on a few bug fixes but I'll aim to prepare a new release next week. If you have any pending changes, please get them in and/or let me know your plans. The release date isn't super urgent if there are other fixes we should be waiting for but I'd like to get the non-beta version of ASM 7 incorporated and a few other important fixes.
Cheers, Paul.