Congrats Houston!
On Fri, Nov 15, 2019 at 7:57 PM Mike Drob wrote:
> Welcome, Houston!
>
> On Fri, Nov 15, 2019 at 6:00 PM Shalin Shekhar Mangar <
> shalinman...@gmail.com> wrote:
>
>> Congratulations and welcome Houston!
>>
>> On Thu, Nov 14, 2019 at 12:39 PM Houston Putman
>> wrote:
>>
>>>
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
Just FYI - you pushed updated versions in versions.props. This has to
be followed by
gradlew --write-locks
so that the lock file is properly updated, otherwise they'll be out of sync.
Dawid
-
To unsubscribe, e-mail:
> 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
+1
Uwe
Am November 16, 2019 4:09:57 PM UTC schrieb Dawid Weiss :
>I don't think the details of how gradle locates (or stores) a
>particular
>dependency matter much. As long as the dependency is resolvable (and
>the
>signature matches the one initially added to the repository) we're
>fine.
>
>For
I don't think the details of how gradle locates (or stores) a particular
dependency matter much. As long as the dependency is resolvable (and the
signature matches the one initially added to the repository) we're fine.
For most things (running tests, sha checks, etc.) the dependency JARs don't
Thanks both. So the gradle build will create a large number of jar files for
our modules and, when working late on Friday a fella can find them scattered
about and think “the dependency jar files must be in there too”. When they’re
not ;). Just looked again and… there are indeed no jar files
All, particularly Uwe and Steve:
Let’s claim I can get the _ant_ version of the build system to work
consistently under the gradle_8 branch. How difficult would it be to set up a
Jenkins job to run _ant_ tests on the gradle_8 branch of master? It’s _NOT_
ready yet, that’s for sure.
I’ve got
good catch on what happens when my jar is not located in specified lib folder?
public repositories:
==
all jars and model declarators should be discoverable in one of these public
repositories
maven https://central.maven.org/
anthttps://repo1.maven.org/maven2/ant/
gradle
11 matches
Mail list logo
