-
Notifications
You must be signed in to change notification settings - Fork 24.7k
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
Remove BouncyCastle dependency from runtime #32193
Changes from 1 commit
e5824d7
15f8c15
27286ac
aca04e2
c40137f
af5745a
defa749
c2e55c2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,22 @@ | ||
apply plugin: 'elasticsearch.build' | ||
|
||
archivesBaseName = 'elasticsearch-security-cli' | ||
dependencies { | ||
compileOnly "org.elasticsearch:elasticsearch:${version}" | ||
compile 'org.bouncycastle:bcprov-jdk15on:1.59' | ||
compile 'org.bouncycastle:bcpkix-jdk15on:1.59' | ||
} | ||
|
||
jar { | ||
from(project(':x-pack:plugin:core').sourceSets.main.output.classesDirs) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. can we not move the source files to this project? At the very least I think we should exclude these from the x-pack core jar There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you elaborate please? We're not moving source files to this project now. Am i reading your comment wrong or maybe the not in can we not move isn't meant to be there ? I - probably falsely - assumed we do not want to move the source files to this project since we preferred this approach to the new plugin approach I tried out yesterday. It definitely makes sense to not have the classes both in this jar and in x-pack-core though - thanks. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry, my comment was not clear. I'd like for us to move the source files to this project for a clearer separation. The distinction between a separate plugin vs a jar is that the certificate generation code doesn't require a plugin and just needs to be packaged in a way that it can be loaded as a CLI tool. I suggested this way as an alternative to a completely separate plugin to avoid any confusion about seeing a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Great thanks, all clear now. I'll move the source files in this project |
||
include 'org/elasticsearch/xpack/core/ssl/CertificateTool.class' | ||
include 'org/elasticsearch/xpack/core/ssl/CertificateGenerateTool.class' | ||
include 'org/elasticsearch/xpack/core/ssl/CertGenUtils.class' | ||
} | ||
} | ||
|
||
dependencyLicenses { | ||
mapping from: /bc.*/, to: 'bouncycastle' | ||
} | ||
|
||
licenseHeaders.enabled = false | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you explain what is happening here? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I can certainly try. I started off without the
I interpreted this to be an error caused by the licenseHeaders task looking for Java files in order to check the license heades in security-cli and failing because there aren't any. Depending on whether I'll bring in the source files (#32193 (comment)) , I'll remove this but what should have been the correct approach in this case? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry, I was unclear. I meant can you leave a comment in the build.gradle about this. Of course, this changes if we do bring in the source files. |
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 am pretty sure this is not where we want to add this since the comment makes me think this section also applies to the oss distribution which does not have xpack.
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.
Thanks, that makes sense. I can take advantage of the
oss
boolean and callwith libFiles(oss)
where applicable so that it only includes the jars intools/security-cli
isoss
is falseThere 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.
Also, I think this can probably just go under
tools
now that I see where we are putting the jar. My suggestion for this directory yesterday was due to my outdated view of how files are laid out within the distribution.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.
Hmm...I think that
tools/security-cli
is the right place? It mimics what we did with theplugin-cli
.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.
derp. Ignore me and leave it as is