Groovy realtime archive internet lookup Add comment to Wiki View in Wiki Edit Wiki page Printable Version

What is Grail?

Groovy Realtime Archive Internet Lookup == GRAIL

This "grail" ideas are not related to the Grails web application framework.

What does it do?

Check IRC log below

The idea is to have something like RubyGems or CPAN for Groovy automating the resolution of dependencies on external jars, and downloading them automatically , the end of jar hell.

A list of potential features

  • Dynamic class loading without using import statements...
  • Maven repository support, with local/mirrors support,
  • virtual mavens repos (a repository that does not exists, but is presented as such by an index that can point to any jar, i.e. for Sourceforge based files, or other non ibiblio based jars)
  • Support for version resolution, scoping
  • Jar integrity verification
  • the base for doing it:

Going forward

After a chat with Phil Milne, the author of, we could use his code as a base. He is also in!

The project could be called Jail (Java Archive Internet Lookup) instead of Grail, because it would be for any java environments, not only Groovy.

The license would be a simple MIT style license.

Maybe hosted at Codehaus?

Grail Genesis : the Groovy 1.0 Beta 7 Release Process IRC logs...

08:36 <tug> Jstrachan: can you put the embeddable jar on the ftp download area, once built.

08:37 <jstrachan> happy

08:37 <Guillaume> we should also distribute this artifact as well

08:38 <jstrachan> you mean in the area?

08:40 <Guillaume> I guess so along the groovy.jar so that ppl can just choose one single jar with everything included


08:43 <Guillaume> perhaps a sub-project, like xml-rpc I guess (for the xml-rpc.jar) with reactor?

08:43 <jstrachan> good idea

08:43 <jstrachan> hmm, no the subproject only gets copied into the binary distro not as a separate jar AFAIK


08:44 <tug> After build it creates target/embedable/groovy-all-xxx.jar

08:44 <tug> Include that jar file on it's own, in the ftp area, for ease of fetching...


08:44 <pombreda> Guillaume: instead of having one big jar, what about somethng like maven/ibiblio integration? something like RubyGems or CPAN?

08:45 <jstrachan> we've got the repo, maven, we just need to use in in a clever way

08:45 <jstrachan> I friend of mine has done a cool class loader to do this...

08:45 <Guillaume> pompreda, the big jar includes the asm jars into one big groovy+asm

08:46 <tug> Jez says: Can we put the bloglines example in the groovy src examples dir...

08:46 <Guillaume> tug-jez, good idea!


08:46 <Guillaume> we'd need to add the http-client jar to the dependencies

08:47 <jstrachan> lets do that next release - its been chugging for 30 mins already


08:46 <pombreda> Guillaume: but for stuffs like xml-rpc getting based on Maven... integrated in Groovy... would be way cool.

08:48 <jstrachan> it'd be cool to just type : x = new

08:48 <jstrachan> and for it to just work, downloading whatever it needs

08:48 <pombreda> Yehaa! happy)) that would rock!


08:48 <Guillaume> what if there are two ? with three different releases?

08:49 <jstrachan> you setup rules for versions

08:49 <Guillaume> yeah, nobody reads the reports... useless

08:49 <jstrachan> e.g. use latest production relases or for 'foo' use version '1.2.3' latest production release is fine for most people plus we should include metadata in the manifest of the versions we depend on so dependent jars should match the release of each project

08:51 <Guillaume> and if groovy requires a specific version, but the script you're running would require another one?

08:51 <jstrachan> things could certainly get nasty

08:51 <pombreda> I would rather get a ganifest than an ugly xml manifest?

08:51 <jstrachan> but you could do a nice simple

08:52 <jstrachan> versionScope

Unknown macro: { // do something with version 1 of foo }

08:52 <jstrachan> versionScope

Unknown macro: { // do something with version 2 }

08:52 <jstrachan> etc

08:52 <jstrachan> versionScope

Unknown macro: { it.setMinimumRequirement("foo", 2.0); .... }

08:52 <jstrachan> etc

08:52 <Guillaume> hmmm... with a specific classloader for the scoped stuff?

08:52 <jstrachan> yep

08:52 <Guillaume> in its own thread,

08:53 <jstrachan> threads don't matter, its the classloader that does

08:53 <Guillaume> interesting idea

08:53 <jstrachan> all the Launcher is, above, is a classloader that auto-downloads stuff it needs

08:53 <jstrachan> would be trivial to add to groovy

08:53 <jstrachan> expecially for use in IDEs / consoles

08:53 <jstrachan> where you just wanna script something quick

08:53 <jstrachan> and not spend most of the time setting the goddamned classpath

08:54 <jstrachan> I'm sure it'd be easy to make a versionScope() thingy introspectable, so you could enquire the versions your using etc

08:54 <pombreda> and include some auto Md5 verif


08:56 <pombreda> jstrachan, Guillaume: this idea rocks... the end of jar hell unhappy(

08:59 <pombreda> what about a name for the version/jar loader? GRAIL

08:59 <pombreda> Groovy Realtime Archive Internet Lookup == GRAIL

08:59 <precipice> ha!

08:59 <Guillaume> pombreda, that sounds like the French verb "grailler" happy

09:00 <jstrachan> happy

09:00 <jstrachan> or just 'groovy' happy

09:00 <pombreda> Guillaume, it would eat jars, would it? "grailler"== eating in slang

09:00 <brianm> WOOT

09:01 <brianm> you talking the go-get-jar-from-maven at runtime thing?

09:01 <jstrachan> yes

09:01 <jstrachan> happy

09:01 <brianm> GRAIL is perfect

09:01 <jstrachan> I'm sold!

09:01 <brianm> heh, better than "go get" use a remote classloader

09:01 <Guillaume> the holy grail cheesy

09:01 <jstrachan> happy

09:01 <Guillaume> who's going to implement taht?

09:01 <brianm> Sun already did

09:01 <Guillaume> wasn't there someone supposed to have been working on it?

09:02 <jstrachan> it shouldn't take long to wire the launcher into the shell / console etc

09:02 <brianm> parsing out maven paths will be tricky =)

09:02 <jstrachan> it does this already

09:02 <brianm> the package -> project mapping is doable though

09:02 <jstrachan> its already done, check the link above


09:05 <pombreda> about GRAIL: some issue: ibiblio/maven is so unreliable... it is down every now and then ...

09:06 <jstrachan> mirrors

09:06 <brianm> should check local maven repo first

09:06 <jstrachan> maven supports mirroring of repos, or have your own local mirror of projects you're interest in etc

09:06 <pombreda> good point.

09:08 <pombreda> that could call for a project.groovy rather than a project.xml...


09:44 <pombreda> brian: about GRAIL, you said earlier : Sun already did. could you elaborate?

09:44 <brianm> the remote classloader

09:44 <brianm> all we need to do is figure out url for jars

09:44 <jstrachan> the Launcher implementation trawls the maven repo to build up indices AFAIK

09:47 <pombreda> but does'nt remote class loader runs has security constraints?

09:53 <pombreda> briaim: AFAIK: remote class loader can only originate jars from the same code base as the app.

09:53 <pombreda> Check


19:52 <pombreda>Guillaume: about GRAIL, I will start a page in the Groovy space, and post an edited IRC log. OK?

19:53 <Guillaume>okey dokey

19:53 <Guillaume>you want to work on that?

19:54 <pombreda>yep. why not? we call it GRAIL or Grail?

19:54 <Guillaume>not too many caps

19:54 <Guillaume>you're welcome to work on anything you like

19:54 <pombreda>So? which one?

19:56 <oni> what is GRAIL?

19:58 <pombreda>oni: Groovy Realtime Archive Internet Lookup == GRAIL

19:59 <oni> pombreda and what does it do?

20:00 <pombreda>oni: check today's IRC log at :

20:00 <pombreda>the idea is to have something like RubyGems or CPAN for Groovy

20:01 <pombreda>automating the resolution of dependencies on external jars , the end of jar hell



Results of your search request can come from various sources: the Groovy website itself, the JIRA issues, the API documentation, as well as a few other interesting Groovy-related blogs.

  By  -  pages  -  views  - last modified