Re: [VOTE] Release Apache Wagon version 3.3.4
+1 On Mon, 4 Nov 2019 at 06:04, Hervé BOUTEMY wrote: > Hi, > > We solved 5 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122&version=12345956&styleName=Text > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20WAGON%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-1535/ > > https://repository.apache.org/content/repositories/maven-1535/org/apache/maven/wagon/wagon/3.3.4/wagon-3.3.4-source-release.zip > > Source release checksum(s): > wagon-3.3.4-source-release.zip sha512: > 1484d17bede842ed45ae3642ccb12f585489a95604fd100a4fddea05e39b0d0471a3d878c8252cc2a29fcdc4f3d2ec0dd25629842ea4443d7557e488b0f3c25f > > Staging site: > https://maven.apache.org/wagon-archives/wagon-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 > > -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: last review of Reproducible Builds proposal
Hi, > but the format of the timestamp is completely different ... doesn't that > matter? I don't think so; at least I don't think the Bnd-LastModified header is meant to be parsed by machines. But I have _removeheaders>Bnd-* (yes, wildcards are supported) in my , so what do I know... > I was currently going for the option number 1 with removing the header. > > In order to be 100% happy with this, I would prefer a setup where the normal > mechanisms are used if no maven.build.outputTimestap is defined, but if it is > (because a future version of the maven release plugin set it there) it uses > that. You could use a that is activated when maven.build.outputTimestap is defined (or not defined) to implement this behavior. I haven't tested this, however. Best wishes, Andreas signature.asc Description: OpenPGP digital signature
AW: last review of Reproducible Builds proposal
Hi all,
And I might want to add, that includes pom, jar, sources jar, javadoc,
release-asembly and fat-jars ...
Currently applying these changes to other apache projects as an experiment.
So is anyone already working on the release plugin?
Chris
Von: Christofer Dutz
Gesendet: Montag, 4. November 2019 18:58:10
An: Maven Developers List
Betreff: Re: last review of Reproducible Builds proposal
Hi all,
so today I made sure the LastModified and the Creator username are omitted and
now the Apache PLC4X build had a 100% reproducible build (at least on my one
machine) ... will be checking this out on other machines.
Chris
Am 04.11.19, 10:12 schrieb "Christofer Dutz" :
Hi Andreas,
but the format of the timestamp is completely different ... doesn't that
matter?
I was currently going for the option number 1 with removing the header.
In order to be 100% happy with this, I would prefer a setup where the
normal mechanisms are used if no maven.build.outputTimestap is defined, but if
it is (because a future version of the maven release plugin set it there) it
uses that.
Will try out your suggestions as soon as I'm able to build again (I
unfortunately installed that Mac OS update ... now things aren't working as
they should be)
Chris
Am 04.11.19, 09:42 schrieb "Andreas Sewe"
:
Christofer Dutz wrote:
> Well I have a new candidate:
>
> maven-bundle-plugin
>
> Creates: Bnd-LastModified in the MANIFEST.MF
>
> Gotta find out a way to either suppress that entry (Would be great if
it could consume the same property)
<_removeheaders>Bnd-LastModified
Alternatively
${maven.build.outputTimestap}
Re: last review of Reproducible Builds proposal
Hi all,
so today I made sure the LastModified and the Creator username are omitted and
now the Apache PLC4X build had a 100% reproducible build (at least on my one
machine) ... will be checking this out on other machines.
Chris
Am 04.11.19, 10:12 schrieb "Christofer Dutz" :
Hi Andreas,
but the format of the timestamp is completely different ... doesn't that
matter?
I was currently going for the option number 1 with removing the header.
In order to be 100% happy with this, I would prefer a setup where the
normal mechanisms are used if no maven.build.outputTimestap is defined, but if
it is (because a future version of the maven release plugin set it there) it
uses that.
Will try out your suggestions as soon as I'm able to build again (I
unfortunately installed that Mac OS update ... now things aren't working as
they should be)
Chris
Am 04.11.19, 09:42 schrieb "Andreas Sewe"
:
Christofer Dutz wrote:
> Well I have a new candidate:
>
> maven-bundle-plugin
>
> Creates: Bnd-LastModified in the MANIFEST.MF
>
> Gotta find out a way to either suppress that entry (Would be great if
it could consume the same property)
<_removeheaders>Bnd-LastModified
Alternatively
${maven.build.outputTimestap}
Re: ***UNCHECKED*** Re: Hard requirements
Thanks. I've rewritten the PR under the assumption that all version
ranges are "hard". Please take another look. (PTAL)
On Fri, Nov 1, 2019 at 7:54 PM Stephen Connolly
wrote:
>
> 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
--
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: last review of Reproducible Builds proposal
Hi Andreas,
but the format of the timestamp is completely different ... doesn't that matter?
I was currently going for the option number 1 with removing the header.
In order to be 100% happy with this, I would prefer a setup where the normal
mechanisms are used if no maven.build.outputTimestap is defined, but if it is
(because a future version of the maven release plugin set it there) it uses
that.
Will try out your suggestions as soon as I'm able to build again (I
unfortunately installed that Mac OS update ... now things aren't working as
they should be)
Chris
Am 04.11.19, 09:42 schrieb "Andreas Sewe" :
Christofer Dutz wrote:
> Well I have a new candidate:
>
> maven-bundle-plugin
>
> Creates: Bnd-LastModified in the MANIFEST.MF
>
> Gotta find out a way to either suppress that entry (Would be great if it
could consume the same property)
<_removeheaders>Bnd-LastModified
Alternatively
${maven.build.outputTimestap}
Re: last review of Reproducible Builds proposal
Christofer Dutz wrote:
> Well I have a new candidate:
>
> maven-bundle-plugin
>
> Creates: Bnd-LastModified in the MANIFEST.MF
>
> Gotta find out a way to either suppress that entry (Would be great if it
> could consume the same property)
<_removeheaders>Bnd-LastModified
Alternatively
${maven.build.outputTimestap}
