[
https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224377#comment-13224377
]
Uwe Schindler commented on SOLR-3204:
-------------------------------------
As noted before, we cannot fix this for Jetty 6 by package-renaming using
JarJar, as this would break almost everything in the jetty configuration (Jetty
is JarJar unfriendly), but Jetty can be easily solved on our side by upgrading
to Jetty 8 (also for Solr 3.6!!!!). The patch/branch is ready, just needs
committing. We can then ship with unmodified Jetty 8, as the Unicode bugs
should be fixed.
For the other projects I see no real problem in using jarjar (which is used in
lots of projects): Lets simply investigate what foreign namespaces we use in
our packages (e.g. we should also rename the Snowball classes, because we
heavily forked them and they are still in org.tartarus namespace - as we forked
that project, we should do it in the source code). For e.g. commons-csv we have
no problem jarjaring our fork and re-release it. In the jarjar issue tracker is
also a discussion about “hiding” renamed classes from GUIs by prefixing all
renamed class names with $, so they are invisible for an autocomplete-using
Eclipse developer, so nobody outside can use the jarjared classes outside
Lucene/Solr.
About the remaining issues Robert mentioned: They are all solvable. JarJar
renames also class names inside strings used for reflection, it can also
rewrite Manifests and META-INF (we use e.g. for codecs, or Apache Xerces uses
to plug in the parser impl). I just would like to give it a try, it cannot
happen more than our testcases do not run. The example Robert has given with
external references to icu4j is exactly what we want to prevent with JarJaring,
so it doesn’t apply in my opinion. If we patch and modify icu4j and ship with a
package-renamed version, code that uses reflection outside the Solr/Lucene JAR
is completely unaffected. If the external project side-by-side with Lucene/Solr
wants to use icu4j it can simply include the original in any version, solr with
its patched version is completely unaffected and vice versa.
So I would strongly suggest to jarjar all dependencies that we modified locally
(means all foreign jar-files with solr-prefix). How we do this is a different
issue: We can only rename all classes in that jar-file and republish it (but
then we have to change our import statements in our code – I would prefer
this), or we jarjar the whole Solr distribution after the complete build.
> 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-3204.patch, 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
