Skip to content

Latest commit

 

History

History
162 lines (124 loc) · 8.46 KB

README.md

File metadata and controls

162 lines (124 loc) · 8.46 KB
Raw

commercetools JVM SDK

CT-logo

The JVM SDK enables developers to use Java 8 methods and objects to communicate with the commercetools platform (formerly SPHERE.IO) rather than using plain HTTP calls. Users gain type-safety, encapsulation, IDE auto completion and an internal domain specific language to discover and formulate valid requests.

JDK compatibility

Tested with JDKs: Oracle 1.8.0_221, OpenJDK 1.8.0_221 and Amazon Corretto 8.222.10.1.

Using the SDK

Installation

Java SDK with Maven

<dependency>
  <groupId>com.commercetools.sdk.jvm.core</groupId>
  <artifactId>commercetools-models</artifactId>
  <version>1.48.0</version>
</dependency>
<dependency>
  <groupId>com.commercetools.sdk.jvm.core</groupId>
  <artifactId>commercetools-java-client</artifactId>
  <version>1.48.0</version>
</dependency>

<!-- experimental -->
<dependency>
  <groupId>com.commercetools.sdk.jvm.core</groupId>
  <artifactId>commercetools-convenience</artifactId>
  <version>1.48.0</version>
</dependency>

Modules

  • commercetools-java-client: alias for commercetools-java-client-ahc-2_0
  • commercetools-java-client-apache-async: uses Apache HTTP client
  • commercetools-java-client-ahc-1_8: uses async HTTP client 1.8
  • commercetools-java-client-ahc-1_9: uses async HTTP client 1.9 (AHC 1.9 is incompatible to AHC 1.8)
  • commercetools-java-client-ahc-2_0: uses async HTTP client 2.0 (do not mix it with the other AHC modules)
  • commercetools-models: models which do not depend to a client implementation

Java SDK with gradle

repositories {
    mavenCentral()
}

dependencies {
    def jvmSdkVersion = "1.48.0"
    compile "com.commercetools.sdk.jvm.core:commercetools-models:$jvmSdkVersion"
    compile "com.commercetools.sdk.jvm.core:commercetools-java-client:$jvmSdkVersion"    
    compile "com.commercetools.sdk.jvm.core:commercetools-convenience:$jvmSdkVersion"
}

Play/Scala SDK with SBT

see https://github.com/commercetools/commercetools-jvm-sdk-scala-add-ons

reactive streams

JVM SDK Contrib

Useful code from external developers

Short-term roadmap

Open Source Examples

  • Sunrise Java - a shop using Play Framework 2.x with Handlebars.java as template engine, Google Guice for DI
  • Donut - single product subscription shop example with Play Framework 2.x and Twirl (Plays default) as template engine
  • commercetools Spring MVC archetype - template integrating the SDK with Spring DI and Spring MVC and showing just some products, thymeleaf template engine
  • Reproducer Example - a demo which shows how to reproduce errors

OSGi support

  • The JVM SDK is OSGi compatible, the module structure is as follows:
    • Bundle sdk-http responsible for http client features, this bundle has the following fragments
      • Fragment sdk-htt-apache-async which provide an implementation of the http clients.
    • Bundle commercetools-sdk-base that contains the base types used for the sdk models, this bundle has the following fragments
      • commercetools-java-client-core
      • commercetools-java-client-apache-async with the previous fragment, it allow to publish a service describing the http client implementation for our API.
      • commercetools-models contains a description model of the commercetools backend and the different actions that alows interaction with it.
  • A demo test that shows a minimum configuration for use in production in an OSGi setup can be found here: DemoOSGiMinimalConfigTest

Stability

  1. Experimental features in the API are also experimental features of the SDK.
    • this includes for example
      • payments
      • nested product attributes
  2. The dependencies will only be updated in the next major version to improve stability. Of course, if bugs in libraries occur, we may need to update.
  3. JVM SDK test dependencies and build tools can be updated because they don't affect the production code.
  4. The JVM SDK has an abstract HTTP client layer so old or new http client versions can be used.
  5. order import is experimental
  6. the search methods with lambda parameters are beta ProductProjectionSearch.ofCurrent().withQueryFilters(m -> m.categories().id().containsAll(categoryIds1))
  7. getters of draft objects might change since new HTTP API features can introduce polymorphism
  8. final classes without public constructors can be transformed into an interface

Executing integration tests

  1. create a NEW API client in the Admin Center (https://admin.sphere.io/YOUR_PROJECT_KEY/developers/clients) with all available permissions (at the time of writing it is manage_payments manage_my_profile manage_orders view_products view_customers view_payments view_types manage_my_orders manage_types manage_customers manage_products view_orders manage_project), the by default created client has just manage_project
  2. in the Admin Center in the "DANGER ZONE" activate the checkbox "ENABLE MESSAGES" within the "Messages Settings"
  3. set "de", "de-AT", "en" as languages in the Admin Center
  4. set at least one country in the Admin Center
  5. create a file "integrationtest.properties" inside the project root
  6. fill it with the credentials of a new empty commercetools project which is for testing;
projectKey=YOUR project key without quotes
clientId=YOUR client id without quotes
clientSecret=YOUR client secret without quotes
apiUrl=https://api.sphere.io
authUrl=https://auth.sphere.io
  1. use ./mvnw verify to execute all integration tests
  2. use ./mvnw -Dit.test=*Product* -DfailIfNoTests=false verify to execute all integration test classes which have "Product" in the class name
  3. for running the unit tests use ./mvnw test
  4. alternatively use your IDE to execute the tests
  5. for some IDEs like IntelliJ IDEA you need to add the Javac flag "-parameters", then also rebuild the whole project to apply the change

[](definitions for the top badges)