[
https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13223389#comment-13223389
]
Uwe Schindler commented on SOLR-3204:
-------------------------------------
Robert: Its not only a maven problem, its the DLL ähm JAR-hell :-) So I agree
with all others that having patched JARs is a no-go for production, because
nobody is able to then satisfy all dependencies.
On the other hand, Solr is a end-user product, so I have no idea why it is in
maven at all. You download the distribution and install it. If you need to
compile plugins against it, setup your eclipse classpath. Lucene is different,
but it has no patched JARs (it does not depend on any external JAR at all). The
Xerces JAR in benchmark is also only a "utility" package, that should not be in
maven.
To come back to the example:
- Jetty should not be a problem, because Solr will upgrade to Jetty 8 (breaking
lots of backwards). For the Jetty 6 series there is no support at all, so there
will not be a new release. Our fixed Jetty 6 is just a plain jetty with one
broken unicode method patched. If somebody accidently have it in his classpath,
he will be happy that Chinese, Japanese, and Mormon UTF8 works correct...
- For the other JARs that have no other relations except to Solr, JARJARing
them is no issue at all. It would be what I would recommend. This affects
commons JARs like commons-csv, also noggit,
- The ICU example is just a minor "example", we will not need to patch ICU,
because they are releasing quite often.
- If you have reflection dependecies or dependencies from other JARs in you
classpath, you can still install the original unpatched version and you are
happy. They will not conflict.
> solr-commons-csv must not use the org.apache.commons.csv package
> ----------------------------------------------------------------
>
> Key: SOLR-3204
> URL: https://issues.apache.org/jira/browse/SOLR-3204
> Project: Solr
> Issue Type: Bug
> Components: Build
> Affects Versions: 3.5
> Reporter: Emmanuel Bourg
> Priority: Blocker
> Fix For: 3.6
>
> Attachments: solr-csv.patch
>
>
> The solr-commons-csv artifact reused the code from the Apache Commons CSV
> project but the package wasn't changed to something else than
> org.apache.commons.csv in the process. This creates a compatibility issue as
> the Apache Commons team works toward an official release of Commons CSV. It
> prevents Commons CSV from using its own org.apache.commons.csv package, or
> forces the renaming of all the classes to avoid a classpath conflict.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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
