+1 this is a great idea for downstream systems like PCC. +1 for bom. It's just so much easier
On Fri, Mar 15, 2019, 7:35 PM Jacob Barrett <jbarr...@pivotal.io> wrote: > +1 for the change and +1 for BOMs. > > We currently have an “all” BOM and a client BOM. Defining server and other > usecase derived BOMs should be easy. > -jake > > > > On Mar 15, 2019, at 4:16 PM, John Blum <jb...@pivotal.io> wrote: > > > > If users will be explicitly declaring such dependencies in their > > applications, then I might also suggest declaring/generating a Maven > > <dependencyManagement> section in the POM to ensure that the user is > > getting and using the right version of these dependencies, especially > when > > they don't care about the version (i.e. their applications likely will > not > > use the same dependency, e.g. org.jgroups:jgroups). Assuming a version > > property is appropriately declared in the POM, then the user can always > > override the dependency version. All too often we running into problems > > (e.g. NoSuchMethodError) due to incompatibility with versions. > > > > As fine example of a curated, harmonized, managed set of dependencies, > see > > the *Spring Boot* Dependency POM > > < > https://github.com/spring-projects/spring-boot/blob/v2.1.3.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L34-L3056 > > > > [1]. > > > > This is recommended, not required. In general, I'd also add that GemFire > > should produce a BOM file to manage its dependencies (both owned (e.g. > > geode-core, geode-lucene, etc) as well as transitive) so users don't have > > to. > > > > Food for thought. > > > > > > > > On Fri, Mar 15, 2019 at 4:07 PM Bruce Schuchardt <bschucha...@pivotal.io > > > > wrote: > > > >> That seems like a great idea > >> > >>> On 3/15/19 11:53 AM, Dan Smith wrote: > >>> Hi, > >>> > >>> We would like to start using gradle's new implementation dependency > >>> notation in our build files. > >>> > >>> This will affect downstream consumers of geode-core, hopefully in a > good > >>> way, in that many of our dependencies will now be marked runtime > >>> dependencies in the pom instead of compile. That means it is easier for > >>> users to avoid accidentally using one of these dependencies in their > >> code. > >>> But it also means if they are using one of these dependencies directly, > >>> they will have to explicitly add it to their maven/gradle build going > >>> forward. > >>> > >>> Here is a PR for this: > >>> https://github.com/apache/geode/pull/3314 > >>> > >>> Are there any concerns with making this switch? > >>> > >>> These are the dependencies that are being flipped to runtime instead of > >>> compile in the pom: > >>> > >>> com.github.stephenc.findbugs:findbugs-annotations > >>> org.jgroups:jgroups > >>> antlr:antlr > >>> com.fasterxml.jackson.core:jackson-annotations > >>> com.fasterxml.jackson.core:jackson-databind > >>> commons-io:commons-io > >>> commons-validator:commons-validator > >>> javax.xml.bind:jaxb-api > >>> com.sun.xml.bind:jaxb-impl > >>> org.apache.commons:commons-lang3 > >>> it.unimi.dsi:fastutil > >>> net.java.dev.jna:jna > >>> net.sf.jopt-simple:jopt-simple > >>> org.apache.logging.log4j:log4j-api > >>> org.apache.logging.log4j:log4j-core > >>> org.eclipse.jetty:jetty-server > >>> io.github.classgraph:classgraph > >>> com.healthmarketscience.rmiio:rmiio > >>> > >> > > > > > > -- > > -John > > john.blum10101 (skype) >
