• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            ++wythern++

            X presents Y for a better Z

            What is shade jar, and what is its purpose.

            https://stackoverflow.com/questions/13620281/what-is-the-maven-shade-plugin-used-for-and-why-would-you-want-to-relocate-java


            Uber JAR, in short, is a JAR containing everything.

            Normally in Maven, we rely on dependency management. An artifact contains only the classes/resources of itself. Maven will be responsible to find out all artifacts (JARs etc) that the project depending on when the project is built.

            An uber-jar is something that take all dependencies, and extract the content of the dependencies and put them with the classes/resources of the project itself, in one big JAR. By having such uber-jar, it is easy for execution, because you will need only one big JAR instead of tons of small JARs to run your app. It also ease distribution in some case.

            Just a side-note. Avoid using uber-jar as Maven dependency, as it is ruining the dependency resolution feature of Maven. Normally we create uber-jar only for the final artifact for actual deployment or for manual distribution, but not for putting to Maven repository.


            Update: I have just discovered I haven't answered one part of the question : "What's the point of renaming the packages of the dependencies?". Here is some brief updates and hopefully will help people having similar question.

            Creating uber-jar for ease of deployment is one use case of shade plugin. There are also other common use cases which involve package renaming.

            For example, I am developing Foo library, which depends on a specific version (e.g. 1.0) of Bar library. Assuming I cannot make use of other version of Bar lib (because API change, or other technical issues, etc). If I simply declare Bar:1.0 as Foo's dependency in Maven, it is possible to fall into a problem: A Qux project is depending on Foo, and also Bar:2.0 (and it cannot use Bar:1.0 because Qux needs to use new feature in Bar:2.0). Here is the dilemma: should Qux use Bar:1.0 (which Qux's code will not work) or Bar:2.0 (which Foo's code will not work)?

            In order to solve this problem, developer of Foo can choose to use shade plugin to rename its usage of Bar, so that all classes in Bar:1.0 jar are embedded in Foo jar, and the package of the embedded Bar classes is changed from com.bar to com.foo.bar. By doing so, Qux can safely depends on Bar:2.0 because now Foo is no longer depending on Bar, and it is using is own copy of "altered" Bar located in another package.

            posted on 2017-06-19 11:23 wythern 閱讀(278) 評論(0)  編輯 收藏 引用

            狠狠色丁香久久综合五月| 狠狠色噜噜色狠狠狠综合久久 | 久久一区二区三区免费| 99国内精品久久久久久久| 国产精品99久久久久久猫咪| 亚洲午夜福利精品久久| 午夜精品久久久久久久久| 久久夜色tv网站| 久久WWW免费人成一看片| 2020最新久久久视精品爱| 香蕉99久久国产综合精品宅男自| 亚洲精品乱码久久久久久| 亚洲国产精品婷婷久久| 中文精品99久久国产| 成人综合伊人五月婷久久| 色综合久久夜色精品国产| 一本久久久久久久| 亚洲精品tv久久久久久久久| 久久伊人中文无码| 岛国搬运www久久| 99久久久精品| 人妻少妇久久中文字幕| 99久久这里只精品国产免费| 久久国产成人| 99久久免费只有精品国产| 99久久精品国产高清一区二区| 欧美伊人久久大香线蕉综合| 久久中文字幕视频、最近更新 | 五月丁香综合激情六月久久| 久久精品国产WWW456C0M| 99久久精品九九亚洲精品| 99久久国产综合精品麻豆| 国产美女久久精品香蕉69| 久久久久久久人妻无码中文字幕爆| 超级97碰碰碰碰久久久久最新| 热综合一本伊人久久精品| 青青热久久国产久精品| 亚洲人成无码网站久久99热国产| 久久涩综合| 久久久久人妻一区二区三区| 久久综合亚洲色一区二区三区|