Re: Solr Ref Guide, Highlighting

[Timothy Rodriguez (BLOOMBERG/ 120 PARK)]

Looks good!  The only thing is the comments are now dated relative to the 
documentation and may be a bit confusing.  Maybe it makes sense to delete them? 
 Not sure if the current strategy is to keep them forever for posterity.  A 
user could theoretically pull up previous versions and have the comments make 
sense.

From: david.w.smi...@gmail.com At: 01/18/17 00:23:50
To: Timothy Rodriguez (BLOOMBERG/ 120 PARK), dev@lucene.apache.org
Subject: Re: Solr Ref Guide, Highlighting

I think I'm done.  I integrated information from the 3 sub-pages into the 
Highlighting master page.  At this point I'd like to delete those 3 pages and 
remove the info box about a renovation being in-progress.

On Mon, Jan 9, 2017 at 6:03 PM David Smiley <david.w.smi...@gmail.com> wrote:

Solr 6.4 is the first release to introduce the UnifiedHighlighter as a new 
highlighter option.  I want to get it documented reasonably well in the Solr 
Ref Guide.  The Highlighters section is here: Highlighting   (lets see if this 
formatted email expands to the URL when it lands on the list)

Unless anyone objects, I'd like to rename the "Standard Highlighter" as 
"Original Highlighter" in the ref guide.  The original Highlighter has no 
actual name qualifications as it was indeed Lucene's original Highlighter.  
"Standard Highlighter" as a name purely exists as-such within the Solr 
Reference Guide only.  In our code it's used by "DefaultSolrHighlighter" which 
is really a combo of the original Highlighter and FastVectorHighlighter.   DSH 
ought to be refactored perhaps... but I digress.  

For those that haven't read CHANGES.txt yet, there is a new "hl.method" 
parameter which can be used to pick your highlighter.  Here I purposely chose a 
possible value of "original" to choose the original Highlighter (not 
"standard").

I haven't started documenting yet but I plan to refactor the highlighter docs a 
bit.  The intro page will better discuss the highlighter options and also how 
to configure both term vectors and offsets in postings.  Then the highlighter 
implementation specific pages will document the parameters and any 
configuration specific to them.  I'm a bit skeptical we need a page dedicated 
to the PostingsHighlighter as the UnifiedHighlighter is a derivative of it, 
supporting all it's options and more.  In that sense, maybe people are fine 
with it only being in the ref guide as a paragraph or two on the UH page 
describing how to activate it.  I suppose it's effectively deprecated.

~ David
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com

Re: Solr Ref Guide, Highlighting

[Timothy Rodriguez (BLOOMBERG/ 120 PARK)]

I've made some edits and additions in word with tracked changes to the Solr Ref 
guide.  I couldn't think of a better way to send out the changes.  Let me know 
if you'd like me to send in some other fashion.

-Tim


From: dev@lucene.apache.org At: 01/11/17 15:53:39
To: dev@lucene.apache.org
Cc: Timothy Rodriguez (BLOOMBERG/ 120 PARK)
Subject: Re: Solr Ref Guide, Highlighting

Yes, I can help - I meant to try today, but tomorrow looks much
clearer schedule-wise to focus on Ref Guide.

On Wed, Jan 11, 2017 at 12:32 AM, David Smiley <david.w.smi...@gmail.com> wrote:
> I made some progress... I'm having flashbacks to book-writing; ugh. If you
> wish to help Cassandra, I think a great spot would be the "Basic Usage"
> section I inserted.  I'll save that for last if nobody gets to it.  I need
> to do the end of the page, and then add a UH page and deal with the other
> highlighter pages.
>
> On Tue, Jan 10, 2017 at 12:20 PM David Smiley <david.w.smi...@gmail.com>
> wrote:
>>
>> Thanks for your input Cassandra.
>> Within the code, DefaultSolrHighlighter.java can be renamed; it's not set
>> in stone unlike code in SolrJ where there needs to be much more care.  Not
>> sure what it would be named though... any way it's another issue perhaps for
>> 7.0.
>> I'll work on the ref guide tonight.
>> ~ David
>>
>> On Tue, Jan 10, 2017 at 11:57 AM Cassandra Targett <casstarg...@gmail.com>
>> wrote:
>>>
>>> (note: I replied to this thread earlier not noticing that dev@l.a.o
>>> was removed from the message I replied to...reposting the relevant
>>> part here for posterity or whatever...)
>>>
>>> [Regarding] reworking the Highlighting section, I'm +1 on the changes you
>>> propose, David. It's a bit of a mess, and not very consistent in the
>>> ways configuration options are described for each of the
>>> implementations.
>>>
>>> I generally prefer to name things along the lines they are named in
>>> the code, but in this case there's already a disconnect between
>>> "Standard Highlighter" and the DefaultSolrHighlighter. I wonder,
>>> though, if it would be a good idea to rename the
>>> DefaultSolrHighlighter? Perhaps it's too early to make such a change,
>>> but it's worth a moment's thought if you haven't already.
>>>
>>> Thanks for taking this on - I was briefly looking at UH yesterday and
>>> considering how to integrate it with the current docs. I didn't get
>>> very far, and found it a bit daunting, so I appreciate your assistance
>>> for sure. Please let me know if you need any help or review from me.
>>>
>>> On Mon, Jan 9, 2017 at 11:17 PM, David Smiley <david.w.smi...@gmail.com>
>>> wrote:
>>> > Unfortunately, The Solr Ref Guide is only editable by committers.  In
>>> > the
>>> > near future it's going to move to a different platform that will allow
>>> > you
>>> > to contribute via pull-request; that will be very nice.  In the mean
>>> > time,
>>> > your feedback is highly appreciated.
>>> >
>>> > ~ David
>>> >
>>> > On Mon, Jan 9, 2017 at 6:21 PM Timothy Rodriguez (BLOOMBERG/ 120 PARK)
>>> > <trodrigue...@bloomberg.net> wrote:
>>> >>
>>> >> +1, I'll be happy to offer assistance with edits or some of the
>>> >> sections
>>> >> if needed. We're glad to see this out there.
>>> >>
>>> >> From: dev@lucene.apache.org At: 01/09/17 18:03:32
>>> >> To: Timothy Rodriguez (BLOOMBERG/ 120 PARK), dev@lucene.apache.org
>>> >> Subject: Re:Solr Ref Guide, Highlighting
>>> >>
>>> >> Solr 6.4 is the first release to introduce the UnifiedHighlighter as a
>>> >> new
>>> >> highlighter option.  I want to get it documented reasonably well in
>>> >> the Solr
>>> >> Ref Guide.  The Highlighters section is here: Highlighting   (lets see
>>> >> if
>>> >> this formatted email expands to the URL when it lands on the list)
>>> >>
>>> >> Unless anyone objects, I'd like to rename the "Standard Highlighter"
>>> >> as
>>> >> "Original Highlighter" in the ref guide.  The original Highlighter has
>>> >> no
>>> >> actual name qualifications as it was indeed Lucene's original
>>> >> Highlighter.
>>> >> "Standard Highlighter" as a name purely exists as-such within t

Re: UnifiedHighlighter and extraction of exact hit offset ranges

[Timothy Rodriguez (BLOOMBERG/ 120 PARK)]

It's arguably per request, imo.  Even per field you may want different possible 
formats depending on the request (and field).  That would potentially require a 
different parameter to specify the formatter to use for a given request (and a 
way to config multiple formatters, with perhaps a default).  

From: david.w.smi...@gmail.com At: 01/11/17 13:19:37
To: Timothy Rodriguez (BLOOMBERG/ 120 PARK), dawid.we...@gmail.com
Cc: dev@lucene.apache.org
Subject: Re: UnifiedHighlighter and extraction of exact hit offset ranges

If the generics could be contained _instead of_ spreading to the UH class 
itself (making UH typed), I think it could be nice.  But given the per-field 
possible settings for formatting... that in particular makes balancing these 
concerns hard.  I guess in the end Object isn't too bad since it's limited to 
the advanced method use-case (highlightFieldsAsObjects).

On Wed, Jan 11, 2017 at 8:45 AM Timothy Rodriguez (BLOOMBERG/ 120 PARK) 
<trodrigue...@bloomberg.net> wrote:

While we were open sourcing it. I had tried creating a patch to generify it, 
but the generics did wind up all over the place. Ultimately the 
UnifiedHighlighter would need to be generic itself so it can ensure the passage 
formatters etc are of the same type. (Or alternatively, generic passage 
formatters are passed in per request.) I wound up dumping the changes because 
they were quite substantial and they'd also push it further from the 
PostingsHighlighjer. 

I'm hoping to get back to trying that again in he future. It'd be nice to have 
a PassageFormatter. 

-Tim

Sent from Bloomberg Professional for iPhone


- Original Message -
From: Dawid Weiss <dawid.we...@gmail.com>
To: david.w.smi...@gmail.com
CC: TIMOTHY RODRIGUEZ, dev@lucene.apache.org
At: 11-Jan-2017 08:37:37


Thanks David!

That's almost exactly what I ended up doing. I don't mind casting
Object to my own type; you can always make it a covariant override in
your subclass (which you have to do to access those expert-level
methods anyway).

I still kind of think startOffset/endOffset and other related methods
could be made public to allow tinkering with them in
FieldHighlighter#highlightOffsetsEnums (otherwise this method is
protected for overriding, but useless in practice).

There is another API problem I found too. If you wish to override
FieldHighlighter.getSummaryPassagesNoHighlight you can't return
anything sensible because Passage is final, contains only
package-private fields and addMatch is package-private too. So you
can't create a "custom" passage.

I can file an issue and provide a patch if these changes are not
against the design of the unified highlighter?

Dawid

On Wed, Jan 11, 2017 at 2:24 PM, David Smiley <david.w.smi...@gmail.com> wrote:
> Hi Dawid,
>
> You could write a trivial PassageFormatter that simply returns the Passage
> list instead of doing formatting.  Passages contain offsets. And yes,
> WholeBreakIterator if you don't need passage fragmentation. Unless I'm
> missing some aspect of your requirements, this doesn't involve any internal
> highlighter customizing.  Perhaps Javadocs could be improved to make this
> more clear... and perhaps this Passage-returning PassageFormatter could be
> included to clarify how it's done.  I recall doing or seeing this recently
> months ago but I'm not sure.
>
> One ugly aspect of the API (shared with it's PostingsHighlighter lineage)
> related to this discussion is that the PassageFormatter is declared to
> return Object.  It's kinda hard to rectify it to be typed, perhaps with
> generics, while also not spilling lots of generics to other places (the UH
> itself) just because of this.  Perhaps UH.highlightFieldsAsObjects() could
> be modified to take a Class to thus provide a type for the output... and
> maybe the PassageFormatter could declare not only with generics but with a
> method what types of results it produces.  I'm curious what you think.
>
> ~ David
>
>
> On Wed, Jan 11, 2017 at 6:02 AM Dawid Weiss <dawid.we...@gmail.com> wrote:
>>
>> To follow-up: I hacked into the offsets by passing WholeBreakIterator
>> and a custom PassageFormatter that just returns the matches from the
>> singleton resulting passage. This is suboptimal though, as there's
>> still some complex logic going on in highlightOffsetsEnums that could
>> be avoided.
>>
>> Dawid
>>
>> On Wed, Jan 11, 2017 at 11:34 AM, Dawid Weiss <dawid.we...@gmail.com>
>> wrote:
>> > Can any of the folks who contributed to UnifiedHighlighter (David?)
>> > clarify my thinking here?
>> >
>> > I have a requirement to extract (for a set of search results) a list
>> > of exact "hit" ranges (field offsets, with support for multi-term
>> > queries and span queries). Obviously, I'm only talking 

Re: UnifiedHighlighter and extraction of exact hit offset ranges

[Timothy Rodriguez (BLOOMBERG/ 120 PARK)]

While we were open sourcing it. I had tried creating a patch to generify it, 
but the generics did wind up all over the place. Ultimately the 
UnifiedHighlighter would need to be generic itself so it can ensure the passage 
formatters etc are of the same type. (Or alternatively, generic passage 
formatters are passed in per request.) I wound up dumping the changes because 
they were quite substantial and they'd also push it further from the 
PostingsHighlighjer. 

I'm hoping to get back to trying that again in he future. It'd be nice to have 
a PassageFormatter. 

-Tim

Sent from Bloomberg Professional for iPhone

- Original Message -
From: Dawid Weiss 
To: david.w.smi...@gmail.com
CC: TIMOTHY RODRIGUEZ, dev@lucene.apache.org
At: 11-Jan-2017 08:37:37


Thanks David!

That's almost exactly what I ended up doing. I don't mind casting
Object to my own type; you can always make it a covariant override in
your subclass (which you have to do to access those expert-level
methods anyway).

I still kind of think startOffset/endOffset and other related methods
could be made public to allow tinkering with them in
FieldHighlighter#highlightOffsetsEnums (otherwise this method is
protected for overriding, but useless in practice).

There is another API problem I found too. If you wish to override
FieldHighlighter.getSummaryPassagesNoHighlight you can't return
anything sensible because Passage is final, contains only
package-private fields and addMatch is package-private too. So you
can't create a "custom" passage.

I can file an issue and provide a patch if these changes are not
against the design of the unified highlighter?

Dawid

On Wed, Jan 11, 2017 at 2:24 PM, David Smiley  wrote:
> Hi Dawid,
>
> You could write a trivial PassageFormatter that simply returns the Passage
> list instead of doing formatting.  Passages contain offsets. And yes,
> WholeBreakIterator if you don't need passage fragmentation. Unless I'm
> missing some aspect of your requirements, this doesn't involve any internal
> highlighter customizing.  Perhaps Javadocs could be improved to make this
> more clear... and perhaps this Passage-returning PassageFormatter could be
> included to clarify how it's done.  I recall doing or seeing this recently
> months ago but I'm not sure.
>
> One ugly aspect of the API (shared with it's PostingsHighlighter lineage)
> related to this discussion is that the PassageFormatter is declared to
> return Object.  It's kinda hard to rectify it to be typed, perhaps with
> generics, while also not spilling lots of generics to other places (the UH
> itself) just because of this.  Perhaps UH.highlightFieldsAsObjects() could
> be modified to take a Class to thus provide a type for the output... and
> maybe the PassageFormatter could declare not only with generics but with a
> method what types of results it produces.  I'm curious what you think.
>
> ~ David
>
>
> On Wed, Jan 11, 2017 at 6:02 AM Dawid Weiss  wrote:
>>
>> To follow-up: I hacked into the offsets by passing WholeBreakIterator
>> and a custom PassageFormatter that just returns the matches from the
>> singleton resulting passage. This is suboptimal though, as there's
>> still some complex logic going on in highlightOffsetsEnums that could
>> be avoided.
>>
>> Dawid
>>
>> On Wed, Jan 11, 2017 at 11:34 AM, Dawid Weiss 
>> wrote:
>> > Can any of the folks who contributed to UnifiedHighlighter (David?)
>> > clarify my thinking here?
>> >
>> > I have a requirement to extract (for a set of search results) a list
>> > of exact "hit" ranges (field offsets, with support for multi-term
>> > queries and span queries). Obviously, I'm only talking about queries
>> > that relate to field content somehow, but this has always been quite
>> > problematic and required the use of multiple helper classes
>> > (WeightedSpanTermExtractor, MultiTermHighlighting, etc.) and pretty
>> > hairy logic.
>> >
>> > So I turned to look at UnifiedHighlighter for help.
>> >
>> > Seems like the right way (?) to do it would be to override (and abuse)
>> > UnifiedHighlighter's getFieldHighlighter method and return a field
>> > highlighter with an override of:
>> >
>> > protected Passage[] highlightOffsetsEnums(List
>> > offsetsEnums) throws IOException {
>> >
>> > so that I can capture and return a separate Passage for each
>> > OffsetsEnum (I have my own code to deal with overlaps and merging, so
>> > I can skip this entirely). Then, with a custom no-op PassageFormatter
>> > I could simply get a list of those offsets.
>> >
>> > The problem with this approach is that there is currently no way to
>> > access offsets in OffsetsEnum -- everything is protected (so
>> > subclassable), but OffsetsEnum are closed to package-private scope.
>> > Namely these two:
>> >
>> >   int startOffset() throws IOException {
>> > return postingsEnum.startOffset();
>> >   }
>> >
>> >   int endOffset() throws 

Re:Solr Ref Guide, Highlighting

[Timothy Rodriguez (BLOOMBERG/ 120 PARK)]

+1, I'll be happy to offer assistance with edits or some of the sections if 
needed.  We're glad to see this out there.

From: dev@lucene.apache.org At: 01/09/17 18:03:32
To: Timothy Rodriguez (BLOOMBERG/ 120 PARK), dev@lucene.apache.org
Subject: Re:Solr Ref Guide, Highlighting

Solr 6.4 is the first release to introduce the UnifiedHighlighter as a new 
highlighter option.  I want to get it documented reasonably well in the Solr 
Ref Guide.  The Highlighters section is here: Highlighting   (lets see if this 
formatted email expands to the URL when it lands on the list)

Unless anyone objects, I'd like to rename the "Standard Highlighter" as 
"Original Highlighter" in the ref guide.  The original Highlighter has no 
actual name qualifications as it was indeed Lucene's original Highlighter.  
"Standard Highlighter" as a name purely exists as-such within the Solr 
Reference Guide only.  In our code it's used by "DefaultSolrHighlighter" which 
is really a combo of the original Highlighter and FastVectorHighlighter.   DSH 
ought to be refactored perhaps... but I digress.  

For those that haven't read CHANGES.txt yet, there is a new "hl.method" 
parameter which can be used to pick your highlighter.  Here I purposely chose a 
possible value of "original" to choose the original Highlighter (not 
"standard").

I haven't started documenting yet but I plan to refactor the highlighter docs a 
bit.  The intro page will better discuss the highlighter options and also how 
to configure both term vectors and offsets in postings.  Then the highlighter 
implementation specific pages will document the parameters and any 
configuration specific to them.  I'm a bit skeptical we need a page dedicated 
to the PostingsHighlighter as the UnifiedHighlighter is a derivative of it, 
supporting all it's options and more.  In that sense, maybe people are fine 
with it only being in the ref guide as a paragraph or two on the UH page 
describing how to activate it.  I suppose it's effectively deprecated.

~ David
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com

Re: Problems Running ant enwiki

[Timothy Rodriguez (BLOOMBERG/ 120 PARK)]

Great, thanks!

From: david.w.smi...@gmail.com At: 11/08/16 13:18:50
To: Timothy Rodriguez (BLOOMBERG/ 120 PARK), dev@lucene.apache.org, 
gsing...@apache.org
Subject: Re: Problems Running ant enwiki

Created https://issues.apache.org/jira/browse/LUCENE-7546 where further 
discussion can continue.  FYI you can grab the wikipedia dump at this URL now: 
http://home.apache.org/~dsmiley/data/enwiki-20070527-pages-articles.xml.bz2
On Tue, Nov 8, 2016 at 9:53 AM David Smiley <david.w.smi...@gmail.com> wrote:

(CC'ing Grant)

I remember hearing something about people.apache.org getting migrated to 
home.apache.org:
https://mail-archives.apache.org/mod_mbox/openoffice-dev/201511.mbox/%3C007a01d127b0$c5ed36c0$51c7a440$@apache.org%3E
I've found it difficult to find public information on this; it's more indirect 
shares that individuals in specific projects (like OpenOffice here) did.  In 
essence, I learned that a lot of content simply moved to the new server but 
some of the largest files were not copied.  This one did not; I checked.

I have a copy of this file -- 2.69GB.  I'll upload it to my account in 
home.apache.org.  It's not clear there is a better space for it; it's large for 
the intended use of home.apache.org.  I'll also update 
lucene/benchmark/build.xml to reference the new URL.

~ David

On Mon, Nov 7, 2016 at 6:46 PM Timothy Rodriguez (BLOOMBERG/ 120 PARK) 
<trodrigue...@bloomberg.net> wrote:

Anyone else having problems retrieving the test wikipedia set used for 
benchmarks? It looks like the resource is no longer available. When I run ant 
enwiki I receive the following:

[get] Error opening connection 
java.io.FileNotFoundException:http://people.apache.org/~gsingers/wikipedia/enwiki-
20070527-pages-articles.xml.bz2

I've tried the link directly from a browser and it looks like it's moved.  Is 
there a mirror someplace?

-Tim
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com

Problems Running ant enwiki

[Timothy Rodriguez (BLOOMBERG/ 120 PARK)]

Anyone else having problems retrieving the test wikipedia set used for 
benchmarks? It looks like the resource is no longer available. When I run ant 
enwiki I receive the following:

[get] Error opening connection 
java.io.FileNotFoundException:http://people.apache.org/~gsingers/wikipedia/enwiki-
20070527-pages-articles.xml.bz2

I've tried the link directly from a browser and it looks like it's moved.  Is 
there a mirror someplace?

-Tim

Re: Building a Solr cluster with Maven

[Timothy Rodriguez (BLOOMBERG/ 120 PARK)]

That'd be a helpful step.  I think it'd be even better if there was a way to 
generate somewhat customized versions of solr from the artifacts that are 
published already.  Publishing the whole zip would be a start, downstream 
builds could add logic to resolve it, explode, tweak, and re-publish.  The 
maintain the strict separation from the war, it might be helpful to have a lib 
or "plugin-ins" folder in the zip that is by default loaded to the classpath as 
an extension point for users who are re-building the package?

-Tim

From: dev@lucene.apache.org At: 10/18/16 09:52:42
To: dev@lucene.apache.org
Subject: Re: Building a Solr cluster with Maven

My team has modified the ant scripts to publish all the jars/poms and the zip 
to our local artifactory when we run our build. We have another project which 
pulls down all of these dependencies including the zip to build our actual solr 
deploy and a maven assembly which unpacks the zip file and extracts all of the 
webapp for our real distribution. 

I haven't upstreamed the changes for the ant tasks thinking there wouldn't be 
too much interest in that, but I could put together a patch if there is.

The changes do the following:

- Packages the zip along with the parent pom if a flag is set
- Allows changing group which the poms are published to. For example instead of 
org.apache you can push it as com.xxx to avoid shadowing conflicts in your 
local repository.

On Tue, Oct 18, 2016 at 8:42 AM David Smiley  wrote:

Thanks for bringing this up, Greg.  I too have felt the pain of this in the 
move away from a WAR file in a project or two.  In one of the projects that 
comes to mind, we built scripts that re-constituted a Solr distribution from 
artifacts in Maven. For anything that wasn't in Maven (e.g. the admin UI pages, 
Jetty configs), we checked it into source control.  In hind sight... the 
simplicity of what you list as (1) -- check the distro zip into a Maven repo 
local to the organization sounds better... but I may be forgetting requirements 
that led us not to do this.  I look forward to that zip shrinking once the docs 
are gone.  Another option, depending on one's needs, is to pursue Docker, which 
I've lately become a huge fan of.  I think Docker is particularly great for 
integration tests.  Does the scenario you wish to use the assets for relate to 
testing or some other use-case?

~ David


On Mon, Oct 17, 2016 at 7:58 PM Greg Pendlebury  
wrote:

Are there any developers with a current working maven build for a downstream 
Solr installation? ie. Not a build for Solr itself, but a build that brings in 
the core Solr server plus local plugins, third party plugins etc?

I am in the process of updating one of our old builds (it builds both the 
application and various shard instances) and have hit a stumbling block in 
sourcing the dashboard static assets (everything under /webapp/web in Solr's 
source).

Prior to the move away from being a webapp I could get them by exploding the 
war from Maven Central.

In our very first foray into 5.x we had a local custom build to patch 
SOLR-2649. We avoided solving this problem then by pushing the webapp into our 
local Nexus as part of that build... but that wasn't a very good long term 
choice.

So now I'm trying to work out the best long term approach to take here. Ideas 
so far:

  1)Manually download the required zip and add it into our Nexus repository as 
a 3rd party artifact. Maven can source and extract anything it needs from here. 
This is where I'm currently leaning for simplicity, but the manual step 
required is annoying. It does have the advantage of causing a build failure 
straight away when a version upgrade occurs, prompting the developer to look 
into why.

  2)Move a copy of the static assets for the dashboard into our project and 
deploy them ourselves. This has the advantage of aligning our approach with the 
resources we already maintain in the project (like core.properties, schema.xml, 
solrconfig.xml, logging etc.). But I am worried that it is really fragile and 
developers will miss it during a version upgrade, resulting in the dashboard 
creeping out-of-date and (worse) introducing subtle bugs because of a version 
mismatch between the UI and the underlying server code.
  3)I'd like to think a long term approach would be for the core Solr build to 
ship a JAR (or any other assembly) to Maven Central like 'solr-dashboard'... 
but I'm not sure how that aligns with the move away from Solr being considered 
a webapp. It seems a shame that all of the Java code ends up in Maven central, 
but the web layer dead-ends in the ant build.
I might be missing something really obvious and there is already a way to do 
this. Is there some other distribution of the dashboard statics? Other than the 
downloadable zip that is.

Ta,
Greg

-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: 

Re: SolrJ 6.2 now depends on Google-Guava and Jackson WTF?!

[Timothy Rodriguez (BLOOMBERG/ 120 PARK)]

I'm conflicted on how big of an issue that is.  It's a really old version of 
jackson since it depends on the org.codehaus version.  On the other hand, it's 
probably less likely to conflict as such.

Guava, is definitely a much more likely potential source of conflict, though.

From: dev@lucene.apache.org At: 09/30/16 16:41:42
To: Timothy Rodriguez (BLOOMBERG/ 120 PARK), dev@lucene.apache.org
Subject: Re: SolrJ 6.2 now depends on Google-Guava and Jackson WTF?!

I know that the Jackson library was added here: 
https://issues.apache.org/jira/browse/SOLR-9542

Kevin Risden
 
On Fri, Sep 30, 2016 at 3:38 PM, Timothy Rodriguez (BLOOMBERG/ 120 PARK) 
<trodrigue...@bloomberg.net> wrote:

This has potential to cause conflicts for a lot of folks builds.  Especially 
since these are libraries users of the client library may have imported 
themselves.

From: dev@lucene.apache.org At: 09/30/16 16:30:45
To: dev@lucene.apache.org
Subject: Re: SolrJ 6.2 now depends on Google-Guava and Jackson WTF?!

Furthermore, changes to SolrJ dependencies should be noted clearly in 
CHANGES.txt (e.g. new SolrJ dependency XYZ for purpose ___, or updated SolrJ 
dependency XYZ to 1.2.3).  I see no reference to this in CHANGES.txt.

On Fri, Sep 30, 2016 at 4:24 PM David Smiley <david.w.smi...@gmail.com> wrote:

I was updating a project of mine today from SolrJ 6.0.0 to 6.2.1 and ran into a 
classpath incompatibility problem pertaining to Guava.  I execute "mvn 
dependency:tree" to see what's going on and I see a huge WTF -- SolrJ depends 
on Guava!  Since when?!  6.2.0 apparently and in this issue -- 
https://issues.apache.org/jira/browse/SOLR-9200Oh wow it depends on Jackson 
now too!

Sorry, this is not okay and I feel strongly about this.  Very deliberate care 
should be taken to our SolrJ dependencies since they are used in many 
environments, and dependencies there add a burden on anyone using Solr.  
**Adding SolrJ dependencies should be announced**; either in their own issue 
with appropriate title or noted in the dev list (not a JIRA issue) so as to be 
noticed.  Can we agree to do this from now on?

Fortunately, it *appears* that the usage is pretty minimal?  Greg Chanan / 
Steve Rowe, it appears the Guava dependency is just a couple import statements 
for annotations.  Is that it?  I manually excluded guava from my SolrJ 
dependency in the pom.xml along with things like Woodstox which I always 
exclude.  I'm not sure yet about the scope of Jackson; we haven't needed that 
to date as we've got Noggit.

~ David
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com

Re: SolrJ 6.2 now depends on Google-Guava and Jackson WTF?!

[Timothy Rodriguez (BLOOMBERG/ 120 PARK)]

This has potential to cause conflicts for a lot of folks builds.  Especially 
since these are libraries users of the client library may have imported 
themselves.

From: dev@lucene.apache.org At: 09/30/16 16:30:45
To: dev@lucene.apache.org
Subject: Re: SolrJ 6.2 now depends on Google-Guava and Jackson WTF?!

Furthermore, changes to SolrJ dependencies should be noted clearly in 
CHANGES.txt (e.g. new SolrJ dependency XYZ for purpose ___, or updated SolrJ 
dependency XYZ to 1.2.3).  I see no reference to this in CHANGES.txt.

On Fri, Sep 30, 2016 at 4:24 PM David Smiley  wrote:

I was updating a project of mine today from SolrJ 6.0.0 to 6.2.1 and ran into a 
classpath incompatibility problem pertaining to Guava.  I execute "mvn 
dependency:tree" to see what's going on and I see a huge WTF -- SolrJ depends 
on Guava!  Since when?!  6.2.0 apparently and in this issue -- 
https://issues.apache.org/jira/browse/SOLR-9200Oh wow it depends on Jackson 
now too!

Sorry, this is not okay and I feel strongly about this.  Very deliberate care 
should be taken to our SolrJ dependencies since they are used in many 
environments, and dependencies there add a burden on anyone using Solr.  
**Adding SolrJ dependencies should be announced**; either in their own issue 
with appropriate title or noted in the dev list (not a JIRA issue) so as to be 
noticed.  Can we agree to do this from now on?

Fortunately, it *appears* that the usage is pretty minimal?  Greg Chanan / 
Steve Rowe, it appears the Guava dependency is just a couple import statements 
for annotations.  Is that it?  I manually excluded guava from my SolrJ 
dependency in the pom.xml along with things like Woodstox which I always 
exclude.  I'm not sure yet about the scope of Jackson; we haven't needed that 
to date as we've got Noggit.

~ David
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com