Active Support | Maintenance Support | End of Life |
---|---|---|
28th February, 2022 |
31st December 2023. |
1st January 2024. |
We recommend to use our Java SDK V2, and you can migrate to the new version using our migration guideline.
The JVM SDK enables developers to use Java 8 methods and objects to communicate with the Composable Commerce API 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.
Tested with JDKs: Oracle 1.8.0_221, OpenJDK 1.8.0_221 and Amazon Corretto 8.222.10.1.
- install Java 8
- (since May 19, 2016 new link) Javadoc, there you find also code snippets and insights
<dependency>
<groupId>com.commercetools.sdk.jvm.core</groupId>
<artifactId>commercetools-models</artifactId>
<version>1.61.0</version>
</dependency>
<dependency>
<groupId>com.commercetools.sdk.jvm.core</groupId>
<artifactId>commercetools-java-client</artifactId>
<version>1.61.0</version>
</dependency>
<!-- experimental -->
<dependency>
<groupId>com.commercetools.sdk.jvm.core</groupId>
<artifactId>commercetools-convenience</artifactId>
<version>1.61.0</version>
</dependency>
- https://search.maven.org/#artifactdetails%7Ccom.commercetools.sdk.jvm.core%7Ccommercetools-models%7C1.61.0%7Cjar
- https://search.maven.org/#artifactdetails%7Ccom.commercetools.sdk.jvm.core%7Ccommercetools-java-client%7C1.61.0%7Cjar
- https://search.maven.org/#artifactdetails%7Ccom.commercetools.sdk.jvm.core%7Ccommercetools-convenience%7C1.61.0%7Cjar
commercetools-java-client
: alias for commercetools-java-client-ahc-2_0commercetools-java-client-apache-async
: uses Apache HTTP clientcommercetools-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-java-client-ahc-2_5
: uses async HTTP client 2.5 (AHC 2.5 is incompatible to AHC 2.0)commercetools-java-client-ahc-2_12
: uses async HTTP client 2.12commercetools-models
: models which do not depend to a client implementation
repositories {
mavenCentral()
}
dependencies {
def jvmSdkVersion = "1.61.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"
}
see https://github.com/commercetools/commercetools-jvm-sdk-scala-add-ons
Useful code from external developers
- https://github.com/commercetools/commercetools-jvm-sdk-contrib
- contains also ProductImageUploadCommand from https://docs.commercetools.com/http-api-projects-products.html#upload-a-product-image
- https://github.com/commercetools/commercetools-jvm-sdk/milestones
- https://waffle.io/commercetools/commercetools-jvm-sdk
- 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
- Experimental features in the API are also experimental features of the SDK.
- this includes for example
- payments
- nested product attributes
- this includes for example
- 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.
- JVM SDK test dependencies and build tools can be updated because they don't affect the production code.
- The JVM SDK has an abstract HTTP client layer so old or new http client versions can be used.
- order import is experimental
- the search methods with lambda parameters are beta
ProductProjectionSearch.ofCurrent().withQueryFilters(m -> m.categories().id().containsAll(categoryIds1))
- getters of draft objects might change since new HTTP API features can introduce polymorphism
- final classes without public constructors can be transformed into an interface
- create a NEW API client in the Admin Center (
https://mc.commercetools.com/YOUR_PROJECT_KEY/settings/developer/api-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 justmanage_project
- in the Admin Center in the "DANGER ZONE" activate the checkbox "ENABLE MESSAGES" within the "Messages Settings"
- set "de", "de-AT", "en" as languages in the Admin Center
- set at least one country in the Admin Center
- create a file "integrationtest.properties" inside the project root
- fill it with the credentials of a new empty 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.europe-west1.gcp.commercetools.com
authUrl=https://auth.europe-west1.gcp.commercetools.com
- use
./mvnw verify
to execute all integration tests - use
./mvnw -Dit.test=*Product* -DfailIfNoTests=false verify
to execute all integration test classes which have "Product" in the class name - for running the unit tests use
./mvnw test
- alternatively use your IDE to execute the tests
- 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)