lucene-dev mailing list archives

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

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

Benson Margulies commented on SOLR-3405:
----------------------------------------

You might be surprised by this, but I agree with you.

I could build that plugin for you, mostly. Here's what I can't do for you. I can't arrange
for you to declare a dependency in terms of the URL to a JAR. I'm sorry, but I can't undo
the narrow-minded thinking of the founder of maven. What I can do is make it possible to have
a two-pass maven build: the first run of maven would use such a plugin to download things
(and, if you like, patch and build them from source), so that the second run would just find
them in the local repo.

Actually, I'm not quite being truthful. Maven has an extension architecture for talking to
repos called 'wagons'. I think that I could set up an wagon that defined a 'repository' in
terms of that CSV file I described above. Not too awful, come to think of it. You add a declaration
of that wagon to the pom, and a rather funny <repository> element to the pom ... but
consumers might not thank you.

The central tenant of maven thinking (who does not pay enough rent) is that it's never a big
deal to grab a jar and stick it in some convenient repo and use it, so why do we need to allow
for getting jars from anywhere else? And lots of people all over find this tolerable. You
don't, and I'm not particularly motivated to tell you that you're wrong. Still and all, given
a days' warning of the need, Steve or I or anyone else who cared to do the reading could get
noggit or anything else onto Central via OSSRH. If we want to ask the author first, we need
time for a response. If we just want to push it under our own coordinates (I'd use 'us.dchbk'),
then it's just the time it takes the jar to wander out there.


                
> 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