Enhance the Gradle build as necessary after removing Ant support [LUCENE-9475] #10514
Comments
|
Dawid Weiss (@dweiss) (migrated from JIRA)
It should be fine - it's part of general check?
This is already covered in the list in #10119. I'll handle it, eventually. There is no specific "Maven" side of things: gradle descriptors translate into Maven descriptors and are published as such. The thing that needs to be done is assembling everything, setting up Apache deployment repository, etc. |
|
Uwe Schindler (@uschindler) (migrated from JIRA)
I think this means that our Jenkins builds work with Gradle. That's what I am currently testing with Jenkins. I have some changes, see #10513! |
|
ASF subversion and git services (migrated from JIRA) Commit da8ea70 in lucene-solr's branch refs/heads/master from Erick Erickson LUCENE-9475: Enhance the Gradle build as necessary after removing Ant support |
|
Cassandra Targett (@ctargett) (migrated from JIRA) Crossed off the Verify Reference Guide builds item. That's been working fine for a few days now; Uwe is still working through other issues in #10513, though. |
|
Tomoko Uchida (@mocobeta) (migrated from JIRA) #10481 was fixed. Also this (re)enables Javadoc linter check on Gradle build. |
|
Uwe Schindler (@uschindler) (migrated from JIRA) I created a pull request to change the checkSourcePatterns task to remove the |
|
ASF subversion and git services (migrated from JIRA) Commit bbf3aec in lucene-solr's branch refs/heads/master from Uwe Schindler LUCENE-9475: Switch validateSourcePatterns away from Ant legacy (#1806) |
|
ASF subversion and git services (migrated from JIRA) Commit bbf3aec in lucene-solr's branch refs/heads/LUCENE-9215 from Uwe Schindler LUCENE-9475: Switch validateSourcePatterns away from Ant legacy (#1806) |
|
David Smiley (@dsmiley) (migrated from JIRA) @rmuir I noticed that yesterday you committed a change to check-source-patterns.groovy to remove a prevention mechanism of the "var". The commit message didn't reference any issue or PR but I see this file migrated to a gradle build file the next day so I suppose this issue is fitting. Please don't make such changes without a JIRA or PR. This check was deliberate on master branch; I recall some conversations that led to it's addition – apache/lucene-solr@f6f1b42 and especially the rationale in the reported message: "var is not allowed in until we stop development on the 8x code line". We still do development on the 8x code line. When there is no such check on master, it's possible for back-ports to be more painful than they need to be thanks to this rather disruptive Java language feature. The thinking is we wait until 9.0 is released. WDYT? As we get closer to 9.0, I'm caring less about this constraint but I still think it's a good idea. |
|
Robert Muir (@rmuir) (migrated from JIRA) If solr wants to add such restrictions, they should form their own TLP and do it there. Don't hold back lucene code (especially when you don't have a clue as to how the feature even works, which is clear from the comments here). Master is on java 11. |
|
Dawid Weiss (@dweiss) (migrated from JIRA) Robert is known for being subtle. ;) My personal opinion (on this in general, not in particular) is that we should be embracing those new language features and APIs. It's part of what makes programming fun and exciting - learning new things. Backports will not be automatic but it won't be anyway as we progress and branches diverge. In this case replacing vars can be probably done automatically from an IDE (much like the type is inferred by the compiler). More complex new language features may require hand-coding an equivalent. |
|
Jan Høydahl (@janhoy) (migrated from JIRA) This decision making process sucks. |
|
Dawid Weiss (@dweiss) (migrated from JIRA) I just expressed my opinion on the technical matter rather than how it was introduced. I agree it should have been called for in a separate Jira issue, like Uwe said. |
|
ASF subversion and git services (migrated from JIRA) Commit e3437a4 in lucene-solr's branch refs/heads/master from Dawid Weiss LUCENE-9475: remove obsolete ant-only jar sha's from Solr. |
|
ASF subversion and git services (migrated from JIRA) Commit 8c5ce09 in lucene-solr's branch refs/heads/master from Erick Erickson LUCENE-9475: Enhance the Gradle build as necessary after removing Ant support, some minor text changes to solr/README.md and help.gradle |
|
ASF subversion and git services (migrated from JIRA) Commit 9f27041 in lucene-solr's branch refs/heads/reference_impl_gradle_updates from Dawid Weiss LUCENE-9475: remove obsolete ant-only jar sha's from Solr. |
|
Erick Erickson (@ErickErickson) (migrated from JIRA) Is it time to close this and raise any other Gradle issues in another JIRA? Gradle is pretty well baked in to master at this point. I'll close this on Wednesday absent objections. I don't think it's serving a valuable purpose at this point. |
|
Dawid Weiss (@dweiss) (migrated from JIRA) Yeah, close it, Erick. |
|
Erick Erickson (@ErickErickson) (migrated from JIRA) We're using Gradle, Ant has been removed from trunk. We can raise new JIRAs for anything that bubbles up. |
|
Adrien Grand (@jpountz) (migrated from JIRA) Closing after the 9.0.0 release |
Once the bulk of the Ant build system is removed, stuff will come bubbling up out of the cracks, especially as we try the first 9.0 release which will be Gradle only. Here we list some of the areas we'll have to be aware of. Please add as you see fit. Assigning to myself to track, but I certainly don't want hog all the fun.
Remove Maven support and replace with "The Gradle Way" of doing Maven. See Gradle build [LUCENE-9077] #10119 (Dawid)
Move Jenkins over to use Gradle onlyVerify reference guide build works under GradleSmoke tester
Remove anything having to to with Clover (obsolete as of Java 11)
Remove all oflucene/tools(Ivy, forbiddenapis,...}}-Remove obsolete files in root dirs of lucene and solr (like ivy-versions.props, now integrated into gradle)-
Remove Maven build files (obsolete with Gradle)Hoss's test rollups?
-Enable javadocs after ant stops being used (Fix ant-specific relative links in Javadocs in accordance with Gradle build [LUCENE-9441] #10481)-
fix some relative links in javadocs which contain ant module names ?
dev-tools/scripts/* There are a lot of mentions of ant in the .py files, and some in the README.md. This one should probably be its own JIRA since it'll require quite a bit of verification...
Make "the best damn beasting script in the world" work with the Gradle build.(see Add functionality to do test re-runs (suite duplication, so-called 'beasting') [LUCENE-9465] #10505, True concurrent test suite duplication and execution (beasting) [LUCENE-9472] #10511 for alternatives)Update the release documentation to reflect Gradle (Update release process to work with Gradle. [LUCENE-9488] #10527)
Clean up anything in lucene/toolsClean up Confluence, in particular any page that mentions IDEs. The "How to Contribute" page has several links to various bits and pieces of how to use IDEs, and some mention ant.
Migrated from LUCENE-9475 by Erick Erickson (@ErickErickson), resolved Oct 27 2020
Linked issues:
Pull requests: apache/lucene-solr#1796, apache/lucene-solr#1806
The text was updated successfully, but these errors were encountered: