FOSDEM 2016 - take action by 4th of December 2015
As most of you probably know FOSDEM 2016 (the biggest, 100% free open source developer conference) is right around the corner: https://fosdem.org/2016/ We hope to have an ASF booth and we would love to see as many ASF projects as possible present at various tracks (AKA Developer rooms): https://fosdem.org/2016/schedule/#devrooms This year, for the first time, we are running a dedicated Big Data and HPC Developer Room and given how much of that open source development is done at ASF it would be great to have folks submit talks to: https://hpc-bigdata-fosdem16.github.io While the CFPs for different Developer Rooms follow slightly different schedules, but if you submit by the end of this week you should be fine. Finally if you don't want to fish for CFP submission URL, here it is: https://fosdem.org/submit If you have any questions -- please email me *directly* and hope to see as many of you as possible in two months! Thanks, Roman. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5392) extend solrj apis to cover collection management
[ https://issues.apache.org/jira/browse/SOLR-5392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Shaposhnik updated SOLR-5392: --- Attachment: 0001-SOLR-5392.-extend-solrj-apis-to-cover-collection-man.patch Please consider the following patch against trunk. What I did here is -- I completely aped CoreAdminRequest and CoreAdminResponse keeping up with all the stylistic idiosyncrasies of the two. Hope this was the right thing to do. Either way, please let me know what do you guys think. extend solrj apis to cover collection management Key: SOLR-5392 URL: https://issues.apache.org/jira/browse/SOLR-5392 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 4.5 Reporter: Roman Shaposhnik Attachments: 0001-SOLR-5392.-extend-solrj-apis-to-cover-collection-man.patch It would be useful to extend solrj APIs to cover collection management calls: https://cwiki.apache.org/confluence/display/solr/Collections+API -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5390) extend solrj apis to cover collection admin functions
Roman Shaposhnik created SOLR-5390: -- Summary: extend solrj apis to cover collection admin functions Key: SOLR-5390 URL: https://issues.apache.org/jira/browse/SOLR-5390 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 4.5 Reporter: Roman Shaposhnik It would be very useful to extend solrj apis to also cover the the collection management API calls: https://cwiki.apache.org/confluence/display/solr/Collections+API -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5389) extend solrj apis to cover collection admin functions
Roman Shaposhnik created SOLR-5389: -- Summary: extend solrj apis to cover collection admin functions Key: SOLR-5389 URL: https://issues.apache.org/jira/browse/SOLR-5389 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 4.5 Reporter: Roman Shaposhnik It would be very useful to extend solrj apis to also cover the the collection management API calls: https://cwiki.apache.org/confluence/display/solr/Collections+API -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5391) extend solrj apis to cover collection management
Roman Shaposhnik created SOLR-5391: -- Summary: extend solrj apis to cover collection management Key: SOLR-5391 URL: https://issues.apache.org/jira/browse/SOLR-5391 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 4.5 Reporter: Roman Shaposhnik It would be useful to extend solrj APIs to cover collection management calls: https://cwiki.apache.org/confluence/display/solr/Collections+API -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5392) extend solrj apis to cover collection management
Roman Shaposhnik created SOLR-5392: -- Summary: extend solrj apis to cover collection management Key: SOLR-5392 URL: https://issues.apache.org/jira/browse/SOLR-5392 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 4.5 Reporter: Roman Shaposhnik It would be useful to extend solrj APIs to cover collection management calls: https://cwiki.apache.org/confluence/display/solr/Collections+API -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5392) extend solrj apis to cover collection management
[ https://issues.apache.org/jira/browse/SOLR-5392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13804943#comment-13804943 ] Roman Shaposhnik commented on SOLR-5392: apologies for duplicate JIRAs -- I have no clue what has happened with JIRA :-( extend solrj apis to cover collection management Key: SOLR-5392 URL: https://issues.apache.org/jira/browse/SOLR-5392 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 4.5 Reporter: Roman Shaposhnik It would be useful to extend solrj APIs to cover collection management calls: https://cwiki.apache.org/confluence/display/solr/Collections+API -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4796) zkcli.sh should honor JAVA_HOME
Roman Shaposhnik created SOLR-4796:
--
Summary: zkcli.sh should honor JAVA_HOME
Key: SOLR-4796
URL: https://issues.apache.org/jira/browse/SOLR-4796
Project: Solr
Issue Type: Bug
Components: scripts and tools
Affects Versions: 4.2
Reporter: Roman Shaposhnik
Fix For: 4.3
On a system with GNU java installed the fact that zkcli.sh doesn't honor
JAVA_HOME could lead to hard to diagnose failure:
{noformat}
Exception in thread main java.lang.NoClassDefFoundError:
org.apache.solr.cloud.ZkCLI
at gnu.java.lang.MainThread.run(libgcj.so.7rh)
Caused by: java.lang.ClassNotFoundException: org.apache.solr.cloud.ZkCLI not
found in gnu.gcj.runtime.SystemClassLoader{urls=[],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(libgcj.so.7rh)
at java.lang.ClassLoader.loadClass(libgcj.so.7rh)
at java.lang.ClassLoader.loadClass(libgcj.so.7rh)
at gnu.java.lang.MainThread.run(libgcj.so.7rh)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4796) zkcli.sh should honor JAVA_HOME
[
https://issues.apache.org/jira/browse/SOLR-4796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Shaposhnik updated SOLR-4796:
---
Attachment: SOLR-4796.patch.txt
Tiny, trivial patch attached.
zkcli.sh should honor JAVA_HOME
---
Key: SOLR-4796
URL: https://issues.apache.org/jira/browse/SOLR-4796
Project: Solr
Issue Type: Bug
Components: scripts and tools
Affects Versions: 4.2
Reporter: Roman Shaposhnik
Fix For: 4.3
Attachments: SOLR-4796.patch.txt
On a system with GNU java installed the fact that zkcli.sh doesn't honor
JAVA_HOME could lead to hard to diagnose failure:
{noformat}
Exception in thread main java.lang.NoClassDefFoundError:
org.apache.solr.cloud.ZkCLI
at gnu.java.lang.MainThread.run(libgcj.so.7rh)
Caused by: java.lang.ClassNotFoundException: org.apache.solr.cloud.ZkCLI not
found in gnu.gcj.runtime.SystemClassLoader{urls=[],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(libgcj.so.7rh)
at java.lang.ClassLoader.loadClass(libgcj.so.7rh)
at java.lang.ClassLoader.loadClass(libgcj.so.7rh)
at gnu.java.lang.MainThread.run(libgcj.so.7rh)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4498) it would be useful for ZkCLI to expose printLayoutToStdOut to aid debugging
Roman Shaposhnik created SOLR-4498: -- Summary: it would be useful for ZkCLI to expose printLayoutToStdOut to aid debugging Key: SOLR-4498 URL: https://issues.apache.org/jira/browse/SOLR-4498 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.1 Reporter: Roman Shaposhnik Priority: Minor It would be nice to have a -cmd list that would simply call zkClient.printLayoutToStdOut() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4498) it would be useful for ZkCLI to expose printLayoutToStdOut to aid debugging
[ https://issues.apache.org/jira/browse/SOLR-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Shaposhnik updated SOLR-4498: --- Attachment: SOLR-4498.patch.txt Attaching trivial patch. it would be useful for ZkCLI to expose printLayoutToStdOut to aid debugging --- Key: SOLR-4498 URL: https://issues.apache.org/jira/browse/SOLR-4498 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.1 Reporter: Roman Shaposhnik Priority: Minor Attachments: SOLR-4498.patch.txt It would be nice to have a -cmd list that would simply call zkClient.printLayoutToStdOut() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4377) making release tarballs identical to the release tags
Roman Shaposhnik created SOLR-4377: -- Summary: making release tarballs identical to the release tags Key: SOLR-4377 URL: https://issues.apache.org/jira/browse/SOLR-4377 Project: Solr Issue Type: Improvement Components: scripts and tools Affects Versions: 4.1, 4.0 Reporter: Roman Shaposhnik Now that we're integrating Solr with Hadoop via the Apache Bigtop project it is a bit of a nuisance to our build system that the release tarballs don't quite match the SVN tags. This is also something that is not quite ASF kosher strictly speaking. Would it be ok with a Solr community to add a comparison check between release tarballs and SVN tags as part of the release process checklist? If you guys have a Wiki outlining how-to-release perhaps it needs to be captured over there or just added to the process. Either way would be fine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4377) making release tarballs identical to the release tags
[
https://issues.apache.org/jira/browse/SOLR-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13565713#comment-13565713
]
Roman Shaposhnik commented on SOLR-4377:
Here's an example from the 4.1.0 release (diff is attached):
{noformat}
$ cd /tmp
$ tar xzvf solr-4.1.0-src.tgz
$ svn co http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_4_1_0
$ find . -name .svn -type d -exec rm -rf {} \;
$ diff -ruN solr-4.1.0 lucene_solr_4_1_0 | grep '^diff' | wc
71 284 12019
$ diff -ruN solr-4.1.0 lucene_solr_4_1_0 diff.txt
{noformat}
So as you can see the diff is actually quite large (71 files total). My cursory
glance shows that most of the deltas are trivial enough to be taken care of
during the release process. What's more important (and what I'm asking for) is
to have
a release policy where a diff like I've mentioned would be part of the release
check list.
making release tarballs identical to the release tags
-
Key: SOLR-4377
URL: https://issues.apache.org/jira/browse/SOLR-4377
Project: Solr
Issue Type: Improvement
Components: scripts and tools
Affects Versions: 4.0, 4.1
Reporter: Roman Shaposhnik
Attachments: diff.txt
Now that we're integrating Solr with Hadoop via the Apache Bigtop project it
is a bit of a nuisance to our build system that the release tarballs don't
quite match the SVN tags. This is also something that is not quite ASF kosher
strictly speaking.
Would it be ok with a Solr community to add a comparison check between
release tarballs and SVN tags as part of the release process checklist?
If you guys have a Wiki outlining how-to-release perhaps it needs to be
captured over there or just added to the process. Either way would be fine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4377) making release tarballs identical to the release tags
[ https://issues.apache.org/jira/browse/SOLR-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Shaposhnik updated SOLR-4377: --- Attachment: diff.txt making release tarballs identical to the release tags - Key: SOLR-4377 URL: https://issues.apache.org/jira/browse/SOLR-4377 Project: Solr Issue Type: Improvement Components: scripts and tools Affects Versions: 4.0, 4.1 Reporter: Roman Shaposhnik Attachments: diff.txt Now that we're integrating Solr with Hadoop via the Apache Bigtop project it is a bit of a nuisance to our build system that the release tarballs don't quite match the SVN tags. This is also something that is not quite ASF kosher strictly speaking. Would it be ok with a Solr community to add a comparison check between release tarballs and SVN tags as part of the release process checklist? If you guys have a Wiki outlining how-to-release perhaps it needs to be captured over there or just added to the process. Either way would be fine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4377) making release tarballs identical to the release tags
[ https://issues.apache.org/jira/browse/SOLR-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13565719#comment-13565719 ] Roman Shaposhnik commented on SOLR-4377: bq. I'm not sure that is the case. I think it comes down to the PMC for a particular project and what they decide to release. Well, as an IPMC member I can tell you that this is something we strongly required from the poddling release. Perhaps you're right and somehow the TLPs are exempt from this requirement. I'd be happy to solicit the advice of ASF long timers if for nothing else but to make sure we treat poddling the same way we are going to treat them when they graduate. making release tarballs identical to the release tags - Key: SOLR-4377 URL: https://issues.apache.org/jira/browse/SOLR-4377 Project: Solr Issue Type: Improvement Components: scripts and tools Affects Versions: 4.0, 4.1 Reporter: Roman Shaposhnik Attachments: diff.txt Now that we're integrating Solr with Hadoop via the Apache Bigtop project it is a bit of a nuisance to our build system that the release tarballs don't quite match the SVN tags. This is also something that is not quite ASF kosher strictly speaking. Would it be ok with a Solr community to add a comparison check between release tarballs and SVN tags as part of the release process checklist? If you guys have a Wiki outlining how-to-release perhaps it needs to be captured over there or just added to the process. Either way would be fine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4057) SolrCloud will not run on the root context.
[ https://issues.apache.org/jira/browse/SOLR-4057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494313#comment-13494313 ] Roman Shaposhnik commented on SOLR-4057: it appears that specifying hostContext=. works as expected or am I missing something? SolrCloud will not run on the root context. --- Key: SOLR-4057 URL: https://issues.apache.org/jira/browse/SOLR-4057 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.1, 5.0 If you try and pass an empty hostContext to solrcloud when trying to run on the root context, the empty value simply triggers using the default value of 8983. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3879) war file has javax.servlet-api jar bundled
Roman Shaposhnik created SOLR-3879:
--
Summary: war file has javax.servlet-api jar bundled
Key: SOLR-3879
URL: https://issues.apache.org/jira/browse/SOLR-3879
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Roman Shaposhnik
Fix For: 4.0
This is incorrect and can lead to deployment issues:
{noformat}
Servlet Spec 2.5
SRV.9.7.2 Web Application Class Loader
The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. As
described in the J2EE license agreement, servlet containers that are
not part of a J2EE product should not allow the application to
override J2SE platform classes, such as those in the java.* and
javax.* namespaces, that J2SE does not allow to be modified. Also,
servlet containers that are part of a J2EE product should not allow
the application to override J2SE or J2EE platform classes, such as
those in java.* and javax.* namespaces, that either J2SE or J2EE do
not allow to be modified. The container should not allow applications
to override or access the container’s implementation
{noformat}
The fix is pretty easy and it would be nice to include it in the upcoming
release of Solr 4.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3879) war file has javax.servlet-api jar bundled
[
https://issues.apache.org/jira/browse/SOLR-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Shaposhnik updated SOLR-3879:
---
Attachment: SOLR-3879.patch.txt
Attached is the patch against trunk. When applied to the RC tarball it takes
care of the issue. Robert, can you please elaborate on how smokeTestRelease.py
relates to build/release? I'm pretty new to SOLR -- still learning.
war file has javax.servlet-api jar bundled
--
Key: SOLR-3879
URL: https://issues.apache.org/jira/browse/SOLR-3879
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Roman Shaposhnik
Priority: Critical
Fix For: 4.0
Attachments: SOLR-3879.patch.txt
This is incorrect and can lead to deployment issues:
{noformat}
Servlet Spec 2.5
SRV.9.7.2 Web Application Class Loader
The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. As
described in the J2EE license agreement, servlet containers that are
not part of a J2EE product should not allow the application to
override J2SE platform classes, such as those in the java.* and
javax.* namespaces, that J2SE does not allow to be modified. Also,
servlet containers that are part of a J2EE product should not allow
the application to override J2SE or J2EE platform classes, such as
those in java.* and javax.* namespaces, that either J2SE or J2EE do
not allow to be modified. The container should not allow applications
to override or access the container’s implementation
{noformat}
The fix is pretty easy and it would be nice to include it in the upcoming
release of Solr 4.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3879) war file has javax.servlet-api jar bundled
[
https://issues.apache.org/jira/browse/SOLR-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462149#comment-13462149
]
Roman Shaposhnik commented on SOLR-3879:
Thanks! I'll update the patch shortly to include a test for this.
war file has javax.servlet-api jar bundled
--
Key: SOLR-3879
URL: https://issues.apache.org/jira/browse/SOLR-3879
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Roman Shaposhnik
Priority: Critical
Fix For: 4.0
Attachments: SOLR-3879.patch.txt
This is incorrect and can lead to deployment issues:
{noformat}
Servlet Spec 2.5
SRV.9.7.2 Web Application Class Loader
The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. As
described in the J2EE license agreement, servlet containers that are
not part of a J2EE product should not allow the application to
override J2SE platform classes, such as those in the java.* and
javax.* namespaces, that J2SE does not allow to be modified. Also,
servlet containers that are part of a J2EE product should not allow
the application to override J2SE or J2EE platform classes, such as
those in java.* and javax.* namespaces, that either J2SE or J2EE do
not allow to be modified. The container should not allow applications
to override or access the container’s implementation
{noformat}
The fix is pretty easy and it would be nice to include it in the upcoming
release of Solr 4.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
