lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Rowe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
Date Fri, 27 Apr 2012 22:04:50 GMT

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message