Message-ID: <495204114.95329.1397965884284.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_95328_1212980155.1397965884284" ------=_Part_95328_1212980155.1397965884284 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Groovy Realtime Archive Internet Lookup =3D=3D GRAIL=20
This "grail" ideas are not related to the Grails web application framework.=20
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.
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 MI= T style license.
Maybe hosted at Codehaus?
08:36 <tug> Jstrachan: can you put the embeddable jar on the ftp d=
ownload area, once built.
08:37 <jstrachan> happy
08:37 &= lt;Guillaume> we should also distribute this artifact as well
08:3= 8 <jstrachan> you mean in the dist.codehaus.org/groovy/jars 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 &l= t;Guillaume> perhaps a sub-project, like xml-rpc I guess (for the xml-rp= c.jar) with reactor?
08:43 <jstrachan> good idea
08:43 &l= t;jstrachan> hmm, no the subproject only gets copied into the binary dis= tro not as a separate jar AFAIK
08:44 <tug> After bui= ld it creates target/embedable/groovy-all-xxx.jar
08:44 <tug> I= nclude that jar file on it's own, in the ftp area, for ease of fetching...<= br /> ...
08:44 <pombreda> Guillaume: instead of having one big= jar, what about somethng like maven/ibiblio integration? something like Ru= byGems http://rubyge= ms.rubyforge.org/wiki/wiki.pl 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= ... http://www.pmilne.net/Launc= her/
08:45 <Guillaume> pompreda, the big jar includes the = asm jars into one big groovy+asm
08:46 <tug> Jez says: Can we p= ut the bloglines example in the groovy src examples dir...
08:46 <= Guillaume> tug-jez, good idea!
08:46 <Guillaume> w= e'd need to add the http-client jar to the dependencies
08:47 <jst= rachan> lets do that next release - its been chugging for 30 mins alread= y
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 =3D new com.foo.= something.Whatever()
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 com.foo.something.Whatever ? with three different releases?
08:49= <jstrachan> you setup rules for versions
08:49 <Guillaume&g= t; 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 re= quires a specific version, but the script you're running would require anot= her one?
08:51 <jstrachan> things could certainly get nasty
08:51 <pombreda> I would rather get a ganifest than an ugly xml ma= nifest?
08:51 <jstrachan> but you could do a nice simple
= 08:52 <jstrachan> versionScope
08:52 <jstrachan> versionScope=20
08:52 <jstrachan> etc
08:52 <jstrachan> versionScope <= /p>=20
08:52 <jstrachan> etc
08:52 <Guillaume> hmmm... with a= specific classloader for the scoped stuff?
08:52 <jstrachan> y= ep
08:52 <Guillaume> in its own thread,
08:53 <jstrach= an> threads don't matter, its the classloader that does
08:53 <= Guillaume> interesting idea
08:53 <jstrachan> all the Launch= er is, above, is a classloader that auto-downloads stuff it needs
08:= 53 <jstrachan> would be trivial to add to groovy
08:53 <jstr= achan> expecially for use in IDEs / consoles
08:5= 3 <jstrachan> where you just wanna script something quick
08:53= <jstrachan> and not spend most of the time setting the goddamned cla= sspath
08:54 <jstrachan> I'm sure it'd be easy to make a versio= nScope() thingy introspectable, so you could enquire the versions your usin= g 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 fo= r the version/jar loader? GRAIL
08:59 <pombreda> Groovy Realtim= e Archive Internet Lookup =3D=3D GRAIL
08:59 <precipice> ha!
08:59 <Guillaume> pombreda, that sounds like the French verb &quo= t;grailler" happy
09:00 <jstrachan> happy
09:00 <= jstrachan> or just 'groovy' happy
09:00 <pombreda> Guillaume= , it would eat jars, would it? "grailler"=3D=3D eating in slang 09:00 <brianm> WOOT
09:01 <brianm> you talking the g= o-get-jar-from-maven at runtime thing?
09:01 <jstrachan> yes
09:01 <jstrachan> happy
09:01 <brianm> GRAIL is perfe= ct
09:01 <jstrachan> I'm sold!
09:01 <brianm> heh, = better than "go get" use a remote classloader
09:01 <Gui= llaume> the holy grail cheesy
09:01 <jstrachan> happy
= 09:01 <Guillaume> who's going to implement taht?
09:01 <bria= nm> Sun already did
09:01 <Guillaume> wasn't there someone s= upposed to have been working on it?
09:02 <jstrachan> it should= n't take long to wire the launcher into the shell / console etc
09:02= <brianm> parsing out maven paths will be tricky =3D)
09:02 <= ;jstrachan> it does this already
09:02 <brianm> the package = -> project mapping is doable though
09:02 <jstrachan> its al= ready done, check the link above
09:05 <pombreda> abo= ut GRAIL: some issue: ibiblio/maven is so unreliable... it is down every no= w and then ...
09:06 <jstrachan> mirrors
09:06 <brian= m> should check local maven repo first
09:06 <jstrachan> mav= en supports mirroring of repos, or have your own local mirror of projects y= ou'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 fig= ure out url for jars
09:44 <jstrachan> the Launcher implementat= ion trawls the maven repo to build up indices AFAIK
09:47 <pombred= a> but does'nt remote class loader runs has security constraints?
= 09:53 <pombreda> briaim: AFAIK: remote class loader can only originat= e jars from the same code base as the app.
09:53 <pombreda> Che= ck http://java.sun.com/j2se/1.4.2/docs/guide/extensions/spec.html
19:52 <pombreda>Guillaume: about GRAIL, I will start a pag= e in the Groovy space, and post an edited IRC log. OK?
19:53 <Guil= laume>okey dokey
19:53 <Guillaume>you want to work on that?<= br /> 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 Archiv= e Internet Lookup =3D=3D GRAIL
19:59 <oni> pombreda and what do= es it do?
20:00 <pombreda>oni: check today's IRC log at : http://servlet.uwyn= .com/drone/log/hausbot/groovy
20:00 <pombreda>the idea is t= o have something like RubyGems or CPAN for Groovy
20:01 <pombreda&= gt;automating the resolution of dependencies on external jars , the end of jar hell