Latest messages from our mailing-lists

User mailing-list

Re: [groovy-user] Property files in jar & ConfigSlurper
Tom Corcoran schrieb: there is a parse method that takes an URL. If you don't worry about the encoding, then you can use that. If not, then maybe you should read the script into a string and give that the parse method bye blackdrag

Re: [groovy-user] Re: Any good recent speed comparisons...
Isaac, nobody says you do bad job. People want benchmarks and you provide perfect infrastructure for that. But you should understand that for us as language/compiler/runtime developers it is permanent source of defocusing from important things to microbenchmarks. But let me repeat I love the fact that you contest exist Alex On Fri, May 16, 2008 at 7:33 PM, Isaac Gouy public.gmane.org> wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

[groovy-user] Re: Any good recent speed comparisons...
On May 15, 10:10 am, tugwilson public.gmane.org> wrote: To make the numbers as meaningless as that comment we'd have to remove all the program source code, build & run logs, and measurements; and ... iirc Groovy was also said to be fast enough for most users before the recent beta release. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Re: [groovy-user] XML processing with Groovy's different APIs
Jean-Noël Rivasseau-3 wrote: Ah! so the document references an external DTD subset? The parser will *always* read the DTD even if it's not validating. This is because DTDs can contain information which are necessary for the correct processing of the document (entity declarations, for example). You are going to have to supply the DTD to the parser. John Wilson

Re: [groovy-user] Property files in jar & ConfigSlurper
Tom Corcoran schrieb: groovy can compile classes in memory and on the fly... like it does with any .groovy file you give it. ConfigSlurper is causing this by feeding the file to our compiler I understand your explanation now about groovy property files, thanks. Reading from the jar is another issue...

Re: [groovy-user] Property files in jar & ConfigSlurper
Sounds promising. I'm not sure how to pipe the file into ConfigSlurper. I could do: InputStream is = getClass().getResourceAsStream('properties/config.groovy') but not sure how to get ConfigSlurper to read the InputStream Or is there a better way? Tom Corcoran schrieb: groovy can compile classes in memory and on the fly... like it does with any .groovy file you give it. ConfigSlurper is causing this by feeding the file to our compiler

Re: [groovy-user] XML processing with Groovy's different APIs
My document looks like: I think this is correct. I am using DOMBuilder right now, how can I pass a parser having the validation property set to true? I have tried: def reader = new FileReader(file) def document = DOMBuilder.parse(reader, true false) but it does not work (From the errors it looks like it is trying to validate against a DTD, which is not present). Jean-Noel On Fri, May 16, 2008 at 3:43 PM, tugwilson wilson.co.uk> wrote:

Re: [groovy-user] Property files in jar & ConfigSlurper
Tom Corcoran schrieb: groovy can compile classes in memory and on the fly... like it does with any .groovy file you give it. ConfigSlurper is causing this by feeding the file to our compiler bye blackdrag

[groovy-user] Property files in jar & ConfigSlurper
I have learned from this list that groovy property files are not really property files but groovy script. We have been storing them in a /properties directory like with Java properties files. I have not noticed .class files being compiled from them so am a little confused how that works. Anyway, we are packing the "property files" in a jar and are wondering how to rig ConfigSlurper to read in from a file in the jar? Thanks, Tom.

Re: [groovy-user] XML processing with Groovy's different APIs
Jean-Noël Rivasseau-3 wrote: If your XML document contains xsi:noNamespaceSchemaLocation or xsi:schemaLocation attributes and the parser's http://xml.org/sax/features/validation property is true then the parser will validate against the schema. If not you need to set the parser's http://apache.org/xml/properties/schema/external-noNamespaceSchemaLocation and/or http://apache.org/xml/properties/schema/external-schemaLocation properties. See http://xerces.apache.org/xerces-j/schema.html With XmlSlurper you can instantiate and configure the parser and then pass the configured parser to the constructor. John Wilson

[groovy-user] Potential change to Gldapo (and Grails-LDAP plugin)
Hi, I need to make a pretty drastic change to Gldapo and could benefit from some user feedback (if there are any users). This particular relates to create, moving and replacing of LDAP entries. If you are using Gldapo to do this please contact me… Or better yet join the users list (see: http://xircles.codehaus.org/lists/user-3PQF+aW3d8lnkHa44VUL00B+6BGkLq7r< at >public.gmane.org) Thanks, LD. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

[groovy-user] XML processing with Groovy's different APIs
Hello all, since yesterday I've been playing with the various APIs for reading / writing XML in Groovy. A couple of remarks and a question: * the differences between the default settings in the different APIs are not documented. For example (I may be wrong), my own experience has been that while XmlParser is namespace aware by default, XmlSlurper is not (why?) * XmlSlurper does not support the notions of text nodes, right? For example

hello, this is some text that ends here.

Using XmlSlurper, on the div element there seems to be only one child node. If I use the DOMBuilder (DOMCategory), I get all three nodes (2 text nodes and one normal node). My question is : is it possible to do schema validation (not DTD) directly in DOMBuilder, XmlParser or XmlSlurper? According to the docs, it seems that validation with these objects works only with a DTD. I am using a schema, I tried to use validation but it failed. Does that mean I have to turn validation off and use the method descri

Re: [groovy-user] Customizing GroovySh
Guillaume Laforge a écrit : I use groovy 1.5.6 and create a class that implements org.codehaus.groovy.tools.shell.Command then I construct a groovysh instance and register my command in it. Everything works very well, I can execute my command and it appears on the help. However I'm going to try groovy 1.6-beta-1 if it is even easier. || Thank you, I'm going to create the JIRA issue --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Re: [groovy-user] Customizing GroovySh
Hi Benjamin, On Fri, May 16, 2008 at 2:19 PM, Strappazzon public.gmane.org> wrote: Excellent! In Groovy 1.6-beta-1, I think it's now easier to register your own commands. Have you used that mechanism? Which version do you use? Currently, if the method is private, you obviously can't override it. But if you create a JIRA issue with such a request for improvement, it's an easy fix if it's just making the method public!

[groovy-user] Customizing GroovySh
Hi list, I currently work on a project that aims to develop a shell. I use groovySh as a base and add my own command. I already succeed in adding commands in groovysh but, now what I'd like to do is to customize the prompt and the banner message. I tried to extends GroovySh to provide my own prompt but the the method that define it is private. Is there another solution to customize the prompt and the banner without modifying groovy source code. regards benjamin --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Re: [groovy-user] Problem using GroovyInterceptable implementation from Java
Jochen Theodorou wrote: If you do consider this for Groovy 2.0 there's an odd corner case you have to look out for. If you subclass the Groovy class in Java and override the method then call the overridden method via super you need to avoid a stack overflow because of recursion. class Foo { // Groovy def bar() { } } class Bar extends Foo { // Java public Object bar() { return super.bar(); } } The stub generated for foo in Foo has to check that it has not been overridden with a Monkey Patch or Category and then, if not, execute the method which was declared on Foo (which is one of the reasons why I make these methods static). If you do a straightforward dynamic dispatch via the normal MetaClass mechanism you get infinite recursion. John Wilson

Re: [groovy-user] Oddities in the grammar that effect DSL writing
Yeah, that would feel weird to seperate c from the closure, when it really reads like the closure is passed into c. I don't think this rule would be ideal and easily mentally parseable.

Re: [groovy-user] Oddities in the grammar that effect DSL writing
melix schrieb: but in a GPath...? nodes.first.findAll{it.prop='11'}.each{println it} that would have to become: (nodes.first.findAll{it.prop='11'}).each{println it} or nodes.first.findAll({it.prop='11'}).each{println it} or it is whitespace sensitive... bye blackdrag

Re: [groovy-user] Oddities in the grammar that effect DSL writing
Russel Winder schrieb: [...] sure, I see that... but what about: foo a.prop(2/3) c { println it } is it now: foo ( a.prop ( 2 / 3 ) , c , { println it } ) ? I am not saying this or that is bad, I just want to remark, that if that is true, then we are going to add whitespace sensitivity here. bye blackdrag

Re: [groovy-user] Problem using GroovyInterceptable implementation from Java
never12 schrieb: that's because (a) it is no secret and (b) we had the guideline to let Groovy behave like Java when looking at Groovy from Java in the past. For example you don't expect 1.plus(1) in Java, when you do 1+1. bye blackdrag

[groovy-user] Re: The Groovy and Gant Subversion repositories
Ben was of the same view so he did it, the Gant repository now has a new UUID. Path: gant URL: http://svn.codehaus.org/gant Repository Root: http://svn.codehaus.org/gant Repository UUID: d02f77da-47a5-474d-b610-f18e4bea325a Apologies to anyone for whom this causes hassle, but I think this was a needed hassle.

Developer mailing-list

Re: [groovy-dev] invokedynamic: Is It What We Really Need?
Jochen Theodorou wrote: Remember this is a dynamic language and the calls are not made directly but via the MetaClass. As I describe in detail in http://docs.google.com/View?docID=ah76zbd6xsx2_9ck33c8dp&revision=_latest each method in an Ng class is identified by a unique number and is called by casting the object to CompiledNgObject and calling ng$Call with the appropriate parameters. So bar() in Foo has a different number to bar() in Bar and super.bar() in Bar results in a different method handle being used and hence a different value being passed to ng$Call. The bottom line is that the runtime system is able to call any method in the Ng class hierarchy even if that method is overridden in a subclass. When an Ng class extends a Java class the Ng class handles the calls to all the visible methods in the Java superclass(es) in its ng$Call implementations. You can interleave Java and Ng classes in an arbitrary way and the method dispatch still works. John Wilson

Re: [groovy-dev] invokedynamic: Is It What We Really Need?
tugwilson schrieb: ok... but how do you make the call then? ah, wait, you mean the methods you call are static, not the reflector method... hmm... that's something that can be tested easily, or not? how do you do super calls in static methods? I mean ok, you give the object you make the call on and all that... but: class Foo{ def bar(){} } class Bar extend Foo{ def bar(){super.bar()} } now if this would actually become: class Foo{ def bar(){} static synthetic access$bar1(Foo f){f.bar()} } class Bar extend Foo{ def bar(){access$bar1(this)} } then nothing is gained... I mean that would end up with a stack overflow, or not? bye blackdrag

Re: [groovy-dev] invokedynamic: Is It What We Really Need?
tugwilson schrieb: I don't know... for public methods there is probably no advantage at all. bye blackdrag

Re: [groovy-dev] I'll give a Groovy presentation at the Jazoon'08
Regarding putting types on functions, I used to do that for every method on every Groovy class in my project. Now, I only declare types on methods that serve as an external API. I changed my thinking after the first major refactoring I had to do. I found that most of my refactoring pain disappeared when I stop putting types everywhere. Scott Hickey Senior Consultant Object Partners, Inc. ----- Original Message ---- From: Martin C. Martin public.gmane.org> To: dev-i9PBDF1N6cxnkHa44VUL00B+6BGkLq7r< at >public.gmane.org Sent: Thursday, May 15, 2008 8:02:56 AM Subject: Re: [groovy-dev] I'll give a Groovy presentation at the Jazoon'08 Aaron Digulla wrote: No problem. And thanks for allowing us to look over your presentation before you give it. You seem genuinely interested in telling the audience what they should know if they're considering Groovy, which I suspect is why you're so willing to discuss the presentation in the first place. I think a lot of what you'

RE: [groovy-dev] I'll give a Groovy presentation at the Jazoon'08
| Different people run into different problems. That's why I'm | asking around here. How about you tell me about the problems | you have with Groovy? Well, then it wouldn't be _your_ experiences, obviously ;-) Anyway, I don't have any problems with Groovy - honestly. But I do have a whishlist, i.e. things that I would like to see although they do not hinder me when programming. - mocking ctors in MockFor and StubFor - easier way of calling the original method (think 'super') when overriding a method through the MOP - joint apidoc generation for Java and Groovy code in my project - interactive Inspector like in the ULC Admin Console and more minor enhancements that don't even bother me enough that I would invest the time to write a JIRA issue for them or fixing them myself. Ah - and a warning inside IDEA when a refactoring makes a reference switch from 'known type' (declared or inferred) to 'unknown type'. I will file a JIRA issue for that one soon. | How would you generate HTML without the "class" at

Re: [groovy-dev] Declaring multiple return types (Was: Re: [groovy-dev] I'll give aGroovy presentation at the Jazoon'08)
There are a couple ways to do this already. Ones is an inner class, something like: class City { class CityAndDistance { def City city def double distance } CityAndDistance getClosestCity() { ... } } But its pretty verbose. Another is to use Generics: Pair getClosestCity() { .. } Basically, this boils down to a notation for types that can reference other types. This seems like a straightforward thing, but then you get into all the problems that Generics have, like parameterized types. I don't know that there's a good solution for this. Best, Martin Aaron Digulla wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Re: [groovy-dev] I'll give a Groovy presentation at the Jazoon'08
It is what is returned from the body of the method. I see your point here, that the user doesn't see this when calling the method, but the IDE could analyze the method and present this type to the user (it should, really:). Eugene. On Thu, May 15, 2008 at 5:14 PM, Martin C. Martin public.gmane.org> wrote:

[groovy-dev] Declaring multiple return types (Was: Re: [groovy-dev] I'll give aGroovy presentation at the Jazoon'08)
Quoting "Martin C. Martin" public.gmane.org>: Hm... there is a feature request lurking here: class City { [City, double distance] getClosestCity() { ... } } to declare the types of the two return values (along with the information that the method returns two values and what they mean). Regards,

Re: [groovy-dev] invokedynamic: Is It What We Really Need?
I have been thinking about possible reasons why we are seeing such a different level of performance with a similar technique. I think the crucial difference may be that I am making calls to static methods in my case statements whereas the Reflector made calls to instance methods. Hotspot can immediately see that it's always safe top inline a static method. For an instance method it has to worry about subclasses overloading it (Hotspot can and does deal with this, of course, but it's logically more costly and I would imagine it delays this optimisation until it's done the cheaper optimisations). If this is the reason that I'm seeing better numbers it's entirely fortuitous. I chose static methods so that I could do super calls easier not because of any performance gain. John Wilson

Re: [groovy-dev] I'll give a Groovy presentation at the Jazoon'08
Quoting "Martin C. Martin" public.gmane.org>: "If someone criticizes you, it means that someone cares" :) Yes, I do. Regards,

Re: [groovy-dev] I'll give a Groovy presentation at the Jazoon'08
Quoting "Martin C. Martin" public.gmane.org>: I'm a very fast developer. I can write 60 lines of code per hour at 1 bug per 2'724 lines of code in the final product (that's one bug per 45 hours of work). I found that I can only do this when I move code formatting and parsing into my subconsciousness. And I can only do that when these task can be automated, which means 4-5 rules which have to apply always. No exceptions. If I omit the parens, I add another rule which means my subconscious can't cope with it anymore. It makes me slower because I notice that I have to think. I'm mentally stopping while I write or read code. At work, I noticed that a lot of developers occupy their thoughts with code formatting. They do it this way here and that way there and in the end, the code is hard to read, hard to maintain and they spent a lot of time on something that doesn't have to take any time at all. In this respect, Groovy is somewhere between Python

Re: [groovy-dev] I'll give a Groovy presentation at the Jazoon'08
Eugene Vigdorchik wrote: By the compiler, or by the user? How would a user infer the return type of something like this: def getAllConnectingCities(String origin_city) ? From the name, it's probably returning a collection. But is it a Set, a List, an array, or a hash table? Or is it returning multiple values wrapped in an Object[], say the collection along with distance of the nearest and furthest cities? Best, Martin --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Re: [groovy-dev] invokedynamic: Is It What We Really Need?
Thanks for such a detailed reply. Any idea how much faster this is than reflection? John Wilson

Re: [groovy-dev] I'll give a Groovy presentation at the Jazoon'08
Hi, It suffices to put the types on parameters only, the return type then should be inferable. (Recursive methods are an exception, but that is another story) Eugene. On Thu, May 15, 2008 at 5:02 PM, Martin C. Martin public.gmane.org> wrote:

Re: [groovy-dev] I'll give a Groovy presentation at the Jazoon'08
Aaron Digulla wrote: No problem. And thanks for allowing us to look over your presentation before you give it. You seem genuinely interested in telling the audience what they should know if they're considering Groovy, which I suspect is why you're so willing to discuss the presentation in the first place. I think a lot of what you've experienced is exposure to a different culture. I always find this opens my eyes: things I'd taken for granted as positives in my old culture are now seen as both good and bad. I used to believe that static typing meant increased productivity, because the compiler could catch problems and save me lots of debugging time. But after using a number of dynamic languages, I can see the costs: reading C++ or Java code now looks like talking to a child, since you have to spell out every little thing, even things that should be obvious. I've gotten into a habit of putting types on most function declarations, both arguments and return. A function declaration is a uni

Re: [groovy-dev] I'll give a Groovy presentation at the Jazoon'08
Quoting Tom Nichols public.gmane.org>: I did :) Jochen just told me that I can use "myList.each() {...}". There are two reasons why I do this: - Consistency (I never have to think whether to omit the parens or not). That means I can store "typing macros" in my fingertips. - The parens are a good visual clue for "this is a method call" (and not a property access). Again, my eyes are trained for these and my brain gets a pre-processed version when I read code - I don't have to "read" the line; I simply somehow "know" that it's a method call. Regards,

Re: [groovy-dev] I'll give a Groovy presentation at the Jazoon'08
Quoting Jochen Theodorou public.gmane.org>: Yeah, these pages ("Reasons not to use Groovy" and "What's Wrong With Groovy") are crap. I was trying to sum up a few points when other languages would be more suitable or stuff where Groovy is weak but what I got is ... uh ... well ... yeah. Anyone got any points I should mention? Times when you felt Groovy just not adequate for the task? If not, I'll just drop these two. Regards,

Re: [groovy-dev] I'll give a Groovy presentation at the Jazoon'08
Aaron Digulla wrote: I think the problem here may be more a lack of documentation than anything else. The rule is pretty simple: if an identifier is followed by a {, then the identifier is considered a function that takes a single argument, the Closure. (I can't remember whether the { has to be on the same line as the identifier or not.) It takes a little getting used to, but I think its measured in days. As Dierk has said, this hasn't really caused lasting confusion for most people. Best, Martin --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Re: [groovy-dev] I'll give a Groovy presentation at the Jazoon'08
How do you call the 'each' method on iterable types? Do you do this every time? myList.each ({ ... }) That would get annoying quickly I think. I always figure, if it has a curly brace after the object.call, then it is automatically a method with parens omitted. I learned that on my first day of looking at Groovy, and since then I don't think I've ever mistaken a method call for a property. The reduction of symbols definitely makes the code easier to read (and write, IMO). I guess it is all very subject to personal preference. On Thu, May 15, 2008 at 7:50 AM, Aaron Digulla public.gmane.org> wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Re: [groovy-dev] Groovy Build System
Hans Dockter schrieb: I have a VDSL box in front of my house, so I could be much faster... well, there are different reasons I use the current conncetion and have not switched yet hehe, true bye blackdrag

Re: [groovy-dev] I'll give a Groovy presentation at the Jazoon'08
Quoting "Martin C. Martin" public.gmane.org>: You're right. I wanted to avoid doing a second "what's great about groovy" presentation (Ted Neward already does that on Monday and I probably can't compete with him :) and while doing so, I went too far. Thanks for pointing that out. Regards,

JSR mailing-list

Groovy 1.5.6 is out!
Hi all, G2One and the Groovy development team is pleased to announce the release of Groovy 1.5.6, a bug fix release for the stable Groovy 1.5.x branch. A regression introduced in 1.5.5 was fixed, and 35 bugs have been resolved (generics, MOP, and joint compiler issues, better line information for IDE support, etc) As usual, you can download the latest Groovy dustribution here: http://groovy.codehaus.org/Download And read the change log to know all the details there: http://jira.codehaus.org/browse/GROOVY?report=com.atlassian.jira.plugin.system.project:changelog-panel Enjoy!

Fwd: final Groovy JSR?
Wasn't delivered. ---------- Forwarded message ---------- From: Bill Shannon public.gmane.org> Date: Sat, Apr 5, 2008 at 12:40 AM Subject: Re: final Groovy JSR? To: Guillaume Laforge public.gmane.org> Cc: jsr-241-comments-vP450+ZD9pU< at >public.gmane.org, Groovy JSR public.gmane.org> Guillaume Laforge wrote: But what if the library is compiled by Foo's Groovy compiler and my program using the library is compiled by Bar's Groovy compiler? You have to decide whether this is important and/or likely. I agree you can probably ignore this for the first version. Will this get any easier in Java SE 7 with the new dynamic language bytecode?

Fwd: final Groovy JSR?
Wasn't delivered. ---------- Forwarded message ---------- From: Bill Shannon public.gmane.org> Date: Fri, Apr 4, 2008 at 11:59 PM Subject: Re: final Groovy JSR? To: Guillaume Laforge public.gmane.org> Cc: jsr-241-comments-vP450+ZD9pU< at >public.gmane.org, Groovy JSR public.gmane.org> Guillaume Laforge wrote: Yes, exactly. I think it would be better if you did, but it's up to you to decide. You're allowed to make that choice. It's up to your expert group to decide whether that's a good choice. Personally, I think this might be acceptable for a first release, but long term it will limit acceptance of Groovy. But you should work through the scenarios for how you expect people to use Groovy to see if it will be an issue for you. For example, do you expect people to write libraries using Groovy, which they would distribute as jar files? We include them in the TCK User's Guide. Let me f

Re: final Groovy JSR?
Yes, for sure, conceptually speaking, this would be desired. For Java, this is simpler as a call to a method is directly encoded in the bytecode. No intermediary layer of indirection. It then just depends on the runtime part (JDK classes, third party libraries, etc) But for a dynamic language, in the bytecode you'll find some calls to utility classes handling the double dispatch. Some of them are public APIs (which will be part of the JSR), but others may be present that are specific to each implementation. So we'll have to think deeper as to what we really want to make portable or not. Tricky issue :-) Right. This has always been possible (as long as you have the Groovy runtime on your classpath). We can seamlessly integrate with Java, or any other alternative language for the JVM. But the problem comes when we have to be compatible between different implementations of Groovy. At the basic object level, things are just fine, but it's when you get into metaprogramming techniques that this may be more prob

Re: final Groovy JSR?
Bonjour Liz, On Wed, Mar 26, 2008 at 11:37 AM, Liz M Kiener public.gmane.org> wrote: Alright, I saw it. It'll take me some time to get the EDR finished, and it won't be before JavaOne. Yes. Yup, I saw that, this is handy. Merci beaucoup :-)

Re: final Groovy JSR?
Hi Bill, Thanks a lot for your explanations. I haven't been able to answer earlier, I'm sorry. Some comments inline. On Sat, Mar 22, 2008 at 8:24 PM, Bill Shannon public.gmane.org> wrote: What do you mean by language/compiler portion, and runtime portion exactly? I just want to be sure I understood correctly. For the language part, we need to explain the semantics of the language, its grammar, etc. For the runtime part, you mean things like the libraries? ie. a closure class, a GString class, etc. Is that what you meant? Okay, it's up to us to decide the level of integration the spec mandates or not for a language to be considered a valid Groovy implementation. Furthermore the TCK will help ensure this. Ok, that makes perfect sense. Back on the level of integration mentioned above, and on this portability / interoperability aspect, Groovy mandates a seamless integration with Java. But does it mean we'd also mandate a perfect interoperability with other Groovy implementatio

Re: final Groovy JSR?
Hello Bill, On Fri, Mar 21, 2008 at 7:25 PM, Bill Shannon public.gmane.org> wrote: Very good question. Actually, after a long period of hibernation on the JSR front, we're resuming work on it in the upcoming months. But we'd be happy to have some guidance to the steps to follow, and details of the key deliverables that are expected to ship with the JSR. So far, the RI is there, of course, in the shape of Groovy 1.5.4. The TCK is not split from the Groovy test suites, so we'd need to find an easy way for people to reuse it if they want to develop a compatible Groovy language. On the spec side, we have the language grammar in an EBNF and diagram form, but what is still missing is the writing of the formal specification document, beyond our online documentation or the books we've written on the topic.

Re: [groovy-dev] Tentative Roadmap
On Dec 17, 2007 10:25 AM, Alexandru Popescu ☀ gmail.com> wrote: You're welcome :-) At least, it's not in contradiction with the roadmap! Agreed, this is what the 1.5.x releases are for. It's going to be a long process I suspect, as various experiments will have to be done, lots of discussions, a nice general proposal of what we really want, etc. So it's something that is going to be done in parallel to the progress we make in 1.x. I tried to put certain features at certain milestones, but we can certainly reorder the priorities. I've put multiple assignments early in the roadmap because we had promised them in 1.1/1.5, but as they're certainly not critical, we can postpone them to a latter release, it's not really critical. In the new features, there are things which should be discussed for inclusion or not. For instance, anonymous inner classes, nested classes and co. Initially, in the early days of Groovy, we didn't want to support them because we found them ugly, and

Tentative Roadmap
Dear Groovy developers, Now that we have released 1.5, it is time to think about the future of Groovy, by discussing its roadmap. After some discussions at GDC#4 ( http://docs.codehaus.org/display/GroovyJSR/GDC4+Discussions), on the lists, and elsewhere, we've listed possible improvements and new features. Jochen and myself compiled a tentative roadmap this weekend, taking these ideas into account and trying to lay them out across potential release numbers. This is a tentative roadmap. Certain features can be discussed, whether we do want them or not. And there's room for moving features from one to another release. New ideas missing can also be introduced. So it's still pretty open at the moment. Note that the roadmap can change across the course of time according to the progress (or lack thereof) we make on the GEPs (Groovy Extension Proposals). It is not set in stone today, even after our upcoming discussions. The GEPs will drive us through the releases. It is very important that we try to clearly de

What's new in Groovy 1.5?
Hi all, After the announcement of the release of Groovy 1.5, as promised in the release notes, here's a detailed article on what's new in Groovy 1.5. Read it on InfoQ: http://www.infoq.com/articles/groovy-1.5-new

Groovy 1.5 is there!
Hi all, I'm very pleased to announce the release of Groovy 1.5. You can read the release notes there: http://docs.codehaus.org/display/GROOVY/2007/12/07/Groovy+1.5+released An upcoming article on InfoQ will give you a more in-depth overview of this new version. Thanks a lot to everybody: developers, contributors, users. Without you, Groovy wouldn't be the great dynamic language it is today.

Release candidate 2 is available!
Dear all, The Groovy development team and G2One , the Groovy & Grails company, are happy to announce the new milestone of Groovy: the second release candidate is here. Just a few weeks after the first release candidate, this new version focused mainly on bug fixing, ironing out the Swing console with a nice new icon toolbar and the interactive shell, and the XML handling. You can have a closer look at the JIRA issuesfor more detailed information and you can download Groovy 1.1-rc-2 from the usual place. Apart from these bugs and little improvements, we kept on increasing the performance of Groovy. As an informal benckmark, we measured the time taken by our test suites to run, and for instance, according to the Grails team, the Grails test suites executed about 40% faster with Groovy 1.1-rc-2 than with Groovy 1.1-rc-1, of course, depending on your project

Groovy 1.1-beta-3 released, RC-1 and 1.1-final around the corner
Dear Groovy friends, I've blogged about the new here: http://glaforge.free.fr/weblog/index.php?itemid=222&catid=2 and there: http://docs.codehaus.org/display/GROOVY/2007/09/20/Groovy+1.1-beta-3+released%2C+RC-1+and+1.1-final+around+the+corner But here it is: Groovy 1.1-beta-3 is there, paving the way for an RC-1 in the following weeks, and if all goes well, for 1.1-final in October, right in time for the Grails eXchange conference that takes place in London. This conference will also be the opportunity for the Groovy developer team to meet for the fourth Groovy Developer Conference! With Groovy 1.1 released by then, it'll be time to think about what's going to happen for the next major version of Groovy. Before going through the new release, let me recap some of the nice things that have been happening lately around Groovy: * JetBrains released a second milestone to the wonderful Groovy & Grails IntelliJ IDEA plugin, so be sure to check it out, as you'll feel at ease developing Groovy with all the

how to make new specification request.
i'm working in web application projects using JSF . i'm asked from team manager to write "module specification request" for every web module. can anybody tell me what the content of any specification request document.

how to maike

get scripting engine by file extension
Hello! I have an application where I use JSR-223 for evaluating the scripts, and I use file extension for identifying the scripting engine that is required to evaluate the script: ScriptEngineManager scriptEngineManager = new ScriptEngineManager(); ScriptEngine engine = scriptEngineManager.getEngineByExtension("groovy"); With groovy-1.0 it works fine. but with groovy-1.1-beta2 this code throws a following exception: Exception in thread "main" java.lang.IncompatibleClassChangeError: Found interface groovy.lang.MetaClass, but class was expected at com.sun.script.groovy.GroovyScriptEngine.( GroovyScriptEngine.java:63) at com.sun.script.groovy.GroovyScriptEngineFactory.getScriptEngine( GroovyScriptEngineFactory.java:87) at javax.script.ScriptEngineManager.getEngineByExtension( ScriptEngineManager.java:275) at And in the version 1.0 there really was "public abstract class MetaClass" which is now "public interface MetaClass extends MetaObjectProtocol"

Groovy 1.1-beta-2 released!
Dear community, The Groovy team is pleased to announce the release of Groovy 1.1-beta-2, yet another step on our aggressive roadmap towards the release of Groovy 1.1 in October. For this release, I would like especially to highlight two key contributions to the project: * First of all, after we've added Java 5 annotation support in Groovy 1.1-beta-1, this time, it was generics' turn. Thanks to the help of some JBoss developers who've integrated Groovy in JBoss Seam, we've been able to test our support for annotations and generics, and to make sure we would release a quality milestone to our users. Groovy is the first alternative dynamic language for the JVM that supports annotations and generics, so that you can integrate Groovy with any Enterprise application frameworks like EJB 3 / JPA, JBoss Seam, Google Guice, Spring, etc. * Secondly, I'm very happy to report the contribution of JetBrains to the development of Groovy. While working on the IntelliJ IDEA plugin for Groovy and Grails, the talentu

Groovy 1.1-beta-1 released with annotation support
Dear all, After Groovy was awarded the first prize of the JAX conferencein Germany last week for being the *most innovative and creative project in 2007 in the Java community*, we're pleased to announce the *release of Groovy 1.1-beta-1*. This release is the first beta release after the release of Groovy 1.0. But it's a very important release as we've been working on key features putting Groovy clearly as the *de facto enterprise scripting solution*. Indeed, Groovy is now the first and sole alternative language for the JVM that *supports Java 5 annotations*. Groovy 1.1-beta-1 also supports Java 5 *static imports*. You can now use Groovy to write your EJB 3 / JPA beans, to wire your components with Google Guice, to mark your services transactional

Re: Fwd: JavaOne EG Meeting Room
Will there be any conference phone facilities, as I'll be in the UK that day Jez.

RE: Fwd: JavaOne EG Meeting Room
I'll be there and happy to meet everybody. Guillaume, I guess I'm not yet an official member of the JSR expert group. Would you mind promoting me so? ;-) cheers Dierk --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email

Fwd: JavaOne EG Meeting Room
For those who will be at JavaOne this year (Groovy / Grails developers and JSR EG members), we might have a room to make a quick meeting at the Argent hotel if needs be. ---------- Forwarded message ---------- From: Liz M Kiener public.gmane.org> Date: Mar 22, 2007 6:36 AM Subject: JavaOne EG Meeting Room To: SPECLEADS-vP450+ZD9pU< at >public.gmane.org Hello All - The PMO is pleased to offer you once more this year a room at the Argent Hotel for EG meetings during JavaOne. The room will be available all week until Fri 11 May on a first come first served basis. You can schedule the room by sending me email with date and time you would like. Kind regards, Liz :-)