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
Thanks, I just put it in gradle tasks for now.
on to the equivalent of “ant server dist”.
> On Nov 15, 2019, at 1:03 PM, Dawid Weiss wrote:
>
> Doesn't make sense to spend much time on such discussions, Erick, not
> at this early stage. If you like it -- leave it in, I have no problem
> with
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
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:
>
>> Thanks everyone!
>>
>> As requested, a brief history of me:
>>
>> A native Austinite,
Congratulations and welcome Houston!
On Thu, Nov 14, 2019 at 12:39 PM Houston Putman
wrote:
> Thanks everyone!
>
> As requested, a brief history of me:
>
> A native Austinite, I went to The University of Texas at Austin. Back in
> 2013 I lucked into an internship with Bloomberg working on a new
Bram:
Andrzej Bailecki and I worked on something similar, it might be good to compare
notes. I gave a talk last Activate that might be useful for you to look at for
ideas.
Basically there are several issues we worked out:
1> how to insure that all segments were rewritten
2> If the schema is
On 15/11/2019 19:14, Jörn Franke wrote:
> Well sometimes even reindexing might not always be avoidable when upgrading.
> However, there should be a more user friendly way. Not every Solr deployment
> that one might inherit has foreseen this. Eg in case Solr is used as a NoSQL
> database where
Well sometimes even reindexing might not always be avoidable when upgrading.
However, there should be a more user friendly way. Not every Solr deployment
that one might inherit has foreseen this. Eg in case Solr is used as a NoSQL
database where the application puts data in Solr, but not
Well sometimes even reindexing might not always be avoidable when upgrading.
However, there should be a more user friendly way. Not every Solr deployment
that one might inherit has foreseen this. Eg in case Solr is used as a NoSQL
database where the application puts data in Solr, but not
Doesn't make sense to spend much time on such discussions, Erick, not
at this early stage. If you like it -- leave it in, I have no problem
with it whatsoever.
Dawid
On Fri, Nov 15, 2019 at 6:02 PM Erick Erickson wrote:
>
> Added SOLR-13935 for this general topic, please comment there if you’d
On 13/11/2019 20:36, Erick Erickson wrote:
> I have zero interest in having an LTS “policy” that requires any further
> commitment of my personal time to random people who ask for it but aren’t
> willing to pay. I consider my non-paid work to Solr a _volunteer_ activity,
> not something anyone
Added SOLR-13935 for this general topic, please comment there if you’d rather.
> On Nov 15, 2019, at 10:36 AM, Dawid Weiss wrote:
>
>> Instead of a help.txt file though, how about some help task? ./gradlew
>> helpAnt?
>
> I don't think that's easier, to be honest. You need to know which task
> But again -- why pollute the build file with stuff
> that could be just a set of plain-text files
All depends on how you define “simplest" ;). One definition is how few
different systems I have to use. Another is how can I get this information in
the least complicated way
I don’t have a lot
Congrats and welcome Houston!
--
Steve
> On Nov 15, 2019, at 1:09 AM, Houston Putman wrote:
>
> Thanks everyone!
>
> As requested, a brief history of me:
>
> A native Austinite, I went to The University of Texas at Austin. Back in 2013
> I lucked into an internship with Bloomberg working on
Congrats and welcome, Houston!
(Austin is a great city, we had the Lucene Solr Revolution there one!)
On Fri, Nov 15, 2019 at 9:59 PM Ignacio Vera wrote:
>
> Welcome Houston!
>
> On Fri, Nov 15, 2019 at 11:07 AM Alan Woodward wrote:
>>
>> Welcome Houston!
>>
>> > On 14 Nov 2019, at 08:57,
Welcome Houston!
On Fri, Nov 15, 2019 at 11:07 AM Alan Woodward wrote:
> Welcome Houston!
>
> > On 14 Nov 2019, at 08:57, Anshum Gupta wrote:
> >
> > Hi all,
> >
> > Please join me in welcoming Houston Putman as the latest Lucene/Solr
> committer!
> >
> > Houston has been involved with the
> Instead of a help.txt file though, how about some help task? ./gradlew
> helpAnt?
I don't think that's easier, to be honest. You need to know which task
to invoke (and how).
A plain file is just right there in your face.
> it works just fine. Does this seem consistent with the structure of
Ohhh, I really like this, especially given the amount of time I’ve spent
looking at all of the possible tasks….
Instead of a help.txt file though, how about some help task? ./gradlew helpAnt?
But I need a sanity check here before pushing this (assuming y’all agree)
before I go changing some
Welcome Houston!
> On 14 Nov 2019, at 08:57, Anshum Gupta wrote:
>
> Hi all,
>
> Please join me in welcoming Houston Putman as the latest Lucene/Solr
> committer!
>
> Houston has been involved with the community since 2013, when he first
> contributed the Analytics contrib module. Since
> Want to raise a JIRA (task?) and put it in the umbrella task? (SOLR-13914)?
> I’m trying to keep all these kinds of TODO’s in a place we won’t forget them.
I won't forget this -- it's too annoying. ;) We can't change the
folder structure now because merges would be too painful (and if we
want
20 matches
Mail list logo
