Am 03/14/17 um 21:24 schrieb Stephen Connolly:
> Not so easy. Was attempted before and hit issues with gpg signing.
Can you remember what issues that were? It will sign the temporary pom
java.io.File the same way the install plugin will install that and the
deploy plugin will deploy that.
Not so easy. Was attempted before and hit issues with gpg signing.
Not in scope for 3.5.0
On Tue 14 Mar 2017 at 18:58, Christian Schulte wrote:
> Am 12.03.2017 um 15:36 schrieb Karl Heinz Marbaise:
> > Hi,
> >
> > So after I finalized the implementation which seemed to be ok
Am 12.03.2017 um 15:36 schrieb Karl Heinz Marbaise:
> Hi,
>
> So after I finalized the implementation which seemed to be ok for
> now...the IT's are currently not working based on particular reason
> (explanations later).
>
> I would like to know the opinion of the Maven DEV's about this:
>
>
Am 03/13/17 um 08:33 schrieb Hervé BOUTEMY:
>> The flatten-maven-plugin solution appears to me like a workaround for
>> some missing support in Maven core. Also a good reason to split build
>> pom from deployed pom. Maybe all of this better be postponed to model
>> version 5.0.0?
> splitting build
> The flatten-maven-plugin solution appears to me like a workaround for
> some missing support in Maven core. Also a good reason to split build
> pom from deployed pom. Maybe all of this better be postponed to model
> version 5.0.0?
splitting build pom from deployed (or consumer) pom IMHO is:
1.
Am 03/12/17 um 15:36 schrieb Karl Heinz Marbaise:
> Hi,
>
> So after I finalized the implementation which seemed to be ok for
> now...the IT's are currently not working based on particular reason
> (explanations later).
>
> I would like to know the opinion of the Maven DEV's about this:
>
>
Hi,
So if no one has objections against this change I would like to do the
merge to master monday evening...
I will wait for the IT's results first ...
Kind regards
Karl Heinz Marbaise
On 12/03/17 19:47, Karl Heinz Marbaise wrote:
Hi Hervé,
On 12/03/17 19:40, Hervé BOUTEMY wrote:
IIUC
Hi Hervé,
On 12/03/17 19:40, Hervé BOUTEMY wrote:
IIUC
You can publish such poms with ${revision}, ${sha1} and/or ${changelist} in
central from the early begining: even MNG-5576 just removed a warning
I didn't remember on that...Thanks for pointing out this.
Then the new commit just make
IIUC
You can publish such poms with ${revision}, ${sha1} and/or ${changelist} in
central from the early begining: even MNG-5576 just removed a warning
Then the new commit just make it work better, in more complex multi-module
situations: looks reasonable
I just pushed 2 commits: the first one
On Sun 12 Mar 2017 at 14:36, Karl Heinz Marbaise wrote:
> Hi,
>
> So after I finalized the implementation which seemed to be ok for
> now...the IT's are currently not working based on particular reason
> (explanations later).
>
> I would like to know the opinion of the Maven
Hi,
So after I finalized the implementation which seemed to be ok for
now...the IT's are currently not working based on particular reason
(explanations later).
I would like to know the opinion of the Maven DEV's about this:
The following scenario:
This feature has been introduced in Maven
Benedikt has started a vote for CLI-1.4[1], which should be used as
replacement for our own MergedCommandLine.
I'll leave it up to you if this is worth adding to alpha-2
Robert
[1]
Ok no problem
On Fri 10 Mar 2017 at 06:22, Karl Heinz Marbaise wrote:
>
> On 10/03/17 00:29, Stephen Connolly wrote:
> > How are we doing?
> >
> > Are we ready to freeze?
>
> Can we wait until monday..
>
> I would like to integrate MNG-6170 (which is ready) and currently
>
On 10/03/17 00:29, Stephen Connolly wrote:
How are we doing?
Are we ready to freeze?
Can we wait until monday..
I would like to integrate MNG-6170 (which is ready) and currently
working on IT's for MNG-6057, MNG-6090, MNG-5895 which I would like to
integrate into 3.5.0-alpha-2...
So I
Am 03/10/17 um 00:29 schrieb Stephen Connolly:
> How are we doing?
>
> Are we ready to freeze?
Nothing left to do on my side. There are a couple of issues in JIRA
flagged "in progress" for -alpha-2. Not sure about them.
-
To
How are we doing?
Are we ready to freeze?
On Sat 4 Mar 2017 at 19:40, Christian Schulte wrote:
> Am 03/04/17 um 18:54 schrieb Hervé BOUTEMY:
> > I have one question, which is recurring for every issue: what is the
> impact?
> >
> > I understand the logic: it should fix a bug
Am 03/04/17 um 14:56 schrieb Stephen Connolly:
> We are still in alpha, so bugs with severity S1-S3 are eligible (and S4
> with a risk assessment)
> Severity is something like this (but as a project we probably need to
> define the categories for Maven core)
>
> S1: blows up for everyone, no
Am 03/04/17 um 18:54 schrieb Hervé BOUTEMY:
> I have one question, which is recurring for every issue: what is the impact?
>
> I understand the logic: it should fix a bug (that is told introduced in Maven
> 3.3.1), and the bug is explained by the logic behind the javadoc.
> But no pointer to any
Am 03/04/17 um 18:54 schrieb Hervé BOUTEMY:
> I have one question, which is recurring for every issue: what is the impact?
>
> I understand the logic: it should fix a bug (that is told introduced in Maven
> 3.3.1), and the bug is explained by the logic behind the javadoc.
> But no pointer to any
I have one question, which is recurring for every issue: what is the impact?
I understand the logic: it should fix a bug (that is told introduced in Maven
3.3.1), and the bug is explained by the logic behind the javadoc.
But no pointer to any code using this method, and that shows that Maven
I've created two more issues:
MNG-6181 Wagon produces a lot of noise at debug loglevel
MNG-6180 groupId has plain color when goal fails
I have no proper solution yet for MNG-6181, maybe we simply need to change
the loglevel for wagon to INFO.
Robert
On Sat, 04 Mar 2017 02:45:21 +0100,
Hi,
I see it the same way...I think we might need an alpha-2 but then I
don't a requirement for further releases before the final GA...
I would like to get two changes into alpha-2 (MNG-6057, MNG-6170) which
fixing things.
MNG-6170 fixes an edge case in relationship with -T XX calling a
We are still in alpha, so bugs with severity S1-S3 are eligible (and S4
with a risk assessment)
Severity is something like this (but as a project we probably need to
define the categories for Maven core)
S1: blows up for everyone, no workaround
S2: blows up under certain circumstances, no
Am 03/02/17 um 22:55 schrieb Stephen Connolly:
> I'd like to declare feature freeze for alpha-2 on March 9th.
>
> If a feature does not land in alpha-2 it will not be in beta-1 (i.e. Only bug
> fixes or rip out features that are causing S1/S2 issues will be in the diff
> from alpha-2 to beta-1)
1 non-final then the final, *if everything happens as expected*: ok, fine for
me,
I can live with that extra step :)
Le samedi 4 mars 2017, 08:12:35 CET Stephen Connolly a écrit :
> I was only planning 1 beta.
>
> And if alpha-2 is good enough and we are confident we can skip the beta...
>
>
I was only planning 1 beta.
And if alpha-2 is good enough and we are confident we can skip the beta...
I want to avoid RCs, we should have one take only for the actual release
On Sat 4 Mar 2017 at 01:47, Hervé BOUTEMY wrote:
> sorry to open such discussion, but given
sorry to open such discussion, but given the good feedback on alpha-1 (which
is a good news), are alpha-2 then beta-1 then beta-2 before GA really useful?
Not a little bit too much?
Or are there really changes I don't see that require such detailed
qualification path?
Regards,
Hervé
Le jeudi
I'd like to declare feature freeze for alpha-2 on March 9th.
If a feature does not land in alpha-2 it will not be in beta-1 (i.e. Only bug
fixes or rip out features that are causing S1/S2 issues will be in the diff
from alpha-2 to beta-1)
I am aiming beta-2 approx 2 weeks after alpha-2 and the
28 matches
Mail list logo