[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13262884#comment-13262884
]
Michael McCandless commented on SOLR-3405:
------------------------------------------
bq. I understand if Rob, Mike, etc. want nothing to do with Maven and I think
that's just fine. But please don't stand in Steve and I's way.
It's not that I want to stand in your way.
I agree that many users want to consume Lucene/Solr from Maven's
central repository, and I agree that users want to to build their own
projects, depending on Lucene/Solr, using Maven. That's all great.
I want Lucene/Solr to be widely accessible/adopted and so pushing to
Maven central helps achieve that goal.
I just don't think it should be this PMC that votes on / pushes our
released artifacts to Maven.
Pushing to Maven has clear risks ("we" got "in trouble" for it), not
all PMC members understand the Maven policies/conventions, it's a
distraction ("we" are supposed to be focused on building great search
engines around here).
We don't push to all the other great repositories (apt, yum, FreeBSD,
etc.) out there. We don't understand their conventions either. The
PMC doesn't vote when a downstream package maintainer pushes our
artifacts into their repository. Why should Maven central be any
different from other repositories?
And I still assert that a stronger decoupling the PMC voting on the
"true" Lucene/Solr artifacts from pushing-to-Maven-central would
net/net be a win for Maven users. Eg, Lucene 3.4.0's Maven artifacts
were broken (SOLR-2770), and now apparently also 3.6.0's (SOLR-3411).
But if the two events were fully decoupled then the Maven POMs could
be re-pushed without this PMC being involved. And issues like this
("which jars/wars should be pushed into Maven central... solr.war
expanded or not") wouldn't be this PMC's business. The Maven experts
would be free to make such decisions.
Maybe... a possible compromise here would be to continue pushing to
Maven central, but as a downstream event (after a release) within this
project. Meaning, the PMC votes on the "original" sources/convenience
binaries, but then the Maven experts around here can separately (once
the vote passes) take that binary release, expand it, attach POMs,
etc., and push to Maven central. This would mean the PMC doesn't vote
on what's-pushed-to-Maven, but we continue using this project's
infrastructure (svn, continuous builds, Jira, etc.) to push to Maven
central. Could something like that work?
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
