Command line parsing

Rough workings for command line syntax:

release -p projectURI,.. all | these artifactId|groupId:artifactId,.. -i groupId,.. -c configFileName

showtree -p projectURI,.. -i groupId, ..

• -p = the projects (top level artifacts) that make up the release

• all | these{..} = the dependencies that have changed.

• all - checks all dependencies for changes

• these artifactId|groupId:artifactId, .. - these dependencies have changed

• all and these are optional - they're absence implies that the tool is being run from a directory that contains the dependenct to be updated

• -i = list of group ids to include in the dependency filter

• -c = path to config file, command line arguments will override any parameters

So it looks like three use cases - release given one dependency changed, check all dependencies for changes and release, release given these dependencies have changed. Now I just have to write the parser for this. Too easy

--------------------conversation from today -------------------

Karl Roberts: looks like "me" is obsolete, simply not having all or these infers it
Karl Roberts: s/infers/implies/
Karen Davis: Ok - makes sense, no all  or these -> assume it's in the working directory. Thanks
Karl Roberts: "me" is slightly tricky, in the sense that it needs to be a default... effectivly it is a singleton list of "these" and the gID and aID are infered from looking at the pom in the current dir.   The default-ness can be modeled in the "config" object constructed from the parse run, ...
Karl Roberts: but there is deffinatly two pieces of info here, one is missing in most cases .....1) gID and aID   and 2)  "knowledge of location" of dependent project in order to release it
Karl Roberts: Looks like we need a case class :-  case class Artifact(GroupId("blah.blah"), ArtifactId("blah"), URI("locationInSvn"))
Karl Roberts: Thatway when you find it you can suck it down to a temporary location and release it
Karen Davis: Ok - so reading the projectURI supplied I'll be able to get the URI of the dependency to release.  Thanks for the case class - I'll use it. all is really the same as these too - a list of dependencies with default check for change
Karl Roberts: yup. For ease of use there may therefore need to be more to your grammar, ie ...
Karl Roberts: these {groupID:artifactID:URL}      
Karl Roberts: or
Karl Roberts: these {groupID:artifactID} -c path_to_config-file
Karl Roberts: where
Karl Roberts: config file has a list of artifact to URL mappings
Karl Roberts: PS put groupId before artifactID so it matches the order usually supplied to maven
Karen Davis: I want it to be as non verbose as possible that's why I used {artifact | groupid:artifact} supply groupId:artifactid only when artifact isn't enough to identify the dependents
Karen Davis: you should be able to get all the extra info you need once you read the poms of the projects supplied 
Karen Davis: I like the idea of the config file
Karl Roberts: that's cool. but it is nice not to have to supply the URL (which can be long) on the command line, We know, apriori, all the projects that we build, that can be supplied as config
Karl Roberts: snap..!
Karl Roberts: NB, when you start building the Config object, consider how you want to use it. It may be useful to have it made of lots of maps so you can query it, eg I know the aID what's its URL?
Karl Roberts: but don't stress it, you can easily refactor as you discover how you want to use it.
Karl Roberts: ...
Karl Roberts: some more stuff to read... "why config"  http://robey.lag.net/2012/03/26/why-config.html
Karl Roberts: Your config file could be compilable (or eval-able) scala :-)
Karl Roberts: So scala will automatically parse and interprete it when you use it... No typos or dangling property issues for you.

Karl Roberts: back to the discussion... if your config file is scala code.... it should be possible to express the result of parsing in that file. That way you can have "canned commandlines". Makes automation scripts easy... Eval becomes easy.. on startup, read in the config (if supplied) let scala evaluate it to produce your config object... then interpret the rest of the command line and overlay that info into the config object...
Karen Davis: Ok - I'll have to reread that a couple of times
Karen Davis: when you say result of parsing you mean parsing the command line?
Karl Roberts: yes,   you don't have to do it yet, but it allows you to develop the "rest" of the system before you have a CLI parser (if you want) simply hard code some config in the config file and use it.
Karen Davis: Ok make sense
Karl Roberts: basically working bottom up and top down doesn't matter, they both meet in the middle at type checked compiled code
Karen Davis: :-) cool - thanks. I'll do it in parallel. So much to learn!
Karl Roberts: :-) it is righteous!  Doing in parallel is good, because having code "use" the config guides you as to how the config should be structured, and having the parser produce a config also gives feedback to how to structure the config, as well as what you need to parse, which guides the CLI which gets feedback from a user as to how "useble" it feels