lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
Date Wed, 25 Apr 2012 14:38:18 GMT

    [ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261678#comment-13261678
] 

Robert Muir commented on SOLR-3405:
-----------------------------------

{quote}
This is an argument against Maven generally, not exclusively the Solr artifacts; I view it
as a thinly veiled re-assertion that Lucene/Solr should not support Maven at all. Again: -1.
{quote}

Its really not that: and though i've asserted this before (especially when maven had no tests,
but now it does), when
did I do this on the recent thread? I have stated that I think we shouldn't release maven
if its "different" than our
other packaging because I think that causes it to be more of a mystery. I opened this issue
to *improve* the situation,
not to have an issue to argue about maven. you can s/maven/rpm/ and i feel the same way about
all of this: these are
just different packaging formats but I think the underlying products we release should be
*the same*.

I'm upset about the maven packaging on this issue because in my opinion, it packages solr
up like an API which is 
different than our binary release: which packages it up to be used as an application. Frankly
you really can't
do much else with the solr binary packaging except use it as an application: those solr-core.jar's
etc do you
absolutely no good unless you hunt down all the jars (or yank em out of solr.war/WEB_INF,
maybe some IDEs do that),
yourself.

{quote}
+1, I've looked at doing this in the past but didn't see a quick way to do it.
{quote}

I also don't think we should do it for 4.0, its too risky. But we should look at it for the
future. A few things to think about:

* its annoying when releasing lucene/solr that you cant do it all with one command line. So
I think we would add a top-level "prepare-release" to trunk/build.xml that would simply invoke
solr/ prepare-release. And solr's prepare-release would depend on lucene's. That would be
nice as we have one single command for this.
* since solr prepare-release now knows that lucene's is also built, I think it would be easier
for it to use the jars from the lucene release. easier, not easy.

thats just the non-maven parts, the maven stuff is more blurry to me.
                
> 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.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
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