Re: Maven 4.0.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

michaelo
Am 2017-11-04 um 13:20 schrieb Stephen Connolly:

> The past two days, Hervé, Robert and I have been discussing our next steps.
>
> I think we have a semi-consensus which I want to bring back to the list:
>
> We keep 3.5.x as a stable branch with critical bug fixes only
>
> We switch master to 4.0.0 and start to burn down a release scope.
>
> 4.0.0 will not change the pom modelVersion
>
> The 4.0.0 scope should probably be:
>
> Required:
> * drop Java 7, switch codebase to Java 8 idioms (while maintaining binary
> api compatibility for plugins)

Who is going to do this? I haven't even seen any Java 7 improvements
(NIO 2 and others) in core since 3.3. I doubt that core will we be
rewritten with Java 8 idioms.
Consider that we still have plugins running Maven 2.2.x which need more
attention first.

> * specify the classloader behaviour and fix impl to align with spec (may
> need a plugin flag to allow plugins to opt in to spec behaviour)
> * specify the extension spec
> * allow limited mutation of the runtime model (reducing transitive
> dependencies for consumers within the reactor, only for plugin goals that
> declare intent) use case: shade plugin
> * better CI integration hooks
> * nice error message for newer pom modelVersion

This looks quite reasonable to me.

Michael



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

Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

stephenconnolly
On Sat 4 Nov 2017 at 12:24, Stephen Connolly <
[hidden email]> wrote:

> On Sat 4 Nov 2017 at 12:20, Stephen Connolly <
> [hidden email]> wrote:
>
>> The past two days, Hervé, Robert and I have been discussing our next
>> steps.
>>
>> I think we have a semi-consensus which I want to bring back to the list:
>>
>> We keep 3.5.x as a stable branch with critical bug fixes only
>>
>> We switch master to 4.0.0 and start to burn down a release scope.
>>
>> 4.0.0 will not change the pom modelVersion
>>
>> The 4.0.0 scope should probably be:
>>
>> Required:
>> * drop Java 7, switch codebase to Java 8 idioms (while maintaining binary
>> api compatibility for plugins)
>> * specify the classloader behaviour and fix impl to align with spec (may
>> need a plugin flag to allow plugins to opt in to spec behaviour)
>> * specify the extension spec
>> * allow limited mutation of the runtime model (reducing transitive
>> dependencies for consumers within the reactor, only for plugin goals that
>> declare intent) use case: shade plugin
>> * better CI integration hooks
>> * nice error message for newer pom modelVersion
>>
> * declare plugin api depreciation policy:
The next major version of Maven (5.0.0) will not support plugins compiled
against Maven 2.x APIs. Plugins compiled against 3.0-3.3 will be best
effort. 3.5.x (Maven Resolver not aether) is the cut-point


>> Optional:
>> * (damn I forgot, maybe Robert remembers)
>>
> * incremental build
> * concurrent safe local repo cache
>
>> --
>> Sent from my phone
>>
> --
> Sent from my phone
>
--
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

stephenconnolly
In reply to this post by michaelo
On Sat 4 Nov 2017 at 13:18, Paul Hammant <[hidden email]> wrote:

> >
> >
> >
> > >
> > > *3. More pluggable dependency resolver:*
> > >
> >
> > I am willing to let this be optional scope for now. May be yanked if too
> > risky or not ready in time
> >
> >
> >
> I don't see how you can even make it optional without a pom specified way
> of saying "not maven central, this way/place instead"


Then ok, out of scope (unless you find a way.. hint repository url could
use a custom scheme provided by an extension)

>
> --
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

stephenconnolly
In reply to this post by michaelo
On Sat 4 Nov 2017 at 17:52, Hervé BOUTEMY <[hidden email]> wrote:

> Le samedi 4 novembre 2017, 18:34:14 CET Romain Manni-Bucau a écrit :
> > > And scripting is the path to the dark side of imperative builds... but
> > > proposals welcome
> >
> > This is true but this is also mandatory today. There is a small
> > alternative to that and I would be as happy if maven can do it:
> > support mojo from the reactor (ie having a project with this layout:
> > parent/[module1, my-maven-plugin]). If this works then no need of
> > scripting
> I like this idea


Yes, this is what we should aim for. It feels more “The Maven way” to me.

There would be limitations, namely you cannot use any CLI goals from the
plugin in your reactor CLI... but goal executions in downstream modules
within the same reactor should be fine... subject to the reactor parallel
execution graph restrictions, much like the restrictions we will need to
fix shade

>
>
>
> Regards,
>
> Hervé
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

Mark Derricutt
In reply to this post by michaelo

On 5 Nov 2017, at 10:42, Robert Scholte wrote:

I would like to drop strict scopes in general and give plugins the opportunity to depend on
specific scoped dependencies.

How would this help with annotations tho? The main issue I'm facing is having a standard m-c-p plugin definition in a parent ( or tile ) but needing different annotation processors used per project. With the current plugin, this means either listing them as standard dependencies and have them auto-scanned, and pollute the compilation classpath, or list every possible annotation processor dependency we may use in our projects in the parent, which is less than ideal.

I hope you are aware that modules already end up on the modulepath based on the moduledescriptor(s). So I don't see the need for this scope. (unless you have this wish that in the end Maven will create the module descriptor based on this, but I still think we shouldn't do that)

I remembered reading something about this, and assumed it was the case if there was a module-info.class, but what if its a standard jar with an Automatic-Module-Name header? Does that fall into the module path or classpath? Having control for this case may be useful.

I recognize this wish. The best solution is to make the dependency optional.

The problem with this is that the dependency is still on the classpath for say surefire, which can influence behaviour.

Mark


"The ease with which a change can be implemented has no relevance at all to whether it is the right change for the (Java) Platform for all time." — Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc (546 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

AW: Maven 4.0.0

Bernd Eckenfels

Hello,

 

Adding annotations and processor as a compiletime dependency sounds like a reasonable thing. It would however be cool if the JAR could describe which package needs to go on the classpath and which is processor impl. (and having a different artifact for runtime)

 

Gruss

Bernd

 

Von: [hidden email]
Gesendet: Sonntag, 5. November 2017 22:20
An: [hidden email]
Betreff: Re: Maven 4.0.0

 

On 5 Nov 2017, at 10:42, Robert Scholte wrote:

I would like to drop strict scopes in general and give plugins the opportunity to depend on
specific scoped dependencies.

How would this help with annotations tho? The main issue I'm facing is having a standard m-c-p plugin definition in a parent ( or tile ) but needing different annotation processors used per project. With the current plugin, this means either listing them as standard dependencies and have them auto-scanned, and pollute the compilation classpath, or list every possible annotation processor dependency we may use in our projects in the parent, which is less than ideal.

I hope you are aware that modules already end up on the modulepath based on the moduledescriptor(s). So I don't see the need for this scope. (unless you have this wish that in the end Maven will create the module descriptor based on this, but I still think we shouldn't do that)

I remembered reading something about this, and assumed it was the case if there was a module-info.class, but what if its a standard jar with an Automatic-Module-Name header? Does that fall into the module path or classpath? Having control for this case may be useful.

I recognize this wish. The best solution is to make the dependency optional.

The problem with this is that the dependency is still on the classpath for say surefire, which can influence behaviour.

Mark

"The ease with which a change can be implemented has no relevance at all to whether it is the right change for the (Java) Platform for all time." — Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt

 



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

ChrisGWarp
In reply to this post by michaelo
One more: Better support for classifiers. ideally be able to reference them
via a {$project.classifier} type of construct, esp so I can use/reference
them in assemble transformations.

This might be able to be done without bumping to V4 though.



On Sun, Nov 12, 2017 at 6:41 PM, Chris Graham <[hidden email]> wrote:

> required:
>  - *everything* in settings.xml can be put in a profile section in
> settings.xml.
>
> I often move around/between projects and having to redo mirrors section,
> and unable to add servers into the profile section for clarity is a pain.
>
> For me, it's just a matter of convienence.
>
> On Sat, Nov 4, 2017 at 11:20 PM, Stephen Connolly <
> [hidden email]> wrote:
>
>> The past two days, Hervé, Robert and I have been discussing our next
>> steps.
>>
>> I think we have a semi-consensus which I want to bring back to the list:
>>
>> We keep 3.5.x as a stable branch with critical bug fixes only
>>
>> We switch master to 4.0.0 and start to burn down a release scope.
>>
>> 4.0.0 will not change the pom modelVersion
>>
>> The 4.0.0 scope should probably be:
>>
>> Required:
>> * drop Java 7, switch codebase to Java 8 idioms (while maintaining binary
>> api compatibility for plugins)
>> * specify the classloader behaviour and fix impl to align with spec (may
>> need a plugin flag to allow plugins to opt in to spec behaviour)
>> * specify the extension spec
>> * allow limited mutation of the runtime model (reducing transitive
>> dependencies for consumers within the reactor, only for plugin goals that
>> declare intent) use case: shade plugin
>> * better CI integration hooks
>> * nice error message for newer pom modelVersion
>>
>> Optional:
>> * (damn I forgot, maybe Robert remembers)
>> --
>> Sent from my phone
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

stephenconnolly
Keep in mind, Maven is not the only pom consumer. Expression changes
outside the pom are probably fine. Expression changes inside the pom will
probably require the 4.0.0 (optional scope) feature to bring flatten Maven
plugin type features to first class core support (ie deploy the pom with
new properties resolved)

On Sun 12 Nov 2017 at 07:56, Chris Graham <[hidden email]> wrote:

> One more: Better support for classifiers. ideally be able to reference them
> via a {$project.classifier} type of construct, esp so I can use/reference
> them in assemble transformations.
>
> This might be able to be done without bumping to V4 though.
>
>
>
> On Sun, Nov 12, 2017 at 6:41 PM, Chris Graham <[hidden email]>
> wrote:
>
> > required:
> >  - *everything* in settings.xml can be put in a profile section in
> > settings.xml.
> >
> > I often move around/between projects and having to redo mirrors section,
> > and unable to add servers into the profile section for clarity is a pain.
> >
> > For me, it's just a matter of convienence.
> >
> > On Sat, Nov 4, 2017 at 11:20 PM, Stephen Connolly <
> > [hidden email]> wrote:
> >
> >> The past two days, Hervé, Robert and I have been discussing our next
> >> steps.
> >>
> >> I think we have a semi-consensus which I want to bring back to the list:
> >>
> >> We keep 3.5.x as a stable branch with critical bug fixes only
> >>
> >> We switch master to 4.0.0 and start to burn down a release scope.
> >>
> >> 4.0.0 will not change the pom modelVersion
> >>
> >> The 4.0.0 scope should probably be:
> >>
> >> Required:
> >> * drop Java 7, switch codebase to Java 8 idioms (while maintaining
> binary
> >> api compatibility for plugins)
> >> * specify the classloader behaviour and fix impl to align with spec (may
> >> need a plugin flag to allow plugins to opt in to spec behaviour)
> >> * specify the extension spec
> >> * allow limited mutation of the runtime model (reducing transitive
> >> dependencies for consumers within the reactor, only for plugin goals
> that
> >> declare intent) use case: shade plugin
> >> * better CI integration hooks
> >> * nice error message for newer pom modelVersion
> >>
> >> Optional:
> >> * (damn I forgot, maybe Robert remembers)
> >> --
> >> Sent from my phone
> >>
> >
> >
>
--
Sent from my phone