Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move java classes out of the native modules #11798

Merged
merged 1 commit into from Oct 28, 2021
Merged

Conversation

normanmaurer
Copy link
Member

@normanmaurer normanmaurer commented Oct 26, 2021

Motivation:

To ensure the user doesnt end up with the same classes multiple times in the classpath when including native dependencies for different platforms we need to ensure we not include the java classes in this jars but provide them as separate modules.

Modifications:

  • Introduces a -classes- module for each -native- module and depend on it from the native module
  • Add entries to the bom
  • Depend on the correct artifacts in netty-all to ensure we not end up with the same classes multiple times

Result:
Fixes #11791

Copy link
Contributor

@chrisvest chrisvest left a comment

Choose a reason for hiding this comment

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

Looks like the way to go.

resolver-dns-classes-macos/pom.xml Outdated Show resolved Hide resolved
@chrisvest
Copy link
Contributor

You also need to tell japicmp that this is fine, though.

Motivation:

To ensure the user doesnt end up with the same classes multiple times in the classpath when including native dependencies for different platforms we need to ensure we not include the java classes in this jars but provide them as seperate modules.

Modifications:

- Introduces a *-classes-* module for each *-native-* module and depend on it from the native module
- Add entries to the bom
- Depend on the correct artifacts in netty-all to ensure we not end up with the same classes multiple times

Result:

Fixes #11791
@normanmaurer normanmaurer changed the title Fix Move java classes out of the native modules Oct 26, 2021
@normanmaurer normanmaurer added this to the 4.1.70.Final milestone Oct 26, 2021
-->
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>netty-transport-native-epoll</artifactId>
<artifactId>netty-transport-classes-epoll</artifactId>
Copy link
Member

@trustin trustin Oct 27, 2021

Choose a reason for hiding this comment

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

Not sure if the name classes makes sense although I don't have a good idea on this. Maybe common? 🤔

Copy link
Member Author

Choose a reason for hiding this comment

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

I picked classes as it contains the classes but no idea 🤷‍♂️

Copy link
Member

Choose a reason for hiding this comment

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

or just nothing? netty-transport-epoll

Copy link
Member

Choose a reason for hiding this comment

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

Forgot to add don't to have a good idea 😅

Copy link
Contributor

Choose a reason for hiding this comment

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

Either nothing or classes seem fine to me.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thinking about it, I think I have a slight preference for keeping it. Without, it might be the first dependency people add, only to discover it doesn’t work because the native binaries are missing.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thinking about it, I think I have a slight preference for keeping it. Without, it might be the first dependency people add, only to discover it doesn’t work because the native binaries are missing.

@trustin works for you ?

@normanmaurer
Copy link
Member Author

Let me merge this one so we can make progress.

@boris-unckel
Copy link
Contributor

@normanmaurer Is it intended to have netty-transport-native-unix-common-4.1.70.Final.jar with class files? Or are they different from the ones you moved here? (jar size of 4.1.69 similar)

@normanmaurer
Copy link
Member Author

yes this is not a problem

korthout added a commit to camunda/zeebe that referenced this pull request Nov 11, 2021
netty-bom 4.1.70 contains the changes from pull request
netty/netty#11798, which moved the classes out
of the native modules to make sure the same classes don't end up on the
classpath multiple times. For us it should mean that we don't have to
depend on the specific native module any more but can simply depend on
the common/shared classes module.
korthout added a commit to camunda/zeebe that referenced this pull request Nov 11, 2021
netty-bom 4.1.70 contains the changes from pull request
netty/netty#11798, which moved the classes out
of the native modules to make sure the same classes don't end up on the
classpath multiple times. For us it means that we need to depend on both
the native and classes modules. However, since we don't use the native
module directly (only classes that were moved to this classes module),
we need to force the dependency plugin to consider the native module as
used.
laosijikaichele pushed a commit to laosijikaichele/netty that referenced this pull request Dec 16, 2021
Motivation:

To ensure the user doesnt end up with the same classes multiple times in the classpath when including native dependencies for different platforms we need to ensure we not include the java classes in this jars but provide them as seperate modules.

Modifications:

- Introduces a *-classes-* module for each *-native-* module and depend on it from the native module
- Add entries to the bom
- Depend on the correct artifacts in netty-all to ensure we not end up with the same classes multiple times

Result:

Fixes netty#11791
laosijikaichele pushed a commit to laosijikaichele/netty that referenced this pull request Dec 16, 2021
Motivation:

To ensure the user doesnt end up with the same classes multiple times in the classpath when including native dependencies for different platforms we need to ensure we not include the java classes in this jars but provide them as seperate modules.

Modifications:

- Introduces a *-classes-* module for each *-native-* module and depend on it from the native module
- Add entries to the bom
- Depend on the correct artifacts in netty-all to ensure we not end up with the same classes multiple times

Result:

Fixes netty#11791
npepinpe pushed a commit to camunda/zeebe that referenced this pull request Jan 15, 2022
netty-bom 4.1.70 contains the changes from pull request
netty/netty#11798, which moved the classes out
of the native modules to make sure the same classes don't end up on the
classpath multiple times. For us it means that we need to depend on both
the native and classes modules. However, since we don't use the native
module directly (only classes that were moved to this classes module),
we need to force the dependency plugin to consider the native module as
used.
raidyue pushed a commit to raidyue/netty that referenced this pull request Jul 8, 2022
Motivation:

To ensure the user doesnt end up with the same classes multiple times in the classpath when including native dependencies for different platforms we need to ensure we not include the java classes in this jars but provide them as seperate modules.

Modifications:

- Introduces a *-classes-* module for each *-native-* module and depend on it from the native module
- Add entries to the bom
- Depend on the correct artifacts in netty-all to ensure we not end up with the same classes multiple times

Result:

Fixes netty#11791
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.

Maven build issues with 4.1.69-Final (Shaded Plugin) - overlapping classes
5 participants