publishM2 in sbt 0.13.2-M2 don't overwrite #1156
Comments
|
I've seen this randomnly show up in our unit tests. If you don't clean the ivy cache before running, it happens always on the second running. I'll dig in and see if I can get a fix. We're blocking the 0.13.2 release on this. Thanks! |
|
Huh, this appears to be a regression from 0199a93 It looks like isSnapshot isn't returning true legitimately. I'm investigating. |
|
So there are two things at play here:
Basically, as of sbt 0.13.2 you can no longer republish a release if it already exists. This is quite a dangerous thing to do because it leads to broken caches all over. Only -SNAPSHOTs are allowed to be republished. In akka, there is a project We have a few things we can do:
|
Workaround for #1156. * Creates a new FileRepository that will stil allow local files to be transfered if overwrite is true (non-snapshot module), but will issue a warning about deprecated behavior. * Ensure warning is long enough to annoy people into asking what it's about.
Workaround for #1156. * Creates a new FileRepository that will stil allow local files to be transfered if overwrite is true (non-snapshot module), but will issue a warning about deprecated behavior. * Ensure warning is long enough to annoy people into asking what it's about.
|
I just pushed a workaround. After the nightly build, can you try against 0.13.2-SNAPSHOT? |
|
I tried (locally) to use 0.13.2-20140309-062258, but then it can't resolve the plugins. Might be easier if you create another akka pull request based on mine, that you can tweak yourself to see how jenkins reacts. Thanks. |
|
@jsuereth I was able to reproduce it locally by changing the location of the m2 repo with |
|
Great news. I need to look into that specifically though. Something is going on there which leads to the overwrite being true. If we remove that in sbt 1.0, we run back into the same issue. |
Workaround for sbt#1156. * Creates a new FileRepository that will stil allow local files to be transfered if overwrite is true (non-snapshot module), but will issue a warning about deprecated behavior. * Ensure warning is long enough to annoy people into asking what it's about.
|
I don't know if this is related, but I just tried publishing a milestone of sbt-web and received the following: java.io.IOException: destination file exists and overwrite == false
at org.apache.ivy.plugins.repository.url.URLRepository.put(URLRepository.java:75)
at org.apache.ivy.plugins.repository.AbstractRepository.put(AbstractRepository.java:130)
at org.apache.ivy.plugins.resolver.RepositoryResolver.putChecksum(RepositoryResolver.java:250)
at org.apache.ivy.plugins.resolver.RepositoryResolver.put(RepositoryResolver.java:236)
at org.apache.ivy.plugins.resolver.RepositoryResolver.publish(RepositoryResolver.java:216)...having issued an Here's my publish config: publishTo := {
val isSnapshot = version.value.contains("-SNAPSHOT")
val typesafe = "http://private-repo.typesafe.com/typesafe/"
val (name, url) = if (isSnapshot)
("sbt-plugin-snapshots", typesafe + "maven-snapshots")
else
("sbt-plugin-releases", typesafe + "maven-releases")
Some(Resolver.url(name, new URL(url)))
}I'm using sbt 0.13.5-M2. I now also have these up on Artifactory; could you remove them? (note, not 1.0.0-M1!) |
|
What repository were you trying to publish to? We recently added the "overwrite" flag back into the system so if you try to publish a release overtop of a file you get a warning. If this was for a non-local URL it's a related, but different bug. Please re-open this with a bit more info if that's the case. |
|
The repository was listed at the end there. :-) It's our typesafe Artifactory repo. |
|
I'm also unable to reopen the bug. Permissions. |
|
@huntc looks like sbt is publishing hte pom.xml file twice. The second time it fails.... |
|
SO, that's not the issue at all. The issue is that when we push checksums, Artifactory automatically creates them for us in the configuration of our repositories, so when Ivy goes to see if it exists, it does and then ivy pukes saying "can't overwrite". I need to think about how to solve this. |
|
@huntc - Your issue is actually mostly unrelated to this one (publishM2 vs. publish. I'm opening a different ticket than this to track the issue separately. |
|
Thanks Josh. Can you please cite the other issue for my tracking purposes? Thanks. |
|
I couldn't find that other issue that you referred to. However I've just seen this on our Play CI server. We're using sbt 0.13.5-RC1: [info] published play-docs_2.11 to https://private-repo.typesafe.com/typesafe/maven-releases/com/typesafe/play/play-docs_2.11/2.4-2014-05-15-b4f8cc8/play-docs_2.11-2.4-2014-05-15-b4f8cc8.pom
[info] published play-docs_2.11 to https://private-repo.typesafe.com/typesafe/maven-releases/com/typesafe/play/play-docs_2.11/2.4-2014-05-15-b4f8cc8/play-docs_2.11-2.4-2014-05-15-b4f8cc8.jar
[info] published play-docs_2.11 to https://private-repo.typesafe.com/typesafe/maven-releases/com/typesafe/play/play-docs_2.11/2.4-2014-05-15-b4f8cc8/play-docs_2.11-2.4-2014-05-15-b4f8cc8-sources.jar
[info] published play-docs_2.11 to https://private-repo.typesafe.com/typesafe/maven-releases/com/typesafe/play/play-docs_2.11/2.4-2014-05-15-b4f8cc8/play-docs_2.11-2.4-2014-05-15-b4f8cc8-tests-sources.jar
java.io.IOException: destination file exists and overwrite == false
at org.apache.ivy.plugins.repository.url.URLRepository.put(URLRepository.java:75)
at org.apache.ivy.plugins.repository.AbstractRepository.put(AbstractRepository.java:130)The artifacts actually got uploaded ok. Here's the CI that failed: https://playframework2.ci.cloudbees.com/job/play2-master-nightly-deploy/323/consoleFull Here's the repo with the published artifacts that ivy is complaining about: https://private-repo.typesafe.com/typesafe/maven-releases/com/typesafe/play/play-docs_2.11/2.4-2014-05-15-b4f8cc8/ |
|
@huntc This is because artifactory is autogenerating the files we look for. What looks odd to me is that you should NOT be seeing that in 0.13.5-RC1. Can you issue more of the stack trace so I can see the sbt-related code? |
|
Hi Josh - the full stack trace is here: https://playframework2.ci.cloudbees.com/job/play2-master-nightly-deploy/323/consoleFull |
|
The build failed again so at least it is reproducible. |
|
@huntc Ok, oddly your issue is different. You're legitimately seeing the overwrite issue. However, since you're publishing a snapshot, you can correct this by having |
|
Hey Josh. We are not publishing a snapshot though... |
|
@huntc I realize that. isSnapshot, currently, only denotes that the build can overwrite previous values. I suspect |
See sbt/sbt#1156 for more details
|
I'm facing the same problem. |
|
Believe I'm having the same issue as @huntc . Using SBT 0.13.5-RC5. These are snapshot builds and I took the same code he used to forcefully set isSnapshot, yet still getting the same error. I double-checked 'isSnapshot' is set in consoleProject: Here is the stack: |
|
0.13.5 is out. Can you try that? |
|
Actually was mistaken in my post. I actually am running 0.13.5 final. |
|
I managed to confirm that the warning goes away with Be careful, though, with |
|
I'm experiencing the same problem with sbt 0.13.8. i have a multi-project with 21 submodules, and I get this error for each project |
|
The issue appeared for me as well while switching from |
|
It would also be nice, if that exception would be caught and wrapped at a level that can provide meaningful information to the sbt user, so that the Exception message would be something along these lines: |
|
Could we have an option to completely ignore this. I've got a multiproject build where I aggregate submodules so that publishing the main project publishes the submodules. Each submodule has its own version so often the submodule has already been published. I would like publish to work so that I can instruct it to just quietly fail if the artifact already exists (and to overwrite it if it is SNAPSHOT). |
Workaround for sbt#1156. * Creates a new FileRepository that will stil allow local files to be transfered if overwrite is true (non-snapshot module), but will issue a warning about deprecated behavior. * Ensure warning is long enough to annoy people into asking what it's about.
Changed behaviour compared to 0.13.1.
See log from this pull request build
The text was updated successfully, but these errors were encountered: