move some tasks from amber cli tool to grunt

> Hello!
>
> The `amber` cli tool does a few things and it asks for more. Like, it does `amber serve` to start a http server capable of PUTs (to commit), it does `amber config` which reconciles .amd.json files to produce config.js, and it asks to run `amber ??? devel` / `amber ??? deploy` to change 'modes' of 'app' mapping and the.js contents.
>
> And it of course does `amber init` to populate new project.
>
> I have the impression that except the latter (`amber init`), all the other mentioned tasks could be done by grunt as well. `amber serve` is just a task of starting a server - grunt-contrib-connect does that already, and if customizations are needed, middleware can be injected in Gruntfile.js, from amber-dev. `amber-config` is another piece which just reuses code already present in `amber-dev` (there is issue 1080 there to make it accessible for grunt); and switching between devel and deploy mode could as well be done from predefined tasks in Gruntfile.js. Thus, there would be `grunt serve` to start server at the root of the project and `grunt config:devel` to run config as well as switch to devel mode and `grunt config:deploy` to do the same for deploy. All of it would be preconfigured in project's Gruntfile.js which would be created by `amber init` and users would then be able to customize these tasks directly in `Gruntfile.js` if they wished so.
>
> Is this feasible or you rather like the specialized `amber` task doing these 'outsourceable' tasks?
>
> Herby
>
> --
> You received this message because you are subscribed to the Google Groups "amber-lang" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.

>is a good question really.
>
>I guess is a matter of deciding if we want to offer a friendly cli or we just delegate all that to learning grunt to do things.
>
>I can’t make my mind of what’s more convenient at this point.
>
>Maybe it helps to see how it looks like.
>
>Could you paste how the command looks switching dev and deploy and how the same would be achieved via gruntfile looks?
>
>
>
>
>On Sep 18, 2014, at 12:54 PM, Herby Vojčík <[hidden email]> wrote:
>
>> Hello!
>>
>> The `amber` cli tool does a few things and it asks for more. Like, it does `amber serve` to start a http server capable of PUTs (to commit), it does `amber config` which reconciles .amd.json files to produce config.js, and it asks to run `amber ??? devel` / `amber ??? deploy` to change 'modes' of 'app' mapping and the.js contents.
>>
>> And it of course does `amber init` to populate new project.
>>
>> I have the impression that except the latter (`amber init`), all the other mentioned tasks could be done by grunt as well. `amber serve` is just a task of starting a server - grunt-contrib-connect does that already, and if customizations are needed, middleware can be injected in Gruntfile.js, from amber-dev. `amber-config` is another piece which just reuses code already present in `amber-dev` (there is issue 1080 there to make it accessible for grunt); and switching between devel and deploy mode could as well be done from predefined tasks in Gruntfile.js. Thus, there would be `grunt serve` to start server at the root of the project and `grunt config:devel` to run config as well as switch to devel mode and `grunt config:deploy` to do the same for deploy. All of it would be preconfigured in project's Gruntfile.js which would be created by `amber init` and users would then be able to customize these tasks directly in `Gruntfile.js` if they wished so.
>>
>> Is this feasible or you rather like the specialized `amber` task doing these 'outsourceable' tasks?
>>
>> Herby
>>
>> --
>> You received this message because you are subscribed to the Google Groups "amber-lang" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
>> For more options, visit https://groups.google.com/d/optout.
>
>--
>You received this message because you are subscribed to the Google Groups "amber-lang" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
>For more options, visit https://groups.google.com/d/optout.

>is a good question really.
>
>I guess is a matter of deciding if we want to offer a friendly cli or we just delegate all that to learning grunt to do things.
>
>I can’t make my mind of what’s more convenient at this point.
>
>Maybe it helps to see how it looks like.
>
>Could you paste how the command looks switching dev and deploy and how the same would be achieved via gruntfile looks?
>
>
>
>
>On Sep 18, 2014, at 12:54 PM, Herby Vojčík <[hidden email]> wrote:
>
>> Hello!
>>
>> The `amber` cli tool does a few things and it asks for more. Like, it does `amber serve` to start a http server capable of PUTs (to commit), it does `amber config` which reconciles .amd.json files to produce config.js, and it asks to run `amber ??? devel` / `amber ??? deploy` to change 'modes' of 'app' mapping and the.js contents.
>>
>> And it of course does `amber init` to populate new project.
>>
>> I have the impression that except the latter (`amber init`), all the other mentioned tasks could be done by grunt as well. `amber serve` is just a task of starting a server - grunt-contrib-connect does that already, and if customizations are needed, middleware can be injected in Gruntfile.js, from amber-dev. `amber-config` is another piece which just reuses code already present in `amber-dev` (there is issue 1080 there to make it accessible for grunt); and switching between devel and deploy mode could as well be done from predefined tasks in Gruntfile.js. Thus, there would be `grunt serve` to start server at the root of the project and `grunt config:devel` to run config as well as switch to devel mode and `grunt config:deploy` to do the same for deploy. All of it would be preconfigured in project's Gruntfile.js which would be created by `amber init` and users would then be able to customize these tasks directly in `Gruntfile.js` if they wished so.
>>
>> Is this feasible or you rather like the specialized `amber` task doing these 'outsourceable' tasks?
>>
>> Herby

> Grunt and Gulp and Bower are there to help.
>
> So everybody has to make its homework.
>
> That of course is not the same as saying we don't give a f*ck about that
> pain.
>
> We fell you.
>
> Here is an idea:
>
> Lets use our profiles in Coderwall to make many little how-to's
>
> This is the patter I'll try to stick into using there:
>
> 0. Title
> 1. What?
> 2. Problem description
> 3. Strategy explaining in plain english the idea behind the solution
> 4. How is done
> 5. Thanks for watching

> I bet if more of use use that, things will be good because one-by-one people
> will have what to do to unstuck themselves
>
> BTW regarding to cli or grunt on that, I'm okay either way. Perhaps I do
> want Grunt (altho I prefer gulp which we are not using in Amber, here is
> why: http://markdalgleish.github.io/presentation-build-wars-gulp-vs-grunt)
>
>
> On Sep 20, 2014, at 11:24 AM, Manfred Kröhnert <[hidden email]>
> wrote:
>
>> No real difference.
>>
>> With cli, commands may look like:
>>   amber serve
>>   amber config devel
>>   amber config deploy

>> Best,
>> Manfred
>
> --
> You received this message because you are subscribed to the Google Groups
> "amber-lang" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.
>

>
> On Sep 20, 2014, at 3:48 PM, H. Hirzel <[hidden email]> wrote:
>
>> On 9/20/14, sebastian <[hidden email]> wrote:
>>> Well if you want to work with html5-ish technologies
>>
>> In connection with Amber, what do you man by this?
>
> I mean what I'm about to tell two paragraphs below
>
>
>>
>>> you can't help it but
>>> face some real problems.
>>
>> For example?
>
> have a non-trivial build of the app, if you don't know what kind of problems
> I'm talking about you're lucky
> sass and less are two things that comes to mind, there are a gazillion
> bizarre things to get integrated in the build of complex apps and Smalltalk,
> as usual, is the perfect glue (that when it doesn't isolate itself in a
> bubble).
>
> And, again, my point here is that outsourcing that problem to Grunt (or
> Gulp) makes sense
>
> I agree about releasing but why the rush? having stuff in production means
> we can deploy things properly, right?
>
> Lets sort that conveniently and we go
>
>
>
>>
>>> Grunt and Gulp and Bower are there to help.
>>>
>>> So everybody has to make its homework.
>>>
>>> That of course is not the same as saying we don't give a f*ck about that
>>> pain.
>>>
>>> We fell you.
>>>
>>> Here is an idea:
>>>
>>> Lets use our profiles in Coderwall to make many little how-to's
>>>
>>> This is the patter I'll try to stick into using there:
>>>
>>> 0. Title
>>> 1. What?
>>> 2. Problem description
>>> 3. Strategy explaining in plain english the idea behind the solution
>>> 4. How is done
>>> 5. Thanks for watching
>>
>>
>>> I bet if more of use use that, things will be good because one-by-one
>>> people
>>> will have what to do to unstuck themselves
>>>
>>> BTW regarding to cli or grunt on that, I'm okay either way. Perhaps I do
>>> want Grunt (altho I prefer gulp which we are not using in Amber, here is
>>> why:
>>> http://markdalgleish.github.io/presentation-build-wars-gulp-vs-grunt)
>>>
>>>
>>> On Sep 20, 2014, at 11:24 AM, Manfred Kröhnert
>>> <[hidden email]>
>>> wrote:
>>>
>>>> No real difference.
>>>>
>>>> With cli, commands may look like:
>>>>  amber serve
>>>>  amber config devel
>>>>  amber config deploy
>>
>> I prefer the above currently. I like the idea of having a kind of
>> facade tool to interact with.
>>
>>
>>>> With grunt, they would be:
>>>>  grunt serve
>>>>  grunt config:devel
>>>>  grunt config:deploy
>>
>> Would be OK as well. But it does not matter all that much for 0.13.
>> The question is: what is the benefit of moving tasks from amber cli
>> tool to grunt?
>>
>> What matters more is that 0.13 is finalized soon so that the new
>> depolyment option which took one year to develop may be tested in
>> production.
>>
>
>
>
>
>>>>
>>>> I guess the real difference here is that using grunt requires Grunt to
>>>> be
>>>> installed explicitely
>>>> whereas the first one uses it implicitely.
>>
>>
>>>> Note, that I am not arguing against using Grunt.
>>>> I think that (some of) those tasks should be available to Grunt, too.
>>
>>>> It is just that there are emails on this list every now and then which
>>>> suggest that some people seem to be a bit overwhelmed by the several
>>>> techs
>>>> we use for Amber.
>>
>> Yes, an inflationary use of tools is not helpful. Choose a few and
>> stay with them. For Smalltalk programming not much the JavaScript tool
>> know how should be a prerequisite.
>>
>> However issue a few npm install commands and calls to command line
>> tools is not an issue if well documented.
>>
>>>> Also, if we want to use something like connect, we might have to
>>>> rewrite
>>>> several parts in pure JS.
>>
>> connect? What would be the benefit we get out of it?
>>
>>>> Best,
>>>> Manfred
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups
>>> "amber-lang" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an
>>> email to [hidden email].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "amber-lang" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [hidden email].
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "amber-lang" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.
>