An Electrode Native container is completely generated by Electrode Native based on the MiniApps and specific native dependencies you want to include in it. The Container should be published in a central, team shared, location. Keeping it local to your machine has its benefits--for example to launch a MiniApp in the Electrode Native runner, or for development and experimentation use, but for the most part you'll want to publish your Electrode Native container.

Electrode Native supports three distinct publishers for the Electrode Native generated containers: Git, Maven and JCenter:

• The Maven publisher can be used to publish Android containers. Upon generation and compilation of the Electrode Native container, the resulting AAR artifact will be published to a Maven repository of your choice--this can be your own custom Nexus for example.

• The JCenter publisher can be used to publish Android container. Upon generation and compilation of the Electrode Native container, the resulting AAR artifact will be published to your Bintray repository.

• The Git publisher can be used for both the Android or iOS container. When you generate a container, the Git publisher will publish the complete generated container project to a Git repository of your choice--probably GitHub. Please note that in the case of an Android Container, the project itself will be published to Git, not the AAR. Only Maven and JCenter publisher will trigger generation and publication of an AAR.

It is possible to use more than one publisher for your container. For example, you can choose to publish your Android containers both to Maven and GitHub.

A Container is versioned for publication. Every time an Electrode Native container is re-generated, its version is updated. When using Maven or JCenter publishers, the version is part of the maven artifact. When using the Git publisher, a Git tag is used to version the Container.

Because Electrode Native containers include some native code, they are primarily used during the development lifecycle of a mobile application version. You cannot use a newly generated Electrode Native container in a mobile application version that has already been released. When you update a Miniapp for an OTA update, a newly generated Electrode Native container is not included because you cannot ship native code through OTA.

Publishing a container

There are two ways to publish a Container using Electrode Native : directly (explicitly) or indirectly (implicitly). Based on your needs and your context, you might need one way or the other (or both).

Explicitly publishing a Container

Electrode Native offers the [publish-container] command that can be used to publish a container. You don't need a Cauldron to use this command. It is mostly used after generating a container locally through the [create-container] command, in order to publish the locally generated container to a shared repository (git, maven or jcenter) so that anyone with access to the repository can use the container.

It is possible to run the [publish-container] command multiple times for the same container, if you wish to publish the container to different repositories.

The use of the [create-container] / [publish-container] commands combo, will be mostly useful for development and experimentation with Electrode Native. Internally, we are also using these commands on one of our CI jobs that is in charge of generating development Containers for our native application on a scheduled basis. We use [create-container] command, providing all MiniApps GitHub repositories to the command (through the --miniapps option), so that it pulls the latest code of all MiniApps and generate a Container based on the latest changes. The CI job then use [publish-container] to publish the newly generated container to repositories accessed by the native application to retrieve the latest development Container.

Implicitly publishing a Container

If you are using a Cauldron, then a container will automatically be regenerated for any non released version(s) of your native application whenever you make a change to the content of the container of a given native application version (for example adding/removing/updating one or more MiniApp(s) or native dependency(ies) for this Container). In addition to regenerating a new Container to include the changes, the Cauldron will also trigger the publication of this new generated Container, using any publishers configured in the Cauldron, as the next section details.

Please also note that if your cauldron is properly configured for container publication, you can also use the [cauldron regen-container] command to trigger a new generation and publication of a container for a given native application version, even if there are no changes to the content of the container (this can be useful in certain scenarios).

Configuring container publication

The container publication configuration is part of the containerGenerator configuration object stored in a Cauldron, so that it can be shared across users of the Cauldron. If you have properly setup your Cauldron, you can use the [cauldron add publisher] command to add a publisher to a given native application platform. You can use this command multiple times if you wish to add more than one publisher.

The publication configuration object will be stored under in the cauldron document. The following illustrate such a configuration:

"nativeApps":[
   {
      "name":"MyWeatherApp",
      "platforms":[
         {
            "name":"android",
            "config":{
               "containerGenerator":{
                  "containerVersion":"1.0.0",
                  "publishers":[
                     {
                        "name":"git",
                        "url":"[email protected]:user/myweatherapp-android-container.git"
                     },
                     {
                        "name":"maven",
                        "url":"http://user.nexus.repo.com:8081/nexus/content/repositories"
                     },
                     {
                        "name":"jcenter"
                     }
                  ]
               }
            }
         },
         {
            "name":"ios",
            "config":{
               "containerGenerator":{
                  "containerVersion":"1.0.0",
                  "publishers":[
                     {
                        "name":"git",
                        "url":"[email protected]:user/myweatherapp-ios-container.git"
                     }
                  ]
               }
            }
         }
      ]
   }
]

The publishers array contains all the publishers you want to use to publish an Electrode Native container. In example shown above, we want to publish the Electrode Native container of MyWeatherApp Android to three destinations: a GitHub repository, a Maven repository and to JCenter. For the GitHub repository, the code of the Electrode Native container will be published and a Git tag will be used for the version. For the Maven repository, the Electrode Native container will be compiled and the resulting versioned AAR will be published to the Maven and JCenter repositories.

The ern cauldron add publisher command can be used to add a publisher to a Cauldron, rather than adding it manually.

Creating a custom Container publisher

Electrode Native Container publishers are standalone node packages (published to npm) and retrieved dynamically (they are not packaged within Electrode Native itself). In that sense it is quite easy to implement (and eventually distribute) your own Container publisher if needed.

Check our dummy publisher as a reference to get started.

A few things to keep in mind when creating a Container publisher :

• The package name must start by ern-container-publisher-. This is a convention for Electrode Native Container publishers, and is enforced by Electrode Native. Using this convention makes it also simpler for the users as Electrode Native will prefix the publisher name with ern-container-publisher- if needed, so they can use a shorthand name. For example, a publisher can be reffered as foo and Electrode Native will look for a package named ern-container-publisher-foo. Please note that if you are publishing a scoped package for a publisher, Electrode Native will not prepend ern-container-publisher-. So if your publisher is @mycompany/ern-container-publisher-foo, it should be reffered to as this ful package name in Electrode Native, there is no shorthand name.
• You should add a keyword 'ern-container-publisher' in the keywords list of the package.json. This could be used later on to enable Container publishers discovery.
• All you have to implement is a class with two getters get name (to return the name of the publisher) and get platforms (to return the list of supported platforms of the publisher), as well as the publish(config) method. This class should be the default export of the module.
• Once your Container publisher is published to npm, it will be immediately available for Electrode Native users. During development, if you need to try out your publisher before publishing it to npm, you can use ern publish-container command by using an absolute local file system path to your Container publisher module. ern publish-container will call either index.js (or index.ts as we support TypeScript) from your module directory root, or src/index.js if no index was found in root. Thus make sure to name your entry point as index.js/index.ts.