I would start by looking at this:
https://docs.gradle.org/current/userguide/application_plugin.html?
On Sat, Nov 16, 2019 at 5:02 PM Erick Erickson wrote:
>
> Hmmm, I’ll have to start looking at this then. There may be two separate
> issues here:
>
> 1> for developers, a convenient way to just
Hmmm, I’ll have to start looking at this then. There may be two separate issues
here:
1> for developers, a convenient way to just compile-and-go, i.e. starting a
Solr instance after a build. I certainly won’t attempt to insist that I can do
it the same way we did in the Ant world if there’s a
> I’ve really got to disagree here when it comes to Solr. I dive into and out
> of building/running Solr many times a day. Having to package it all up then
> explode it just to check something and/or explore a problem is a waste.
It's not really like this. With gradle you can set up a packaging
bq. For most things (running tests, sha checks, etc.) the dependency JARs don't
have to be copied to the project (and why should they be).
Sure.
bq. The only exception is packaging final distribution.
I’ve really got to disagree here when it comes to Solr. I dive into and out of
ll apparently resolves to newest
>> (latest modification date) e.g.
>> com.erickson
>> -erick
>> -1.0 modification date 11/16/2019
>>-1.1 modification date 11/01/2019
>> sans version gradle will auto-select the latest mod-date (version
>of
>> 1.
erickson
> -erick
>-1.0 modification date 11/16/2019
>-1.1 modification date 11/01/2019
> sans version gradle will auto-select the latest mod-date (version of
> 1.0 version)
>
> as this is clear as mud i invite correction
>
> does this help?
> M-
>
> -
odification date 11/01/2019
> sans version gradle will auto-select the latest mod-date (version of 1.0
> version)
>
> as this is clear as mud i invite correction
>
> does this help?
> M-
>
> From: Erick Erickson
> Sent: Friday, November 15, 2019 9:44 PM
> To: de
ection
does this help?
M-
From: Erick Erickson
Sent: Friday, November 15, 2019 9:44 PM
To: dev@lucene.apache.org
Subject: Anyone interested in the Gradle build, please comment on SOLR-13915
In a nutshell, it doesn’t look like there’s any task that populates:
../solr
I can handle this, Erick (on the branch). In short, "assemble" is a
task added by the "base" gradle plugin. This is just a placeholder for
things that should be "assembled" in the project. The java plugin puts
together a jar file from compiled classes, for example.
Gradle projects typically don't
In a nutshell, it doesn’t look like there’s any task that populates:
../solr/server/solr-webapp/webapp/WEB-INF/lib/
../solr/server/lib/ext/
../solr/server/lib/
with jar files. So "solr/bin/solr start” simply can’t start since it defines
CLASSPATH to point to them. Before I try to mimic the Ant
10 matches
Mail list logo
