gmane.comp.lang.groovy.user

Re: [groovy-user] Date.format convenience methods

Guillaume Laforge — 2008-10-06T14:36:37

Great job, Tom, thanks a lot! On Mon, Oct 6, 2008 at 4:19 PM, Tom Nichols public.gmane.org> wrote:

Re: [groovy-user] Date.format convenience methods

Tom Nichols — 2008-10-06T14:19:51

Added a static Date.parse( pattern, input ) method in r.13699. Please yell if I break anything -- A lot of unit tests seem to be failing for me, even on a clean checkout -- Windows :( Also, I'd like to get a tally of who thinks the name (or format) should be changed for the "quickie" Date format methods. I'll reiterate what stands right now: date.dateString // uses DateFormat.getDateInstance( SHORT ) - dd/MM/yy in en_UK date.timeString // uses DateFormat.getTimeInstance( MEDIUM ) - HH:mm:ss date.dateTimeString // uses DateFormat.getDateTimeInstance( SHORT, MEDIUM ) I think the other proposal was to use "format..." for all of the method names like so: date.formatDate() date.formatTime() date.formatDateTime() Again, my main reason for choosing properties was to aid readability in GStrings like "Today's date is ${date.dateString}" versus "Today's date is ${date.formatDate()}" but if the majority likes the "format.." convention better I can switch it. If there isn't more significant discussion on this (or argument on why there should be additional DGM methods) I'll consider this done and close the JIRA issue. Thanks!! -Tom On Thu, Oct 2, 2008 at 3:31 PM, Tom Nichols public.gmane.org> wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

[groovy-user] Re: Gant and Gradle

Hans Dockter — 2008-10-06T11:25:25

Hi, On Oct 4, 2008, at 11:07 AM, Russel Winder wrote: Maven unfortunately does not use a DAG. This is another reason for its inflexibility IMO. I would say that Gant uses an implicit DAG created at runtime. This is what the 'depends' call is all about, isn't it. To me this is the same way as Ant is doing things. This is a very valid point. Therefore we will put a lot of effort into modularization soon. Definitely in terms of size and dependencies (see above). Do you also see a difference in regard to coding? I think it is time for Groovy (I don't know the Grails build) to show the world by its build the advantages of a Groovy based internal DSL :) - Hans -- Hans Dockter Gradle Project lead http://www.gradle.org --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Re: [groovy-user] Groovy as arithmetic expression evaluator?

Jochen Theodorou — 2008-10-05T13:27:32

HamletDRC schrieb: ModuleNode#addStaticImportClass(importClassString, classNode) bye blackdrag

RE: [groovy-user] Gant and Gradle

David Sills — 2008-10-04T15:37:10

Russell: Your proposal as to the futures of Gant and Gradle seems very reasonable to me. I see the advantages of both, so long as they don't tend toward each other in a vain attempt to be all things to all people. Repositioning Gant as principally a scripting framework for Ant tasks and Gradle as principally a build framework seems like a reasonable development given the lightweight/heavyweight description you supply. Of course, there will be folks who will be able to use Gant as a build framework for simple cases, which is perfectly fine, too; just as there are those who feel it is appropriate to use a business card to spread jam on toast if a knife isn't ready to hand - and long may they do so! :) My $0.02. David Sills --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

[groovy-user] Re: [grails-user] Gant and Gradle

Bashar Abdul-Jawad — 2008-10-04T15:29:47

This comparison sounds to me exactly like the one between Ant and Maven. Maven and Ant both serve different purposes - Gant to me sounds just like Ant while Gradle sounds like Maven. The solution ? continue to develop both independently - Gant should focus on being a build scripting tool while Gradle should focus on being a project management tool. Add support to running Gant scripts in Gradle - just like Maven supports running Ant tasks. Bashar Russel Winder wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

[groovy-user] Gant and Gradle

Russel Winder — 2008-10-04T09:07:37

Please excuse the very wide initial circulation of this, but I want to make sure people are aware that there is a debate that might affect them. I suspect the best place for the debate is the Gant Users email list, so if people could be careful about which list they reply to when replying then people not interested in the debate will not get flooded

Re: [groovy-user] Groovy as arithmetic expression evaluator?

Guillaume Laforge — 2008-10-04T08:12:33

Hi Hamlet, You can use the technique illustrated at the bottom of this class: http://code.google.com/p/testngroove/source/browse/trunk/src/main/org/codehaus/groovy/testng/GroovyTestNG.java#205 And use module.addStaticImportClass() On Sat, Oct 4, 2008 at 4:02 AM, HamletDRC public.gmane.org> wrote:

Re: [groovy-user] Groovy as arithmetic expression evaluator?

Robert Fischer — 2008-10-04T03:47:13

There's the concept of mix-ins, but they're not in general release yet (I think). ~~ Robert. HamletDRC wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Re: [groovy-user] Groovy as arithmetic expression evaluator?

HamletDRC — 2008-10-04T02:02:25

Is there a way to cleanly add a static import for Math other than just appending "import static java.lang.Math.*" to the front of the groovyshell input? glaforge wrote: ----- -- Hamlet D'Arcy

Re: [groovy-user] Date.format convenience methods

Tom Nichols — 2008-10-04T00:31:21

I see. I'd still argue cases like this are better suited for a mixin, or category. It's not too difficult to do with plain GregorianCalendar either. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Re: [groovy-user] Date.format convenience methods

Luke Daley — 2008-10-03T10:58:15

+1 -- LD. On 03/10/2008, at 6:35 PM, "Graeme Rocher" public.gmane.org> wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Re: [groovy-user] Date.format convenience methods

Paul King — 2008-10-03T23:39:52

I think he is referring to something like .midnight() which would take a given date and effectively zero off hours, minutes and seconds (in the current timezone). You could then add or subtract 1. Paul. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Re: [groovy-user] Cannot use Map to "extend" a Java inner class

Paul King — 2008-10-03T23:03:36

Yes, I have a patch somewhere which at least partially fixes this. Didn't get time to test it properly, so saved it as a patch locally before rolling back to work on other things. I'll see if I can find it. Paul. Roshan Dawrani wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Re: [groovy-user] Closure does not have scope precedent over local method?

Roshan Dawrani — 2008-10-03T18:00:50

Hi, I have now opened an issue for the issue relating to a closure parameter not having scope precedent over local method - http://jira.codehaus.org/browse/GROOVY-3069 rgds, Roshan On Thu, Oct 2, 2008 at 9:30 AM, Roshan Dawrani public.gmane.org>wrote:

Re: [groovy-user] Cannot use Map to "extend" a Java inner class

Roshan Dawrani — 2008-10-03T17:34:05

Hi, The source code that groovy is internally generating for the proxy class (for the map extending the inner class "TestInner.Inner" in the groovy code) is as follows: --------------------------------------------------------------------------------------------------------- class TestInner$Inner_groovyProxy extends TestInner$Inner { private closureMap TestInner$Inner_groovyProxy(map) { super() this.closureMap = map } java.lang.String debug() { this.< at >closureMap['debug'] () } } new TestInner$Inner_groovyProxy(map) --------------------------------------------------------------------------------------------------------- And it is giving a compilation error as the name of the class has a "$" symbol in it. If the maps can extend classes/abstract classes to provide the implementation and inner classes need to be supported, then naming of the inner classes needs to be handled appropriately. rgds, Roshan On Fri, Oct 3, 2008 at 10:55 PM, Mingfai public.gmane.org> wrote:

Re: [groovy-user] Cannot use Map to "extend" a Java inner class

Mingfai — 2008-10-03T17:25:55

tried. it doesn't work, too. http://jira.codehaus.org/browse/GROOVY-3068 On Sat, Oct 4, 2008 at 1:07 AM, Guillaume Laforge public.gmane.org>wrote:

Re: [groovy-user] Cannot use Map to "extend" a Java inner class

Guillaume Laforge — 2008-10-03T17:07:56

At first sight, it looks like a bug, worth a JIRA. I haven't tried, but perhaps a workaround could be to try aliasing the import of that inner class with import foo.TestInner.Inner as MyInner, and do def inner1 = [debug: { "outer debug 1" }] as MyInner. Dunno if that works. On Fri, Oct 3, 2008 at 7:03 PM, Mingfai public.gmane.org> wrote:

[groovy-user] Cannot use Map to "extend" a Java inner class

Mingfai — 2008-10-03T17:03:55

i'm not sure if using a Map to "extend" a Java class is an officially supported feature anyway. The doc only say it can be used to implement interface. Say, for the following Java: public class TestInner { public String debug(){ return "outer debug"; } public class Inner { public String debug(){ return "inner debug"; } } } The following does work: def inner1 = ['debug':{return "outer debug 1"}] as TestInner println inner1.debug() But not : def inner2 = ['debug':{return "inner debug 1"}] as TestInner.Inner println inner2.debug() There is compilation error. Caught: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Error casting map to TestInner$Inner, Reason: Error creating proxy: startup failed, Script1.groovy: 1: unexpected token: $ < at > line 1, column 16. 1 error JIRA it as bug or request for new feature? :-) regards, mingfai

Re: [groovy-user] London GGUG meeting last evening -- Groovy strategy for parallelism

Andres Almiray — 2008-10-03T16:36:09

Peter Ledbrook-2 wrote: We do have some abstractions provided by Swing(X)Builder already (edt, doLater, doOutside, withworker), but I agree that an actor based library would boost concurrent programming, not just for Swing apps :-) Peter Ledbrook-2 wrote: See here for some examples http://groovy.dzone.com/news/concurrency-jsr-166y-meets-gro

Re: [groovy-user] closure issue in GroovyTestCase

Jochen Theodorou — 2008-10-03T16:15:12

Haotian Sun schrieb: you tried to execute the closure classas junit test. You should not do that. Look at where you collect the tests and how you do that and fix that part ;) bye blackdrag