lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (Commented) (JIRA)" <>
Subject [jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package
Date Wed, 07 Mar 2012 14:46:58 GMT


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

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

> solr-commons-csv must not use the org.apache.commons.csv package
> ----------------------------------------------------------------
>                 Key: SOLR-3204
>                 URL:
>             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:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message