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] [Issue Comment Edited] (SOLR-3405) maven artifacts should be equivalent to binary packaging
Date Tue, 24 Apr 2012 14:17:36 GMT

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

Benson Margulies edited comment on SOLR-3405 at 4/24/12 2:16 PM:
-----------------------------------------------------------------

What you did is perfect in every way if you *want* to publish the JAR so that API-style users
get the benefit, but it's a lot of work if all you want it to put a patch into a war or an
assembly.

How does the following alternative strike for getting patched binaries into the war without
them leaking anywhere or renaming packages?

WAR FILES:

Some script (probably in ant):

1. Grab and patch patch the source (not changing the package) and builds a jar for each patched
item.
2. The results are assembled into a 'sparse war file' (just containing WEB-INF/lib/all-them-jars).
3. mvn install:install-file (or the maven ant tools) push the results to the local repository.
4. the pom for the war file lists the results as an 'overlay'.

It seems to me that the WAR file is the whole show here, since all the patched binaries go
inside the war? If that's no so, let me know.


                
      was (Author: bmargulies):
    What you did is perfect in every way if you *want* to publish the JAR so that API-style
users get the benefit, but it's a lot of work if all you want it to put a patch into a war
or an assembly.

How does the following alternative strike you?

WAR FILES:

Some script (probably in ant):

1. Grab and patch patch the source (not changing the package) and builds a jar for each patched
item.
2. The results are assembled into a 'sparse war file' (just containing WEB-INF/lib/all-them-jars).
3. mvn install:install-file (or the maven ant tools) push the results to the local repository.
4. the pom for the war file lists the results as an 'overlay'.

It seems to me that the WAR file is the whole show here, since all the patched binaries go
inside the war? If that's no so, let me know.


                  
> 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