geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Barrett <jbarr...@pivotal.io>
Subject Re: [DISCUSS] Changing many geode-core dependencies from compile to runtime
Date Fri, 15 Mar 2019 23:34:58 GMT
+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 <jblum@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 <bschuchardt@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)

Mime
View raw message