Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Tue, 24 Apr 2012 21:24:06 +0000 (UTC)
From: "Steven Rowe (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: 
 <1637177127.306.1335302646466.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1895788472.9710.1335276815214.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (SOLR-3405) maven artifacts should be equivalent
 to binary packaging
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Steven Rowe commented on SOLR-3405:
-----------------------------------

{quote}
So then i can commit my patch, and we could release tomorrow and maven should work? great!

But i suspect this isnt the case, you are conflating the 'maven build' with 'maven artifacts' no?
{quote}

I am not conflating the two; as Benson mentioned, marking those non-mavenized dependencies as optional in the POMs of modules that need them would allow "maven artifacts" on Maven Central to be useable.  

The mode of use, however, would be: 

* checkout the tagged release, including dev-tools, from subversion (or maybe from git instead?)
* run {{ant get-maven-poms resolve ; mvn -N -Pbootstrap install}} in order to put the non-mavenized jars in one's local maven repository
* add *optional* dependencies, using Benson's "groupId-invented/artifactId-invented" coordinates, to one's own project's POMs.

                
> 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