Skip to content

Conversation

@JoshRosen
Copy link
Contributor

Netty classes are published under multiple artifacts with different names, so our build needs to exclude the io.netty:netty and org.jboss.netty:netty versions of the Netty artifact. However, our existing exclusions were incomplete, leading to situations where duplicate Netty classes would wind up on the classpath and cause compile errors (or worse).

This patch fixes the exclusion issue by adding more exclusions and uses Maven Enforcer's banned dependencies rule to prevent these classes from accidentally being reintroduced. I also updated dev/test-dependencies.sh to run mvn validate so that the enforcer rules can run as part of pull request builds.

/cc @rxin @srowen @pwendell. I'd like to backport at least the exclusion portion of this fix to branch-1.5 in order to fix the documentation publishing job, which fails nondeterministically due to incompatible versions of Netty classes taking precedence on the compile-time classpath.

@JoshRosen
Copy link
Contributor Author

I'd like to backport the dev/test-dependencies infrastructure as far back as branch-1.5 so that we can merge a similar fix there as well. After this fix gets in, I think we should audit the build for other dependencies which should be banned via enforcer rules.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pwendell, this was from your original PR but I think it's no longer necessary because we don't run the compile phase.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, note that we need to install dummy JARs and test JARs for all modules so that mvn validate doesn't fail during dependency resolution.

@srowen
Copy link
Member

srowen commented Jan 9, 2016

LGTM. Other candidates for banning: the servlet API jars in all its packagings

@SparkQA
Copy link

SparkQA commented Jan 9, 2016

Test build #49041 has finished for PR 10672 at commit 798441a.

  • This patch fails from timeout after a configured wait of 250m.
  • This patch merges cleanly.
  • This patch adds no public classes.

@JoshRosen
Copy link
Contributor Author

I've opened two pull requests to backport the dev/test-dependencies infra to branch-1.5 and 1.6, which should allow me to backport this change as well.

I agree about the servlet API JARs, that's a good case. We should also exclude the ASM classes, since pulling in old versions of ASM is a leading cause of Java 8 compatibility issues. I'll update this in a little bit in order to cover those two obvious cases. There might be a couple of other candidates that are worth banning, but I'd like to cover them in followups.

@JoshRosen
Copy link
Contributor Author

Actually, I might choose to handle those separately in a followup next week in order to have more time to think through a few additional cases, including the exclusion of certain Jetty versions. I want to get the enforcer infra and the Netty fix in first to unblock a 1.5 doc building problem.

@rxin
Copy link
Contributor

rxin commented Jan 10, 2016

LGTM.

@JoshRosen
Copy link
Contributor Author

Thanks for reviewing. I'm going to merge this into master and will open separate PRs to test the backports, which might possibly require a different set of exclusion rules.

@asfgit asfgit closed this in 3ab0138 Jan 11, 2016
@JoshRosen JoshRosen deleted the enforce-netty-exclusions branch January 11, 2016 04:04
JoshRosen added a commit to JoshRosen/spark that referenced this pull request Jan 11, 2016
…event future bugs

Netty classes are published under multiple artifacts with different names, so our build needs to exclude the `io.netty:netty` and `org.jboss.netty:netty` versions of the Netty artifact. However, our existing exclusions were incomplete, leading to situations where duplicate Netty classes would wind up on the classpath and cause compile errors (or worse).

This patch fixes the exclusion issue by adding more exclusions and uses Maven Enforcer's [banned dependencies](https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html) rule to prevent these classes from accidentally being reintroduced. I also updated `dev/test-dependencies.sh` to run `mvn validate` so that the enforcer rules can run as part of pull request builds.

/cc rxin srowen pwendell. I'd like to backport at least the exclusion portion of this fix to `branch-1.5` in order to fix the documentation publishing job, which fails nondeterministically due to incompatible versions of Netty classes taking precedence on the compile-time classpath.

Author: Josh Rosen <[email protected]>
Author: Josh Rosen <[email protected]>

Closes apache#10672 from JoshRosen/enforce-netty-exclusions.
JoshRosen added a commit to JoshRosen/spark that referenced this pull request Jan 11, 2016
…event future bugs

Netty classes are published under multiple artifacts with different names, so our build needs to exclude the `io.netty:netty` and `org.jboss.netty:netty` versions of the Netty artifact. However, our existing exclusions were incomplete, leading to situations where duplicate Netty classes would wind up on the classpath and cause compile errors (or worse).

This patch fixes the exclusion issue by adding more exclusions and uses Maven Enforcer's [banned dependencies](https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html) rule to prevent these classes from accidentally being reintroduced. I also updated `dev/test-dependencies.sh` to run `mvn validate` so that the enforcer rules can run as part of pull request builds.

/cc rxin srowen pwendell. I'd like to backport at least the exclusion portion of this fix to `branch-1.5` in order to fix the documentation publishing job, which fails nondeterministically due to incompatible versions of Netty classes taking precedence on the compile-time classpath.

Author: Josh Rosen <[email protected]>
Author: Josh Rosen <[email protected]>

Closes apache#10672 from JoshRosen/enforce-netty-exclusions.
@JoshRosen
Copy link
Contributor Author

I discovered that the now-removed netty.io:netty dependency places its classes under the org.jboss.netty namespace, so I guess there's not a conflict between netty.io:netty-all and netty.io:netty. As a result, I think that we may need to allow transitive dependencies on netty.io:netty but should continue to ban the org.jboss.netty:netty artifact. I'll submit a followup to handle this tomorrow.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, so this exclude is likely to break Akka remote now that the Netty 3.x classes are completely missing from the classpath.

@JoshRosen
Copy link
Contributor Author

I've opened #10693 to hotfix the exclusions. In the 1.5 and 1.6 backport branches, I've re-scoped the changes to only exclude org.jboss.netty:netty.

asfgit pushed a commit that referenced this pull request Jan 11, 2016
This is a hotfix for a build bug introduced by the Netty exclusion changes in #10672. We can't exclude `io.netty:netty` because Akka depends on it. There's not a direct conflict between `io.netty:netty` and `io.netty:netty-all`, because the former puts classes in the `org.jboss.netty` namespace while the latter uses the `io.netty` namespace. However, there still is a conflict between `org.jboss.netty:netty` and `io.netty:netty`, so we need to continue to exclude the JBoss version of that artifact.

While the diff here looks somewhat large, note that this is only a revert of a some of the changes from #10672. You can see the net changes in pom.xml at 3119206...5211ab8#diff-600376dffeb79835ede4a0b285078036

Author: Josh Rosen <[email protected]>

Closes #10693 from JoshRosen/netty-hotfix.
asfgit pushed a commit that referenced this pull request Jan 11, 2016
…to branch-1.6

This patch backports the Netty exclusion fixes from #10672 to branch-1.6.

Author: Josh Rosen <[email protected]>

Closes #10691 from JoshRosen/netty-exclude-16-backport.
asfgit pushed a commit that referenced this pull request Jan 11, 2016
…to branch-1.5

This patch backports the Netty exclusion fixes from #10672 to branch-1.5.

Author: Josh Rosen <[email protected]>

Closes #10690 from JoshRosen/netty-exclude-15-backport.
asfgit pushed a commit that referenced this pull request Jan 11, 2016
…er install in dep tests

This patch fixes a build/test issue caused by the combination of #10672 and a latent issue in the original `dev/test-dependencies` script.

First, changes which _only_ touched build files were not triggering full Jenkins runs, making it possible for a build change to be merged even though it could cause failures in other tests. The `root` build module now depends on `build`, so all tests will now be run whenever a build-related file is changed.

I also added a `clean` step to the Maven install step in `dev/test-dependencies` in order to address an issue where the dummy JARs stuck around and caused "multiple assembly JARs found" errors in tests.

/cc zsxwing

Author: Josh Rosen <[email protected]>

Closes #10704 from JoshRosen/fix-build-test-problems.
asfgit pushed a commit that referenced this pull request Jan 11, 2016
…er install in dep tests

This patch fixes a build/test issue caused by the combination of #10672 and a latent issue in the original `dev/test-dependencies` script.

First, changes which _only_ touched build files were not triggering full Jenkins runs, making it possible for a build change to be merged even though it could cause failures in other tests. The `root` build module now depends on `build`, so all tests will now be run whenever a build-related file is changed.

I also added a `clean` step to the Maven install step in `dev/test-dependencies` in order to address an issue where the dummy JARs stuck around and caused "multiple assembly JARs found" errors in tests.

/cc zsxwing

Author: Josh Rosen <[email protected]>

Closes #10704 from JoshRosen/fix-build-test-problems.

(cherry picked from commit a449914)
Signed-off-by: Josh Rosen <[email protected]>
asfgit pushed a commit that referenced this pull request Jan 11, 2016
…er install in dep tests

This patch fixes a build/test issue caused by the combination of #10672 and a latent issue in the original `dev/test-dependencies` script.

First, changes which _only_ touched build files were not triggering full Jenkins runs, making it possible for a build change to be merged even though it could cause failures in other tests. The `root` build module now depends on `build`, so all tests will now be run whenever a build-related file is changed.

I also added a `clean` step to the Maven install step in `dev/test-dependencies` in order to address an issue where the dummy JARs stuck around and caused "multiple assembly JARs found" errors in tests.

/cc zsxwing

Author: Josh Rosen <[email protected]>

Closes #10704 from JoshRosen/fix-build-test-problems.

(cherry picked from commit a449914)
Signed-off-by: Josh Rosen <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants