[
https://issues.apache.org/jira/browse/BUILDR-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629376#action_12629376
]
Ittay Dror commented on BUILDR-142:
-----------------------------------
after reading assaf's comment, i'd like to say more.
there are three users to buildr. the ones writing extensions, the ones
authoring buildfile and the ones that simply run buildr. for the last 2 groups,
i don't think there can be an issue where things are going wrong and the use of
fully qualified named tasks means anything for these reasons:
1. if something functional goes wrong (that is, not a compilation error, but
something in the flow), they will likely turn to the first group to fix the
error anyway
2. understanding from a task name what project it refers to is easy. people
know projects and know tasks. it is like classes and methods. if i tell you the
method com.company.package.Foo.bar has failed, is this confusing? does the use
of 'import', to remove the need to fully qualify class names confusing?
The fact that projects are defined as tasks and not a unique object outside of
Rake is an implementation detail. Not a must, they can be distinct entities,
same as classes/objects are distinct from methods. (Not everything in buildr
that looks like it has the characteristics of a task is a task. See for example
the reverse example of Compiler, it is not a task, but reimplements some
task-like methods like 'needed?', 'compile_map' and 'dependencies'. )
> Allow running project tasks from a top directory in the same way as after
> 'cd' to the project's base dir
> --------------------------------------------------------------------------------------------------------
>
> Key: BUILDR-142
> URL: https://issues.apache.org/jira/browse/BUILDR-142
> Project: Buildr
> Issue Type: New Feature
> Components: Core features
> Affects Versions: 1.3.2
> Reporter: Ittay Dror
> Assignee: Victor Hugo Borja
> Fix For: 1.3.3
>
> Attachments: 0001-rspec-for-p-switch.patch,
> 0002-added-p-switch.patch,
> 0003-allow-project-names-with-path-separators.patch,
> 0004-list-project-names-with-file-separator.patch
>
>
> Currently, to run a specific project's tasks, there are two alternatives:
> 1. cd to the project's base dir and run 'buildr' or 'buildr <tasks>'.
> 2. run 'buildr <project name>:<task1> <project name>:<task2>'
> The first one requires 'cd' and is not comfortable to run from an IDE. The
> second one is verbose, cannot rely on default tasks and is confusing to new
> users.
> Users usually expect the behavior as in 'make' or 'tar'. That is, a switch
> (usually -C) that first does a 'cd' for you and then continues to run as
> usual. This is an issue I'm faced with right now. People are confused when I
> tell them to run 'buildr top_project:sub_project:build'. Also, people don't
> think of projects as tasks. This is an implementation detail of Buildr, not
> something that people comprehend intuitively (at least my users)
> Moreover, several projects may share the same base directory (I intend to use
> this to compile the same source tree with different configurations), so a
> 'cd' will cause both to compile.
> Suggestion: add a '-p' switch that tells buildr the "local project" to use
> when running. Then users simply invoke 'buildr -p top_project:sub_project'
> and all default tasks run.
> Suggestion 2: since project names will usually correspond with a directory
> layout, allow to specify them with File::SEPARATOR. this way, command line
> completion is easy (especially in windows).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
