Skip to content

Document usage of client libraries #293

@laurentpellegrino

Description

@laurentpellegrino

If standard build automation tools for Java (e.g. Gradle, Maven, etc.) or even some dependency managers such as Ivy are used, then we have some client packages.

It simply consists in adding ActiveEon repository and using dependency rest-smartproxy or rest-client, etc.

If the goal is to get all dependencies offline, this is also pretty easy. Below is an example with Gradle by adding a task:

task copyToLib(type: Copy) {
    into "$buildDir/output/lib"
    from configurations.runtime
}

and here with Maven:

mvn dependency:copy-dependencies

For sure all that should be documented and ideally dependencies published on Maven Central or Jcenter for global availability. However, working with such repositories when using an SDK is quite standard nowadays.

It should also be mentioned and highlighted that scheduler client libraries MUST NOT be included in the final JAR or WAR file that is generated and put in addons or dist/war folder of the Scheduler.

An issue, that is not really within the scope of this issue, is about the transitive dependencies that are fetched by client modules such as rest-smartproxy or rest-client. These last require programming-core by transitivity, which is ugly for a REST client module whose the aim is to avoid such coupling.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions