aepp-sdk-java
Search…
How to contribute?
Building the SDK
Prerequisites
- Docker
- Gradle
The SDK heavily makes use of the lombok IDE plugin to hide glue code, especially getters, setters, builders and helper methods and helps to keep the classes clean and focus on the logic. The plugin is needed in your IDE of choice to automatically create the necessary methods in the background
- latest version of the SDK (dev branch):
1
git clone [email protected]:kryptokrauts/aepp-sdk-java.git
2
git checkout dev
Copied!
Development environment
The SDK is shipped with multiple preconfigured docker containers to support integration testing and debugging. In order to start them just call docker-compose:
1
docker-compose up -d
Copied!
After pulling the images you should see the following instances up and running:
- aeternal - local middleware that provides aggregated data and websockets
- compiler - local aeternity node to provide the sophia compiler functions
- node - local aeternity node to provide the protocol functions
- proxy - a nginx httpd to expose the aeternity nodes as well as the goggles app to the running host
The services then can be accessed through the following URLs.
Function
URL
aeternal REST API
http://aeternal.localhost/api
OR
http://localhost:8080/api
node REST API
http://localhost/api
compiler REST API
http://compiler.localhost/api
OR
http://localhost:3080
If the the docker-machine can't be accessed through localhost (e.g. when using docker-toolbox for windows) you can set the host
aelocal in your /etc/hosts file and point to the IP of your docker-machine. Of course you would need to use aelocal instead of localhost to access the services.By default, the aeternity node starts with debug logging mode which is defined in the docker/aeternity.yaml. In order to access the node logs, use docker-compose to connect into the container using the following script
1
docker-compose exec node sh
2
bash
3
cd log/
4
tail -100f aeternity.log
Copied!
Generate API clients
In order to develop and test the SDK one need to generate the necessary Java classes for defined in the swagger endpoint definition once (and every time, the swagger definition is updated).
1
# if set to true the sources will be generated on each build
2
export AETERNITY_GENERATE_SOURCES=true # unix
3
SET AETERNITY_GENERATE_SOURCES=true # windows
4
5
# if the above env-variable is missing or set to false the sources
6
# need to be generated manually be executing this command
7
gradle generateApiClient
Copied!
Testing the SDK
The SDK ships with two kinds of tests
- unit tests, which run independently of a node and prove basic functions and services
- integration tests, which need a running aeternity node and validate posted transactions of all currently supported types
In order to run the integration tests you need to define the URLs to the local aeternity and compiler node. This is done using the following environment variables (example is provided for local environment):
1
## using localhost
2
AETERNAL_BASE_URL = http://aeternal.localhost
3
AETERNITY_BASE_URL = http://localhost
4
COMPILER_BASE_URL = http://compiler.localhost
5
6
## using aelocal (by editing /etc/hosts)
7
AETERNAL_BASE_URL = http://aeternal.aelocal
8
AETERNITY_BASE_URL = http://aelocal
9
COMPILER_BASE_URL = http://compiler.aelocal
10
11
## using IP
12
AETERNAL_BASE_URL = http://localhost:8080
13
AETERNITY_BASE_URL = http://localhost
14
COMPILER_BASE_URL = http://localhost:3080
Copied!
The tests can be run within your IDE of choice by using the following gradle tasks
1
gradle test
2
gradle integrationTest
Copied!
The task
integrationTest requires the running docker-compose setup.Contributing to the SDK
All contributions to the SDK must be linked to an issue within the aepp-sdk-java project - either pick one or create a new one if you miss a feature or want to fix / enhance current services.
The next step is to create a feature branch which must be named according to the ticket
1
feature/<ticket-number>-<further-description>
Copied!
Integrationtests should extend the BaseTest class which especially provides some convinent functions for running tests using the underlying vertx framework. Test methods can thus make use of the
1
executeTest(TestContext context, Consumer<?> method)
Copied!
1
@Test
2
public void testMyLogic(TestContext context) {
3
this.executeTest(
4
context,
5
t -> {
6
<Custom Test Logic>
7
context.assertTrue(result.getBalance().compareTo(ZERO) == 1);
8
});
9
}
Copied!
After implementing the feature / enhancement / fix and providing an appropriate amount of tests / integration tests format your code using the google formatter pattern (if you don't already use it) by running the following gradle command. Unformated / wrong formatted as well as untested code will be rejected.
1
gradle googleJavaFormat
Copied!
Then push your branch and create a pull request. After successful review, the PR will be merged into the dev branch and later into the master branch, from where it will be released.
Last modified 2yr ago