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

michaelo
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.

Michael


---------------------------------------------------------------------
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

Robert Scholte-8
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 can already see where  
this thread is going to... ;)

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]

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