You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by David Smiley <da...@gmail.com> on 2019/12/23 21:49:46 UTC
Propose eliminate "Versions of Major Components"
Our CHANGES.txt has "Versions of Major Components" as follows:
Versions of Major Components
---------------------
Apache Tika 1.23
Carrot2 3.16.0
Velocity 2.0 and Velocity Tools 3.0
Apache ZooKeeper 3.5.5
Jetty 9.4.24.v20191120
I think we should just eliminate this. Some of this stuff is really in our
contribs, and some of those will be ejected soon. But even for the others,
this sort of thing is pretty easy to figure out (e.g. version.properties or
simply *look* at the jar names).
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
Re: Propose eliminate "Versions of Major Components"
Posted by Dawid Weiss <da...@gmail.com>.
> Then realized jar files are a mess, just ask Dawid.
It is a mess. I don't quite understand many of these dependencies.
We can generate a file with all (or a subset) of versions from actual
dependency list during build time (gradle). This isn't a problem -- in
fact, it's already being done for solr manual.
D.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Propose eliminate "Versions of Major Components"
Posted by Erick Erickson <er...@gmail.com>.
Does it make sense to mention where to look for the jars Solr uses? Or maybe just where the “major components” live?
The problem is that even leaving out things like contribs and test, it’s still confusing:
dist
dist/solrj-libs
server/solr-webapp/webapp/WEB-INF/lib
server/lib
> On Dec 24, 2019, at 12:44 PM, David Smiley <da...@gmail.com> wrote:
>
> Somewhat bigger scope:
> SOLR-14149 - Remove non-changes from CHANGES.txt
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Tue, Dec 24, 2019 at 12:33 PM David Smiley <da...@gmail.com> wrote:
> The "new features + upgrade notes in a single place" page in the ref guide seems to me an odd place to put the current versions of major components. Seems out of scope. https://lucene.apache.org/solr/guide/8_4/solr-upgrade-notes.html
>
> > "I love “Solr System Requirements”"
>
> LOL
>
> This page, "solr-system-requirements.adoc" seems to me the right place to specify ZooKeeper's current version. No need to mention Jetty; users don't install that.
>
> I'll file a JIRA issue.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Tue, Dec 24, 2019 at 12:19 PM Cassandra Targett <ca...@gmail.com> wrote:
> +1 to removing from CHANGES.txt, but I think we should really try to publish them somewhere instead of asking people to look for .jars.
>
> If we were to go the way I’ve been advocating to go - to have a single page in the Ref Guide for each release that includes the new features + upgrade notes in a single place instead of two - it would be really trivial to publish the versions for the major components on the same page. Most of them already exist as Guide build parameters already, a single place would make it less likely they're broken for 2 releases (thanks Jan for fixing that), and it is very little effort to add new ones as needed.
>
> Cassandra
> On Dec 24, 2019, 8:37 AM -0600, Erick Erickson <er...@gmail.com>, wrote:
>> I started out strongly negative on this, since the idea of just looking at the jar file names presupposed you know _where_ to look in the first place.
>>
>> Then realized jar files are a mess, just ask Dawid. There are 272 jar files in the 8.3 distro, scattered all over the place. This may get better when we move to Gradle, but even then there will still be a lot of jar files.
>>
>> For instance, there are three copies of slf4j-api-1.7.24.jar in the distro, which one is important? At least they all have the same version so that’s something.
>>
>> ./dist/solrj-lib/slf4j-api-1.7.24.jar
>> ./server/lib/ext/slf4j-api-1.7.24.jar
>> ./contrib/prometheus-exporter/lib/slf4j-api-1.7.24.jar
>>
>> Zookeeper is in ./dist/solrj-lib/ and ./server/solr-webapp/webapp/WEB-INF/lib/. Which one is important? Which one is used? Which one should I use if I want to run an external Zookeeper? Gaaaaahhhhh.
>>
>> So the more I thought about it, the more I realized it’s just impossible to untangle that in the CHANGES.txt file, and the point of specifying which Tika version is well taken (why that and not others?). The only component that I think _shouldn’t_ be something a user needs to dig for is Zookeeper since we recommend that they install an external ensemble. And just putting Zookeeper in CHANGES.txt is awkward.
>>
>> For that matter, why to we specify the JVM in a different place in CHANGES.txt? That should be moved to a system-requirements page too IMO. I’d frankly rather go find the one place the relevant information is than reconcile multiple, possibly conflicting sources.
>>
>> So after dithering for far too long, +1 to rip this out of CHANGES.txt. We should take the JVM out of CHANGES.txt too. Let’s put this in a system requirements page in the ref guide and point to it from CHANGES.txt. I think we should just point here: https://lucene.apache.org/solr/guide/ which lets them pick the version of the ref guide rather than to a specific version on the theory that it’s one less thing to keep synchronized. Perhaps guiding them to look at “System requirements>>Solr System Requirements”. (and, BTW, I love “Solr System Requirements”, when I was working on the page I wanted to start with “start a few billion yeas ago with a lot of interstellar dust and gas and...”).
>>
>>> On Dec 24, 2019, at 6:56 AM, Jan Høydahl <ja...@cominvent.com> wrote:
>>>
>>> Jetty version is printed early in the logs so should be easy to find if you don’t want to check the sources.
>>>
>>> Looking in RefGuide for ZK version, there seems to be a bug, see https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper
>>> The variable ${org.apache.zookeeper.version} is not expanded in the asciidoc… I opened https://issues.apache.org/jira/browse/SOLR-14146
>>>
>>> Jan
>>>
>>>> 24. des. 2019 kl. 06:48 skrev David Smiley <da...@gmail.com>:
>>>>
>>>> +1 to all that Jan; your response was very thoughtful.
>>>>
>>>> Except "Perhaps just keep Jetty version in CHANGES". Why? Since the WAR option went away, we now think of Jetty as a component of Solr instead of something we deploy to, at least in communication to our users. If an advanced user wants to mess with Jetty configuration, I'm sure he/she will figure it out.
>>>>
>>>> ~ David Smiley
>>>> Apache Lucene/Solr Search Developer
>>>> http://www.linkedin.com/in/davidwsmiley
>>>>
>>>>
>>>> On Mon, Dec 23, 2019 at 5:59 PM Jan Høydahl <ja...@cominvent.com> wrote:
>>>> In the binary distro there is no version.properties...
>>>>
>>>> Perhaps just keep Jetty version in CHANGES?
>>>> The Zookeeper version is useful if you want to choose an external ZK to install, but the refGuide should help here.
>>>> Unfortunately we do not link to the Reference Guide from README in Solr binary download so that info is not readily available either.
>>>> I think we should link to online ref-guide both from README and from online docs https://lucene.apache.org/solr/8_2_0/
>>>> Also, recommended ZK version for Cloud should be part of SYSTEM_REQUIREMENTS.txt, i.e. https://lucene.apache.org/solr/8_2_0/SYSTEM_REQUIREMENTS.html ?
>>>>
>>>> Jan
>>>>
>>>>> 23. des. 2019 kl. 22:49 skrev David Smiley <da...@gmail.com>:
>>>>>
>>>>> Our CHANGES.txt has "Versions of Major Components" as follows:
>>>>>
>>>>> Versions of Major Components
>>>>> ---------------------
>>>>> Apache Tika 1.23
>>>>> Carrot2 3.16.0
>>>>> Velocity 2.0 and Velocity Tools 3.0
>>>>> Apache ZooKeeper 3.5.5
>>>>> Jetty 9.4.24.v20191120
>>>>>
>>>>> I think we should just eliminate this. Some of this stuff is really in our contribs, and some of those will be ejected soon. But even for the others, this sort of thing is pretty easy to figure out (e.g. version.properties or simply *look* at the jar names).
>>>>>
>>>>> ~ David Smiley
>>>>> Apache Lucene/Solr Search Developer
>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Propose eliminate "Versions of Major Components"
Posted by David Smiley <da...@gmail.com>.
Somewhat bigger scope:
SOLR-14149 - Remove non-changes from CHANGES.txt
<https://issues.apache.org/jira/browse/SOLR-14149>
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Dec 24, 2019 at 12:33 PM David Smiley <da...@gmail.com>
wrote:
> The "new features + upgrade notes in a single place" page in the ref guide
> seems to me an odd place to put the current versions of major components.
> Seems out of scope.
> https://lucene.apache.org/solr/guide/8_4/solr-upgrade-notes.html
>
> > "I love “Solr System Requirements”"
>
> LOL
>
> This page, "solr-system-requirements.adoc" seems to me the right place to
> specify ZooKeeper's current version. No need to mention Jetty; users don't
> install that.
>
> I'll file a JIRA issue.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Tue, Dec 24, 2019 at 12:19 PM Cassandra Targett <ca...@gmail.com>
> wrote:
>
>> +1 to removing from CHANGES.txt, but I think we should really try to
>> publish them somewhere instead of asking people to look for .jars.
>>
>> If we were to go the way I’ve been advocating to go - to have a single
>> page in the Ref Guide for each release that includes the new features +
>> upgrade notes in a single place instead of two - it would be really trivial
>> to publish the versions for the major components on the same page. Most of
>> them already exist as Guide build parameters already, a single place would
>> make it less likely they're broken for 2 releases (thanks Jan for fixing
>> that), and it is very little effort to add new ones as needed.
>>
>> Cassandra
>> On Dec 24, 2019, 8:37 AM -0600, Erick Erickson <er...@gmail.com>,
>> wrote:
>>
>> I started out strongly negative on this, since the idea of just looking
>> at the jar file names presupposed you know _where_ to look in the first
>> place.
>>
>> Then realized jar files are a mess, just ask Dawid. There are 272 jar
>> files in the 8.3 distro, scattered all over the place. This may get better
>> when we move to Gradle, but even then there will still be a lot of jar
>> files.
>>
>> For instance, there are three copies of slf4j-api-1.7.24.jar in the
>> distro, which one is important? At least they all have the same version so
>> that’s something.
>>
>> ./dist/solrj-lib/slf4j-api-1.7.24.jar
>> ./server/lib/ext/slf4j-api-1.7.24.jar
>> ./contrib/prometheus-exporter/lib/slf4j-api-1.7.24.jar
>>
>> Zookeeper is in ./dist/solrj-lib/ and
>> ./server/solr-webapp/webapp/WEB-INF/lib/. Which one is important? Which one
>> is used? Which one should I use if I want to run an external Zookeeper?
>> Gaaaaahhhhh.
>>
>> So the more I thought about it, the more I realized it’s just impossible
>> to untangle that in the CHANGES.txt file, and the point of specifying which
>> Tika version is well taken (why that and not others?). The only component
>> that I think _shouldn’t_ be something a user needs to dig for is Zookeeper
>> since we recommend that they install an external ensemble. And just putting
>> Zookeeper in CHANGES.txt is awkward.
>>
>> For that matter, why to we specify the JVM in a different place in
>> CHANGES.txt? That should be moved to a system-requirements page too IMO.
>> I’d frankly rather go find the one place the relevant information is than
>> reconcile multiple, possibly conflicting sources.
>>
>> So after dithering for far too long, +1 to rip this out of CHANGES.txt.
>> We should take the JVM out of CHANGES.txt too. Let’s put this in a system
>> requirements page in the ref guide and point to it from CHANGES.txt. I
>> think we should just point here: https://lucene.apache.org/solr/guide/
>> which lets them pick the version of the ref guide rather than to a specific
>> version on the theory that it’s one less thing to keep synchronized.
>> Perhaps guiding them to look at “System requirements>>Solr System
>> Requirements”. (and, BTW, I love “Solr System Requirements”, when I was
>> working on the page I wanted to start with “start a few billion yeas ago
>> with a lot of interstellar dust and gas and...”).
>>
>> On Dec 24, 2019, at 6:56 AM, Jan Høydahl <ja...@cominvent.com> wrote:
>>
>> Jetty version is printed early in the logs so should be easy to find if
>> you don’t want to check the sources.
>>
>> Looking in RefGuide for ZK version, there seems to be a bug, see
>> https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper
>> The variable ${org.apache.zookeeper.version} is not expanded in the
>> asciidoc… I opened https://issues.apache.org/jira/browse/SOLR-14146
>>
>> Jan
>>
>> 24. des. 2019 kl. 06:48 skrev David Smiley <da...@gmail.com>:
>>
>> +1 to all that Jan; your response was very thoughtful.
>>
>> Except "Perhaps just keep Jetty version in CHANGES". Why? Since the WAR
>> option went away, we now think of Jetty as a component of Solr instead of
>> something we deploy to, at least in communication to our users. If an
>> advanced user wants to mess with Jetty configuration, I'm sure he/she will
>> figure it out.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Mon, Dec 23, 2019 at 5:59 PM Jan Høydahl <ja...@cominvent.com>
>> wrote:
>> In the binary distro there is no version.properties...
>>
>> Perhaps just keep Jetty version in CHANGES?
>> The Zookeeper version is useful if you want to choose an external ZK to
>> install, but the refGuide should help here.
>> Unfortunately we do not link to the Reference Guide from README in Solr
>> binary download so that info is not readily available either.
>> I think we should link to online ref-guide both from README and from
>> online docs https://lucene.apache.org/solr/8_2_0/
>> Also, recommended ZK version for Cloud should be part of
>> SYSTEM_REQUIREMENTS.txt, i.e.
>> https://lucene.apache.org/solr/8_2_0/SYSTEM_REQUIREMENTS.html ?
>>
>> Jan
>>
>> 23. des. 2019 kl. 22:49 skrev David Smiley <da...@gmail.com>:
>>
>> Our CHANGES.txt has "Versions of Major Components" as follows:
>>
>> Versions of Major Components
>> ---------------------
>> Apache Tika 1.23
>> Carrot2 3.16.0
>> Velocity 2.0 and Velocity Tools 3.0
>> Apache ZooKeeper 3.5.5
>> Jetty 9.4.24.v20191120
>>
>> I think we should just eliminate this. Some of this stuff is really in
>> our contribs, and some of those will be ejected soon. But even for the
>> others, this sort of thing is pretty easy to figure out (e.g.
>> version.properties or simply *look* at the jar names).
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
Re: Propose eliminate "Versions of Major Components"
Posted by David Smiley <da...@gmail.com>.
The "new features + upgrade notes in a single place" page in the ref guide
seems to me an odd place to put the current versions of major components.
Seems out of scope.
https://lucene.apache.org/solr/guide/8_4/solr-upgrade-notes.html
> "I love “Solr System Requirements”"
LOL
This page, "solr-system-requirements.adoc" seems to me the right place to
specify ZooKeeper's current version. No need to mention Jetty; users don't
install that.
I'll file a JIRA issue.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Dec 24, 2019 at 12:19 PM Cassandra Targett <ca...@gmail.com>
wrote:
> +1 to removing from CHANGES.txt, but I think we should really try to
> publish them somewhere instead of asking people to look for .jars.
>
> If we were to go the way I’ve been advocating to go - to have a single
> page in the Ref Guide for each release that includes the new features +
> upgrade notes in a single place instead of two - it would be really trivial
> to publish the versions for the major components on the same page. Most of
> them already exist as Guide build parameters already, a single place would
> make it less likely they're broken for 2 releases (thanks Jan for fixing
> that), and it is very little effort to add new ones as needed.
>
> Cassandra
> On Dec 24, 2019, 8:37 AM -0600, Erick Erickson <er...@gmail.com>,
> wrote:
>
> I started out strongly negative on this, since the idea of just looking at
> the jar file names presupposed you know _where_ to look in the first place.
>
> Then realized jar files are a mess, just ask Dawid. There are 272 jar
> files in the 8.3 distro, scattered all over the place. This may get better
> when we move to Gradle, but even then there will still be a lot of jar
> files.
>
> For instance, there are three copies of slf4j-api-1.7.24.jar in the
> distro, which one is important? At least they all have the same version so
> that’s something.
>
> ./dist/solrj-lib/slf4j-api-1.7.24.jar
> ./server/lib/ext/slf4j-api-1.7.24.jar
> ./contrib/prometheus-exporter/lib/slf4j-api-1.7.24.jar
>
> Zookeeper is in ./dist/solrj-lib/ and
> ./server/solr-webapp/webapp/WEB-INF/lib/. Which one is important? Which one
> is used? Which one should I use if I want to run an external Zookeeper?
> Gaaaaahhhhh.
>
> So the more I thought about it, the more I realized it’s just impossible
> to untangle that in the CHANGES.txt file, and the point of specifying which
> Tika version is well taken (why that and not others?). The only component
> that I think _shouldn’t_ be something a user needs to dig for is Zookeeper
> since we recommend that they install an external ensemble. And just putting
> Zookeeper in CHANGES.txt is awkward.
>
> For that matter, why to we specify the JVM in a different place in
> CHANGES.txt? That should be moved to a system-requirements page too IMO.
> I’d frankly rather go find the one place the relevant information is than
> reconcile multiple, possibly conflicting sources.
>
> So after dithering for far too long, +1 to rip this out of CHANGES.txt. We
> should take the JVM out of CHANGES.txt too. Let’s put this in a system
> requirements page in the ref guide and point to it from CHANGES.txt. I
> think we should just point here: https://lucene.apache.org/solr/guide/
> which lets them pick the version of the ref guide rather than to a specific
> version on the theory that it’s one less thing to keep synchronized.
> Perhaps guiding them to look at “System requirements>>Solr System
> Requirements”. (and, BTW, I love “Solr System Requirements”, when I was
> working on the page I wanted to start with “start a few billion yeas ago
> with a lot of interstellar dust and gas and...”).
>
> On Dec 24, 2019, at 6:56 AM, Jan Høydahl <ja...@cominvent.com> wrote:
>
> Jetty version is printed early in the logs so should be easy to find if
> you don’t want to check the sources.
>
> Looking in RefGuide for ZK version, there seems to be a bug, see
> https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper
> The variable ${org.apache.zookeeper.version} is not expanded in the
> asciidoc… I opened https://issues.apache.org/jira/browse/SOLR-14146
>
> Jan
>
> 24. des. 2019 kl. 06:48 skrev David Smiley <da...@gmail.com>:
>
> +1 to all that Jan; your response was very thoughtful.
>
> Except "Perhaps just keep Jetty version in CHANGES". Why? Since the WAR
> option went away, we now think of Jetty as a component of Solr instead of
> something we deploy to, at least in communication to our users. If an
> advanced user wants to mess with Jetty configuration, I'm sure he/she will
> figure it out.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Mon, Dec 23, 2019 at 5:59 PM Jan Høydahl <ja...@cominvent.com> wrote:
> In the binary distro there is no version.properties...
>
> Perhaps just keep Jetty version in CHANGES?
> The Zookeeper version is useful if you want to choose an external ZK to
> install, but the refGuide should help here.
> Unfortunately we do not link to the Reference Guide from README in Solr
> binary download so that info is not readily available either.
> I think we should link to online ref-guide both from README and from
> online docs https://lucene.apache.org/solr/8_2_0/
> Also, recommended ZK version for Cloud should be part of
> SYSTEM_REQUIREMENTS.txt, i.e.
> https://lucene.apache.org/solr/8_2_0/SYSTEM_REQUIREMENTS.html ?
>
> Jan
>
> 23. des. 2019 kl. 22:49 skrev David Smiley <da...@gmail.com>:
>
> Our CHANGES.txt has "Versions of Major Components" as follows:
>
> Versions of Major Components
> ---------------------
> Apache Tika 1.23
> Carrot2 3.16.0
> Velocity 2.0 and Velocity Tools 3.0
> Apache ZooKeeper 3.5.5
> Jetty 9.4.24.v20191120
>
> I think we should just eliminate this. Some of this stuff is really in our
> contribs, and some of those will be ejected soon. But even for the others,
> this sort of thing is pretty easy to figure out (e.g. version.properties or
> simply *look* at the jar names).
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Propose eliminate "Versions of Major Components"
Posted by Cassandra Targett <ca...@gmail.com>.
+1 to removing from CHANGES.txt, but I think we should really try to publish them somewhere instead of asking people to look for .jars.
If we were to go the way I’ve been advocating to go - to have a single page in the Ref Guide for each release that includes the new features + upgrade notes in a single place instead of two - it would be really trivial to publish the versions for the major components on the same page. Most of them already exist as Guide build parameters already, a single place would make it less likely they're broken for 2 releases (thanks Jan for fixing that), and it is very little effort to add new ones as needed.
Cassandra
On Dec 24, 2019, 8:37 AM -0600, Erick Erickson <er...@gmail.com>, wrote:
> I started out strongly negative on this, since the idea of just looking at the jar file names presupposed you know _where_ to look in the first place.
>
> Then realized jar files are a mess, just ask Dawid. There are 272 jar files in the 8.3 distro, scattered all over the place. This may get better when we move to Gradle, but even then there will still be a lot of jar files.
>
> For instance, there are three copies of slf4j-api-1.7.24.jar in the distro, which one is important? At least they all have the same version so that’s something.
>
> ./dist/solrj-lib/slf4j-api-1.7.24.jar
> ./server/lib/ext/slf4j-api-1.7.24.jar
> ./contrib/prometheus-exporter/lib/slf4j-api-1.7.24.jar
>
> Zookeeper is in ./dist/solrj-lib/ and ./server/solr-webapp/webapp/WEB-INF/lib/. Which one is important? Which one is used? Which one should I use if I want to run an external Zookeeper? Gaaaaahhhhh.
>
> So the more I thought about it, the more I realized it’s just impossible to untangle that in the CHANGES.txt file, and the point of specifying which Tika version is well taken (why that and not others?). The only component that I think _shouldn’t_ be something a user needs to dig for is Zookeeper since we recommend that they install an external ensemble. And just putting Zookeeper in CHANGES.txt is awkward.
>
> For that matter, why to we specify the JVM in a different place in CHANGES.txt? That should be moved to a system-requirements page too IMO. I’d frankly rather go find the one place the relevant information is than reconcile multiple, possibly conflicting sources.
>
> So after dithering for far too long, +1 to rip this out of CHANGES.txt. We should take the JVM out of CHANGES.txt too. Let’s put this in a system requirements page in the ref guide and point to it from CHANGES.txt. I think we should just point here: https://lucene.apache.org/solr/guide/ which lets them pick the version of the ref guide rather than to a specific version on the theory that it’s one less thing to keep synchronized. Perhaps guiding them to look at “System requirements>>Solr System Requirements”. (and, BTW, I love “Solr System Requirements”, when I was working on the page I wanted to start with “start a few billion yeas ago with a lot of interstellar dust and gas and...”).
>
> > On Dec 24, 2019, at 6:56 AM, Jan Høydahl <ja...@cominvent.com> wrote:
> >
> > Jetty version is printed early in the logs so should be easy to find if you don’t want to check the sources.
> >
> > Looking in RefGuide for ZK version, there seems to be a bug, see https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper
> > The variable ${org.apache.zookeeper.version} is not expanded in the asciidoc… I opened https://issues.apache.org/jira/browse/SOLR-14146
> >
> > Jan
> >
> > > 24. des. 2019 kl. 06:48 skrev David Smiley <da...@gmail.com>:
> > >
> > > +1 to all that Jan; your response was very thoughtful.
> > >
> > > Except "Perhaps just keep Jetty version in CHANGES". Why? Since the WAR option went away, we now think of Jetty as a component of Solr instead of something we deploy to, at least in communication to our users. If an advanced user wants to mess with Jetty configuration, I'm sure he/she will figure it out.
> > >
> > > ~ David Smiley
> > > Apache Lucene/Solr Search Developer
> > > http://www.linkedin.com/in/davidwsmiley
> > >
> > >
> > > On Mon, Dec 23, 2019 at 5:59 PM Jan Høydahl <ja...@cominvent.com> wrote:
> > > In the binary distro there is no version.properties...
> > >
> > > Perhaps just keep Jetty version in CHANGES?
> > > The Zookeeper version is useful if you want to choose an external ZK to install, but the refGuide should help here.
> > > Unfortunately we do not link to the Reference Guide from README in Solr binary download so that info is not readily available either.
> > > I think we should link to online ref-guide both from README and from online docs https://lucene.apache.org/solr/8_2_0/
> > > Also, recommended ZK version for Cloud should be part of SYSTEM_REQUIREMENTS.txt, i.e. https://lucene.apache.org/solr/8_2_0/SYSTEM_REQUIREMENTS.html ?
> > >
> > > Jan
> > >
> > > > 23. des. 2019 kl. 22:49 skrev David Smiley <da...@gmail.com>:
> > > >
> > > > Our CHANGES.txt has "Versions of Major Components" as follows:
> > > >
> > > > Versions of Major Components
> > > > ---------------------
> > > > Apache Tika 1.23
> > > > Carrot2 3.16.0
> > > > Velocity 2.0 and Velocity Tools 3.0
> > > > Apache ZooKeeper 3.5.5
> > > > Jetty 9.4.24.v20191120
> > > >
> > > > I think we should just eliminate this. Some of this stuff is really in our contribs, and some of those will be ejected soon. But even for the others, this sort of thing is pretty easy to figure out (e.g. version.properties or simply *look* at the jar names).
> > > >
> > > > ~ David Smiley
> > > > Apache Lucene/Solr Search Developer
> > > > http://www.linkedin.com/in/davidwsmiley
> > >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
Re: Propose eliminate "Versions of Major Components"
Posted by Erick Erickson <er...@gmail.com>.
I started out strongly negative on this, since the idea of just looking at the jar file names presupposed you know _where_ to look in the first place.
Then realized jar files are a mess, just ask Dawid. There are 272 jar files in the 8.3 distro, scattered all over the place. This may get better when we move to Gradle, but even then there will still be a lot of jar files.
For instance, there are three copies of slf4j-api-1.7.24.jar in the distro, which one is important? At least they all have the same version so that’s something.
./dist/solrj-lib/slf4j-api-1.7.24.jar
./server/lib/ext/slf4j-api-1.7.24.jar
./contrib/prometheus-exporter/lib/slf4j-api-1.7.24.jar
Zookeeper is in ./dist/solrj-lib/ and ./server/solr-webapp/webapp/WEB-INF/lib/. Which one is important? Which one is used? Which one should I use if I want to run an external Zookeeper? Gaaaaahhhhh.
So the more I thought about it, the more I realized it’s just impossible to untangle that in the CHANGES.txt file, and the point of specifying which Tika version is well taken (why that and not others?). The only component that I think _shouldn’t_ be something a user needs to dig for is Zookeeper since we recommend that they install an external ensemble. And just putting Zookeeper in CHANGES.txt is awkward.
For that matter, why to we specify the JVM in a different place in CHANGES.txt? That should be moved to a system-requirements page too IMO. I’d frankly rather go find the one place the relevant information is than reconcile multiple, possibly conflicting sources.
So after dithering for far too long, +1 to rip this out of CHANGES.txt. We should take the JVM out of CHANGES.txt too. Let’s put this in a system requirements page in the ref guide and point to it from CHANGES.txt. I think we should just point here: https://lucene.apache.org/solr/guide/ which lets them pick the version of the ref guide rather than to a specific version on the theory that it’s one less thing to keep synchronized. Perhaps guiding them to look at “System requirements>>Solr System Requirements”. (and, BTW, I love “Solr System Requirements”, when I was working on the page I wanted to start with “start a few billion yeas ago with a lot of interstellar dust and gas and...”).
> On Dec 24, 2019, at 6:56 AM, Jan Høydahl <ja...@cominvent.com> wrote:
>
> Jetty version is printed early in the logs so should be easy to find if you don’t want to check the sources.
>
> Looking in RefGuide for ZK version, there seems to be a bug, see https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper
> The variable ${org.apache.zookeeper.version} is not expanded in the asciidoc… I opened https://issues.apache.org/jira/browse/SOLR-14146
>
> Jan
>
>> 24. des. 2019 kl. 06:48 skrev David Smiley <da...@gmail.com>:
>>
>> +1 to all that Jan; your response was very thoughtful.
>>
>> Except "Perhaps just keep Jetty version in CHANGES". Why? Since the WAR option went away, we now think of Jetty as a component of Solr instead of something we deploy to, at least in communication to our users. If an advanced user wants to mess with Jetty configuration, I'm sure he/she will figure it out.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Mon, Dec 23, 2019 at 5:59 PM Jan Høydahl <ja...@cominvent.com> wrote:
>> In the binary distro there is no version.properties...
>>
>> Perhaps just keep Jetty version in CHANGES?
>> The Zookeeper version is useful if you want to choose an external ZK to install, but the refGuide should help here.
>> Unfortunately we do not link to the Reference Guide from README in Solr binary download so that info is not readily available either.
>> I think we should link to online ref-guide both from README and from online docs https://lucene.apache.org/solr/8_2_0/
>> Also, recommended ZK version for Cloud should be part of SYSTEM_REQUIREMENTS.txt, i.e. https://lucene.apache.org/solr/8_2_0/SYSTEM_REQUIREMENTS.html ?
>>
>> Jan
>>
>>> 23. des. 2019 kl. 22:49 skrev David Smiley <da...@gmail.com>:
>>>
>>> Our CHANGES.txt has "Versions of Major Components" as follows:
>>>
>>> Versions of Major Components
>>> ---------------------
>>> Apache Tika 1.23
>>> Carrot2 3.16.0
>>> Velocity 2.0 and Velocity Tools 3.0
>>> Apache ZooKeeper 3.5.5
>>> Jetty 9.4.24.v20191120
>>>
>>> I think we should just eliminate this. Some of this stuff is really in our contribs, and some of those will be ejected soon. But even for the others, this sort of thing is pretty easy to figure out (e.g. version.properties or simply *look* at the jar names).
>>>
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Propose eliminate "Versions of Major Components"
Posted by Jan Høydahl <ja...@cominvent.com>.
Jetty version is printed early in the logs so should be easy to find if you don’t want to check the sources.
Looking in RefGuide for ZK version, there seems to be a bug, see https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper <https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper>
The variable ${org.apache.zookeeper.version} is not expanded in the asciidoc… I opened https://issues.apache.org/jira/browse/SOLR-14146 <https://issues.apache.org/jira/browse/SOLR-14146>
Jan
> 24. des. 2019 kl. 06:48 skrev David Smiley <da...@gmail.com>:
>
> +1 to all that Jan; your response was very thoughtful.
>
> Except "Perhaps just keep Jetty version in CHANGES". Why? Since the WAR option went away, we now think of Jetty as a component of Solr instead of something we deploy to, at least in communication to our users. If an advanced user wants to mess with Jetty configuration, I'm sure he/she will figure it out.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
>
> On Mon, Dec 23, 2019 at 5:59 PM Jan Høydahl <jan.asf@cominvent.com <ma...@cominvent.com>> wrote:
> In the binary distro there is no version.properties...
>
> Perhaps just keep Jetty version in CHANGES?
> The Zookeeper version is useful if you want to choose an external ZK to install, but the refGuide should help here.
> Unfortunately we do not link to the Reference Guide from README in Solr binary download so that info is not readily available either.
> I think we should link to online ref-guide both from README and from online docs https://lucene.apache.org/solr/8_2_0/ <https://lucene.apache.org/solr/8_2_0/>
> Also, recommended ZK version for Cloud should be part of SYSTEM_REQUIREMENTS.txt, i.e. https://lucene.apache.org/solr/8_2_0/SYSTEM_REQUIREMENTS.html <https://lucene.apache.org/solr/8_2_0/SYSTEM_REQUIREMENTS.html> ?
>
> Jan
>
>> 23. des. 2019 kl. 22:49 skrev David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>>:
>>
>> Our CHANGES.txt has "Versions of Major Components" as follows:
>>
>> Versions of Major Components
>> ---------------------
>> Apache Tika 1.23
>> Carrot2 3.16.0
>> Velocity 2.0 and Velocity Tools 3.0
>> Apache ZooKeeper 3.5.5
>> Jetty 9.4.24.v20191120
>>
>> I think we should just eliminate this. Some of this stuff is really in our contribs, and some of those will be ejected soon. But even for the others, this sort of thing is pretty easy to figure out (e.g. version.properties or simply *look* at the jar names).
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
Re: Propose eliminate "Versions of Major Components"
Posted by David Smiley <da...@gmail.com>.
+1 to all that Jan; your response was very thoughtful.
Except "Perhaps just keep Jetty version in CHANGES". Why? Since the WAR
option went away, we now think of Jetty as a component of Solr instead of
something we deploy to, at least in communication to our users. If an
advanced user wants to mess with Jetty configuration, I'm sure he/she will
figure it out.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Mon, Dec 23, 2019 at 5:59 PM Jan Høydahl <ja...@cominvent.com> wrote:
> In the binary distro there is no version.properties...
>
> Perhaps just keep Jetty version in CHANGES?
> The Zookeeper version is useful if you want to choose an external ZK to
> install, but the refGuide should help here.
> Unfortunately we do not link to the Reference Guide from README in Solr
> binary download so that info is not readily available either.
> I think we should link to online ref-guide both from README and from
> online docs https://lucene.apache.org/solr/8_2_0/
> Also, recommended ZK version for Cloud should be part of
> SYSTEM_REQUIREMENTS.txt, i.e.
> https://lucene.apache.org/solr/8_2_0/SYSTEM_REQUIREMENTS.html ?
>
> Jan
>
> 23. des. 2019 kl. 22:49 skrev David Smiley <da...@gmail.com>:
>
> Our CHANGES.txt has "Versions of Major Components" as follows:
>
> Versions of Major Components
> ---------------------
> Apache Tika 1.23
> Carrot2 3.16.0
> Velocity 2.0 and Velocity Tools 3.0
> Apache ZooKeeper 3.5.5
> Jetty 9.4.24.v20191120
>
>
> I think we should just eliminate this. Some of this stuff is really in
> our contribs, and some of those will be ejected soon. But even for the
> others, this sort of thing is pretty easy to figure out (e.g.
> version.properties or simply *look* at the jar names).
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
>
Re: Propose eliminate "Versions of Major Components"
Posted by Jan Høydahl <ja...@cominvent.com>.
In the binary distro there is no version.properties...
Perhaps just keep Jetty version in CHANGES?
The Zookeeper version is useful if you want to choose an external ZK to install, but the refGuide should help here.
Unfortunately we do not link to the Reference Guide from README in Solr binary download so that info is not readily available either.
I think we should link to online ref-guide both from README and from online docs https://lucene.apache.org/solr/8_2_0/ <https://lucene.apache.org/solr/8_2_0/>
Also, recommended ZK version for Cloud should be part of SYSTEM_REQUIREMENTS.txt, i.e. https://lucene.apache.org/solr/8_2_0/SYSTEM_REQUIREMENTS.html <https://lucene.apache.org/solr/8_2_0/SYSTEM_REQUIREMENTS.html> ?
Jan
> 23. des. 2019 kl. 22:49 skrev David Smiley <da...@gmail.com>:
>
> Our CHANGES.txt has "Versions of Major Components" as follows:
>
> Versions of Major Components
> ---------------------
> Apache Tika 1.23
> Carrot2 3.16.0
> Velocity 2.0 and Velocity Tools 3.0
> Apache ZooKeeper 3.5.5
> Jetty 9.4.24.v20191120
>
> I think we should just eliminate this. Some of this stuff is really in our contribs, and some of those will be ejected soon. But even for the others, this sort of thing is pretty easy to figure out (e.g. version.properties or simply *look* at the jar names).
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>