-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
An improved build description? #8
Comments
@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).
It may be helpful to have a discussion via video-chat. |
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. |
@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. |
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:
Also provides some flexibility (which makes it very human friendly), like:
in this language can be writen with dot notation or:
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:
#
or//
{}
around a root object=
as a synonym for:
=
or:
before a{
sofoo { a : 42 }
foo.bar=42
meansfoo { bar : 42 }
except for object-valued keys where the two objects are merged
recursively
include
feature merges root object in another file intocurrent object, so
foo { include "bar.json" }
merges keys inbar.json
into the objectfoo
.conf
,.json
,.properties
include url("http://example.com")
orfile()
orclasspath()
syntax to force the type, or use justinclude "whatever"
to have the library do what you probably mean(Note:
url()
/file()
/classpath()
syntax is not supportedin Play/Akka 2.0, only in later releases.)
foo : ${a.b}
sets keyfoo
to the same valueas the
b
field in thea
objectfoo : the quick ${colors.fox} jumped
resolve in the config itself, so
${HOME}
would work as youexpect. Also, most configs have system properties merged in so
you could use
${user.home}
.there is a syntax
${?a.b}
to permit them to be missing.+=
syntax to append elements to arrays,path += "/bin"
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:
Could make it a serious player, especially in Linux distributions where maven is pure pain.
The text was updated successfully, but these errors were encountered: