New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow sbt to freeze update locally. #290
Comments
sbt should probably handle this situation better. I've merged #244 into this and will address snapshot+offline handling together. |
Thanks, we would really appreciate getting this fixed because it does cause us a lot of pain. I'm curious, why did lib_managed change from being a single directory in 0.7.x to a tree in 0.11.x? Do you plan to keep this behaviour? Many thanks, Paul |
hi, is there a plan to work on this issue. Its quite painful in our enterprisy environments. |
I'd also like a way to separate the resolution of the dependencies from the build of the project, so that the build can be performed offline. We like to keep our builds repeatable, even when third party repos are down (as happens from time to time). Bundler (a similar system from the Ruby world) allows separation of "bundle package" which downloads dependencies form the internet, from "bundle install" which runs an offline build (given the right command line options). Something like that would be good with sbt. |
This can be closed soon. Will be ready in 1.0. Some changes need to be done in sbt/sbt, but the most important changes are already merged in sbt/librarymanagement. To have an idea of how the offline mode will look like, see https://github.com/sbt/sbt/wiki/User-Stories:--Offline-mode-and-Dependency-Locking. |
I guess these sbt/librarymanagement#92 are the librarymanagement changes? where they already integrated in sbt/sbt? |
Fix equal sign handling for -D
is this still relevant to remain open? |
I think it's relevant, but there hasn't been much progress in this front. |
Hi,
Apologies, I realise that we are probably doing this all wrong/fighting against how sbt wants to work.
We really like the fact that sbt magically downloads library dependencies, life is too short to do that stuff manually. It all works beautifully on our development machines, which can freely access the internet.
However, it becomes problematic in hostile "enterprise" environments where certain machines simply cannot access the internet (e.g. continuous integration, uat, production). This setup is very typical for many of our clients. Non-development boxes are strictly forbidden from downloading from the internet.
Our solution to date was to set retrievedManaged=true. So on our dev boxes the jars get downloaded, we then check lib_managed into source control and on the other boxes the jars get picked up without hitting the internet. We were okay with that. It all worked well in sbt 0.7.x when lib_managed was just a single directory, which made it easy to handle in source control.
With 0.11.x things got tricky, lib_managed now contains nested directories and 'clean' seems to whack the contents of it, which just doesn’t play nicely with source control at all (subversion at least).
We explored having our own nexus, unfortunately in the "enterprise" it can take literally months of paperwork to get something into nexus and it's highly likely that someone will mess it up. Regardless, the rate at which libraries get updated this just isn’t tenable.
Our current work around is so fantastically horrible that I'm almost too embarrassed to commit it to words ...we are checking the entire ivy and sbt boot caches into version control. Yes, this is gruesome on so many levels, but it was mainly working. Until yesterday we upgraded to 0.11.2 and I'm not sure if something changed, but not no matter what we checkin, sbt always tries to access the internet (even if you just do "sbt exit")
So, to put this a little more succinctly:
As an sbt user I want sbt to download my jars (when I say so), then I want to freeze them and have sbt not look at the internet ever again (unless I specifically ask it to).
Is this currently possible in sbt? Or is there a more elegant workaround?
I know we are not alone in having this issue, this is our third client. I also know of other projects that have just given up and shoved the jars in unmanaged or downgraded to 0.7.x – both of those options seem like a fail.
I appreciate that many of the problems we are encountering are symptomatic of working in broken enterprises, but unfortunately these factors are non-negotiable and at the end of the day we just want to get some work done/eat, so all advice is greatly appreciated!
Many thanks,
Paul
FYI, we are using sbt-launcher 0.11.2
The text was updated successfully, but these errors were encountered: