Home » Archived » B3 » the ways to invoke b3? opinions wanted...
the ways to invoke b3? opinions wanted... [message #603392] |
Sun, 14 March 2010 17:24 ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Henrik Lindberg![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=henrik.lindberg%40puppet.com) Messages: 2509 Registered: July 2009 |
Senior Member |
|
|
Hi,
Here is a topic where I want your input - the various ways we want to be
able to invoke the b3 engine.
There are a couple of cases, and situations. Here are some ideas for how
things could work. They are all quite easy to implement, but what is the
best approach, and what would be the easiest to use?
So - braindump on ideas...
When the workspace does not contain what user wants to work on, it feels
natural to get it there via Eclipse -> Import -> "Import using b3
materialization"
A b3 materialization requires a) a definition of the repositories to
search, and b) the top unit (i.e. what is requested).
Now, there are many choices how this can be done in the user interface.
- User could point to a b3 script that contains everything required.
(i.e. something like:
repositories { "p2:..."; "git:..."; "svn: ..."; }
b3.resolveAndMaterialize("org.myorg.mytopComponent");
)
- User could point to a b3 script that only contains the repositories
declaration (and any other setup code the user is interested in), and
enter the name of the component manually.
- What if this is the first time the user is using b3? User has no
scripts, and has made no configuration of b3. What should the dialog
tell the user? By default b3 resolves from workspace and target platform
(and naturally the b3 file being executed) - the dialog could tell the
user that additional repository configuration is required (if wanted)
and then create a b3 file with a template repository config. It would
probably be possible to discover repositories by looking at the p2
repositories in p2's preferences, and by looking at repositories
configured for cvs, svn, git, etc. and then guess on a template (could
be directed by user choice - showing them). This is perhaps a separate
wizard that the user is offered a choice to run - the output would be a
b3 script with a repository configuration that can then be further
edited as required).
- An alterantive to the above is to just open the b3 editor with a
minimal template, and let the user insert repository configuration using
code/completion (i.e. look up repository info from scm's and p2
preferences).
- User would not have to use the import dialog at all, when there is a
b3 script defining repositories and having a resolveAndMaterialize call.
It is enough to simply run the b3 script.
- User preferences for b3 could contain a reference to the equivalence
of a .b3rc to run by default when running b3 scripts. User could be
allowed to have several such named scripts. User could then select one
of them in the import dialog.
- User could open the script editor. When in the script editor, the b3
code can be executed from within the editor (currently via "run" in the
outline - but could be placed in a more visible place).
- We can implement a "run as b3", that would be available from the run
menu, as well as in a context menu for a b3 file. (Some distinction is
needed between "run in IDE" (i.e. having b3 installed), and "run
selfhosted / for debugging" - but those are probably quite different as
the latter requires a launch configuration.
- Currently, invokation of b3 scripts call a function called main. There
is no notion of just executing expressions at the top level (as in many
script languages). I think that feature should be added in order to
simplify when using b3 as a command script (i.e. to do resolve and
materialize, import, build, etc).
- When running a b3 file from the command line, passing arguments is
naturally easy - should there be a dialog for this in the UI? i.e.
typing parameters in a field?
// When there is stuff in the workspace
- When there are things in the workspace that b3 has translated into
build units (i.e. plugins, features, etc.) it is possible to invoke
actions on them. (Similar to how Buckminster does this). In Buckminster
there is a clear distinction between running a query and invoking
actions, but in b3, these can be combined. So a dialog for invoking an
action on a discovered unit is very similar to the ways to invoke things
described above. The difference being that it makes sense to show the
builders (and perhaps functions) in the dialog, and let the user choose
what to invoke (as opposed to just running the expressions in a b3
script, or calling a fixed function (e.g. "main"). Do you think all of
the options should be unified into one "invoke b3" dialog?
How can all of the above be done in the simplest possible fashion?
How would you like it to work.
Regards
- henrik
|
|
|
Re: the ways to invoke b3? opinions wanted... [message #603398 is a reply to message #603392] |
Mon, 15 March 2010 08:04 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
|
Hi,
In the IDE, I would like to see a flow that does something like this:
1. The user chooses b3 import.
2. A wizard pops up. Depending on the current selection, the wizard is either empty or shows a b3 script.
3. The wizard assists the user with editing the aspects of a b3 script that pertains to selecting the top component and
the repository configuration.
4. The user is given a choice to save what he has entered as a b3 script.
5. Finish will start a job in a dialog that provides a "Run in background" button.
Another idea that we discussed earlier is to use a special b3 releng project. If we want to encourage that flow, then
perhaps the flow when starting in an empty workspace is not an import, but rather "Create new b3 project". The steps
would then be:
1. Enter all data necessary (project name, initial b3 data)
2. Save the project
3. Do an optional import
That gives the user more time to configure and experiment with the correct repository layout. Once the layout is set and
things are working, he will typically check the project in. In many cases (like SVN, or Git) this check-in will make the
project available using a URL. This URL could then be prompted for if the user selects "Import b3 project from URL" or
similar.
Once some b3 thingies are present in the workspace, I think it should be possible to invoke the public actions that they
provide in much the same way that you can do that with Buckminster today.
- thomas
On 03/14/2010 06:24 PM, Henrik Lindberg wrote:
> Hi,
> Here is a topic where I want your input - the various ways we want to be
> able to invoke the b3 engine.
>
> There are a couple of cases, and situations. Here are some ideas for how
> things could work. They are all quite easy to implement, but what is the
> best approach, and what would be the easiest to use?
>
> So - braindump on ideas...
>
> When the workspace does not contain what user wants to work on, it feels
> natural to get it there via Eclipse -> Import -> "Import using b3
> materialization"
>
> A b3 materialization requires a) a definition of the repositories to
> search, and b) the top unit (i.e. what is requested).
>
> Now, there are many choices how this can be done in the user interface.
> - User could point to a b3 script that contains everything required.
> (i.e. something like:
> repositories { "p2:..."; "git:..."; "svn: ..."; }
> b3.resolveAndMaterialize("org.myorg.mytopComponent");
> )
> - User could point to a b3 script that only contains the repositories
> declaration (and any other setup code the user is interested in), and
> enter the name of the component manually.
>
> - What if this is the first time the user is using b3? User has no
> scripts, and has made no configuration of b3. What should the dialog
> tell the user? By default b3 resolves from workspace and target platform
> (and naturally the b3 file being executed) - the dialog could tell the
> user that additional repository configuration is required (if wanted)
> and then create a b3 file with a template repository config. It would
> probably be possible to discover repositories by looking at the p2
> repositories in p2's preferences, and by looking at repositories
> configured for cvs, svn, git, etc. and then guess on a template (could
> be directed by user choice - showing them). This is perhaps a separate
> wizard that the user is offered a choice to run - the output would be a
> b3 script with a repository configuration that can then be further
> edited as required).
>
> - An alterantive to the above is to just open the b3 editor with a
> minimal template, and let the user insert repository configuration using
> code/completion (i.e. look up repository info from scm's and p2
> preferences).
>
> - User would not have to use the import dialog at all, when there is a
> b3 script defining repositories and having a resolveAndMaterialize call.
> It is enough to simply run the b3 script.
>
> - User preferences for b3 could contain a reference to the equivalence
> of a .b3rc to run by default when running b3 scripts. User could be
> allowed to have several such named scripts. User could then select one
> of them in the import dialog.
>
> - User could open the script editor. When in the script editor, the b3
> code can be executed from within the editor (currently via "run" in the
> outline - but could be placed in a more visible place).
>
> - We can implement a "run as b3", that would be available from the run
> menu, as well as in a context menu for a b3 file. (Some distinction is
> needed between "run in IDE" (i.e. having b3 installed), and "run
> selfhosted / for debugging" - but those are probably quite different as
> the latter requires a launch configuration.
>
> - Currently, invokation of b3 scripts call a function called main. There
> is no notion of just executing expressions at the top level (as in many
> script languages). I think that feature should be added in order to
> simplify when using b3 as a command script (i.e. to do resolve and
> materialize, import, build, etc).
>
> - When running a b3 file from the command line, passing arguments is
> naturally easy - should there be a dialog for this in the UI? i.e.
> typing parameters in a field?
>
> // When there is stuff in the workspace
> - When there are things in the workspace that b3 has translated into
> build units (i.e. plugins, features, etc.) it is possible to invoke
> actions on them. (Similar to how Buckminster does this). In Buckminster
> there is a clear distinction between running a query and invoking
> actions, but in b3, these can be combined. So a dialog for invoking an
> action on a discovered unit is very similar to the ways to invoke things
> described above. The difference being that it makes sense to show the
> builders (and perhaps functions) in the dialog, and let the user choose
> what to invoke (as opposed to just running the expressions in a b3
> script, or calling a fixed function (e.g. "main"). Do you think all of
> the options should be unified into one "invoke b3" dialog?
>
> How can all of the above be done in the simplest possible fashion?
> How would you like it to work.
>
> Regards
> - henrik
>
>
>
|
|
|
Re: the ways to invoke b3? opinions wanted... [message #603414 is a reply to message #603398] |
Wed, 17 March 2010 15:13 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Gabriel BARBIER![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=barbier.gabriel%40gmail.com) Messages: 106 Registered: July 2009 |
Senior Member |
|
|
Hello,
I vote for the idea of a b3 project (b3 nature ?) to describe your application. As it could be identified easily in your
scm as the releng configuration. It could look like a "features" project which is easy to use and configure. And
buckminster already provides a suitable entry to launch build process in contextual menu from "features" project,
perhaps a launch configuration could be used additionnally.
Would it be also possible to populate your eclipse/workspace using b3 informations, like a mix of teamwork project set
and p2 update mechanisms ? That is what I understood when I read "import using b3 materialization".
Regards,
Gabriel
Thomas Hallgren wrote:
> Hi,
> In the IDE, I would like to see a flow that does something like this:
>
> 1. The user chooses b3 import.
> 2. A wizard pops up. Depending on the current selection, the wizard is
> either empty or shows a b3 script.
> 3. The wizard assists the user with editing the aspects of a b3 script
> that pertains to selecting the top component and the repository
> configuration.
> 4. The user is given a choice to save what he has entered as a b3 script.
> 5. Finish will start a job in a dialog that provides a "Run in
> background" button.
>
> Another idea that we discussed earlier is to use a special b3 releng
> project. If we want to encourage that flow, then perhaps the flow when
> starting in an empty workspace is not an import, but rather "Create new
> b3 project". The steps would then be:
>
> 1. Enter all data necessary (project name, initial b3 data)
> 2. Save the project
> 3. Do an optional import
>
> That gives the user more time to configure and experiment with the
> correct repository layout. Once the layout is set and things are
> working, he will typically check the project in. In many cases (like
> SVN, or Git) this check-in will make the project available using a URL.
> This URL could then be prompted for if the user selects "Import b3
> project from URL" or similar.
>
> Once some b3 thingies are present in the workspace, I think it should be
> possible to invoke the public actions that they provide in much the same
> way that you can do that with Buckminster today.
>
> - thomas
>
>
>
> On 03/14/2010 06:24 PM, Henrik Lindberg wrote:
>> Hi,
>> Here is a topic where I want your input - the various ways we want to be
>> able to invoke the b3 engine.
>>
>> There are a couple of cases, and situations. Here are some ideas for how
>> things could work. They are all quite easy to implement, but what is the
>> best approach, and what would be the easiest to use?
>>
>> So - braindump on ideas...
>>
>> When the workspace does not contain what user wants to work on, it feels
>> natural to get it there via Eclipse -> Import -> "Import using b3
>> materialization"
>>
>> A b3 materialization requires a) a definition of the repositories to
>> search, and b) the top unit (i.e. what is requested).
>>
>> Now, there are many choices how this can be done in the user interface.
>> - User could point to a b3 script that contains everything required.
>> (i.e. something like:
>> repositories { "p2:..."; "git:..."; "svn: ..."; }
>> b3.resolveAndMaterialize("org.myorg.mytopComponent");
>> )
>> - User could point to a b3 script that only contains the repositories
>> declaration (and any other setup code the user is interested in), and
>> enter the name of the component manually.
>>
>> - What if this is the first time the user is using b3? User has no
>> scripts, and has made no configuration of b3. What should the dialog
>> tell the user? By default b3 resolves from workspace and target platform
>> (and naturally the b3 file being executed) - the dialog could tell the
>> user that additional repository configuration is required (if wanted)
>> and then create a b3 file with a template repository config. It would
>> probably be possible to discover repositories by looking at the p2
>> repositories in p2's preferences, and by looking at repositories
>> configured for cvs, svn, git, etc. and then guess on a template (could
>> be directed by user choice - showing them). This is perhaps a separate
>> wizard that the user is offered a choice to run - the output would be a
>> b3 script with a repository configuration that can then be further
>> edited as required).
>>
>> - An alterantive to the above is to just open the b3 editor with a
>> minimal template, and let the user insert repository configuration using
>> code/completion (i.e. look up repository info from scm's and p2
>> preferences).
>>
>> - User would not have to use the import dialog at all, when there is a
>> b3 script defining repositories and having a resolveAndMaterialize call.
>> It is enough to simply run the b3 script.
>>
>> - User preferences for b3 could contain a reference to the equivalence
>> of a .b3rc to run by default when running b3 scripts. User could be
>> allowed to have several such named scripts. User could then select one
>> of them in the import dialog.
>>
>> - User could open the script editor. When in the script editor, the b3
>> code can be executed from within the editor (currently via "run" in the
>> outline - but could be placed in a more visible place).
>>
>> - We can implement a "run as b3", that would be available from the run
>> menu, as well as in a context menu for a b3 file. (Some distinction is
>> needed between "run in IDE" (i.e. having b3 installed), and "run
>> selfhosted / for debugging" - but those are probably quite different as
>> the latter requires a launch configuration.
>>
>> - Currently, invokation of b3 scripts call a function called main. There
>> is no notion of just executing expressions at the top level (as in many
>> script languages). I think that feature should be added in order to
>> simplify when using b3 as a command script (i.e. to do resolve and
>> materialize, import, build, etc).
>>
>> - When running a b3 file from the command line, passing arguments is
>> naturally easy - should there be a dialog for this in the UI? i.e.
>> typing parameters in a field?
>>
>> // When there is stuff in the workspace
>> - When there are things in the workspace that b3 has translated into
>> build units (i.e. plugins, features, etc.) it is possible to invoke
>> actions on them. (Similar to how Buckminster does this). In Buckminster
>> there is a clear distinction between running a query and invoking
>> actions, but in b3, these can be combined. So a dialog for invoking an
>> action on a discovered unit is very similar to the ways to invoke things
>> described above. The difference being that it makes sense to show the
>> builders (and perhaps functions) in the dialog, and let the user choose
>> what to invoke (as opposed to just running the expressions in a b3
>> script, or calling a fixed function (e.g. "main"). Do you think all of
>> the options should be unified into one "invoke b3" dialog?
>>
>> How can all of the above be done in the simplest possible fashion?
>> How would you like it to work.
>>
>> Regards
>> - henrik
>>
>>
>>
>
|
|
|
Goto Forum:
Current Time: Sun Sep 01 03:58:47 GMT 2024
Powered by FUDForum. Page generated in 0.03342 seconds
|