Re: On Maven 4.0.0 and beyond

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: On Maven 4.0.0 and beyond

Karl Heinz Marbaise-3
On 23/12/18 12:40, Stephen Connolly wrote:

> On Sun 23 Dec 2018 at 11:32, Michael Osipov <[hidden email]> wrote:
>
>> Am 2018-12-23 um 11:14 schrieb Stephen Connolly:
>>> Over the break I *may* get some time to work on the tooling improvements
>>> that Robert, Hervé and I identified for the jump to 4.0.0 (namely a
>> better
>>> way to ensure api binary compatibility for the APIs that core exposes to
>>> plugins)
>>>
>>> If I do get a chance to work on this, it’ll be in a branch until we think
>>> it’s “good enough”.
>>>
>>> The idea is to enable large scale lambdafication and other Java 8
>>> improvements in core without breaking plugins.
>>
>> I'd rather see a big bug/PR sweep than lambafication which does not give
>> a huge benefit for the users. What else I'd like to see is edge cases
>> covered Christian Schulte started to work on. We can break things this
>> time and clean them up.
>
>
> We need to get people actually involved in the code. Lambdafication and
> other modernisation refactoring enable people to get their hands dirty
> without committing too much. Asking potential new blood to look at the
> harder things will not get us new blood.
>
> Actual committers should be looking at the other changes... though I don’t
> believe we can change the pom until 5.0.0 which is why the scope of 4.0.0
> is likely:
>
> * modernise the codebase

Wouldln't it be a good idea to have list of ideas in a JIRA(or multiple
of them) so we can distribute the work...or have at least smaller chunks
of work...

We have already a 4.0.X release marker ("4.0.x-candidate") where we can
assign issues to that line...

> * Java 8 baseline

> * perhaps relocate aether to org.apache.maven

You mean that the current maven resolver package should be relocated to
org.apache.maven.resolver ?

> * other behaviour changes that do not affect the pom

Can we summarize them a little bit best would be via JIRA...

> * nicer failure message when presented with a newer modelVersion
> * native consumer pom support... perhaps also PDT publishing
>
>

I would suggest to create a branch "Maven-4.0.0" from where we do split
off feature branches like "4.0.0/Feature1" for the parts mentioned and
merge (via fast forwards as we did before) them into "Maven-4.0.0" and
there we can let check by CI/IT's running and keep compatibility and
also gives us a simple chance to make alphas' etc. easily...

That also gives other committers a chance to be involved easily via a
feature branch.

Do we have a more accurate list of changes/Ideas which are identified
for the tooling which should be done? (also via JIRA or multiple JIRA's).

Also would be it be a good idea to reconsider the changes which had been
suggested by Christian Schulte (mentioned by Michael Osipov), cause
there are some things which should be fixed. For 4.0.0 it's the right
time to do it and we have the chance to break things which makes sense...

Kind regards
Karl Heinz Marbaise

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On Maven 4.0.0 and beyond

Karl Heinz Marbaise-3
Hi Robert,

On 24/12/18 11:44, Robert Scholte wrote:
> Let's plan a hangout in the beginning of next year, that should be much
> more effective than trying to do this by mail.

I agree...

 >
I can already see where
> this thread is going to... ;)

would you enlighten us with your wisdom ?...;-)...

Kind regards
Karl Heinz Marbaise

>
> Robert
>
> On Mon, 24 Dec 2018 10:38:35 +0100, Karl Heinz Marbaise
> <[hidden email]> wrote:
>
>> On 23/12/18 12:40, Stephen Connolly wrote:
>>> On Sun 23 Dec 2018 at 11:32, Michael Osipov <[hidden email]> wrote:
>>>
>>>> Am 2018-12-23 um 11:14 schrieb Stephen Connolly:
>>>>> Over the break I *may* get some time to work on the tooling
>>>>> improvements
>>>>> that Robert, Hervé and I identified for the jump to 4.0.0 (namely a
>>>> better
>>>>> way to ensure api binary compatibility for the APIs that core
>>>>> exposes to
>>>>> plugins)
>>>>>
>>>>> If I do get a chance to work on this, it’ll be in a branch until we
>>>>> think
>>>>> it’s “good enough”.
>>>>>
>>>>> The idea is to enable large scale lambdafication and other Java 8
>>>>> improvements in core without breaking plugins.
>>>>
>>>> I'd rather see a big bug/PR sweep than lambafication which does not
>>>> give
>>>> a huge benefit for the users. What else I'd like to see is edge cases
>>>> covered Christian Schulte started to work on. We can break things this
>>>> time and clean them up.
>>>   We need to get people actually involved in the code. Lambdafication
>>> and
>>> other modernisation refactoring enable people to get their hands dirty
>>> without committing too much. Asking potential new blood to look at the
>>> harder things will not get us new blood.
>>>  Actual committers should be looking at the other changes... though I
>>> don’t
>>> believe we can change the pom until 5.0.0 which is why the scope of
>>> 4.0.0
>>> is likely:
>>>  * modernise the codebase
>>
>> Wouldln't it be a good idea to have list of ideas in a JIRA(or
>> multiple of them) so we can distribute the work...or have at least
>> smaller chunks of work...
>>
>> We have already a 4.0.X release marker ("4.0.x-candidate") where we
>> can assign issues to that line...
>>
>>> * Java 8 baseline
>>
>>> * perhaps relocate aether to org.apache.maven
>>
>> You mean that the current maven resolver package should be relocated
>> to org.apache.maven.resolver ?
>>
>>> * other behaviour changes that do not affect the pom
>>
>> Can we summarize them a little bit best would be via JIRA...
>>
>>> * nicer failure message when presented with a newer modelVersion
>>> * native consumer pom support... perhaps also PDT publishing
>>>
>>
>> I would suggest to create a branch "Maven-4.0.0" from where we do
>> split off feature branches like "4.0.0/Feature1" for the parts
>> mentioned and merge (via fast forwards as we did before) them into
>> "Maven-4.0.0" and there we can let check by CI/IT's running and keep
>> compatibility and also gives us a simple chance to make alphas' etc.
>> easily...
>>
>> That also gives other committers a chance to be involved easily via a
>> feature branch.
>>
>> Do we have a more accurate list of changes/Ideas which are identified
>> for the tooling which should be done? (also via JIRA or multiple JIRA's).
>>
>> Also would be it be a good idea to reconsider the changes which had
>> been suggested by Christian Schulte (mentioned by Michael Osipov),
>> cause there are some things which should be fixed. For 4.0.0 it's the
>> right time to do it and we have the chance to break things which makes
>> sense...
>>
>> Kind regards
>> Karl Heinz Marbaise
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]