Re: last review of Reproducible Builds proposal

2019-10-08 Thread Mark Derricutt
On 6 Oct 2019, at 9:14, Hervé BOUTEMY wrote:

> if anybody cares about the exact value: but
> who really looks at the timestamp of entries in release zips/jars/tar.gz
> honestly?

I've actually done so in the past trying to find differences between two 
versions of a jar for repair reasons.

VERY infrequent tho - if you're wanting to generate a delta-patch between two 
jars/zips then I guess it might also be handy (altho you might be better off 
going direct for checksumdifferences  there ).


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature


Re: last review of Reproducible Builds proposal

2019-10-08 Thread Emmanuel Bourg
Le 07/10/2019 à 14:40, Andreas Sewe a écrit :

> - Can we get something analogous to maven.build.timestamp.format? One
> could then write the following to be compatible with env.SOURCE_DATE_EPOCH:
> 
> 
>   
> 
> ${env.SOURCE_DATE_EPOCH}
> 
> ...
>   
> 

+1, some kind of support for SOURCE_DATE_EPOCH would be nice. Either
this (but maybe with only one property supporting both formats) or by
overriding automatically the property when SOURCE_DATE_EPOCH is set.

Emmanuel Bourg

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



Re: Consumer pom, use a System property or a pom property ?

2019-10-08 Thread Enrico Olivelli
Il lun 7 ott 2019, 20:59 Robert Scholte  ha scritto:

> bq. I would like to use this feature when Maven 3.7.0 is out
>
> There's this interesting idea from Stephen to activate it by default,
> disabling it explicitly by setting the property to false.
>

Using it by default is good.

After thinking more about this 'flag' I do think that a system property is
fine, it will help transitions to the new way, but we should print out a
warning that in the future there will be no way to disable it

Enrico




> I did a Twitter poll, and the result after 100 responses was close to 50/50
>
> The more I think about it, the more I start to like the idea.
> In the past we've always been very careful with activating features, but
> why in this case?
> The whole idea here is that it should not break current poms. However, it
> is possible to remove a couple of elements and these will be added during
> *build* as if they were always there. The installed/deployed pom in based
> on this, minus a view build-specific elements.
>
> Btw, I discovered that I should take care of the LexicalHandler too, so
> there will be more commits and tests.
>
> Robert
>
> ps. thanks for the compliments. I hope it'll move the project forward!
>
> On Mon, 07 Oct 2019 07:52:48 +0200, Enrico Olivelli 
>
> wrote:
>
> > Hello,
> > Robert sent out a (great) patch than enables experimental support for the
> > consumer pom.
> >
> > This new way of working is enabled by a system property
> > -Dmaven.experimental.
> >
> > I would like to use this feature when Maven 3.7.0 is out, but it won't be
> > possible to use such a feature with a system property, as such system
> > property is to be configured in every build machine in order to be sure
> > that the build is consistent across all of the environments.
> >
> > What about having a simply "property" (in ) in the
> project
> > ?
> > I will set in on the parent of my hierarchy.
> > I see we cannot a a new xml tag/xml attribute, as it will be a change in
> > the version of the pom.
> >
> > As an alternative we could have a flag in Maven, to be activated by an
> > 'extension'
> >
> >
> > Thoughts
> >
> > Enrico
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>