-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
HBASE-29016 Refactor assembly creation to use only DependencySets and… #6519
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I have tested this on a pseudo-distributed cluster, starting and stopping HBase, and running a simple smoke test via HBase shell, and the rowCounter MR job. |
hbase-generate-dev-classpath/pom.xml
Outdated
<modelVersion>4.0.0</modelVersion> | ||
<parent> | ||
<groupId>org.apache.hbase</groupId> | ||
<artifactId>hbase-build-configuration</artifactId> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better names welcome
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
may be hbase-dev-generate-classpath? so that we can prefix all dev related modules as "hbase-dev-*" in case we add more in future
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will hold off changing that in case we get other suggestions.
… move cached classpath creation to a new module also remove explicit jaxsw-ri dependency from assembly
<exclude>org.apache.yetus:audience-annotations</exclude> | ||
<exclude>org.slf4j:*</exclude> | ||
<exclude>org.apache.logging.log4j:*</exclude> | ||
<!-- TODO shouldn't we also exclude duplicate io.opentelemetry.* jars which are added to client-facing-thirdparty ? --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @stoty any reason for not excluding io.opentelemetry.* here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't 100% sure that the current version doesn't do this on purpose, and I wanted to minimize the changes.
We can add the exclusion here, or we can open a follow-up ticket for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sound good either ways
<!-- Exclude the Ruby jar that goes in the lib/ruby directory --> | ||
<exclude>org.jruby:jruby-complete</exclude> | ||
<!-- Exclude jars that go into the lib/client-facing-thirdparty directoy --> | ||
<exclude>com.github.stephenc.findbugs:findbugs-annotations</exclude> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so the excludes block should be kept in sync with any dependencies we add in a sub folder of lib. may be add a note somewhere to avoid dependencies getting duplicated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea.
@@ -143,6 +51,36 @@ | |||
</files> | |||
|
|||
<dependencySets> | |||
<dependencySet> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is client.xml and hadoop-three-compat a copy now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes.
The differences were already minimal, I think they were accidental, too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, we can see if we should keep both as follow up. I am good as long as generated assembly is same
hbase-generate-dev-classpath/pom.xml
Outdated
<artifactId>hbase-mapreduce</artifactId> | ||
<type>test-jar</type> | ||
</dependency> | ||
<!-- To dump tools in hbase-procedure into cached_classpath.txt. --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this comment is no longer needed right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah we are referring why we addded hbase-procedure here. ignore comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I think that this comment IS redundant, I don't see why hbase-procedure would be different than the rest of the artifacts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
exactly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that some of the scope changes, etc are also unneccessary in this case, but I ran out steam when cleaning up the pom.
Is there any difference between tarball generated with this change and without this change? If both are same, a +1 from me, as long as we all are fine to move to use only DependencySets, this is lot cleaner and avoids mixing up. Although it is important to note that this step comes with a extra maintenance step of excluding any non base folder directory jar. But I am fine with this given we barely add new sub folders and we already plan to add a note in code to notify devs to take care of this. |
Yes, there are changes,. About half of them is the jaxws-ri removal, which could be split into a different issue, if desired. |
It would prefer to have it separate it it is not too much effort since if we do more this jira should be otherwise "Refactor and cleanup" Also thinking about the future use case of having assembly with assembly-without-hadoop-jars, have you thought how the dependencySet mechanism will be able to handle it? Would we need to create a new module for assembly-without-hadoop-jars now? As now I am not sure how we can support multiple assemblies with single dependency set without managing inclusion/exclusion lists for each assembly.xml. Or do we plan to follow inclusion/exclusion list approach only. |
I have also added some reasoning on why we need the assembly changes to the JIRA. |
Just saw the JIRA title, sounds good to me. |
For the hadoop-less assembly, I plan to copy this assembly, and add the Hadoop artifacts as provided scope dependencies. That is the best (only) way I know to remove both the Hadoop artifacts, and their exclusive transitive dependencies, while keeping HBase's transitive dependencies. The only other way I know would be excluding and including everything by hand, which would be super fragile. |
Re-added jaxws-ri |
This comment has been minimized.
This comment has been minimized.
<include>org.apache.hbase:hbase-shaded-client-byo-hadoop</include> | ||
</includes> | ||
<outputDirectory>lib</outputDirectory> | ||
<useTransitiveDependencies>true</useTransitiveDependencies> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: <!-- Exclude artifacts added in the sub-directories to avoid duplication -->
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Synced to the other xml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 LGTM
I have checked the external and internal classpaths, and determined that duplicating the opentelemtry JARs is not needed. |
So I removed the duplication. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@@ -245,20 +211,36 @@ | |||
<groupId>io.opentelemetry.javaagent</groupId> | |||
<artifactId>opentelemetry-javaagent</artifactId> | |||
</dependency> | |||
<!-- We don't really add this to assembly tarball, we retain it here just to dump it into | |||
cached_classpath.txt ! See HBASE-28433 for more info. --> | |||
<!-- This is an optional dependency of hbase-external-blockcache. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If so, let's just remove the optional flag in hbase-external-blockcache's pom file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took another look at this.
I guess that the original intent was to NOT include it in the assembly, it just got lost somehow.
The last version is also from 2017, so this doesn't look a maintaned library.
Based on the comments, getting this right is far from trivial, and this probably has few users, so it might be better to keep it optional, and just leave it out from assembly.
That way most users will get less JARs, and the few (if any) users of it would have to provide it themselves.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or we can do the removal in another ticket, so that it's better documented.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have opened a [DISCUSS] thread for spymemcached removal.
Let's have a try first. |
🎊 +1 overall
This message was automatically generated. |
I have already merged this back in December. |
… move cached classpath creation to a new module