lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (JIRA)" <>
Subject [jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
Date Tue, 24 Apr 2012 20:03:34 GMT


Robert Muir commented on SOLR-3405:

Rob, my experience here is that you pose a very specific question (e.g. do war files force
public dependencies) and when I answer it, you switch the subject to a different question.
Not an illegitimate or uninteresting question, but a different question.

I agree its somewhat off-topic, I'm just trying to point out that these 'implementation-detail'
jars have real costs and are not free. By maven exposing them the way it does, it more than
doubles the surface area of responsibility of third party jars as compared to the binary packaging.

And by maven not being able to download jar files from anywhere except maven itself, it really
boxes you into a corner as far as managing dependencies. Would it really be so bad if someone
adds a maven plugin that can just download a jar file from any http location? I could call
it 'maven-antivirus-plugin'? :)

> maven artifacts should be equivalent to binary packaging
> --------------------------------------------------------
>                 Key: SOLR-3405
>                 URL:
>             Project: Solr
>          Issue Type: Task
>          Components: Build
>            Reporter: Robert Muir
>             Fix For: 4.0
> 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
> 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:!default.jspa
For more information on JIRA, see:


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

View raw message