Copy Page

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account. You can also Sign Up for a new account.

<table class="wysiwyg-macro" data-macro-name="unmigrated-wiki-markup" style="background-image: url(/plugins/servlet/confluence/placeholder/macro-heading?definition=e3VubWlncmF0ZWQtd2lraS1tYXJrdXB9&amp;locale=en_GB&amp;version=2); background-repeat: no-repeat;" data-macro-body-type="PLAIN_TEXT"><tr><td class="wysiwyg-macro-body"><pre>h3. What is Grail?
Groovy Realtime Archive Internet Lookup == GRAIL

This "grail" ideas are not related to the [Grails web application framework|http://grails.codehaus.org].

h3. 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  :D, the end of jar hell.

h3. 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: [http://www.pmilne.net/Launcher/]

h3. Going forward
After a chat with Phil Milne, the author of Launcher.java, 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?

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

08:36 &lt;tug> Jstrachan: can you put the embeddable jar on the ftp download area, once built.
08:37 &lt;jstrachan> happy
08:37 &lt;Guillaume> we should also distribute this artifact as well
08:38 &lt;jstrachan> you mean in the dist.codehaus.org/groovy/jars area?
08:40 &lt;Guillaume> I guess so along the groovy.jar so that ppl can just choose one single jar with everything included
..
08:43 &lt;Guillaume> perhaps a sub-project, like xml-rpc I guess (for the xml-rpc.jar) with reactor?
08:43 &lt;jstrachan> good idea
08:43 &lt;jstrachan> hmm, no the subproject only gets copied into the binary distro not as a separate jar AFAIK
...
08:44 &lt;tug> After build it creates target/embedable/groovy-all-xxx.jar
08:44 &lt;tug> Include that jar file on it's own, in the ftp area, for ease of fetching...
...
08:44 &lt;pombreda> Guillaume: instead of having one big jar, what about somethng like maven/ibiblio integration? something like RubyGems http://rubygems.rubyforge.org/wiki/wiki.pl or CPAN?
08:45 &lt;jstrachan> we've got the repo, maven, we just need to use in in a clever way
08:45 &lt;jstrachan> I friend of mine has done a cool class loader to do this... http://www.pmilne.net/Launcher/ 
08:45 &lt;Guillaume> pompreda, the big jar includes the asm jars into one big groovy+asm
08:46 &lt;tug> Jez says: Can we put the bloglines example in the groovy src examples dir...
08:46 &lt;Guillaume> tug-jez, good idea!
...
08:46 &lt;Guillaume> we'd need to add the http-client jar to the dependencies
08:47 &lt;jstrachan> lets do that next release - its been chugging for 30 mins already
...
08:46 &lt;pombreda> Guillaume: but for stuffs like xml-rpc getting based on Maven...  integrated in Groovy... would be way cool.
08:48 &lt;jstrachan> it'd be cool to just type :  x = new com.foo.something.Whatever()
08:48 &lt;jstrachan> and for it to just work, downloading whatever it needs
08:48 &lt;pombreda> Yehaa! happy)) that would rock!
...
08:48 &lt;Guillaume> what if there are two com.foo.something.Whatever ? with three different releases?
08:49 &lt;jstrachan> you setup rules for versions
08:49 &lt;Guillaume> yeah, nobody reads the reports... useless
08:49 &lt;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 &lt;Guillaume> and if groovy requires a specific version, but the script you're running would require another one?
08:51 &lt;jstrachan> things could certainly get nasty
08:51 &lt;pombreda> I would rather get a ganifest than an ugly xml manifest?
08:51 &lt;jstrachan> but you could do a nice simple
08:52 &lt;jstrachan> versionScope { // do something with version 1 of foo }
08:52 &lt;jstrachan> versionScope { // do something with version 2 }
08:52 &lt;jstrachan> etc
08:52 &lt;jstrachan> versionScope { it.setMinimumRequirement("foo", 2.0); .... }
08:52 &lt;jstrachan> etc
08:52 &lt;Guillaume> hmmm... with a specific classloader for the scoped stuff?
08:52 &lt;jstrachan> yep
08:52 &lt;Guillaume> in its own thread,
08:53 &lt;jstrachan> threads don't matter, its the classloader that does
08:53 &lt;Guillaume> interesting idea
08:53 &lt;jstrachan> all the Launcher is, above, is a classloader that auto-downloads stuff it needs
08:53 &lt;jstrachan> would be trivial to add to groovy
08:53 &lt;jstrachan> *expecially* for use in IDEs / consoles
08:53 &lt;jstrachan> where you just wanna script something quick
08:53 &lt;jstrachan> and not spend most of the time setting the goddamned classpath
08:54 &lt;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 &lt;pombreda> and include some auto Md5 verif
...
08:56 &lt;pombreda> jstrachan, Guillaume: this idea rocks... the end of jar hell unhappy(
08:59 &lt;pombreda> what about a name for the version/jar loader? GRAIL
08:59 &lt;pombreda> Groovy Realtime Archive Internet Lookup == GRAIL
08:59 &lt;precipice> ha!
08:59 &lt;Guillaume> pombreda, that sounds like the French verb "grailler" happy
09:00 &lt;jstrachan> happy
09:00 &lt;jstrachan> or just 'groovy' happy
09:00 &lt;pombreda> Guillaume, it would eat jars, would it? "grailler"== eating in slang
09:00 &lt;brianm> WOOT
09:01 &lt;brianm> you talking the go-get-jar-from-maven at runtime thing?
09:01 &lt;jstrachan> yes
09:01 &lt;jstrachan> happy
09:01 &lt;brianm> GRAIL is perfect
09:01 &lt;jstrachan> I'm sold!
09:01 &lt;brianm> heh, better than "go get" use a remote classloader
09:01 &lt;Guillaume> the holy grail cheesy
09:01 &lt;jstrachan> happy
09:01 &lt;Guillaume> who's going to implement taht?
09:01 &lt;brianm> Sun already did
09:01 &lt;Guillaume> wasn't there someone supposed to have been working on it?
09:02 &lt;jstrachan> it shouldn't take long to wire the launcher into the shell / console etc
09:02 &lt;brianm> parsing out maven paths will be tricky =)
09:02 &lt;jstrachan> it does this already
09:02 &lt;brianm> the package -> project mapping is doable though
09:02 &lt;jstrachan> its already done, check the link above
...
09:05 &lt;pombreda> about GRAIL: some issue: ibiblio/maven is so unreliable... it is down every now and then ...
09:06 &lt;jstrachan> mirrors 
09:06 &lt;brianm> should check local maven repo first
09:06 &lt;jstrachan> maven supports mirroring of repos, or have your own local mirror of projects you're interest in etc
09:06 &lt;pombreda> good point.
09:08 &lt;pombreda> that could call for a project.groovy rather than a project.xml...
...
09:44 &lt;pombreda> brian: about GRAIL, you said earlier : Sun already did. could you elaborate?
09:44 &lt;brianm> the remote classloader
09:44 &lt;brianm> all we need to do is figure out url for jars
09:44 &lt;jstrachan> the Launcher implementation trawls the maven repo to build up indices AFAIK
09:47 &lt;pombreda> but does'nt remote class loader runs has security constraints?
09:53 &lt;pombreda> briaim: AFAIK: remote class loader can only originate jars from the same code base as the app.
09:53 &lt;pombreda> Check http://java.sun.com/j2se/1.4.2/docs/guide/extensions/spec.html
...
19:52	&lt;pombreda>Guillaume: about GRAIL, I will start a page in the Groovy space, and post an edited IRC log. OK?
19:53	&lt;Guillaume>okey dokey
19:53	&lt;Guillaume>you want to work on that?
19:54	&lt;pombreda>yep. why not? we call it GRAIL or Grail?
19:54	&lt;Guillaume>not too many caps ;-)
19:54	&lt;Guillaume>you're welcome to work on anything you like :-)
19:54	&lt;pombreda>So? which one?
19:56	&lt;oni>	what is GRAIL?
19:58	&lt;pombreda>oni: Groovy Realtime Archive Internet Lookup == GRAIL
19:59	&lt;oni>	pombreda and what does it do?
20:00	&lt;pombreda>oni: check today's IRC log at : http://servlet.uwyn.com/drone/log/hausbot/groovy
20:00	&lt;pombreda>the idea is to have something like RubyGems or CPAN for Groovy
20:01	&lt;pombreda>automating the resolution of dependencies on external jars :D, the end of jar hell</pre></td></tr></table>