You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@buildr.apache.org by Assaf Arkin <ar...@intalio.com> on 2008/09/01 01:34:55 UTC
Re: [PATCH] added -p switch to specify project name
On Sun, Aug 31, 2008 at 12:59 PM, Ittay Dror <it...@gmail.com> wrote:
>
>
> Assaf Arkin wrote:
>>
>> On Sun, Aug 31, 2008 at 1:02 AM, Ittay Dror <it...@tikalk.com> wrote:
>>
>>>
>>> This patch adds the ability to run buildr as 'buildr -p <project name>',
>>> instead of 'cd' to the project's base directory. This is more comfortable
>>> when building several projects and when using buildr as a tool from an
>>> ide
>>> (since specifying an argument is easier than specifying a working dir)
>>>
>>
>> A few suggestions:
>> [SNIP]
>>
>
> so do you want to continue the discussion in JIRA or here?
Mailing list is the right place to have the discussion, but the wrong
place to submit a patch.
>>
>> Specifically for this patch:
>> - You can already build a project without changing into its directory.
>> http://incubator.apache.org/buildr/projects.html#running_project_tasks
>>
>
> but i have to specify the task name instead of relying on the defaults.
> writing buildr <project name>:<task name> is confusing to my users. it is
> more confusing because there's help:projects and separate help:tasks. people
> don't think of projects as tasks.
Buildr uses tasks for just about everything, and because most names
are repeated, we use namespaces, so you can have foo:test and bar:test
and these are two separate tasks. Projects helps you specify related
tasks, they take care of a lot of details so you don't have to, they
keep the buildfile DRY and simple. So it's inherit in this model that
you're going to do foo:build or bar:test, because these are the
specific tasks you want to execute.
It could be the wrong abstraction, and we can open it up for
discussion and see how people feel and maybe come up with a different
abstraction and roll it out in a future version. But we can't accept
a different abstraction as a side-effect of a patch.
>>
>> - Command line options are used for controlling Buildr.application,
>> variables for controlling tasks.
>>
>
> i think this is controlling Buildr.application. it is telling buildr to run
> in the context of a certain project, treating projects as a special kind,
> not a task.
You lost me. When you run foo (if foo is a project), nothing
interesting happens. If you run foo:build, that's a task. It's that
entire tree of stack (you can see it by running buildr --prereqs) that
you work with when using Buildr, and all the dependencies between
these tasks.
>>
>> - Follow coding conventions.
>>
>
> where can i find the coding conventions?
In the same source file you're modifying. The source code is self-documenting.
Assaf
>>
>> - return projects if projects: when is projects ever nil?
>>
>
> right. it can't. will fix.
>>
>> - local_projects expects a block.
>>
>
> only if a block is given ('elsif block')
>
>> Assaf
>>
>>
>>
>>>
>>> ---
>>> lib/buildr/core/application_cli.rb | 6 +++++-
>>> lib/buildr/core/project.rb | 4 ++++
>>> 2 files changed, 9 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/lib/buildr/core/application_cli.rb
>>> b/lib/buildr/core/application_cli.rb
>>> index 3a19cf9..3f826e8 100644
>>> --- a/lib/buildr/core/application_cli.rb
>>> +++ b/lib/buildr/core/application_cli.rb
>>> @@ -59,7 +59,9 @@ module Buildr
>>> ['--version', '-v', GetoptLong::NO_ARGUMENT,
>>> 'Display the program version.'],
>>> ['--environment', '-e', GetoptLong::REQUIRED_ARGUMENT,
>>> - 'Environment name (e.g. development, test, production).']
>>> + 'Environment name (e.g. development, test, production).'],
>>> + ['--project', '-p', GetoptLong::REQUIRED_ARGUMENT,
>>> + 'Project name, can be relative to current directory']
>>> ]
>>>
>>> def collect_tasks
>>> @@ -99,6 +101,8 @@ module Buildr
>>> options.show_task_pattern = Regexp.new(value || '.')
>>> when '--nosearch', '--quiet', '--trace'
>>> super
>>> + when '--project'
>>> + options.project = value
>>> end
>>> end
>>>
>>> diff --git a/lib/buildr/core/project.rb b/lib/buildr/core/project.rb
>>> index 6a37751..d5c511a 100644
>>> --- a/lib/buildr/core/project.rb
>>> +++ b/lib/buildr/core/project.rb
>>> @@ -336,6 +336,10 @@ module Buildr
>>> end
>>>
>>> def local_projects(dir = nil, &block) #:nodoc:
>>> + if dir.nil? and Buildr.application.options.project
>>> + projects = local_projects('.').map{|p|
>>> project("#{p}:#{Buildr.application.options.project}")}
>>> + return projects if projects
>>> + end
>>> dir = File.expand_path(dir || Buildr.application.original_dir)
>>> projects = Project.projects.select { |project| project.base_dir ==
>>> dir }
>>> if projects.empty? && dir != Dir.pwd && File.dirname(dir) != dir
>>> --
>>> 1.6.0.36.g3814c
>>>
>>> --
>>> Ittay Dror <it...@tikalk.com>
>>> Tikal <http://www.tikalk.com>
>>> Tikal Project <http://tikal.sourceforge.net>
>>>
>>>
>>>
>>>
>
> --
> --
> Ittay Dror <it...@gmail.com>
>
>
Re: [PATCH] added -p switch to specify project name
Posted by Ittay Dror <it...@gmail.com>.
Assaf Arkin wrote:
> [snip]
>>> Specifically for this patch:
>>> - You can already build a project without changing into its directory.
>>> http://incubator.apache.org/buildr/projects.html#running_project_tasks
>>>
>>>
>> but i have to specify the task name instead of relying on the defaults.
>> writing buildr <project name>:<task name> is confusing to my users. it is
>> more confusing because there's help:projects and separate help:tasks. people
>> don't think of projects as tasks.
>>
>
> Buildr uses tasks for just about everything, and because most names
> are repeated, we use namespaces, so you can have foo:test and bar:test
> and these are two separate tasks. Projects helps you specify related
> tasks, they take care of a lot of details so you don't have to, they
> keep the buildfile DRY and simple. So it's inherit in this model that
> you're going to do foo:build or bar:test, because these are the
> specific tasks you want to execute.
>
> It could be the wrong abstraction, and we can open it up for
> discussion and see how people feel and maybe come up with a different
> abstraction and roll it out in a future version. But we can't accept
> a different abstraction as a side-effect of a patch.
>
My suggestion to a '-p' is similar to using 'namespace' inside the ruby
code. It is easier to write 'buildr -p foo:bar' and have buildr run the
default tasks. Otherwise, the user needs to learn the default tasks
names (which may not only be 'build') and specify them explicitly.
From a user's perspective, the buildfile he sees uses the abstraction
of projects, not tasks.
Ittay
>
>>> - Command line options are used for controlling Buildr.application,
>>> variables for controlling tasks.
>>>
>>>
>> i think this is controlling Buildr.application. it is telling buildr to run
>> in the context of a certain project, treating projects as a special kind,
>> not a task.
>>
>
> You lost me. When you run foo (if foo is a project), nothing
> interesting happens. If you run foo:build, that's a task. It's that
> entire tree of stack (you can see it by running buildr --prereqs) that
> you work with when using Buildr, and all the dependencies between
> these tasks.
>
>
>>> - Follow coding conventions.
>>>
>>>
>> where can i find the coding conventions?
>>
>
> In the same source file you're modifying. The source code is self-documenting.
>
> Assaf
>
>
>>> - return projects if projects: when is projects ever nil?
>>>
>>>
>> right. it can't. will fix.
>>
>>> - local_projects expects a block.
>>>
>>>
>> only if a block is given ('elsif block')
>>
>>
>>> Assaf
>>>
>>>
>>>
>>>
>>>> ---
>>>> lib/buildr/core/application_cli.rb | 6 +++++-
>>>> lib/buildr/core/project.rb | 4 ++++
>>>> 2 files changed, 9 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/lib/buildr/core/application_cli.rb
>>>> b/lib/buildr/core/application_cli.rb
>>>> index 3a19cf9..3f826e8 100644
>>>> --- a/lib/buildr/core/application_cli.rb
>>>> +++ b/lib/buildr/core/application_cli.rb
>>>> @@ -59,7 +59,9 @@ module Buildr
>>>> ['--version', '-v', GetoptLong::NO_ARGUMENT,
>>>> 'Display the program version.'],
>>>> ['--environment', '-e', GetoptLong::REQUIRED_ARGUMENT,
>>>> - 'Environment name (e.g. development, test, production).']
>>>> + 'Environment name (e.g. development, test, production).'],
>>>> + ['--project', '-p', GetoptLong::REQUIRED_ARGUMENT,
>>>> + 'Project name, can be relative to current directory']
>>>> ]
>>>>
>>>> def collect_tasks
>>>> @@ -99,6 +101,8 @@ module Buildr
>>>> options.show_task_pattern = Regexp.new(value || '.')
>>>> when '--nosearch', '--quiet', '--trace'
>>>> super
>>>> + when '--project'
>>>> + options.project = value
>>>> end
>>>> end
>>>>
>>>> diff --git a/lib/buildr/core/project.rb b/lib/buildr/core/project.rb
>>>> index 6a37751..d5c511a 100644
>>>> --- a/lib/buildr/core/project.rb
>>>> +++ b/lib/buildr/core/project.rb
>>>> @@ -336,6 +336,10 @@ module Buildr
>>>> end
>>>>
>>>> def local_projects(dir = nil, &block) #:nodoc:
>>>> + if dir.nil? and Buildr.application.options.project
>>>> + projects = local_projects('.').map{|p|
>>>> project("#{p}:#{Buildr.application.options.project}")}
>>>> + return projects if projects
>>>> + end
>>>> dir = File.expand_path(dir || Buildr.application.original_dir)
>>>> projects = Project.projects.select { |project| project.base_dir ==
>>>> dir }
>>>> if projects.empty? && dir != Dir.pwd && File.dirname(dir) != dir
>>>> --
>>>> 1.6.0.36.g3814c
>>>>
>>>> --
>>>> Ittay Dror <it...@tikalk.com>
>>>> Tikal <http://www.tikalk.com>
>>>> Tikal Project <http://tikal.sourceforge.net>
>>>>
>>>>
>>>>
>>>>
>>>>
>> --
>> --
>> Ittay Dror <it...@gmail.com>
>>
>>
>>
--
--
Ittay Dror <it...@gmail.com>
Re: [PATCH] added -p switch to specify project name
Posted by Ittay Dror <it...@gmail.com>.
Assaf Arkin wrote:
>>> - Follow coding conventions.
>>>
>>>
>> where can i find the coding conventions?
>>
>
> In the same source file you're modifying. The source code is self-documenting.
>
> Assaf
>
Sorry, but I still can't see what I did wrong. I would appreciate it if
you could point out my mistakes. Maybe it is also worth while explicitly
documenting conventions.
Ittay
>
>>> - return projects if projects: when is projects ever nil?
>>>
>>>
>> right. it can't. will fix.
>>
>>> - local_projects expects a block.
>>>
>>>
>> only if a block is given ('elsif block')
>>
>>
>>> Assaf
>>>
>>>
>>>
>>>
>>>> ---
>>>> lib/buildr/core/application_cli.rb | 6 +++++-
>>>> lib/buildr/core/project.rb | 4 ++++
>>>> 2 files changed, 9 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/lib/buildr/core/application_cli.rb
>>>> b/lib/buildr/core/application_cli.rb
>>>> index 3a19cf9..3f826e8 100644
>>>> --- a/lib/buildr/core/application_cli.rb
>>>> +++ b/lib/buildr/core/application_cli.rb
>>>> @@ -59,7 +59,9 @@ module Buildr
>>>> ['--version', '-v', GetoptLong::NO_ARGUMENT,
>>>> 'Display the program version.'],
>>>> ['--environment', '-e', GetoptLong::REQUIRED_ARGUMENT,
>>>> - 'Environment name (e.g. development, test, production).']
>>>> + 'Environment name (e.g. development, test, production).'],
>>>> + ['--project', '-p', GetoptLong::REQUIRED_ARGUMENT,
>>>> + 'Project name, can be relative to current directory']
>>>> ]
>>>>
>>>> def collect_tasks
>>>> @@ -99,6 +101,8 @@ module Buildr
>>>> options.show_task_pattern = Regexp.new(value || '.')
>>>> when '--nosearch', '--quiet', '--trace'
>>>> super
>>>> + when '--project'
>>>> + options.project = value
>>>> end
>>>> end
>>>>
>>>> diff --git a/lib/buildr/core/project.rb b/lib/buildr/core/project.rb
>>>> index 6a37751..d5c511a 100644
>>>> --- a/lib/buildr/core/project.rb
>>>> +++ b/lib/buildr/core/project.rb
>>>> @@ -336,6 +336,10 @@ module Buildr
>>>> end
>>>>
>>>> def local_projects(dir = nil, &block) #:nodoc:
>>>> + if dir.nil? and Buildr.application.options.project
>>>> + projects = local_projects('.').map{|p|
>>>> project("#{p}:#{Buildr.application.options.project}")}
>>>> + return projects if projects
>>>> + end
>>>> dir = File.expand_path(dir || Buildr.application.original_dir)
>>>> projects = Project.projects.select { |project| project.base_dir ==
>>>> dir }
>>>> if projects.empty? && dir != Dir.pwd && File.dirname(dir) != dir
>>>> --
>>>> 1.6.0.36.g3814c
>>>>
>>>> --
>>>> Ittay Dror <it...@tikalk.com>
>>>> Tikal <http://www.tikalk.com>
>>>> Tikal Project <http://tikal.sourceforge.net>
>>>>
>>>>
>>>>
>>>>
>>>>
>> --
>> --
>> Ittay Dror <it...@gmail.com>
>>
>>
>>
--
--
Ittay Dror <it...@gmail.com>