You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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:
and here with Maven:
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.
The text was updated successfully, but these errors were encountered: