missing META-INF artifacts about sbt-assembly

[eed3si9n]

Everything directly under META-INF are excluded by design. Try this:

excludedFiles in Assembly := { (base: Seq[File]) => Nil }

conflictingFiles  in Assembly := { (base: Seq[File]) => Nil }

[rollinsruss]

Added that per your suggestion, now receiving:

java.lang.RuntimeException: Could not create directory /var/folders/g5/g5ooF8+7EvCDdAf+Xv+ZfU+++TI/-Tmp-/sbt_dd73df93/META-INF/license: file exists and is not a directory.

[eed3si9n]

So you have to exclude license files.

excludedFiles in Assembly := { (base: Seq[File]) => (base / "META-INF" / "license").get }

conflictingFiles  in Assembly := { (base: Seq[File]) => (base / "META-INF" / "license").get }

You get the idea..

[rollinsruss]

Thanks, appreciate the tip, I wondered how nasty it might be to reconcile potential collisions from the dependencies.

[rollinsruss]

So looks like the case is for a license directory, even with the exclusion/conflicting setting I'm still getting this error. After multiple sbt reloads and restarts. Being new, not sure if it has anything to do with the line below, where the isFile is being evaluated and my case (not sure which jar) has a directory?

private def assemblyExcludedFiles(base: Seq[File]): Seq[File] =
    (base / "META-INF" * "*").get collect { case f if f.isFile => f }

[eed3si9n]

I'll look into this later. Could you give me the name of the jars?

[rollinsruss]

The jar that's providing the directory is netty-3.2.3.Final.jar, probably several in my dependency tree that have single license files that could be overwriting each other prior to even processing the directory case. I forked so I could get this working locally (since I found another case with missing META-INF files is hosing the runtime of my assembled deployment jar) and it dawned on me that this situation presents an unpleasant chicken-and-egg issue due to name/type collisions. So I started added some logic to simply move all license related dirs and files into a separate directory to avoid collisions and overwrites altogether. That being said, I keep coming back to thinking about the Maven assembly plugin that applies an alternative approach to unzipping everything and simply shoves the jars into an embedded lib directory and updates the manifest so the classpath is complete--which avoids this problem altogether and maintains pristine isolation. Perhaps that approach could be a future alternative task on this plugin (wish I had time to help, as it has me quite intrigued).

[eed3si9n]

Not sure why license dir would cause problem if it's deleted right away.

That being said, I keep coming back to thinking about the Maven assembly plugin that applies an alternative approach to unzipping everything and simply shoves the jars into an embedded lib directory and updates the manifest so the classpath is complete--which avoids this problem altogether and maintains pristine isolation.

That's an interesting approach. Class file level exclusion filter won't work any more, but they're mostly to get around META-INF problems it seems. If the resulting jar can be made runnable, that could be the way to go.

[rollinsruss]

So the real problem was the actual deletion, but the temp dir approach might be useful for ensuring all licenses are accounted for. In the end, here's what worked for me using version 0.5:

excludedFiles in Assembly := { (base: Seq[File]) => (base.head / "META-INF" / "license" * "*" ).get }

conflictingFiles  in Assembly := { (base: Seq[File]) =>
    val licConflicts  = base.head / "META-INF" / "license"
    val manifestConflicts = base.head / "META-INF" / "MANIFEST.MF"
    (licConflicts).get ++ (manifestConflicts).get }

Note that I had to call "head" to get the actual temp dir entry otherwise my entries were ignored.

For what it's worth, any project using Java Mail with the present version will have to at least have something defined for both conflictingFiles and excludingFiles or the assembled package will be missing a slew of critical files since the default case removes everything from META-INF (in which case, again favors the Maven-style approach http://goo.gl/wq4w5).

[eed3si9n]

I am adopting your idea on excluding only license and MANIFEST.MF by default.

  private def assemblyExcludedFiles(bases: Seq[File]): Seq[File] =
    bases flatMap { base =>
      (base / "META-INF" * "*").get collect {
        case f if f.getName.toLowerCase == "license" => f
        case f if f.getName.toLowerCase == "manifest.mf" => f
      }
    }

I created #12 for maven-assembly-plugin mode, so let's keep talking there.

[rollinsruss]

Along the lines of the "lib" recommendation in an earlier comment: http://stackoverflow.com/questions/7351280/collecting-dependencies-under-sbt-0-10-putting-all-dependency-jars-to-target-sca/7361492#7361492

[eed3si9n]

I so tried to implement this, but it was more complicated than I thought. Class-Path entry in the manifest doesn't actually resolve the jar in jar, and instead you're supposed to provide a class loader. Good news is someone has already done the hard work: One-JAR™. Aslo retronym has already ported it to sbt-onejar.

[rollinsruss]

Thanks, I'll check it out!

[rain1024]

I got issue like this (http://stackoverflow.com/questions/25925233/deduplication-error-in-build-sbt-when-building-a-fat-jar-using-sbt-assembly).

But I don't know where I put

excludedFiles in assembly <<=
(excludedFiles in assembly) {
  (old) => (bases) =>
    old(bases) ++ (bases flatMap (base =>
      (base / "META-INF/ECLIPSEF.RSA").get))
}

I put this code to build.sbt in the root project but got error

/code//build.sbt:26: error: not found: value excludedFiles
excludedFiles in assembly <<= (excludedFiles in assembly) {
^
[error] Type error in expression