Nabble - groovy - dev

Automated testing of Groovy assertions in javadoc comments

2009-11-29T17:10:58Z

Hi all,

I've just submitted a patch for a TestSuite that can be used to
automate the testing of Groovy assertions in javadoc comments. It's
borrows conventions from the AllTestSuite and generates TestCases
based on code fragments nested inside a <pre class="groovyTestCase>
tag. I had intended to use it as a way to insure that code that I
added to document default Groovy methods was valid. However, it could
be a more general tool. What do you think? See
http://jira.codehaus.org/browse/GROOVY-3913

Cheers,
Merlyn

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Note about version numbers

2009-11-29T13:32:27Z

On Sun, 2009-11-29 at 20:13 +0100, Jochen Theodorou wrote:

> Russel Winder schrieb:
> > Until yesterday development version were numbered x.y-beta-z-SNAPSHOT it
> > seems though that trunk is now 1.8.0-beta-1-SNAPSHOT.
> >
> > Is this intentional?
> >
> > (It affects the version number parsing in the Gant tests.)
>
> no, that was me not remembering how to do that correctly... Well... on
> fact I would prefer that scheme, but if it is causing problems, I can
> change it

The actual format of the number isn't an issue for me, as long as I know
what the numbering scheme is so that I can have the ability to have
Groovy version decision making in the Gant tests: most of the Gant
tests are actually integration tests and not unit tests, and so the
changes in Groovy output has to be taken into account.

I have to admit though that whilst I use x.y.0-snapshot instead of
x.y-SNAPSHOT I can see the rationale for the latter.

--
Russel.
=============================================================================
Dr Russel Winder Partner
xmpp: russel@...
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip:russel.winder@...
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder

signature.asc (204 bytes) Download Attachment

Re: HTML decoding without reinventing the wheel

2009-11-29T13:06:52Z

Thanks for that. The QDox would help me find the comments but not
address the HTML decoding part of it.

On Sun, Nov 29, 2009 at 10:52 AM, Guillaume Laforge
<glaforge@...> wrote:

> The Groovy GDK documentation is using QDox for parsing the
> DefaultGroovyMethods class, perhaps you can do something similar, parse the
> JavaDoc, extract the pre tag. You'll probably need some regex kungfu.
>
> On Sun, Nov 29, 2009 at 19:16, Merlyn Albery-Speyer
> <curious.attempt.bunny@...> wrote:
>>
>> Hi all,
>>
>> Pardon the off topic question here. I'm looking for an easy yet robust
>> way to pass this test:
>>
>> void testDecodesHtml() {
>> Class test = builder.buildTest("SomeClass.java", '''
>> /** <pre class="groovyTestCase"> assert 3 < 5
>> </pre> */
>> public class SomeClass { }
>> ''')
>> test.newInstance().testAssertionFromLineNumber2();
>> }
>>
>> For this I need something available to the groovy runtime that can
>> decode <, , etc. Is there something already in the groovy
>> runtime that can do this for me?
>>
>> Cheers,
>> Merlyn
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>
>
>
> --
> Guillaume Laforge
> Groovy Project Manager
> Head of Groovy Development at SpringSource
> http://www.springsource.com/g2one
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Bamboo build for 1.7.0 branch

2009-11-29T13:06:43Z

Paul King wrote:
> We may need more builds created to cover all the scenarios
> we are going to have in play.

Looks like Guillaume created the extra builds we need for now!

He is fast! ;-)

Paul.

> Guillaume Laforge wrote:
>> Okay, I think I properly made the full doco build a child of the 1.7.x
>> JDK 6 build.
>> We'll see if it works for the next time.
>>
>> On Sun, Nov 29, 2009 at 17:26, Roshan Dawrani
>> <roshandawrani@... <mailto:roshandawrani@...>> wrote:
>>
>> Thanks. The 1.7.0 builds have kicked-in.
>>
>> While we are at it - 1.7.x build with documentation, etc also did
>> not kick-in as a dependency of 1.7.x JDK 1.6 build.
>>
>> The normal JDK 1.5/1.6 builds started fine.
>>
>>
>>
>> On Sun, Nov 29, 2009 at 9:48 PM, Guillaume Laforge
>> <glaforge@... <mailto:glaforge@...>> wrote:
>>
>>
>> On Sun, Nov 29, 2009 at 17:14, Guillaume Laforge
>> <glaforge@... <mailto:glaforge@...>> wrote:
>>
>>
>> On Sun, Nov 29, 2009 at 17:01, Roshan Dawrani
>> <roshandawrani@...
>> <mailto:roshandawrani@...>> wrote:
>>
>> Hi,
>> Is the Bamboo build not setup yet for 1.7.0? The 1.7.0
>> build entries that show up on
>> http://bamboo.ci.codehaus.org/browse/GROOVY are
>> greyed-out.
>>
>> I checked-in the fix for GROOVY-3911 but the build is
>> not kicking-in?
>>
>> I think Jochen created the two Bamboo plans for 1.7.0.
>> They look inded greyed-out, not sure exactly why, perhaps
>> they're just not triggered automatically.
>> When you're logged-in, can you launch them manually
>> yourself? (wondering if all the rights are properly setup
>> for all committers).
>>
>>
>> The SVN branch was not pointing at the right place, dunno if
>> that's what causing the issue.
>> I'm gonna try launch the builds manually for now at least.
>> -- Guillaume Laforge
>> Groovy Project Manager
>> Head of Groovy Development at SpringSource
>> http://www.springsource.com/g2one
>>
>>
>>
>>
>>
>> --
>> Guillaume Laforge
>> Groovy Project Manager
>> Head of Groovy Development at SpringSource
>> http://www.springsource.com/g2one
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Bamboo build for 1.7.0 branch

2009-11-29T12:45:18Z

The greyed out builds were left over ones from when we released
1.6 final. I renamed them and disabled them in prep for now but
didn't point them to the new branches yet.

We may need more builds created to cover all the scenarios
we are going to have in play.

Paul.

Guillaume Laforge wrote:

> Okay, I think I properly made the full doco build a child of the 1.7.x
> JDK 6 build.
> We'll see if it works for the next time.
>
> On Sun, Nov 29, 2009 at 17:26, Roshan Dawrani
> <roshandawrani@... <mailto:roshandawrani@...>> wrote:
>
> Thanks. The 1.7.0 builds have kicked-in.
>
> While we are at it - 1.7.x build with documentation, etc also did
> not kick-in as a dependency of 1.7.x JDK 1.6 build.
>
> The normal JDK 1.5/1.6 builds started fine.
>
>
>
> On Sun, Nov 29, 2009 at 9:48 PM, Guillaume Laforge
> <glaforge@... <mailto:glaforge@...>> wrote:
>
>
> On Sun, Nov 29, 2009 at 17:14, Guillaume Laforge
> <glaforge@... <mailto:glaforge@...>> wrote:
>
>
> On Sun, Nov 29, 2009 at 17:01, Roshan Dawrani
> <roshandawrani@...
> <mailto:roshandawrani@...>> wrote:
>
> Hi,
> Is the Bamboo build not setup yet for 1.7.0? The 1.7.0
> build entries that show up on
> http://bamboo.ci.codehaus.org/browse/GROOVY are greyed-out.
>
> I checked-in the fix for GROOVY-3911 but the build is
> not kicking-in?
>
> I think Jochen created the two Bamboo plans for 1.7.0.
> They look inded greyed-out, not sure exactly why, perhaps
> they're just not triggered automatically.
> When you're logged-in, can you launch them manually
> yourself? (wondering if all the rights are properly setup
> for all committers).
>
>
> The SVN branch was not pointing at the right place, dunno if
> that's what causing the issue.
> I'm gonna try launch the builds manually for now at least.
>
> --
> Guillaume Laforge
> Groovy Project Manager
> Head of Groovy Development at SpringSource
> http://www.springsource.com/g2one
>
>
>
>
>
> --
> Guillaume Laforge
> Groovy Project Manager
> Head of Groovy Development at SpringSource
> http://www.springsource.com/g2one

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Note about version numbers

2009-11-29T11:13:02Z

Russel Winder schrieb:
> Until yesterday development version were numbered x.y-beta-z-SNAPSHOT it
> seems though that trunk is now 1.8.0-beta-1-SNAPSHOT.
>
> Is this intentional?
>
> (It affects the version number parsing in the Gant tests.)

no, that was me not remembering how to do that correctly... Well... on
fact I would prefer that scheme, but if it is causing problems, I can
change it

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: HTML decoding without reinventing the wheel

2009-11-29T10:52:24Z

The Groovy GDK documentation is using QDox for parsing the DefaultGroovyMethods class, perhaps you can do something similar, parse the JavaDoc, extract the pre tag. You'll probably need some regex kungfu.

On Sun, Nov 29, 2009 at 19:16, Merlyn Albery-Speyer <curious.attempt.bunny@...> wrote:

Hi all,

Pardon the off topic question here. I'm looking for an easy yet robust
way to pass this test:

void testDecodesHtml() {
Class test = builder.buildTest("SomeClass.java", '''
/** <pre class="groovyTestCase"> assert 3 < 5 </pre> */
public class SomeClass { }
''')
test.newInstance().testAssertionFromLineNumber2();
}

For this I need something available to the groovy runtime that can
decode <,  , etc. Is there something already in the groovy
runtime that can do this for me?

Cheers,
Merlyn

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

HTML decoding without reinventing the wheel

2009-11-29T10:16:44Z

Hi all,

Pardon the off topic question here. I'm looking for an easy yet robust
way to pass this test:

void testDecodesHtml() {
Class test = builder.buildTest("SomeClass.java", '''
/** <pre class="groovyTestCase"> assert 3 < 5 </pre> */
public class SomeClass { }
''')
test.newInstance().testAssertionFromLineNumber2();
}

For this I need something available to the groovy runtime that can
decode <, , etc. Is there something already in the groovy
runtime that can do this for me?

Cheers,
Merlyn

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Windows Installer for 1.6.6 and 1.7RC1

2009-11-29T10:10:57Z

Hi,

I didn't have time this weekend and will be away for the next week, but
I hope that next weekend I can create the new installers.

So, the usual question for the respective version of Groovy: Which
version of the different modules should be packed with Groovy?

Cheers, Joachim

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Bamboo build for 1.7.0 branch

2009-11-29T08:35:13Z

Okay, I think I properly made the full doco build a child of the 1.7.x JDK 6 build.

We'll see if it works for the next time.

On Sun, Nov 29, 2009 at 17:26, Roshan Dawrani <roshandawrani@...> wrote:

Thanks. The 1.7.0 builds have kicked-in.

While we are at it - 1.7.x build with documentation, etc also did not kick-in as a dependency of 1.7.x JDK 1.6 build.

The normal JDK 1.5/1.6 builds started fine.

On Sun, Nov 29, 2009 at 9:48 PM, Guillaume Laforge <glaforge@...> wrote:

On Sun, Nov 29, 2009 at 17:14, Guillaume Laforge <glaforge@...> wrote:

On Sun, Nov 29, 2009 at 17:01, Roshan Dawrani <roshandawrani@...> wrote:

Hi,
Is the Bamboo build not setup yet for 1.7.0? The 1.7.0 build entries that show up on http://bamboo.ci.codehaus.org/browse/GROOVY are greyed-out.

I checked-in the fix for GROOVY-3911 but the build is not kicking-in?

I think Jochen created the two Bamboo plans for 1.7.0.
They look inded greyed-out, not sure exactly why, perhaps they're just not triggered automatically.

When you're logged-in, can you launch them manually yourself? (wondering if all the rights are properly setup for all committers).

The SVN branch was not pointing at the right place, dunno if that's what causing the issue.
I'm gonna try launch the builds manually for now at least.

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

Re: Bamboo build for 1.7.0 branch

2009-11-29T08:26:55Z

Thanks. The 1.7.0 builds have kicked-in.

While we are at it - 1.7.x build with documentation, etc also did not kick-in as a dependency of 1.7.x JDK 1.6 build.

The normal JDK 1.5/1.6 builds started fine.

On Sun, Nov 29, 2009 at 9:48 PM, Guillaume Laforge <glaforge@...> wrote:

On Sun, Nov 29, 2009 at 17:14, Guillaume Laforge <glaforge@...> wrote:

On Sun, Nov 29, 2009 at 17:01, Roshan Dawrani <roshandawrani@...> wrote:

Hi,
Is the Bamboo build not setup yet for 1.7.0? The 1.7.0 build entries that show up on http://bamboo.ci.codehaus.org/browse/GROOVY are greyed-out.

I checked-in the fix for GROOVY-3911 but the build is not kicking-in?

I think Jochen created the two Bamboo plans for 1.7.0.
They look inded greyed-out, not sure exactly why, perhaps they're just not triggered automatically.

When you're logged-in, can you launch them manually yourself? (wondering if all the rights are properly setup for all committers).

The SVN branch was not pointing at the right place, dunno if that's what causing the issue.
I'm gonna try launch the builds manually for now at least.

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

Re: Bamboo build for 1.7.0 branch

2009-11-29T08:18:25Z

On Sun, Nov 29, 2009 at 17:14, Guillaume Laforge <glaforge@...> wrote:

On Sun, Nov 29, 2009 at 17:01, Roshan Dawrani <roshandawrani@...> wrote:

Hi,
Is the Bamboo build not setup yet for 1.7.0? The 1.7.0 build entries that show up on http://bamboo.ci.codehaus.org/browse/GROOVY are greyed-out.

I checked-in the fix for GROOVY-3911 but the build is not kicking-in?

I think Jochen created the two Bamboo plans for 1.7.0.
They look inded greyed-out, not sure exactly why, perhaps they're just not triggered automatically.

When you're logged-in, can you launch them manually yourself? (wondering if all the rights are properly setup for all committers).

The SVN branch was not pointing at the right place, dunno if that's what causing the issue.

I'm gonna try launch the builds manually for now at least.

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

Re: Bamboo build for 1.7.0 branch

2009-11-29T08:14:25Z

On Sun, Nov 29, 2009 at 17:01, Roshan Dawrani <roshandawrani@...> wrote:

Hi,
Is the Bamboo build not setup yet for 1.7.0? The 1.7.0 build entries that show up on http://bamboo.ci.codehaus.org/browse/GROOVY are greyed-out.

I checked-in the fix for GROOVY-3911 but the build is not kicking-in?

I think Jochen created the two Bamboo plans for 1.7.0.

They look inded greyed-out, not sure exactly why, perhaps they're just not triggered automatically.

When you're logged-in, can you launch them manually yourself? (wondering if all the rights are properly setup for all committers).

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

Bamboo build for 1.7.0 branch

2009-11-29T08:01:22Z

Hi,
Is the Bamboo build not setup yet for 1.7.0? The 1.7.0 build entries that show up on http://bamboo.ci.codehaus.org/browse/GROOVY are greyed-out.

I checked-in the fix for GROOVY-3911 but the build is not kicking-in?

rgds,
Roshan

Re: Changes post RC release

2009-11-29T07:34:05Z

I also agree for this one which is weird, and everybody will wonder why something so obvious isn't fixed in the final release, as it's a pretty visual thing :-(

But otherwise, yes, we need to mimize what's going to be in that 1_7_0 branch, Jochen's right.

But this one could be in, since we'll have an RC-2 anyway.

On Sun, Nov 29, 2009 at 14:55, Roshan Dawrani <roshandawrani@...> wrote:

You don't want it solved in main 1.7 release that whenever u run the new groovy console, a blank window without any body/message just stays there?

You should see how silly it looks - everybody will need to be explained what is the workaround - that u use the "Detach" option one time and then everything will be fine.

On Sun, Nov 29, 2009 at 7:21 PM, Jochen Theodorou <blackdrag@...> wrote:
Guillaume Laforge schrieb:
[...]

So, if there is one blocker that mandates the RC-2, say, then why do
even other issues have to be blockers in order to be included in RC-2?

If RC-2 is happening anyway and in a month's time or so, we get to
know about issues that are not really blockers, per se, but are
genuine nuisances anyway, then why can't they be included?

For example, the new groovy console dialog box issue reported on
user list today or compiler going into endless loop and interfaces
have circular references? Shouldn't such things also be included in
RC-2 if it is happening anyway?

Yeah, well, these kind of non-critical issues can be going into the branch, since we'll have to do an RC-2 anyway, I think it's okay, as the impact is not big in any way.
And yes, this one about the dialog box, and having a little icon instead of the running box would be good to be fixed too and included.

I do not agee fully. Each bug fix can cause trouble, so the number of fixes should be minimized. Even simple tings can cause a problem and then the next release is required. I am for only fixing the bug I caused and not putting any other things.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

Re: Changes post RC release

2009-11-29T05:55:15Z

You don't want it solved in main 1.7 release that whenever u run the new groovy console, a blank window without any body/message just stays there?

You should see how silly it looks - everybody will need to be explained what is the workaround - that u use the "Detach" option one time and then everything will be fine.

On Sun, Nov 29, 2009 at 7:21 PM, Jochen Theodorou <blackdrag@...> wrote:

Guillaume Laforge schrieb:
[...]

So, if there is one blocker that mandates the RC-2, say, then why do
even other issues have to be blockers in order to be included in RC-2?

If RC-2 is happening anyway and in a month's time or so, we get to
know about issues that are not really blockers, per se, but are
genuine nuisances anyway, then why can't they be included?

For example, the new groovy console dialog box issue reported on
user list today or compiler going into endless loop and interfaces
have circular references? Shouldn't such things also be included in
RC-2 if it is happening anyway?

Yeah, well, these kind of non-critical issues can be going into the branch, since we'll have to do an RC-2 anyway, I think it's okay, as the impact is not big in any way.
And yes, this one about the dialog box, and having a little icon instead of the running box would be good to be fixed too and included.

I do not agee fully. Each bug fix can cause trouble, so the number of fixes should be minimized. Even simple tings can cause a problem and then the next release is required. I am for only fixing the bug I caused and not putting any other things.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Changes post RC release

2009-11-29T05:51:53Z

Guillaume Laforge schrieb:
[...]

>
> So, if there is one blocker that mandates the RC-2, say, then why do
> even other issues have to be blockers in order to be included in RC-2?
>
> If RC-2 is happening anyway and in a month's time or so, we get to
> know about issues that are not really blockers, per se, but are
> genuine nuisances anyway, then why can't they be included?
>
> For example, the new groovy console dialog box issue reported on
> user list today or compiler going into endless loop and interfaces
> have circular references? Shouldn't such things also be included in
> RC-2 if it is happening anyway?
>
>
> Yeah, well, these kind of non-critical issues can be going into the
> branch, since we'll have to do an RC-2 anyway, I think it's okay, as the
> impact is not big in any way.
> And yes, this one about the dialog box, and having a little icon instead
> of the running box would be good to be fixed too and included.

I do not agee fully. Each bug fix can cause trouble, so the number of
fixes should be minimized. Even simple tings can cause a problem and
then the next release is required. I am for only fixing the bug I caused
and not putting any other things.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Changes post RC release

2009-11-29T05:06:25Z

On Sun, Nov 29, 2009 at 14:00, Roshan Dawrani <roshandawrani@...> wrote:

On Sun, Nov 29, 2009 at 3:48 PM, Jochen Theodorou <blackdrag@...> wrote:
ok, then change in policy... changes to 1_7_0 only if it is to be considered a blocker for 1.7.0 and the change will reuqire a new RC

bye blackdrag

So, if there is one blocker that mandates the RC-2, say, then why do even other issues have to be blockers in order to be included in RC-2?

If RC-2 is happening anyway and in a month's time or so, we get to know about issues that are not really blockers, per se, but are genuine nuisances anyway, then why can't they be included?

For example, the new groovy console dialog box issue reported on user list today or compiler going into endless loop and interfaces have circular references? Shouldn't such things also be included in RC-2 if it is happening anyway?

Yeah, well, these kind of non-critical issues can be going into the branch, since we'll have to do an RC-2 anyway, I think it's okay, as the impact is not big in any way.

And yes, this one about the dialog box, and having a little icon instead of the running box would be good to be fixed too and included.

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

Re: Changes post RC release

2009-11-29T05:00:28Z

On Sun, Nov 29, 2009 at 3:48 PM, Jochen Theodorou <blackdrag@...> wrote:

ok, then change in policy... changes to 1_7_0 only if it is to be considered a blocker for 1.7.0 and the change will reuqire a new RC

bye blackdrag

So, if there is one blocker that mandates the RC-2, say, then why do even other issues have to be blockers in order to be included in RC-2?

If RC-2 is happening anyway and in a month's time or so, we get to know about issues that are not really blockers, per se, but are genuine nuisances anyway, then why can't they be included?

For example, the new groovy console dialog box issue reported on user list today or compiler going into endless loop and interfaces have circular references? Shouldn't such things also be included in RC-2 if it is happening anyway?

Re: Changes post RC release

2009-11-29T02:18:24Z

Russel Winder schrieb:

> On Sat, 2009-11-28 at 22:20 +0100, Jochen Theodorou wrote:
>> Russel Winder schrieb:
>>> On Sat, 2009-11-28 at 18:23 +0100, Jochen Theodorou wrote:
>>>> Roshan Dawrani schrieb:
>>>>> Let me test the policy a bit :-) What should I do about GROOVY-1465 -> a
>>>>> change post RC-1. Where will it fit? (I need the answer anyway after
>>>>> pushing it just to trunk)
>>>> that is an ok one for all, since it removes an endless loop. It does not
>>>> change the langauge or anything.
>>> But it will then require 1.7-rc-2 to be released for testing before
>>> 1.7.0 can be released.
>> you say we should go with absolutely no chane in 1_7_0 unless something
>> really bad happens? Well we can go with that too
>
> No, that isn't what I was saying. What I was saying is that 1.7.0 must
> be identical to the last RC released and tested. So if changes to
> 1.7-rc-X are needed then 1.7-rc-(X+1) must be released and allowed to be
> tested.

ok, then change in policy... changes to 1_7_0 only if it is to be
considered a blocker for 1.7.0 and the change will reuqire a new RC

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Regression in MarkupBuilder?

2009-11-29T01:20:15Z

Okie dokie, no worries, it's better to continue the alignment anyway.

On Sun, Nov 29, 2009 at 08:54, Paul King <paulk@...> wrote:

Guillaume Laforge wrote:

Hmm, okay.
But it used to work that way before.
But that's perhaps an artifact of aligning MarkupBuilder and StreamingMarkupBuilder.
Anyhow, with mkp.yieldUnescaped, I'm fine.
Thanks!

Yes, part of the alignment activity. To support things
like mkp.comment without breaking people using comment
as their tag name meant we had to turn it off the previous
shortcut feature by default. There is a bit of discussion
I think in one of the related issues. I pondered making
some kind of legacy mode to support the old behavior
but the implementation was starting to look very cumbersome.

Paul.

On Sun, Nov 29, 2009 at 07:29, Merlyn Albery-Speyer <curious.attempt.bunny@... <mailto:curious.attempt.bunny@...>> wrote:

No bug per say. It's a combination of two things. First you need to
use the mkp the property to access yieldUnescaped. Second your mkp
variable is taking precedence over the MarkupBuilder mkp property
(which surprised me). So this will work:

def mkp2 = new groovy.xml.MarkupBuilder()
mkp2.html {
body {
h1 "test"
mkp.yieldUnescaped "foo"
}
}

On Sat, Nov 28, 2009 at 9:05 PM, Guillaume Laforge
<glaforge@... <mailto:glaforge@...>> wrote:
> Hi all,
> Suffering from insomnia and playing with the Groovy Web Console
which I
> updated to Groovy 1.7-RC-1, I think I noticed a regression in
MarkupBuilder.
> If you execute that:
> import groovy.xml.MarkupBuilder
> def mkp = new MarkupBuilder()
> mkp.html {
> body {
> h1 "test"
> yieldUnescaped "foo"
> }
> }
> It'll generate a tag <yieldUnescaped>foo</yieldUnescaped>.
> Am I missing something?
> Has there any change been done in that area?
> Or is it just a regresion?
> PS: suffering from insomnia, but not courageous enough to have a
look at the
> code base :-)
>
> --
> Guillaume Laforge
> Groovy Project Manager
> Head of Groovy Development at SpringSource
> http://www.springsource.com/g2one
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

Re: Regression in MarkupBuilder?

2009-11-28T23:54:04Z

Guillaume Laforge wrote:
> Hmm, okay.
> But it used to work that way before.
> But that's perhaps an artifact of aligning MarkupBuilder and
> StreamingMarkupBuilder.
> Anyhow, with mkp.yieldUnescaped, I'm fine.
> Thanks!

Yes, part of the alignment activity. To support things
like mkp.comment without breaking people using comment
as their tag name meant we had to turn it off the previous
shortcut feature by default. There is a bit of discussion
I think in one of the related issues. I pondered making
some kind of legacy mode to support the old behavior
but the implementation was starting to look very cumbersome.

Paul.

> On Sun, Nov 29, 2009 at 07:29, Merlyn Albery-Speyer
> <curious.attempt.bunny@...
> <mailto:curious.attempt.bunny@...>> wrote:
>
> No bug per say. It's a combination of two things. First you need to
> use the mkp the property to access yieldUnescaped. Second your mkp
> variable is taking precedence over the MarkupBuilder mkp property
> (which surprised me). So this will work:
>
> def mkp2 = new groovy.xml.MarkupBuilder()
> mkp2.html {
> body {
> h1 "test"
> mkp.yieldUnescaped "foo"
> }
> }
>
> On Sat, Nov 28, 2009 at 9:05 PM, Guillaume Laforge
> <glaforge@... <mailto:glaforge@...>> wrote:
> > Hi all,
> > Suffering from insomnia and playing with the Groovy Web Console
> which I
> > updated to Groovy 1.7-RC-1, I think I noticed a regression in
> MarkupBuilder.
> > If you execute that:
> > import groovy.xml.MarkupBuilder
> > def mkp = new MarkupBuilder()
> > mkp.html {
> > body {
> > h1 "test"
> > yieldUnescaped "foo"
> > }
> > }
> > It'll generate a tag <yieldUnescaped>foo</yieldUnescaped>.
> > Am I missing something?
> > Has there any change been done in that area?
> > Or is it just a regresion?
> > PS: suffering from insomnia, but not courageous enough to have a
> look at the
> > code base :-)
> >
> > --
> > Guillaume Laforge
> > Groovy Project Manager
> > Head of Groovy Development at SpringSource
> > http://www.springsource.com/g2one
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
>
>
> --
> Guillaume Laforge
> Groovy Project Manager
> Head of Groovy Development at SpringSource
> http://www.springsource.com/g2one

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Regression in MarkupBuilder?

2009-11-28T22:32:44Z

Hmm, okay.

But it used to work that way before.

But that's perhaps an artifact of aligning MarkupBuilder and StreamingMarkupBuilder.

Anyhow, with mkp.yieldUnescaped, I'm fine.

Thanks!

On Sun, Nov 29, 2009 at 07:29, Merlyn Albery-Speyer <curious.attempt.bunny@...> wrote:

No bug per say. It's a combination of two things. First you need to
use the mkp the property to access yieldUnescaped. Second your mkp
variable is taking precedence over the MarkupBuilder mkp property
(which surprised me). So this will work:

def mkp2 = new groovy.xml.MarkupBuilder()
mkp2.html {
body {
h1 "test"
mkp.yieldUnescaped "foo"

}
}

On Sat, Nov 28, 2009 at 9:05 PM, Guillaume Laforge <glaforge@...> wrote:
> Hi all,
> Suffering from insomnia and playing with the Groovy Web Console which I
> updated to Groovy 1.7-RC-1, I think I noticed a regression in MarkupBuilder.
> If you execute that:
> import groovy.xml.MarkupBuilder
> def mkp = new MarkupBuilder()
> mkp.html {
>    body {
>    h1 "test"
>    yieldUnescaped "foo"
>    }
> }
> It'll generate a tag <yieldUnescaped>foo</yieldUnescaped>.
> Am I missing something?
> Has there any change been done in that area?
> Or is it just a regresion?
> PS: suffering from insomnia, but not courageous enough to have a look at the
> code base :-)
>
> --
> Guillaume Laforge
> Groovy Project Manager
> Head of Groovy Development at SpringSource
> http://www.springsource.com/g2one
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

Re: Regression in MarkupBuilder?

2009-11-28T22:29:59Z

No bug per say. It's a combination of two things. First you need to
use the mkp the property to access yieldUnescaped. Second your mkp
variable is taking precedence over the MarkupBuilder mkp property
(which surprised me). So this will work:

def mkp2 = new groovy.xml.MarkupBuilder()
mkp2.html {
body {
h1 "test"
mkp.yieldUnescaped "foo"
}
}

On Sat, Nov 28, 2009 at 9:05 PM, Guillaume Laforge <glaforge@...> wrote:

> Hi all,
> Suffering from insomnia and playing with the Groovy Web Console which I
> updated to Groovy 1.7-RC-1, I think I noticed a regression in MarkupBuilder.
> If you execute that:
> import groovy.xml.MarkupBuilder
> def mkp = new MarkupBuilder()
> mkp.html {
>    body {
>    h1 "test"
>    yieldUnescaped "foo"
>    }
> }
> It'll generate a tag <yieldUnescaped>foo</yieldUnescaped>.
> Am I missing something?
> Has there any change been done in that area?
> Or is it just a regresion?
> PS: suffering from insomnia, but not courageous enough to have a look at the
> code base :-)
>
> --
> Guillaume Laforge
> Groovy Project Manager
> Head of Groovy Development at SpringSource
> http://www.springsource.com/g2one
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Regression in MarkupBuilder?

2009-11-28T21:05:56Z

Hi all,

Suffering from insomnia and playing with the Groovy Web Console which I updated to Groovy 1.7-RC-1, I think I noticed a regression in MarkupBuilder.

If you execute that:

import groovy.xml.MarkupBuilder

def mkp = new MarkupBuilder()

mkp.html {

body {

h1 "test"

yieldUnescaped "foo"

}

It'll generate a tag <yieldUnescaped>foo</yieldUnescaped>.

Am I missing something?

Has there any change been done in that area?

Or is it just a regresion?

PS: suffering from insomnia, but not courageous enough to have a look at the code base :-)

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

Re: Adding reGINA examples to the unit tests

2009-11-28T17:26:45Z

Dierk König wrote:
> I'm all for it but we have to consider possible Manning copyrights on this.
> Will check.

In the worst case, couldn't we just create equivalent tests: use
different identifiers and change the code around, but test the same
language features?

> Am 28.11.2009 um 14:38 schrieb Roshan Dawrani:
>
>> I think as groovy changes over time, it may only be natural for
>> printed examples to become invalid - the changes that happen may
>> deviate from printed behavior for a genuine reason.

I agree. When we make a change that invalidates an example from the
book, we need to be aware we're doing it, and decide its worth the cost.
I think there were examples after the 1st edition of GINA where the
behaviour was changed without people realizing it would affect the
examples. Or maybe the behavior had changed before the book was even
published, or something like that.

>> What is needed is just to keep the book examples and groovy in sync.
>> May be a portion of groovy site can host all the examples - organized
>> by chapters.
>>
>> And as and when behavior changes, the book examples can be kept
>> up-to-date - possibly with a note there explaining the behavior change.
>>
>> rgds,
>> Roshan
>>
>> On Sat, Nov 28, 2009 at 6:08 PM, Martin C. Martin
>> <martin@... <mailto:martin@...>> wrote:
>>
>> Hi all,
>>
>> Is there a plan to add the examples in the new Groovy In Action to
>> the unit tests? There have been problems where behavior described
>> in GINA was changed without realizing we were invalidating the book.
>>
>> Best,
>> Martin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Changes post RC release

2009-11-28T14:04:20Z

On Sat, 2009-11-28 at 22:20 +0100, Jochen Theodorou wrote:

> Russel Winder schrieb:
> > On Sat, 2009-11-28 at 18:23 +0100, Jochen Theodorou wrote:
> >> Roshan Dawrani schrieb:
> >>> Let me test the policy a bit :-) What should I do about GROOVY-1465 -> a
> >>> change post RC-1. Where will it fit? (I need the answer anyway after
> >>> pushing it just to trunk)
> >> that is an ok one for all, since it removes an endless loop. It does not
> >> change the langauge or anything.
> >
> > But it will then require 1.7-rc-2 to be released for testing before
> > 1.7.0 can be released.
>
> you say we should go with absolutely no chane in 1_7_0 unless something
> really bad happens? Well we can go with that too

No, that isn't what I was saying. What I was saying is that 1.7.0 must
be identical to the last RC released and tested. So if changes to
1.7-rc-X are needed then 1.7-rc-(X+1) must be released and allowed to be
tested.

--
Russel.
=============================================================================
Dr Russel Winder Partner
xmpp: russel@...
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip:russel.winder@...
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder

signature.asc (204 bytes) Download Attachment

Re: Changes post RC release

2009-11-28T13:20:22Z

Russel Winder schrieb:

> On Sat, 2009-11-28 at 18:23 +0100, Jochen Theodorou wrote:
>> Roshan Dawrani schrieb:
>>> Let me test the policy a bit :-) What should I do about GROOVY-1465 -> a
>>> change post RC-1. Where will it fit? (I need the answer anyway after
>>> pushing it just to trunk)
>> that is an ok one for all, since it removes an endless loop. It does not
>> change the langauge or anything.
>
> But it will then require 1.7-rc-2 to be released for testing before
> 1.7.0 can be released.

you say we should go with absolutely no chane in 1_7_0 unless something
really bad happens? Well we can go with that too

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Changes post RC release

2009-11-28T09:50:57Z

On Sat, 2009-11-28 at 18:23 +0100, Jochen Theodorou wrote:
> Roshan Dawrani schrieb:
> > Let me test the policy a bit :-) What should I do about GROOVY-1465 -> a
> > change post RC-1. Where will it fit? (I need the answer anyway after
> > pushing it just to trunk)
>
> that is an ok one for all, since it removes an endless loop. It does not
> change the langauge or anything.

But it will then require 1.7-rc-2 to be released for testing before
1.7.0 can be released.

--
Russel.
=============================================================================
Dr Russel Winder Partner
xmpp: russel@...
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip:russel.winder@...
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder

signature.asc (204 bytes) Download Attachment

Re: Groovy supports goto - bug or feature?

2009-11-28T09:38:30Z

I have created http://jira.codehaus.org/browse/GROOVY-3908 to track this issue.

Cheers,
Peter

Jochen Theodorou wrote:

Alex Shneyderman schrieb:
>> undocumented, not ensured feature. How id you find that, I found nobody
>> would ever find my easter egg ;)
>
> Please, stop planting your easter eggs and document the ones
> you already did plant.
>
> These sorts of things make people very nervous and rightfully so.
> What if next you will decide to plant money-transfer egg (from an
> available account to your Swiss Bank account)?

haha, there is only a check missing preventing this kind of stuff,
nothing more.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Changes post RC release

2009-11-28T09:23:10Z

Roshan Dawrani schrieb:
> Let me test the policy a bit :-) What should I do about GROOVY-1465 -> a
> change post RC-1. Where will it fit? (I need the answer anyway after
> pushing it just to trunk)

that is an ok one for all, since it removes an endless loop. It does not
change the langauge or anything.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Documenting Groovy JDK methods with assertions

2009-11-28T08:33:02Z

Hi Blackdrag,

On Sat, Nov 28, 2009 at 4:37 AM, Jochen Theodorou <blackdrag@...> wrote:
> all in all a very good idea. Instead of the test tag we... hmm.. how about
> something like <pre class="groovytestcase">...</pre>, or using the code tags
> for it? This could also used by some java script to do a small bit of syntax
> highliting. I have a script like that on my blog, so it is not really much
> of a problem

Yes. That's a neater solution. I'll do that instead.

Cheers,
Merlyn

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Documenting Groovy JDK methods with assertions

2009-11-28T08:31:35Z

Hey Martin,

Thank you. I didn't realise just how much was in DefaultGroovyMethods
before I started. So I might be a few more days at it.

Cheers,
Merlyn

On Sat, Nov 28, 2009 at 4:35 AM, Martin C. Martin
<martin@...> wrote:

> This is great! Having documentation like this will really help, and so will
> the tests. And it's really, really helpful that you're adding them to the
> test suite as well. I think a <test> tag is perfect.
>
> Best,
> Martin
>
> Merlyn Albery-Speyer wrote:
>>
>> Hi all,
>>
>> I learnt a lot of Groovy from the Groovy JDK pages, and I like the
>> documentation through assertions in Javadocs. So I'm working my way
>> through the DefaultGroovyMethods class adding examples like this one:
>>
>> /**
>> * Splits all items into two lists based on the closure condition.
>> * The first list contains all items matching the closure expression.
>> * The second list all those that don't. Example:
>> * <code><test><pre>assert [1, 2, 3, 4, 5].split { it % 2 == 0 }
>> == [[2, 4], [1, 3, 5]]</pre></test></code>
>> *
>> * @param self an Object with an Iterator returning its values
>> * @param closure a closure condition
>> * @return a List containing whose first item is the accepted
>> values and whose second item is the rejected values
>> * @since 1.6.0
>> */
>> public static Collection split(Object self, Closure closure) {
>>
>> As a way of ensuring I don't introduce erroneous assertions (and that
>> future changes don't break them), I've added a test to
>> DefaultGroovyMethodsTest that executes all the assertions in the
>> Javadoc comment.
>>
>> What do you think? Is there a better way of marking up the assertion
>> than a <test> tag?
>>
>> Cheers,
>> Merlyn
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Adding reGINA examples to the unit tests

2009-11-28T07:31:03Z

I'm all for it but we have to consider possible Manning copyrights on this.

Will check.

Dierk

Am 28.11.2009 um 14:38 schrieb Roshan Dawrani:

I think as groovy changes over time, it may only be natural for printed examples to become invalid - the changes that happen may deviate from printed behavior for a genuine reason.

What is needed is just to keep the book examples and groovy in sync. May be a portion of groovy site can host all the examples - organized by chapters.

And as and when behavior changes, the book examples can be kept up-to-date - possibly with a note there explaining the behavior change.

rgds,
Roshan

On Sat, Nov 28, 2009 at 6:08 PM, Martin C. Martin <martin@...> wrote:

Hi all,

Is there a plan to add the examples in the new Groovy In Action to the unit tests? There have been problems where behavior described in GINA was changed without realizing we were invalidating the book.

Best,
Martin

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Adding reGINA examples to the unit tests

2009-11-28T05:38:12Z

I think as groovy changes over time, it may only be natural for printed examples to become invalid - the changes that happen may deviate from printed behavior for a genuine reason.

What is needed is just to keep the book examples and groovy in sync. May be a portion of groovy site can host all the examples - organized by chapters.

And as and when behavior changes, the book examples can be kept up-to-date - possibly with a note there explaining the behavior change.

rgds,
Roshan

On Sat, Nov 28, 2009 at 6:08 PM, Martin C. Martin <martin@...> wrote:

Hi all,

Is there a plan to add the examples in the new Groovy In Action to the unit tests? There have been problems where behavior described in GINA was changed without realizing we were invalidating the book.

Best,
Martin

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email