We need to port current YAPI functionality to CLI, moving existing code to CommonJS format and refactoring REST API calls integrating https://github.com/Backbase/mosaic-rest-js.

Current bb rest will focus on small targeted API calls, using hand-crafted configuration with command line --flags.

bb yapi will analyze defined XML files, prepare the right submit order and send everything to portalserver.

bb archetype will no longer exist. Instead, developers will use bb generate project.

why:

• LP together with ES is releasing one archetype and this is gonna be the only archetype we should use (bb way of working ;)
• 6.0 there will be no archetypes, but we probably will still have to generate some initial code

how:

• project will be just a template on bb generate which will leverage some functionality from the bb archetype code
• in the future, project will be a normal template

bb link needs to be updated for new banking widgets:
widget-transactions-search
widget-transactions-list
widget-transactions-chart-donut
widget-transactions-overview

Apparently the performance is not good. We need to check wether ronin is loading the modules properly based on the command.

Additionally to docs, we should have some usage demos aside.

I've just installed bb-cli and tried to run bb generate lp12-widget as first command, but it was stuck for a while and didn't generate anything or ask any questions like "Widget title".

After I ran another command, in this case bb generate widget, the previous command did work.

bower link (same as npm link) http://bower.io/docs/api/#link allows to easily install local hosted dependencies instead of remote endpoints. This is very usefull for new component development process, or for testing forked components changes.

Differenct between bb link and bb deploy is that first one will be only creating symlink, insted of copying all the files to deploy target. But this will work only with right Jetty server configuration, as it by default ignores symlink folders.

while using the command import-item if i specify the host through the -H myhost.com it takes by default localhost so i have to always use --host!

If we are planning to release a stable version of the cli, is better to start writing some tests.
I've just written a few, but we need something like https://github.com/gotwarlost/istanbul to test the coverage.

When exporting a portal from Server A, it exports the CS repository with fixed UUID.
Trying to import portal on Server B, it will fail because it cannot find the CS repository with UUID from Server A

Today the export is just compatible with yapi. We need to make it possible to work with the importPortal and also bb rest.

Following previous request #5, we break down our ideas to separate tools and tasks.

We want to have a separate command available in bb-cli, that will allow to easily edit any preferences and configuration of component.

This command will expose next actions:

model add property (we are deprecating preferences)
model add tag
model add section-tag
model add feature

Subjects for discussion:

• name of the command
• default targets for editing files
• additional actions

(note that configuration sync command is a separate tool #14)

I would like to a timestamp in the import-item watch tasks to quickly see when the last time a task was executed

I would like to recursively watch a directory structure to kick off import-item -w on each of the sub directories with a cumulative log file with log lines identifying which item was changed and imported

If we checkout the bb-cli repo, switch to the nightly branch, and run npm link, we get the following error on Windows: https://gist.github.com/stephanepericat/81eef280b60d16e24e14

As we discussed before, we need to have a flexible configuration system, especially for defining CXP portal data (server, portal, context).

Here's a draft of config priority list (starting from less important):

• Defaults
• Global config in ~/.bacbase/config.json
• Config file in CXP project - all commands from nested folders will seek the root of CXP project and check prohect level settings
• Config file in process working directory (component folder, CXP project and etc)
• Command line --flag params

Topic for duscussion: name of the config file and folder name in home dir for system wide settings.

After @mistermark will accept latest PR to mvn-credentials and release updated version, we should point this dependency to original NPM package.

Currently it's pointing to my fork https://github.com/operatino/mvn-credentials.

Add a watch task, for continious copy of forked component to target project. Vital task for development process of new components and testing forked component improvements.

If I try to use the command
bb export --structured
i get an xml where the right file its wrong

<rights>
    <contextItemName>dbe</contextItemName>
    <name>link_1434108783198</name>
    <type>links</type>
    <itemRight>
      <name>link_1434108783198</name>
      <inherited>false</inherited>
    </itemRight>
    <itemRight>
      <0>A</0>
      <1>D</1>
      <2>M</2>
      <3>I</3>
      <4>N</4>
    </itemRight>
    <itemRight>
      <0>g</0>
      <1>r</1>
      <2>o</2>
      <3>u</3>
      <4>p</4>
      <5>_</5>
      <6>a</6>
      <7>d</7>
      <8>m</8>
      <9>i</9>
      <10>n</10>
    </itemRight>
  </rights>

and it should be something like 👍

<rights>
<itemRight name="link_1434108783198" inherited="true">
<securityProfile>ADMIN</securityProfile>
<sid>group_admin</sid>
</itemRight>
</rights>

The generate command should just take care of bootstrapping. Add to the portal should be a separated command. So even if the add to the portal fails, or the user haven't bootstrapped a particular widget, the user can still get the benefit of the cli to add a component to cxp.

As in CXP 5.6 it's possible to store widgets in content services, we need a nice automated way of syncing changes of local widget to remote portal.

We should add some configuration flag, that instead of uploading just model, will zip widget into package and submit it into proper CXP API.

This should also be available with watch.

We should chose one asking module to use - Inquirer or Asking. I personally was using Inquirer all the time, as well as @GuilhermeMedeiros.

@igord, if you don't have a big preference, please migrate your modules to Inquirer.

I am using bb-cli#0.2.2, i tried to generate a module and i succeed it. But i couldn't find model.xml. So when i try to import-item, it says no model.xml found. Should i need to create model.xml manually ? bb-cli will not do it for me as like it did for widget generation ?

Calling bb arch, latest launchpad-archetype does not appear in the list.

Add little beautification (indents) to default export xml format.

Use unified, verbose help dialog for all the commands, based on bb rest (thanks @igord).

Sync flag params like --install (installing to portal via REST) to all related commands.

Current behaviour:

• On get call like bb rest -t portalCatalog -p dashboard, stdout is only the status code

• If -s flag set, the XML output is broken

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><catalog totalSize="0"/>

Expected behaviour:

• On get, it should output the contents of the request
• Saving response to file, escaped XML

Apart from standalone tool, for editing component configuration #13, we need sync command, that will send all the updates of local developed component to remote model.

During execution, command will do following actions:

@igord

1. get properties of the widget from the portal
2. check index.html(if it exists) for g:preference tag its and modification date
3. check config file(if it exists) where properties are stored and its modification date
4. compare values and optionally dates
5. submit changes to the portal

Subjects for discussion:

• name of the command
• default targets for editing files
• should we have watch task for it, or not

Re-test commands on Windows.

On the -h (help) option for every command it should display what the default value is of each option. Not all options are mandatory, but the mandatory ones have a default value. It would help to indicate what the default value of each option would be.

Example from command jekyll --help:

$ jekyll --help
jekyll 2.5.3 -- Jekyll is a blog-aware, static site generator in Ruby

Usage:

  jekyll <subcommand> [options]

Options:
        -s, --source [DIR]  Source directory (defaults to ./)
        -d, --destination [DIR]  Destination directory (defaults to ./_site)
            --safe         Safe mode (defaults to false)
        -p, --plugins PLUGINS_DIR1[,PLUGINS_DIR2[,...]]  Plugins directory (defaults to ./_plugins)
            --layouts DIR  Layouts directory (defaults to ./_layouts)
        -h, --help         Show this message
        -v, --version      Print the name and version
        -t, --trace        Show the full backtrace when an error occurs

Starting from 0.1.8, we're using local forked bower with added HTTP auth. We need this feature to be able installing artifacts as Bower dependencies through bb install.

Here's the PR I made to Bower, to get changes back into original repo bower/bower#1855.

If I run without sourcemaps:

With sourcemaps:

Igor previously finished new command for syncing widget local model changes with remote storage on CXP #14, and now it's called bb auto.

I want to discuss if there's a better name for it, as I think auto is too abstract. I could name all bb cli command as automation tasks.

Vote for your option

1. Leave bb auto name
2. Rename to bb sync
3. bb model
4. Your option

Managing preferences trough the CLI is also required.
The CLI should allow the users to quickly add/remove preferences to the index.html, as well as making the request do modify on CXP.

We can do something like this:

And then we can add the preferences to this widget.
We are able to parse this preferences and make sure those match with CXP.

I will separate the templates from the generate command. However, the templates is gonna still be a dependency for the CLI.

Until we will introduce some mechanism for creating template bundles (or just switch to yeoman), it will be useful to add remote templates support for current bb generate.

This will be very handy for training and syncing with other teams:

bb generate ssh://[email protected]:7999/lp/widget-ng-template.git

Hello,

below is the error we get in Windows when we try to run 'mvn clean install' in the statics folder:

[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Statics :: Launchpad 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ launchpad-collection ---
[INFO]
[INFO] --- frontend-maven-plugin:0.0.24:install-node-and-npm (install node and npm) @ launchpad-collection ---
[INFO] Node v0.10.33 is already installed.
[INFO] Found NPM version 2.1.6
[INFO]
[INFO] --- frontend-maven-plugin:0.0.24:npm (npm install) @ launchpad-collection ---
[INFO] Running 'npm install --color=false' in C:\bb-training\lpwith56\statics\collection-launchpad
[ERROR] npm WARN package.json [email protected] No repository field.
[ERROR] npm ERR! git clone https://github.com/operatino/ronin undefined
[ERROR] npm ERR! git clone https://github.com/operatino/ronin undefined
[ERROR] npm ERR! Windows_NT 6.1.7601
[ERROR] npm ERR! argv "C:\\bb-training\\lpwith56\\statics\\collection-launchpad\\node\\node.exe" "C:\\bb-training\\lpwith56\\statics\\collection-launchpad\\node\\npm\\bin\\npm-cli.js" "install" "--col
or=false"
[ERROR] npm ERR! node v0.10.33
[ERROR] npm ERR! npm  v2.1.6
[ERROR] npm ERR! code ENOGIT
[ERROR]
[ERROR] npm ERR! not found: git
[ERROR] npm ERR!
[ERROR] npm ERR! Failed using git.
[ERROR] npm ERR! This is most likely not a problem with npm itself.
[ERROR] npm ERR! Please check if you have git installed and in your PATH.
[ERROR]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 10.525 s
[INFO] Finished at: 2015-08-18T10:48:05+02:00
[INFO] Final Memory: 9M/122M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:0.0.24:npm (npm install) on project launchpad-collection: Failed to run task: 'npm install --color=false' failed. (error code 1
) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException

When trying to push some XML files created by bb export to a remote server using HTTPS connection, the command bb import doesn't handle unsigned certificates.

The current host connection is setup like:

{
    "scheme": "https",
    "host": "dev.portalhost.com",
    "port": "8545",
    "context": "cxp-manager/",
    "username": "admin",
    "password": "admin",
    "portal": "knd"
}

The certificate of the host is a self-signed one which usually needs to be verified and accepted when accessing the portal in the browser.
I should be able to point to a certificate in the .bbrc file that should bypass the SSL certificate handshake.

As I presented before I have this shell script to generate archetypes from a single command.
I'd like to see bb-cli being extended with this function to poll for the current available backbase archetypes and their version numbers and to generate a mvn archetype from that.

This configuration file should be working the same as .bowerrc (we could re-use their code), so it would be possible to define one .bbrc conf file for whole the project and it's nested folders.

Currently .bbrc conf is taken only from current working dir.

Currently it's not possible to redefine some important options for exporting tools, like port, user and etc.

bb export should read common options file .bbrc to get configuration from there.

I want to create one template per type of widget (the major ones). By doing so, we have a few advantages:

• On boarding is gonna be easier. New front-end developers can look at all types of widgets in one place
• Best practices by default. You don't even need to follow the best practices, if you keep writing in the same style
• Minimize errors
• Sample generated widget (explained below).

I think using the CLI should be the main way of creating a component to Backbase CXP. Like on Ruby on Rails. However, if someone don't want to use the CLI, we can provide a sample of all the widgets on the templates repository. The user can easily download and extract on his/her project and keep taking advantages of the best practices/styleguide/whatever.

When I'm using bb generate lp12-widget to generate a new widget I enter kn as bundle prefix. In the rendered result I'm seeing a class with double prefix as a result:

<body g:onload="requireWidget(__WIDGET__, 'scripts/main')" ng-controller="MainCtrl as mainCtrl" class="lp-kn-main-navigation">

I would expect the result to only render the class here as kn-main-navigation.

After exporting portal through bb export -s and re-importing files back through client-side YAPI, pages are not added to the portal. Need to test what's the conflict both on CXP 5.5 and 5.6.

We should choose one XML to JSON parser, it should jxon or xml2js.

@igord was using jxon quite actively and it's backed by Mozilla https://developer.mozilla.org/en-US/docs/JXON. So I think the choice is obvious :)

so if you forget the -a flag, it could ask at least

not every 3rd party module defines a version, if the version is not present we set to 0.0.0 or something like that