making rm -rf ~/.ivy2/cache less painful

[Diego Medina]

Hi,

From time to time I end up having to delete my ivy cache to get sbt work normal, and the pain there is that you have to download all the jar files again, which takes a long time. I usually can get away with simply removing the net.liftweb jars, but even there, as I try different versions of Lift on a weekly basis, the download time hurts.

Today I did some simple tests, and the cloudbees repo seems faster than the sonatype,

some not scientific numbers here:

https://gist.github.com/fmpwizard/6180934

short test for webkit:

 cloudbees   sonatype

5 sec             5.8 sec

4.8 sec           5.5 sec

I'm on the east coast, so that may make a difference, but I'm going to see about changing the default repo from sonatype to

"CB Central Mirror" at "http://repo.cloudbees.com/content/groups/public",

Thanks

  Diego

--
Diego Medina
Lift/Scala Developer
di...@fmpwizard.com
http://fmpwizard.telegr.am

[Tim Nelson]

How about giving https://bintray.com/ a try. Been hearing some Scala folks rave about how much easier it is to use. Not sure if it's going to be any better with the download speeds, though.

Tim

[Richard Dallaway]

If it's easier for publishing than Sonatype, that's really interesting.  I'll have a look around bintray... thanks.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
 
---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Viktor Hedefalk]

If you have a home-server its actually not that big a deal to set up
an Artifactory or Nexus and proxy everything. I tend to do that for
most stuff. I just moved from Artifactory to Nexus and I'm finally
happy. Maybe not a reason alone to have a wardrobe-server always on,
but who doesn't need to host code-repos, nexus, jenkins, staging
sites, torrent- and media-server? :)

But then I haven't ever had the need to blow away my local ivy-cache
either? When do you struck these problems? I've heard of these
problems but never understood. I'm curious, do you do publish-local
when developing Lift without changing version? I guess you could get
the same problems with broken cache on the server too depending on
what's causing it. It's not much more fun deleting a cache with a web
gui than command line :)

By the way, I've found Ivy horrible for publishing SNAPSHOTs so I
moved over to a aether-deploy plugin (Mavens way of deploying) which
then timestamps correctly so I actually get the newest SNAPSHOT when I
ask for it.

Thanks,
Viktor

[Diego Medina]

The issue tends to happen when I publish-local with the same version, which works "sometimes", but not all the time. It sometimes happens at work too, and there it is related to having different feature branches and some of them bring new dependencies and sbt reload or even restarting it doesn't always fix it. It's not as bad that it happens once a week, but once every two months or so.

Thanks

  Diego

[Viktor Hedefalk]

You're developing on a SNAPSHOT version, right? I think it might have
to do with how Ivy handles that. Seems completely broken to me coming
from Maven. Aether on the other hand does SNAPSHOTing just fine with
timestamps so that I get the latest version and that xml:s and jar:s
match.

I had problems with metadata deploying SNAPSHOTS from jenkins.
Basically I wanted every commit to be published (I like to keep my
wardrobe warm) and then staged on a downstream project. But I couldn't
do this with Ivy. Deploying a new SNAPSHOT didn't update meta-data so
the downstream project just got an old snapshot version.

http://stackoverflow.com/questions/16734190/nexus-doesnt-update-metadata-for-snapshot

I would guess your problem is something similar but local.

I think you can fix so that sbt also checks your Maven repo and then
use https://github.com/arktekk/sbt-aether-deploy to deploy SNAPSHOTs
with Aether against a local Maven repo instead.

Maybe too big a hastle, dunno.

Either that or use something like git-version into the version-string
(like Josh suggests:
http://jsuereth.com/scala/2013/06/11/effective-sbt.html) so that
they're all different. But then you can't depend on something like
2.6-SNAPSHOT on you test-project :(

Hm, hm...,
Viktor

[Diego Medina]

I'll add

https://github.com/arktekk/sbt-aether-deploy

to the list of neat tools to look at

I saw the presentation from Josh, but had the same thought, what's the point of doing a snapshot if I need to keep changing my dependencies to get the latest.

Thanks

  Diego