Re: package-tgz-src / package-src-tgz equivilent missing from gradle build on master?

[Chris Hostetter]

: At this major juncture in the project (switching build systems), it's worth
: re-considering what we need to produce on a release.  A -src.tar.gz seems
: anachronistic to me given both (a) GitHub source control providing a
: convenient download .tar.gz for any release "tag" --
: https://github.com/apache/lucene-solr/releases, and (b) maven central
: having -source.jar for convenience in IDE tooling.  So why bother?

Because we're required to by ASF policy...

http://www.apache.org/legal/release-policy.html#artifacts

"Every ASF release MUST contain one or more source packages, which MUST be 
sufficient for a user to build and test the release provided they have 
access to the appropriate platform and tools."

...

"As a convenience to users that might not have the appropriate tools to 
build a compiled version of the source, binary/bytecode packages MAY be 
distributed alongside official Apache releases. In all such cases, the 
binary/bytecode package MUST have the same version number as the source 
release and MUST only add binary/bytecode files that are the result of 
compiling that version of the source code release and its dependencies."


-Hoss
http://www.lucidworks.com/

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Confusion over the term "paramsets" and "Request Parameters API" in Ref Guide

[Alexandre Rafalovitch]

So, we may have a problem with the way we use "configset" too. We
are using it to mean a template from which a new collection can be
created (default, techproducts, etc).

But also, if I remember correctly, we allow to share configuration
between live cores using configset parameter in core.properties. And
that is not a template use, because both cores may modify the same
files through API (oops). Though, now that I look at the
documentation, we seem to have collapsed those two. This collapse may
actually be wrong
https://lucene.apache.org/solr/guide/8_8/defining-core-properties.html

For paramsets, the cool thing is that you can refer to them for update
operations as well. So, they could be used for A/B indexing tests,
etc.

Regards,
   Alex.

On Mon, 8 Feb 2021 at 13:03, Erik Hatcher  wrote:
>
>
>
> > On Feb 6, 2021, at 9:48 AM, Eric Pugh  
> > wrote:
> >
> >  “paramsets”,  which I think is a really powerful feature that most people 
> > don’t know about.
>
> Agreed on that!   (see the old example/files for my early paramset usage as I 
> explored that cool capability)
>
> > I’m thinking that we rename request-parameters-api.adoc —> paramsets.adoc, 
> > and rewrite the page to highlight that this feature is called “paramset”, 
> > in the same way we use the term “configset”.
>
> +1
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: package-tgz-src / package-src-tgz equivilent missing from gradle build on master?

[David Smiley]

At this major juncture in the project (switching build systems), it's worth
re-considering what we need to produce on a release.  A -src.tar.gz seems
anachronistic to me given both (a) GitHub source control providing a
convenient download .tar.gz for any release "tag" --
https://github.com/apache/lucene-solr/releases, and (b) maven central
having -source.jar for convenience in IDE tooling.  So why bother?

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Wed, Feb 3, 2021 at 2:51 PM Houston Putman 
wrote:

> Thanks for getting the list of steps currently taken.
>
> These are easy to keep in the gradle task:
>
>- excluding jdk javadoc package-list files (for licensing reasons
>evidently)
>- setting chmod bits on scripts
>
>
> building Changes.html from CHANGES.txt
>>
> I'm not sure building Changes.html is a huge necessity for the source
> package. It's already done in the artifacts release, so maybe it's better
> to just leave it there?
> No other documentation sites are provided, so I find it a bit odd that
> this is. I might be missing context though.
>
> including lucene/CHANGES.txt in solr as LUCENE_CHANGES.txt
>>
>  While useful when the projects are connected, we probably won't keep this
> when the projects are split (though I could be wrong on this, it would be
> good to discuss anyways).
> If that happens before 9.0 is cut, then this is likely moot.
>
> So we could always start with a task that does a clean checkout, and the
> two easy steps mentioned above. Should be a good first pass, that we can
> change later if needed.
>
> - Houston
>
> On Wed, Feb 3, 2021 at 11:51 AM Chris Hostetter 
> wrote:
>
>>
>> : It wasn't as much of an oversight as lack of knowledge how to deal
>> : with it. I personally think the source distribution should be
>> : equivalent to a clean git checkout. If this works for you then things
>> : are relatively simple and I can do it.
>>
>> I'm not an authority here, so what works for me doesn't really matter :)
>>
>> While i would generally agree with you, I think there are some aspects of
>> how the current targets work that are worth bearing in mind since
>> deliberate decisions were made to get to this point - deliberate
>> decisions should probably made to "undo" these choices..
>>
>> * excluding jdk javadoc package-list files (for licensing reasons
>> evidently)
>> * building Changes.html from CHANGES.txt
>> * including lucnee/CHANGES.txt in solr as LUCENE_CHANGES.txt
>> * setting chmod bits on scripts
>>
>>
>> : On Wed, Feb 3, 2021 at 1:30 AM Chris Hostetter <
>> hossman_luc...@fucit.org> wrote:
>> : >
>> : >
>> : > thinking about how we (want to) build solr docker containers moving
>> : > forward (SOLR-15102) lead me to realize that on the mster branch,
>> there
>> : > doesn't seem to be any logic to build the "*-src.tgz" files.
>> : >
>> : > On branch_8x "ant package" in both the lucene & solr directories
>> handles
>> : > this by delegation to either package-tgz-src or package-src-tgz (for
>> some
>> : > reason they have diff names in each dir?) ... but there doesn't seem
>> to be
>> : > any equivilent of this logic in the gradle build.
>> : >
>> : > Was this an oversight, or is ther some other plan for where/how we
>> deal
>> : > with "src.tgz" release artifacts in 9.x ?
>> : >
>> : >
>> : > -Hoss
>> : > http://www.lucidworks.com/
>> : >
>> : > -
>> : > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> : > For additional commands, e-mail: dev-h...@lucene.apache.org
>> : >
>> :
>> : -
>> : To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> : For additional commands, e-mail: dev-h...@lucene.apache.org
>> :
>> :
>>
>> -Hoss
>> http://www.lucidworks.com/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Re: Confusion over the term "paramsets" and "Request Parameters API" in Ref Guide

[Erik Hatcher]

> On Feb 6, 2021, at 9:48 AM, Eric Pugh  wrote:
> 
>  “paramsets”,  which I think is a really powerful feature that most people 
> don’t know about.

Agreed on that!   (see the old example/files for my early paramset usage as I 
explored that cool capability)

> I’m thinking that we rename request-parameters-api.adoc —> paramsets.adoc, 
> and rewrite the page to highlight that this feature is called “paramset”, in 
> the same way we use the term “configset”.

+1




-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Confusion over the term "paramsets" and "Request Parameters API" in Ref Guide

[David Smiley]

Eric, based on what you wrote, your proposal makes sense to me.
CC'ing Noble who added this feature originally, I think.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Sat, Feb 6, 2021 at 9:56 AM Eric Pugh 
wrote:

> I was reading through the ref guide page on Implicit Request Handlers [1]
> and saw a mention of “paramsets”,  which I think is a really powerful
> feature that most people don’t know about.
>
> I then wanted to learn more about paramsets, and tried to find it in the
> ref guide..   I’d learned about this feature in the first place FROM the
> ref guide, so I knew it was there somewhere…
>
> After gripping through source, I found the page Request Parameters API
> [2].
>
> I’m looking for some guidance on if we would want to rewrite the Request
> Parameters API page as the “ParamSets” page, and retire the term Request
> Parameters API.
>
> “Paramsets” shows up 47 times in *.adoc files.
>
> “Request Parameters API” shows up ONLY as part of a link to the page.
>
> I’m thinking that we rename request-parameters-api.adoc —> paramsets.adoc,
> and rewrite the page to highlight that this feature is called “paramset”,
> in the same way we use the term “configset”.
>
> Thoughts/
>
> Eric
>
> ___
> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
> | http://www.opensourceconnections.com | My Free/Busy
> 
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> 
> This e-mail and all contents, including attachments, is considered to be
> Company Confidential unless explicitly stated otherwise, regardless
> of whether attachments are marked as such.
>
>

Re: PR without jira ticket

[David Smiley]

Hello Joel,

I filed that PR (as you know), and not a JIRA because it was an internal
refactoring for code readability/maintenance that no user should
notice, and highly unlikely (I think) some other plugin-writer would notice
either.  I would have filed a JIRA for it at the time if Jason (my
code-reviewer) or really anyone stated it deserved one.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Sun, Feb 7, 2021 at 10:20 AM Joel Bernstein  wrote:

> This PR https://github.com/apache/lucene-solr/pull/1600 doesn't have a
> jira attached to it. This ticket was not a small change. While the PR does
> have lots of information about the decisions made we still need Jira
> tickets and commits to point to jira tickets. Was there a jira ticket
> created for this PR?
>
>
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>

Re: Behaviour change of Query.parse(String query) in 8.7.0 vs 2.9.4

[jitesh129]

Thanks Adrien.



--
Sent from: 
https://lucene.472066.n3.nabble.com/Lucene-Java-Developer-f564358.html

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org