如何使用不同的配置为单个模块创建 tarball 和 zip? [英] How do I create a tarball and a zip for a single module using distinct configurations?

查看:44
本文介绍了如何使用不同的配置为单个模块创建 tarball 和 zip?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个多项目构建,其中包含一个特别凌乱的模块,其中包含多个 mainClass.我想为这个凌乱的模块创建几个分发包,每个分发包使用不同的文件集和不同的格式.想法?

I have a multi-project build with a particularly messy module which contain several mainClasses. I would like to create several distribution packages for this messy module, each distribution package employing distinct file sets and employing different formats. Ideas?

推荐答案

这是来自 sbt-nativer-packager 问题跟踪器,其中发布了相同的问题.

This is the answer from the sbt-nativer-packager issue tracker where the same question was posted.

我也在 gitter 聊天中添加了这个:

I'm adding this from the gitter chat as well:

我刚到这个聊天室,我对 sbt-native-packager 的了解几乎为零……但无论如何……在我看来,JavaAppPackaging 和其他原型实际上应该是从 Universal 扩展的配置.在这种情况下,我将创建我自己的从 JavaAppPackaging 扩展的配置,并根据我的需要调整必要的位.最后,如果插件只选择 ThisScope 中的映射...它会选择我自己的作用域,而不是 JavaAppPackaging... 也不是 Universal.那么,让我们一一介绍.

I'm just arriving in this chat room and my knowledge of sbt-native-packager is virtually zero... but anyway... looks to me that JavaAppPackaging and other archetypes should actually be configurations extended from Universal. In this scenario, I would just create my own configuration extended from JavaAppPackaging and tweak the necessary bits according to my needs. And, finally, if the plugin just picks mappings in ThisScope... it would pick my own scope, and not JavaAppPackaging... and not Universal. So, let's go through this one by one.

sbt-native-packager 插件总是在 Universal 中选择映射.这并不理想.它应该在概念上选择 ThisScope 中的映射SBT 原生打包器提供两类 AutoPlugins:FormatPluginsArchetypePlugins.FormatPlugins 提供了一种新的包格式,例如UniversalPlugin(zip、tarball)或 DebianPlugins (.deb).这些插件形成一个层次结构,因为它们是建立在彼此之上的:

The sbt-native-packager plugin always pick mappings in Universal. This is not ideal. It should conceptually pick mappings in ThisScope SBT native packager provides two categories of AutoPlugins: FormatPlugins and ArchetypePlugins. FormatPlugins provide a new package format, e.g. UniversalPlugin (zip, tarball) or DebianPlugins (.deb). These plugins form a a hierarchy as they are build on top of each other:

          SbtNativePackager
                +
                |
                |
  +-------+  Universal  +--------+
  |                              |
  |             +                |
  |             |                |
  +             +                +
Docker    +-+ Linux +-+      Windows
          |           |
          |           |
          +           +
       Debian        RPM

映射,定义一个 文件 ->targetpath 关系,用这个模式继承

mappings, which define a file -> targetpath relation, are inherited with this pattern

mappings in ParentFormatPluginScope := (mappings in FormatPluginScope).value

所以对于 docker 来说,它看起来像这样

So for docker it looks like this

mappings in Docker := (mappings in Universal).value

linux 格式插件使用专门的映射来保留文件权限,但基本相同.

The linux format plugins use specialized mappings to preserve file permissions, but are basically the same.

由于 sbt-native-packager 插件总是在 Universal 中选择映射,我必须在我的每个配置中重新定义 Universal 中的映射是的.如果您想定义自己的范围并继承映射并更改它们,您也必须这样做,就像所有其他打包插件一样.我建议将此代码放入项目文件夹中的自定义 AutoPlugins 中.

Since sbt-native-packager plugin always pick mappings in Universal, I have to redefine mappings in Universal in each of my configurations Yes. If you want to define your own scope and inherit the mappings and change them you have to do this, like all other packaging plugins, too. I recommend putting this code into custom AutoPlugins in your project folder.

例如(未测试,可能缺少导入)

For example (not tested, imports may be missing )

import sbt._

object BuilderRSPlugin extends AutoPlugin {
   def requires = JavaAppPackaging

   object autoImport {
        val BuilderRS = config("builderrs") extend Universal
   }

  import autoImport._

  override lazy val projectSettings = Seq(
     mappings in BuilderRS := (mappings in Universal).value
  )
}

在我看来 JavaAppPackaging 和其他原型实际上应该是从 Universal 扩展的配置JavaAppPackaging 是一个原型,这意味着这个插件不会带来任何新的打包格式,因此没有新的作用域.它配置了所有可以使用的打包格式并启用它们.

looks to me that JavaAppPackaging and other archetypes should actually be configurations extended from Universal JavaAppPackaging is an archetype, which means this plugin doesn't bring any new packaging formats, thus no new scopes. It configures all the packaging formats it can and enables them.

您可以通过指定范围来打包内容:

You package stuff by specifying the scope:

universal:packageBin
debian:packageBin
windows:packageBin

因此,如果您需要自定义输出格式,请在相应的范围内执行此操作.

So if you need to customize your output format you are doing this in the respecting scope.

mappings in Docker := (mappings in Docker).value.filter( /* what ever you want to filter */)

这篇关于如何使用不同的配置为单个模块创建 tarball 和 zip?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆