mcupak / beacon-network-client Goto Github PK

It would be useful to be able to run the test suite against a real (not mocked) server to check for API compatibility as we make changes on both client and server side in the future. Thanks to the way the current tests are designed, it seems like the integration tests could reuse a lot of the existing stuff.

I would imagine this as follows. The current unit tests stay as they are and are run by default with the default profile. Integration tests will have their own maven profile, not active by default. When this profile is specified, mocking would not be used. The URL of the server would default to https://beacon-network.org/api/, and could be overridden by supplying a system property. This can be specified in surefire configuration with something like this:

<plugin>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <systemPropertyVariables>
            <property>
                <name>...</name>
                <value>...</value>
            </property>
        </systemPropertyVariables>
    </configuration>
</plugin>

Implement a Java library talking to the Beacon Network API. The goal here is to create a jar file, which can be included as a dependency in your project and utilized to execute queries against the Beacon Network API.

Links:

• Beacon Network API
• Beacon Network API docs (we have interactive Swagger-based docs as well, please contact mcupak for access)

Requirements:

• Reuse objects (DTOs) exposed through the Beacon Network API (a private module now, but can be shared. Contact mcupak).
• Beacon Network provides JSON and XML APIs. The library should utilize the JSON API.
• Beacon Network uses JAX-RS and Moxy to expose DTOs. Using these technologies could make things easier.
• API host (port, context) should be configurable from the application using the library.
• Multi-module Maven project with 2 modules - API (interfaces providing API methods, most of which will return DTOs) and IMPL (the actual library implementation). API module should not have any non-trivial depencies on external libraries. The application using the library should include the API module as a compile time and IMPL module as a runtime dependency.
• Errors should be handled through exceptions (depending on HTTP status codes returned from the Beacon Network API).
• Unit tests.
• Documentation (README, javadoc).

Set up Javadoc Maven plugin, so that we can generate documentation. Fix Javadoc-related errors/warning.

https://maven.apache.org/plugins/maven-javadoc-plugin/