Args to groovy ant task?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Args to groovy ant task?

Edward Povazan
Hello,

The project I am working on has a few tools implemented in Groovy. These tools
take args on the command line. An example is:
groovy CreateKeys.groovy mykeys

I want to add these tools to an ant build to glue them into CLI of sorts -
thanks for the idea Grails :)
But how to deal with args?
<groovy src="CreateKeys" args=??? />

Is there an easy way to do this? From what I see in the groovy task source this
is not possible. Is this something that should be in the task? I could give it a go.

Thanks
-Ed

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Args to groovy ant task?

Edward Povazan
Well, I went and hacked the groovy ant task. So now I can do:
<target name="create-keys">
   <input addproperty="create.name" message="Enter keys file name prefix:" />
   <groovy
     src="${home}/scripts/KeyGenerator.groovy"
     args="${create.name}"
     classpath="${home}/classes"
   />
</target>

Any use to anyone? I can add a JIRA enhancement request with a patch.
Incidentally, why isn't classpath/classpathRef used in the Groovy ant task? You
can set it, but the variable is never used in the task. This means:
<groovy classpath=${lib}/blah.jar>
   import blah.blah.Blah
</groovy>
would not work if the classpath to Blah is not used, no?

-Ed

Edward Povazan wrote:

> Hello,
>
> The project I am working on has a few tools implemented in Groovy. These
> tools take args on the command line. An example is:
> groovy CreateKeys.groovy mykeys
>
> I want to add these tools to an ant build to glue them into CLI of sorts
> - thanks for the idea Grails :)
> But how to deal with args?
> <groovy src="CreateKeys" args=??? />
>
> Is there an easy way to do this? From what I see in the groovy task
> source this is not possible. Is this something that should be in the
> task? I could give it a go.
>
> Thanks
> -Ed
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Args to groovy ant task?

Jochen Theodorou
Edward Povazan wrote:

> Well, I went and hacked the groovy ant task. So now I can do:
> <target name="create-keys">
>   <input addproperty="create.name" message="Enter keys file name
> prefix:" />
>   <groovy
>     src="${home}/scripts/KeyGenerator.groovy"
>     args="${create.name}"
>     classpath="${home}/classes"
>   />
> </target>

Can you explain what you changed?

> Any use to anyone? I can add a JIRA enhancement request with a patch.
> Incidentally, why isn't classpath/classpathRef used in the Groovy ant
> task? You can set it, but the variable is never used in the task. This
> means:
> <groovy classpath=${lib}/blah.jar>
>   import blah.blah.Blah
> </groovy>
> would not work if the classpath to Blah is not used, no?

hmm.. can you create an issue for this one? I mean filled as bug?


bye blackdrag
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Args to groovy ant task?

Edward Povazan


Jochen Theodorou wrote:

> Edward Povazan wrote:
>> Well, I went and hacked the groovy ant task. So now I can do:
>> <target name="create-keys">
>>   <input addproperty="create.name" message="Enter keys file name
>> prefix:" />
>>   <groovy
>>     src="${home}/scripts/KeyGenerator.groovy"
>>     args="${create.name}"
>>     classpath="${home}/classes"
>>   />
>> </target>
>
> Can you explain what you changed?
I added:
public void setArgs(String args) {
        this.args = args.trim().split("\\s+");
}

And:
public void execute() throws BuildException {
...
        try {
...
                if (srcFile != null) {
                        execSourceFile();
                        return;
                }
...}

And:
private void execSourceFile() {
        log("execSourceFile()", Project.MSG_VERBOSE);
        try {
                GroovyClassLoader loader = new GroovyClassLoader(GroovyShell.class
                                .getClassLoader());
                loader.addClasspath(classpath.toString());
                GroovyShell groovy = new GroovyShell(loader, new Binding(),
                                configuration);
                groovy.run(srcFile, args);
        } catch (IOException e) {
...
        } catch (CompilationFailedException e) {
...
        }
}

It is a hack as I said - but it works.

>
>> Any use to anyone? I can add a JIRA enhancement request with a patch.
>> Incidentally, why isn't classpath/classpathRef used in the Groovy ant
>> task? You can set it, but the variable is never used in the task. This
>> means:
>> <groovy classpath=${lib}/blah.jar>
>>   import blah.blah.Blah
>> </groovy>
>> would not work if the classpath to Blah is not used, no?
>
> hmm.. can you create an issue for this one? I mean filled as bug?
>
Yes. I tried this just to be sure:
<groovy classpath="${codeclam.home}/classes">
        import com...KeyGenerator
        KeyGenerator.generateKeys(properties."create.name")
</groovy>
and it fails with NoSuchProperty KeyGenerator.

So I did a similar thing with class loader as above and now it works. I can
upload a patch which includes both this patch, and the <groovy src="" args="">
addition if you like.

How does one write a test case for this stuff? I am not sure the Maven stuff is
correct:
protected void execGroovy(String txt, PrintStream out) { // line 435 Groovy.java
// added this:
        GroovyClassLoader loader = new GroovyClassLoader(GroovyShell.class
                                .getClassLoader());
        loader.addClasspath(classpath.toString());

                // treat the case Ant is run through Maven, and
        if ("org.apache.commons.grant.GrantProject".equals(project.getClass()
                                .getName())) {
...
// Changed here, line 472
                Thread.currentThread().setContextClassLoader(
                                loader);
                // load groovy into "root.maven" classloader instead of "root" so
                // that
                // groovy script can access Maven classes
                groovy = new GroovyShell(mavenPom.getClass().getClassLoader(),
                                        new Binding(), configuration);
        } else {
// Changed here, line 480
                groovy = new GroovyShell(loader,
                                new Binding(), configuration);
        }
...
}

Heh, heh, so if my code snippets above have caused enough confusion, should I
upload a patch as a bug + enhancement so you can diff it properly?

-Ed
Loading...