[
https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13223334#comment-13223334
]
Torsten Curdt commented on SOLR-3204:
-------------------------------------
You guys don't like maven - we get that (who really does?) ...but that's not
the point. For now let's just assume your bugfix jars did not get released to
maven central. (That's another issue to deal with)
What about Solr users that now have some unreleases Xerces, Jetty und Commons
classes in their classpath? Maybe even without knowing? If you don't hate your
users - don't do it.
Maintaining upstreaming patches is painful - but that's how it is. Push for a
release, maintain a patch or (only worst case) fork.
But there is an option somewhere in the middle is using using tools like
minijar/the shade plugin/jarjar. They let you do the rewriting of the package
transparently on the byte code level. That makes getting back to the releases
version easier. Or you do it like Tomcat - they so some search and replace in
their build.
I your specific case I would keep the bugfix jars in your lib dir (just like
you have now) but modify your build to include a relocated(!) version of your
bugfix jars into the Solr jar (by using jarjar). Problem solved!
No one needs those bugfix version in a repo and it's super easy to fall back to
the official release once out.
There are ways around big code duplications and still avoid the namespace
problem.
Come on guys - be good to the world :)
> 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
