Re: ***UNCHECKED*** Re: Hard requirements
On Fri 1 Nov 2019 at 21:37, Elliotte Rusty Harold
wrote:
> Pass 1:
> https://github.com/apache/maven-site/compare/master...elharo:patch-34
>
> This might not be accurate. In particular I am assuming that if there
> are two requirements for [1.0,2.0] and (3.0,5.0) that something will
> be picked.
If the same dependency is pulled into the tree in different places and the
intersection of ranges is an empty set then the build fails.
This might not be accurate. If this instead fails the
> build, please let me know. Comments are probably most convenient on
> the PR. Thanks all.
>
> *** {Dependency Version Requirement Specification}
>
> Dependencies' <<>> elements define version requirements,
> which are used to compute effective dependency
> versions. Version requirements have the following syntax:
>
> * <<<1.0>>>: "Soft" requirement on 1.0. Use 1.0 if no other version
> appears earlier in the dependency tree.
>
> * <<<[1.0]>>>: "Hard" requirement on 1.0. Use 1.0 and only 1.0, even
> if other versions come before this dependency in
> the tree. If multiple hard versions conflict, fail the build.
>
> * <<<(,1.0]>>>: Soft requirement on any version \<= 1.0
>
> * <<<[1.2,1.3]>>>: Soft requirement on any version between 1.2 and
> 1.3 inclusive.
>
> * <<<[1.0,2.0)>>>: 1.0 \<= x \< 2.0; soft requirement on any version
> between 1.0 inclusive and 2.0 exclusive.
>
> * <<<[1.5,)>>>: Soft requirement on any version greater than or equal to
> 1.5.
>
> * <<<(,1.0],[1.2,)>>>: Soft requirement on any version less than or
> equal to 1.0 than or greater than
> or equal to 1.2, but not 1.1. Multiple requirements are comma-separated
>
> * <<<(,1.1),(1.1,)>>>: Soft requirement on any version except 1.1;
> for example because
> it is known not to have a critical vulnerability.
>
>
> On Fri, Oct 25, 2019 at 4:43 PM Stephen Connolly
> wrote:
> >
> > On Tue 22 Oct 2019 at 11:30, Elliotte Rusty Harold
> > wrote:
> >
> > > The docs at
> > >
> https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification
> > > say:
> > >
> > > 1.0: "Soft" requirement on 1.0 (just a recommendation, if it matches
> > > all other ranges for the dependency)
> > > [1.0]: "Hard" requirement on 1.0
> > >
> > > However, I don't think anywhere do we actually explain what a soft or
> > > a "Hard" requirement is. If someone can clarify this for me, I'll
> > > update the docs accordingly.
> > >
> >
> > Ranges only come into affect when you have multiple dependencies using
> > ranges.
> >
> > When you use ranges, Maven tries to satisfy all the requests.
> >
> > A soft version is like: “I’d like this if I can have it”
> >
> > A hard version is: “only this or die”
> >
> > If your dependency tree has dependency foo being brought in by multiple
> > dependencies:
> >
> > Maven first gets the intersection of all ranges
> >
> > If there is more than one version left in the intersection, Maven looks
> at
> > the “nearest” soft version requests and if that fits the range it will
> use
> > that.
> >
> > If your range is just a single version, that means only that version will
> > do, hence it becomes a hard specification.
> >
> > Now having said all that, ranges have - to date - proven problematic. In
> > general it is better to avoid ranges at all... and that includes hard
> > version numbers.
> >
> > Hopefully in Maven 5.0.0 we can find a way to make ranges at least
> > usable... but the reality is ranges are a hard problem in and if
> themselves.
> >
> > >
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elh...@ibiblio.org
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > > --
> > Sent from my phone
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone
***UNCHECKED*** Re: Hard requirements
Pass 1: https://github.com/apache/maven-site/compare/master...elharo:patch-34
This might not be accurate. In particular I am assuming that if there
are two requirements for [1.0,2.0] and (3.0,5.0) that something will
be picked. This might not be accurate. If this instead fails the
build, please let me know. Comments are probably most convenient on
the PR. Thanks all.
*** {Dependency Version Requirement Specification}
Dependencies' <<>> elements define version requirements,
which are used to compute effective dependency
versions. Version requirements have the following syntax:
* <<<1.0>>>: "Soft" requirement on 1.0. Use 1.0 if no other version
appears earlier in the dependency tree.
* <<<[1.0]>>>: "Hard" requirement on 1.0. Use 1.0 and only 1.0, even
if other versions come before this dependency in
the tree. If multiple hard versions conflict, fail the build.
* <<<(,1.0]>>>: Soft requirement on any version \<= 1.0
* <<<[1.2,1.3]>>>: Soft requirement on any version between 1.2 and
1.3 inclusive.
* <<<[1.0,2.0)>>>: 1.0 \<= x \< 2.0; soft requirement on any version
between 1.0 inclusive and 2.0 exclusive.
* <<<[1.5,)>>>: Soft requirement on any version greater than or equal to 1.5.
* <<<(,1.0],[1.2,)>>>: Soft requirement on any version less than or
equal to 1.0 than or greater than
or equal to 1.2, but not 1.1. Multiple requirements are comma-separated
* <<<(,1.1),(1.1,)>>>: Soft requirement on any version except 1.1;
for example because
it is known not to have a critical vulnerability.
On Fri, Oct 25, 2019 at 4:43 PM Stephen Connolly
wrote:
>
> On Tue 22 Oct 2019 at 11:30, Elliotte Rusty Harold
> wrote:
>
> > The docs at
> > https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification
> > say:
> >
> > 1.0: "Soft" requirement on 1.0 (just a recommendation, if it matches
> > all other ranges for the dependency)
> > [1.0]: "Hard" requirement on 1.0
> >
> > However, I don't think anywhere do we actually explain what a soft or
> > a "Hard" requirement is. If someone can clarify this for me, I'll
> > update the docs accordingly.
> >
>
> Ranges only come into affect when you have multiple dependencies using
> ranges.
>
> When you use ranges, Maven tries to satisfy all the requests.
>
> A soft version is like: “I’d like this if I can have it”
>
> A hard version is: “only this or die”
>
> If your dependency tree has dependency foo being brought in by multiple
> dependencies:
>
> Maven first gets the intersection of all ranges
>
> If there is more than one version left in the intersection, Maven looks at
> the “nearest” soft version requests and if that fits the range it will use
> that.
>
> If your range is just a single version, that means only that version will
> do, hence it becomes a hard specification.
>
> Now having said all that, ranges have - to date - proven problematic. In
> general it is better to avoid ranges at all... and that includes hard
> version numbers.
>
> Hopefully in Maven 5.0.0 we can find a way to make ranges at least
> usable... but the reality is ranges are a hard problem in and if themselves.
>
> >
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > --
> Sent from my phone
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0
0: from me. The reason is that we did not reach the consensus that we would also have the benefits when the sources in Maven Core would be converted to J8 including performed some performance tests. On Tue, Oct 29, 2019 at 9:11 PM Karl Heinz Marbaise wrote: > Hi to all, > > based on the discusion this is the formal VOTE to lift the minimum of > Maven Core with version 3.7.0 to JDK 8 minimum. > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > > Kind regards > Karl Heinz Marbaise > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Release Apache Maven Assembly Plugin version 3.2.0
Hi, tested. +1 from me. Kind regards Karl Heinz Marbaise On 29.10.19 23:10, Hervé BOUTEMY wrote: Hi, We solved 9 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317220=12344773=Text Staging repo: https://repository.apache.org/content/repositories/maven-1534/ https://repository.apache.org/content/repositories/maven-1534/org/apache/maven/plugins/maven-assembly-plugin/3.2.0/maven-assembly-plugin-3.2.0-source-release.zip Source release checksum(s): maven-assembly-plugin-3.2.0-source-release.zip sha512: 23c1c79c51279232efc8dbeb697a6357257263c03356732d94b06f26ce219f44e650910ec7deb2ca8889449e669d40c47f7717ab6c1fb1e5ea6572cf643a5926 Staging site: https://maven.apache.org/plugins-archives/maven-assembly-plugin-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Vote open for at least 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0
+1 On Tue, Oct 29, 2019 at 10:11 PM Karl Heinz Marbaise wrote: > Hi to all, > > based on the discusion this is the formal VOTE to lift the minimum of > Maven Core with version 3.7.0 to JDK 8 minimum. > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > > Kind regards > Karl Heinz Marbaise > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: last review of Reproducible Builds proposal
Hi, so I just updated the versions of the 3 plugins and gave the Apache PLC4X build a little spin ... https://github.com/apache/plc4x/tree/feature/reproducible-builds Did two executions of this: mvn -U -P with-boost,with-java,with-dotnet,with-cpp,with-python,with-proxies,with-sandbox,with -DaltDeploymentRepository=snapshot-repo::default::file:./local-snapshots-dir clean deploy (but with a different second local repo location) Then I used "diff" and "cmp" to compare individual files and it didn't show differences with the artifacts I chose ... now I guess I'll have to whip up some little bash script to sort of compare the artifacts from one directory with the other (Unfortunately the SNAPSHOT timestamps are a little annoying :-/ We do have some C++, C# and Python modules ... but I wouldn't expect the C++ and C# to be reproducible. Chris Am 01.11.19, 12:04 schrieb "Hervé BOUTEMY" : Le vendredi 1 novembre 2019, 09:40:40 CET Christofer Dutz a écrit : > Hi Herve, > > thanks for that will try it asap and report any findings back. > > But good to know that there is a difference between JDK major versions and > OSes ... so it would probably be best to stage releases on Linux with an > OpenJDK of the minimum supported version? > Just thinking how to make it > possible to verify without having to buy Mac or Windows licenses ... guess > on every machine you could whip up a Ubuntu VM for verification. Just > thinking about it ... perhaps it would be best to create a Docker image for > doing the reproducible stuff ... just to be clear: the difference is on newline only, then Windows vs anything else. You get the same result on Linux, MacOS, FreeBSD, or any other Unix. And if I want to be complete, if you get a source tarball from Windows, extract it to a Linux/MacOS/... box and build with "mvn - Dline.separator='\r\n'", in general, you get the same result as a build under Windows: I tested multiple times, it worked, but we'll see if it works always or just "in general" > Are there any plans on creating a plugin to allow verification? > > Sort of something like this: > "mvn package release:verify-reproduicble > -DstagingRepoUrl=a.b.c.de/repo/blahblahblah" > (Which doesn't deploy the > artifacts, but instead download them and do a binary comparison) yes, but for now it was completely another form: this is the "Buildinfo file" proposal https://reproducible-builds.org/docs/jvm/ that I stopped to work on 1 year ago given I had no chance to get the same output: it's now a good time to restart working on it as next steps > Also it could be great if the release-plugin could automatically set the > property: > a) if it finds the "project.build.outputTimestamp" set to some > placeholder value b) if some switch tells it to prepare a reproducible > build by using some sort of "switch" parameter > Guess that would sort of close the loop to get the biggest benefit out of > the reproducible builds. +1 issue has been created https://issues.apache.org/jira/browse/MRELEASE-1029 But I didn't work on it yet, help welcome > I would be happy to help as I think this is one > of the greatest new features. (Ok ... perhaps besides the > sound-output-extension I learned about yesterday ;-) ) +1 the current step is important, but it's only the beginning of the story from an effective usage perspective Regards, Hervé > > Chris > > > Am 01.11.19, 09:24 schrieb "Hervé BOUTEMY" : > > Le jeudi 31 octobre 2019, 17:26:52 CET Christofer Dutz a écrit : > > > Hi all, > > > > as I can see you're voting on releasing the reproducible build > > extended > > plugin versions. > > Is there any documentation on how to use this new > > > feature? > > > > I had a look at the confluence page, but that seemed like a > > brainstorming > > session. > > ok, the Wiki page [1] started as a brainstorming session, was updated to > a proposal (the "Output Archive Entries Timestamp" parapgraph). And now I > probably should order paragraph a little bit, and add a "Making your build > reproducible" section for end uses to have a quick explanation. > I'll write the explanation here as a first try before working on the > Wiki: > 1. upgrade your plugins to reproducible version, particularly > mpaven-source-plugin, maven-jar-plugin and maven-assembly-plugin to vesion > 3.2.0 2. add project.build.outputTimestamp property with the timestamp > value that will be used in zip/jar/tar archives: > > 2019-10-02T08:04:00Z mestamp> > > Notice: > - there is no
Re: last review of Reproducible Builds proposal
please provide an example of a visible issue so we can work on it Regards, Hervé Le vendredi 1 novembre 2019, 10:27:36 CET Vladimir Sitnikov a écrit : > OpenJDK8 uses hashmap for manifest entries, so jar files are not really > reproducible there. > > Note: there's run-to-run randomization in j.u.HashMap, so the manifest > contents is not predictable. > > Vladimir - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: last review of Reproducible Builds proposal
Le vendredi 1 novembre 2019, 09:40:40 CET Christofer Dutz a écrit : > Hi Herve, > > thanks for that will try it asap and report any findings back. > > But good to know that there is a difference between JDK major versions and > OSes ... so it would probably be best to stage releases on Linux with an > OpenJDK of the minimum supported version? > Just thinking how to make it > possible to verify without having to buy Mac or Windows licenses ... guess > on every machine you could whip up a Ubuntu VM for verification. Just > thinking about it ... perhaps it would be best to create a Docker image for > doing the reproducible stuff ... just to be clear: the difference is on newline only, then Windows vs anything else. You get the same result on Linux, MacOS, FreeBSD, or any other Unix. And if I want to be complete, if you get a source tarball from Windows, extract it to a Linux/MacOS/... box and build with "mvn - Dline.separator='\r\n'", in general, you get the same result as a build under Windows: I tested multiple times, it worked, but we'll see if it works always or just "in general" > Are there any plans on creating a plugin to allow verification? > > Sort of something like this: > "mvn package release:verify-reproduicble > -DstagingRepoUrl=a.b.c.de/repo/blahblahblah" > (Which doesn't deploy the > artifacts, but instead download them and do a binary comparison) yes, but for now it was completely another form: this is the "Buildinfo file" proposal https://reproducible-builds.org/docs/jvm/ that I stopped to work on 1 year ago given I had no chance to get the same output: it's now a good time to restart working on it as next steps > Also it could be great if the release-plugin could automatically set the > property: > a) if it finds the "project.build.outputTimestamp" set to some > placeholder value b) if some switch tells it to prepare a reproducible > build by using some sort of "switch" parameter > Guess that would sort of close the loop to get the biggest benefit out of > the reproducible builds. +1 issue has been created https://issues.apache.org/jira/browse/MRELEASE-1029 But I didn't work on it yet, help welcome > I would be happy to help as I think this is one > of the greatest new features. (Ok ... perhaps besides the > sound-output-extension I learned about yesterday ;-) ) +1 the current step is important, but it's only the beginning of the story from an effective usage perspective Regards, Hervé > > Chris > > > Am 01.11.19, 09:24 schrieb "Hervé BOUTEMY" : > > Le jeudi 31 octobre 2019, 17:26:52 CET Christofer Dutz a écrit : > > > Hi all, > > > > as I can see you're voting on releasing the reproducible build > > extended > > plugin versions. > > Is there any documentation on how to use this new > > > feature? > > > > I had a look at the confluence page, but that seemed like a > > brainstorming > > session. > > ok, the Wiki page [1] started as a brainstorming session, was updated to > a proposal (the "Output Archive Entries Timestamp" parapgraph). And now I > probably should order paragraph a little bit, and add a "Making your build > reproducible" section for end uses to have a quick explanation. > I'll write the explanation here as a first try before working on the > Wiki: > 1. upgrade your plugins to reproducible version, particularly > mpaven-source-plugin, maven-jar-plugin and maven-assembly-plugin to vesion > 3.2.0 2. add project.build.outputTimestamp property with the timestamp > value that will be used in zip/jar/tar archives: > > 2019-10-02T08:04:00Z mestamp> > > Notice: > - there is no Maven version prerequisite, everything happens at plugins > level - Reproducible Builds require to have no version ranges in > dependencies, generally gives different result on Unixes vs Windows, and > generally depend on the major version of JDK used to compile (see "Out of > Scope" paragraph) > You have the basis configured, the output should be reproducible now. > If something is still not reproducible, use diffoscope to find the > unstable output, find the plugin that generated this output and check if > there is a reproducible version available: if not, please open an issue to > help plugin maintainers improving Reproducible Builds support at every > plugin level. > [1] > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318 > > > > > I would love to add this to the PLC4X build asap. > > I'd love to have feedback > Don't hesitate to ping me. > > > > > So I would like to test the release-candidates and vote too. > > I would love to have many tester and votes :) > > > > > > Chris > > > > > > > > Am 16.10.19, 14:42 schrieb "Hervé BOUTEMY" : > > > > > > Le mercredi 16 octobre 2019, 13:40:48 CEST Andreas Sewe a écrit : > > > > > > > > >
Re: last review of Reproducible Builds proposal
OpenJDK8 uses hashmap for manifest entries, so jar files are not really reproducible there. Note: there's run-to-run randomization in j.u.HashMap, so the manifest contents is not predictable. Vladimir
Re: last review of Reproducible Builds proposal
Hi Herve, thanks for that will try it asap and report any findings back. But good to know that there is a difference between JDK major versions and OSes ... so it would probably be best to stage releases on Linux with an OpenJDK of the minimum supported version? Just thinking how to make it possible to verify without having to buy Mac or Windows licenses ... guess on every machine you could whip up a Ubuntu VM for verification. Just thinking about it ... perhaps it would be best to create a Docker image for doing the reproducible stuff ... Are there any plans on creating a plugin to allow verification? Sort of something like this: "mvn package release:verify-reproduicble -DstagingRepoUrl=a.b.c.de/repo/blahblahblah" (Which doesn't deploy the artifacts, but instead download them and do a binary comparison) Also it could be great if the release-plugin could automatically set the property: a) if it finds the "project.build.outputTimestamp" set to some placeholder value b) if some switch tells it to prepare a reproducible build by using some sort of "switch" parameter Guess that would sort of close the loop to get the biggest benefit out of the reproducible builds. I would be happy to help as I think this is one of the greatest new features. (Ok ... perhaps besides the sound-output-extension I learned about yesterday ;-) ) Chris Am 01.11.19, 09:24 schrieb "Hervé BOUTEMY" : Le jeudi 31 octobre 2019, 17:26:52 CET Christofer Dutz a écrit : > Hi all, > > as I can see you're voting on releasing the reproducible build extended > plugin versions. Is there any documentation on how to use this new > feature? > > I had a look at the confluence page, but that seemed like a brainstorming > session. ok, the Wiki page [1] started as a brainstorming session, was updated to a proposal (the "Output Archive Entries Timestamp" parapgraph). And now I probably should order paragraph a little bit, and add a "Making your build reproducible" section for end uses to have a quick explanation. I'll write the explanation here as a first try before working on the Wiki: 1. upgrade your plugins to reproducible version, particularly mpaven-source-plugin, maven-jar-plugin and maven-assembly-plugin to vesion 3.2.0 2. add project.build.outputTimestamp property with the timestamp value that will be used in zip/jar/tar archives: 2019-10-02T08:04:00Z Notice: - there is no Maven version prerequisite, everything happens at plugins level - Reproducible Builds require to have no version ranges in dependencies, generally gives different result on Unixes vs Windows, and generally depend on the major version of JDK used to compile (see "Out of Scope" paragraph) You have the basis configured, the output should be reproducible now. If something is still not reproducible, use diffoscope to find the unstable output, find the plugin that generated this output and check if there is a reproducible version available: if not, please open an issue to help plugin maintainers improving Reproducible Builds support at every plugin level. [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318 > I would love to add this to the PLC4X build asap. I'd love to have feedback Don't hesitate to ping me. > > So I would like to test the release-candidates and vote too. I would love to have many tester and votes :) > > Chris > > > > Am 16.10.19, 14:42 schrieb "Hervé BOUTEMY" : > > Le mercredi 16 octobre 2019, 13:40:48 CEST Andreas Sewe a écrit : > > > Emmanuel Bourg wrote: > > > > > Le 16/10/2019 à 08:35, Hervé BOUTEMY a écrit : > > > > > >> last question: now that we seem to fully understand each other, > > >> does it > > >> mean that you don't need any more "seconds since the epoch" format > > >> support for the property? > > > > > > > > > If Maven supports the SOURCE_DATE_EPOCH environment variable I > > > don't > > > think that's necessary, otherwise it would be nice to be able to > > > invoke > > > > > > Maven with: > > > > > >mvn package -Dproject.build.outputTimestamp=$SOURCE_DATE_EPOCH > > > > > > > > > and this means supporting a timestamp formatted as seconds since > > > the > > > epoch. > > > > > > +1 > > > > The above would be a nice, simple way of bridging the gap between > > SOURCE_DATE_EPOCH and project.build.outputTimestamp. > > told like that, ok, why not > > > > > > If it is not too much trouble to implement the "\d+ -> seconds since > > epoch" heuristic, them I would love to see it
Re: [VOTE] Release Apache Maven Source Plugin version 3.2.0
here is my +1 Regards, Hervé Le mardi 29 octobre 2019, 22:44:17 CET Hervé BOUTEMY a écrit : > Hi, > > We solved 2 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317924& > ersion=12345522=Text > > Staging repo: > https://repository.apache.org/content/repositories/maven-1532/ > https://repository.apache.org/content/repositories/maven-1532/org/apache/mav > en/plugins/maven-source-plugin/3.2.0/maven-source-plugin-3.2.0-source-releas > e.zip > > Source release checksum(s): > maven-source-plugin-3.2.0-source-release.zip sha512: > 2321599d28affd25b2821a14182383a1a3a31bb33344fae395805d3173e9cdcfd2b1c09608e > 73a160f054f9086ad56f2b11f4fe56117fddb34356d1b8e935780 > > Staging site: > https://maven.apache.org/plugins-archives/maven-source-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Assembly Plugin version 3.2.0
Here is my +1 Sylwester pt., 1 lis 2019, 09:26 użytkownik Hervé BOUTEMY napisał: > Hi, > > I need some votes on this one, in addition to the 2 others :) > > Regards, > > Hervé > > Le mardi 29 octobre 2019, 23:10:46 CET Hervé BOUTEMY a écrit : > > Hi, > > > > We solved 9 issues: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317220 > > rsion=12344773=Text > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-1534/ > > > https://repository.apache.org/content/repositories/maven-1534/org/apache/mav > > > en/plugins/maven-assembly-plugin/3.2.0/maven-assembly-plugin-3.2.0-source-re > > lease.zip > > > > Source release checksum(s): > > maven-assembly-plugin-3.2.0-source-release.zip sha512: > > > 23c1c79c51279232efc8dbeb697a6357257263c03356732d94b06f26ce219f44e650910ec7d > > eb2ca8889449e669d40c47f7717ab6c1fb1e5ea6572cf643a5926 > > > > Staging site: > > https://maven.apache.org/plugins-archives/maven-assembly-plugin-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for at least 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Release Apache Maven JAR Plugin version Y.Z
here is my +1 Regards, Hervé Le mardi 29 octobre 2019, 22:55:56 CET Hervé BOUTEMY a écrit : > Hi, > > We solved 1 issue: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317526 > rsion=12345503=Text > > Staging repo: > https://repository.apache.org/content/repositories/maven-1533/ > https://repository.apache.org/content/repositories/maven-1533/org/apache/mav > en/plugins/maven-jar-plugin/3.2.0/maven-jar-plugin-3.2.0-source-release.zip > > Source release checksum(s): > maven-jar-plugin-3.2.0-source-release.zip sha512: > b84da749dd6ca3a58173ad060a7406bee48ea02d78bc638fcc404c1c31c7c466d5d33890ab5 > 49a4edd99efcfebb8926a7955d647a398968c2b1c44393a3bef43 > > Staging site: > https://maven.apache.org/plugins-archives/maven-jar-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Assembly Plugin version 3.2.0
Hi, I need some votes on this one, in addition to the 2 others :) Regards, Hervé Le mardi 29 octobre 2019, 23:10:46 CET Hervé BOUTEMY a écrit : > Hi, > > We solved 9 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317220 > rsion=12344773=Text > > Staging repo: > https://repository.apache.org/content/repositories/maven-1534/ > https://repository.apache.org/content/repositories/maven-1534/org/apache/mav > en/plugins/maven-assembly-plugin/3.2.0/maven-assembly-plugin-3.2.0-source-re > lease.zip > > Source release checksum(s): > maven-assembly-plugin-3.2.0-source-release.zip sha512: > 23c1c79c51279232efc8dbeb697a6357257263c03356732d94b06f26ce219f44e650910ec7d > eb2ca8889449e669d40c47f7717ab6c1fb1e5ea6572cf643a5926 > > Staging site: > https://maven.apache.org/plugins-archives/maven-assembly-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: New link pattern when option is set to true
hi, Any update on this please? Is this mail group actively monitored? or should I raise a pull request directly to the project? Max On Mon, Oct 28, 2019 at 6:12 PM Max Zhu wrote: > For what's worth I am talking about maven-javadoc-plugin (just realized > this is the main maven mail group) > > On Sat, Oct 26, 2019 at 6:51 PM Max Zhu wrote: > >> hi, >> >> Wondering if it makes sense to extend option to javadoc.io. >> >> For example, google gson (https://github.com/google/gson) has pointed >> their javadoc to https://www.javadoc.io/doc/com.google.code.gson/gson on >> their README.md. But currently, maven-javadoc-plugin will only try to fetch >> https://github.com/google/gson/apidoc/package-list , which apparently is >> an invalid address. >> >> I am aware there is already on option to extend tag, but that's >> quite tedious as everytime we have to manually keep things in sync when we >> add / remove dependencies or change versions. >> >> There are quite a few popular libraries hosting javadoc with javadoc.io >> already (eg, mockito / spark), and the pattern is very simple as well: >> https://www.javadoc.io/doc/[group_id]/[artifact_id]/[version_id]/package-list >> >> Thus, it will be quite helpful if maven-javadoc-plugin can just >> automatically try this url pattern from the dependency list as well. >> >> Declaimer, I started javadoc.io about 5 years ago and now it's getting >> more trendy these days, so I would like to better support this project. >> >> Max >> >> >> Reference: >> https://github.com/apache/maven-javadoc-plugin/blob/b1c029f26c4dc40b29a0e122e5c42b294845acfd/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L6526 >> >> >
Re: last review of Reproducible Builds proposal
Le jeudi 31 octobre 2019, 17:26:52 CET Christofer Dutz a écrit : > Hi all, > > as I can see you're voting on releasing the reproducible build extended > plugin versions. Is there any documentation on how to use this new > feature? > > I had a look at the confluence page, but that seemed like a brainstorming > session. ok, the Wiki page [1] started as a brainstorming session, was updated to a proposal (the "Output Archive Entries Timestamp" parapgraph). And now I probably should order paragraph a little bit, and add a "Making your build reproducible" section for end uses to have a quick explanation. I'll write the explanation here as a first try before working on the Wiki: 1. upgrade your plugins to reproducible version, particularly mpaven-source-plugin, maven-jar-plugin and maven-assembly-plugin to vesion 3.2.0 2. add project.build.outputTimestamp property with the timestamp value that will be used in zip/jar/tar archives: 2019-10-02T08:04:00Z Notice: - there is no Maven version prerequisite, everything happens at plugins level - Reproducible Builds require to have no version ranges in dependencies, generally gives different result on Unixes vs Windows, and generally depend on the major version of JDK used to compile (see "Out of Scope" paragraph) You have the basis configured, the output should be reproducible now. If something is still not reproducible, use diffoscope to find the unstable output, find the plugin that generated this output and check if there is a reproducible version available: if not, please open an issue to help plugin maintainers improving Reproducible Builds support at every plugin level. [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318 > I would love to add this to the PLC4X build asap. I'd love to have feedback Don't hesitate to ping me. > > So I would like to test the release-candidates and vote too. I would love to have many tester and votes :) > > Chris > > > > Am 16.10.19, 14:42 schrieb "Hervé BOUTEMY" : > > Le mercredi 16 octobre 2019, 13:40:48 CEST Andreas Sewe a écrit : > > > Emmanuel Bourg wrote: > > > > > Le 16/10/2019 à 08:35, Hervé BOUTEMY a écrit : > > > > > >> last question: now that we seem to fully understand each other, > > >> does it > > >> mean that you don't need any more "seconds since the epoch" format > > >> support for the property? > > > > > > > > > If Maven supports the SOURCE_DATE_EPOCH environment variable I > > > don't > > > think that's necessary, otherwise it would be nice to be able to > > > invoke > > > > > > Maven with: > > > > > >mvn package -Dproject.build.outputTimestamp=$SOURCE_DATE_EPOCH > > > > > > > > > and this means supporting a timestamp formatted as seconds since > > > the > > > epoch. > > > > > > +1 > > > > The above would be a nice, simple way of bridging the gap between > > SOURCE_DATE_EPOCH and project.build.outputTimestamp. > > told like that, ok, why not > > > > > > If it is not too much trouble to implement the "\d+ -> seconds since > > epoch" heuristic, them I would love to see it included. > > ok, I'll do and prepare the release > > Regards, > > Hervé > > > > > > Best wishes, > > > > Andreas > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven JAR Plugin version Y.Z
+1 Sylwester czw., 31 paź 2019, 18:40 użytkownik Karl Heinz Marbaise napisał: > Hi Hervé, > > tested with serveral maven versions etc. > > Just fine. > > So +1 from me. > > Kind regards > Karl Heinz Marbaise > On 29.10.19 22:55, Hervé BOUTEMY wrote: > > Hi, > > > > We solved 1 issue: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317526=12345503=Text > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-1533/ > > > https://repository.apache.org/content/repositories/maven-1533/org/apache/maven/plugins/maven-jar-plugin/3.2.0/maven-jar-plugin-3.2.0-source-release.zip > > > > Source release checksum(s): > > maven-jar-plugin-3.2.0-source-release.zip sha512: > b84da749dd6ca3a58173ad060a7406bee48ea02d78bc638fcc404c1c31c7c466d5d33890ab549a4edd99efcfebb8926a7955d647a398968c2b1c44393a3bef43 > > > > Staging site: > > https://maven.apache.org/plugins-archives/maven-jar-plugin-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for at least 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Next Generation Integration Testing for Plugins/Core
Hi everyone, Yesterday I needed to test a maven plugin around graal so wrote a junit5 extension relying on testcontainers. Think it is close to this thread so sharing the idea/code: https://gitbox.apache.org/repos/asf?p=geronimo-arthur.git;a=blob;f=integration-test/src/test/java/org/apache/geronimo/arthur/integrationtests/MavenTest.java;h=4372204eaa24513b4c9ecaf6b4a17c22339892bc;hb=19d8c093008ca4c03ced1858aed0f884a60d7220 Le ven. 1 nov. 2019 à 01:08, Tibor Digana a écrit : > am, programming language is our toy ;-) > everybody has some preferences, so i respect them and i understand that > even the Lambda would be a big jump for us nevertheless the Groovy or > Kotlin. > i saw the parameterized tests, re-runs in Groovy, log result of assertion > statements, and I spoke with Benedikt and we agreed that Spock is very > special and we like it. > i do not want to push Karl. Maybe one advice is to think about the > programming approach where these annotations and code would be easily used > in another languages too. > that's basically all from my side. > > Enjoy! > > > On Thu, Oct 31, 2019 at 11:56 PM Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> wrote: > > > Karl>on the language features but since JDK8 I don't see any advantage > > > > What about Kotlin? > > > > There are nice things there: the language is statically compiled, great > > Java interop, there are extension functions, multiline strings, helpful > > standard library, default parameters. > > Kotlin is great for creating DSLs. > > > > It can be used with JUnit or other frameworks (e.g. > > https://github.com/kotlintest/kotlintest ) > > > > Vladimir > > >
