[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13264020#comment-13264020
]
Steven Rowe commented on SOLR-3405:
-----------------------------------
bq. So I got frustrated with some of the responses/suggestions here that seem
like maybe people aren't taking this stuff as seriously as we should be.
I'm taking this stuff seriously.
* patched dependencies: There is no patched-dependencies solution for Maven at
this point, but putting patched dependencies up as forked projects with
"download jar" links on github makes them exactly like other non-mavenized
dependencies, so if Lucene/Solr goes that route independent of Maven concerns,
then it isn't a separate issue for Maven.
* non-mavenized dependencies: the standard Maven-proponent answer (i.e. "just
put them in Maven") may work some of the time, but it certainly isn't a
panacea, and Lucene/Solr needs to cover all bases. I think ivy-maven-plugin
could address most, and maybe all, of the cases where "just put them in Maven"
doesn't work.
* packaging: I would split this into two concerns:
** Maven binary jar/war artifacts should be identical (bit for bit) to the
official binary artifacts.
** Maven POMs should require the same dependencies that Solr ships with. In
other words, as I stated previously on this issue: POMs for Solr jars/war
published on Maven Central should never require (i.e., have a non-optional
dependency on) a third party artifact if that third party dependency is not
directly included in the binary package; the contents of the war don't count as
"inclusion in the binary package".
This issue is supposed to be about this last point. I don't agree with the
idea myself.
Here's why: Maven POMs should list the dependencies required to use the
associated artifact. I seriously don't understand why it matters if this
differs from the 3rd party libraries shipped (directly, not in the war) with
the convenience binary package.
And, as Ryan has stated on this issue, what's included in the convenience
binary package is subject to change - we could just start including all 3rd
party libraries in the Solr convenience distribution. Why not?
> maven artifacts should be equivalent to binary packaging
> --------------------------------------------------------
>
> Key: SOLR-3405
> URL: https://issues.apache.org/jira/browse/SOLR-3405
> Project: Solr
> Issue Type: Task
> Components: Build
> Reporter: Robert Muir
> Fix For: 4.1
>
>
> Lets take the commons-csv scenario:
> * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar
> anywhere,
> in fact it contains no third party jars (the stuff present in solr/lib) at
> all.
> * binary distribution contains only the jars necessary for *solrj* and
> *contrib plugins*, and a solr.war
> I think the maven artifacts should match whats in the binary release (no
> third party jars
> inside the .war are "exposed", we just publish the .war itself). This exposes
> a lot less surface area.
--
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: [email protected]
For additional commands, e-mail: [email protected]
