Migrating existing adapters to work under MobileFirst Server V8.0.0
improve this page | report issueOverview
Starting with v8.0 of MobileFirst Server, adapters are Maven projects. Learn how to upgrade adapters that were developed under earlier versions of MobileFirst Server.
This page describes the steps to take to migrate adapters that were developed to work with MobileFirst Server V6.2 or later so that they work with MobileFirst Server v8.0
To start, study the changes in adapter APIs that are described in Deprecated features and API elements and Server-side API changes in v8.0.
- Under certain conditions, existing adapters work as-is with MobileFirst Server v8.0. See Using older adapters as-is under MobileFirst Server V8.0.
- In most cases, you need to upgrade the adapters. For Java™ adapters, see Migrating Java adapters to Maven projects for MobileFirst Server v8.0. For JavaScript adapters, see Migrating JavaScript adapters to Maven projects for MobileFirst Server v8.0.
Migration of adapters using the migration assistance tool
Migration of existing adapters is made easier with migration assistance tool. See here, for more information.
Using older adapters as-is under MobileFirst Server v8.0
An existing adapter can be deployed as-is under MobileFirst Server v8.0, unless it matches any of the following criteria:
Adapter type | Condition |
---|---|
Java | Uses the PushAPI or SecurityAPI interfaces |
JavaScript |
|
Migrating Java adapters to Maven projects for MobileFirst Server v8.0
- Create a Maven adapter project with the archetype adapter-maven-archetype-java. When setting the parameter artifactId use the adapter name and for the parameter package use the same package as the one in the existing Java adapter. For more information, see Creating Java adapters.
- Overwrite the adapter-descriptor file (adapter.xml) in the src/main/adapter-resources folder of the new adapter project that you created in Step 1. For more details about the descriptor, see The Java adapter-descriptor file.
-
Remove all the files from the src/main/java folder of your new adapter project. Then, copy all the Java files from the src/ folder of your old Java adapter project, but preserve the same folder structure. Copy all the non-Java files from the src folder of the old adapter to the src/main/resources folder of the new adapter. By default, src/main/resources does not exist, so if the adapter contains non-Java files, create it. For the changes in Java adapter APIs, see Server-side API changes in v8.0.
The following diagrams illustrate the structure of adapters up to v7.1 and Maven adapters, starting from v8.0:
├── adapters │ └── RSSAdapter │ ├── RSSAdapter.xml │ ├── lib │ └── src │ └── com │ └── sample │ ├── RSSAdapterApplication.java │ └── RSSAdapterResource.java
New structure of a Java adapter:
├── pom.xml ├── src │ └── main │ ├── adapter-resources │ │ └── adapter.xml │ └── java │ └── com │ └── sample │ ├── RSSAdapterApplication.java │ └── RSSAdapterResource.java
- Using either of the following methods, add any JAR files that are not in the Maven repository:
- Add the JAR files to a local repository, as described in Guide to installing third-party JARs, then add them to dependencies element.
- Add the JAR files to the dependencies element by using the systemPath element. For more information, see Introduction to the Dependency Mechanism.
Migrating JavaScript adapters to Maven projects for MobileFirst Server v8.0
- Create a Maven adapter project with the archetype adapter-maven-archetype-http or adapter-maven-archetype-sql. When setting the parameter artifactId use the adapter name. For more information, see Creating JavaScript adapters.
- Overwrite the adapter-descriptor file (adapter.xml) in the src/main/adapter-resources folder of the new adapter project that you created in Step 1. For details about the descriptor, see The JavaScript adapter-descriptor file.
- Overwrite the JavaScript files in the src/main/adapter-resources/js folder of your new adapter project.
Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.