You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Michael Osipov <mi...@apache.org> on 2017/01/01 00:55:10 UTC
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
I just went through the list my issues. Here is a safe list I would
merge/cherry-pick into new master:
FIX-3.5.0: MNG-5457, MNG-5567, MNG-5579, MNG-5607, MNG-5815, MNG-5954,
MNG-5963, MNG-5975, MNG-5977, MNG-6001, MNG-6003, MNG-6029, MNG-6081,
MNG-6102, MNG-6106, MNG-6115, MNG-6136, MNG-6137, MNG-6138
To be transfered to someone else:
MNG-6043 can be merged into Hervé's MNG-3507.
Without issue id FIX-3.5.0:
MNG-xxxx WONTFIX Added some docs in CLIReporting Utils
NONE Remove trailing whitespace
MNG-xxxx WONTFIX Pass force=true to DefaultWagonManagerTest
#testGetMissingJarForced()
NONE Fix checkstyle error
NONE Use static final values instead of literals
NONE Remove non-existent m2 include in component.xml
NONE Language style improvements for commit
5dab4940c9a7d3b362bd2a8b078b183e4eb521bb
MNG-xxxx WONTFIX Update Maven Dependency Plugin in Super POM
to 2.10
MNG-xxxx WONTFIX Removing redundant test
MNG-xxxx WONTFIX Work around a rounding bug existed upto
Java 7
MNG-xxxx WONTFIX Remove ancient Subversion keywords
MNG-xxxx WONTFIX Use the proper term for char U+002D (-)
hyphen(-minus) instead of dash
Some of them will be squashed into into closely related commits, will
have tickets created or are so trivial that they will be applied directly.
Drop: MNG-5976
Undecided:
MNG-5708: fixed by Christian's work
MNG-6049: Maybe for Christian, I just pulled PR and IT
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Posted by Hervé BOUTEMY <he...@free.fr>.
in general, I completely agree
in this specific case, where there were changes in 1.1.0 and 1.2.0-SNAPSHOT
that we won't integrate yet, Aether 1.0.2 followed by Artifact Resolver 1.0.3
with only coordinate changes (but not code) seems easier to understand
Regards,
Hervé
Le lundi 2 janvier 2017, 22:08:43 CET Michael Osipov a écrit :
> > Hervé will be adding the coordinate changes to that branch and then will
> > cut a 1.0.3 release which we will then change MNG-6110's title to
> > reference
> >
> > So you see the change in 3.5.0 should be a no-op from 3.3.9
>
> I sew what you are after. It makes sense. Though, I dislike to change
> coordinates in a patch release. This deserves a minor release (at least)
> for the relocation. Next release, with real changes, can be 2.0. 3.0
> will likely include new package names.
>
> Michael
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Posted by Stephen Connolly <st...@gmail.com>.
Seconded on both
I'll update the wiki page tomorrow
On Tue 3 Jan 2017 at 21:44, Michael Osipov <mi...@apache.org> wrote:
> Am 2017-01-02 um 21:34 schrieb Stephen Connolly:
>
> > On 2 January 2017 at 20:15, Michael Osipov <mi...@apache.org> wrote:
>
> >
>
> >>>> MNG-6029,
>
> >>>>>
>
> >>>>> I'd second this for 3.5.1
>
> >>>>> I have concerns with introducing for 3.5.0 as it affects how the
>
> >>>>> classpath
>
> >>>>> gets built and could cause behaviour differences between 3.3.9 and
> 3.5.0
>
> >>>>> (as it causes the test classpath to actually get resolved)
>
> >>>>>
>
> >>>>> -1 for 3.5.0 but I am open to change my position
>
> >>>>>
>
> >>>>>
>
> >>>> It is actually two-fold, duplicate code and wrong scope. Fix has been
>
> >>>> there for seven months without causing any IT failures. I think is is
> a
>
> >>>> safe bet for an RC.
>
> >>>>
>
> >>>
>
> >>>
>
> >>> But it breaks my goal for 3.5.0... the duplicate code part is OK for
>
> >>> 3.5.0... but the fixing the scope bug is why I remain -1. Perfectly
> fine
>
> >>> for 3.5.1
>
> >>>
>
> >>
>
> >> Let's split it! What do you think?
>
> >
>
> >
>
> > I am fine on the duplicate code removal for 3.5.0 as it should be a
> no-op.
>
> >
>
> > Create a new JIRA for the test scope change then and we can include that
> in
>
> > for 3.5.1?
>
>
>
> Here are the splitted issues:
>
> > [MNG-6147] MetadataResolutionResult#getGraph() contains duplicate if
> clause
>
>
>
> FIX-3.5.0
>
>
>
> > [MNG-6149] MetadataResolutionResult#getGraph() never resolves request
> type 'test'
>
>
>
> FIX-3.5.1
>
>
>
> Is that ok for you?
>
>
>
> Michael
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> --
Sent from my phone
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-01-02 um 21:34 schrieb Stephen Connolly:
> On 2 January 2017 at 20:15, Michael Osipov <mi...@apache.org> wrote:
>
>>>> MNG-6029,
>>>>>
>>>>> I'd second this for 3.5.1
>>>>> I have concerns with introducing for 3.5.0 as it affects how the
>>>>> classpath
>>>>> gets built and could cause behaviour differences between 3.3.9 and 3.5.0
>>>>> (as it causes the test classpath to actually get resolved)
>>>>>
>>>>> -1 for 3.5.0 but I am open to change my position
>>>>>
>>>>>
>>>> It is actually two-fold, duplicate code and wrong scope. Fix has been
>>>> there for seven months without causing any IT failures. I think is is a
>>>> safe bet for an RC.
>>>>
>>>
>>>
>>> But it breaks my goal for 3.5.0... the duplicate code part is OK for
>>> 3.5.0... but the fixing the scope bug is why I remain -1. Perfectly fine
>>> for 3.5.1
>>>
>>
>> Let's split it! What do you think?
>
>
> I am fine on the duplicate code removal for 3.5.0 as it should be a no-op.
>
> Create a new JIRA for the test scope change then and we can include that in
> for 3.5.1?
Here are the splitted issues:
> [MNG-6147] MetadataResolutionResult#getGraph() contains duplicate if clause
FIX-3.5.0
> [MNG-6149] MetadataResolutionResult#getGraph() never resolves request type 'test'
FIX-3.5.1
Is that ok for you?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Posted by Stephen Connolly <st...@gmail.com>.
On Monday, 2 January 2017, Michael Osipov <mi...@apache.org> wrote:
> Am 2017-01-02 um 21:34 schrieb Stephen Connolly:
>
>> On 2 January 2017 at 20:15, Michael Osipov <mi...@apache.org> wrote:
>>
>> Am 2017-01-02 um 20:35 schrieb Stephen Connolly:
>>>
>>> On 2 January 2017 at 18:49, Michael Osipov <mi...@apache.org> wrote:
>>>>
>>>> Am 2017-01-01 um 15:51 schrieb Stephen Connolly:
>>>>
>>>>>
>>>>> On 1 January 2017 at 00:55, Michael Osipov <mi...@apache.org>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> I just went through the list my issues. Here is a safe list I would
>>>>>>
>>>>>> merge/cherry-pick into new master:
>>>>>>>
>>>>>>> FIX-3.5.0:
>>>>>>> MNG-5567,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Affects behaviour, I recommend 3.5.1 but I will not object if others
>>>>>> feel
>>>>>> 3.5.0
>>>>>>
>>>>>>
>>>>>> This indeed changes behavior but behavioral changes should not be in a
>>>>> patch version like 3.5.1, but in a minor. Moreover, Java supports ZIP
>>>>> files
>>>>> first-class citizens, we simply failed/forgot this here.
>>>>>
>>>>>
>>>>> Well that is why I see this as a patch fix. Changing behaviour where
>>>> the
>>>> original behaviour was a bug or a regression does not mean we have to
>>>> bump
>>>> a minor version.
>>>>
>>>> I think this and the plugin classpath building *bugs/regressions* are
>>>> both
>>>> perfectly valid to fix in a patch.
>>>>
>>>>
>>>> I still think that 3.5.0 is appropriate.
>>>>>
>>>>>
>>>>
>>>> I still think that it raises the risk of marking the "no-op" change from
>>>> aether to resolver as breaking existing builds.
>>>>
>>>> My plan is 3.5.0 in the next two weeks and 3.5.1, etc at a 6 week
>>>> cadence
>>>> thereafter. If you want I am happy to do 3.5.0 and 3.5.1 in more rapid
>>>> sequence, but I really would like to keep dependency and classpath
>>>> changes
>>>> out of 3.5.0 and push them for 3.5.1 (where they are bugs / regressions)
>>>> or
>>>> 3.6.0 (which should be as soon as we think we are ready, not a year or
>>>> two's time
>>>>
>>>>
>>> Agreed.
>>>
>>>
>>>
>>>>> MNG-5954,
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is
>>>>>> low
>>>>>> risk to drop-in replacement with 3.3.9
>>>>>>
>>>>>>
>>>>>> Do not share, it is never read. I even asked on dev list and Jason
>>>>> replied, it is safe to be nuked.
>>>>>
>>>>>
>>>>
>>>> If somebody else seconds, then it is agreed (unless we have an
>>>> objector)...
>>>> just I'm not going to second it for 3.5.0
>>>>
>>>>
>>> Anyone else?
>>>
>>>
>>>
>>>>> MNG-6029,
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>> I'd second this for 3.5.1
>>>>>> I have concerns with introducing for 3.5.0 as it affects how the
>>>>>> classpath
>>>>>> gets built and could cause behaviour differences between 3.3.9 and
>>>>>> 3.5.0
>>>>>> (as it causes the test classpath to actually get resolved)
>>>>>>
>>>>>> -1 for 3.5.0 but I am open to change my position
>>>>>>
>>>>>>
>>>>>> It is actually two-fold, duplicate code and wrong scope. Fix has been
>>>>> there for seven months without causing any IT failures. I think is is a
>>>>> safe bet for an RC.
>>>>>
>>>>>
>>>>
>>>> But it breaks my goal for 3.5.0... the duplicate code part is OK for
>>>> 3.5.0... but the fixing the scope bug is why I remain -1. Perfectly fine
>>>> for 3.5.1
>>>>
>>>>
>>> Let's split it! What do you think?
>>>
>>
>>
>> I am fine on the duplicate code removal for 3.5.0 as it should be a no-op.
>>
>> Create a new JIRA for the test scope change then and we can include that
>> in
>> for 3.5.1?
>>
>
> Agreed. Will do tomorrow.
>
> MNG-6102,
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is
>>>>>> low
>>>>>> risk to drop-in replacement with 3.3.9
>>>>>>
>>>>>>
>>>>>> This is change in behavior and not subject to a bugfix. The default
>>>>> behaves like before.
>>>>>
>>>>>
>>>>
>>>> This does not affect dependency / classpath resolution, but we are
>>>> growing
>>>> changes for 3.5.0 and I would like to try and keep the non
>>>> s/aether/resolver/g changes to a minimum. If you can find another
>>>> seconder
>>>> it's in.
>>>>
>>>>
>>> Anyone else?
>>>
>>> MNG-6106,
>>>
>>>>
>>>>>
>>>>>>
>>>>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is
>>>>>> low
>>>>>> risk to drop-in replacement with 3.3.9
>>>>>>
>>>>>>
>>>>>> This is actually a bug because maven.home can never be user.home/.m2
>>>>>
>>>>>
>>>>
>>>>
>>>> This does not affect dependency / classpath resolution, but we are
>>>> growing
>>>> changes for 3.5.0 and I would like to try and keep the non
>>>> s/aether/resolver/g changes to a minimum. If you can find another
>>>> seconder
>>>> it's in.
>>>>
>>>>
>>> Anyone else?
>>>
>>> MNG-6115,
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>> We need to decide on colourised logs for 3.5.0 or 3.5.1
>>>>>>
>>>>>>
>>>>>> Colorize is a new feature, not a bug fix. Either 3.5 or 3.6. It could
>>>>> also
>>>>> be squashed into MNG-3507.
>>>>>
>>>>>
>>>>
>>>> It's a new feature for logging, but it doesn't add new APIs to the
>>>> *core*
>>>> of maven. So I think we could put it in 3.5.1 if we decided our version
>>>> policy was "effects on plugin API / dependency resolution"
>>>>
>>>> The squashed diff should be quite small, so I am fine with us adding it
>>>> for
>>>> 3.5.0... I just am not stepping up to sponsor it
>>>>
>>>>
>>> I'd like to handle over this to Hervé and make it his decision. I will
>>> ping him in the ticket.
>>>
>>> MNG-6136,
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is
>>>>>> low
>>>>>> risk to drop-in replacement with 3.3.9
>>>>>>
>>>>>> MNG-6137,
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is
>>>>>> low
>>>>>> risk to drop-in replacement with 3.3.9
>>>>>>
>>>>>>
>>>>>> Rather 3.5 or 3.6, consider that the last Wagon release is quite old
>>>>> and
>>>>> currently, there duplicate dependencies on Maven's classpath as layed
>>>>> out
>>>>> in MNG-6137.
>>>>>
>>>>>
>>>>
>>>> I don't see this being something that needs to wait for 3.6.0... 3.5.1
>>>> seems perfectly ok to me
>>>>
>>>>
>>> Why not 3.5 then? We update Resolver, why not Wagon? At last, Resolver
>>> requires Wagon too as its transport...
>>>
>>
>>
>> Because it will be a resolver that is cut from
>> https://github.com/apache/maven-resolver/commits/1.0.x so that the only
>> change between resolver in 3.3.9 and resolver in 3.5.0 is the groupId and
>> artifactId changes.
>>
>> (this was discussed on IRC with Hervé and Robert somewhere near
>> http://wilderness.apache.org/channels/?f=maven-dev/2017-01-02#1483389145
>> (if we could get the link to work!)
>>
>> Hervé will be adding the coordinate changes to that branch and then will
>> cut a 1.0.3 release which we will then change MNG-6110's title to
>> reference
>>
>> So you see the change in 3.5.0 should be a no-op from 3.3.9
>>
>
> I sew what you are after. It makes sense. Though, I dislike to change
> coordinates in a patch release. This deserves a minor release (at least)
> for the relocation.
>
So the relocation is what 3.5.0 is
3.5.1 will be then just a version bump
If we rename packages that would be 4.0.0 at least (unless we retain a
compatibility shim... in which case it could be 3.6.0)
Next release, with real changes, can be 2.0. 3.0 will likely include new
> package names.
>
> Michael
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sent from my phone
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-01-02 um 21:34 schrieb Stephen Connolly:
> On 2 January 2017 at 20:15, Michael Osipov <mi...@apache.org> wrote:
>
>> Am 2017-01-02 um 20:35 schrieb Stephen Connolly:
>>
>>> On 2 January 2017 at 18:49, Michael Osipov <mi...@apache.org> wrote:
>>>
>>> Am 2017-01-01 um 15:51 schrieb Stephen Connolly:
>>>>
>>>> On 1 January 2017 at 00:55, Michael Osipov <mi...@apache.org> wrote:
>>>>>
>>>>> I just went through the list my issues. Here is a safe list I would
>>>>>
>>>>>> merge/cherry-pick into new master:
>>>>>>
>>>>>> FIX-3.5.0:
>>>>>> MNG-5567,
>>>>>>
>>>>>>
>>>>>
>>>>> Affects behaviour, I recommend 3.5.1 but I will not object if others
>>>>> feel
>>>>> 3.5.0
>>>>>
>>>>>
>>>> This indeed changes behavior but behavioral changes should not be in a
>>>> patch version like 3.5.1, but in a minor. Moreover, Java supports ZIP
>>>> files
>>>> first-class citizens, we simply failed/forgot this here.
>>>>
>>>>
>>> Well that is why I see this as a patch fix. Changing behaviour where the
>>> original behaviour was a bug or a regression does not mean we have to bump
>>> a minor version.
>>>
>>> I think this and the plugin classpath building *bugs/regressions* are both
>>> perfectly valid to fix in a patch.
>>>
>>>
>>>> I still think that 3.5.0 is appropriate.
>>>>
>>>
>>>
>>> I still think that it raises the risk of marking the "no-op" change from
>>> aether to resolver as breaking existing builds.
>>>
>>> My plan is 3.5.0 in the next two weeks and 3.5.1, etc at a 6 week cadence
>>> thereafter. If you want I am happy to do 3.5.0 and 3.5.1 in more rapid
>>> sequence, but I really would like to keep dependency and classpath changes
>>> out of 3.5.0 and push them for 3.5.1 (where they are bugs / regressions)
>>> or
>>> 3.6.0 (which should be as soon as we think we are ready, not a year or
>>> two's time
>>>
>>
>> Agreed.
>>
>>
>>>>
>>>> MNG-5954,
>>>>
>>>>>
>>>>>>
>>>>>
>>>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
>>>>> risk to drop-in replacement with 3.3.9
>>>>>
>>>>>
>>>> Do not share, it is never read. I even asked on dev list and Jason
>>>> replied, it is safe to be nuked.
>>>>
>>>
>>>
>>> If somebody else seconds, then it is agreed (unless we have an
>>> objector)...
>>> just I'm not going to second it for 3.5.0
>>>
>>
>> Anyone else?
>>
>>
>>>>
>>>> MNG-6029,
>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> I'd second this for 3.5.1
>>>>> I have concerns with introducing for 3.5.0 as it affects how the
>>>>> classpath
>>>>> gets built and could cause behaviour differences between 3.3.9 and 3.5.0
>>>>> (as it causes the test classpath to actually get resolved)
>>>>>
>>>>> -1 for 3.5.0 but I am open to change my position
>>>>>
>>>>>
>>>> It is actually two-fold, duplicate code and wrong scope. Fix has been
>>>> there for seven months without causing any IT failures. I think is is a
>>>> safe bet for an RC.
>>>>
>>>
>>>
>>> But it breaks my goal for 3.5.0... the duplicate code part is OK for
>>> 3.5.0... but the fixing the scope bug is why I remain -1. Perfectly fine
>>> for 3.5.1
>>>
>>
>> Let's split it! What do you think?
>
>
> I am fine on the duplicate code removal for 3.5.0 as it should be a no-op.
>
> Create a new JIRA for the test scope change then and we can include that in
> for 3.5.1?
Agreed. Will do tomorrow.
>> MNG-6102,
>>>>
>>>>>
>>>>>>
>>>>>
>>>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
>>>>> risk to drop-in replacement with 3.3.9
>>>>>
>>>>>
>>>> This is change in behavior and not subject to a bugfix. The default
>>>> behaves like before.
>>>>
>>>
>>>
>>> This does not affect dependency / classpath resolution, but we are growing
>>> changes for 3.5.0 and I would like to try and keep the non
>>> s/aether/resolver/g changes to a minimum. If you can find another seconder
>>> it's in.
>>>
>>
>> Anyone else?
>>
>> MNG-6106,
>>>>
>>>>>
>>>>>
>>>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
>>>>> risk to drop-in replacement with 3.3.9
>>>>>
>>>>>
>>>> This is actually a bug because maven.home can never be user.home/.m2
>>>>
>>>
>>>
>>>
>>> This does not affect dependency / classpath resolution, but we are growing
>>> changes for 3.5.0 and I would like to try and keep the non
>>> s/aether/resolver/g changes to a minimum. If you can find another seconder
>>> it's in.
>>>
>>
>> Anyone else?
>>
>> MNG-6115,
>>>>
>>>>>
>>>>>>
>>>>>
>>>>> We need to decide on colourised logs for 3.5.0 or 3.5.1
>>>>>
>>>>>
>>>> Colorize is a new feature, not a bug fix. Either 3.5 or 3.6. It could
>>>> also
>>>> be squashed into MNG-3507.
>>>>
>>>
>>>
>>> It's a new feature for logging, but it doesn't add new APIs to the *core*
>>> of maven. So I think we could put it in 3.5.1 if we decided our version
>>> policy was "effects on plugin API / dependency resolution"
>>>
>>> The squashed diff should be quite small, so I am fine with us adding it
>>> for
>>> 3.5.0... I just am not stepping up to sponsor it
>>>
>>
>> I'd like to handle over this to Hervé and make it his decision. I will
>> ping him in the ticket.
>>
>> MNG-6136,
>>>>
>>>>>
>>>>>>
>>>>>
>>>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
>>>>> risk to drop-in replacement with 3.3.9
>>>>>
>>>>> MNG-6137,
>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
>>>>> risk to drop-in replacement with 3.3.9
>>>>>
>>>>>
>>>> Rather 3.5 or 3.6, consider that the last Wagon release is quite old and
>>>> currently, there duplicate dependencies on Maven's classpath as layed out
>>>> in MNG-6137.
>>>>
>>>
>>>
>>> I don't see this being something that needs to wait for 3.6.0... 3.5.1
>>> seems perfectly ok to me
>>>
>>
>> Why not 3.5 then? We update Resolver, why not Wagon? At last, Resolver
>> requires Wagon too as its transport...
>
>
> Because it will be a resolver that is cut from
> https://github.com/apache/maven-resolver/commits/1.0.x so that the only
> change between resolver in 3.3.9 and resolver in 3.5.0 is the groupId and
> artifactId changes.
>
> (this was discussed on IRC with Hervé and Robert somewhere near
> http://wilderness.apache.org/channels/?f=maven-dev/2017-01-02#1483389145
> (if we could get the link to work!)
>
> Hervé will be adding the coordinate changes to that branch and then will
> cut a 1.0.3 release which we will then change MNG-6110's title to reference
>
> So you see the change in 3.5.0 should be a no-op from 3.3.9
I sew what you are after. It makes sense. Though, I dislike to change
coordinates in a patch release. This deserves a minor release (at least)
for the relocation. Next release, with real changes, can be 2.0. 3.0
will likely include new package names.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Posted by Stephen Connolly <st...@gmail.com>.
On 2 January 2017 at 20:34, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
>
>
> On 2 January 2017 at 20:15, Michael Osipov <mi...@apache.org> wrote:
>
>> Am 2017-01-02 um 20:35 schrieb Stephen Connolly:
>>
>>> On 2 January 2017 at 18:49, Michael Osipov <mi...@apache.org> wrote:
>>>
>>> Am 2017-01-01 um 15:51 schrieb Stephen Connolly:
>>>>
>>>> On 1 January 2017 at 00:55, Michael Osipov <mi...@apache.org> wrote:
>>>>>
>>>>> I just went through the list my issues. Here is a safe list I would
>>>>>
>>>>>> merge/cherry-pick into new master:
>>>>>>
>>>>>> FIX-3.5.0:
>>>>>> MNG-5567,
>>>>>>
>>>>>>
>>>>>
>>>>> Affects behaviour, I recommend 3.5.1 but I will not object if others
>>>>> feel
>>>>> 3.5.0
>>>>>
>>>>>
>>>> This indeed changes behavior but behavioral changes should not be in a
>>>> patch version like 3.5.1, but in a minor. Moreover, Java supports ZIP
>>>> files
>>>> first-class citizens, we simply failed/forgot this here.
>>>>
>>>>
>>> Well that is why I see this as a patch fix. Changing behaviour where the
>>> original behaviour was a bug or a regression does not mean we have to
>>> bump
>>> a minor version.
>>>
>>> I think this and the plugin classpath building *bugs/regressions* are
>>> both
>>> perfectly valid to fix in a patch.
>>>
>>>
>>>> I still think that 3.5.0 is appropriate.
>>>>
>>>
>>>
>>> I still think that it raises the risk of marking the "no-op" change from
>>> aether to resolver as breaking existing builds.
>>>
>>> My plan is 3.5.0 in the next two weeks and 3.5.1, etc at a 6 week cadence
>>> thereafter. If you want I am happy to do 3.5.0 and 3.5.1 in more rapid
>>> sequence, but I really would like to keep dependency and classpath
>>> changes
>>> out of 3.5.0 and push them for 3.5.1 (where they are bugs / regressions)
>>> or
>>> 3.6.0 (which should be as soon as we think we are ready, not a year or
>>> two's time
>>>
>>
>> Agreed.
>>
>>
>>>>
>>>> MNG-5954,
>>>>
>>>>>
>>>>>>
>>>>>
>>>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is
>>>>> low
>>>>> risk to drop-in replacement with 3.3.9
>>>>>
>>>>>
>>>> Do not share, it is never read. I even asked on dev list and Jason
>>>> replied, it is safe to be nuked.
>>>>
>>>
>>>
>>> If somebody else seconds, then it is agreed (unless we have an
>>> objector)...
>>> just I'm not going to second it for 3.5.0
>>>
>>
>> Anyone else?
>>
>>
>>>>
>>>> MNG-6029,
>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> I'd second this for 3.5.1
>>>>> I have concerns with introducing for 3.5.0 as it affects how the
>>>>> classpath
>>>>> gets built and could cause behaviour differences between 3.3.9 and
>>>>> 3.5.0
>>>>> (as it causes the test classpath to actually get resolved)
>>>>>
>>>>> -1 for 3.5.0 but I am open to change my position
>>>>>
>>>>>
>>>> It is actually two-fold, duplicate code and wrong scope. Fix has been
>>>> there for seven months without causing any IT failures. I think is is a
>>>> safe bet for an RC.
>>>>
>>>
>>>
>>> But it breaks my goal for 3.5.0... the duplicate code part is OK for
>>> 3.5.0... but the fixing the scope bug is why I remain -1. Perfectly fine
>>> for 3.5.1
>>>
>>
>> Let's split it! What do you think?
>
>
> I am fine on the duplicate code removal for 3.5.0 as it should be a no-op.
>
> Create a new JIRA for the test scope change then and we can include that
> in for 3.5.1?
>
>
>>
>>
>> MNG-6102,
>>>>
>>>>>
>>>>>>
>>>>>
>>>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is
>>>>> low
>>>>> risk to drop-in replacement with 3.3.9
>>>>>
>>>>>
>>>> This is change in behavior and not subject to a bugfix. The default
>>>> behaves like before.
>>>>
>>>
>>>
>>> This does not affect dependency / classpath resolution, but we are
>>> growing
>>> changes for 3.5.0 and I would like to try and keep the non
>>> s/aether/resolver/g changes to a minimum. If you can find another
>>> seconder
>>> it's in.
>>>
>>
>> Anyone else?
>>
>> MNG-6106,
>>>>
>>>>>
>>>>>
>>>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is
>>>>> low
>>>>> risk to drop-in replacement with 3.3.9
>>>>>
>>>>>
>>>> This is actually a bug because maven.home can never be user.home/.m2
>>>>
>>>
>>>
>>>
>>> This does not affect dependency / classpath resolution, but we are
>>> growing
>>> changes for 3.5.0 and I would like to try and keep the non
>>> s/aether/resolver/g changes to a minimum. If you can find another
>>> seconder
>>> it's in.
>>>
>>
>> Anyone else?
>>
>> MNG-6115,
>>>>
>>>>>
>>>>>>
>>>>>
>>>>> We need to decide on colourised logs for 3.5.0 or 3.5.1
>>>>>
>>>>>
>>>> Colorize is a new feature, not a bug fix. Either 3.5 or 3.6. It could
>>>> also
>>>> be squashed into MNG-3507.
>>>>
>>>
>>>
>>> It's a new feature for logging, but it doesn't add new APIs to the *core*
>>> of maven. So I think we could put it in 3.5.1 if we decided our version
>>> policy was "effects on plugin API / dependency resolution"
>>>
>>> The squashed diff should be quite small, so I am fine with us adding it
>>> for
>>> 3.5.0... I just am not stepping up to sponsor it
>>>
>>
>> I'd like to handle over this to Hervé and make it his decision. I will
>> ping him in the ticket.
>>
>> MNG-6136,
>>>>
>>>>>
>>>>>>
>>>>>
>>>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is
>>>>> low
>>>>> risk to drop-in replacement with 3.3.9
>>>>>
>>>>> MNG-6137,
>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is
>>>>> low
>>>>> risk to drop-in replacement with 3.3.9
>>>>>
>>>>>
>>>> Rather 3.5 or 3.6, consider that the last Wagon release is quite old and
>>>> currently, there duplicate dependencies on Maven's classpath as layed
>>>> out
>>>> in MNG-6137.
>>>>
>>>
>>>
>>> I don't see this being something that needs to wait for 3.6.0... 3.5.1
>>> seems perfectly ok to me
>>>
>>
>> Why not 3.5 then? We update Resolver, why not Wagon? At last, Resolver
>> requires Wagon too as its transport...
>
>
> Because it will be a resolver that is cut from https://github.com/apache/
> maven-resolver/commits/1.0.x so that the only change between resolver in
> 3.3.9 and resolver in 3.5.0 is the groupId and artifactId changes.
>
> (this was discussed on IRC with Hervé and Robert somewhere near
> http://wilderness.apache.org/channels/?f=maven-dev/2017-01-02#1483389145
> (if we could get the link to work!)
>
Link works unless you have HTTPS Everywhere browser plugin installed. See
https://issues.apache.org/jira/servicedesk/agent/INFRA/issue/INFRA-13219
for my request to make available over https also
>
> Hervé will be adding the coordinate changes to that branch and then will
> cut a 1.0.3 release which we will then change MNG-6110's title to reference
>
> So you see the change in 3.5.0 should be a no-op from 3.3.9
>
>
>>
>>
>> Michael
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Posted by Stephen Connolly <st...@gmail.com>.
On 2 January 2017 at 20:15, Michael Osipov <mi...@apache.org> wrote:
> Am 2017-01-02 um 20:35 schrieb Stephen Connolly:
>
>> On 2 January 2017 at 18:49, Michael Osipov <mi...@apache.org> wrote:
>>
>> Am 2017-01-01 um 15:51 schrieb Stephen Connolly:
>>>
>>> On 1 January 2017 at 00:55, Michael Osipov <mi...@apache.org> wrote:
>>>>
>>>> I just went through the list my issues. Here is a safe list I would
>>>>
>>>>> merge/cherry-pick into new master:
>>>>>
>>>>> FIX-3.5.0:
>>>>> MNG-5567,
>>>>>
>>>>>
>>>>
>>>> Affects behaviour, I recommend 3.5.1 but I will not object if others
>>>> feel
>>>> 3.5.0
>>>>
>>>>
>>> This indeed changes behavior but behavioral changes should not be in a
>>> patch version like 3.5.1, but in a minor. Moreover, Java supports ZIP
>>> files
>>> first-class citizens, we simply failed/forgot this here.
>>>
>>>
>> Well that is why I see this as a patch fix. Changing behaviour where the
>> original behaviour was a bug or a regression does not mean we have to bump
>> a minor version.
>>
>> I think this and the plugin classpath building *bugs/regressions* are both
>> perfectly valid to fix in a patch.
>>
>>
>>> I still think that 3.5.0 is appropriate.
>>>
>>
>>
>> I still think that it raises the risk of marking the "no-op" change from
>> aether to resolver as breaking existing builds.
>>
>> My plan is 3.5.0 in the next two weeks and 3.5.1, etc at a 6 week cadence
>> thereafter. If you want I am happy to do 3.5.0 and 3.5.1 in more rapid
>> sequence, but I really would like to keep dependency and classpath changes
>> out of 3.5.0 and push them for 3.5.1 (where they are bugs / regressions)
>> or
>> 3.6.0 (which should be as soon as we think we are ready, not a year or
>> two's time
>>
>
> Agreed.
>
>
>>>
>>> MNG-5954,
>>>
>>>>
>>>>>
>>>>
>>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
>>>> risk to drop-in replacement with 3.3.9
>>>>
>>>>
>>> Do not share, it is never read. I even asked on dev list and Jason
>>> replied, it is safe to be nuked.
>>>
>>
>>
>> If somebody else seconds, then it is agreed (unless we have an
>> objector)...
>> just I'm not going to second it for 3.5.0
>>
>
> Anyone else?
>
>
>>>
>>> MNG-6029,
>>>>
>>>>>
>>>>>
>>>>
>>>> I'd second this for 3.5.1
>>>> I have concerns with introducing for 3.5.0 as it affects how the
>>>> classpath
>>>> gets built and could cause behaviour differences between 3.3.9 and 3.5.0
>>>> (as it causes the test classpath to actually get resolved)
>>>>
>>>> -1 for 3.5.0 but I am open to change my position
>>>>
>>>>
>>> It is actually two-fold, duplicate code and wrong scope. Fix has been
>>> there for seven months without causing any IT failures. I think is is a
>>> safe bet for an RC.
>>>
>>
>>
>> But it breaks my goal for 3.5.0... the duplicate code part is OK for
>> 3.5.0... but the fixing the scope bug is why I remain -1. Perfectly fine
>> for 3.5.1
>>
>
> Let's split it! What do you think?
I am fine on the duplicate code removal for 3.5.0 as it should be a no-op.
Create a new JIRA for the test scope change then and we can include that in
for 3.5.1?
>
>
> MNG-6102,
>>>
>>>>
>>>>>
>>>>
>>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
>>>> risk to drop-in replacement with 3.3.9
>>>>
>>>>
>>> This is change in behavior and not subject to a bugfix. The default
>>> behaves like before.
>>>
>>
>>
>> This does not affect dependency / classpath resolution, but we are growing
>> changes for 3.5.0 and I would like to try and keep the non
>> s/aether/resolver/g changes to a minimum. If you can find another seconder
>> it's in.
>>
>
> Anyone else?
>
> MNG-6106,
>>>
>>>>
>>>>
>>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
>>>> risk to drop-in replacement with 3.3.9
>>>>
>>>>
>>> This is actually a bug because maven.home can never be user.home/.m2
>>>
>>
>>
>>
>> This does not affect dependency / classpath resolution, but we are growing
>> changes for 3.5.0 and I would like to try and keep the non
>> s/aether/resolver/g changes to a minimum. If you can find another seconder
>> it's in.
>>
>
> Anyone else?
>
> MNG-6115,
>>>
>>>>
>>>>>
>>>>
>>>> We need to decide on colourised logs for 3.5.0 or 3.5.1
>>>>
>>>>
>>> Colorize is a new feature, not a bug fix. Either 3.5 or 3.6. It could
>>> also
>>> be squashed into MNG-3507.
>>>
>>
>>
>> It's a new feature for logging, but it doesn't add new APIs to the *core*
>> of maven. So I think we could put it in 3.5.1 if we decided our version
>> policy was "effects on plugin API / dependency resolution"
>>
>> The squashed diff should be quite small, so I am fine with us adding it
>> for
>> 3.5.0... I just am not stepping up to sponsor it
>>
>
> I'd like to handle over this to Hervé and make it his decision. I will
> ping him in the ticket.
>
> MNG-6136,
>>>
>>>>
>>>>>
>>>>
>>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
>>>> risk to drop-in replacement with 3.3.9
>>>>
>>>> MNG-6137,
>>>>
>>>>>
>>>>>
>>>>
>>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
>>>> risk to drop-in replacement with 3.3.9
>>>>
>>>>
>>> Rather 3.5 or 3.6, consider that the last Wagon release is quite old and
>>> currently, there duplicate dependencies on Maven's classpath as layed out
>>> in MNG-6137.
>>>
>>
>>
>> I don't see this being something that needs to wait for 3.6.0... 3.5.1
>> seems perfectly ok to me
>>
>
> Why not 3.5 then? We update Resolver, why not Wagon? At last, Resolver
> requires Wagon too as its transport...
Because it will be a resolver that is cut from
https://github.com/apache/maven-resolver/commits/1.0.x so that the only
change between resolver in 3.3.9 and resolver in 3.5.0 is the groupId and
artifactId changes.
(this was discussed on IRC with Hervé and Robert somewhere near
http://wilderness.apache.org/channels/?f=maven-dev/2017-01-02#1483389145
(if we could get the link to work!)
Hervé will be adding the coordinate changes to that branch and then will
cut a 1.0.3 release which we will then change MNG-6110's title to reference
So you see the change in 3.5.0 should be a no-op from 3.3.9
>
>
> Michael
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-01-02 um 20:35 schrieb Stephen Connolly:
> On 2 January 2017 at 18:49, Michael Osipov <mi...@apache.org> wrote:
>
>> Am 2017-01-01 um 15:51 schrieb Stephen Connolly:
>>
>>> On 1 January 2017 at 00:55, Michael Osipov <mi...@apache.org> wrote:
>>>
>>> I just went through the list my issues. Here is a safe list I would
>>>> merge/cherry-pick into new master:
>>>>
>>>> FIX-3.5.0:
>>>> MNG-5567,
>>>>
>>>
>>>
>>> Affects behaviour, I recommend 3.5.1 but I will not object if others feel
>>> 3.5.0
>>>
>>
>> This indeed changes behavior but behavioral changes should not be in a
>> patch version like 3.5.1, but in a minor. Moreover, Java supports ZIP files
>> first-class citizens, we simply failed/forgot this here.
>>
>
> Well that is why I see this as a patch fix. Changing behaviour where the
> original behaviour was a bug or a regression does not mean we have to bump
> a minor version.
>
> I think this and the plugin classpath building *bugs/regressions* are both
> perfectly valid to fix in a patch.
>
>>
>> I still think that 3.5.0 is appropriate.
>
>
> I still think that it raises the risk of marking the "no-op" change from
> aether to resolver as breaking existing builds.
>
> My plan is 3.5.0 in the next two weeks and 3.5.1, etc at a 6 week cadence
> thereafter. If you want I am happy to do 3.5.0 and 3.5.1 in more rapid
> sequence, but I really would like to keep dependency and classpath changes
> out of 3.5.0 and push them for 3.5.1 (where they are bugs / regressions) or
> 3.6.0 (which should be as soon as we think we are ready, not a year or
> two's time
Agreed.
>>
>>
>> MNG-5954,
>>>>
>>>
>>>
>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
>>> risk to drop-in replacement with 3.3.9
>>>
>>
>> Do not share, it is never read. I even asked on dev list and Jason
>> replied, it is safe to be nuked.
>
>
> If somebody else seconds, then it is agreed (unless we have an objector)...
> just I'm not going to second it for 3.5.0
Anyone else?
>>
>>
>>> MNG-6029,
>>>>
>>>
>>>
>>> I'd second this for 3.5.1
>>> I have concerns with introducing for 3.5.0 as it affects how the classpath
>>> gets built and could cause behaviour differences between 3.3.9 and 3.5.0
>>> (as it causes the test classpath to actually get resolved)
>>>
>>> -1 for 3.5.0 but I am open to change my position
>>>
>>
>> It is actually two-fold, duplicate code and wrong scope. Fix has been
>> there for seven months without causing any IT failures. I think is is a
>> safe bet for an RC.
>
>
> But it breaks my goal for 3.5.0... the duplicate code part is OK for
> 3.5.0... but the fixing the scope bug is why I remain -1. Perfectly fine
> for 3.5.1
Let's split it! What do you think?
>> MNG-6102,
>>>>
>>>
>>>
>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
>>> risk to drop-in replacement with 3.3.9
>>>
>>
>> This is change in behavior and not subject to a bugfix. The default
>> behaves like before.
>
>
> This does not affect dependency / classpath resolution, but we are growing
> changes for 3.5.0 and I would like to try and keep the non
> s/aether/resolver/g changes to a minimum. If you can find another seconder
> it's in.
Anyone else?
>> MNG-6106,
>>>
>>>
>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
>>> risk to drop-in replacement with 3.3.9
>>>
>>
>> This is actually a bug because maven.home can never be user.home/.m2
>
>
>
> This does not affect dependency / classpath resolution, but we are growing
> changes for 3.5.0 and I would like to try and keep the non
> s/aether/resolver/g changes to a minimum. If you can find another seconder
> it's in.
Anyone else?
>> MNG-6115,
>>>>
>>>
>>>
>>> We need to decide on colourised logs for 3.5.0 or 3.5.1
>>>
>>
>> Colorize is a new feature, not a bug fix. Either 3.5 or 3.6. It could also
>> be squashed into MNG-3507.
>
>
> It's a new feature for logging, but it doesn't add new APIs to the *core*
> of maven. So I think we could put it in 3.5.1 if we decided our version
> policy was "effects on plugin API / dependency resolution"
>
> The squashed diff should be quite small, so I am fine with us adding it for
> 3.5.0... I just am not stepping up to sponsor it
I'd like to handle over this to Hervé and make it his decision. I will
ping him in the ticket.
>> MNG-6136,
>>>>
>>>
>>>
>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
>>> risk to drop-in replacement with 3.3.9
>>>
>>> MNG-6137,
>>>>
>>>
>>>
>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
>>> risk to drop-in replacement with 3.3.9
>>>
>>
>> Rather 3.5 or 3.6, consider that the last Wagon release is quite old and
>> currently, there duplicate dependencies on Maven's classpath as layed out
>> in MNG-6137.
>
>
> I don't see this being something that needs to wait for 3.6.0... 3.5.1
> seems perfectly ok to me
Why not 3.5 then? We update Resolver, why not Wagon? At last, Resolver
requires Wagon too as its transport...
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Posted by Stephen Connolly <st...@gmail.com>.
On 2 January 2017 at 18:49, Michael Osipov <mi...@apache.org> wrote:
> Am 2017-01-01 um 15:51 schrieb Stephen Connolly:
>
>> On 1 January 2017 at 00:55, Michael Osipov <mi...@apache.org> wrote:
>>
>> I just went through the list my issues. Here is a safe list I would
>>> merge/cherry-pick into new master:
>>>
>>> FIX-3.5.0:
>>> MNG-5567,
>>>
>>
>>
>> Affects behaviour, I recommend 3.5.1 but I will not object if others feel
>> 3.5.0
>>
>
> This indeed changes behavior but behavioral changes should not be in a
> patch version like 3.5.1, but in a minor. Moreover, Java supports ZIP files
> first-class citizens, we simply failed/forgot this here.
>
Well that is why I see this as a patch fix. Changing behaviour where the
original behaviour was a bug or a regression does not mean we have to bump
a minor version.
I think this and the plugin classpath building *bugs/regressions* are both
perfectly valid to fix in a patch.
>
> I still think that 3.5.0 is appropriate.
I still think that it raises the risk of marking the "no-op" change from
aether to resolver as breaking existing builds.
My plan is 3.5.0 in the next two weeks and 3.5.1, etc at a 6 week cadence
thereafter. If you want I am happy to do 3.5.0 and 3.5.1 in more rapid
sequence, but I really would like to keep dependency and classpath changes
out of 3.5.0 and push them for 3.5.1 (where they are bugs / regressions) or
3.6.0 (which should be as soon as we think we are ready, not a year or
two's time
>
>
> MNG-5954,
>>>
>>
>>
>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
>> risk to drop-in replacement with 3.3.9
>>
>
> Do not share, it is never read. I even asked on dev list and Jason
> replied, it is safe to be nuked.
If somebody else seconds, then it is agreed (unless we have an objector)...
just I'm not going to second it for 3.5.0
>
>
>
>> MNG-6029,
>>>
>>
>>
>> I'd second this for 3.5.1
>> I have concerns with introducing for 3.5.0 as it affects how the classpath
>> gets built and could cause behaviour differences between 3.3.9 and 3.5.0
>> (as it causes the test classpath to actually get resolved)
>>
>> -1 for 3.5.0 but I am open to change my position
>>
>
> It is actually two-fold, duplicate code and wrong scope. Fix has been
> there for seven months without causing any IT failures. I think is is a
> safe bet for an RC.
But it breaks my goal for 3.5.0... the duplicate code part is OK for
3.5.0... but the fixing the scope bug is why I remain -1. Perfectly fine
for 3.5.1
>
>
> MNG-6102,
>>>
>>
>>
>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
>> risk to drop-in replacement with 3.3.9
>>
>
> This is change in behavior and not subject to a bugfix. The default
> behaves like before.
This does not affect dependency / classpath resolution, but we are growing
changes for 3.5.0 and I would like to try and keep the non
s/aether/resolver/g changes to a minimum. If you can find another seconder
it's in.
>
>
> MNG-6106,
>>
>>
>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
>> risk to drop-in replacement with 3.3.9
>>
>
> This is actually a bug because maven.home can never be user.home/.m2
This does not affect dependency / classpath resolution, but we are growing
changes for 3.5.0 and I would like to try and keep the non
s/aether/resolver/g changes to a minimum. If you can find another seconder
it's in.
>
>
> MNG-6115,
>>>
>>
>>
>> We need to decide on colourised logs for 3.5.0 or 3.5.1
>>
>
> Colorize is a new feature, not a bug fix. Either 3.5 or 3.6. It could also
> be squashed into MNG-3507.
It's a new feature for logging, but it doesn't add new APIs to the *core*
of maven. So I think we could put it in 3.5.1 if we decided our version
policy was "effects on plugin API / dependency resolution"
The squashed diff should be quite small, so I am fine with us adding it for
3.5.0... I just am not stepping up to sponsor it
>
>
> MNG-6136,
>>>
>>
>>
>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
>> risk to drop-in replacement with 3.3.9
>>
>> MNG-6137,
>>>
>>
>>
>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
>> risk to drop-in replacement with 3.3.9
>>
>
> Rather 3.5 or 3.6, consider that the last Wagon release is quite old and
> currently, there duplicate dependencies on Maven's classpath as layed out
> in MNG-6137.
I don't see this being something that needs to wait for 3.6.0... 3.5.1
seems perfectly ok to me
>
>
> Michael
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-01-01 um 15:51 schrieb Stephen Connolly:
> On 1 January 2017 at 00:55, Michael Osipov <mi...@apache.org> wrote:
>
>> I just went through the list my issues. Here is a safe list I would
>> merge/cherry-pick into new master:
>>
>> FIX-3.5.0:
>> MNG-5567,
>
>
> Affects behaviour, I recommend 3.5.1 but I will not object if others feel
> 3.5.0
This indeed changes behavior but behavioral changes should not be in a
patch version like 3.5.1, but in a minor. Moreover, Java supports ZIP
files first-class citizens, we simply failed/forgot this here.
I still think that 3.5.0 is appropriate.
>> MNG-5954,
>
>
> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
> risk to drop-in replacement with 3.3.9
Do not share, it is never read. I even asked on dev list and Jason
replied, it is safe to be nuked.
>
>> MNG-6029,
>
>
> I'd second this for 3.5.1
> I have concerns with introducing for 3.5.0 as it affects how the classpath
> gets built and could cause behaviour differences between 3.3.9 and 3.5.0
> (as it causes the test classpath to actually get resolved)
>
> -1 for 3.5.0 but I am open to change my position
It is actually two-fold, duplicate code and wrong scope. Fix has been
there for seven months without causing any IT failures. I think is is a
safe bet for an RC.
>> MNG-6102,
>
>
> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
> risk to drop-in replacement with 3.3.9
This is change in behavior and not subject to a bugfix. The default
behaves like before.
> MNG-6106,
>
>
> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
> risk to drop-in replacement with 3.3.9
This is actually a bug because maven.home can never be user.home/.m2
>> MNG-6115,
>
>
> We need to decide on colourised logs for 3.5.0 or 3.5.1
Colorize is a new feature, not a bug fix. Either 3.5 or 3.6. It could
also be squashed into MNG-3507.
>> MNG-6136,
>
>
> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
> risk to drop-in replacement with 3.3.9
>
>> MNG-6137,
>
>
> I'd second this for 3.5.1 but I'm not objecting if others feel it is low
> risk to drop-in replacement with 3.3.9
Rather 3.5 or 3.6, consider that the last Wagon release is quite old and
currently, there duplicate dependencies on Maven's classpath as layed
out in MNG-6137.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Posted by Stephen Connolly <st...@gmail.com>.
On 1 January 2017 at 00:55, Michael Osipov <mi...@apache.org> wrote:
> I just went through the list my issues. Here is a safe list I would
> merge/cherry-pick into new master:
>
> FIX-3.5.0:
> MNG-5457,
Should not affect behaviour: I'll second
> MNG-5567,
Affects behaviour, I recommend 3.5.1 but I will not object if others feel
3.5.0
> MNG-5579,
Note to self: This is a dup of MNG-6003
> MNG-5607,
I'd proposed this so marked as agreed unless we have an objector in the
next 3 days
MNG-5815,
I'd proposed this so marked as agreed unless we have an objector in the
next 3 days
> MNG-5954,
I'd second this for 3.5.1 but I'm not objecting if others feel it is low
risk to drop-in replacement with 3.3.9
MNG-5963,
Marked as agreed unless we have an objector in the next 3 days
> MNG-5975,
Should not affect behaviour: I'll second
> MNG-5977,
Should not affect behaviour: I'll second
> MNG-6001,
Marked as agreed unless we have an objector in the next 3 days
> MNG-6003,
Marked as agreed unless we have an objector in the next 3 days
> MNG-6029,
I'd second this for 3.5.1
I have concerns with introducing for 3.5.0 as it affects how the classpath
gets built and could cause behaviour differences between 3.3.9 and 3.5.0
(as it causes the test classpath to actually get resolved)
-1 for 3.5.0 but I am open to change my position
> MNG-6081,
>
Marked as agreed unless we have an objector in the next 3 days
> MNG-6102,
I'd second this for 3.5.1 but I'm not objecting if others feel it is low
risk to drop-in replacement with 3.3.9
MNG-6106,
I'd second this for 3.5.1 but I'm not objecting if others feel it is low
risk to drop-in replacement with 3.3.9
> MNG-6115,
We need to decide on colourised logs for 3.5.0 or 3.5.1
> MNG-6136,
I'd second this for 3.5.1 but I'm not objecting if others feel it is low
risk to drop-in replacement with 3.3.9
> MNG-6137,
I'd second this for 3.5.1 but I'm not objecting if others feel it is low
risk to drop-in replacement with 3.3.9
> MNG-6138
>
Should not affect behaviour: I'll second
>
> To be transfered to someone else:
> MNG-6043 can be merged into Hervé's MNG-3507.
>
> Without issue id FIX-3.5.0:
> MNG-xxxx WONTFIX Added some docs in CLIReporting Utils
> NONE Remove trailing whitespace
> MNG-xxxx WONTFIX Pass force=true to DefaultWagonManagerTest
> #testGetMissingJarForced()
> NONE Fix checkstyle error
> NONE Use static final values instead of literals
> NONE Remove non-existent m2 include in component.xml
> NONE Language style improvements for commit
> 5dab4940c9a7d3b362bd2a8b078b183e4eb521bb
> MNG-xxxx WONTFIX Update Maven Dependency Plugin in Super POM
> to 2.10
> MNG-xxxx WONTFIX Removing redundant test
> MNG-xxxx WONTFIX Work around a rounding bug existed upto
> Java 7
> MNG-xxxx WONTFIX Remove ancient Subversion keywords
> MNG-xxxx WONTFIX Use the proper term for char U+002D (-)
> hyphen(-minus) instead of dash
>
> Some of them will be squashed into into closely related commits, will have
> tickets created or are so trivial that they will be applied directly.
>
> Drop: MNG-5976
>
> Undecided:
> MNG-5708: fixed by Christian's work
> MNG-6049: Maybe for Christian, I just pulled PR and IT
>
> Michael
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Posted by Dan Tran <da...@gmail.com>.
I would like to add MNG-6084 WONTFIX Support JSR 250 @PreDestory and
@PostContruct
On Sat, Dec 31, 2016 at 5:17 PM, Michael Osipov <mi...@apache.org> wrote:
> Am 2017-01-01 um 02:11 schrieb Anton Tanasenko:
>
>> FIX-3.5.0:
>> MNG-xxxx WONTFIX Add a ProjectArtifactsCache similar to
>> PluginArtifactsCache
>> That's actually a https://issues.apache.org/jira/browse/MNG-6025
>>
>
> JIRA adjusted, thank you. Stephen, please update your list with MNG-6025.
>
>
> 2017-01-01 2:55 GMT+02:00 Michael Osipov <mi...@apache.org>:
>>
>> I just went through the list my issues. Here is a safe list I would
>>> merge/cherry-pick into new master:
>>>
>>> FIX-3.5.0: MNG-5457, MNG-5567, MNG-5579, MNG-5607, MNG-5815, MNG-5954,
>>> MNG-5963, MNG-5975, MNG-5977, MNG-6001, MNG-6003, MNG-6029, MNG-6081,
>>> MNG-6102, MNG-6106, MNG-6115, MNG-6136, MNG-6137, MNG-6138
>>>
>>> To be transfered to someone else:
>>> MNG-6043 can be merged into Hervé's MNG-3507.
>>>
>>> Without issue id FIX-3.5.0:
>>> MNG-xxxx WONTFIX Added some docs in CLIReporting Utils
>>> NONE Remove trailing whitespace
>>> MNG-xxxx WONTFIX Pass force=true to DefaultWagonManagerTest
>>> #testGetMissingJarForced()
>>> NONE Fix checkstyle error
>>> NONE Use static final values instead of literals
>>> NONE Remove non-existent m2 include in
>>> component.xml
>>> NONE Language style improvements for commit
>>> 5dab4940c9a7d3b362bd2a8b078b183e4eb521bb
>>> MNG-xxxx WONTFIX Update Maven Dependency Plugin in Super POM
>>> to 2.10
>>> MNG-xxxx WONTFIX Removing redundant test
>>> MNG-xxxx WONTFIX Work around a rounding bug existed upto
>>> Java 7
>>> MNG-xxxx WONTFIX Remove ancient Subversion keywords
>>> MNG-xxxx WONTFIX Use the proper term for char U+002D (-)
>>> hyphen(-minus) instead of dash
>>>
>>> Some of them will be squashed into into closely related commits, will
>>> have
>>> tickets created or are so trivial that they will be applied directly.
>>>
>>> Drop: MNG-5976
>>>
>>> Undecided:
>>> MNG-5708: fixed by Christian's work
>>> MNG-6049: Maybe for Christian, I just pulled PR and IT
>>>
>>> Michael
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-01-01 um 02:11 schrieb Anton Tanasenko:
> FIX-3.5.0:
> MNG-xxxx WONTFIX Add a ProjectArtifactsCache similar to
> PluginArtifactsCache
> That's actually a https://issues.apache.org/jira/browse/MNG-6025
JIRA adjusted, thank you. Stephen, please update your list with MNG-6025.
> 2017-01-01 2:55 GMT+02:00 Michael Osipov <mi...@apache.org>:
>
>> I just went through the list my issues. Here is a safe list I would
>> merge/cherry-pick into new master:
>>
>> FIX-3.5.0: MNG-5457, MNG-5567, MNG-5579, MNG-5607, MNG-5815, MNG-5954,
>> MNG-5963, MNG-5975, MNG-5977, MNG-6001, MNG-6003, MNG-6029, MNG-6081,
>> MNG-6102, MNG-6106, MNG-6115, MNG-6136, MNG-6137, MNG-6138
>>
>> To be transfered to someone else:
>> MNG-6043 can be merged into Hervé's MNG-3507.
>>
>> Without issue id FIX-3.5.0:
>> MNG-xxxx WONTFIX Added some docs in CLIReporting Utils
>> NONE Remove trailing whitespace
>> MNG-xxxx WONTFIX Pass force=true to DefaultWagonManagerTest
>> #testGetMissingJarForced()
>> NONE Fix checkstyle error
>> NONE Use static final values instead of literals
>> NONE Remove non-existent m2 include in component.xml
>> NONE Language style improvements for commit
>> 5dab4940c9a7d3b362bd2a8b078b183e4eb521bb
>> MNG-xxxx WONTFIX Update Maven Dependency Plugin in Super POM
>> to 2.10
>> MNG-xxxx WONTFIX Removing redundant test
>> MNG-xxxx WONTFIX Work around a rounding bug existed upto
>> Java 7
>> MNG-xxxx WONTFIX Remove ancient Subversion keywords
>> MNG-xxxx WONTFIX Use the proper term for char U+002D (-)
>> hyphen(-minus) instead of dash
>>
>> Some of them will be squashed into into closely related commits, will have
>> tickets created or are so trivial that they will be applied directly.
>>
>> Drop: MNG-5976
>>
>> Undecided:
>> MNG-5708: fixed by Christian's work
>> MNG-6049: Maybe for Christian, I just pulled PR and IT
>>
>> Michael
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Posted by Anton Tanasenko <at...@gmail.com>.
FIX-3.5.0:
MNG-xxxx WONTFIX Add a ProjectArtifactsCache similar to
PluginArtifactsCache
That's actually a https://issues.apache.org/jira/browse/MNG-6025
2017-01-01 2:55 GMT+02:00 Michael Osipov <mi...@apache.org>:
> I just went through the list my issues. Here is a safe list I would
> merge/cherry-pick into new master:
>
> FIX-3.5.0: MNG-5457, MNG-5567, MNG-5579, MNG-5607, MNG-5815, MNG-5954,
> MNG-5963, MNG-5975, MNG-5977, MNG-6001, MNG-6003, MNG-6029, MNG-6081,
> MNG-6102, MNG-6106, MNG-6115, MNG-6136, MNG-6137, MNG-6138
>
> To be transfered to someone else:
> MNG-6043 can be merged into Hervé's MNG-3507.
>
> Without issue id FIX-3.5.0:
> MNG-xxxx WONTFIX Added some docs in CLIReporting Utils
> NONE Remove trailing whitespace
> MNG-xxxx WONTFIX Pass force=true to DefaultWagonManagerTest
> #testGetMissingJarForced()
> NONE Fix checkstyle error
> NONE Use static final values instead of literals
> NONE Remove non-existent m2 include in component.xml
> NONE Language style improvements for commit
> 5dab4940c9a7d3b362bd2a8b078b183e4eb521bb
> MNG-xxxx WONTFIX Update Maven Dependency Plugin in Super POM
> to 2.10
> MNG-xxxx WONTFIX Removing redundant test
> MNG-xxxx WONTFIX Work around a rounding bug existed upto
> Java 7
> MNG-xxxx WONTFIX Remove ancient Subversion keywords
> MNG-xxxx WONTFIX Use the proper term for char U+002D (-)
> hyphen(-minus) instead of dash
>
> Some of them will be squashed into into closely related commits, will have
> tickets created or are so trivial that they will be applied directly.
>
> Drop: MNG-5976
>
> Undecided:
> MNG-5708: fixed by Christian's work
> MNG-6049: Maybe for Christian, I just pulled PR and IT
>
> Michael
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Regards,
Anton.
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Posted by Guillaume Boué <gb...@apache.org>.
OK, thanks for confirming this.
Le 01/01/2017 � 23:44, Christian Schulte a �crit :
> Am 01/01/17 um 18:44 schrieb Guillaume Bou�:
>> There is a commit about MRESOLVER-9 in tag 2.11 of Wagon:
>> https://git1-us-west.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=f244ece2eee01500e4b1bc334b8dcd35b47f9422.
>> I'm unsure whether it is safe to use this tag if MRESOLVER-9 doesn't
>> make it in the resolver release after its reset.
> Does not make a difference. Everything is resolved the same way as
> before. It's just that the project can be build with MRESOLVER-9 in
> place. It can be built the same way now even when MRESOLVER-9 is not
> there. Does not affect anything.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
L'absence de virus dans ce courrier �lectronique a �t� v�rifi�e par le logiciel antivirus Avast.
https://www.avast.com/antivirus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Posted by Christian Schulte <cs...@schulte.it>.
Am 01/01/17 um 18:44 schrieb Guillaume Bou�:
>
> There is a commit about MRESOLVER-9 in tag 2.11 of Wagon:
> https://git1-us-west.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=f244ece2eee01500e4b1bc334b8dcd35b47f9422.
> I'm unsure whether it is safe to use this tag if MRESOLVER-9 doesn't
> make it in the resolver release after its reset.
Does not make a difference. Everything is resolved the same way as
before. It's just that the project can be build with MRESOLVER-9 in
place. It can be built the same way now even when MRESOLVER-9 is not
there. Does not affect anything.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-01-01 um 18:44 schrieb Guillaume Boué:
>
> Le 01/01/2017 à 01:55, Michael Osipov a écrit :
>> I just went through the list my issues. Here is a safe list I would
>> merge/cherry-pick into new master:
>>
>> FIX-3.5.0: MNG-5457,
>
> Note: this is dependant upon MRESOLVER-2 (commit
> https://git1-us-west.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=11b359e188f3b1d25bb6bda60195e7a47ca45bfc),
> so it depends if this makes it in the resolver release after its reset.
I know, the issues have been linked properly.
>> MNG-5567,
>
> This changes the classpath by adding ZIP files to it. I'd say this
> should be FIX-3.5.1 instead.
This indeed changes behavior but behavioral changes should not be in a
patch version like 3.5.1, but in a minor. Moreover, Java supports ZIP
files first-class citizens, we simply failed/forgot this here.
I still think that 3.5.0 is appropriate. Especially because there is a
longstanding issue for packaging zip.
>> MNG-6136, MNG-6137
>
> There is a commit about MRESOLVER-9 in tag 2.11 of Wagon:
> https://git1-us-west.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=f244ece2eee01500e4b1bc334b8dcd35b47f9422.
> I'm unsure whether it is safe to use this tag if MRESOLVER-9 doesn't
> make it in the resolver release after its reset.
This commit can safely be dropped because it is necessary for changes in
Maven 3.4.0. I can revert before pushing 2.11.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Posted by Guillaume Boué <gb...@apache.org>.
Le 01/01/2017 � 01:55, Michael Osipov a �crit :
> I just went through the list my issues. Here is a safe list I would
> merge/cherry-pick into new master:
>
> FIX-3.5.0: MNG-5457,
Note: this is dependant upon MRESOLVER-2 (commit
https://git1-us-west.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=11b359e188f3b1d25bb6bda60195e7a47ca45bfc),
so it depends if this makes it in the resolver release after its reset.
> MNG-5567,
This changes the classpath by adding ZIP files to it. I'd say this
should be FIX-3.5.1 instead.
> MNG-6106,
Seconded.
> MNG-6136, MNG-6137
There is a commit about MRESOLVER-9 in tag 2.11 of Wagon:
https://git1-us-west.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=f244ece2eee01500e4b1bc334b8dcd35b47f9422.
I'm unsure whether it is safe to use this tag if MRESOLVER-9 doesn't
make it in the resolver release after its reset.
>
> To be transfered to someone else:
> MNG-6043 can be merged into Herv�'s MNG-3507.
>
> Without issue id FIX-3.5.0:
> MNG-xxxx WONTFIX Added some docs in CLIReporting Utils
> NONE Remove trailing whitespace
> MNG-xxxx WONTFIX Pass force=true to DefaultWagonManagerTest
> #testGetMissingJarForced()
> NONE Fix checkstyle error
> NONE Use static final values instead of literals
> NONE Remove non-existent m2 include in
> component.xml
> NONE Language style improvements for commit
> 5dab4940c9a7d3b362bd2a8b078b183e4eb521bb
> MNG-xxxx WONTFIX Update Maven Dependency Plugin in Super POM
> to 2.10
> MNG-xxxx WONTFIX Removing redundant test
> MNG-xxxx WONTFIX Work around a rounding bug existed upto
> Java 7
> MNG-xxxx WONTFIX Remove ancient Subversion keywords
> MNG-xxxx WONTFIX Use the proper term for char U+002D (-)
> hyphen(-minus) instead of dash
>
> Some of them will be squashed into into closely related commits, will
> have tickets created or are so trivial that they will be applied
> directly.
>
> Drop: MNG-5976
>
> Undecided:
> MNG-5708: fixed by Christian's work
> MNG-6049: Maybe for Christian, I just pulled PR and IT
>
> Michael
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
L'absence de virus dans ce courrier �lectronique a �t� v�rifi�e par le logiciel antivirus Avast.
https://www.avast.com/antivirus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-01-01 um 04:51 schrieb Christian Schulte:
> Am 01/01/17 um 01:55 schrieb Michael Osipov:
>> Undecided:
>> MNG-5708: fixed by Christian's work
>
> Should not be done in that release. Let's ship all bugfixes affecting
> resolution together - not just one after the other. All or nothing. So
> nothing.
I do agree, you are the expert. Moving to FIX-3.6.0, FIX-4.0.0?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Posted by Christian Schulte <cs...@schulte.it>.
Am 01/01/17 um 01:55 schrieb Michael Osipov:
> Undecided:
> MNG-5708: fixed by Christian's work
Should not be done in that release. Let's ship all bugfixes affecting
resolution together - not just one after the other. All or nothing. So
nothing.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-01-01 um 10:26 schrieb Stephen Connolly:
> On 1 January 2017 at 00:55, Michael Osipov <mi...@apache.org> wrote:
>
>> MNG-5963, MNG-6137
>
>
> I couldn't find them in my list... note to self, double check... note to
> michael, can you confirm
I distilled from your list, filtered git log and Jira roadmap.
* MNG-5963 is fixed and on agreed in your list.
* MNG-6137 is still open depends on MNG-6136 which is Wagon upgrade to 2.11.
> Otherwise I have updated the wiki with your proposals (some of which were
> seconds and moved things into agreed (pending no objections from others in
> the next 3 days)
Just checked, looks fine.
I will go on and create a few more tickets for the dandling stuff.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Posted by Stephen Connolly <st...@gmail.com>.
On 1 January 2017 at 00:55, Michael Osipov <mi...@apache.org> wrote:
> MNG-5963, MNG-6137
I couldn't find them in my list... note to self, double check... note to
michael, can you confirm
Otherwise I have updated the wiki with your proposals (some of which were
seconds and moved things into agreed (pending no objections from others in
the next 3 days)