You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Dan Smith <ds...@pivotal.io> on 2019/03/15 18:53:18 UTC
[DISCUSS] Changing many geode-core dependencies from compile to runtime
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
Re: [DISCUSS] Changing many geode-core dependencies from compile to runtime
Posted by pulkit chandra <pu...@gmail.com>.
+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 <jb...@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 <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)
>
Re: [DISCUSS] Changing many geode-core dependencies from compile to runtime
Posted by Jacob Barrett <jb...@pivotal.io>.
+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 <bs...@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)
Re: [DISCUSS] Changing many geode-core dependencies from compile to runtime
Posted by John Blum <jb...@pivotal.io>.
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 <bs...@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)
Re: [DISCUSS] Changing many geode-core dependencies from compile to
runtime
Posted by Bruce Schuchardt <bs...@pivotal.io>.
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
>