Setting assemblyOutputPath to "." leads to data loss!

[posto]

Please add a warning to the documentation about the possible data loss when setting assemblyOutputPath folder. I didn't expect that the content is emptied during the build.

Judging by the name of the property, I was expecting that assembly plugin will just save the output (the überjar) in the specified folder. I did not expect anything to be deleted. At most -- just an overwrite of the old file it generated during the last build.

If the assembly plugin uses this folder as some sort of work dir as well, please name the property accordingly.

How to reproduce (if you really must): I needed to save shadowed jar file in the root of my project so I tried setting up

// do NOT do this at home!
assemblyOutputPath := new File(".") // thank god I did not set it to "/"

I ran the build just once and then the src/ and .git/ folders and everything else in the project got deleted.

java.lang.RuntimeException: Specified output file . is a directory.
    at scala.sys.package$.error(package.scala:27)
    at sbt.IO$.archive(IO.scala:457)
    at sbt.IO$.jar(IO.scala:445)
    at sbt.Package$.makeJar(Package.scala:97)
    at sbtassembly.Assembly$.sbtassembly$Assembly$$makeJar$1(Assembly.scala:40)
    at sbtassembly.Assembly$$anonfun$5$$anonfun$apply$4.apply(Assembly.scala:79)
    at sbtassembly.Assembly$$anonfun$5$$anonfun$apply$4.apply(Assembly.scala:75)
    at sbt.Tracked$$anonfun$outputChanged$1.apply(Tracked.scala:84)
    at sbt.Tracked$$anonfun$outputChanged$1.apply(Tracked.scala:79)
    at sbtassembly.Assembly$.apply(Assembly.scala:83)
    at sbtassembly.Assembly$$anonfun$assemblyTask$1.apply(Assembly.scala:240)
    at sbtassembly.Assembly$$anonfun$assemblyTask$1.apply(Assembly.scala:237)
    at scala.Function1$$anonfun$compose$1.apply(Function1.scala:47)
    at sbt.$tilde$greater$$anonfun$$u2219$1.apply(TypeFunctions.scala:40)
    at sbt.std.Transform$$anon$4.work(System.scala:63)
    at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:228)
    at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:228)
    at sbt.ErrorHandling$.wideConvert(ErrorHandling.scala:17)
    at sbt.Execute.work(Execute.scala:237)
    at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:228)
    at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:228)
    at sbt.ConcurrentRestrictions$$anon$4$$anonfun$1.apply(ConcurrentRestrictions.scala:159)
    at sbt.CompletionService$$anon$2.call(CompletionService.scala:28)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
$ ls src/                                                                                                                
ls: src/: No such file or directory

[larsrh]

Just ran into the same problem. Should be easy enough to fix with a PR (will try to do that).

[larsrh]

This is the cause of the problem:

def makeJar(sources: Seq[(File, String)], jar: File, manifest: Manifest, log: Logger): Unit = {
    log.info("Packaging " + jar.getAbsolutePath + " ...")
    IO.delete(jar)
    log.debug(sourcesDebugString(sources))
    IO.jar(sources, jar, manifest)
    log.info("Done packaging.")
}

It unconditionally recursively deletes jar. I believe it should check whether it's a regular file first.

[larsrh]

Would a maintainer mind closing this? (Poke @eed3si9n)

This is fixed in an upcoming SBT release, by virtue of sbt/sbt#3014.

[ryan-williams]

Just hit this as well, with sbt-assembly 0.14.4 and SBT 0.13.13.

Is the recommended fix to upgrade SBT to 0.13.14? Is an sbt-assembly upgrade also required?

[larsrh]

@ryan-williams It is sufficient to update sbt, yes. No upgrade of the plugin required.

[eed3si9n]

Actually per https://github.com/sbt/sbt-assembly/pull/523, we can still manage to lose data via IO.delete(...).