An improved build description?

[dmacvicar]

This is not an issue, but I wanted to open a discussion and did not find a better place.

I like the simplicity of the model ply uses: the concept of scopes, scripts, etc.

however, property files are not that nice to read and work with.

Hashicop invented HCL (inspired by ucl) in order to provide a language that was good for both humans and machines.

Typesafe Config is an implementation for Java for a similar idea. Keeping the underlaying model the same, the build configuration could look, in a single file like:

project {
  version=1.0
  name=ply-compiler
  namespace=ply-compiler
}

compiler {
  java.source=1.6
  java.target=1.6
}

dependencies {
  "ply-util:ply-util" = 1.0.5
}

dependencies.test {
  // #Fri Oct 21 17:20:55 EDT 2011
  "junit:junit" = 4.10
}

manifest {
  mainClass=net.ocheyedan.ply.script.CompilerScript
}

Also provides some flexibility (which makes it very human friendly), like:

manifest.mainClass=net.ocheyedan.ply.script.CompilerScript
project.version=1.0
project.name=ply-compiler
project.namespace=ply-compiler

in this language can be writen with dot notation or:

manifest {
  mainClass=net.ocheyedan.ply.script.CompilerScript
}

project {
  version=1.0
  name=ply-compiler
  namespace=ply-compiler
}

But you get all the features and testability of a single library that has no dependencies, which at the same time it is also a super-set of properties.

Features of this HOCON language:

• Comments, with # or //
• Allow omitting the {} around a root object
• Allow = as a synonym for :
• Allow omitting the = or : before a { so
  foo { a : 42 }
• Allow omitting commas as long as there's a newline
• Allow trailing commas after last element in objects and arrays
• Allow unquoted strings for keys and values
• Unquoted keys can use dot-notation for nested objects,
  foo.bar=42 means foo { bar : 42 }
• Duplicate keys are allowed; later values override earlier,
  except for object-valued keys where the two objects are merged
  recursively
• include feature merges root object in another file into
  current object, so foo { include "bar.json" } merges keys in
  bar.json into the object foo
• include with no file extension includes any of .conf,
  .json, .properties
• you can include files, URLs, or classpath resources; use
  include url("http://example.com") or file() or
  classpath() syntax to force the type, or use just include "whatever" to have the library do what you probably mean
  (Note: url()/file()/classpath() syntax is not supported
  in Play/Akka 2.0, only in later releases.)
• substitutions foo : ${a.b} sets key foo to the same value
  as the b field in the a object
• substitutions concatenate into unquoted strings, foo : the quick ${colors.fox} jumped
• substitutions fall back to environment variables if they don't
  resolve in the config itself, so ${HOME} would work as you
  expect. Also, most configs have system properties merged in so
  you could use ${user.home}.
• substitutions normally cause an error if unresolved, but
  there is a syntax ${?a.b} to permit them to be missing.
• += syntax to append elements to arrays, path += "/bin"
• multi-line strings with triple quotes as in Python or Scala

I am very interested in trying this. I am not sure if you would think about accepting it upstream giving that the property files are kind of "core" to the current design, but I also understand the important part is keeping the simplicity, so I would like to have a discussion before I start to try to implement it.

I believe that:

• A nicer build description
• The ability to bootstrap on Linux without bringing maven in any dependency
• Some extra sugar on Linux like good offline support and building against system jars
• Some extra maven compatibility (eg, a script to build simple maven projects)

Could make it a serious player, especially in Linux distributions where maven is pure pain.

[blangel]

@dmacvicar this is great stuff. Let me review this more thoroughly. In general I'm not whetted to the idea of properties files (and even have a roadmap item to revisit them). I simply chose them because of their ubiquity and because I hadn't come across anything better at the time (now I may have considered yml, this hcl variant or others).
My main goal in ply is to have a full featured build tool which is fast, simple and easily extensible. The ease of extensibility I have seen over time via scripts/aliases (my company uses ply solely and we have seen this work really well for us; mixing bash/python/java/etc scripts together to do very powerful things without overhead pain of MOJO, set-language (i.e. groovy), etc). The speed is good and I have plans of making it better. The simplicity is decent but can always improve especially as others bring ideas to the table (as you are).
Most of the additional features Typesafe Config brings I've added into ply's usage of properties files (most importantly quoting/escaping, substitutions, and environment variable fallback). However, using a supported library is a good idea and the additional features are helpful. I think the biggest issue I want to resolve before considering this is how this build description will work with ply's notion of scopes (similar to variants in gradle).
I would love to have a larger discussion of this and the other points you've mentioned (especially better offline support as this is something in my current road map for ply).
To give you a better sense of my current direction with ply here's the rough road map:

• [repo script] checksum checking
• [core ply] dsl for properties (i.e. different build description like you're proposing)
• [repo script / core ply] repository support for scripts/aliases (to allow sharing of these across projects)
• [java compiler script] improvements to the java compiler script (use of annotation processors to determine graph of file dependencies automatically
• [core ply] offline support
• [repo script] compute a SHA for the repo item's dep-tree (to uniquely identify the build artifact not only by it's code but by the dependent code)

It may be helpful to have a discussion via video-chat.

[dmacvicar]

Sounds great. We could do a Hangout or something. I am in Central European Time. You?

While implementing any of those items would mean a steep learning curve (eg, all the dependency stuff), if they are tracked as issues with some background, pointers, ideas, etc, I am pretty sure they can be discussed independently and various people (including me) could at least try to work on them.

[blangel]

@dmacvicar sorry for the delay, had family in town. I'm in America/New_York. I can do a call tomorrow anytime after 15.00 UTC if you're available.