I don't know about what Gradle offers other than observing what Erick shares, but I like to think that we can get rid of not only the Ant build but the Maven build too. If there are obstacles, I'd prefer to figure them out rather than settle for the complexity (and thus maintenance costs) of an entire parallel build.
I wondered if perhaps this protobuf dependency is something we don't need -- it seems to be an optional dependency of Calcite. Disclaimer: I looked very quickly; didn't fully verify. So I did a little removing of it and then found the same HTTP problem but for a different dependency now -- Dropwizard metrics-bom which is definitely something we depend on. I was unable to work around this bug of the Maven Ant Task but didn't spend much time on it. I was looking for the source and had trouble finding it, then realized this thing is like 6 years old and has been superseded by the "Maven Artifact Resolver Ant Task": https://maven.apache.org/resolver-ant-tasks/. It looks similar to the old one. ~ David On Mon, Jun 15, 2020 at 5:06 PM Erick Erickson <erickerick...@gmail.com> wrote: > > https://docs.gradle.org/current/userguide/publishing_maven.html#publishing_maven > > I know absolutely _nothing_ about it, just that it exists…. > > > > > On Jun 15, 2020, at 4:07 PM, Mike Drob <md...@apache.org> wrote: > > > > David - Does the Gradle build offer something easier to maintain than a > very old Ant Maven plugin? > > > > On Mon, Jun 15, 2020 at 8:43 AM Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > > Hi David, > > It may be unrelated, but I was similarly puzzled when all hardcoded > Maven URLs had https://, but it was still resolving against http:// and > failing. Here's how I tackled it: > > https://issues.apache.org/jira/browse/LUCENE-9170 > > Regards, > > Ishan > > > > On Mon, Jun 15, 2020 at 11:59 AM David Smiley <david.w.smi...@gmail.com> > wrote: > > No; it's another option for people who would rather use Maven instead of > Ant. Where I work I've found it useful because it allows you to fork Solr > and push the artifacts (plus source & docs) to a company Maven repo. It > wasn't apparent to me how to do that in the Ant build. Also, it's > substantially easier to understand than the Ant build IMO. > > > > I looked at the failures and it's because of Maven central being HTTPS > only now yet the build is trying HTTP. I am locally playing with this to > fix it... common-build.xml line 718 is using an old Ant Maven plugin thing > that probably has a built-in hardcoded notion of where Maven central is. I > added the repo explicitly with HTTPS and I got the build to progress but > now am stuck trying to resolve a "protobuf-bom" dependency wherein it's > still using the old HTTP URL for some inexplicable reason. This dependency > is of scope "import" which I've never seen before. Shrug. I'll look at > this more later. > > > > ~ David > > > > > > On Sun, Jun 14, 2020 at 10:58 PM Michael Sokolov <msoko...@gmail.com> > wrote: > > I'm not sure what the purpose of these builds is? Is it to push > artifacts to Maven central? > > > > On Sun, Jun 14, 2020, 10:09 PM Mike Drob <md...@apache.org> wrote: > > Devs, > > > > I was looking at the maven builds and they have been failing for a long > time. For example > https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-Maven-master/ > > > > The question is, are these worth fixing, with the eventual move to > Gradle? If not, can we disable the jobs? > > > > Mike > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
