Directories in packageMapping

[Dremora]

Currently it's not possible just to specify a single dir in packageMapping, one has to recursively go through its contents. The following code does not work as expected:

linuxPackageMappings <+= target map { target =>
  val src = target / "webapp"
  val dest = "/opt/app"
  packageMapping(src -> dest)
}

A way of dealing with it on the client side:

linuxPackageMappings <+= target map { target =>
  val src = target / "webapp"
  val dest = "/opt/app"
  LinuxPackageMapping(
    for {
      path <- (src ***).get
      if !path.isDirectory
    } yield path -> path.toString.replaceFirst(src.toString, dest)
  )
}

It would be nice to have this functionality on the library side for consistent and expected behavior.

[jsuereth]

What do you think of the following API?

linuxPackageMapping <+= target map { t =>
  mapDirectoryAndContents(target / "webapp", "/opt/app")
}

You can then use the combinators to do more, like:

linuxPackageMapping <+= target map { t =>
  (mapDirectoryAndContents(target / "webapp/config", "/opt/app/config") 
   gzipped()
   withConfig("autoreplace")
  )
}

That's until I come up with a better idea to do package mappings of files in a convenient way. Personally I liked how the maven-rpm-plugin worked, but I need to think through how to make something handy in SBT like that.

[Dremora]

It makes more sense to have this as a flag:

linuxPackageMapping <+= target map { t =>
  packageMapping(target / "webapp", "/opt/app") withContents()
}

However, mapDirectoryAndContents can be just helper function implementing the code above, and thus might be handy as well. The other thing is that the name mapDirectoryAndContents is a bit redundant, as many would expect directories to be mapped with their entire contents by default. Just mapDirectory seems fine to me. It makes even more sense to enable content inclusion by default even for packageMapping, but it will break existing code.

On a side note, I also don't see a reason for having one-to-many relationship between metadata and mapping, especially after this feature is implemented (as the amount of mappings will greatly reduce for most projects). rpm-maven-plugin doesn't have this feature either. Even the example in README is mostly using one mapping per LinuxPackageMapping (and, well, having mappings inside mapping is a bit confusing). Again, this is not directly related to the issue discussed here, but may be a step towards simplification without losing any functionality.

[jsuereth]

The rpm-maven-plugin is doing some crazy stuff with those mappings. Crazy and uncontrollable and can be a PITA to debug. I remember.

This is explicit, and I use the mutli-mapping feature all the time.

In any case, I find myself missing two features from the maven-rpm-plugin:

(1) Auto-resolving dependencies into desired locations and assinging permissions. Something like:

linuxPackageMapping <++=  libraryDependencies {  ld =>
  def runtimeScoped(a: ModuleID): Boolean = ...
  (dependencyMappings(ld filter runtimeScoped) 
     into "/usr/share/java" 
     withPermissions("755")
  )
}

And then something else that can take a directory and its sub directories and map them appropriately. The issue we have is that the Maven rpm plugin actually parses a config file to determine filtering. If you configure a sub-directory or file differently than a parent, something different happens. I can add logic like this of course, but I'd prefer a more SBT solution, one that uses common SBT-isms like filters and exlcudes, etc.

[indykish]

Josh,
We are building a debian package for bundling a "scala based Play API Server"- (http://github.com/indykish/megam_play.git).

Our process sbt clean deploy stage

Once we have staged (*.jars), and start script, run deb package. It will be cumbersome to include all the required jars recursively.

This fix worked perfectly. Thankyou Dremora

linuxPackageMappings <+= target map { target =>
  val src = target / "staged"
  val dest = "/usr/local/mp/lib"
  LinuxPackageMapping(
    for {
      path <- (src ***).get
      if !path.isDirectory
    } yield path -> path.toString.replaceFirst(src.toString, dest)
  )
}

[jsuereth]

Hey guys, glad to hear it. I'm hoping to revamp this stuff shortly, possibly with some more nice/clean defaults for most projects. Just haven't had time recently. Patches are welcome thoguh.

[jsuereth]

@Dremora You should look at the auto-debian support in the latest version as well. You can now create a debian file for 'generic' java applications. Play 2.2 is pulling this in by default.