You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Michael Osipov (JIRA)" <ji...@apache.org> on 2017/02/13 12:13:41 UTC

[jira] [Updated] (MSHADE-249) Consistent dates in the jar entries

     [ https://issues.apache.org/jira/browse/MSHADE-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Osipov updated MSHADE-249:
----------------------------------
    Description: 
Nowadays, Java developers often create Docker images attaching the uberjar or collections of jars to the docker image. However, these jars are time dependant. In other words, each time you create a jar, it has a different hash even though the code is actually the same. This feature leads to the creation of multiple docker image for the same code, significantly increasing the deploy time.

The two reasons that makes the different hashes are:
1. jar entries contains the creation timestamp in at least the last modified attribute. 
2. each uberjar usually contains an automatically generated property file with a timestamp located in {{META-INF/maven/$\{package}/pom.properties}}  

The goal of this feature is to solve the first problem giving a consistent date to all the jar entries.

I take the liberty of create a github repository with the suggested change in the plugin to accomplish this feature https://github.com/javiersigler/apache-maven-shade-plugin 

In addition, you could find in the repository a solution of the second problem.

I hope you could find it useful.

Thank you in advance.



  was:
Nowadays, Java developers often create Docker images attaching the uberjar or collections of jars to the docker image. However, these jars are time dependant. In other words, each time you create a jar, it has a different hash even though the code is actually the same. This feature leads to the creation of multiple docker image for the same code, significantly increasing the deploy time.

The two reasons that makes the different hashes are:
1. jar entries contains the creation timestamp in at least the last modified attribute. 
2. each uberjar usually contains an automatically generated property file with a timestamp located in META-INF/maven/${package}/pom.properties  

The goal of this feature is to solve the first problem giving a consistent date to all the jar entries.

I take the liberty of create a github repository with the suggested change in the plugin to accomplish this feature https://github.com/javiersigler/apache-maven-shade-plugin 

In addition, you could find in the repository a solution of the second problem.

I hope you could find it useful.

Thank you in advance.




> Consistent dates in the jar entries
> -----------------------------------
>
>                 Key: MSHADE-249
>                 URL: https://issues.apache.org/jira/browse/MSHADE-249
>             Project: Maven Shade Plugin
>          Issue Type: New Feature
>            Reporter: Javier Sigler
>
> Nowadays, Java developers often create Docker images attaching the uberjar or collections of jars to the docker image. However, these jars are time dependant. In other words, each time you create a jar, it has a different hash even though the code is actually the same. This feature leads to the creation of multiple docker image for the same code, significantly increasing the deploy time.
> The two reasons that makes the different hashes are:
> 1. jar entries contains the creation timestamp in at least the last modified attribute. 
> 2. each uberjar usually contains an automatically generated property file with a timestamp located in {{META-INF/maven/$\{package}/pom.properties}}  
> The goal of this feature is to solve the first problem giving a consistent date to all the jar entries.
> I take the liberty of create a github repository with the suggested change in the plugin to accomplish this feature https://github.com/javiersigler/apache-maven-shade-plugin 
> In addition, you could find in the repository a solution of the second problem.
> I hope you could find it useful.
> Thank you in advance.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)