headers
Guillaume Laforge | 9 Feb 19:09
Picon
Gravatar

[groovy-dev] [ANN] Groovy 1.8.6 released

Hi all,

The Groovy development team is pleased to announce the release of Groovy 1.8.6.

Groovy 1.8.6 is a maintenance release essentially, with a few minor improvements and new features.
You can see the details in the JIRA release notes here: 
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10242&version=18245

You can download Groovy 1.8.6 in the Download section of the Groovy website: 
http://groovy.codehaus.org/Download

Thanks a lot to all those who contributed to this release!

Next in line should be a new beta of Groovy 2.0 ;-)

--
Guillaume Laforge
Groovy Project Manager
SpringSource, a division of VMware


Permalink | Reply | 0 comments |
headers
Russel Winder | 8 Feb 18:58
Picon
Gravatar

[groovy-dev] Java 8 (and beyond)

Hi,

LJC (in the person of Martijn Verburg; LJC is a JCP EC member) is trying
to get people to start using the Java 8 snapshots so as to put in place
a reasonable testing regime, and hopefully ensure a very successful Java
8 launch.

Java 8 offers the possibility of being an even bigger revolution in Java
than Java 5.  It is therefore fairly mandatory that the release is a
smooth one -- unlike the Java 7 release.

I am wondering if there is any way that, if we can get a reasonably flow
of Java 8 snapshots in place, whether Groovy, GPars and Gradle can get
Java 8 as a CI component alongside the Java 7, 6, ... ones?  Is this
something that is viable?

--

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder <at> ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@...
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Permalink | Reply | 1 comment |
headers
Arturo Herrero | 5 Feb 21:49
Picon
Gravatar

[groovy-dev] Error with documentation font size


Hey,
what

happens

with

this

documentation

page?

*http://groovy.codehaus.org/api/org/codehaus/groovy/runtime/DefaultGroovyMethods.html*

--
View this message in context: http://groovy.329449.n5.nabble.com/Error-with-documentation-font-size-tp5458685p5458685.html
Sent from the groovy - dev mailing list archive at Nabble.com.

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

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 1 comment |
headers
Tim Yates | 1 Feb 17:53
Picon
Gravatar

[groovy-dev] Adding intersect on lists of things

I was looking in to adding an intersect method to lists of things, so that:

assert [ [ 1, 2 ], [ 2, 3 ], [ 2, 4 ] ].intersect() == [ 2 ]

And then you don't need to get your lists into 2 separate variables in order to perform an intersection on them.

Working with lists of lists was fine with the function definition in DGM as:

    public static <T> Collection<T> intersect( List<Collection<T>> self ) {
      ...
    }

However, then of course, there is lists of Maps to consider (as there is an intersect method already in for maps)

This would need to be defined as:

    public static <K,V> Map<K,V> intersect( List<Map<K,V>> self ) {
      ...
    }

However, this doesn't work as at runtime, java cannot choose between the two methods) once the generics have been erased...

So, what would people do in this situation?

As I see it, there are 3 options:

1)  Write the method so it takes a List, and returns an Object and uses introspection to see if it is dealing with a List of Maps or a List of Lists
2)  Write an listIntersection() method and a mapIntersection() method
3)  Don't bother doing it at all as it's problematic and will almost certainly make Cédric's job harder down the line

Any other ideas, or suggestions of a route that could be taken?

Tim

Permalink | Reply | 0 comments |
headers
Guillaume Laforge | 1 Feb 12:38
Picon
Gravatar

[groovy-dev] Groovy 1.8.6 targeted for Thursday 9th

Hi developers,


We're targeting the release of Groovy 1.8.6 for Thursday 9th.
We'll create a release branch on Tuesday, to freeze the code, and release a snapshot in our snapshot repository, for those who want to test this snapshot with their respective projects, tools and frameworks.
If you've got a few things in the pipeline, this is the time to see if you want to integrate that in 1.8.6 before the release.

Thanks for your attention and happy coding :-)

--
Guillaume Laforge
Groovy Project Manager
SpringSource, a division of VMware


Permalink | Reply | 14 comments |
headers
Martin Janicek | 17 Jan 13:57
Picon
Favicon

[groovy-dev] CompilationUnit - Recompiling sources

Hi guys,

could anyone help me with a following problem? I'm currently working on 
groovy support for an IDE and I need to recompile one source file 
somehow. The use case is that when a user is editing source code, we 
need to recompile changed sources so the IDE could use newly added (or 
changed) code to provide code completion and so on.

Typically the IDE is recompiling/indexing whole source base after the 
start-up. We are using CompilationUnit for this (concretly addSource and 
compile methods), which works just fine. After this I want to have the 
same compiled code base collected in CompilationUnit and the only thing 
I want to do is propagate user changes from the edited source file and 
recompile them again. But I can't find a way how to do so.

I expected that there will be something like recompile method directly 
inside of CompilationUnit, but I was wrong. And when I tried to call 
compile with a changed sources, the changes has not been propagated and 
recompiled at all. I found that there is a possibility to put 
GroovyClassLoader as a constructor parameter for CompilationUnit. And 
there is a recompile method inside GroovyClassLoader, but how should I 
use it properly?

I'm quite sure that there is some easy way to do this and I'm just 
missing it (and unfortunately the documentation isn't as helpful for 
this kind of tasks).

Btw: Please tell me if I'm writing to the wrong mailing list :]

Best regards
Martin

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

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 10 comments |
headers
Gerd Aschemann | 13 Jan 12:14

[groovy-dev] RFE: Extend "initial" java class path of groovy/startGroovy ...

Hi,

I posted this some days ago to the groovy-user list. Maybe there is no
better way to extend the initial Java classpath in a better way? Would
you mind do treat my proposal as Request for Enhancement?

Regards,
  Gerd

----- Forwarded message from Gerd Aschemann <gerd@...> -----

I would like to extend the initial -classpath which is used for the
java call within the groovy (or startGroovy) shell script. Is there a
"standard" way to do so? The startGroovy script only forwards the
groovy-x-y-z.jar to the JVM, as far as I can see.

Setting of $CLASSPATH or using the -cp / -classpath leads to a class
path which is forwarded to the Groovy starter class. In my case it is
necessary to make java initially load some classes in the root class
loader: In fact I would like to use the JacORB CORBA implementation
which interferes with org.omg... classes from the default Java rt.jar
if loaded by a subsequent class loader as with the Groovy startup
classes: It is essential to have the jacorb.jar in the initial
classpath of the Java call. Putting the jacorb.jar to ~/.groovy/lib or
something similar loaded from the groovy-starter.conf didn't help
either.

My current work around is the following patch to startGroovy and
setting GROOVY_BOOT_CLASSPATH with a proper value:

diff -bc /opt/groovy/current/bin/startGroovy{.~1~,}
*** /opt/groovy/current/bin/startGroovy.~1~     Fri Dec 23 15:40:16 2011
--- /opt/groovy/current/bin/startGroovy Fri Jan  6 15:33:11 2012
***************
*** 129,134 ****
--- 129,138 ----
  fi
  STARTER_CLASSPATH="$GROOVY_HOME/lib/groovy-1.8.5.jar"

+ if [ -n "${GROOVY_BOOT_CLASSPATH}" ] ; then
+     STARTER_CLASSPATH="${STARTER_CLASSPATH}:${GROOVY_BOOT_CLASSPATH}"
+ fi
+
  # Create the final classpath. Setting a classpath using the -cp or -classpath option means not to use the
  # global classpath. Groovy behaves then the same as the java interpreter
  if [ -n "$CP" ] ; then

But maybe there is a better solution?

Regards,
  Gerd

--
Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas)
+49/173/3264070 -- gerd@... -- http://www.aschemann.net

----- End forwarded message -----

--
Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas)
+49/173/3264070 -- gerd@... -- http://www.aschemann.net
Permalink | Reply | 0 comments |
headers
Sergey Bondarenko | 12 Jan 00:28
Picon

[groovy-dev] defect in Groovy documentation page rendering

Good evening,



Could someone please take a look at the following two pages with Groovy documentation?


The first page contains unexpected ?? (double question mark) sequences in the code examples, whereas the second one contains correct code without these characters.
Does anybody know what can be the cause of the issue?

It looks like something is wrong in HTML output. You can find example in attached screenshot.





Thanks,
Sergey
Permalink | Reply | 3 comments |
headers
Jonathan Tew | 11 Jan 15:07
Picon

[groovy-dev] Secure Uberspector for Groovy?

Hi,

I'm considering replacing Velocity within a project that I'm working on with Groovy, but I'm stuggling with the security mechanisms available for Groovy.  So far what I've tested is the following methods for security:

- java.policy file to lock down the permissions of the code base (good, but not perfect)
- SecureASTCustomizer (good for blocking certain expressions at compile time, but easy to get around at run-time unless you employee draconian restrictions on the language features)

One thing that I'm missing is the concept of the Uberspector that Velocity implements.  This is basically a class that is called before each .invoke() on an object.  The inspector object gets a chance to see:

- Instance object
- Arguments

It can then decline allowing it to execute.  This seems like a great way to prohibit the execution of certain objects and provide the missing link to securing Groovy for usage of user based scripts without having to remove tremendous amounts of functionality like closures, method definitions, etc.  Would this be the trifecta of security for Groovy user scripts within an application?

Searching through the source code there is a reasonable amount of choke points to implement such a strategy with a lot of it revolving around the InvokeHelper class.

What do you guys think about this concept? 
Is this something that would be compatible with Groovy's go forward language strategy?

I'll be glad to spend the development time implementing the concept, but want to make sure this is something that is needed and wanted.  Your feedback is greatly appreciated.

Thanks,
Jonathan

Permalink | Reply | 1 comment |
headers
Passell, Matthew | 5 Jan 23:53
Favicon

[groovy-dev] Using ConcurrentHashMaps in GroovyScriptEngineImpl?

Hi All,


I was digging around the in classes related to Groovy's implementation of JSR-223 (Scripting for the Java Platform) and noticed that GroovyScriptEngineImpl is using Collections.synchronizedMap(new HashMap()) to create values for the classMap and globalClosures fields.  Is there any reason it's not using ConcurrentHashMaps instead?  ConcurrentHashMap has better performance characteristics and since it implements ConcurrentMap, the code using it could take advantage of putIfAbsent().

Thanks,
Matt
Permalink | Reply | 3 comments |
headers
Joachim Baumann | 5 Jan 17:35
Picon
Gravatar

[groovy-dev] Windows-Installer for 1.8.5

Hi,


after extended holidays I am now back and can create the new installer on the coming weekend.

So the usual question for the usual suspects :-)

Cheers, Joachim
Permalink | Reply | 5 comments |

Gmane