Closed GoogleCodeExporter closed 9 years ago
Well, you could also do:
ls -1 *.jar | xargs java -jar plovr.jar serve
But I realize that's not what you're looking for. I do see the use case for
this -- could you put together some examples of what you think the format
should be?
I am planning to add support for "config file inheritance" so you could set
your compilation options in one file and then have individual files "inherit"
those config options. So if it were possible to declare multiple configs in one
file, I think that the idea of sharing some settings across configs would still
need to be preserved.
Original comment by bolinf...@gmail.com
on 30 Sep 2010 at 8:00
In my team there are some people working on windows, so their shell wont help
them too much here, I guess : )
Anyway, besides the increased comfort that managing only a single config file
would bring:
typing 'java -jar plovr.jar serve apps.json' would just even be a little more
convenient than the piped statement above.
Potential closure users are sometimes 'just' frontend-devs with possibly little
cli experience(yet), so I think the easier the better.
'Config file inheritance' sounds awesome! Thinking about it, it could even
solve some things that I thought would make using ant or some other build tool
necessary. For example, creating separate builds for dev, stage, production or
similar.
Having that in mind, an idea for a config file making use of multiple apps &
inheritance:
// file: apps.json
{
// master config. 'abstract': not servable nor buildable(no 'inputs')
"id":"master",
"mode":"advanced",
"paths":["goox", "moox"],
"externs":["ext/maps.js", "ext/ga.js"]
},
{
// widget only code, used by third party sites, etc.
"id":"widget",
"extends":"master",
"inputs":"wigdet.js"
},
{
// full fledged app
"id":"app",
"extends":"master",
"inputs":"app.js"
},
{
// api for 3rd party devs to use. only exports data, net stuff from app
"id":"api",
"extends":"master",
"externs":null,
"inputs":"json-api.js",
},
{
// debug version of the api. adds logging, more readable
"id":"api-dev",
"extends":"api",
"mode":"whitespace",
"output":"api.debug.js"
}
How it could work:
The serve cmd just checks for the 'id' query string param to serve the
requested target.
The build cmd builds & writes a file for each config that either has an
'inputs' value on its own or inherits from a config that has one. Filenames are
constructed using the id field by default, eg 'api.js'; when 'output' is given
its value is used instead.
Inherited fields can be overwritten and eg. nulled(see api.externs).
Dont have a good idea how to augment inherited fields right now, maybe sth like
"paths:['base_.paths', 'logging']" or so?
Hope, this comment isnt too long :D
Original comment by carsten.kraus
on 1 Oct 2010 at 7:16
Original comment by bolinf...@gmail.com
on 14 Oct 2010 at 5:02
I added support for an "inherits" option in
http://code.google.com/p/plovr/source/detail?r=0a68ff1f9aab3e430e3c2b350f33c398e
ef3fb27
I know that's not what you proposed, though what you proposed above also won't
parse under a strict JSON parser because it does not have a root. plovr expects
that root to be a map (rather than an array), so at a minimum, you'd have to
add another two levels of indent for your thing to work: a root map (1) with an
property whose value is an array (2) of the configs you list above.
I'd encourage you to build plovr from source and try out the new "inherits"
option and let me know if it works for you.
Original comment by bolinf...@gmail.com
on 21 Jun 2011 at 4:38
As discussed in the Google Group
(https://groups.google.com/group/plovr/browse_thread/thread/b2b4454e7810a031),
it seems the consensus is to prefer config options to command-line arguments,
so I'm going to declare config inheritance as the official way to go with this
one rather than supporting multiple configs in the same file. Thus, I am
closing this issue as WontFix.
If this is really an issue for you, I recommend writing a script to generate
all of the configs. In practice, I have only run into this issue when creating
plovr configs for unit tests (of which you should have many!). I have put
together a bash script that works for me, but I'm planning to port it to Java
and include it as part of plovr.
Also, I just checked in support for generating a deps.js, so using
base.js/deps.js is also a good alternative to creating a plovr config every
time you want to build something.
Original comment by bolinf...@gmail.com
on 14 Oct 2011 at 1:22
Original issue reported on code.google.com by
carsten.kraus
on 24 Aug 2010 at 2:22