I support this approach.
Customization of build and deploy lifecycle actions depends on
the ability to register different kinds of services for performing
these actions. I can imagine that operators would want to provide
such services as part of their Solum install. Then, app developers
would be
+1 for using a simple plan file for M1.
I agree, the language pack id would need to be part of the plan file.
-Murali
On Mar 4, 2014, at 9:20 PM, devdatta kulkarni devdatta.kulka...@rackspace.com
wrote:
I support this approach.
Customization of build and deploy lifecycle actions depends
Angus,
Please include a solum-dsl-version attribute in all examples. That can default
to current.
It would also be wise to have a language pack attribute as Devdatta suggested.
Then we don't need to bump the version to support it later. The default value
for solum-language-pack should be auto