logo separator

[mkgmap-dev] version of splitter's fastutil dependency?

From Richard Hansen rhansen at bbn.com on Sun Feb 5 21:04:05 GMT 2012

On 2012-02-05 07:03, Steve Ratcliffe wrote:
> Hi Richard
>> Does anyone know which version of fastutil is checked in to splitter's
>> svn repository?  All of the versions at
>> <http://mvnrepository.com/artifact/it.unimi.dsi/fastutil> are MUCH
>> bigger than that one.
> I believe that it is 5.1.5.

OK, thanks.  I don't see that version in the public Maven Central 
Repository.  Would it be OK to upgrade to the latest?  Or downgrade to 
5.0.9 (see <http://mvnrepository.com/artifact/fastutil/fastutil>)?

> However it is processed with autojar (http://autojar.sourceforge.net/)
> to contain only the classes that we require, as suggested on the home
> page of fastutil (http://fastutil.dsi.unimi.it/)

Ah, I see.  I don't see autojar in any of the public Maven repositories; 
we may have to put it up on ivy.mkgmap.org.uk.

> From the point of view of creating the distribution that I serve at
> http://www.mkgmap.org.uk/splitter/ I think it is worth continuing to
> included a trimmed fastutil jar, since otherwise the download will
> bloat to several times its existing size for no benefit.


> But this could be done by putting the trimmed jar in the mkgmap ivy repo
> or by trimming the fastutils jar as part of the build process, I don't
> mind which.
> For someone building on their own machine it probably matters less.

I think I'd prefer to trim fastutil as part of the build process for a 
few reasons:
   * all of the logic needed to go from start to finish is contained in 
build.xml (we don't have to separately document how to generate the 
trimmed fastutil jar)
   * if splitter starts using more of fastutil we don't have to generate 
a new fastutil jar
   * if splitter starts using less of fastutil the output will be 
smaller without us uploading a smaller fastutil jar to the ivy 
repository (which would break compatibility with old svn revisions)
   * downloading from the Maven Central Repository reduces load on 

There are the following drawbacks:
   * it slows down the build
   * it increases the load on the Maven Central Repository
   * it increases the amount users have to download in order to build 
splitter from svn


More information about the mkgmap-dev mailing list