[
https://issues.apache.org/jira/browse/SOLR-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-1449:
---------------------------
Attachment: SOLR-1449.patch
checkpoint patch, new additions...
1. updated TestConfig to also assert that the existing automatic lib dir
support works (i don't see any evidence that we already had a test for this)
2. replaced the TODO's in the example solrconfig.xml with documentation
explaining hte new <lib> directives.
3. updated the README in the example solr home so that the note about ./lib
also mentions the <lib> config option
4. updated the build.xml and example/solrconfig.xml for the clusturing contrib
so that they don't copy just for the example
5. fixed a small bug in the clustering example schema (that example reuses the
main example docs, but wasn't ignoring unexpected fields which have since been
added to those docs on the trunk since the clustering example was added)
> solrconfig.xml syntax to add classpath elements from outside of instanceDir
> ---------------------------------------------------------------------------
>
> Key: SOLR-1449
> URL: https://issues.apache.org/jira/browse/SOLR-1449
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
> Fix For: 1.4
>
> Attachments: SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch,
> SOLR-1449.patch
>
>
> the idea has been discussed numerous times that it would be nice if there was
> a way to configure a core to load plugins from specific jars (or "classes"
> style directories) by path w/o needing to copy them to the "./lib" dir in
> the instanceDir.
> The current workaround is "symlinks" but that doesn't really help the
> situation of the Solr Release artifacts, where we wind up making numerous
> copies of jars to support multiple example directories (you can't have
> reliable symlinks in zip files)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
