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

Mark Derricutt
Would adding support for 2 new scopes be viable without changing the pom
model ( the DTD/XSD doesn't actually define the values so that should be
ok).

Specifically I'm thinking 'annotation' ( having annotationPaths on m-c-p
was a workaround, but kinda horrible in practice ), and maybe "module" for
the new module path?

On the topic of scopes, I'd love to see an _actual_ compile-time-only
scope, thats only at compilation.  I wonder, since the scope values are not
actually set in the DTD/XSDs, could the internals be altered to say a CSV
of scopes, with the default being "compile,test" which would cover current
behaviour - but if you specifically say "this is a compile only dependency"
then it literally is.

Mark

--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

On Sun, Nov 5, 2017 at 1:20 AM, 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

Hervé BOUTEMY
Le samedi 4 novembre 2017, 22:35:35 CET Robert Scholte a écrit :

> On Sat, 04 Nov 2017 18:34:14 +0100, Romain Manni-Bucau
>
> <[hidden email]> wrote:
> > 2017-11-04 18:17 GMT+01:00 Stephen Connolly
> >
> > <[hidden email]>:
> >> On Sat 4 Nov 2017 at 17:11, Romain Manni-Bucau <[hidden email]>
> >>
> >> wrote:
> >>> My wishlist as a user would be:
> >>>
> >>> - incremental build (based on scm is fine)
> >>> - some built in scripting (groovy based?)
> >>
> >> I have a worry for groovy with Java 9+
> >
> > Understand, here is the long version of that wish:
> >
> > 1. java -> groovy is very doable (compared to other language) so it is
> > the natural language for maven IMHO
> > 2. groovy will have to support Java 9 - to be honest I worry as much
> > for a plain java lib than for groovy so guess it is 1-1
> > 3. I'm happy to have a java scripting alternative (src/build/java)
> > which is not available outside the scope of a plugin (= no inherited
> > in compile or test scopes)
> >
> >> 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
> > but today you must release the mojo before using it in your build
> > which imposes to use scripting.
>
> sounds like https://issues.apache.org/jira/browse/MNG-6118
> right?

no: MNG-6118 is about restrictions where a plugin mojo runs

here, it's about using a plugin *from the reactor*: sure, there is a
restriction because the plugin module has to be built first, to be available
for other modules consumption, but it's just a consequence of the need, not
really a goal per se (unlike MNG-6118)

Regards,

Hervé

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

Romain Manni-Bucau
In reply to this post by Mark Derricutt
Forgot a user wish feature: some progress logging somehow. On "big" project
(actually on project logging a lot) you are easily lost on the progress,
you know current module is X but you don't know anymore if it is 50% of the
build or 5%. Having at least "module X / Y" would be helpful. IMO it is
enough to log it with the module name:

[INFO]
------------------------------------------------------------------------
[INFO] Building Foo 1.0.0-SNAPSHOT
[INFO]
------------------------------------------------------------------------
[INFO] Module 10 / 100





Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau>

2017-11-05 22:27 GMT+01:00 Bernd Eckenfels <[hidden email]>:

> 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: *Mark Derricutt <[hidden email]>
> *Gesendet: *Sonntag, 5. November 2017 22:20
> *An: *Maven Developers List <[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

Romain Manni-Bucau
indeed: https://issues.apache.org/jira/browse/MNG-6302

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn


2017-11-06 9:37 GMT+01:00 Stephen Connolly <[hidden email]>:

> On Mon 6 Nov 2017 at 08:13, Romain Manni-Bucau <[hidden email]>
> wrote:
>
>> Forgot a user wish feature: some progress logging somehow. On "big" project
>> (actually on project logging a lot) you are easily lost on the progress,
>> you know current module is X but you don't know anymore if it is 50% of the
>> build or 5%. Having at least "module X / Y" would be helpful. IMO it is
>> enough to log it with the module name:
>>
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Building Foo 1.0.0-SNAPSHOT
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Module 10 / 100
>>
>
> Can you file a JIRA?
>
>>
>>
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau>
>>
>> 2017-11-05 22:27 GMT+01:00 Bernd Eckenfels <[hidden email]>:
>>
>> > 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: *Mark Derricutt <[hidden email]>
>> > *Gesendet: *Sonntag, 5. November 2017 22:20
>> > *An: *Maven Developers List <[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]
>> >
>>
> --
> Sent from my phone

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

Romain Manni-Bucau
Can't tackle it before next year but if not done in january sure.


2017-11-06 10:00 GMT+01:00 Stephen Connolly <[hidden email]>:

> FYI this seems something that doesnt need to wait for 4.0.0
>
> If there was a PR for this and enough other small changes I'd be happy to
> roll a 3.5.3
>
> Do you want to take a stab at it?
>
> (only complexity might be parallel execution, but we could just report the
> linear plan number and when in parallel also log how many have completed)
>
> On 6 November 2017 at 00:51, Romain Manni-Bucau <[hidden email]>
> wrote:
>
>> indeed: https://issues.apache.org/jira/browse/MNG-6302
>>
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>>
>>
>> 2017-11-06 9:37 GMT+01:00 Stephen Connolly <stephen.alan.connolly@gmail.
>> com>:
>> > On Mon 6 Nov 2017 at 08:13, Romain Manni-Bucau <[hidden email]>
>> > wrote:
>> >
>> >> Forgot a user wish feature: some progress logging somehow. On "big"
>> project
>> >> (actually on project logging a lot) you are easily lost on the progress,
>> >> you know current module is X but you don't know anymore if it is 50% of
>> the
>> >> build or 5%. Having at least "module X / Y" would be helpful. IMO it is
>> >> enough to log it with the module name:
>> >>
>> >> [INFO]
>> >> ------------------------------------------------------------
>> ------------
>> >> [INFO] Building Foo 1.0.0-SNAPSHOT
>> >> [INFO]
>> >> ------------------------------------------------------------
>> ------------
>> >> [INFO] Module 10 / 100
>> >>
>> >
>> > Can you file a JIRA?
>> >
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Romain Manni-Bucau
>> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> >> <https://rmannibucau.metawerx.net/> | Old Blog
>> >> <http://rmannibucau.wordpress.com> | Github <
>> >> https://github.com/rmannibucau> |
>> >> LinkedIn <https://www.linkedin.com/in/rmannibucau>
>> >>
>> >> 2017-11-05 22:27 GMT+01:00 Bernd Eckenfels <[hidden email]>:
>> >>
>> >> > 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: *Mark Derricutt <[hidden email]>
>> >> > *Gesendet: *Sonntag, 5. November 2017 22:20
>> >> > *An: *Maven Developers List <[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]
>> >> >
>> >>
>> > --
>> > Sent from my phone
>>
>> ---------------------------------------------------------------------
>> 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]

Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

Romain Manni-Bucau
Another good feedback from beam (they did a PoC using gradle and are
signigicantly faster with gradle): being able to parallelize some
plugins (like checkstyle/findbugs/pmd) can be beneficial to the
overall soft.

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn


2017-11-06 11:16 GMT+01:00 Romain Manni-Bucau <[hidden email]>:

> Can't tackle it before next year but if not done in january sure.
>
>
> 2017-11-06 10:00 GMT+01:00 Stephen Connolly <[hidden email]>:
>> FYI this seems something that doesnt need to wait for 4.0.0
>>
>> If there was a PR for this and enough other small changes I'd be happy to
>> roll a 3.5.3
>>
>> Do you want to take a stab at it?
>>
>> (only complexity might be parallel execution, but we could just report the
>> linear plan number and when in parallel also log how many have completed)
>>
>> On 6 November 2017 at 00:51, Romain Manni-Bucau <[hidden email]>
>> wrote:
>>
>>> indeed: https://issues.apache.org/jira/browse/MNG-6302
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>>>
>>>
>>> 2017-11-06 9:37 GMT+01:00 Stephen Connolly <stephen.alan.connolly@gmail.
>>> com>:
>>> > On Mon 6 Nov 2017 at 08:13, Romain Manni-Bucau <[hidden email]>
>>> > wrote:
>>> >
>>> >> Forgot a user wish feature: some progress logging somehow. On "big"
>>> project
>>> >> (actually on project logging a lot) you are easily lost on the progress,
>>> >> you know current module is X but you don't know anymore if it is 50% of
>>> the
>>> >> build or 5%. Having at least "module X / Y" would be helpful. IMO it is
>>> >> enough to log it with the module name:
>>> >>
>>> >> [INFO]
>>> >> ------------------------------------------------------------
>>> ------------
>>> >> [INFO] Building Foo 1.0.0-SNAPSHOT
>>> >> [INFO]
>>> >> ------------------------------------------------------------
>>> ------------
>>> >> [INFO] Module 10 / 100
>>> >>
>>> >
>>> > Can you file a JIRA?
>>> >
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> Romain Manni-Bucau
>>> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>> >> <https://rmannibucau.metawerx.net/> | Old Blog
>>> >> <http://rmannibucau.wordpress.com> | Github <
>>> >> https://github.com/rmannibucau> |
>>> >> LinkedIn <https://www.linkedin.com/in/rmannibucau>
>>> >>
>>> >> 2017-11-05 22:27 GMT+01:00 Bernd Eckenfels <[hidden email]>:
>>> >>
>>> >> > 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: *Mark Derricutt <[hidden email]>
>>> >> > *Gesendet: *Sonntag, 5. November 2017 22:20
>>> >> > *An: *Maven Developers List <[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]
>>> >> >
>>> >>
>>> > --
>>> > Sent from my phone
>>>
>>> ---------------------------------------------------------------------
>>> 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]

Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

Jörg Schaible-5
In reply to this post by Mark Derricutt
Hi,

one wish: Better integration with pom-less Tycho projects.

Currently it is not possible to run Maven and use standard Maven-based
and pom-less Tycho-based projects in one reactor if the Tycho projects
have dependencies on the Maven-based projects.

AFAICS the problem is that Polyglott is used to generate the temporary
POMs out of the MANIFEST.MF on the fly, but the reactor-phase has already
passed that calculates the build order.

It would be nice to adjust Maven Core in a way that allows such
extensions contribute to the build order.

Cheers,
Jörg


Am Sat, 04 Nov 2017 12:20:18 +0000 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)
> * 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)



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

Romain Manni-Bucau
Hi Jörg, fully unrelated (cross topic). About tycho I often end up
doing a custom script hacking the resolvedArtifacts and using a local
cache (m2 fake repo) because tycho plugin is way to slow in practise.
It can look like
https://github.com/Talend/component-runtime/blob/master/component-studio-integration/src/build/StudioDependencies.groovy#L27
(which transitive deps support but it is not that hard to add).

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn


2017-11-13 11:11 GMT+01:00 Jörg Schaible <[hidden email]>:

> Hi Romain,
>
> Am Thu, 09 Nov 2017 09:32:12 +0100 schrieb Romain Manni-Bucau:
>
>> FYI opened https://github.com/apache/maven/pull/136 for the MNG-6302
>> (guess we can switch from thread to discuss it now?)
>
> How is this issue related with my topic regarding improved Tycho support
> in Maven 4.0.0?
>
> Regards,
> Jörg
>
>
> ---------------------------------------------------------------------
> 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]