Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Tue, 3 Apr 2012 15:36:24 +0000 (UTC)
From: "Hoss Man (Updated) (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: 
 <2040483443.6608.1333467384460.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <182362553.4001.1333410562630.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (LUCENE-3943) Use ivy cachepath and cachefileset
 instead of ivy retrieve
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/LUCENE-3943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hoss Man updated LUCENE-3943:
-----------------------------

    Description: 
In LUCENE-3930 we moved to resolving all external dependencies using ivy:retrieve.  This process places the dependencies into the lib/ folder of the respective modules which was ideal since it replicated the existing build process and limited the number of changes to be made to the build.

However it can lead to multiple jars for the same dependency in the lib folder when the dependency is upgraded, and just isn't the most efficient way to use Ivy.

Uwe pointed out that _when working from svn or in using src releases_ we can remove the ivy:retrieve calls and make use of ivy:cachepath and ivy:cachefileset to build our classpaths and packages respectively, which will go some way to addressing these limitations -- however we still need the build system capable of putting the actual jars into specific lib folders when assembling the binary artifacts

  was:
In LUCENE-3930 we moved to resolving all external dependencies using ivy:retrieve.  This process places the dependencies into the lib/ folder of the respective modules which was ideal since it replicated the existing build process and limited the number of changes to be made to the build.

However it can lead to multiple jars for the same dependency in the lib folder when the dependency is upgraded, and just isn't the most efficient way to use Ivy.

Uwe pointed out that we can remove the ivy:retrieve calls and make use of ivy:cachepath and ivy:cachefileset to build our classpaths and packages respectively, which will go some way to addressing these limitations


updating summary to note that this will really only help when working with svn checkouts and src releases -- we'll still need to actually copy jar files around when building the binary artifacts (which means we'll probably also still want something like clean-jar for use by the R.M.)
                
> Use ivy cachepath and cachefileset instead of ivy retrieve
> ----------------------------------------------------------
>
>                 Key: LUCENE-3943
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3943
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: general/build
>            Reporter: Chris Male
>
> In LUCENE-3930 we moved to resolving all external dependencies using ivy:retrieve.  This process places the dependencies into the lib/ folder of the respective modules which was ideal since it replicated the existing build process and limited the number of changes to be made to the build.
> However it can lead to multiple jars for the same dependency in the lib folder when the dependency is upgraded, and just isn't the most efficient way to use Ivy.
> Uwe pointed out that _when working from svn or in using src releases_ we can remove the ivy:retrieve calls and make use of ivy:cachepath and ivy:cachefileset to build our classpaths and packages respectively, which will go some way to addressing these limitations -- however we still need the build system capable of putting the actual jars into specific lib folders when assembling the binary artifacts

--
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