-
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
Switch to gradle build system #13930
Comments
You should probably add some of this to the pre-merge checklist to. Maybe just the some basic build instructions and a big note saying "
I'm cool with grabbing these later this week. If anyone that wants them before I get to them then please take them with my best wishes.
I'm cool with grabbing this later, maybe porting github.com/wikimedia/search-highlighter or something to prove it out. |
I published a snapshot of the |
I was wondering if we can contribute this plugin to Gradle as it sounds like to me a useful one for Gradle community. Is it doable at some point (when stable enough)? |
The gradle folks are working on a longer term solution for combining multiple multi-project builds. This is just a semi-temporary solution. |
Great news! |
And now that I'm finally done with |
I would add 'ability to do third party license analysis' as part of release requirement. gradle seems to have one |
@mrsolo afaik, we only use the maven license plugin to check files have a license header? |
@rjernst we use http://code.mycila.com/license-maven-plugin/ to check the license header which is a different license plug in than http://www.mojohaus.org/license-maven-plugin/ we use depends on maven license plugin to do third party library license auditing |
Hmm .. since 2.x, the licenses are managed in https://github.com/elastic/elasticsearch/tree/2.1/distribution/licenses and some if not all libraries are not shaded, this pretty much invalidate pre 2.x auditing workflo, gradle 3rd party dependencies therefore is nice to have but not necessary. Auditing will be
|
#2 basically mean generation of google spreadsheet, currently not automated |
The test jar was previously built in maven by copying class files. With gradle we now have a proper test framework artifact. This change moves the classes used by the test framework into the test-framework module. See elastic#13930
This change removes the leftover pom files. A couple files were left for reference, namely in qa tests that have not yet been migrated (vagrant and multinode). The deb and rpm assemblies also still exist for reference when finishing their setup in gradle. See elastic#13930
The randomized testing gradle code belongs with the randomized testing library. This moves it to its own repository, which is now published as a snapshot in nexus. See elastic#13930
Ok - I'm going to look at the vagrant tests. |
I've got the vagrant tests working as well as I can without rpm and deb packages so I'm going to start work on fixing the deb package. |
Ok - I'm going to see about these. |
Elasticsearch switched to Gradle as the build system in elastic/elasticsearch#13930, and the current Maven-oriented script stopped working. This patch refactors the code and adds a better infrastructure for future expansion.
This is done, bar the docs for plugin authors (#15280). Closing |
@rjernst I'm curious did you not know about From maven: https://maven.apache.org/pom.html#Inheritance
Thus if you had put the relative path to your parent pom in your submodules maven would not have to go "download" the internet. I only bring this up because I have people point to your gradle video about how the maven reactor won't let them build a part of the project without downloading other modules and thus fundamentally flawed. EDIT: Oh I thought your parent was in a non standard directory. I guess you mean it goes and downloads snapshot pom files. There are ways around that but yes that is the reactor behavior. |
We currently have a very large maven build system, comprising of 6k lines of xml. While maven parent POMs have been very useful in de-duplicating build logic across elasticsearch and plugins, the rigidity of maven has required us to begin implementing most of our test logic through
maven-antrun-plugin
. Another major problem with multi-module builds is trap: building a module requires explicitly listing an upstream module in order to get a local build of the dependency, or building from a higher level module (which implicitly builds all sub-modules). And finally, the maven model is incapable of decoupling test dependencies from main dependencies, in that tests for module A, cannot depend on module B, which in turn depends on module A (this is not a cycle).I have a branch which contains elasticsearch switched to using gradle:
https://github.com/elastic/elasticsearch/tree/burn_maven_with_fire
This is a tracking issue for completing the migration to gradle. The tasks are separated into two groups: those remaining required before pushing to master (as to not completely break development), and those required for the migration to be complete, which must happen before the next release (tentatively 2.2).
Required for master push:
Required for release:
Addtional nice to haves:
run
task for elasticsearch and plugins to replacerun.sh
/run.bat
: fixing run.bat and run.sh #14451The text was updated successfully, but these errors were encountered: