Renaming compiled artifact in package (feature)

[sumkincpp]

By default compiled jar from Compile scope with name XXX.jar got renamed to lib/default.XXX.jar in Universal package scope. Would be great to have a feature which will allow to customize the naming of artifact(s) in final package.

artifactName in Universal ... renames whole zip and doesn't customizes jar naming.

Currently there is a workaround where each artifact in final package can be customized, i.e. :

mappings in Universal := {
    val universalMappings = (mappings in Universal).value
    val resultjar = (packageBin in Compile).value // this is named XXX.jar or whatever we need

    // Removing generated lib/default.XXX.jar 
    val filtered = universalMappings filter {
        case (file, name) =>  ! name.startsWith("lib/default")
    }

    filtered :+ (resultjar -> ("lib/" + resultjar.getName))
}

I hadn't found in repo where 'default' prefix is added to binary, I will be pleased if someone could point to this place.

As @muuki88 said in mailing list thread, there may be a helper method implementation for renaming mappings.

[muuki88]

Hi,

I think I misunderstood your question. Your application jar is named default.jar? This sounds more like some configuration error.

How the names are generated for the jars in the /lib folder is defined in the JavaApp archetype. The logic follows the basic maven classifier.

Please check your organization and name settings. And can you post a minimal build.sbt to reproduce this?

The original purpose of this ticket would be to implement a small helper to rename artifacts and add this feature to the MappingHelpers

[sumkincpp]

Yes, I have default sbt config w/o any maven setting specified. This is why organization defaults to default value. As a result the package name becomes default.package-name.jar as by the logic you pointed to.

[normana400]

I'd like to reactivate this conversation by adding a concrete usecase
dependent jars by default get placed in a /lib directory and they can have names that we want to alter:

(i.e. rename/ move ./lib/com.mycompany.myproject.myjarname-1.2.3-SNAPSHOT-assembly.jar -> ./myjarname.jar)

[muuki88]

After 4 years have passed I'm not entirely sure if this is a good idea.

All scripts assume that the jars are placed in a folder lib. The package layout is rather fixed and shouldn't really matter as the start script builds the classpath (different variations are available, e.g the LauncherJar plugin) .

@normana400 from your example I assume you are using sbt-native-packager and sbt-assembly together. These plugins can be used together, but actually they are solving the same issue, but in different ways. Namely: "packaging a deployable artifact". sbt-assembly builds a fat-jar, while native-packager builds a distribution in various formats (docker, zip, rpm, ... ).

Depending on the use case you choose one or the other. Why do you combine both? I'm curious 😄

[normana400]

I don't use sbt-assembly and native-packager together per se.

Assembly is used in upstream projects to create individual service uber jars.
we have 7 or so services that get built that way and they are meant to be individually deployable (and developers deploy these individually in our development environments).

The sbt-native-packager is used in a downstream project as a single zip of all these uber jars. This give operations has a "single zip of everything that needs to be deployed in a release cycle" and they use that single zip as a convenient package that they do all their deployments from.

So in this case with the downstream "bundler" project, it references the artifacted assembly jars built from the upstream service projects as dependencies. The "bundler" just zips those uber jars up as a zip file (using the native-packager) with the uber jars inside.

Since the uber jars are dependencies, they are getting placed in a /lib directory. I was trying to see if I could configure the native-packager to package them so they are in the root directory. Extra credit if I can also rename the uber jars themselves as well. This removes the need for logic in downstream operation scripts that would need to do this.