Re: [DISCUSS] propdeps removal and what to do going forward

2022-01-19 Thread Kenneth Knowles
On Wed, Jan 19, 2022 at 10:59 AM Brian Hulette wrote: > > But I believe the issue is that some tooling will bundle up the > "compile" dependencies and submit with the job, which will then have a > conflict with the libraries on the cluster. > > Do you know specifically what tooling does this?

Re: [DISCUSS] propdeps removal and what to do going forward

2022-01-18 Thread Kenneth Knowles
On Fri, Jan 14, 2022 at 9:34 AM Daniel Collins wrote: > > In particular the Hadoop/Spark and Kafka dependencies must be > **provided** as they were. I am not sure of others but those three matter. > > I think there's a bit of a difference here between what should be the > state in the short term

Re: [DISCUSS] propdeps removal and what to do going forward

2022-01-13 Thread Ismaël Mejía
Optional dependencies should not be a major issue. What matters to validate that we are not breaking users is to compare the generated POM files with the previous (pre gradle 7 / 2.35.0) version and see that what was provided is still provided. In particular the Hadoop/Spark and Kafka

Re: [DISCUSS] propdeps removal and what to do going forward

2022-01-11 Thread Kenneth Knowles
To clarify: "provided" should have been in the test runtime configuration, but not in the shipped runtime configuration (otherwise dep resolution for users would pull in provided deps, which should not happen) On Thu, Dec 30, 2021 at 10:05 AM Luke Cwik wrote: > During the migration to Gradle