Ok, I have been trying to confine all the nasty details of that Jython artifact handling thing.
But I'm stuck in Gradle. Below is an annotated version of what I have been trying to get working. I tried to confine everything to one task to not have all the details spread through the build code. If I have to structure it differently, please tell me. Also, I'm pretty sure that I have a boatload of things that could be coded neater, but I lack the knowledge to make it smooth. Also the current problem is, even if I get past the Ivy cached resolutions, Ivy uses the sourceforge resolver, and can actually download something (an error page), which then fails to work, obviously). I also tried to solve the problem with a custom IvyResolver, but the resolver code is pretty involved, and I'm not sure where I have to plug in (on stackoverflow.com: http://stackoverflow.com/questions/908371/apache-ivy-resolving-dependencies-embedded-in-an-installer) Thanks in advance for any help, it's deeply appreciated task getJython << { try { // TODO I don't think that this here actually works, because if the resolution // has failed then it will not try to resolve again? configurations.jython.resolve() throw new StopExecutionException() // abort this task, since we already have the libs } catch (InvalidUserDataException e) { println "Jython is not installed" } // Get the version of the jython runtime assert configurations.jython.dependencies.size() == 1 configurations.jython.dependencies.each { dep -> jythonVersion = dep.version } // download the installer configurations { jythonInstaller } dependencies.jythonInstaller "jython:jython_installer:${jythonVersion}" repositories { add(new org.apache.ivy.plugins.resolver.URLResolver()) { name = "python_sf" // For non standard resolvers the name is required addArtifactPattern(" http://downloads.sourceforge.net/[organisation]/[artifact]-[revision].[ext] ") } } configurations.jythonInstaller.resolve() // get the location of the install on the disk assert configurations.jythonInstaller.dependencies.size() == 1 File installerFile = configurations.jythonInstaller.files.toList()[0] // create temp dir to expand the installer into tmpDir = new File(System.properties['java.io.tmpdir'], "jython-${System.currentTimeMillis()}") ant.mkdir(dir: tmpDir.path) //tmpDir.deleteOnExit() // cleanup after we're done // run the installer ant.java(jar: installerFile.path, fork: true) { arg(value: '--silent') arg(value: '--directory') arg(value: tmpDir.path) arg(value: '--type') arg(value: 'standalone') //arg(value: '--verbose') // no effect when used called here. } // results in a jython.jar in the given location // create a flatDir resolver and resolve the artifact to be // included in the cache... repositories { flatDir(name: 'jythonTemp', dirs: tmpDir.path) jythonTemp.addArtifactPattern("$tmpDir/[artifact].[ext]") } configurations.jython.resolve() // finished, we should now have everything in place // TODO can we clean the dependencies and repositories from the temporary introduced // ones somehow? } 2009/5/26 Daniel <dan.in.a.bot...@gmail.com> > > > On Tue, May 26, 2009 at 2:19 AM, Hans Dockter <m...@dockter.biz> wrote: > >> >> On May 25, 2009, at 7:54 PM, Luke Taylor wrote: >> >> You can use the ant support, for example: >>> >>> task getJython << { >>> ant.get(src: ' >>> http://downloads.sourceforge.net/jython/jython_installer-2.5rc2.jar', >>> dest: 'jython-installer.jar') >>> } >>> >> >> Alternatively you could use the Gradle dependency management. >> >> configurations { >> jython >> } >> >> dependencies { >> jython "jython:jython_installer:2.5rc2" >> } >> >> repositories { >> add(new org.apache.ivy.plugins.resolver.URLResolver()) { >> name = "python_sf" // For non standard resolvers the name is >> required >> addArtifactPattern("http://downloads.sourceforge.net/ >> [organisation]/[artifact]-[revision].[ext]") >> } >> } >> >> task resolve << { >> println configurations.jython.resolve() >> } >> >> This will of course also cache the jython jar automatically. >> >> In the future we will provide our own domain objects for repositories. ATM >> you have to use the native Ivy ones. > > > Very cool, that's what I'm actually just tinkering with. > > What I'm currently toying with is the following workflow > > ( is this an 'init' task?) > - create dependency on jython (jython.jar and jython-lib.jar, or > together?) > - create an adhoc resolver for Ivy that downloads the Jython Jar if the > appropriate version is not found > > - run on top of jython (delegate) from here > - create zc.buildout (setuptools) execution point > - execute zc.buildout (dependencies) to download eggs into local cache > (build dir?) > - bind from gradle to buildout > (zc.buildout can be under the covers (assemble the config)) > - if requested explicitly, bind the script points to tasks (prefixed > with taskname-), so they can be executed. > > > this eventually would end in a Jython plugin. If you give me some pointers, > I'd actually try to tackle this. > > What I have in mind eventually is to have something similar like the Buildr > hack from Daniel Spiewak, to support interactive shells with the full > dependency path. > > I'm in coding mood, but I'm in unknown terrain. Any pointers appreciated... > > [1] > http://www.codecommit.com/blog/java/hacking-buildr-interactive-shell-support > [2] http://github.com/djspiewak/buildr/tree/interactive-shell > > >> >> - Hans >> >> -- >> Hans Dockter >> Gradle Project Manager >> http://www.gradle.org >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> >
