Tool-Targets, that can use SBuild infrastructure, to provide easy cmdline tools

[lefou]

Tool targets should behave as normal target, but they should have some special handling for the sbuild commandline: When a tool target is given on commandline, all succeeding commandline arguments should be feeded to that tool.

Motivation: It is sometime difficult, to get arbitrary Java tools to work in various environments. In most cases, those tools are simply a standard Java main plus a classpath. SBuild provides the perfect infrastructure to provide the tool and the classpath of a tool, therefore, it is pretty easy, to use SBuild a tool hub and single commandline entry point for the developer.

Benefits:

• Easy tool usage, just write "sbuild toolname" followed by all parameters you want to feed to the tool.
• No need to use complicated -Dargs=xyz constructs to feed parameter to the target.

Example commandline: @sbuild my-tool arg1-feeded-to-tool@

If SBuild will get an proper plugin system, it would be easy for plugins to provide tools targets.

Ticket imported form Redmine http://sbuild.tototec.de/sbuild

Original Redmine issue link: Redmine ID 126
Reporter: Tobias Roeser => @lefou
Creating date: 2013-05-29T19:57:16+02:00

Assigned to:
Start date: 2013-05-29
Due date:

Another issue #134 relates this issue.

[lefou]

As an alternative to a special kind of target, a special marker commandline parameter comes to mind, which designates, that all following parameters will be feeded to the last given target, e.g. "sbuild mytool % arg1 arg2".

An even more general aproach might be possible, that all arguments following a marker parameter are provided in the sbuild via a dedicated API.

Comment imported from Redmine http://sbuild.tototec.de/sbuild/issues/126
Author: Tobias Roeser => @lefou
Creating date: 2013-05-29T20:03:33+02:00

[lefou]

Example, which works with current SBuild. Run Scalagen (a Java to Scala code converter) from SBuild.

The Commandline:

sbuild scalagen -D srcDir=src/main/java -D targetDir=target/scala

The build file:

import de.tototec.sbuild._
import de.tototec.sbuild.TargetRefs._
@version("0.4.0.9000")
class SBuild(implicit _project: Project) {
  val scalaGenCp =
    "mvn:org.scala-lang:scala-library:2.9.2" ~
    "mvn:com.mysema.scalagen:scalagen:0.2.2" ~
    "mvn:com.google.code.javaparser:javaparser:1.0.8" ~
    "mvn:net.sourceforge.collections:collections-generic:4.01" ~
    "mvn:org.apache.commons:commons-lang3:3.0.1" ~
    "mvn:org.apache.commons:commons-io:1.3.2"
  Target("phony:scalagen") dependsOn scalaGenCp exec {
    addons.support.ForkSupport.runJavaAndWait(
      interactive = true,
      classpath = scalaGenCp.files,
      arguments = Array("com.mysema.scalagen.Cli", Prop("srcDir"), Prop("targetDir"))
    )
  }
}

As one can see, to feed parameter to the tool, one need to use properties (same mechanism Maven uses, to run plugins from command line).
With this ticket's feature, the command line could look like this:

sbuild scalagen % src/main/java target/scala

Comment imported from Redmine http://sbuild.tototec.de/sbuild/issues/126
Author: Tobias Roeser => @lefou
Creating date: 2013-05-29T20:30:10+02:00

[lefou]

• fixed_version_id changed
  • Old Value:
  • New Value: 2

Comment imported from Redmine http://sbuild.tototec.de/sbuild/issues/126
Author: Tobias Roeser => @lefou
Creating date: 2013-07-01T16:21:56+02:00

[lefou]

After rethinking it, all required infrastructure is already in place. Instead of writing targets, one can simply write a scheme handler. A scheme handler has a name followed by a double colon (:) and everything after that is up to the scheme handlers interpretation. If required, a scheme handler can even have dependencies (extending SchemeHandlerWithDependencies). So, it would be perfectly valid to use the path as argument list for the tool.

To reuse the scalagen use case above, a scheme hander with the name scalagen could be used that way on the command line:

sbuild "scalagen: src/main/java target/scala"

For convenience, some support to parse and split the scheme path into arguments for the underlying tool might be useful, but are not required to accomplish the tool target mission.