Managing Applications¶
EDP offers much functionality to manage applications: users can upload new bundles into runtimes, have them validated, accelerated, installed, or uninstalled. Users can also steer these components’ activities by starting or stopping them.
Once in the Features & Bundles area, for each selected environment, authorized users can create upload bundles, new feature versions and group them within other features. They can browse and inspect a list of all available bundles in various phases, either as “snapshots” that still need to be tested or as final versions.
Note that snapshot bundles can only be uploaded in the “Develop” environment, while full version bundles can be uploaded in “Staging” and “Release”.
Each artifact may be available in several versions, and each version can have different system requirements. Older versions of bundles and features are kept in the list since they could still be used by runtimes or be dependencies for other bundles or features. Likewise, a bundle can have several accelerations associated with it, and those could be useful for different platform requirements.
Features and bundles can be aligned in a predefined (yet configurable) life cycle, referred to in EDP as bundle pipelines. Each bundle artifact that is added to EDP shall pass all required steps of a preconfigured pipeline.
Populate the Feature¶
After creating a new feature, select it in the left column and press “+” to start an initial version, by giving it a name and choosing a status, e.g. “draft”. After saving this version is generated, and you can populate it with bundles or other features. In order to do that, just click on the “pencil” icon and click the boxes of the corresponding bundles or features that you wish to include in the new version. After saving the new feature will be listed: unfold to see its building blocks.
Upload bundles, create and edit features. Open in new tab to see full-size image.¶
State & Status¶
EDP presents validation for bundle artifacts in different ways, depending on the area of the web portal users find themselves in.
In Runtimes, users can track the OSGi life cycle state of the bundles in a specific device, like “ACTIVE” or “RESOLVED”.
Under Features & Bundles, the availability lists permit filtering only the components that have “published” or “draft” status, for example. When a specific bundle or a feature version is selected, their status can be selected out of a drop-down menu containing the values draft, published, rejected or archived. Once a bundle or a feature is rejected, this component can be archived, but it can no longer be deployed or selected as building block to new features.
While users can manually change a software component’s status, automatic adjustments can be triggered out of bundle pipelines. There, status determines which action nodes are allowed: for example, artifacts can only be deployed after being published. Similarly the status “published” is a prerequisite for a component to be promoted, i.e. transition to the environments staging or release. On the other, in the environment develop drafts are deployable.
Besides general states like STARTED or FINISHED, in the Bundle Pipeline area users will find information in reference of some user tasks applied to the artifacts. This information is displayed when, in a BP family, users choose to view the execution of a specific revision. It can refer to tasks around acceleration or deployment. For example: ACCELERATION.STARTED, ACCELERATION.FAILURE, ACCELERATION.TIMEOUT, ACCELERATION.SUCCESS, DEPLOYMENT.STARTED or DEPLOYMENT.FAILURE.
Bundle Acceleration¶
Each artifact can have accelerated versions, intended for a particular platform. The presence of an accelerated version in the bundle list shows that the bundle has successfully completed an acceleration step in the bundle pipeline and can be downloaded for use on devices of a specific architecture. By acceleration step is understood that the aicas tool JARAccelerator was run with predefined parameters to optimize the execution performance.
Acceleration
Jamaica JARAccelerator (aka JARA) is an aicas tool that takes a bundle’s JAR and produces a new, accelerated file with improved execution times for a specific target. This file incorporates the original source, complemented with a shared library containing methods in classes of the JAR that have been compiled to machine code. The library is identified with the platform for which it is intended. When a class from the accelerated JAR is loaded by an executable program running on a matching platform, the shared library is automatically linked with that program. The integration of JARA is possible only for bundles running on devices powered by aicas’ JamaicaAMS.
The definition of platforms that support bundle acceleration is a task that EDP administrators perform right after deployment. By clicking on Jara Targets in the Settings menu, users with the required permissions can define on which platforms acceleration will be possible.
By setting a JARA target, mandatory fields must be completed, like family and revision. The field classifier shows a string composed of information like platform and variant. Like other mandatory parameters, the classifier value is defined in the AWS console, during EDP deployment, in the configuration of the AWS cloud formation template. This information can be later edited or deleted.
Adding a Fargate task to define JARA targets¶
Currently, EDP supports linux-x86_64-4 as JARA classifier, where “4” represents the Application Binary Interface (ABI) version 4. In the future other platforms are planned to allow dynamic acceleration.
Here are some relevant aspects around bundle acceleration:
By the time a bundle is uploaded in EDP, the portal automatically accelerates this bundle for x86_64, which is the default architecture for optimization purposes.
When users select a device and choose to install a bundle, EDP preferably installs an accelerated bundle, if applicable. Users can verify whether a specific bundle has accelerated artifacts by selecting it in the bundle list shown in Features & Bundles.
For a target, for which no accelerated version of the chosen bundle is available, EDP will install a regular, not accelerated version.
Uploading a Bundle in Web¶
To upload a bundle in EDP’s web portal, access Features & Bundles and choose the
Upload option. After a bundle is selected, EDP will access its manifest, expecting to find
the OSGi headers symbolic name and version, which are considered mandatory. In case those
headers are missing, EDP will reject the JAR as being a non valid OSGi bundle.
Please note that
An uploaded bundle cannot be deleted once its status is set to “published”, as it still could be used by any runtime or another bundle.
Using Maven¶
Sometimes users who are developing bundles from their local environment setups, for example an IDE like Eclipse or IntelliJ, might want to use Maven to deploy their bundles directly to EDP. To do that, users must start by creating a token.
In the menu Settings, choose Maven tokens and “Add a token”. Then enter a name and
expiration date. Click Save and your personal token will be generated. This token needs to
be stored, since it will be used by Maven for the secure authentication operations required to
upload bundles.
Maven Configuration¶
Once the token is created, it is necessary to configure Maven. This can be done by entering all Maven-related information in the IDEs’ Maven plugin settings. Another option would be to use the command line interface, as shown here.
In this case, Maven’s default settings need to be properly changed. Add the following to your Maven settings.xml, replacing XXX with the proper values.
<settings>
<servers>
<server>
<id>jedp</id>
<configuration>
<httpHeaders>
<property>
<name>jedp-mvn-user</name>
<value>XXX</value>
</property>
<property>
<name>jedp-mvn-org</name>
<value>XXX</value>
</property>
<property>
<name>jedp-mvn-token-name</name>
<value>XXX</value>
</property>
<property>
<name>jedp-mvn-token</name>
<value>XXX</value>
</property>
</httpHeaders>
</configuration>
</server>
</servers>
</settings>
If you do not want or cannot use the global settings, you can provide settings.xml with the following mvn command:
mvn -s <path>/settings.xml -U clean deploy
Changing pom.xml¶
When Maven is used, each bundle is packed with a pom.xml file that specifies its properties and dependencies. Change the OSGi bundle’s pom.xml accordingly, updating host and environment.
<project>
<repositories>
<repository>
<id>jedp</id>
<url>http://<your-company>.dev.jedp.de/maven/develop</url>
</repository>
</repositories>
<distributionManagement>
<repository>
<id>jedp</id>
<url>http://<your-company>.dev.jedp.de/maven/develop</url>
</repository>
</distributionManagement>
</project>
From the point of view of developers, establishing a direct bridge between their IDEs and EDP using Maven is a faster way to upload their final artifacts.
With a single command they can clean, package and deploy a project, with no extra steps. Otherwise they would need to work on the code, build and export the jar; then go to EDP portal, choose Application, click “upload”, select the bundle and confirm. Only then the bundle would be listed in the EDP portal, reported as uploaded by the respective user.
Also in case the developer needs to upload a same bundle many times, after modifications or bug fixes, the direct IDE-EDP way speeds up the process considerably.
