+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)
