MASSEMBLY-918 proposal

2019-08-18 Thread abrarov
4. Squash Docker image layers? This approach requires additional tool 
(https://github.com/jwilder/docker-squash requires sudo) and understanding of 
what layers to squash and what layers to keep as is (for optimization of Docker 
image delivery - some base layers are taken from image vendor and are not 
changed, so I need to keep them to avoid re-delivering of the whole Docker 
image). I'm not sure about impact of squashing of Docker layers on Docker build 
cache and on the whole time required for building (if TAR checksum didn't 
change then rebuilding of Docker image is faster due to Docker build cache).



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



RE: MASSEMBLY-918 proposal

2019-08-18 Thread abrarov
What can I do in that script?

1. Change owner in TAR created by Maven Assembly plugin - I need a tool for 
that (I failed to find one)
2. Change owner before packaging of TAR - I need root permissions (sudo) for 
that (I just want to add an entry into TAR with chosen owner / group - why 
should I run my build with escalated privileges?)
3. Change owner in Docker image created using TAR - it duplicates all impacted 
files / directories, i.e. increases Docker image size (refer to 
https://medium.com/@lmakarov/the-backlash-of-chmod-chown-mv-in-your-dockerfile-f12fe08c0b55)


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: MASSEMBLY-918 proposal

2019-08-18 Thread Enrico Olivelli
Can't you run some post package script with the maven exec plugin?


Enrico

Il ven 16 ago 2019, 19:55  ha scritto:

> Hi Enrico,
>
> Yes, I need just root:root for the task I described, but it doesn't look
> like correct (generic) solution to add just flag for the "root ownership",
> because its implementation looks as hard (easy for smbd) as adding
> possibility to specify both user and group.
>
> Marat.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


Re: Review - Maven Core - Resolver 1.4.1

2019-08-18 Thread Enrico Olivelli
+1

Enrico

Il dom 18 ago 2019, 17:25 Tibor Digana  ha scritto:

> Hi,
>
> There's a new branch MNG-6738 with new Resolver 1.4.1.
> If you have no objections, I will push it to master.
>
> https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=88b632cf3d727c7d003a8a36f1b39bffb2f790f3
>
> The build is running
> https://builds.apache.org/job/maven-box/job/maven/job/MNG-6738/
>
> Cheers
> Tibor
>


Review - Maven Core - Resolver 1.4.1

2019-08-18 Thread Tibor Digana
Hi,

There's a new branch MNG-6738 with new Resolver 1.4.1.
If you have no objections, I will push it to master.
https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=88b632cf3d727c7d003a8a36f1b39bffb2f790f3

The build is running
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6738/

Cheers
Tibor


[ANN] Apache Maven Resolver 1.4.1 released

2019-08-18 Thread Tibor Digana
The Apache Maven team is pleased to announce the release of the Maven
Resolver 1.4.1.

https://maven.apache.org/resolver/

Release Notes - Maven Resolver - Version 1.4.1

** Task
 * [MRESOLVER-92] - Revert MRESOLVER-7


Enjoy,

-The Apache Maven team


[RESULT] [VOTE] Release Apache Maven Resolver version 1.4.1

2019-08-18 Thread Tibor Digana
Hi,

The vote has passed with the following result:

+1 : Tamás Cservenák, Tibor Digana, Michael Osipov, Sylwester Lachiewicz,
Olivier Lamy
  0 : none
-1 : none.

PMC quorum: accomplished.

I will promote the artifacts to the central repo.

Kind regards
Tibor17


Re: [VOTE] Release Apache Maven Resolver version 1.4.1

2019-08-18 Thread Tibor Digana
Thx, the Vote has passed successfully.

On Sun, Aug 18, 2019 at 1:27 AM Olivier Lamy  wrote:

> +1
>
> On Thu, 15 Aug 2019 at 21:53, Tibor Digana  wrote:
>
> > Hi,
> >
> > We solved 1 issue:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12345950
> >
> > There are still a couple of issues left in JIRA:
> >
> >
> https://issues.apache.org/jira/i#issues/?jql=project+%3D+MRESOLVER+AND+status+%3D+Open+ORDER+BY+priority+DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1526
> >
> >
> https://repository.apache.org/content/repositories/maven-1526/org/apache/maven/resolver/maven-resolver/1.4.1/maven-resolver-1.4.1-source-release.zip
> >
> > Source release checksum(s):
> > maven-resolver-1.4.1-source-release.zip sha512:
> >
> >
> e90430f551513603b40de8401fec66998959c5e1744ccd1241228dec062334f51eb4395ef2c0afd9550d092017bf5431cc69985e8c410bd7e1d46c77fb50ffb0
> >
> > Staging site:
> >
> >
> https://svn.apache.org/repos/asf/maven/website/components/resolver-archives/resolver-LATEST
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>


Re: plugins share common repository on one Jenkins node

2019-08-18 Thread Enrico Olivelli
Il ven 16 ago 2019, 20:37 Tibor Digana  ha scritto:

> The builds on a Jenkins node should be isolated. The paths of local
> repository should be distinct. Therefore we used the trick with
> EXECUTOR_NUMBER:
>
>
> https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=blob;f=vars/asfMavenTlpPlgnBuild.groovy;h=e4576ac12e9dec73aee0540fa9aab37fd507d614;hb=HEAD#l150
>
> This is the path and wrong because it is not distinct!
> Local Repo (linux-jdk11-m3.6.x_build): ../.maven_repositories/null
>
> The problem is that the code is not serialized on the particular Jenkins
> node and executor.
> Thus we observed errors in Archetype builds when running integration tests
> via maven-invoker-plugin:
>
> [INFO] Building: build-and-run-its\pom.xml
> [INFO] run post-build script verify.groovy
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.codehaus.groovy.reflection.CachedClass
>
> (file:/F:/short/.maven_repositories/null/org/codehaus/groovy/groovy-all/2.4.8/groovy-all-2.4.8.jar)
> to method java.lang.Object.finalize()
>
> So I moved the code into the targeting execution block:
>
>
> https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=commitdiff;h=aee445426dac012af4326c0b80c93422200c2a56
>
> and the logs look promissing now:
>
> Local Repo (windows-jdk11-m3.6.x_build): ../.maven_repositories/0
> Local Repo (windows-jdk12-m3.6.x_build): ../.maven_repositories/1
> Local Repo (windows-jdk13-m3.6.x_build): ../.maven_repositories/2
>

Good catch!

Thank you Tibor

Enrico



> --
> Cheers
> Tibor
>