Oh, thanks, that would be awesome. Daniel
On Tue, May 26, 2009 at 11:32 PM, Hans Dockter <[email protected]> wrote: > Hi Daniel, > > there is a reasonable solution for your problem. I need to do some > polishing and commenting. I will post it during the next couple of hours. > > - Hans > > > On May 26, 2009, at 4:49 PM, Daniel wrote: > > 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 <[email protected]> >> >> >> On Tue, May 26, 2009 at 2:19 AM, Hans Dockter <[email protected]> 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 >> >> >> >> >> > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
