Publication

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. It can also be used for automation purposes (CI) in some contexts.

Implicitly publishing a Container

Using a Cauldron, a Container will automatically be regenerated for any non released version(s) of your native application whenever a change is made 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, or regenerating a Container that is tracking MiniApps branches that have new commits). 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

Container publishers are part of the pipeline array of the containerGenerator configuration stored in a Cauldron, so that it can be shared across users of the Cauldron.

All Cauldron configuration is kept in configuration files stored in the config directory of the Cauldron.

The following illustrate such a configuration:

{
"containerGenerator":{
"pipeline":[
{
"name":"ern-container-publisher-git",
"url":"[email protected]:username/myweatherapp-android-container.git"
},
{
"name":"ern-container-publisher-maven",
"url": "https://repo.example.org/content/repositories"
},
{
"name":"ern-container-publisher-jcenter"
}
]
}

The pipeline array contains all the publishers (and transformers) you want to use to publish an Electrode Native container. In the 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.

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.

  • 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.