I just released the DepNames plugin for Gradle. It’s part of my gradle-plugins collection, appearing in version 0.6.6. You can read the description with an example from the README, but the basic idea is that you can create “keywords” for your common external dependencies.

So this line:

dependencies { compile "org.apache.felix:org.apache.felix.framework:3.0.1"
}

Becomes this line:

dependencies { compile felix
}

And if you can upgrade your definition of felix in one place and all your projects get the same upgrade. The dependency keywords can be defined in either the root project or globally (with the root project definitions trumping the global ones).

(Digital Fingerprint: bcecb67d74ab248f06f068724220e340 (67.192.109.108) )

Here’s an update to the Java class file to ASM script based on suggestions from Headius and Guillaume Laforge.

 
#!/usr/bin/env groovy
 
import org.objectweb.asm.util.ASMifierClassVisitor as V
 
@GrabResolver(name='ow2.org', root='http://maven.ow2.org/maven2/')
@Grab(group='asm', module='asm-all', version='[3.3,)')
private class JustHereForGrab {}
 
V.main(this.args)

No need to muck with your grapeConfig.xml file with this script.

(Digital Fingerprint: bcecb67d74ab248f06f068724220e340 (67.192.109.108) )

Edit: Updated version of the script here.

#!/usr/bin/env groovy
 
import org.objectweb.asm.util.ASMifierClassVisitor as V
import org.objectweb.asm.ClassReader as R
 
@Grab(group='asm', module='asm-all', version='[3.3,)')
private class JustHereForGrab {}
 
new R(new File(this.args[0]).newInputStream()).accept(new V(new PrintWriter(System.out)), 0)

You will have to update your ~/.groovy/grapeConfig.xml file to point to a repo with ASM in it. I’ve posted my grapeConfig.xml at http://repo.smokejumperit.com/grapeConfig.xml.

Comments

• November 5, 2010, Guillaume Laforge wrote: You could use a @GrabResolver, no? Why modify grapeConfig?
• November 5, 2010, Robert Fischer wrote: 1) I didn't know about GrabResolver 2) Even if I did, it keeps configuration all in one place

(Digital Fingerprint: bcecb67d74ab248f06f068724220e340 (67.192.109.108) )

Quick announcement: I added a JavaCC plugin (which also supports JJTree) to Gradle Plugins. This is the 0.6.2 release.

(Digital Fingerprint: bcecb67d74ab248f06f068724220e340 (69.147.112.169) )

Ashlar‘s infrastructure is now live. Basically, we have a compiler and a runtime (ashlarc and ashlar, respectively). Ashlar compiles code down to a component (JAR + properly configured metadata). When Ashlar executes, it loads the component (OSGi install + processing), checks the metadata for any additional components required, fetches those additional components via Ivy, and loads them. Only after all that is done does it invoke the component (OSGi start + processing), which fires off any module in the component with code to execute.

So, in short, you don’t have to muck about with the classpath in Ashlar: we resolve that automatically. If you need to do fancy Ivy stunts, you can muck about with ~/.ashlar/ivy.settings. If you don’t want to think about Ivy or if you mess up your ivy.settings, Ashlar will automatically generate an appropriate one.

We’ve got ashlar and ashlarc. I’d like two other programs eventually: ashlard to deploy components to a local Ivy repository that Ashlar uses, and ashlarx to be a REPL and execute scripts.

For testing, I’m using Cuke4Duke by way of my gradle-plugins. The functional tests act on the actual distribution: the very same code that will be zipped up to make a release. So I can’t get into a situation where the tests pass as long as I’m in the context of a unit test case, but compiled code bombed out on us.

As for the language itself: at this point, all the language can do is print out integers and rational numbers. Not terribly exciting. But the language itself is where the attention is going next: first, some rudimentary type-checking; then, mathematical operations.

Things are about to get a bit slower, because now that I’ve got to this point, I’m shifting some of my free-time focus back to other pending projects. But it’s a pretty exciting place to be.

Comments

• August 24, 2010, Hamlet D'Arcy wrote: The OSGi stuff built into the language is a really good idea. Kudos for actually implementing it as well!

(Digital Fingerprint: bcecb67d74ab248f06f068724220e340 (69.147.112.169) )