lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3943) Use ivy cachepath and cachefileset instead of ivy retrieve
Date Tue, 03 Apr 2012 16:04:27 GMT


Robert Muir commented on LUCENE-3943:

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

Is this really the case?

In my opinion, the ideal situation would be that we pass these filesets directly to the zip/tar/gz
whatever in the
binary release targets: they never see lib/, they are just added directly to the zip. So we
could nuke the 
clean-jars stuff totally.

This is also way more ideal because then compile/test/release packaging tasks only change
files in build/ and dist/, not
elsewhere (be it tests modifying the source tree: SOLR-3268, or dist-maven modifying the source
tree: LUCENE-3944,
or ivy:retrieve modifying the source tree: lib/), this is bad news and makes releasing complicated.

The tradeoff is we have to seriously modify packaging tasks to implement this, which I think
is too risky to do
for 3.x, but this would be a very nice improvement for making the release process less error-prone
for 4.0 or possibly even 4.1 or later.

> Use ivy cachepath and cachefileset instead of ivy retrieve
> ----------------------------------------------------------
>                 Key: LUCENE-3943
>                 URL:
>             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:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message