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
