Pants JVMtoolSpec for JVM Tools.

[Tej]

Folks,

Me and John Chee have been working on this design document to simply writing of tasks that depending on external dependencies.

This design is in inline with Pants Self Bootstrapping doc that Mark has.
(However with addressing a smaller scope of just JVM tools.)

Let us know your comments.

Thanks
Tejal

[Mark Chu-Carroll]

Looks good to me.

I'd like to make sure that this is sufficient for stuff like running installing and running zinc for scala compilation. Looking at your spec, I'm not sure if that's going to work. It's very close, but not quite. 

What I'm wondering is if you can generalize this just a bit. Right now, you've got two basic concepts tied together in one abstraction:

• a JVM command runnable from the command-line
  
• a task that requires jar dependencies be fetched.

You could split those into a "NailgunTaskWithJarDeps", and "JvmToolSpec" (which would inherit from NailgunTaskWithJarDeps"). Then the logic about fetching jar dependencies and assembling a class path from the ivy report could be used both by JvmToolSpec tasks, and tasks (like ScalaCompile) which require jars, but which have ways of interacting with the command fetched by the jars that don't fit with the uniform JvmToolSpec command-line generation.

    -Mark

--
Mark Craig Chu-Carroll  
*** Software Engineer@foursquare, Software Tools/Programming Language/Math Geek
*** Email: mar...@foursquare.com; Twitter: @MarkCC
*** Blog: http://scientopia.org/blogs/goodmath

[Tejal Desai]

Thanks Mark for a quick response.

Sure,
We can refactor this more and make NailgunTaskWithJarDeps one more level of Abstraction.

ScalaCompile does do a lot of more of stuff than just packing the arguments as is.

Will change the document.

Thanks
Tejal

[Tejal Desai]

On Tue, Apr 16, 2013 at 12:38 PM, Mark Chu-Carroll <mar...@foursquare.com> wrote:

Looks good to me.

I'd like to make sure that this is sufficient for stuff like running installing and running zinc for scala compilation. Looking at your spec, I'm not sure if that's going to work. It's very close, but not quite. 

Regarding this point,
Me and John C discussed and we know this design is very specific and limited to JVM tools.
 
In the design doc i added NailgunTaskWitjJarDeps, but I left the class TDB. As we go about writing the JvmToolSpec, we will implement  the generic stuff in this class.
Later when we tackle more complicated tasks like ScalaCompile and JavaCompile, we can refactor code if there is duplication.

[Benjy Weinberger]

I commented inline in the doc before I read Mark's email, but it turns
out he'd mentioned the same issue.

I don't love that two orthogonal concepts ("how to bootstrap a tool"
and "how to run a tool") are represented by the same entity. In fact,
I don't think the second can reasonably be declarative. It should
probably be imperative the task code, as there can be many logical
branches that can affect the flags and settings.

On Tue, Apr 16, 2013 at 12:38 PM, Mark Chu-Carroll
<mar...@foursquare.com> wrote: