[jira] [Commented] (SOLR-13677) All Metrics Gauges should be unregistered by the objects that registered them
[ https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16924391#comment-16924391 ] Mark Miller commented on SOLR-13677: Reverts should take place right away, else we can easily end up in a bad situation. Development should be worked out on the branch, not in our release branches. Please let's do a simple and fast revert and then commit when we have consensus. > All Metrics Gauges should be unregistered by the objects that registered them > - > > Key: SOLR-13677 > URL: https://issues.apache.org/jira/browse/SOLR-13677 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Blocker > Fix For: 8.3 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > The life cycle of Metrics producers are managed by the core (mostly). So, if > the lifecycle of the object is different from that of the core itself, these > objects will never be unregistered from the metrics registry. This will lead > to memory leaks -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16920247#comment-16920247 ] Mark Miller edited comment on SOLR-13452 at 9/1/19 12:24 AM: - Development has shifted to https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_6 which is up to date from a few days ago I believe. If anyone pushes something to the previous branch on an update, I'll cherry pick it to the latest branch for you if it helps. was (Author: markrmil...@gmail.com): Development has shifted to https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_6 which is up from a few days ago I believe. If anyone pushes something to the previous branch on an update, I'll cherry pick it to the latest branch for you if it helps. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_6 -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16920247#comment-16920247 ] Mark Miller commented on SOLR-13452: Development has shifted to https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_6 which is up from a few days ago I believe. If anyone pushes something to the previous branch on an update, I'll cherry pick it to the latest branch for you if it helps. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_6 -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Description: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend [https://github.com/dougborg/gdub] This gradle branch uses the following plugin for version locking, version configuration and version consistency across modules: [https://github.com/palantir/gradle-consistent-versions] https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_6 was: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend [https://github.com/dougborg/gdub] This gradle branch uses the following plugin for version locking, version configuration and version consistency across modules: [https://github.com/palantir/gradle-consistent-versions] https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5 > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_6 -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16913677#comment-16913677 ] Mark Miller commented on SOLR-13452: [~tomoko], thanks so much! That's a huge help, even if you don't end up with time for more soon, that lowers the barrier for other intellij users to improve it greatly. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5 -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16913658#comment-16913658 ] Mark Miller commented on SOLR-13452: [~ivera], thanks, good catches - one of the hard parts of this forking off long ago when Dat first started work, is keeping up to date on newer additions. I'll stub those out this weekend. bq. And a question: which is the gradle command similar to ant precommit? Currently, this remains to be seen. Before we merge into master, I'll try and make a detailed list of things we still need to resolve. Right now, many of the items that where part of precommit are now tasks that the check task depends on. This means many of those checks are now run during build, and in parallel across modules. We have to see how good all those checks scale across older hardware. A precommit task that is not finished right now is the check javadocs for missing links check - I have an early stub for creating javadoc across all modules. but it's currently commented out. My feeling was, if we can get all the checks other than something like the javadoc missing links, maybe precommit should go away, checks are run as part of the normal build, and we count on jenkins to catch missing javadoc links if that task must remain non parallel and very slow. If we have to retain more than one long running important check task though, perhaps precommit stays. Right now though, the currently implemented and uncommented checks are part of the check task and not something you normally run independently. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5 -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13709) Race condition on core reload while core is still loading?
[
https://issues.apache.org/jira/browse/SOLR-13709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16913221#comment-16913221
]
Mark Miller commented on SOLR-13709:
I don’t recall adding a comment off the top of my head but I know I ran into a
bunch of ugly little issues after this change where the descriptor can now be
null when it couldn’t in the past. I had to change a bunch of plugin code to
grab the descriptor right away and save it vs count on being able to get it
from the core always.
> Race condition on core reload while core is still loading?
> --
>
> Key: SOLR-13709
> URL: https://issues.apache.org/jira/browse/SOLR-13709
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Priority: Major
> Attachments: apache_Lucene-Solr-Tests-8.x_449.log.txt
>
>
> A recent jenkins failure from {{TestSolrCLIRunExample}} seems to suggest that
> there may be a race condition when attempting to re-load a SolrCore while the
> core is currently in the process of (re)loading that can leave the SolrCore
> in an unusable state.
> Details to follow...
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16909862#comment-16909862 ] Mark Miller commented on SOLR-13452: Hey [~sdavids], that came up above in discussion if you want to do a quick keyword search and catch up on that. I've pointed out my current thinking. I know that Kotlin is supposed to solve the javascripty ide support situation, but at this point in time, I still see groovy as dominant when I'm looking stuff up or looking at other projects, etc. I think for an open source project, we want to stick to the fertile ground, and I don't find the lacking ide support to be much of an issue, even though I know proper support is clearly a nicer experience. That is my impression anyway - that Kotlin feels early considering the wealth of groovy based dev knowledge and resources in comparison. I feel like it's maybe something we should do later, when the tide seems to shift a little more. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16908338#comment-16908338 ] Mark Miller commented on SOLR-13452: [~tomoko], ping - probably not a bad time to start looking at support for intellij? I think from that perspective things are in fairly good shape. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16908336#comment-16908336 ] Mark Miller commented on SOLR-13452: [~ctargett], one thing still left is the doc module! I stubbed it out, but if you have any spare cycles, would love to take you up on the help offer. I can pitch in on the gradle side, but I'm pretty out of the know on the doc stuff and this project is already swallowing me up. Either way, I'll look to tackle it eventually. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13658) Precommit fail Java "var" until 9x. Fail "var...<>" constructs entirely
[
https://issues.apache.org/jira/browse/SOLR-13658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906822#comment-16906822
]
Mark Miller commented on SOLR-13658:
Weird keyword to single out IMO - non of the new features or keywords will work
in a backport, it's happened before and before, what is different here?
What I got from Erick was that he didn't like that it's more difficult to
determine the actual type visually, but as he mentioned, IDE's make this simple.
Personally, I'm still not a big var fan, but not sure why it should be banned
anymore than other new stuff we start using in newer versions every time we
jump up a Java version. Ban it all baby ;)
> Precommit fail Java "var" until 9x. Fail "var...<>" constructs entirely
> ---
>
> Key: SOLR-13658
> URL: https://issues.apache.org/jira/browse/SOLR-13658
> Project: Solr
> Issue Type: Wish
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (9.0), 8.2
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13658.patch, SOLR-13658.patch
>
>
> Personally, I'm strongly against allowing the "var" construct in Lucene/Solr
> code. I think it's a wonderful opportunity to introduce bugs that won't be
> found until runtime as well as making maintainence significantly harder. I
> don't even think for a project like Solr it would save any time overall...
> So let's discuss this ahead of time and see if we can reach a consensus. I'll
> start the discussion off:
> My baseline argument is that for a large complex project, especially ones
> with many different people coding, I want the compiler to give me all the
> help possible. And the "var" construct takes away some of that help.
> I’ve seen this argument go around at least 4 times in my career. The argument
> that “it takes longer to write if you have to type all this stuff” is bogus.
> Last I knew, 80% of the time spent is in maintaining/reading it. So the
> argument “I can write faster” means I can save some fraction of the 20% of
> the time writing the original code but spend many times that figuring out
> what the code is actually doing the other 80% of the time.
> The IDE makes _writing_ this slightly faster, admittedly.
> {code:java}
> Whatever what = new Whatever();
> var kidding = what.getComplex();
> var blivet = kidding.get("stuff");
> {code}
> But once that’s done, if I’m reading the code again I don't have any clue what
> {code:java}
> kidding or blivet
> {code}
> are. Here's the signature for getComplex:
> {code:java}
> Map> getComplex()
> {code}
> I have to go over to the definition (which I admit is easier than it used to
> be in the bad old days, but still) to find out.
> HERE'S THE PART I REALLY OBJECT TO!
> The above I could probably live with, maybe we could get the InteliJ
> developers and see if they can make hover show the inference. What I will
> kick and scream about is introducing bugs that are not found until runtime.
> Even this obvious stupidity fails with a ClassCastException:
> {code:java}
> var corny = new TreeMap();
> corny.put("one", "two");
> corny.get(1);
> {code}
> But it's much worse when using classes from somewhere else. For instance,
> change the underlying class in the first example to return
> {code:java}
> Map>{code}
> .
> This code that used to work now throws an error, _but it compiles_.
> {code:java}
> var kidding = what.getComplex();
> var blivet = kidding.get("stuff");
> var blah = kidding.get("stuff").get(1); // generates ClassCastException:
> class java.lang.String cannot be cast to class java.lang.Integer
> {code}
> So in order to save some time writing (that I claim will be lost multiple
> times over when maintaining the code) we'll introduce run-time errors that
> will take a bunch _more_ time to figure out, and won’t be found during unit
> tests unless and until we have complete code coverage.
> If there's a way to insure that this kind of thing can't get into the code
> and we implement that, I could be persuaded, but let's make that an explicit
> requirement (and find a suitable task for the build system, precommit or
> whatever).
> The floor is open...
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906732#comment-16906732 ] Mark Miller commented on SOLR-13452: Okay, I've updated to trunk, got the dependencies checking tasks largely working on all the modules, and am still working through some other dep stuff. Dev has moved to [https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5|https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5] > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Description: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend [https://github.com/dougborg/gdub] This gradle branch uses the following plugin for version locking, version configuration and version consistency across modules: [https://github.com/palantir/gradle-consistent-versions] https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5 was: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend [https://github.com/dougborg/gdub] This gradle branch uses the following plugin for version locking, version configuration and version consistency across modules: [https://github.com/palantir/gradle-consistent-versions] https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4 > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Attachment: gradle-build.pdf > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16884416#comment-16884416 ] Mark Miller commented on SOLR-13452: I've had to step back from this for a bit, but back to it soon. Will update to master before long. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Description: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend [https://github.com/dougborg/gdub] This gradle branch uses the following plugin for version locking, version configuration and version consistency across modules: [https://github.com/palantir/gradle-consistent-versions] https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4 was: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend [https://github.com/dougborg/gdub] This gradle branch uses the following plugin for version locking, version configuration and version consistency across modules: [https://github.com/palantir/gradle-consistent-versions] [ https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4| https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4] > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Description: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend [https://github.com/dougborg/gdub] This gradle branch uses the following plugin for version locking, version configuration and version consistency across modules: [https://github.com/palantir/gradle-consistent-versions] [ https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4| https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4] was: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend [https://github.com/dougborg/gdub] This gradle branch uses the following plugin for version locking, version configuration and version consistency across modules: [https://github.com/palantir/gradle-consistent-versions] https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > [ https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4| > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16864128#comment-16864128 ] Mark Miller commented on SOLR-13452: [~thetaphi], for some reason TestVirtualMethod does not pass when run under gradle. It works when I run it from eclipse, but I don't even think compiles with gradle - I tried to poke around a bit but it just failed in other spots. Any chance you could take a look? > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Comment: was deleted (was: Commit 183267bc70a74a0783cfe583fe8b6f96086481c3 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_4 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=183267b ] SOLR-13452: Make contrib-clustering dependency checker compliant. ) > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Comment: was deleted (was: Commit aaec9b2dbfc2a75b84bbcb6efb4307d98b3e2846 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_4 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=aaec9b2 ] SOLR-13452: Add comment on why kerby-pkix is excluded. ) > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Comment: was deleted (was: Commit e6837816e05365d0330190d4bdf64ab397980dbc in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_4 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e683781 ] SOLR-13452: Fix Solr JavaCC task to work with JavaCC 5 and add lucene queryparser javacc tasks, also hook them and solr javacc qp task to regenerate so they are tested by buildTest. ) > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Comment: was deleted (was: Commit 6f884a9fa190bc65f5f52df9e92b000f3f9f6f9b in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_3 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6f884a9 ] SOLR-13452: Re enable Lucene test that was failing early on. ) > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Comment: was deleted (was: Commit 6c01ca109b0d29467971ab9ad899220341770751 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_4 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6c01ca1 ] SOLR-13452: Commit updated generated solr queryparser so that FastCharStream changes compile. ) > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Comment: was deleted (was: Commit 7c6e1ff09d6f9318a98af58fd9e325078207aa09 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_4 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7c6e1ff ] SOLR-13452: Make contrib-dataimporthandler dependency checker compliant. ) > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Comment: was deleted (was: Commit 82b47237ca187197c543c766044753652b41dbf6 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_4 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=82b4723 ] SOLR-13452: Finish making solr-core transitive and more work on the new dependency checkers. solr-core is now in compliance with these checkers. ) > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Comment: was deleted (was: Commit b486e8a834f0b0c3d7ee685f52630040f5035dcb in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_4 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b486e8a ] SOLR-13452: Fix logging dependency issue and only add dependency tasks to java modules. ) > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Comment: was deleted (was: Commit 95f8d34de5d842a0491612887ba479b0b6c55001 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_4 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=95f8d34 ] SOLR-13452: Run missingDependencies in buildTest as well. ) > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Comment: was deleted (was: Commit c0a1c0592856d1014e8b079f9a3d30ee8af0c7d8 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_4 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c0a1c05 ] SOLR-13452: Some more work towards a solid transitive dependency solution. ) > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16864126#comment-16864126 ] Mark Miller commented on SOLR-13452: I've moved to jira/SOLR-13452_gradle_4, which is up to date with master from last night. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8346) Upgrade Zookeeper to version 3.5.5
[ https://issues.apache.org/jira/browse/SOLR-8346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16863378#comment-16863378 ] Mark Miller commented on SOLR-8346: --- I have not really looked into, the new gradle build just tells you this stuff. Looks to me like it would probably only possibly break our mode were you run zk internally with Solr on multiple hosts. > Upgrade Zookeeper to version 3.5.5 > -- > > Key: SOLR-8346 > URL: https://issues.apache.org/jira/browse/SOLR-8346 > Project: Solr > Issue Type: Task > Components: SolrCloud >Reporter: Jan Høydahl >Assignee: Erick Erickson >Priority: Major > Labels: security, zookeeper > Fix For: master (9.0), 8.2 > > Attachments: SOLR-8346.patch, SOLR-8346.patch, SOLR-8346.patch, > SOLR-8346.patch, SOLR-8346.patch, SOLR_8346.patch > > > Investigate upgrading ZooKeeper to 3.5.x, once released. Primary motivation > for this is SSL support. --Currently a 3.5.4-beta is released (2018-05-17).-- > Version 3.5.5 was released 2019-05-20 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8346) Upgrade Zookeeper to version 3.5.5
[ https://issues.apache.org/jira/browse/SOLR-8346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16863331#comment-16863331 ] Mark Miller commented on SOLR-8346: --- Just an FYI on some new dependency(s) this version of Zookeeper has over the last we used: "org.apache.zookeeper.server.quorum.UnifiedServerSocket$UnifiedSocket" -> "io.netty.buffer.ByteBuf (not found)"; "org.apache.zookeeper.server.quorum.UnifiedServerSocket$UnifiedSocket" -> "io.netty.buffer.Unpooled (not found)"; "org.apache.zookeeper.server.quorum.UnifiedServerSocket$UnifiedSocket" -> "io.netty.handler.ssl.SslHandler (not found)"; > Upgrade Zookeeper to version 3.5.5 > -- > > Key: SOLR-8346 > URL: https://issues.apache.org/jira/browse/SOLR-8346 > Project: Solr > Issue Type: Task > Components: SolrCloud >Reporter: Jan Høydahl >Assignee: Erick Erickson >Priority: Major > Labels: security, zookeeper > Fix For: master (9.0), 8.2 > > Attachments: SOLR-8346.patch, SOLR-8346.patch, SOLR-8346.patch, > SOLR-8346.patch, SOLR-8346.patch, SOLR_8346.patch > > > Investigate upgrading ZooKeeper to 3.5.x, once released. Primary motivation > for this is SSL support. --Currently a 3.5.4-beta is released (2018-05-17).-- > Version 3.5.5 was released 2019-05-20 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13437) fork noggit code to Solr
[ https://issues.apache.org/jira/browse/SOLR-13437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861725#comment-16861725 ] Mark Miller commented on SOLR-13437: I think it's not anymore? It might be that whatever we use in spatial4j doesn't touch the code that uses noggit (obviously nothing in tests appear to touch it). Unless someone reports a problem, I'm not too concerned, just thought I'd mentioned it because I noticed while working on the gradle build. I'll have to probe a little more and maybe get some input from [~dsmiley] to decide what to do there - include it for the spatial module or make an exception for it. > fork noggit code to Solr > > > Key: SOLR-13437 > URL: https://issues.apache.org/jira/browse/SOLR-13437 > Project: Solr > Issue Type: Task > Components: SolrJ >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > We rely on noggit for all our JSON encoding/decoding needs.The main project > is not actively maintained . We cannot easily switch to another parser > because it may cause backward incompatibility and we have advertised the > ability to use flexible JSON and we also use noggit internally in many classes -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861668#comment-16861668
]
Mark Miller commented on SOLR-13452:
{quote}As long as the test hit every code path you expect a user to hit.
{quote}
Not really related to this, but this is a little tricky too and part of why I
made these tasks - our test runtime classpath is different than a user runtime
classpath will be and so we can make tests pass and then not distribute
dependencies we need. Again, not happening here.
> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
> Issue Type: Improvement
> Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
>
> I took some things from the great work that Dat did in
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a
> little further.
>
> When working with gradle in sub modules directly, I recommend
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version
> configuration and version consistency across modules:
> [https://github.com/palantir/gradle-consistent-versions]
>
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861665#comment-16861665
]
Mark Miller commented on SOLR-13452:
{quote}If the test cases are passing is that enough to be certain that the
production release will run correctly with the same features?
{quote}
As long as the test hit every code path you expect a user to hit.
{quote}bq.Would be good to open a Jira to track down if we should include those
dependencies separately.
{quote}
I'll do that.
> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
> Issue Type: Improvement
> Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
>
> I took some things from the great work that Dat did in
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a
> little further.
>
> When working with gradle in sub modules directly, I recommend
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version
> configuration and version consistency across modules:
> [https://github.com/palantir/gradle-consistent-versions]
>
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861287#comment-16861287 ] Mark Miller commented on SOLR-13452: Cool, just need to know what I need to exclude or add. I plan on a dependency checking task that will fail if any runtime dependencies that are referred to in our code or libs are missing. I'll add an exception. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861242#comment-16861242
]
Mark Miller commented on SOLR-13452:
[~joel.bernstein], in my current build, calcite is missing the following
runtime dependencies. Does this seem legit to you? Do we expect not to use
these geometry package classes?
{noformat}
calcite-core-1.18.0.jar.dot:
"org.apache.calcite.adapter.jdbc.JdbcUtils$DataSourcePool" ->
"org.apache.commons.dbcp2.BasicDataSource (not found)";
"org.apache.calcite.materialize.TileSuggester" ->
"org.pentaho.aggdes.algorithm.Algorithm (not found)";
"org.apache.calcite.materialize.TileSuggester" ->
"org.pentaho.aggdes.algorithm.Algorithm$ParameterEnum (not found)";
"org.apache.calcite.materialize.TileSuggester" ->
"org.pentaho.aggdes.algorithm.Progress (not found)";
"org.apache.calcite.materialize.TileSuggester" ->
"org.pentaho.aggdes.algorithm.Result (not found)";
"org.apache.calcite.materialize.TileSuggester" ->
"org.pentaho.aggdes.algorithm.impl.MonteCarloAlgorithm (not found)";
"org.apache.calcite.materialize.TileSuggester" ->
"org.pentaho.aggdes.algorithm.util.ArgumentUtils (not found)";
"org.apache.calcite.materialize.TileSuggester" ->
"org.pentaho.aggdes.algorithm.util.ArgumentUtils$TextProgress (not found)";
"org.apache.calcite.materialize.TileSuggester" ->
"org.pentaho.aggdes.model.Aggregate (not found)";
"org.apache.calcite.materialize.TileSuggester" ->
"org.pentaho.aggdes.model.Attribute (not found)";
"org.apache.calcite.materialize.TileSuggester" ->
"org.pentaho.aggdes.model.Schema (not found)";
"org.apache.calcite.materialize.TileSuggester" ->
"org.pentaho.aggdes.model.StatisticsProvider (not found)";
"org.apache.calcite.materialize.TileSuggester$AttributeImpl" ->
"org.pentaho.aggdes.model.Attribute (not found)";
"org.apache.calcite.materialize.TileSuggester$AttributeImpl" ->
"org.pentaho.aggdes.model.Dialect (not found)";
"org.apache.calcite.materialize.TileSuggester$AttributeImpl" ->
"org.pentaho.aggdes.model.Table (not found)";
"org.apache.calcite.materialize.TileSuggester$SchemaImpl" ->
"org.pentaho.aggdes.model.Aggregate (not found)";
"org.apache.calcite.materialize.TileSuggester$SchemaImpl" ->
"org.pentaho.aggdes.model.Attribute (not found)";
"org.apache.calcite.materialize.TileSuggester$SchemaImpl" ->
"org.pentaho.aggdes.model.Dialect (not found)";
"org.apache.calcite.materialize.TileSuggester$SchemaImpl" ->
"org.pentaho.aggdes.model.Dimension (not found)";
"org.apache.calcite.materialize.TileSuggester$SchemaImpl" ->
"org.pentaho.aggdes.model.Measure (not found)";
"org.apache.calcite.materialize.TileSuggester$SchemaImpl" ->
"org.pentaho.aggdes.model.Schema (not found)";
"org.apache.calcite.materialize.TileSuggester$SchemaImpl" ->
"org.pentaho.aggdes.model.StatisticsProvider (not found)";
"org.apache.calcite.materialize.TileSuggester$SchemaImpl" ->
"org.pentaho.aggdes.model.Table (not found)";
"org.apache.calcite.materialize.TileSuggester$StatisticsProviderImpl" ->
"org.pentaho.aggdes.model.Attribute (not found)";
"org.apache.calcite.materialize.TileSuggester$StatisticsProviderImpl" ->
"org.pentaho.aggdes.model.StatisticsProvider (not found)";
"org.apache.calcite.materialize.TileSuggester$TableImpl" ->
"org.pentaho.aggdes.model.Table (not found)";
"org.apache.calcite.model.ModelHandler" ->
"com.fasterxml.jackson.dataformat.yaml.YAMLMapper (not found)";
"org.apache.calcite.profile.ProfilerImpl$HllCollector" ->
"com.yahoo.sketches.hll.HllSketch (not found)";
"org.apache.calcite.profile.ProfilerImpl$HllCollector" ->
"com.yahoo.sketches.hll.HllSketchBuilder (not found)";
"org.apache.calcite.profile.ProfilerImpl$HllCompositeCollector" ->
"com.yahoo.sketches.hll.HllSketch (not found)";
"org.apache.calcite.profile.ProfilerImpl$HllSingletonCollector" ->
"com.yahoo.sketches.hll.HllSketch (not found)";
"org.apache.calcite.runtime.GeoFunctions" -> "com.esri.core.geometry.Envelope
(not found)";
"org.apache.calcite.runtime.GeoFunctions" -> "com.esri.core.geometry.Geometry
(not found)";
"org.apache.calcite.runtime.GeoFunctions" ->
"com.esri.core.geometry.Geometry$Type (not found)";
"org.apache.calcite.runtime.GeoFunctions" ->
"com.esri.core.geometry.GeometryEngine (not found)";
"org.apache.calcite.runtime.GeoFunctions" -> "com.esri.core.geometry.Line (not
found)";
"org.apache.calcite.runtime.GeoFunctions" ->
"com.esri.core.geometry.MapGeometry (not found)";
"org.apache.calcite.runtime.GeoFunctions" -> "com.esri.core.geometry.Operator
(not found)";
"org.apache.calcite.runtime.GeoFunctions" ->
"com.esri.core.geometry.Operator$Type (not found)";
"org.apache.calcite.runtime.GeoFunctions" ->
"com.esri.core.geometry.OperatorBoundary (not found)";
"org.apache.calcite.runtime.GeoFunctions" ->
"com.esri.core.geometry.OperatorFactoryLocal (not found)";
"org.apache.calcite.runtime.GeoFunctions" ->
"com.esri.core.geometry.OperatorInter
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861240#comment-16861240
]
Mark Miller commented on SOLR-13452:
[~dsmiley], in my current build, spatial is missing the following runtime stuff
- do we actaully want this? Appears to mostly geom package stuff from
org.locationtech.jts.
{noformat}
spatial4j-0.7.jar.dot:
"org.locationtech.spatial4j.context.jts.JtsSpatialContext" ->
"org.locationtech.jts.geom.Geometry (not found)";
"org.locationtech.spatial4j.context.jts.JtsSpatialContext" ->
"org.locationtech.jts.geom.GeometryFactory (not found)";
"org.locationtech.spatial4j.context.jts.JtsSpatialContextFactory" ->
"org.locationtech.jts.geom.CoordinateSequenceFactory (not found)";
"org.locationtech.spatial4j.context.jts.JtsSpatialContextFactory" ->
"org.locationtech.jts.geom.GeometryFactory (not found)";
"org.locationtech.spatial4j.context.jts.JtsSpatialContextFactory" ->
"org.locationtech.jts.geom.PrecisionModel (not found)";
"org.locationtech.spatial4j.context.jts.JtsSpatialContextFactory" ->
"org.locationtech.jts.geom.PrecisionModel$Type (not found)";
"org.locationtech.spatial4j.context.jts.JtsSpatialContextFactory" ->
"org.locationtech.jts.geom.impl.CoordinateArraySequenceFactory (not found)";
"org.locationtech.spatial4j.io.jts.JtsBinaryCodec" ->
"org.locationtech.jts.geom.Geometry (not found)";
"org.locationtech.spatial4j.io.jts.JtsBinaryCodec" ->
"org.locationtech.jts.geom.GeometryFactory (not found)";
"org.locationtech.spatial4j.io.jts.JtsBinaryCodec" ->
"org.locationtech.jts.geom.PrecisionModel (not found)";
"org.locationtech.spatial4j.io.jts.JtsBinaryCodec" ->
"org.locationtech.jts.geom.PrecisionModel$Type (not found)";
"org.locationtech.spatial4j.io.jts.JtsBinaryCodec" ->
"org.locationtech.jts.io.InStream (not found)";
"org.locationtech.spatial4j.io.jts.JtsBinaryCodec" ->
"org.locationtech.jts.io.OutStream (not found)";
"org.locationtech.spatial4j.io.jts.JtsBinaryCodec" ->
"org.locationtech.jts.io.ParseException (not found)";
"org.locationtech.spatial4j.io.jts.JtsBinaryCodec" ->
"org.locationtech.jts.io.WKBReader (not found)";
"org.locationtech.spatial4j.io.jts.JtsBinaryCodec" ->
"org.locationtech.jts.io.WKBWriter (not found)";
"org.locationtech.spatial4j.io.jts.JtsBinaryCodec$1" ->
"org.locationtech.jts.io.InStream (not found)";
"org.locationtech.spatial4j.io.jts.JtsBinaryCodec$1" ->
"org.locationtech.jts.io.WKBConstants (not found)";
"org.locationtech.spatial4j.io.jts.JtsBinaryCodec$2" ->
"org.locationtech.jts.io.OutStream (not found)";
"org.locationtech.spatial4j.io.jts.JtsGeoJSONWriter" ->
"org.locationtech.jts.geom.Coordinate (not found)";
"org.locationtech.spatial4j.io.jts.JtsGeoJSONWriter" ->
"org.locationtech.jts.geom.CoordinateSequence (not found)";
"org.locationtech.spatial4j.io.jts.JtsGeoJSONWriter" ->
"org.locationtech.jts.geom.Geometry (not found)";
"org.locationtech.spatial4j.io.jts.JtsGeoJSONWriter" ->
"org.locationtech.jts.geom.GeometryCollection (not found)";
"org.locationtech.spatial4j.io.jts.JtsGeoJSONWriter" ->
"org.locationtech.jts.geom.LineString (not found)";
"org.locationtech.spatial4j.io.jts.JtsGeoJSONWriter" ->
"org.locationtech.jts.geom.MultiLineString (not found)";
"org.locationtech.spatial4j.io.jts.JtsGeoJSONWriter" ->
"org.locationtech.jts.geom.MultiPoint (not found)";
"org.locationtech.spatial4j.io.jts.JtsGeoJSONWriter" ->
"org.locationtech.jts.geom.MultiPolygon (not found)";
"org.locationtech.spatial4j.io.jts.JtsGeoJSONWriter" ->
"org.locationtech.jts.geom.Point (not found)";
"org.locationtech.spatial4j.io.jts.JtsGeoJSONWriter" ->
"org.locationtech.jts.geom.Polygon (not found)";
"org.locationtech.spatial4j.io.jts.JtsPolyshapeWriter" ->
"org.locationtech.jts.geom.Coordinate (not found)";
"org.locationtech.spatial4j.io.jts.JtsPolyshapeWriter" ->
"org.locationtech.jts.geom.CoordinateSequence (not found)";
"org.locationtech.spatial4j.io.jts.JtsPolyshapeWriter" ->
"org.locationtech.jts.geom.Geometry (not found)";
"org.locationtech.spatial4j.io.jts.JtsPolyshapeWriter" ->
"org.locationtech.jts.geom.GeometryCollection (not found)";
"org.locationtech.spatial4j.io.jts.JtsPolyshapeWriter" ->
"org.locationtech.jts.geom.LineString (not found)";
"org.locationtech.spatial4j.io.jts.JtsPolyshapeWriter" ->
"org.locationtech.jts.geom.MultiPoint (not found)";
"org.locationtech.spatial4j.io.jts.JtsPolyshapeWriter" ->
"org.locationtech.jts.geom.Point (not found)";
"org.locationtech.spatial4j.io.jts.JtsPolyshapeWriter" ->
"org.locationtech.jts.geom.Polygon (not found)";
"org.locationtech.spatial4j.io.jts.JtsWKTWriter" ->
"org.locationtech.jts.geom.Geometry (not found)";
"org.locationtech.spatial4j.shape.jts.JtsGeometry" ->
"org.locationtech.jts.geom.Coordinate (not found)";
"org.locationtech.spatial4j.shape.jts.JtsGeometry" ->
"org.locationtech.jts.geom.CoordinateSequence (not found)";
"org.locationtech.spatial4
[jira] [Commented] (SOLR-13437) fork noggit code to Solr
[ https://issues.apache.org/jira/browse/SOLR-13437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861222#comment-16861222 ] Mark Miller commented on SOLR-13437: We actually still have a dependency on noggit - org.locationtech.spatial4j appears to use it. > fork noggit code to Solr > > > Key: SOLR-13437 > URL: https://issues.apache.org/jira/browse/SOLR-13437 > Project: Solr > Issue Type: Task > Components: SolrJ >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > We rely on noggit for all our JSON encoding/decoding needs.The main project > is not actively maintained . We cannot easily switch to another parser > because it may cause backward incompatibility and we have advertised the > ability to use flexible JSON and we also use noggit internally in many classes -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16859508#comment-16859508
]
Mark Miller commented on SOLR-13452:
I'm fleshing out dependency checking a bit more.
jdeps is really quite useful. I'd like to work towards a couple checks that are
part of some precommit type task. I've got these targets mostly working.
The first is an extension of the above output. We can fail the task when it
appears new deps have come in and are not statically referenced. You will be
able to add exclusions with a reason when a dep is still required. To help
track down if a dep is still required, each class in a jar that looks unused
will be searched for in the src of all the project jars and if a class is
referenced in say, an xml or java file, that information will be provided.
Another task will find classes that are referenced, but no jar exists for them.
Again, we can fail the task and add exclusions and a reason where we expect and
want this (hadoop for example, annotation jars for example).
Here is some sample output for an early impl of the unusedDependencies task.
Jars with a * where found to have classes that are referenced in the src jars
of other dependencies. This is on the solr-core module:
{noformat}
Our classpath dependency count 101
Our directly used dependency count 76
List of possibly unused jars - they may be used at runtime however
(Class.forName on plugins or other dynamic Object instantiation for example).
This is not definitive, but helps narrow down what to investigate.
We take our classpath dependencies, substract our direct dependencies and then
subtract dependencies used by our direct dependencies.
Direct deps that may be unused:
-> Found org.apache.kerby.x509.type.SubjectPublicKeyInfo in src:
/home/mark/.gradle/caches/modules-2/files-2.1/org.apache.kerby/kerb-core/1.0.1/bdb610cf26e95c6b072a26be697311db445e1711/kerb-core-1.0.1-sources.jar
-> org/apache/kerby/kerberos/kerb/type/pa/pkinit/AuthPack.java
-> Found org.apache.kerby.x509.type.AlgorithmIdentifier in src:
/home/mark/.gradle/caches/modules-2/files-2.1/org.apache.kerby/kerb-core/1.0.1/bdb610cf26e95c6b072a26be697311db445e1711/kerb-core-1.0.1-sources.jar
-> org/apache/kerby/kerberos/kerb/type/pa/pkinit/AlgorithmIdentifiers.java
- kerby-pkix-1.0.1.jar *
- org.restlet.ext.servlet-2.3.0.jar
Deps brought in by other modules that may be unused in this module:
- asm-analysis-6.2.jar
-> Found org.objectweb.asm.tree.AbstractInsnNode in src:
/home/mark/.gradle/caches/modules-2/files-2.1/org.ow2.asm/asm-analysis/6.2/a14aec1bf493541fc9cb94b97eb7f8cf9f161b10/asm-analysis-6.2-sources.jar
-> org/objectweb/asm/tree/analysis/SourceValue.java
-> Found org.objectweb.asm.tree.FieldInsnNode in src:
/home/mark/.gradle/caches/modules-2/files-2.1/org.ow2.asm/asm-analysis/6.2/a14aec1bf493541fc9cb94b97eb7f8cf9f161b10/asm-analysis-6.2-sources.jar
-> org/objectweb/asm/tree/analysis/BasicInterpreter.java
-> Found org.objectweb.asm.tree.IincInsnNode in src:
/home/mark/.gradle/caches/modules-2/files-2.1/org.ow2.asm/asm-analysis/6.2/a14aec1bf493541fc9cb94b97eb7f8cf9f161b10/asm-analysis-6.2-sources.jar
-> org/objectweb/asm/tree/analysis/Analyzer.java
-> Found org.objectweb.asm.tree.InsnList in src:
/home/mark/.gradle/caches/modules-2/files-2.1/org.ow2.asm/asm-analysis/6.2/a14aec1bf493541fc9cb94b97eb7f8cf9f161b10/asm-analysis-6.2-sources.jar
-> org/objectweb/asm/tree/analysis/Analyzer.java
-> Found org.objectweb.asm.tree.InsnNode in src:
/home/mark/.gradle/caches/modules-2/files-2.1/org.ow2.asm/asm-commons/6.2/34e0c61d4d7e9921681e8053a23f4e28fbb998f1/asm-commons-6.2-sources.jar
-> org/objectweb/asm/commons/JSRInlinerAdapter.java
-> Found org.objectweb.asm.tree.IntInsnNode in src:
/home/mark/.gradle/caches/modules-2/files-2.1/org.ow2.asm/asm-analysis/6.2/a14aec1bf493541fc9cb94b97eb7f8cf9f161b10/asm-analysis-6.2-sources.jar
-> org/objectweb/asm/tree/analysis/BasicInterpreter.java
-> Found org.objectweb.asm.tree.InvokeDynamicInsnNode in src:
/home/mark/.gradle/caches/modules-2/files-2.1/org.ow2.asm/asm-analysis/6.2/a14aec1bf493541fc9cb94b97eb7f8cf9f161b10/asm-analysis-6.2-sources.jar
-> org/objectweb/asm/tree/analysis/BasicInterpreter.java
-> Found org.objectweb.asm.tree.JumpInsnNode in src:
/home/mark/.gradle/caches/modules-2/files-2.1/org.ow2.asm/asm-analysis/6.2/a14aec1bf493541fc9cb94b97eb7f8cf9f161b10/asm-analysis-6.2-sources.jar
-> org/objectweb/asm/tree/analysis/Analyzer.java
-> Found org.objectweb.asm.tree.LabelNode in src:
/home/mark/.gradle/caches/modules-2/files-2.1/org.ow2.asm/asm-analysis/6.2/a14aec1bf493541fc9cb94b97eb7f8cf9f161b10/asm-analysis-6.2-sources.jar
-> org/objectweb/asm/tree/analysis/Analyzer.java
-> Found org.objectweb.asm.tree.LdcInsnNode in src:
/home/mark/.gradle/caches/modules-2/files-2.1/org.ow2.asm/asm-analysis/6.2/a14aec1bf493541fc9cb94b97eb7f8cf9f161b10/asm-analysis-6.2-sour
[jira] [Comment Edited] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857576#comment-16857576
]
Mark Miller edited comment on SOLR-13452 at 6/6/19 11:52 AM:
-
{quote}One think I noticed is that you use File constructor a lot
{quote}
Yeah, I'm still fumbling with groovy and gradle as a Java guy. I'll do a pass
and try to convert file stuff.
FYI, the new unusedDeps task will give a printout like the following (example
on solr-core):
{noformat}
> gw unusedDeps
Our classpath dependency count 101
Our directly used dependency count 76
List of possibly unused jars - they may be used at runtime however
(Class.forName or something), this is not definitive.
We take our classpath dependenies, substract our direct dependencies and then
subtract dependencies used by our direct dependencies
asm-analysis-6.2.jar
asm-tree-6.2.jar
commons-beanutils-1.9.3.jar
kerb-crypto-1.0.1.jar
kerby-config-1.0.1.jar
kerby-pkix-1.0.1.jar
kerby-util-1.0.1.jar
lucene-spatial-8.1.0.jar
org.restlet.ext.servlet-2.3.0.jar
{noformat}
was (Author: markrmil...@gmail.com):
bq. One think I noticed is that you use File constructor a lot
Yeah, I'm still fumbling with groovy and gradle as a Java guy. I'll do a pass
and try to convert file stuff.
FYI, the new unusedDeps task will give a printout like the following:
{noformat}
> gw unusedDeps
Our classpath dependency count 101
Our directly used dependency count 76
List of possibly unused jars - they may be used at runtime however
(Class.forName or something), this is not definitive.
We take our classpath dependenies, substract our direct dependencies and then
subtract dependencies used by our direct dependencies
asm-analysis-6.2.jar
asm-tree-6.2.jar
commons-beanutils-1.9.3.jar
kerb-crypto-1.0.1.jar
kerby-config-1.0.1.jar
kerby-pkix-1.0.1.jar
kerby-util-1.0.1.jar
lucene-spatial-8.1.0.jar
org.restlet.ext.servlet-2.3.0.jar
{noformat}
> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
>
> I took some things from the great work that Dat did in
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a
> little further.
>
> When working with gradle in sub modules directly, I recommend
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version
> configuration and version consistency across modules:
> [https://github.com/palantir/gradle-consistent-versions]
>
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857576#comment-16857576
]
Mark Miller commented on SOLR-13452:
bq. One think I noticed is that you use File constructor a lot
Yeah, I'm still fumbling with groovy and gradle as a Java guy. I'll do a pass
and try to convert file stuff.
FYI, the new unusedDeps task will give a printout like the following:
{noformat}
> gw unusedDeps
Our classpath dependency count 101
Our directly used dependency count 76
List of possibly unused jars - they may be used at runtime however
(Class.forName or something), this is not definitive.
We take our classpath dependenies, substract our direct dependencies and then
subtract dependencies used by our direct dependencies
asm-analysis-6.2.jar
asm-tree-6.2.jar
commons-beanutils-1.9.3.jar
kerb-crypto-1.0.1.jar
kerby-config-1.0.1.jar
kerby-pkix-1.0.1.jar
kerby-util-1.0.1.jar
lucene-spatial-8.1.0.jar
org.restlet.ext.servlet-2.3.0.jar
{noformat}
> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
>
> I took some things from the great work that Dat did in
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a
> little further.
>
> When working with gradle in sub modules directly, I recommend
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version
> configuration and version consistency across modules:
> [https://github.com/palantir/gradle-consistent-versions]
>
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13489) Stop the leader from trying to rejoin the election on session expiration and harden our zk reconnect code path.
[ https://issues.apache.org/jira/browse/SOLR-13489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-13489. Resolution: Fixed Fix Version/s: 8.2 master (9.0) Thanks [~anshumg]! > Stop the leader from trying to rejoin the election on session expiration and > harden our zk reconnect code path. > --- > > Key: SOLR-13489 > URL: https://issues.apache.org/jira/browse/SOLR-13489 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0), 8.2 > > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-13489) Stop the leader from trying to rejoin the election on session expiration and harden our zk reconnect code path.
[ https://issues.apache.org/jira/browse/SOLR-13489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13489: --- Comment: was deleted (was: Commit 6b33695c8673afd5d0742076ef5160a98ec2171e in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_3 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6b33695 ] SOLR-13489: Add jflex targets to lucene:analysis:common. ) > Stop the leader from trying to rejoin the election on session expiration and > harden our zk reconnect code path. > --- > > Key: SOLR-13489 > URL: https://issues.apache.org/jira/browse/SOLR-13489 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-13489) Stop the leader from trying to rejoin the election on session expiration and harden our zk reconnect code path.
[ https://issues.apache.org/jira/browse/SOLR-13489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13489: --- Comment: was deleted (was: Commit 47fe3c8242f50343a2e94b40244044d528d8a529 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_3 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=47fe3c8 ] SOLR-13489: Remove regenerate debug output. ) > Stop the leader from trying to rejoin the election on session expiration and > harden our zk reconnect code path. > --- > > Key: SOLR-13489 > URL: https://issues.apache.org/jira/browse/SOLR-13489 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-13489) Stop the leader from trying to rejoin the election on session expiration and harden our zk reconnect code path.
[ https://issues.apache.org/jira/browse/SOLR-13489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13489: --- Comment: was deleted (was: Commit 6d433a233bf0ff3c75027cf36b24c976fb7442b5 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_3 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6d433a2 ] SOLR-13489: First pass at patchSnowball target. ) > Stop the leader from trying to rejoin the election on session expiration and > harden our zk reconnect code path. > --- > > Key: SOLR-13489 > URL: https://issues.apache.org/jira/browse/SOLR-13489 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-13489) Stop the leader from trying to rejoin the election on session expiration and harden our zk reconnect code path.
[ https://issues.apache.org/jira/browse/SOLR-13489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13489: --- Comment: was deleted (was: Commit fdd5f3428e0b2cd41dd5775773f206dfc992c758 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_3 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=fdd5f34 ] SOLR-13489: Fix the CheckSourcePattern warnings when running grawlew. ) > Stop the leader from trying to rejoin the election on session expiration and > harden our zk reconnect code path. > --- > > Key: SOLR-13489 > URL: https://issues.apache.org/jira/browse/SOLR-13489 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853901#comment-16853901 ] Mark Miller commented on SOLR-13452: Maybe in a couple weeks we could start running side by side in master until we are ready for a switch over. I'd like to start building 9 with gradle and continue releasing 8 built by ant, even if someone wants to pull gradle back to 8. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Description: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend [https://github.com/dougborg/gdub] This gradle branch uses the following plugin for version locking, version configuration and version consistency across modules: [https://github.com/palantir/gradle-consistent-versions] https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 was: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend [https://github.com/dougborg/gdub] This gradle branch uses the following plugin for version locking, version configuration and version consistency across modules: [https://github.com/palantir/gradle-consistent-versions] https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_2 > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Comment: was deleted (was: Commit 785c349bdbd83852a12f6297ee5245d127b14e98 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_3 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=785c349 ] SOLR-13452: First pass at a testTimes target. ) > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_2 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853763#comment-16853763 ] Mark Miller commented on SOLR-13452: The version locking is really the key thing - it gives a precise and compact view of what has changed, you have to commit a diff of those changes, and it will be checked and cause targets to fail well before precommit. Running tests will fail, building will fail, etc. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_2 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853762#comment-16853762
]
Mark Miller commented on SOLR-13452:
{quote}as long as something unexpected will fail precommit, probably due to a
missing checksum.
{quote}
There are a variety of checks and enforcers that would fire and alert of you
all the changes going on - you would then have to accept and commit those
changes.
For example, let's say you update a single version of a library and it adds a
couple of dependencies and changes the versions of a couple others.
* The license check would fail for new dependencies.
* The jar checksum check would fail for new dependencies and for version
changes.
* The versions plugin would fail the check target until you do gradlew
--write-locks and review/accept an updated versions.locks file that lists every
dependency and it's current version.
IMO, the best idea is to let gradle handle transitive deps and version
resolution - it will do the best job. A human then reviews and either accepts
or makes constraints / exceptions. The whole system is designed to work this
way really, and when done right, it's really the best we have IMHO.
bq. Does the precommit check notice when there's a checksum but no matching jar?
This is a little more complicated than that to do well or thoroughly. There is
a cool plugin that helps with this, but it doesn't work with implementation and
api yet. When it does, we can use it to find deps that are not actually used by
anything anymore.
> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
>
> I took some things from the great work that Dat did in
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a
> little further.
>
> When working with gradle in sub modules directly, I recommend
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version
> configuration and version consistency across modules:
> [https://github.com/palantir/gradle-consistent-versions]
>
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_2
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853360#comment-16853360 ] Mark Miller commented on SOLR-13452: Dev has rolled over to SOLR-13452_gradle_3, which is now up to date with master. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_2 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853358#comment-16853358
]
Mark Miller commented on SOLR-13452:
{quote}I don't think we can go slower than the current ant build, with its
recursive duplicated checks. ;)
{quote}
Oh I figured it would be much faster, but I didn't realize how addictive that
would be on beefy hardware. The fact that so much more is done in parallel and
per project , everything can be just so snappy. Most of precommit can just run
all the time basically. Things like running all the tests in parallel instead
of per modules is also just so nice, waiting for Solr contrib tests as it runs
2-3 jvms at a time is just such a drag. I figured that ant was fast enough
basically, but if you have a nice desktop and taste this speed, good luck going
back to dial up.
> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
>
> I took some things from the great work that Dat did in
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a
> little further.
>
> When working with gradle in sub modules directly, I recommend
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version
> configuration and version consistency across modules:
> [https://github.com/palantir/gradle-consistent-versions]
>
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_2
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-13489) Stop the leader from trying to rejoin the election on session expiration and harden our zk reconnect code path.
[ https://issues.apache.org/jira/browse/SOLR-13489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13489: --- Comment: was deleted (was: Commit fa57ba631f4d107431fb3f39d4c320fad5d9 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_2 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=fa57ba6 ] SOLR-13489: Fix the CheckSourcePattern warnings when running grawlew. ) > Stop the leader from trying to rejoin the election on session expiration and > harden our zk reconnect code path. > --- > > Key: SOLR-13489 > URL: https://issues.apache.org/jira/browse/SOLR-13489 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-13489) Stop the leader from trying to rejoin the election on session expiration and harden our zk reconnect code path.
[ https://issues.apache.org/jira/browse/SOLR-13489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13489: --- Comment: was deleted (was: Commit 3801e56a21f135f5ab9d79caa7523bd08c1bceb0 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_2 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3801e56 ] SOLR-13489: First pass at patchSnowball target. ) > Stop the leader from trying to rejoin the election on session expiration and > harden our zk reconnect code path. > --- > > Key: SOLR-13489 > URL: https://issues.apache.org/jira/browse/SOLR-13489 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-13489) Stop the leader from trying to rejoin the election on session expiration and harden our zk reconnect code path.
[ https://issues.apache.org/jira/browse/SOLR-13489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13489: --- Comment: was deleted (was: Commit 01ec8cf81955b6a1087a3bbe16dc9082e58e7d30 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_2 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=01ec8cf ] SOLR-13489: Add jflex targets to lucene:analysis:common. ) > Stop the leader from trying to rejoin the election on session expiration and > harden our zk reconnect code path. > --- > > Key: SOLR-13489 > URL: https://issues.apache.org/jira/browse/SOLR-13489 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-13489) Stop the leader from trying to rejoin the election on session expiration and harden our zk reconnect code path.
[ https://issues.apache.org/jira/browse/SOLR-13489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13489: --- Comment: was deleted (was: Commit 7e2eb07499bccf1e462e67814a6c2ebfa54ed799 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_2 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7e2eb07 ] SOLR-13489: Remove regenerate debug output. ) > Stop the leader from trying to rejoin the election on session expiration and > harden our zk reconnect code path. > --- > > Key: SOLR-13489 > URL: https://issues.apache.org/jira/browse/SOLR-13489 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13501) Use Http2SolrClient in DUP and remove ConcurrentUpdateHttp2SolrClient.
[ https://issues.apache.org/jira/browse/SOLR-13501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16852051#comment-16852051 ] Mark Miller commented on SOLR-13501: Dat let me know this was done because of performance issues we have to solve. So we will need to benchmark and tune well before making this change. > Use Http2SolrClient in DUP and remove ConcurrentUpdateHttp2SolrClient. > -- > > Key: SOLR-13501 > URL: https://issues.apache.org/jira/browse/SOLR-13501 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: 8.2 > > > One of the great things about Http2SolrClient is that it removes the need for > the complicated and trappy ConcurrentUpdateSolrServer. The Jetty HttpClient > already has queues and handles all of this stuff better than we do. > DUP should be using async and Http2SolrClient and now properly handling > errors and such for the first time, unless I am missing something ... -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13489) Stop the leader from trying to rejoin the election on session expiration and harden our zk reconnect code path.
[ https://issues.apache.org/jira/browse/SOLR-13489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16852049#comment-16852049 ] Mark Miller commented on SOLR-13489: I don't really have something I can commit, but I test this by forcing stop the world gc pauses, repeatedly with random time between, ensuring it tests real world gc pauses and tests them happening again during the reconnect phase. It's a bit of a hack to do this, how well it works depends on the garbage collector, it can take a very long time to run if you dont have great hardware, and so it's not really unit test material. > Stop the leader from trying to rejoin the election on session expiration and > harden our zk reconnect code path. > --- > > Key: SOLR-13489 > URL: https://issues.apache.org/jira/browse/SOLR-13489 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13501) Use Http2SolrClient in DUP and remove ConcurrentUpdateHttp2SolrClient.
[ https://issues.apache.org/jira/browse/SOLR-13501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16852037#comment-16852037 ] Mark Miller commented on SOLR-13501: CUSC is intended to open a variety of connections and stream across them. With http2 we actually only want one connection. Http2SolrClient is already the dream. We want to use it to use a single connection per server, to do async requests (with built in queues and update / reordering / concurrency handling), and to have one client thats better than all the others (well 2, also CloudSolrClient). > Use Http2SolrClient in DUP and remove ConcurrentUpdateHttp2SolrClient. > -- > > Key: SOLR-13501 > URL: https://issues.apache.org/jira/browse/SOLR-13501 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: 8.2 > > > One of the great things about Http2SolrClient is that it removes the need for > the complicated and trappy ConcurrentUpdateSolrServer. The Jetty HttpClient > already has queues and handles all of this stuff better than we do. > DUP should be using async and Http2SolrClient and now properly handling > errors and such for the first time, unless I am missing something ... -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13501) Use Http2SolrClient in DUP and remove ConcurrentUpdateHttp2SolrClient.
[ https://issues.apache.org/jira/browse/SOLR-13501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16852027#comment-16852027 ] Mark Miller commented on SOLR-13501: ConcurrentUpdateHttp2SolrClient#offer(E e, long timeout, TimeUnit unit) has a race that can leave requests stuck - rather than fix things like this (like ConcurrentUpdateSolrClient, this stuff is too complicated) I think we should remove this class and use Http2SolrClient like it was intended - as the client to replace all clients. > Use Http2SolrClient in DUP and remove ConcurrentUpdateHttp2SolrClient. > -- > > Key: SOLR-13501 > URL: https://issues.apache.org/jira/browse/SOLR-13501 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: 8.2 > > > One of the great things about Http2SolrClient is that it removes the need for > the complicated and trappy ConcurrentUpdateSolrServer. The Jetty HttpClient > already has queues and handles all of this stuff better than we do. > DUP should be using async and Http2SolrClient and now properly handling > errors and such for the first time, unless I am missing something ... -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-12406) Stop using response.sendError because it closes connections instead of allowing the client to manage connection the lifecycle.
[ https://issues.apache.org/jira/browse/SOLR-12406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-12406: -- Assignee: Mark Miller > Stop using response.sendError because it closes connections instead of > allowing the client to manage connection the lifecycle. > -- > > Key: SOLR-12406 > URL: https://issues.apache.org/jira/browse/SOLR-12406 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Environment: Bad for connection reuse, bad for client connection from > pool use races. >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > > This doesn't play well with our clients either. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13501) Use Http2SolrClient in DUP and remove ConcurrentUpdateHttp2SolrClient.
[ https://issues.apache.org/jira/browse/SOLR-13501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-13501: -- Assignee: Mark Miller > Use Http2SolrClient in DUP and remove ConcurrentUpdateHttp2SolrClient. > -- > > Key: SOLR-13501 > URL: https://issues.apache.org/jira/browse/SOLR-13501 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: 8.2 > > > One of the great things about Http2SolrClient is that it removes the need for > the complicated and trappy ConcurrentUpdateSolrServer. The Jetty HttpClient > already has queues and handles all of this stuff better than we do. > DUP should be using async and Http2SolrClient and now properly handling > errors and such for the first time, unless I am missing something ... -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13501) Use Http2SolrClient in DUP and remove ConcurrentUpdateHttp2SolrClient.
Mark Miller created SOLR-13501: -- Summary: Use Http2SolrClient in DUP and remove ConcurrentUpdateHttp2SolrClient. Key: SOLR-13501 URL: https://issues.apache.org/jira/browse/SOLR-13501 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Mark Miller Fix For: 8.2 One of the great things about Http2SolrClient is that it removes the need for the complicated and trappy ConcurrentUpdateSolrServer. The Jetty HttpClient already has queues and handles all of this stuff better than we do. DUP should be using async and Http2SolrClient and now properly handling errors and such for the first time, unless I am missing something ... -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13489) Stop the leader from trying to rejoin the election on session expiration and harden our zk reconnect code path.
[ https://issues.apache.org/jira/browse/SOLR-13489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16849930#comment-16849930 ] Mark Miller commented on SOLR-13489: Pull request and patch for review: https://patch-diff.githubusercontent.com/raw/apache/lucene-solr/pull/689 https://patch-diff.githubusercontent.com/raw/apache/lucene-solr/pull/689.patch > Stop the leader from trying to rejoin the election on session expiration and > harden our zk reconnect code path. > --- > > Key: SOLR-13489 > URL: https://issues.apache.org/jira/browse/SOLR-13489 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13489) Stop the leader from trying to rejoin the election on session expiration and harden our zk reconnect code path.
[ https://issues.apache.org/jira/browse/SOLR-13489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16849930#comment-16849930 ] Mark Miller edited comment on SOLR-13489 at 5/28/19 5:00 PM: - Pull request and patch for review: https://github.com/apache/lucene-solr/pull/689 [https://patch-diff.githubusercontent.com/raw/apache/lucene-solr/pull/689.patch|https://github.com/apache/lucene-solr/pull/689] was (Author: markrmil...@gmail.com): Pull request and patch for review: https://patch-diff.githubusercontent.com/raw/apache/lucene-solr/pull/689 https://patch-diff.githubusercontent.com/raw/apache/lucene-solr/pull/689.patch > Stop the leader from trying to rejoin the election on session expiration and > harden our zk reconnect code path. > --- > > Key: SOLR-13489 > URL: https://issues.apache.org/jira/browse/SOLR-13489 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13489) Fix various issues impacting stability on Zookeeper expiration reconnect.Stop the leader from trying to rejoin the election on session expiration and harden our zk reconn
[ https://issues.apache.org/jira/browse/SOLR-13489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13489: --- Summary: Fix various issues impacting stability on Zookeeper expiration reconnect.Stop the leader from trying to rejoin the election on session expiration and harden our zk reconnect code path. (was: Fix various issues impacting stability on Zookeeper expiration reconnect.) > Fix various issues impacting stability on Zookeeper expiration reconnect.Stop > the leader from trying to rejoin the election on session expiration and > harden our zk reconnect code path. > > > Key: SOLR-13489 > URL: https://issues.apache.org/jira/browse/SOLR-13489 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13489) Stop the leader from trying to rejoin the election on session expiration and harden our zk reconnect code path.
[ https://issues.apache.org/jira/browse/SOLR-13489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13489: --- Summary: Stop the leader from trying to rejoin the election on session expiration and harden our zk reconnect code path. (was: Fix various issues impacting stability on Zookeeper expiration reconnect.Stop the leader from trying to rejoin the election on session expiration and harden our zk reconnect code path.) > Stop the leader from trying to rejoin the election on session expiration and > harden our zk reconnect code path. > --- > > Key: SOLR-13489 > URL: https://issues.apache.org/jira/browse/SOLR-13489 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16849854#comment-16849854 ] Mark Miller commented on SOLR-13452: Forget what I said about not being interested in the performance differences. It's painful to go back to the ant build now and the gradle build is even doing most of precommit in the normal course of build targets. Doing so much more in parallel is huge on good hardware. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_2 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Fix Version/s: master (9.0) > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_2 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-13452: -- Assignee: Mark Miller > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_2 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16849232#comment-16849232 ] Mark Miller commented on SOLR-13452: And just like with transitive dependencies, versions are not just changing and updating behind your back - we have the versions.lock file and you have --write-locks when versions change and accept them. It does what you should and are probably not doing, and you have to verify it was you want. A much better situation. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_2 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16849228#comment-16849228
]
Mark Miller commented on SOLR-13452:
{quote}But I bet there's a million ways to do it
{quote}
My perspective is somewhat tainted by a what is now a long history of working
with lots of different modules in lots of different projects all inter
depending on each other. It creates some unique jar hell headaches. I've seen
and tried various ways around it and I think they did at Palantir as well (they
have some great gradle plugins).
In this type of world, where you need to harmonize dependencies across so many
inter-connected projects, I've found the best thing you can do is embrace the
build systems, use transitive dependencies with checks and tools on top, avoid
forcing versions wherever possible, use Platforms (Maven BOM's) and version
contrainsts plugin to ensure consistent versions across submodules. We can
publish our own BOM as well.
Then, versions are chosen and updates by figuring out what makes the most
sense. When that doesn't work, constraints can be added. Creating a system that
enforces single versions per project across submodules, and then allowing the
system to harmonize versions using BOM's and dependencies trees really keeps
things in the best state and gives the minimal effort required while allowing
you to enforce all the old constraints you enjoyed.
When the build handles versions and looks at BOM's and what not it can do cool
things like ensure all of our various jackson dependencies are at the highest
level that makes sense, but also that they are all the same version. We can
provide the same thing to our consumers, that however they add lucene and solr
dependencies to their build, a consistent version resolves for them.
Now when one dependency updates a sub dependency for a security vulnerability
or a performance fix, we also pick that up instead of our current super slow
update times. Dependency combos have fewer runtime surprises and versions get
updated more often when they should get updated.
We add constraints and exceptions and otherwise let the build do smart more
consistent work for us.
> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Reporter: Mark Miller
>Priority: Major
>
> I took some things from the great work that Dat did in
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a
> little further.
>
> When working with gradle in sub modules directly, I recommend
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version
> configuration and version consistency across modules:
> [https://github.com/palantir/gradle-consistent-versions]
>
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_2
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16849158#comment-16849158 ] Mark Miller commented on SOLR-13452: bq. I myself use transitive deps in gradle, carefully checking for unwanted dependencies If i was starting my own project, this is how I would do it. I do think the benefits outweigh the negatives and you can mitigate the negatives. So I think we have agreement, I just don't know that a couple of us agreeing could push it through. But if it means we get real version resolution (that can work with BOMs/Platforms and constraints, etc) and it's easier to add new dependencies, I think we should def explore it. Working with the grain usually ends up nicer than against, even if we have to add some wood or something. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_2 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16849153#comment-16849153 ] Mark Miller commented on SOLR-13452: bq. I think it'll pick whatever you choose if you disable transitivity. I'll experiment a bit then. That would not be great, version resolution is much better done by the build than by humans IMO. If we where to simply turn on transitive and match what we have now with excludes, it's not like the build is going to balloon that quickly and interested parties can help keep things minimal. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_2 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16849137#comment-16849137 ] Mark Miller edited comment on SOLR-13452 at 5/27/19 7:08 PM: - bq. Both approaches have their pros and cons. No worries. Right, any project could go either way, so it has more to do with what the community will allow or go with and what I can manage to get bogged down with here. Technical issues aside, it's not easy to make a big change like this with so many developers on the project. One thing that could def put weight towards using transitive with excludes is if we don't get full version resolution without transitive. For example, if zookeeper says it wants commons-io 2.4 and we have transitive false, when we pick our commons-io version, does it still take that into account? [~dweiss], [~thetaphi], do you know? If we did't get proper version resolution, I'd really argue we should change how we do things sooner rather than later. was (Author: markrmil...@gmail.com): bq. Both approaches have their pros and cons. No worries. Right, any project could go either way, so it has more to do with what the community will allow or go with and what I can manage to get bogged down with her. Technical issues aside, it's not easy to make a big change like this with so many developers on the project. One thing that could def put weight towards using transitive with excludes is if we don't get full version resolution without transitive. For example, if zookeeper says it wants commons-io 2.4 and we have transitive false, when we pick our commons-io version, does it still take that into account? [~dweiss], [~thetaphi], do you know? If we did't get proper version resolution, I'd really argue we should change how we do things sooner rather than later. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_2 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16849137#comment-16849137 ] Mark Miller commented on SOLR-13452: bq. Both approaches have their pros and cons. No worries. Right, any project could go either way, so it has more to do with what the community will allow or go with and what I can manage to get bogged down with her. Technical issues aside, it's not easy to make a big change like this with so many developers on the project. One thing that could def put weight towards using transitive with excludes is if we don't get full version resolution without transitive. For example, if zookeeper says it wants commons-io 2.4 and we have transitive false, when we pick our commons-io version, does it still take that into account? [~dweiss], [~thetaphi], do you know? If we did't get proper version resolution, I'd really argue we should change how we do things sooner rather than later. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_2 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16848981#comment-16848981
]
Mark Miller commented on SOLR-13452:
{quote}I don't want to heat things up, but I've been wondering – perhaps
instead of disabling transitive dependencies we can just embrace them while
harnessing uncontrolled dependencies via final-jar dependency checksums (which
we already do)? I am well aware of the pitfalls that come with transitive
dependencies, yet I think those final JAR checksum checks effectively prevent
us from slurping new jar files upon upgrades. And dependencies of each module
become much easier to grasp and express then. Somehow I don't think explicit
flattening of all dependencies (non-transitive expression) is much more helpful
than a transitive dependency on the "root" library (possibly excluding truly
unnecessary junk), followed by sanity check preventing (or enforcing) a manual
eyeball if something changes.{quote}
I've thought about this as well. Not only we do have the license files and jar
checksums, but also dep locking. So deps won't just sneak in. I went back to
one of the primary reasons I have always had a distaste for Maven though -
people are lazy when it comes to deps. They add tons to their projects without
much care or thought. They suck up everything without much care or thought.
Next thing you know, you write a simple calculator app and the build downloads
5 gig the first time you do mvn build.
So yeah, I'm with you largely, but I do really like one thing about no
transitive deps - we default to figuring out the min we need instead of the
opposite, and that means we stay slimmer over time I think. Take the ZooKeeper
example. It brings in some random stuff we don't need or want, but when you
first add that dep are you going to be careful and choosy and try things out
with certain transitive excludes? Not likely, you just suck it all in and add
the licenses and checksums and new lock files. With transitive=false, you add
the zk dep, everything works and boom, you don't add the other unnecessary
stuff.
I'm open to whatever people prefer, there are also pain points to
transitive=false, but we don't have to decide now - we can change later on if
we would prefer.
> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Reporter: Mark Miller
>Priority: Major
>
> I took some things from the great work that Dat did in
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a
> little further.
>
> When working with gradle in sub modules directly, I recommend
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version
> configuration and version consistency across modules:
> [https://github.com/palantir/gradle-consistent-versions]
>
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_2
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16848976#comment-16848976 ] Mark Miller commented on SOLR-13452: Dev has rolled over to SOLR-13452_gradle_2, which is now up to date with master. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_2 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Description: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend [https://github.com/dougborg/gdub] This gradle branch uses the following plugin for version locking, version configuration and version consistency across modules: [https://github.com/palantir/gradle-consistent-versions] https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_2 was: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend [https://github.com/dougborg/gdub] This gradle branch uses the following plugin for version locking, version configuration and version consistency across modules: [https://github.com/palantir/gradle-consistent-versions] > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_2 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Description: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend [https://github.com/dougborg/gdub] This gradle branch uses the following plugin for version locking, version configuration and version consistency across modules: [https://github.com/palantir/gradle-consistent-versions] was: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend [https://github.com/dougborg/gdub] This gradle branch uses the following plugin for version locking, version configuration and version consistency across modules: [https://github.com/palantir/gradle-consistent-versions] By default, dependencies are not transitive, but there is a special Configuration for adding dependencies on other project internal modules that are transitive to their direct external dependencies (their jar libs). > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13489) Fix various issues impacting stability on Zookeeper expiration reconnect.
[ https://issues.apache.org/jira/browse/SOLR-13489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847924#comment-16847924 ] Mark Miller commented on SOLR-13489: This is one of the hardest to test areas and since it often happens in less than ideal conditions it's also important to test reconnect under many different (possibly repeating) failure cases. This area is a bit of our soft under-shell, though developers have made many fixes and improvements over the years. This stuff works a lot more often than it used to in master. I have a few more of those fixes and improvements. > Fix various issues impacting stability on Zookeeper expiration reconnect. > - > > Key: SOLR-13489 > URL: https://issues.apache.org/jira/browse/SOLR-13489 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13489) Fix various issues impacting stability on Zookeeper expiration reconnect.
Mark Miller created SOLR-13489: -- Summary: Fix various issues impacting stability on Zookeeper expiration reconnect. Key: SOLR-13489 URL: https://issues.apache.org/jira/browse/SOLR-13489 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Mark Miller Assignee: Mark Miller -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847009#comment-16847009 ] Mark Miller commented on SOLR-13452: FYI, on Saturday I will roll this to a new SOLR-13452_gradle_2 branch as I would like to do a clean rebase and catch things back up to master. Rather than force pushing, I'll roll the branch. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16846104#comment-16846104 ] Mark Miller commented on SOLR-13452: [~varunthacker] thanks for taking a look! Yeah, jflex is still like 70% done and I have not done that hack yet to disable buffer expansion. I'll try and wrap up the regenerate tasks soon! > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16844245#comment-16844245 ] Mark Miller edited comment on SOLR-13452 at 5/20/19 8:59 PM: - The above commit let's you test the build using your local check out in docker. This is very basic at the moment and just runs a few targets. By doing this in docker we can control various isolation levels, a clean dependency cache environment and can install certain target pre-requisites like python. We could shorten the dependency gathering phase with an apt cache image or by sharing local caches with Docker if wanted to. The test is in buildSrc and implemented as a new target called buildTest (I have not tested that much yet, just running from eclipse directly so far). It's implemented as a Java junit test that calls out to bash. A test script is run and configured to fail the junit test if any command fails. The test has an assume that basically checks for unix and docker command availability. was (Author: markrmil...@gmail.com): The above commit let's you test the build using your local check out in docker. This is very basic at the moment and just runs a few targets. By doing this in docker we can control various isolation levels, a clean dependency cache environment and can install certain target pre-requisites like python. We could shorten the dependency gathering phase with an apt cache image or by sharing local caches with Docker if wanted to. The test is in buildSrc and implemented as a new target called testBuild (I have not tested that much yet, just running from eclipse directly so far). It's implemented as a Java junit test that calls out to bash. A test script is run and configured to fail the junit test if any command fails. The test has an assume that basically checks for unix and docker command availability. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16844245#comment-16844245 ] Mark Miller commented on SOLR-13452: The above commit let's you test the build using your local check out in docker. This is very basic at the moment and just runs a few targets. By doing this in docker we can control various isolation levels, a clean dependency cache environment and can install certain target pre-requisites like python. We could shorten the dependency gathering phase with an apt cache image or by sharing local caches with Docker if wanted to. The test is in buildSrc and implemented as a new target called testBuild (I have not tested that much yet, just running from eclipse directly so far). It's implemented as a Java junit test that calls out to bash. A test script is run and configured to fail the junit test if any command fails. The test has an assume that basically checks for unix and docker command availability. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843336#comment-16843336 ] Mark Miller commented on SOLR-13452: Starting on Apache Rat next. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843293#comment-16843293 ] Mark Miller commented on SOLR-13452: I tried to solve all the issues you brought up Uwe , but without pulling buildSrc out of settings.gradle. I think it's really nice to have that tied in as a module for eclipse integration, for using the same gradle setup as the all the other modules, etc. Let me know if this solves your concerns. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843256#comment-16843256
]
Mark Miller commented on SOLR-13452:
{quote}The result of this is that the buildSrc dir is treated as a separate
subproject, so all the configurations are applied to it, too.
{quote}
It turns out the reason I did this was it's the only way it showed up nicely as
a project in eclipse. I'll see what I can do about getting the buildSrc
.project to somehow import anyway - it's very nice to have that java and groovy
code as a project in eclipse on import. I guess you could import it as a
separate project? What do other projects do?
> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Reporter: Mark Miller
>Priority: Major
>
> I took some things from the great work that Dat did in
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a
> little further.
>
> When working with gradle in sub modules directly, I recommend
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version
> configuration and version consistency across modules:
> [https://github.com/palantir/gradle-consistent-versions]
> By default, dependencies are not transitive, but there is a special
> Configuration for adding dependencies on other project internal modules that
> are transitive to their direct external dependencies (their jar libs).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843252#comment-16843252
]
Mark Miller edited comment on SOLR-13452 at 5/18/19 9:43 PM:
-
Did some quick testing to ensure we are not regressing in multi-module build
performance:
{noformat}
with deps cached and warmed up (ant cmd run more than once and gradle daemon on)
ant clean compile-test
Total time: 1 minute 35 seconds
gw clean compileTestJava
BUILD SUCCESSFUL in 27s
cold run with no deps cached (gradle daemon on)
ant clean compile-test
Total time: 7 minutes 19 seconds
gw clean compileTestJava
BUILD SUCCESSFUL in 1m 7s
{noformat}
was (Author: markrmil...@gmail.com):
Did some quick testing to ensure we are not regressing in multi-module build
performance:
{noformat}
with deps cached and warmed up (ant cmd run more than once and gradle daemon on)
ant clean compile-java
Total time: 1 minute 35 seconds
gw clean compileTestJava
BUILD SUCCESSFUL in 27s
cold run with no deps cached (gradle daemon on)
ant clean compile-test
Total time: 7 minutes 19 seconds
gw clean compileTestJava
BUILD SUCCESSFUL in 1m 7s
{noformat}
> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Reporter: Mark Miller
>Priority: Major
>
> I took some things from the great work that Dat did in
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a
> little further.
>
> When working with gradle in sub modules directly, I recommend
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version
> configuration and version consistency across modules:
> [https://github.com/palantir/gradle-consistent-versions]
> By default, dependencies are not transitive, but there is a special
> Configuration for adding dependencies on other project internal modules that
> are transitive to their direct external dependencies (their jar libs).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843252#comment-16843252
]
Mark Miller commented on SOLR-13452:
Did some quick testing to ensure we are not regressing in multi-module build
performance:
{noformat}
with deps cached and warmed up (ant cmd run more than once and gradle daemon on)
ant clean compile-java
Total time: 1 minute 35 seconds
gw clean compileTestJava
BUILD SUCCESSFUL in 27s
cold run with no deps cached (gradle daemon on)
ant clean compile-test
Total time: 7 minutes 19 seconds
gw clean compileTestJava
BUILD SUCCESSFUL in 1m 7s
{noformat}
> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Reporter: Mark Miller
>Priority: Major
>
> I took some things from the great work that Dat did in
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a
> little further.
>
> When working with gradle in sub modules directly, I recommend
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version
> configuration and version consistency across modules:
> [https://github.com/palantir/gradle-consistent-versions]
> By default, dependencies are not transitive, but there is a special
> Configuration for adding dependencies on other project internal modules that
> are transitive to their direct external dependencies (their jar libs).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13266) /update/json/docs should support the JSON record format
[ https://issues.apache.org/jira/browse/SOLR-13266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843235#comment-16843235 ] Mark Miller commented on SOLR-13266: Generally, pulling a project or code base that was developed outside of Apache wants a code grant from the owner. > /update/json/docs should support the JSON record format > --- > > Key: SOLR-13266 > URL: https://issues.apache.org/jira/browse/SOLR-13266 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > > This is a standard [JSON format |https://tools.ietf.org/html/rfc7464]that > Solr does not support -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840871#comment-16840871 ] Mark Miller commented on SOLR-13452: Cool, that all sounds good to me. I hadn't even seen a buildSrc module before, so however it's supposed to be done sounds good. In terms of compileOnly and stuff, I've only been experimenting, so change away. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840570#comment-16840570 ] Mark Miller commented on SOLR-13452: bq. IMHO, the build plugin should also contain the JFlex task, currently its applied on top-level. Ah, I misread this, I thought you meant there should be a jflex task top level. I tried to put this in buildSrc only and had some issues access the right classpath for the ant task def, but I agree. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840562#comment-16840562 ] Mark Miller commented on SOLR-13452: bq. What's the exact issue with forbidden-apis? It fails because it was checking hadoop classes or something and I see in ant there are excludes for that, but we don't have them here yet. bq. IMHO, the build plugin should also contain the JFlex task, currently its applied on top-level. Yeah, I think that makes sense, JFlex is not fully done yet, maybe 70%. bq. While playing around, it was hard to me to find all custom defined tasks, as none of them has a description. I'll address that. In general, I just tried to start pulling some config out of the main build.gradle as I find it becomes hard to follow easily. I don't know if that is good practice or what we should do or what, but I think for me it made things simpler. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840459#comment-16840459 ] Mark Miller edited comment on SOLR-13452 at 5/15/19 2:24 PM: - I think Groovy seems more widely known and used with Gradle currently and one of the primary motivations here is to use something that most devs will be familiar with and that has great support and tooling. If that changes, we would/could consider moving in the future I would imagine. was (Author: markrmil...@gmail.com): I think Goovy seems more widely known and used with Gradle currently and one of the primary motivations here is to use something that most devs will be familiar with and that has great support and tooling. If that changes, we would/cloud consider moving in the future I would imagine. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840459#comment-16840459 ] Mark Miller commented on SOLR-13452: I think Goovy seems more widely known and used with Gradle currently and one of the primary motivations here is to use something that most devs will be familiar with and that has great support and tooling. If that changes, we would/cloud consider moving in the future I would imagine. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Description: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend [https://github.com/dougborg/gdub] This gradle branch uses the following plugin for version locking, version configuration and version consistency across modules: [https://github.com/palantir/gradle-consistent-versions] By default, dependencies are not transitive, but there is a special Configuration for adding dependencies on other project internal modules that are transitive to their direct external dependencies (their jar libs). was: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend https://github.com/dougborg/gdub > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Description: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend https://github.com/dougborg/gdub was:I took some things from the great work that Dat did in https://github.com/apache/lucene-solr/tree/jira/gradle and took the ball a little further. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > https://github.com/dougborg/gdub -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
