Hello,
Robert sent out a (great) patch to introduce support for the 'consumer' pom,
that is (if I understand correctly) a skinny pom that contains only useful
information for downstream 'consumers' of the pom (poms that depend on it).
This consumer pom feature is required in order to start thinkin
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 p
Le dimanche 6 octobre 2019, 22:18:59 CEST Emmanuel Bourg a écrit :
> Le 06/10/2019 à 20:13, Hervé BOUTEMY a écrit :
> > no, it does not add any dependency on developer configuration:
> > 2019-10-05T18:37:42Z == 2019-10-05T20:37:42+02:00 ==
> > 2019-10-05T16:37:42-02:00
> yes but:
>
> "2019-10-05T
Hi,
I thought it would help to merge some of the PR's..which are ready...
I will take a look within the next days and see if I could do a new
release...
Kidn regards
Karl Heinz Marbaise
On 06.10.19 22:43, Stephane Nicoll wrote:
I second that though I've seen some activity today, including a
Small reminder: if you want to be reproducible you must fix the timestamp
so whatever zone, whatever format works. It is common to use new Date(1000)
in utc but not important at the end.
Side note: same applies for most of the env though (locale for ex.).
Le dim. 6 oct. 2019 à 22:57, Tibor Digana
Hi Emmanuel,
>> The point is, two developers may generate a different pom if the local
timezone is used.
very well explained! It could not be better: utc time is the same however
the text is different and that's important for the stream identity.
Karl had a proposal with additional property "form
I second that though I've seen some activity today, including a fix that
allows the Spring Boot project to upgrade to Maven 3.6[1]. Looking forward
to a release of the plugin!
Thanks,
S.
[1] https://github.com/mojohaus/flatten-maven-plugin/issues/89
On Sun, Oct 6, 2019 at 11:52 AM Falko Modler
Le 06/10/2019 à 20:13, Hervé BOUTEMY a écrit :
> no, it does not add any dependency on developer configuration:
> 2019-10-05T18:37:42Z == 2019-10-05T20:37:42+02:00 == 2019-10-05T16:37:42-02:00
yes but:
"2019-10-05T18:37:42Z" != "2019-10-05T20:37:42+02:00" !=
"2019-10-05T16:37:42-02:00"
The poi
Am 2019-10-06 um 20:35 schrieb Hervé BOUTEMY:
Le dimanche 6 octobre 2019 20:29:46 CEST, vous avez écrit :
Am 2019-10-06 um 20:21 schrieb Hervé BOUTEMY:> Le dimanche 6 octobre
2019 12:24:57 CEST, vous avez écrit :
>> Am 2019-10-06 um 09:35 schrieb Hervé BOUTEMY:
>>> Le samedi 5 octobre 2019,
Am 2019-10-06 um 20:21 schrieb Hervé BOUTEMY:> Le dimanche 6 octobre
2019 12:24:57 CEST, vous avez écrit :
>> Am 2019-10-06 um 09:35 schrieb Hervé BOUTEMY:
>>> Le samedi 5 octobre 2019, 22:46:20 CEST Michael Osipov a écrit :
Am 2019-10-05 um 22:10 schrieb Hervé BOUTEMY:
> Le samedi 5 oct
Le dimanche 6 octobre 2019, 16:41:27 CEST Emmanuel Bourg a écrit :
> Le 06/10/2019 à 09:43, Hervé BOUTEMY a écrit :
> > Notice that you can also express a timezone (as digits), as seen in the
> > unit tests.
> I know but that's not desirable, otherwise the formatted timestamp would
> depend on the
Le dimanche 6 octobre 2019, 12:19:35 CEST Michael Osipov a écrit :
> Am 2019-10-05 um 23:15 schrieb Emmanuel Bourg:
> > Le 05/10/2019 à 19:52, Hervé BOUTEMY a écrit :
> >> based on the feedback I got, I updated the proposal:
> >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=7468
Le dimanche 6 octobre 2019, 16:41:27 CEST Emmanuel Bourg a écrit :
> Le 06/10/2019 à 09:43, Hervé BOUTEMY a écrit :
> > Notice that you can also express a timezone (as digits), as seen in the
> > unit tests.
> I know but that's not desirable, otherwise the formatted timestamp would
> depend on the
>ISO 8601 is neither aware of zones or
>DSTs, just abstract offsets which is a good thing
Well. ISO 8601 allows timestamps without "UTC offset"
For instance, 2019-10-06T12:30:00 is ISO 8601-compatible timestamp, however
it is ambiguous.
So I suggest that the property must require Z or +HH:MM part
Hi everyone,
I (and others) have created various pull requests for
flatten-maven-pugin over the last months and the feedback was less than
stellar, to put it mildly:
https://github.com/mojohaus/flatten-maven-plugin/pulls
I am not sure whether Jörg Hohwiller (the primary maintainer?) is
reachab
I don't understand that either. ISO 8601 is neither aware of zones or
DSTs, just abstract offsets which is a good thing. The format Hervé has
chosen is almost correct (comments) left. The way the value has to be
provided can *always* be canonicalized to UTC. I don't see here a big
hurdle to sol
Le 06/10/2019 à 09:43, Hervé BOUTEMY a écrit :
> Notice that you can also express a timezone (as digits), as seen in the unit
> tests.
I know but that's not desirable, otherwise the formatted timestamp would
depend on the timezone of the developer and that would harm the
reproducibility of the p
The difference between this time and UTC is ( Zone Offset + DST offset ).
I think here this feature does not need to describe the LOCAL time nothing
but the timestamp and that is in UTC. It makes sense that the plugins use
particular FORMAT, forinstance platform format of predefined format by the
M
I still don't see and issue because the offset is there. If you subtract
or add the offset and you have the Zulu time.
Can you provide this concrete example? I am quite certain that there was
an error on some side.
If you case is true, the entire time logic in Java 8 woudn't be able to
perfo
Michael, it is the problem with summer time. Do you know what i mean?We had
this problem in my company therefore we strictly used Z as UTC and if
somebody sent another timezone we sent back an error from REST.
You cannot say that you disagree if you do not understand. Pls have it
logically explaine
Am 2019-10-06 um 12:25 schrieb Tibor Digana:
ISO format was often discussed and this was found as problematic format
because you cannot always compute it to UTC due to GMT offset. The offset
is not enough. What is required for EXACT computing to UTC is Time zome
name but this format does not su
ISO format was often discussed and this was found as problematic format
because you cannot always compute it to UTC due to GMT offset. The offset
is not enough. What is required for EXACT computing to UTC is Time zome
name but this format does not support it. It is exactly the same problem in
XML.
Am 2019-10-06 um 09:35 schrieb Hervé BOUTEMY:
Le samedi 5 octobre 2019, 22:46:20 CEST Michael Osipov a écrit :
Am 2019-10-05 um 22:10 schrieb Hervé BOUTEMY:
Le samedi 5 octobre 2019 20:41:40 CEST, vous avez écrit :
Am 2019-10-05 um 19:52 schrieb Hervé BOUTEMY:
based on the feedback I got, I u
Am 2019-10-05 um 23:15 schrieb Emmanuel Bourg:
Le 05/10/2019 à 19:52, Hervé BOUTEMY a écrit :
based on the feedback I got, I updated the proposal:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318
The archives entries timestamp is now configured with
project.build.outpu
Le samedi 5 octobre 2019 20:41:40 CEST, vous avez écrit :
> Am 2019-10-05 um 19:52 schrieb Hervé BOUTEMY:
> > based on the feedback I got, I updated the proposal:
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318
> >
> > The archives entries timestamp is now configured
Le samedi 5 octobre 2019, 23:15:58 CEST Emmanuel Bourg a écrit :
> Le 05/10/2019 à 19:52, Hervé BOUTEMY a écrit :
> > based on the feedback I got, I updated the proposal:
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318
> >
> > The archives entries timestamp is now con
Yes, having the timestamp to 0 is something I wanted generally to avoid.
But this has opened another question: use what value? Can this be automated?
I knew that war files could be a specific use case.
Perhaps this plugin requires a specific way of handling reproducibility, even
more than the sta
Le samedi 5 octobre 2019, 22:46:20 CEST Michael Osipov a écrit :
> Am 2019-10-05 um 22:10 schrieb Hervé BOUTEMY:
> > Le samedi 5 octobre 2019 20:41:40 CEST, vous avez écrit :
> >> Am 2019-10-05 um 19:52 schrieb Hervé BOUTEMY:
> >>> based on the feedback I got, I updated the proposal:
> >>> https://
28 matches
Mail list logo
