[
https://issues.apache.org/jira/browse/BROOKLYN-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aled Sage updated BROOKLYN-156:
-------------------------------
Description:
`brooklyn-client` allows third-party Java code to make API calls to Brooklyn.
However it is very difficult to use as it carries with it a huge set of
transitive dependencies, which has the effect of enforcing policy on downstream
consumers of Brooklyn. Worse still, some of its dependencies conflict with each
other, which can cause runtime failures.
{noformat}
[INFO] org.apache.brooklyn:brooklyn-rest-client:jar:0.8.0-SNAPSHOT
[INFO] +- org.apache.brooklyn:brooklyn-rest-api:jar:0.8.0-SNAPSHOT:compile
[INFO] | +- org.codehaus.jackson:jackson-core-asl:jar:1.9.13:compile
[INFO] | +- com.sun.jersey.contribs:jersey-multipart:jar:1.18.1:compile
[INFO] | | \- org.jvnet.mimepull:mimepull:jar:1.9.3:compile
[INFO] | +- javax.validation:validation-api:jar:1.0.0.GA:compile
[INFO] | +- com.google.code.findbugs:jsr305:jar:2.0.1:compile
[INFO] | +- commons-lang:commons-lang:jar:2.4:compile
[INFO] | +- com.wordnik:swagger-core_2.9.1:jar:1.0.1:compile
[INFO] | +-
org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:compile
[INFO] | +-
org.apache.brooklyn:brooklyn-utils-common:jar:0.8.0-SNAPSHOT:compile
[INFO] | | +- ch.qos.logback:logback-classic:jar:1.0.7:compile
[INFO] | | | \- ch.qos.logback:logback-core:jar:1.0.7:compile
[INFO] | | +- org.slf4j:jul-to-slf4j:jar:1.6.6:compile
[INFO] | | \-
org.apache.brooklyn:brooklyn-logback-includes:jar:0.8.0-SNAPSHOT:compile
[INFO] | \-
org.apache.brooklyn:brooklyn-utils-rest-swagger:jar:0.8.0-SNAPSHOT:compile
[INFO] | \- com.wordnik:swagger-jaxrs_2.9.1:jar:1.0.1:compile
[INFO] | \- org.scala-lang:scala-library:jar:2.9.1-1:compile
[INFO] +- org.apache.brooklyn:brooklyn-api:jar:0.8.0-SNAPSHOT:compile
[INFO] +- org.jboss.resteasy:resteasy-jaxrs:jar:3.0.8.Final:compile
[INFO] | +-
org.jboss.spec.javax.annotation:jboss-annotations-api_1.1_spec:jar:1.0.1.Final:compile
[INFO] | +- javax.activation:activation:jar:1.1:compile
[INFO] | +- org.apache.httpcomponents:httpclient:jar:4.4.1:compile
[INFO] | +- commons-io:commons-io:jar:2.4:compile
[INFO] | \- net.jcip:jcip-annotations:jar:1.0:compile
[INFO] +- org.jboss.resteasy:resteasy-jackson-provider:jar:3.0.8.Final:compile
[INFO] +- org.jboss.resteasy:jaxrs-api:jar:3.0.8.Final:compile
[INFO] +- org.codehaus.jackson:jackson-mapper-asl:jar:1.9.13:compile
[INFO] +- org.codehaus.jackson:jackson-jaxrs:jar:1.9.13:compile
[INFO] +- org.codehaus.jackson:jackson-xc:jar:1.9.13:compile
[INFO] +- com.sun.jersey:jersey-core:jar:1.18.1:compile
[INFO] +- org.eclipse.jetty:jetty-webapp:jar:8.1.17.v20150415:compile
[INFO] | +- org.eclipse.jetty:jetty-xml:jar:8.1.17.v20150415:compile
[INFO] | | \- org.eclipse.jetty:jetty-util:jar:8.1.17.v20150415:compile
[INFO] | \- org.eclipse.jetty:jetty-servlet:jar:8.1.17.v20150415:compile
[INFO] | \- org.eclipse.jetty:jetty-security:jar:8.1.17.v20150415:compile
[INFO] +- org.eclipse.jetty:jetty-server:jar:8.1.17.v20150415:compile
[INFO] | +- org.eclipse.jetty:jetty-continuation:jar:8.1.17.v20150415:compile
[INFO] | \- org.eclipse.jetty:jetty-http:jar:8.1.17.v20150415:compile
[INFO] | \- org.eclipse.jetty:jetty-io:jar:8.1.17.v20150415:compile
[INFO] +- com.google.guava:guava:jar:17.0:compile
[INFO] +- org.slf4j:slf4j-api:jar:1.6.6:compile
[INFO] +- javax.ws.rs:jsr311-api:jar:1.1.1:compile
[INFO] +- com.google.code.gson:gson:jar:2.3:compile
{noformat}
Some examples of problems here:
* These dependencies contain within them conflicting implementations of the
javax.ws classes. This is a major problem which causes runtime errors if the
"wrong" version ends up at the front of the classpath.
* It is bringing in Jetty, a web server
* It depends on some Jersey components. If the downstream project is also
using Jersey, then it must use the same version. Similar issues exist for
Jackson, SLF4J, Jetty and others.
* It brings in logback. If the downstream project is using SLF4J, it is
forced to use logback as an implementation.
brooklyn-client needs to be *much* lighter than it currently is, it must not
contain conflicting dependencies, and it should have as small a dependency
footprint as possible.
was:
`brooklyn-client` allows third-party Java code to make API calls to Brooklyn.
However it is very difficult to use as it carries with it a huge set of
transitive dependencies, which has the effect of enforcing policy on downstream
consumers of Brooklyn. Worse still, some of its dependencies conflict with each
other, which can cause runtime failures.
[INFO] org.apache.brooklyn:brooklyn-rest-client:jar:0.8.0-SNAPSHOT
[INFO] +- org.apache.brooklyn:brooklyn-rest-api:jar:0.8.0-SNAPSHOT:compile
[INFO] | +- org.codehaus.jackson:jackson-core-asl:jar:1.9.13:compile
[INFO] | +- com.sun.jersey.contribs:jersey-multipart:jar:1.18.1:compile
[INFO] | | \- org.jvnet.mimepull:mimepull:jar:1.9.3:compile
[INFO] | +- javax.validation:validation-api:jar:1.0.0.GA:compile
[INFO] | +- com.google.code.findbugs:jsr305:jar:2.0.1:compile
[INFO] | +- commons-lang:commons-lang:jar:2.4:compile
[INFO] | +- com.wordnik:swagger-core_2.9.1:jar:1.0.1:compile
[INFO] | +-
org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:compile
[INFO] | +-
org.apache.brooklyn:brooklyn-utils-common:jar:0.8.0-SNAPSHOT:compile
[INFO] | | +- ch.qos.logback:logback-classic:jar:1.0.7:compile
[INFO] | | | \- ch.qos.logback:logback-core:jar:1.0.7:compile
[INFO] | | +- org.slf4j:jul-to-slf4j:jar:1.6.6:compile
[INFO] | | \-
org.apache.brooklyn:brooklyn-logback-includes:jar:0.8.0-SNAPSHOT:compile
[INFO] | \-
org.apache.brooklyn:brooklyn-utils-rest-swagger:jar:0.8.0-SNAPSHOT:compile
[INFO] | \- com.wordnik:swagger-jaxrs_2.9.1:jar:1.0.1:compile
[INFO] | \- org.scala-lang:scala-library:jar:2.9.1-1:compile
[INFO] +- org.apache.brooklyn:brooklyn-api:jar:0.8.0-SNAPSHOT:compile
[INFO] +- org.jboss.resteasy:resteasy-jaxrs:jar:3.0.8.Final:compile
[INFO] | +-
org.jboss.spec.javax.annotation:jboss-annotations-api_1.1_spec:jar:1.0.1.Final:compile
[INFO] | +- javax.activation:activation:jar:1.1:compile
[INFO] | +- org.apache.httpcomponents:httpclient:jar:4.4.1:compile
[INFO] | +- commons-io:commons-io:jar:2.4:compile
[INFO] | \- net.jcip:jcip-annotations:jar:1.0:compile
[INFO] +- org.jboss.resteasy:resteasy-jackson-provider:jar:3.0.8.Final:compile
[INFO] +- org.jboss.resteasy:jaxrs-api:jar:3.0.8.Final:compile
[INFO] +- org.codehaus.jackson:jackson-mapper-asl:jar:1.9.13:compile
[INFO] +- org.codehaus.jackson:jackson-jaxrs:jar:1.9.13:compile
[INFO] +- org.codehaus.jackson:jackson-xc:jar:1.9.13:compile
[INFO] +- com.sun.jersey:jersey-core:jar:1.18.1:compile
[INFO] +- org.eclipse.jetty:jetty-webapp:jar:8.1.17.v20150415:compile
[INFO] | +- org.eclipse.jetty:jetty-xml:jar:8.1.17.v20150415:compile
[INFO] | | \- org.eclipse.jetty:jetty-util:jar:8.1.17.v20150415:compile
[INFO] | \- org.eclipse.jetty:jetty-servlet:jar:8.1.17.v20150415:compile
[INFO] | \- org.eclipse.jetty:jetty-security:jar:8.1.17.v20150415:compile
[INFO] +- org.eclipse.jetty:jetty-server:jar:8.1.17.v20150415:compile
[INFO] | +- org.eclipse.jetty:jetty-continuation:jar:8.1.17.v20150415:compile
[INFO] | \- org.eclipse.jetty:jetty-http:jar:8.1.17.v20150415:compile
[INFO] | \- org.eclipse.jetty:jetty-io:jar:8.1.17.v20150415:compile
[INFO] +- com.google.guava:guava:jar:17.0:compile
[INFO] +- org.slf4j:slf4j-api:jar:1.6.6:compile
[INFO] +- javax.ws.rs:jsr311-api:jar:1.1.1:compile
[INFO] +- com.google.code.gson:gson:jar:2.3:compile
Some examples of problems here:
* These dependencies contain within them conflicting implementations of the
javax.ws classes. This is a major problem which causes runtime errors if the
"wrong" version ends up at the front of the classpath.
* It is bringing in Jetty, a web server
* It depends on some Jersey components. If the downstream project is also
using Jersey, then it must use the same version. Similar issues exist for
Jackson, SLF4J, Jetty and others.
* It brings in logback. If the downstream project is using SLF4J, it is
forced to use logback as an implementation.
brooklyn-client needs to be *much* lighter than it currently is, it must not
contain conflicting dependencies, and it should have as small a dependency
footprint as possible.
> brooklyn-client project has horrendous dependency issues
> --------------------------------------------------------
>
> Key: BROOKLYN-156
> URL: https://issues.apache.org/jira/browse/BROOKLYN-156
> Project: Brooklyn
> Issue Type: Bug
> Affects Versions: 0.7.0, 0.8.0
> Reporter: Richard Downer
>
> `brooklyn-client` allows third-party Java code to make API calls to Brooklyn.
> However it is very difficult to use as it carries with it a huge set of
> transitive dependencies, which has the effect of enforcing policy on
> downstream consumers of Brooklyn. Worse still, some of its dependencies
> conflict with each other, which can cause runtime failures.
> {noformat}
> [INFO] org.apache.brooklyn:brooklyn-rest-client:jar:0.8.0-SNAPSHOT
> [INFO] +- org.apache.brooklyn:brooklyn-rest-api:jar:0.8.0-SNAPSHOT:compile
> [INFO] | +- org.codehaus.jackson:jackson-core-asl:jar:1.9.13:compile
> [INFO] | +- com.sun.jersey.contribs:jersey-multipart:jar:1.18.1:compile
> [INFO] | | \- org.jvnet.mimepull:mimepull:jar:1.9.3:compile
> [INFO] | +- javax.validation:validation-api:jar:1.0.0.GA:compile
> [INFO] | +- com.google.code.findbugs:jsr305:jar:2.0.1:compile
> [INFO] | +- commons-lang:commons-lang:jar:2.4:compile
> [INFO] | +- com.wordnik:swagger-core_2.9.1:jar:1.0.1:compile
> [INFO] | +-
> org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:compile
> [INFO] | +-
> org.apache.brooklyn:brooklyn-utils-common:jar:0.8.0-SNAPSHOT:compile
> [INFO] | | +- ch.qos.logback:logback-classic:jar:1.0.7:compile
> [INFO] | | | \- ch.qos.logback:logback-core:jar:1.0.7:compile
> [INFO] | | +- org.slf4j:jul-to-slf4j:jar:1.6.6:compile
> [INFO] | | \-
> org.apache.brooklyn:brooklyn-logback-includes:jar:0.8.0-SNAPSHOT:compile
> [INFO] | \-
> org.apache.brooklyn:brooklyn-utils-rest-swagger:jar:0.8.0-SNAPSHOT:compile
> [INFO] | \- com.wordnik:swagger-jaxrs_2.9.1:jar:1.0.1:compile
> [INFO] | \- org.scala-lang:scala-library:jar:2.9.1-1:compile
> [INFO] +- org.apache.brooklyn:brooklyn-api:jar:0.8.0-SNAPSHOT:compile
> [INFO] +- org.jboss.resteasy:resteasy-jaxrs:jar:3.0.8.Final:compile
> [INFO] | +-
> org.jboss.spec.javax.annotation:jboss-annotations-api_1.1_spec:jar:1.0.1.Final:compile
> [INFO] | +- javax.activation:activation:jar:1.1:compile
> [INFO] | +- org.apache.httpcomponents:httpclient:jar:4.4.1:compile
> [INFO] | +- commons-io:commons-io:jar:2.4:compile
> [INFO] | \- net.jcip:jcip-annotations:jar:1.0:compile
> [INFO] +- org.jboss.resteasy:resteasy-jackson-provider:jar:3.0.8.Final:compile
> [INFO] +- org.jboss.resteasy:jaxrs-api:jar:3.0.8.Final:compile
> [INFO] +- org.codehaus.jackson:jackson-mapper-asl:jar:1.9.13:compile
> [INFO] +- org.codehaus.jackson:jackson-jaxrs:jar:1.9.13:compile
> [INFO] +- org.codehaus.jackson:jackson-xc:jar:1.9.13:compile
> [INFO] +- com.sun.jersey:jersey-core:jar:1.18.1:compile
> [INFO] +- org.eclipse.jetty:jetty-webapp:jar:8.1.17.v20150415:compile
> [INFO] | +- org.eclipse.jetty:jetty-xml:jar:8.1.17.v20150415:compile
> [INFO] | | \- org.eclipse.jetty:jetty-util:jar:8.1.17.v20150415:compile
> [INFO] | \- org.eclipse.jetty:jetty-servlet:jar:8.1.17.v20150415:compile
> [INFO] | \- org.eclipse.jetty:jetty-security:jar:8.1.17.v20150415:compile
> [INFO] +- org.eclipse.jetty:jetty-server:jar:8.1.17.v20150415:compile
> [INFO] | +- org.eclipse.jetty:jetty-continuation:jar:8.1.17.v20150415:compile
> [INFO] | \- org.eclipse.jetty:jetty-http:jar:8.1.17.v20150415:compile
> [INFO] | \- org.eclipse.jetty:jetty-io:jar:8.1.17.v20150415:compile
> [INFO] +- com.google.guava:guava:jar:17.0:compile
> [INFO] +- org.slf4j:slf4j-api:jar:1.6.6:compile
> [INFO] +- javax.ws.rs:jsr311-api:jar:1.1.1:compile
> [INFO] +- com.google.code.gson:gson:jar:2.3:compile
> {noformat}
> Some examples of problems here:
> * These dependencies contain within them conflicting implementations of the
> javax.ws classes. This is a major problem which causes runtime errors if the
> "wrong" version ends up at the front of the classpath.
> * It is bringing in Jetty, a web server
> * It depends on some Jersey components. If the downstream project is also
> using Jersey, then it must use the same version. Similar issues exist for
> Jackson, SLF4J, Jetty and others.
> * It brings in logback. If the downstream project is using SLF4J, it is
> forced to use logback as an implementation.
> brooklyn-client needs to be *much* lighter than it currently is, it must not
> contain conflicting dependencies, and it should have as small a dependency
> footprint as possible.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
