Nabble - codehaus - Groovy

Re: Nested class inheritance used to work

2009-11-25T10:28:43Z

The following code not only compiles but also runs - even though A is a non-static class referred in a static context:

----------------------------------
public class Parent {
   public class A {
   }

   public static void moo() {
      final a = new A()
      println a
   }
}

Parent.moo()
----------------------------------

This is not correct, right?

On Wed, Nov 25, 2009 at 2:58 PM, Jochen Theodorou <blackdrag@...> wrote:

Roshan Dawrani schrieb:

If the try the same code on 1.7-beta-1 groovyconsole, I get the error:
-----------------------------------
1 compilation error:

unable to resolve class A
at line: 5, column: 4
-----------------------------------

In any case, can you please file a bug?

that is fixed already, it will now compile... still it will not run, since moo is a static method and A not a static nested class.

Also I wonder what this pre milestone 1 is... Is that before Groovy 1.0?

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

From forum: groovy - user

Re: Heads-up: release of 1.6.6 and 1.7-RC-1 Friday

2009-11-25T10:24:02Z

Should this be considered a blocker for 1.7?

http://jira.codehaus.org/browse/GROOVY-3714

Best,
Martin

Jochen Theodorou wrote:

> Alex Tkachman schrieb:
>> I see 6 blockers and 15 major issues in Jira. How can it be RC on Friday?
>
> you mean 6 blockers and 17 critical. Of these blockers most are for 2.0,
> one is for 1.6.6 (which I will fix tomorrow) and one for 1.7, which is
> a compiler check only, so no problem. The last blocker is
> GROOVY-3819 which I don't know why it is one.
>
> bye blackdrag
>

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

http://xircles.codehaus.org/manage_email

From forum: groovy - dev

Re: Heads-up: release of 1.6.6 and 1.7-RC-1 Friday

2009-11-25T10:19:12Z

Alex Tkachman schrieb:
> I see 6 blockers and 15 major issues in Jira. How can it be RC on Friday?

you mean 6 blockers and 17 critical. Of these blockers most are for 2.0,
one is for 1.6.6 (which I will fix tomorrow) and one for 1.7, which is
a compiler check only, so no problem. The last blocker is GROOVY-3819
which I don't know why it is one.

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

From forum: groovy - dev

Re: Change in the way Groovy version is managed

2009-11-25T10:16:39Z

2 reasons that had come out in the comments were (restated here):

a) The manifest certainly contains all the information we need. But how do we find it at runtime? Search through all manifests found on the class path?

b) With a custom properties file, we could also include things like SVN revision number and build time (if we wanted to).

I don't really understand what tool you are talking about making available to Gant, Gradle, Griffon, etc. If you are clear about what you are asking for, you can raise a JIRA for it.

The problem with the classloader may be related to GAE in the reported instance but it can occur under any container that uses custom classloaders - it then depends on how they are defining the packages.

GANT may probably continue to stick to Package.getPackage technique as it doesn't have to deal with custom class loaders like in GAE or inside various web/app servers.

On Wed, Nov 25, 2009 at 11:36 PM, Russel Winder <russel.winder@...> wrote:

Roshan,

On Wed, 2009-11-25 at 23:10 +0530, Roshan Dawrani wrote:
> Have you gone through the comments of GROOVY-3884? If not, I suggest
> first you do that.

Yes I had read it, and was appalled <for reasons that are redacted>.
However my point is actually very simple. I understand the need for
having a class to avoid using the class loader however objectionable it
is that we have to do this just to please GAE. My question is why we
have to replicate the information already in MANIFEST.MF in another
file, why not just read MANIFEST.MF to get the information. Or is it
that GAE actually removes MANIFEST.MF from any jar it loads from?

Also it would be good if tools such as this could be made available so
Gant, Gradle, Griffon, etc. can use the same tools and not end up
replicating them.

--

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%3Arussel.winder@...
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder

From forum: groovy - dev

Re: Change in the way Groovy version is managed

2009-11-25T10:06:38Z

Roshan,

On Wed, 2009-11-25 at 23:10 +0530, Roshan Dawrani wrote:
> Have you gone through the comments of GROOVY-3884? If not, I suggest
> first you do that.

Yes I had read it, and was appalled <for reasons that are redacted>.
However my point is actually very simple. I understand the need for
having a class to avoid using the class loader however objectionable it
is that we have to do this just to please GAE. My question is why we
have to replicate the information already in MANIFEST.MF in another
file, why not just read MANIFEST.MF to get the information. Or is it
that GAE actually removes MANIFEST.MF from any jar it loads from?

Also it would be good if tools such as this could be made available so
Gant, Gradle, Griffon, etc. can use the same tools and not end up
replicating them.

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

From forum: groovy - dev

Re: Heads-up: release of 1.6.6 and 1.7-RC-1 Friday

2009-11-25T10:05:29Z

I see 6 blockers and 15 major issues in Jira. How can it be RC on Friday?

On Wed, Nov 25, 2009 at 7:50 PM, Russel Winder
<russel.winder@...> wrote:

> On Wed, 2009-11-25 at 18:32 +0100, Guillaume Laforge wrote:
>> Hi all,
>>
>> Just a quick heads-up to say we plan to release Groovy 1.6.6 and
>> Groovy 1.7-RC-1 on Friday.
>
> I know you and Jochen (indeed everyone one this list) already know all
> that follows, but I thought I would say it anyway so we can avert the
> fiasco we ended up with with the 1.6 release.
>
> Once the RC is released there must be no changes to it before it becomes
> the release unless some absolutely have to be made because the RC is not
> fit to be the release: a release candidate is a release candidate and
> not an alpha or beta release with a different name. If it turns out
> that RC-1 is not a fit release and changes are made, then there must be
> an RC-2, etc., etc. Whatever the final 1.7.0 release is, it must be
> absolutely identical to the final release candidate in every and all
> ways.
>
> This means that trunk should immediately become 1.8.x with the 1.7
> maintenance branch being taken and the release candidate tagged. There
> must be no way for any developer to slip in changes between release
> candidate and release.
>
> --
> 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
>

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

http://xircles.codehaus.org/manage_email

From forum: groovy - dev

Re: Heads-up: release of 1.6.6 and 1.7-RC-1 Friday

2009-11-25T09:50:44Z

On Wed, 2009-11-25 at 18:32 +0100, Guillaume Laforge wrote:
> Hi all,
>
> Just a quick heads-up to say we plan to release Groovy 1.6.6 and
> Groovy 1.7-RC-1 on Friday.

I know you and Jochen (indeed everyone one this list) already know all
that follows, but I thought I would say it anyway so we can avert the
fiasco we ended up with with the 1.6 release.

Once the RC is released there must be no changes to it before it becomes
the release unless some absolutely have to be made because the RC is not
fit to be the release: a release candidate is a release candidate and
not an alpha or beta release with a different name. If it turns out
that RC-1 is not a fit release and changes are made, then there must be
an RC-2, etc., etc. Whatever the final 1.7.0 release is, it must be
absolutely identical to the final release candidate in every and all
ways.

This means that trunk should immediately become 1.8.x with the 1.7
maintenance branch being taken and the release candidate tagged. There
must be no way for any developer to slip in changes between release
candidate and release.

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

From forum: groovy - dev

Re: Change in the way Groovy version is managed

2009-11-25T09:40:02Z

Have you gone through the comments of GROOVY-3884? If not, I suggest first you do that.

rgds,
Roshan

On Wed, Nov 25, 2009 at 11:07 PM, Russel Winder <russel.winder@...> wrote:

Roshan,

I spotted your amendment to the way Groovy version is processed,
responding to GROOVY-3884 (http://jira.codehaus.org/browse/GROOVY-3884)

I use the same Package.getPackage technique in Gant. Given that this
gets the version number from the metadata in the jar file I am not sure
what the problem is.

Isn't the solution you have replicating information in
release-info.properties that is already in the MANIFEST.MF file?

--
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%3Arussel.winder@...
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder

From forum: groovy - dev

Change in the way Groovy version is managed

2009-11-25T09:37:30Z

Roshan,

I spotted your amendment to the way Groovy version is processed,
responding to GROOVY-3884 (http://jira.codehaus.org/browse/GROOVY-3884)

I use the same Package.getPackage technique in Gant. Given that this
gets the version number from the metadata in the jar file I am not sure
what the problem is.

Isn't the solution you have replicating information in
release-info.properties that is already in the MANIFEST.MF file?

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

From forum: groovy - dev

Re: External Content with BuilderSupport

2009-11-25T09:33:26Z

Jochen Theodorou wrote:

text is a String, putting the curly braces around it makes it a Closure
that returns that string only. What you would need is something like:

testClosure = {
evaluate text
}

to get the string executed. Usually this can be done using GroovyShell.
But since you need it for your Builder you have to do more.
ConfigSlurper#parse(Script,URL) shows the meta class stuff needed for
this once you have a Script. To get a script you can use
GroovyClassLoader#parseClass, as ConfigSlurper does, or use GroovyShell
as I mentioned before.

but ConfigSlurper looks really like what you actually want to do.

I figured that I needed to do some extra work to the text. I just wasn't sure what exactly needed to be done. I had hoped that it would be something simple, but the simple part was switching to ConfigSlurper. :)

I think I really wanted to make a builder, so I was trying to make it fit a situation that wasn't good for it.

Thanks for the help!

Chad

From forum: groovy - user

Heads-up: release of 1.6.6 and 1.7-RC-1 Friday

2009-11-25T09:32:28Z

Hi all,

Just a quick heads-up to say we plan to release Groovy 1.6.6 and
Groovy 1.7-RC-1 on Friday.

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

From forum: groovy - dev

Re: Grape Repository List Feature

2009-11-25T08:39:07Z

No idea.

On Wed, Nov 25, 2009 at 17:34, Mark Fortner <phidias51@...> wrote:

> Are there REST services for the web front ends that could be called to
> provide that information? Presumably grape would cache the information
> locally.
>
> -- Mark
>
> On Wed, Nov 25, 2009 at 8:31 AM, Guillaume Laforge <glaforge@...>
> wrote:
>>
>> On Wed, Nov 25, 2009 at 17:26, Mark Fortner <phidias51@...> wrote:
>> > Currently Grape does a good job of fetching a module from a maven
>> > repository. However, in order to do that you must know the group id and
>> > artifact id. I was wondering if there were any plans to provide a
>> > repository "list" feature with Grape that would list all of the modules
>> > in a
>> > repository?
>>
>> No plan for that.
>> That would be an expensive operation to ask Maven Central to tell us
>> all the modules available :-O
>> There are also several web frontends doing that kind of feature by the
>> way.
>>
>> --
>> 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
>>
>>
>
>
>
> --
> Mark Fortner
>
> blog: http://feeds.feedburner.com/jroller/ideafactory
>

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

From forum: groovy - dev

Re: Grape Repository List Feature

2009-11-25T08:34:10Z

Are there REST services for the web front ends that could be called to provide that information? Presumably grape would cache the information locally.

-- Mark

On Wed, Nov 25, 2009 at 8:31 AM, Guillaume Laforge <glaforge@...> wrote:

On Wed, Nov 25, 2009 at 17:26, Mark Fortner <phidias51@...> wrote:
> Currently Grape does a good job of fetching a module from a maven
> repository. However, in order to do that you must know the group id and
> artifact id. I was wondering if there were any plans to provide a
> repository "list" feature with Grape that would list all of the modules in a
> repository?

No plan for that.
That would be an expensive operation to ask Maven Central to tell us
all the modules available :-O
There are also several web frontends doing that kind of feature by the way.

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

--
Mark Fortner

blog: http://feeds.feedburner.com/jroller/ideafactory

From forum: groovy - dev

Re: Grape Repository List Feature

2009-11-25T08:31:10Z

On Wed, Nov 25, 2009 at 17:26, Mark Fortner <phidias51@...> wrote:
> Currently Grape does a good job of fetching a module from a maven
> repository. However, in order to do that you must know the group id and
> artifact id. I was wondering if there were any plans to provide a
> repository "list" feature with Grape that would list all of the modules in a
> repository?

No plan for that.
That would be an expensive operation to ask Maven Central to tell us
all the modules available :-O
There are also several web frontends doing that kind of feature by the way.

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

From forum: groovy - dev

Grape Repository List Feature

2009-11-25T08:26:36Z

Currently Grape does a good job of fetching a module from a maven repository. However, in order to do that you must know the group id and artifact id. I was wondering if there were any plans to provide a repository "list" feature with Grape that would list all of the modules in a repository?

Regards,

Mark Fortner

From forum: groovy - dev

Re: Suggestion for a Grape repository feature

2009-11-25T08:24:01Z

Merlyn Albery-Speyer schrieb:
> Hi blackdrag,
>
> The reason for the check is because there are two routes to specifying
> the attributes: one via the GrapeResolver annotation -- and in that
> case you're right, the compile enforces this; the other case is via a
> map in the Grapes annotation which allows you to specify the
> attributes without compiler checking.

ah ok, then all is fine ;)

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

From forum: groovy - dev

Re: mod_groovy?

2009-11-25T08:22:49Z

try
http://www.easygsp.com

Michael Klishin-2 wrote:

Hi,

Could anyone tell me is there any kind of mod_groovy for Apache around?
Or I have to use application server for groovlets?

--
Michael "Antares" Klishin,

http://www.novemberain.com | mailto:michael@novemberain.com

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

http://xircles.codehaus.org/manage_email

From forum: groovy - user

configslurper

2009-11-25T07:58:37Z

Hello world -

Here's an example with several environments based on which O/S is running. My question is, if an app wants to update it's version of 'images' in this example based on it's O/S, the highlighted code below does not reproduce the input properties file, but looses any reference to any other o/s other than "macosx" in this case (cos that's what it's running on for this test). Do i need something else in the withWriter clause to the output to reproduce the input properties file, but with the new value for 'images' ? Many thanx jim

/* ./path.properties file looks like this :

environments {

macosx {

home="/Volumes/UBUNTU/Groovy/ImageDev/"

images="/Volumes/UBUNTU/"

help = "${home}help.txt"

}

linux {

home="/Volumes/UBUNTU/Groovy/ImageDev/"

images="/Volumes/UBUNTU/images/"

}

} // end of environments

String pathfile = './path.properties' // non O/S specific parameters for technical issues

def config

def paths

def OSN

// Get all system properties

Properties props = System.getProperties()

// find O/S name & build a brief version of it

OSN = (String)props.get("os.name");

def tokens = OSN.trim().toLowerCase().split(' ').toList()

def osid = new StringBuffer();

tokens.each{tok -> osid << tok;}

// tell which O/S version of the environmental variables we want

println("... Support() set to use $osid")

// and load the O/S version of the environmental variables

paths = new ConfigSlurper(osid.toString()).parse(new File(pathfile).toURL()) // get o/s related path specifications

println("... config is set to use '$osid' paths at <${paths}>")

paths.each{ println "path=${it}";}

println "images path is ${paths["images"]}"

paths["images"] = "/Volumes/UBUNTU/images"

println "images path is ${paths["images"]}"

new File("./jim.properties").withWriter { writer -> paths.writeTo(writer) }

/* ./jim.properties =

home="/Volumes/UBUNTU/Groovy/ImageDev/"

images="/Volumes/UBUNTU/images"

help=/Volumes/UBUNTU/Groovy/ImageDev/help.txt

From forum: groovy - user

Re: Suggestion for a Grape repository feature

2009-11-25T07:48:00Z

Hi blackdrag,

The reason for the check is because there are two routes to specifying
the attributes: one via the GrapeResolver annotation -- and in that
case you're right, the compile enforces this; the other case is via a
map in the Grapes annotation which allows you to specify the
attributes without compiler checking.

Cheers,
Merlyn

On Tue, Nov 24, 2009 at 11:04 PM, Jochen Theodorou <blackdrag@...> wrote:

> the patch looks good to me, only one small thing... the error reporting you
> do there... isn't that part already done by Groovy? Groovy should complain
> if required attributes are not set. I did not check and maybe you just
> copied that from somewhere else in grape, but that only means that it is
> surplus code there 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
>
>
>

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

http://xircles.codehaus.org/manage_email

From forum: groovy - dev

Re: Nested class inheritance used to work

2009-11-25T04:34:01Z

If the error message is still confusing (e.g. doesn't mention static vs.
non-static), could you file a JIRA for that?

Best,
Martin

Roshan Dawrani wrote:

> Right, I missed that static/non-static thing and just tried the given
> code as is on 1.7-beta-1 thinking that is what pre milestone 1.0 was
> pointing to (given that inner class support was never in support before
> 1.7.x)
>
>
> On Wed, Nov 25, 2009 at 2:58 PM, Jochen Theodorou <blackdrag@...
> <mailto:blackdrag@...>> wrote:
>
> Roshan Dawrani schrieb:
>
> If the try the same code on 1.7-beta-1 groovyconsole, I get the
> error:
> -----------------------------------
> 1 compilation error:
>
> unable to resolve class A
> at line: 5, column: 4
> -----------------------------------
>
> In any case, can you please file a bug?
>
>
> that is fixed already, it will now compile... still it will not run,
> since moo is a static method and A not a static nested class.
>
> Also I wonder what this pre milestone 1 is... Is that before Groovy 1.0?
>
> 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
>
>
>

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

http://xircles.codehaus.org/manage_email

From forum: groovy - user

Re: where to post groovy scripts

2009-11-25T01:55:01Z

Bonjour

many thanx for that - will look again tonite. like to do documentation also but spend SO much time writing groovy apps that i rarely have time

working on a google app to auto translate ubuntu operating system messages from english to french, mais mon francais est tres mal

will encore ecrite when i have le temp

merci

jim

2009/11/25 Guillaume Laforge <glaforge@...>

Hi Jim,

If you want to contribute documentation, you can certainly register on
Confluence, to help us improve the online documentation.
And if you want to share scripts with the world (friends, colleagues,
etc), you can also use the Groovy Web Console:
http://groovyconsole.appspot.com/

Guillaume

On Wed, Nov 25, 2009 at 10:40, jim northrop
<james.b.northrop@...> wrote:
> Hi again -
> guess i am too new to understand this, but is there some place/space where i
> can upload a bunch of groovy scripts for public use ? or maybe a tutorial.
> i'm working to join confluence as someone told me it was needed.
> Any advice appreciated.
> ta
> jim

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

From forum: groovy - user

Re: HTTPBuilder multipart message

2009-11-25T01:49:32Z

Thanks for your help!

I was finally able to achive my multipart upload.
After reading through http://www.nabble.com/multipart-form-data-in-4.0-td14224819.html I used the MultipartEntityWrapper from there to wrap the httpclient 3.x multipart functionality to be used for httpclient 4.x.
Feels a bit like cheating but it worked for me :)

After putting the additional stuff (wrapper and old httpclient jar) into the classpath i was able to do:

http.request(POST) {request ->
uri.path = '/demopath'
requestContentType = 'multipart/form-data'

Part[] parts = [new FilePart("theFile", new File(args[0])),
new StringPart("action", "importZip")]

request.entity = new MultipartEntityWrapper(parts, request.params)

response.success = { resp, reader ->
....
}
}

The wrapper is missing some functionaliy regarding request.params but it worked for my usecase.

Thanks again for your help and this nice piece of software in general!

Tobias

From forum: groovy - user

Re: ConfigSlurper: several environments, several pages. How?

2009-11-25T01:45:40Z

MichaelM schrieb:
> OK, this is what I have come up with for the configuration file. It relies on
> variable "environment" being available (is this a documented feature?):

I think the documentation is missing that feature, you could fill a
request to correct the documentation. As you found yourself out (but for
others reading this) environment is a property of ConfigSlurper itself
and can be set by for example using the String based constructor. So

>> ----------------------------------------
>> config = new ConfigSlurper("test").parse(new File('config.cfg').toURL())
>> println config.baseUrl // testServer/
>> println config.pageConfig.newEmp.url // localhost/emp.jsp
>> ----------------------------------------

will use "test" for environment.

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

From forum: groovy - user

Re: where to post groovy scripts

2009-11-25T01:42:57Z

Hi Jim,

If you want to contribute documentation, you can certainly register on
Confluence, to help us improve the online documentation.
And if you want to share scripts with the world (friends, colleagues,
etc), you can also use the Groovy Web Console:
http://groovyconsole.appspot.com/

Guillaume

On Wed, Nov 25, 2009 at 10:40, jim northrop
<james.b.northrop@...> wrote:
> Hi again -
> guess i am too new to understand this, but is there some place/space where i
> can upload a bunch of groovy scripts for public use ? or maybe a tutorial.
> i'm working to join confluence as someone told me it was needed.
> Any advice appreciated.
> ta
> jim

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

From forum: groovy - user

where to post groovy scripts

2009-11-25T01:40:21Z

Hi again -

guess i am too new to understand this, but is there some place/space where i can upload a bunch of groovy scripts for public use ? or maybe a tutorial. i'm working to join confluence as someone told me it was needed.

Any advice appreciated.

jim

From forum: groovy - user

Re: Nested class inheritance used to work

2009-11-25T01:40:16Z

Yes, sounds good. So, the request for raising an issue is still valid :-)

On Wed, Nov 25, 2009 at 3:08 PM, Jochen Theodorou <blackdrag@...> wrote:

Roshan Dawrani schrieb:

Right, I missed that static/non-static thing and just tried the given code as is on 1.7-beta-1 thinking that is what pre milestone 1.0 was pointing to (given that inner class support was never in support before 1.7.x)

maybe it would be a good idea to check the static access, no need to wait till runtime.

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

From forum: groovy - user

Re: Nested class inheritance used to work

2009-11-25T01:38:35Z

Roshan Dawrani schrieb:
> Right, I missed that static/non-static thing and just tried the given
> code as is on 1.7-beta-1 thinking that is what pre milestone 1.0 was
> pointing to (given that inner class support was never in support before
> 1.7.x)

maybe it would be a good idea to check the static access, no need to
wait till runtime.

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

From forum: groovy - user

Re: External Content with BuilderSupport

2009-11-25T01:37:36Z

iamthechad schrieb:
> I can use ConfigSlurper if I change my configuration definition. I'm
> not 100% tied to what I'm using now, so it may be easier to make the
> change.
>
> I've spent enough time with this over the last couple of days that now
> I really just want to know if it's at all possible to pass a plain
> string/eternally loaded content into a builder.

ConfigSlurper does this, so it is possible.

[...]
>>> def textClosure = { "Some Entry" (property1:value1, property2: value2) }
>>> builder.foo(textClosure)
>>>
>>> because textClosure is a closure.

you should try:

def textClosure = { "Some Entry" (property1:value1, property2: value2) }
textClosure.delegate = builder

and then

builder.foo(textClosure)

or

textClosure()

depending on what you want to have.

>>> If I do this:
>>>
>>> def text = '"Some Entry" (property1:value1, property2: value2)'
>>> def textClosure = { text }
>>> builder.foo(textClosure)

text is a String, putting the curly braces around it makes it a Closure
that returns that string only. What you would need is something like:

testClosure = {
evaluate text
}

to get the string executed. Usually this can be done using GroovyShell.
But since you need it for your Builder you have to do more.
ConfigSlurper#parse(Script,URL) shows the meta class stuff needed for
this once you have a Script. To get a script you can use
GroovyClassLoader#parseClass, as ConfigSlurper does, or use GroovyShell
as I mentioned before.

but ConfigSlurper looks really like what you actually want to do.

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

From forum: groovy - user

Re: ConfigSlurper: several environments, several pages. How?

2009-11-25T01:31:49Z

OK, this is what I have come up with for the configuration file. It relies on variable "environment" being available (is this a documented feature?):

----------------------------------------
switch (environment) {
case 'dev':
baseUrl = "devServer/"
break
case 'test':
baseUrl = "testServer/"
break
default:
baseUrl = "localhost/"
}

pageConfig {
newEmp { url = "${baseUrl}emp.jsp"
}
newDept { url = "${baseUrl}emp.jsp"
}
}
----------------------------------------

MichaelM wrote:

I have a configuration file like this:

----------------------------------------
baseUrl = "localhost/"

// Override for specific environments
environments {
dev { baseUrl = "devServer/"
}
test{ baseUrl = "testServer/"
}
}

pageConfig {
newEmp { url = "${baseUrl}emp.jsp"
}
newDept { url = "${baseUrl}emp.jsp"
}
}
----------------------------------------

Read it with this script:

----------------------------------------
config = new ConfigSlurper("test").parse(new File('config.cfg').toURL())
println config.baseUrl // testServer/
println config.pageConfig.newEmp.url // localhost/emp.jsp
----------------------------------------

I understand why the last line contains localhost. But I could use some advice on how to restructure the config file so that it produces the desired results. The config file will contain 5 environments and 20 pages, so I'm trying to prevent 5x20 configuration lines.

Thanks for your suggestions.
M.

From forum: groovy - user

Re: Nested class inheritance used to work

2009-11-25T01:31:23Z

Right, I missed that static/non-static thing and just tried the given code as is on 1.7-beta-1 thinking that is what pre milestone 1.0 was pointing to (given that inner class support was never in support before 1.7.x)

On Wed, Nov 25, 2009 at 2:58 PM, Jochen Theodorou <blackdrag@...> wrote:

Roshan Dawrani schrieb:

If the try the same code on 1.7-beta-1 groovyconsole, I get the error:
-----------------------------------
1 compilation error:

unable to resolve class A
at line: 5, column: 4
-----------------------------------

In any case, can you please file a bug?

that is fixed already, it will now compile... still it will not run, since moo is a static method and A not a static nested class.

Also I wonder what this pre milestone 1 is... Is that before Groovy 1.0?

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

From forum: groovy - user

Re: Nested class inheritance used to work

2009-11-25T01:28:22Z

Roshan Dawrani schrieb:
> If the try the same code on 1.7-beta-1 groovyconsole, I get the error:
> -----------------------------------
> 1 compilation error:
>
> unable to resolve class A
> at line: 5, column: 4
> -----------------------------------
>
> In any case, can you please file a bug?

that is fixed already, it will now compile... still it will not run,
since moo is a static method and A not a static nested class.

Also I wonder what this pre milestone 1 is... Is that before Groovy 1.0?

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

From forum: groovy - user

Re: Java SDK classes start with a MetaClassImpl but it can change?

2009-11-25T01:23:09Z

codecraig schrieb:
> Ok I see that's what is happening, but why switch it from an instance of
> MetaClassImpl to ExpandoMetaClass? From what I can see MetaClassImpl
> implements MutableMetaClass (which extends MetaClass which extends
> MetaObjectProtocol) which means you can set attributes, properties, new
> methods on it.
>
> Maybe its historical and things have changed but ExpandoMetaClass is still
> being used for now? can anyone confirm this?

for one part it is historical, for the other part it is true that you
can add methods, properties and all that on when using MetaClassImpl,
but once initialize() is called the meta class is "sealed". And before
that method had been called you cannot use the metaclass to invoke
methods or use properties. ExpandoMetaClass is different, as it allows
addtions after initialize() as been called.

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

From forum: groovy - user

Re: Nested class inheritance used to work

2009-11-25T00:29:07Z

If the try the same code on 1.7-beta-1 groovyconsole, I get the error:
-----------------------------------
1 compilation error:

unable to resolve class A
at line: 5, column: 4
-----------------------------------

In any case, can you please file a bug?

On Wed, Nov 25, 2009 at 9:53 AM, John Ky <newhoggy@...> wrote:

Hi all,

I've got this code which used to work with on pre milestone 1 groovy.

public class Parent {
   public class A {
   }

   public class B extends A {
   }

   public static void moo() {
      final a = new A()
      final b = new B() // Fails here!
   }
}

Parent.moo()

but on the latest nightly, I get this:

Exception in thread "main" java.lang.NoSuchMethodError: Parent$A: method <init>()V not found
    at Parent$B.<init>(Moo.groovy)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
    at java.lang.reflect.Constructor.newInstance(Unknown Source)
    at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:77)
    at org.codehaus.groovy.reflection.CachedConstructor.doConstructorInvoke(CachedConstructor.java:71)
    at org.codehaus.groovy.runtime.callsite.ConstructorSite.callConstructor(ConstructorSite.java:43)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:52)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:192)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:196)
    at Parent.moo(Moo.groovy:11)

Cheers,

-John

From forum: groovy - user

Re: MetaClass confusion...

2009-11-24T23:45:41Z

The reason you don't have to do "p.metaClass.initialize()" explicitly is that as soon as you do "p.metaClass.speak = {-> ...}", HandleMetaClass comes into picture, switches the object's metaclass from MetaClassImpl to ExpandoMetaClass and then also intiialize it - that's why you calling it explicitly is not necessary and really has no effect.

On Wed, Nov 25, 2009 at 7:10 AM, craig w <codecraig@...> wrote:

So I'm looking at groovy.lang.MetaClass#initialize() and it says:
void initialize()

complete the initlialisation process. After this method is called no methods should be added to the meta class. Invocation of methods or access to fields/proeprties is forbidden unless this method is called. This method should contain any initialisation code, taking a longer time to complete. An example is the creation of the Reflector. It is suggested to synchronize this method.
source: http://groovy.codehaus.org/api/groovy/lang/MetaClass.html#initialize()

However, is this really true? From what I can tell it doesn't matter if I call "initialize" or not, I can add methods without calling it and I can add methods after calling it without a problem.

class Person { }

p = new Person()
p.metaClass.speak = {-> println 'i spoke' }
p.metaClass.initialize()
p.speak()

p.metaClass.blah = {-> println 'blah'}
p.blah()

...try commenting out the "p.metaClass.initialize()" method...everything still works.

is the documentation just out-of-date now? (it's groovy 1.6.5)

thanks

From forum: groovy - user

Re: Suggestion for a Grape repository feature

2009-11-24T23:04:16Z

Merlyn Albery-Speyer schrieb:
> Hey all,
>
> I've created GROOVY-3897 which enables runtime definition of Grape Ivy
> ibiblio resolvers. I've attached a patch with a tests to demonstrate
> the behaviour as well as the code that passes those tests. Please let
> me know how I could improve on this:
> http://jira.codehaus.org/browse/GROOVY-3897

the patch looks good to me, only one small thing... the error reporting
you do there... isn't that part already done by Groovy? Groovy should
complain if required attributes are not set. I did not check and maybe
you just copied that from somewhere else in grape, but that only means
that it is surplus code there 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

From forum: groovy - dev