You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Stephen Connolly <st...@gmail.com> on 2017/11/04 12:20:18 UTC
Maven 4.0.0
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
Re: Maven 4.0.0
Posted by Tibor Digana <ti...@apache.org>.
I would like to have SCM Hook from CI or SCM Agent. Maven 4 should run only
changed modules similar to "mvn -pl...".
If we get a list of changed files, the Eclipse compiler might be faster and
then only tests for changed classes will run.
Then I would like to have clean and site executed on entire multi-module
project and not on individual modules like it is nowadays. Now when you run
"clean install site site:stage", all are run on every individual module. So
when site fails, the slowest was site and blocked more important install.
We should maybe introduce a new structure for BOM.
Another problem I struggle is transitive dependencies and their conflict.
Should a framework expose transitive dependencies?
Should we introduce a new scope like "abstract" and force the dependent POM
fail in validation phase if transitive dependency from f/w does not present
in App?
App (POM) ---[dependency]---> f/w(POM) ---[dependency with
scope=abstract]---> T :: transitive dep.(POM)
*abstract would be similar to scope=provided but the App POM must list the
dependency T.
It is fail-fast validation with abstract and then you do not need to use
maven-enforcer-plugin.
The T dependency appears very close to the root of dependency tree and
there would not be a conflict.
The T may come from company's BOM.
On Mon, Nov 13, 2017 at 11:19 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> 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 <jo...@bpm-inspire.com>:
> > 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: 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: Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <jo...@bpm-inspire.com>:
> 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: 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: Maven 4.0.0
Posted by Jörg Schaible <jo...@bpm-inspire.com>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
FYI opened https://github.com/apache/maven/pull/136 for the MNG-6302
(guess we can switch from thread to discuss it now?)
Romain Manni-Bucau
@rmannibucau | Blog | Old Blog | Github | LinkedIn
2017-11-09 9:30 GMT+01:00 Jörg Schaible <jo...@bpm-inspire.com>:
> 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: 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: Maven 4.0.0
Posted by Jörg Schaible <jo...@bpm-inspire.com>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <rm...@gmail.com>:
> Can't tackle it before next year but if not done in january sure.
>
>
> 2017-11-06 10:00 GMT+01:00 Stephen Connolly <st...@gmail.com>:
>> 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 <rm...@gmail.com>
>> 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 <rm...@gmail.com>
>>> > 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 <ec...@zusammenkunft.net>:
>>> >>
>>> >> > 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 <ma...@talios.com>
>>> >> > *Gesendet: *Sonntag, 5. November 2017 22:20
>>> >> > *An: *Maven Developers List <de...@maven.apache.org>
>>> >> > *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: dev-unsubscribe@maven.apache.org
>>> >> > For additional commands, e-mail: dev-help@maven.apache.org
>>> >> >
>>> >>
>>> > --
>>> > Sent from my phone
>>>
>>> ---------------------------------------------------------------------
>>> 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: Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Can't tackle it before next year but if not done in january sure.
2017-11-06 10:00 GMT+01:00 Stephen Connolly <st...@gmail.com>:
> 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 <rm...@gmail.com>
> 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 <rm...@gmail.com>
>> > 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 <ec...@zusammenkunft.net>:
>> >>
>> >> > 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 <ma...@talios.com>
>> >> > *Gesendet: *Sonntag, 5. November 2017 22:20
>> >> > *An: *Maven Developers List <de...@maven.apache.org>
>> >> > *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: dev-unsubscribe@maven.apache.org
>> >> > For additional commands, e-mail: dev-help@maven.apache.org
>> >> >
>> >>
>> > --
>> > Sent from my phone
>>
>> ---------------------------------------------------------------------
>> 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: Maven 4.0.0
Posted by Stephen Connolly <st...@gmail.com>.
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 <rm...@gmail.com>
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 <rm...@gmail.com>
> > 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 <ec...@zusammenkunft.net>:
> >>
> >> > 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 <ma...@talios.com>
> >> > *Gesendet: *Sonntag, 5. November 2017 22:20
> >> > *An: *Maven Developers List <de...@maven.apache.org>
> >> > *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: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >>
> > --
> > Sent from my phone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <st...@gmail.com>:
> On Mon 6 Nov 2017 at 08:13, Romain Manni-Bucau <rm...@gmail.com>
> 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 <ec...@zusammenkunft.net>:
>>
>> > 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 <ma...@talios.com>
>> > *Gesendet: *Sonntag, 5. November 2017 22:20
>> > *An: *Maven Developers List <de...@maven.apache.org>
>> > *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: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>>
> --
> Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0
Posted by Stephen Connolly <st...@gmail.com>.
On Mon 6 Nov 2017 at 08:13, Romain Manni-Bucau <rm...@gmail.com>
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 <ec...@zusammenkunft.net>:
>
> > 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 <ma...@talios.com>
> > *Gesendet: *Sonntag, 5. November 2017 22:20
> > *An: *Maven Developers List <de...@maven.apache.org>
> > *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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
--
Sent from my phone
Re: Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <ec...@zusammenkunft.net>:
> 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 <ma...@talios.com>
> *Gesendet: *Sonntag, 5. November 2017 22:20
> *An: *Maven Developers List <de...@maven.apache.org>
> *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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
AW: Maven 4.0.0
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
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
Gesendet: Sonntag, 5. November 2017 22:20
An: Maven Developers List
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
Re: Maven 4.0.0
Posted by Mark Derricutt <ma...@talios.com>.
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
Re: Maven 4.0.0
Posted by Robert Scholte <rf...@apache.org>.
On Sat, 04 Nov 2017 21:42:34 +0100, Mark Derricutt <ma...@talios.com> wrote:
> 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?
I would like to drop strict scopes in general and give plugins the
opportunity to depend on specific scoped dependencies.
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)
>
> 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.
I recognize this wish. The best solution is to make the dependency
optional.
>
> Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0
Posted by Mark Derricutt <ma...@talios.com>.
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 <
stephen.alan.connolly@gmail.com> 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
>
Re: Maven 4.0.0
Posted by Stephen Connolly <st...@gmail.com>.
On Sat 4 Nov 2017 at 12:24, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> On Sat 4 Nov 2017 at 12:20, Stephen Connolly <
> stephen.alan.connolly@gmail.com> 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
Re: Maven 4.0.0
Posted by Stephen Connolly <st...@gmail.com>.
On Sat 4 Nov 2017 at 12:20, Stephen Connolly <
stephen.alan.connolly@gmail.com> 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)
>
* incremental build
* concurrent safe local repo cache
> --
> Sent from my phone
>
--
Sent from my phone
Re: Maven 4.0.0
Posted by Stephen Connolly <st...@gmail.com>.
On Sat 4 Nov 2017 at 12:52, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> On Sat 4 Nov 2017 at 12:49, Michael Osipov <mi...@apache.org> wrote:
>
>> 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.
>
>
> We are going to ask the wider community to contribute PRs towards that
> goal, each PR limited to ~20 Lines of diff.
>
A diff this small on “obvious” (as in we’d be just as likely to come up
with the same or similar change if we looked at the method) changes does
not require a signed ICLA, just confirmation of grant in PR...
Should give a much lower barrier for getting started contributing
> We will need infrastructure to assure binary compatibility (like clirr
> used to do before it died) before we can start that effort.
>
> Aim is to find people willing to dive in and get them familiar with the
> code base by making many small low/no risk changes
>
>
>>
>> > * 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> --
> Sent from my phone
>
--
Sent from my phone
Re: Maven 4.0.0
Posted by Stephen Connolly <st...@gmail.com>.
On Sat 4 Nov 2017 at 12:49, Michael Osipov <mi...@apache.org> wrote:
> 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.
We are going to ask the wider community to contribute PRs towards that
goal, each PR limited to ~20 Lines of diff.
We will need infrastructure to assure binary compatibility (like clirr used
to do before it died) before we can start that effort.
Aim is to find people willing to dive in and get them familiar with the
code base by making many small low/no risk changes
>
> > * 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
Sent from my phone
Re: Maven 4.0.0
Posted by Michael Osipov <mi...@apache.org>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0
Posted by Stephen Connolly <st...@gmail.com>.
On Sat 4 Nov 2017 at 17:52, Hervé BOUTEMY <he...@free.fr> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
Sent from my phone
Re: Maven 4.0.0
Posted by Hervé BOUTEMY <he...@free.fr>.
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
Regards,
Hervé
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0
Posted by Robert Scholte <rf...@apache.org>.
On Sun, 05 Nov 2017 07:04:54 +0100, Hervé BOUTEMY <he...@free.fr>
wrote:
> 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
>>
>> <rm...@gmail.com> wrote:
>> > 2017-11-04 18:17 GMT+01:00 Stephen Connolly
>> >
>> > <st...@gmail.com>:
>> >> On Sat 4 Nov 2017 at 17:11, Romain Manni-Bucau
>> <rm...@gmail.com>
>> >>
>> >> 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)
So this issue is about a plugin being part of the buildplan AND being part
of the reactor.
I recognize the pro's and cons, but that deserves a separate mailthread to
discuss.
Robert
>
> Regards,
>
> Hervé
>
> ---------------------------------------------------------------------
> 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: Maven 4.0.0
Posted by Hervé BOUTEMY <he...@free.fr>.
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
>
> <rm...@gmail.com> wrote:
> > 2017-11-04 18:17 GMT+01:00 Stephen Connolly
> >
> > <st...@gmail.com>:
> >> On Sat 4 Nov 2017 at 17:11, Romain Manni-Bucau <rm...@gmail.com>
> >>
> >> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0
Posted by Robert Scholte <rf...@apache.org>.
On Sat, 04 Nov 2017 18:34:14 +0100, Romain Manni-Bucau
<rm...@gmail.com> wrote:
> 2017-11-04 18:17 GMT+01:00 Stephen Connolly
> <st...@gmail.com>:
>> On Sat 4 Nov 2017 at 17:11, Romain Manni-Bucau <rm...@gmail.com>
>> 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?
>
>>
>>
>>> - plugin sorting from the pom (current rules are deterministic but too
>>> hard
>>> to use so defining a dependency between two executions in the same
>>> phase
>>> would be very handy - depends-on tag?)
>>>
>>> As a plugin developper:
>>>
>>> - programmatic component lookup api (it is deprecated at the moment)
>>> - ability to contribute dependencies for next plugins/phases
>>> (resolvedArtifacts)
>>>
>>> Le 4 nov. 2017 17:03, "Stephen Connolly"
>>> <st...@gmail.com>
>>> a écrit :
>>>
>>> > On 4 November 2017 at 07:30, Hervé BOUTEMY <he...@free.fr>
>>> wrote:
>>> >
>>> > > Le samedi 4 novembre 2017, 14:43:46 CET John Patrick a écrit :
>>> > > > I've got a few updates I feel would be useful for the next major
>>> > > version;
>>> > > >
>>> > > > 1) Packaging type generic 'archive', or specific zip or tar.gz
>>> > > > - maybe a user property to enable zip and/or tar.gz
>>> > > >
>>> > > > 2) Packaging type generic 'application', or specific rpm or deb
>>> > > > - in future could be extended for windows installers too
>>> > > >
>>> > > > Over the past 6 years I've mainly created jar, war or ear, but
>>> for
>>> > > > deployment the standard is bundle it up into a tar.gz or zip,
>>> along
>>> > > > with the ansible scripts or custom scripts. So I usually use pom
>>> > > > packaging then adding assembly plugin, just feels strange doing
>>> that
>>> > > > all the time and it might make it more simpler for everyone.
>>> > > do you have some demos of such packagings?
>>> > >
>>> >
>>> > This feels like plugin level functionality. I am unclear how this
>>> needs
>>> > core changes. Could you provide details where you feel we need to
>>> modify
>>> > core for this (or is it you want to be able to fetch some artifacts
>>> from
>>> > within the zip, iow a zip with the other artifacts embedded and we
>>> "reach
>>> > in"?
>>> >
>>> >
>>> > >
>>> > > >
>>> > > > 3) Checksum, switch to SHA3, drop md5 and sha1. If we care about
>>> > > > security, we should keep up to date with what is considered
>>> secure
>>> > > > still.
>>> > > -1
>>> > > checksums are checksums, not security
>>> > > if you want security, don't look at checksums but at signatures
>>> > >
>>> > > This makes me think that we should find a way to show security
>>> (with
>>> > these
>>> > > signatures): I don't know precisely how, but that would definitely
>>> be
>>> > > useful
>>> > >
>>> > > >
>>> > > > 3) Debian style repo management. Instead of having a massive
>>> bucket
>>> of
>>> > > > artefacts, start having repo's either based upon java class
>>> version,
>>> > > > or maven major release version. Also split more than just
>>> release and
>>> > > > snapshot, maybe core, plugins, general...
>>> > > >
>>> > > > Not sure exactly the best solution, but as maven central has
>>> stuff
>>> > > > going back years and years. How much of the old stuff will be
>>> used
>>> for
>>> > > > new projects going forward.
>>> > > what's the objective?
>>> > > with Linux distributions, there are compatibility issues that
>>> require
>>> > > different artifacts, and an objective to keep distro on one CD/DVD
>>> > > But Java and central don't have such considerations
>>> > >
>>> > > >
>>> > > > Anyway, those are some of my thoughts, if their is a more formal
>>> way
>>> > > > of suggesting them let me know and I'll be happy to raise them
>>> > > > separately for consideration and maybe also do some pull
>>> requests for
>>> > > > them.
>>> > > I think the packaging ideas deserve some demos to see if something
>>> can
>>> be
>>> > > made
>>> > > generic enough
>>> > >
>>> > > Regards,
>>> > >
>>> > > Hervé
>>> > >
>>> > > >
>>> > > > John
>>> > > >
>>> > > > On 4 November 2017 at 13:18, Paul Hammant <pa...@hammant.org>
>>> 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"
>>> > > >
>>> > > >
>>> ---------------------------------------------------------------------
>>> > > > 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
>>> > >
>>> > >
>>> >
>>>
>> --
>> Sent from my phone
>
> ---------------------------------------------------------------------
> 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: Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2017-11-04 18:17 GMT+01:00 Stephen Connolly <st...@gmail.com>:
> On Sat 4 Nov 2017 at 17:11, Romain Manni-Bucau <rm...@gmail.com>
> 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.
>
>
>> - plugin sorting from the pom (current rules are deterministic but too hard
>> to use so defining a dependency between two executions in the same phase
>> would be very handy - depends-on tag?)
>>
>> As a plugin developper:
>>
>> - programmatic component lookup api (it is deprecated at the moment)
>> - ability to contribute dependencies for next plugins/phases
>> (resolvedArtifacts)
>>
>> Le 4 nov. 2017 17:03, "Stephen Connolly" <st...@gmail.com>
>> a écrit :
>>
>> > On 4 November 2017 at 07:30, Hervé BOUTEMY <he...@free.fr>
>> wrote:
>> >
>> > > Le samedi 4 novembre 2017, 14:43:46 CET John Patrick a écrit :
>> > > > I've got a few updates I feel would be useful for the next major
>> > > version;
>> > > >
>> > > > 1) Packaging type generic 'archive', or specific zip or tar.gz
>> > > > - maybe a user property to enable zip and/or tar.gz
>> > > >
>> > > > 2) Packaging type generic 'application', or specific rpm or deb
>> > > > - in future could be extended for windows installers too
>> > > >
>> > > > Over the past 6 years I've mainly created jar, war or ear, but for
>> > > > deployment the standard is bundle it up into a tar.gz or zip, along
>> > > > with the ansible scripts or custom scripts. So I usually use pom
>> > > > packaging then adding assembly plugin, just feels strange doing that
>> > > > all the time and it might make it more simpler for everyone.
>> > > do you have some demos of such packagings?
>> > >
>> >
>> > This feels like plugin level functionality. I am unclear how this needs
>> > core changes. Could you provide details where you feel we need to modify
>> > core for this (or is it you want to be able to fetch some artifacts from
>> > within the zip, iow a zip with the other artifacts embedded and we "reach
>> > in"?
>> >
>> >
>> > >
>> > > >
>> > > > 3) Checksum, switch to SHA3, drop md5 and sha1. If we care about
>> > > > security, we should keep up to date with what is considered secure
>> > > > still.
>> > > -1
>> > > checksums are checksums, not security
>> > > if you want security, don't look at checksums but at signatures
>> > >
>> > > This makes me think that we should find a way to show security (with
>> > these
>> > > signatures): I don't know precisely how, but that would definitely be
>> > > useful
>> > >
>> > > >
>> > > > 3) Debian style repo management. Instead of having a massive bucket
>> of
>> > > > artefacts, start having repo's either based upon java class version,
>> > > > or maven major release version. Also split more than just release and
>> > > > snapshot, maybe core, plugins, general...
>> > > >
>> > > > Not sure exactly the best solution, but as maven central has stuff
>> > > > going back years and years. How much of the old stuff will be used
>> for
>> > > > new projects going forward.
>> > > what's the objective?
>> > > with Linux distributions, there are compatibility issues that require
>> > > different artifacts, and an objective to keep distro on one CD/DVD
>> > > But Java and central don't have such considerations
>> > >
>> > > >
>> > > > Anyway, those are some of my thoughts, if their is a more formal way
>> > > > of suggesting them let me know and I'll be happy to raise them
>> > > > separately for consideration and maybe also do some pull requests for
>> > > > them.
>> > > I think the packaging ideas deserve some demos to see if something can
>> be
>> > > made
>> > > generic enough
>> > >
>> > > Regards,
>> > >
>> > > Hervé
>> > >
>> > > >
>> > > > John
>> > > >
>> > > > On 4 November 2017 at 13:18, Paul Hammant <pa...@hammant.org> 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"
>> > > >
>> > > > ---------------------------------------------------------------------
>> > > > 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
>> > >
>> > >
>> >
>>
> --
> Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0
Posted by Stephen Connolly <st...@gmail.com>.
On Sat 4 Nov 2017 at 17:11, Romain Manni-Bucau <rm...@gmail.com>
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+
And scripting is the path to the dark side of imperative builds... but
proposals welcome
> - plugin sorting from the pom (current rules are deterministic but too hard
> to use so defining a dependency between two executions in the same phase
> would be very handy - depends-on tag?)
>
> As a plugin developper:
>
> - programmatic component lookup api (it is deprecated at the moment)
> - ability to contribute dependencies for next plugins/phases
> (resolvedArtifacts)
>
> Le 4 nov. 2017 17:03, "Stephen Connolly" <st...@gmail.com>
> a écrit :
>
> > On 4 November 2017 at 07:30, Hervé BOUTEMY <he...@free.fr>
> wrote:
> >
> > > Le samedi 4 novembre 2017, 14:43:46 CET John Patrick a écrit :
> > > > I've got a few updates I feel would be useful for the next major
> > > version;
> > > >
> > > > 1) Packaging type generic 'archive', or specific zip or tar.gz
> > > > - maybe a user property to enable zip and/or tar.gz
> > > >
> > > > 2) Packaging type generic 'application', or specific rpm or deb
> > > > - in future could be extended for windows installers too
> > > >
> > > > Over the past 6 years I've mainly created jar, war or ear, but for
> > > > deployment the standard is bundle it up into a tar.gz or zip, along
> > > > with the ansible scripts or custom scripts. So I usually use pom
> > > > packaging then adding assembly plugin, just feels strange doing that
> > > > all the time and it might make it more simpler for everyone.
> > > do you have some demos of such packagings?
> > >
> >
> > This feels like plugin level functionality. I am unclear how this needs
> > core changes. Could you provide details where you feel we need to modify
> > core for this (or is it you want to be able to fetch some artifacts from
> > within the zip, iow a zip with the other artifacts embedded and we "reach
> > in"?
> >
> >
> > >
> > > >
> > > > 3) Checksum, switch to SHA3, drop md5 and sha1. If we care about
> > > > security, we should keep up to date with what is considered secure
> > > > still.
> > > -1
> > > checksums are checksums, not security
> > > if you want security, don't look at checksums but at signatures
> > >
> > > This makes me think that we should find a way to show security (with
> > these
> > > signatures): I don't know precisely how, but that would definitely be
> > > useful
> > >
> > > >
> > > > 3) Debian style repo management. Instead of having a massive bucket
> of
> > > > artefacts, start having repo's either based upon java class version,
> > > > or maven major release version. Also split more than just release and
> > > > snapshot, maybe core, plugins, general...
> > > >
> > > > Not sure exactly the best solution, but as maven central has stuff
> > > > going back years and years. How much of the old stuff will be used
> for
> > > > new projects going forward.
> > > what's the objective?
> > > with Linux distributions, there are compatibility issues that require
> > > different artifacts, and an objective to keep distro on one CD/DVD
> > > But Java and central don't have such considerations
> > >
> > > >
> > > > Anyway, those are some of my thoughts, if their is a more formal way
> > > > of suggesting them let me know and I'll be happy to raise them
> > > > separately for consideration and maybe also do some pull requests for
> > > > them.
> > > I think the packaging ideas deserve some demos to see if something can
> be
> > > made
> > > generic enough
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > >
> > > > John
> > > >
> > > > On 4 November 2017 at 13:18, Paul Hammant <pa...@hammant.org> 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"
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> > >
> > >
> >
>
--
Sent from my phone
Re: Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
My wishlist as a user would be:
- incremental build (based on scm is fine)
- some built in scripting (groovy based?)
- plugin sorting from the pom (current rules are deterministic but too hard
to use so defining a dependency between two executions in the same phase
would be very handy - depends-on tag?)
As a plugin developper:
- programmatic component lookup api (it is deprecated at the moment)
- ability to contribute dependencies for next plugins/phases
(resolvedArtifacts)
Le 4 nov. 2017 17:03, "Stephen Connolly" <st...@gmail.com>
a écrit :
> On 4 November 2017 at 07:30, Hervé BOUTEMY <he...@free.fr> wrote:
>
> > Le samedi 4 novembre 2017, 14:43:46 CET John Patrick a écrit :
> > > I've got a few updates I feel would be useful for the next major
> > version;
> > >
> > > 1) Packaging type generic 'archive', or specific zip or tar.gz
> > > - maybe a user property to enable zip and/or tar.gz
> > >
> > > 2) Packaging type generic 'application', or specific rpm or deb
> > > - in future could be extended for windows installers too
> > >
> > > Over the past 6 years I've mainly created jar, war or ear, but for
> > > deployment the standard is bundle it up into a tar.gz or zip, along
> > > with the ansible scripts or custom scripts. So I usually use pom
> > > packaging then adding assembly plugin, just feels strange doing that
> > > all the time and it might make it more simpler for everyone.
> > do you have some demos of such packagings?
> >
>
> This feels like plugin level functionality. I am unclear how this needs
> core changes. Could you provide details where you feel we need to modify
> core for this (or is it you want to be able to fetch some artifacts from
> within the zip, iow a zip with the other artifacts embedded and we "reach
> in"?
>
>
> >
> > >
> > > 3) Checksum, switch to SHA3, drop md5 and sha1. If we care about
> > > security, we should keep up to date with what is considered secure
> > > still.
> > -1
> > checksums are checksums, not security
> > if you want security, don't look at checksums but at signatures
> >
> > This makes me think that we should find a way to show security (with
> these
> > signatures): I don't know precisely how, but that would definitely be
> > useful
> >
> > >
> > > 3) Debian style repo management. Instead of having a massive bucket of
> > > artefacts, start having repo's either based upon java class version,
> > > or maven major release version. Also split more than just release and
> > > snapshot, maybe core, plugins, general...
> > >
> > > Not sure exactly the best solution, but as maven central has stuff
> > > going back years and years. How much of the old stuff will be used for
> > > new projects going forward.
> > what's the objective?
> > with Linux distributions, there are compatibility issues that require
> > different artifacts, and an objective to keep distro on one CD/DVD
> > But Java and central don't have such considerations
> >
> > >
> > > Anyway, those are some of my thoughts, if their is a more formal way
> > > of suggesting them let me know and I'll be happy to raise them
> > > separately for consideration and maybe also do some pull requests for
> > > them.
> > I think the packaging ideas deserve some demos to see if something can be
> > made
> > generic enough
> >
> > Regards,
> >
> > Hervé
> >
> > >
> > > John
> > >
> > > On 4 November 2017 at 13:18, Paul Hammant <pa...@hammant.org> 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"
> > >
> > > ---------------------------------------------------------------------
> > > 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: Maven 4.0.0
Posted by Stephen Connolly <st...@gmail.com>.
On 4 November 2017 at 07:30, Hervé BOUTEMY <he...@free.fr> wrote:
> Le samedi 4 novembre 2017, 14:43:46 CET John Patrick a écrit :
> > I've got a few updates I feel would be useful for the next major
> version;
> >
> > 1) Packaging type generic 'archive', or specific zip or tar.gz
> > - maybe a user property to enable zip and/or tar.gz
> >
> > 2) Packaging type generic 'application', or specific rpm or deb
> > - in future could be extended for windows installers too
> >
> > Over the past 6 years I've mainly created jar, war or ear, but for
> > deployment the standard is bundle it up into a tar.gz or zip, along
> > with the ansible scripts or custom scripts. So I usually use pom
> > packaging then adding assembly plugin, just feels strange doing that
> > all the time and it might make it more simpler for everyone.
> do you have some demos of such packagings?
>
This feels like plugin level functionality. I am unclear how this needs
core changes. Could you provide details where you feel we need to modify
core for this (or is it you want to be able to fetch some artifacts from
within the zip, iow a zip with the other artifacts embedded and we "reach
in"?
>
> >
> > 3) Checksum, switch to SHA3, drop md5 and sha1. If we care about
> > security, we should keep up to date with what is considered secure
> > still.
> -1
> checksums are checksums, not security
> if you want security, don't look at checksums but at signatures
>
> This makes me think that we should find a way to show security (with these
> signatures): I don't know precisely how, but that would definitely be
> useful
>
> >
> > 3) Debian style repo management. Instead of having a massive bucket of
> > artefacts, start having repo's either based upon java class version,
> > or maven major release version. Also split more than just release and
> > snapshot, maybe core, plugins, general...
> >
> > Not sure exactly the best solution, but as maven central has stuff
> > going back years and years. How much of the old stuff will be used for
> > new projects going forward.
> what's the objective?
> with Linux distributions, there are compatibility issues that require
> different artifacts, and an objective to keep distro on one CD/DVD
> But Java and central don't have such considerations
>
> >
> > Anyway, those are some of my thoughts, if their is a more formal way
> > of suggesting them let me know and I'll be happy to raise them
> > separately for consideration and maybe also do some pull requests for
> > them.
> I think the packaging ideas deserve some demos to see if something can be
> made
> generic enough
>
> Regards,
>
> Hervé
>
> >
> > John
> >
> > On 4 November 2017 at 13:18, Paul Hammant <pa...@hammant.org> 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"
> >
> > ---------------------------------------------------------------------
> > 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: Maven 4.0.0
Posted by Hervé BOUTEMY <he...@free.fr>.
Le samedi 4 novembre 2017, 14:43:46 CET John Patrick a écrit :
> I've got a few updates I feel would be useful for the next major version;
>
> 1) Packaging type generic 'archive', or specific zip or tar.gz
> - maybe a user property to enable zip and/or tar.gz
>
> 2) Packaging type generic 'application', or specific rpm or deb
> - in future could be extended for windows installers too
>
> Over the past 6 years I've mainly created jar, war or ear, but for
> deployment the standard is bundle it up into a tar.gz or zip, along
> with the ansible scripts or custom scripts. So I usually use pom
> packaging then adding assembly plugin, just feels strange doing that
> all the time and it might make it more simpler for everyone.
do you have some demos of such packagings?
>
> 3) Checksum, switch to SHA3, drop md5 and sha1. If we care about
> security, we should keep up to date with what is considered secure
> still.
-1
checksums are checksums, not security
if you want security, don't look at checksums but at signatures
This makes me think that we should find a way to show security (with these
signatures): I don't know precisely how, but that would definitely be useful
>
> 3) Debian style repo management. Instead of having a massive bucket of
> artefacts, start having repo's either based upon java class version,
> or maven major release version. Also split more than just release and
> snapshot, maybe core, plugins, general...
>
> Not sure exactly the best solution, but as maven central has stuff
> going back years and years. How much of the old stuff will be used for
> new projects going forward.
what's the objective?
with Linux distributions, there are compatibility issues that require
different artifacts, and an objective to keep distro on one CD/DVD
But Java and central don't have such considerations
>
> Anyway, those are some of my thoughts, if their is a more formal way
> of suggesting them let me know and I'll be happy to raise them
> separately for consideration and maybe also do some pull requests for
> them.
I think the packaging ideas deserve some demos to see if something can be made
generic enough
Regards,
Hervé
>
> John
>
> On 4 November 2017 at 13:18, Paul Hammant <pa...@hammant.org> 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"
>
> ---------------------------------------------------------------------
> 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: Maven 4.0.0
Posted by John Patrick <nh...@gmail.com>.
I've got a few updates I feel would be useful for the next major version;
1) Packaging type generic 'archive', or specific zip or tar.gz
- maybe a user property to enable zip and/or tar.gz
2) Packaging type generic 'application', or specific rpm or deb
- in future could be extended for windows installers too
Over the past 6 years I've mainly created jar, war or ear, but for
deployment the standard is bundle it up into a tar.gz or zip, along
with the ansible scripts or custom scripts. So I usually use pom
packaging then adding assembly plugin, just feels strange doing that
all the time and it might make it more simpler for everyone.
3) Checksum, switch to SHA3, drop md5 and sha1. If we care about
security, we should keep up to date with what is considered secure
still.
3) Debian style repo management. Instead of having a massive bucket of
artefacts, start having repo's either based upon java class version,
or maven major release version. Also split more than just release and
snapshot, maybe core, plugins, general...
Not sure exactly the best solution, but as maven central has stuff
going back years and years. How much of the old stuff will be used for
new projects going forward.
Anyway, those are some of my thoughts, if their is a more formal way
of suggesting them let me know and I'll be happy to raise them
separately for consideration and maybe also do some pull requests for
them.
John
On 4 November 2017 at 13:18, Paul Hammant <pa...@hammant.org> 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"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0
Posted by Stephen Connolly <st...@gmail.com>.
On Sat 4 Nov 2017 at 13:18, Paul Hammant <pa...@hammant.org> 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
Re: Maven 4.0.0
Posted by Paul Hammant <pa...@hammant.org>.
>
>
>
> >
> > *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"
Re: Maven 4.0.0
Posted by Stephen Connolly <st...@gmail.com>.
On Sat 4 Nov 2017 at 12:50, Paul Hammant <pa...@hammant.org> wrote:
> To add to scope for Maven 4, IMO:
>
> *1. <dependency> tag could have an optional <repo-list> arg:*
>
> <dependency>
> <repo-list>my-team,mycorp</repo-list>
> <groupId>com.thoughtworks.xstream</groupId>
> <artifactId>xstream</artifactId>
> <version>1.4.10</version>
> </dependency>
No. We are pushing pom model changes to 5.0.0 (as modelVersion 4.0.0 aligns
with Maven version)
Aim is to build a platform from which 5.0.0 can be launched
>
>
> In the above, central is not checked at all. my-team and my-corp are
> defined elsewhere.
>
> *2. GAV as a first class thing (optional):*
>
> <dependency>
> <gav>com.thoughtworks.xstream:xstream:1.4.10</gav>
> </dependency>
>
> or
>
> <dependency gav="com.thoughtworks.xstream:xstream:1.4.10"/>
>
>
> For the first time ever people could do simple ack/ag/grep thru source
> bases looking for things.
No, requires modelVersion bump. Out of scope for 4.0.0
>
> *3. More pluggable dependency resolver:*
>
> I might want alternate places to source JARs from that are *not* HTTP
> mounted system that match the Maven2 directory structure.
>
> Like here - https://github.com/paul-hammant/xstream-jar/releases (and
> associated blog entry -
> https://paulhammant.com/2017/05/13/maven-central-as-multiple-git-repos/)
>
> In particular I need to rework the jar as it is pulled into the local
> ~/.m2/repository cache - there's a root directory to remove.
I am willing to let this be optional scope for now. May be yanked if too
risky or not ready in time
>
> - Paul
>
--
Sent from my phone
Re: Maven 4.0.0
Posted by Paul Hammant <pa...@hammant.org>.
To add to scope for Maven 4, IMO:
*1. <dependency> tag could have an optional <repo-list> arg:*
<dependency>
<repo-list>my-team,mycorp</repo-list>
<groupId>com.thoughtworks.xstream</groupId>
<artifactId>xstream</artifactId>
<version>1.4.10</version>
</dependency>
In the above, central is not checked at all. my-team and my-corp are
defined elsewhere.
*2. GAV as a first class thing (optional):*
<dependency>
<gav>com.thoughtworks.xstream:xstream:1.4.10</gav>
</dependency>
or
<dependency gav="com.thoughtworks.xstream:xstream:1.4.10"/>
For the first time ever people could do simple ack/ag/grep thru source
bases looking for things.
*3. More pluggable dependency resolver:*
I might want alternate places to source JARs from that are *not* HTTP
mounted system that match the Maven2 directory structure.
Like here - https://github.com/paul-hammant/xstream-jar/releases (and
associated blog entry -
https://paulhammant.com/2017/05/13/maven-central-as-multiple-git-repos/)
In particular I need to rework the jar as it is pulled into the local
~/.m2/repository cache - there's a root directory to remove.
- Paul
Re: Maven 4.0.0
Posted by Stephen Connolly <st...@gmail.com>.
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 <ch...@gmail.com> 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 <ch...@gmail.com>
> 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 <
> > stephen.alan.connolly@gmail.com> 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
Re: Maven 4.0.0
Posted by Chris Graham <ch...@gmail.com>.
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 <ch...@gmail.com> 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 <
> stephen.alan.connolly@gmail.com> 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
>>
>
>
Re: Maven 4.0.0
Posted by Mark Derricutt <ma...@talios.com>.
On 12 Nov 2017, at 23:06, Stephen Connolly wrote:
> That could end up duplicating the local repo cache... unless we default the
> cache to ~/.m2/repository anyway... otoh a concurrency safe local repo
> cache may mandate a new location... but double the downloads for inter-op
> with older Maven installs on the same machine seems not so good to me.
If we're talking restructuring the local repo, I've long wanting to separate out locally "mvn install"'d items from those downloaded, essentially this would keep ( for the most part ) local SNAPSHOTs separate from anything downloaded.
I guess what I really want there is a local releases/snaphshots repo separation, often it's handy to just blow away all snapshots and rebuild into a known state. It does make for more complexity tho.
---
"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
Re: Maven 4.0.0
Posted by Stephen Connolly <st...@gmail.com>.
On Sun 12 Nov 2017 at 07:41, Chris Graham <ch...@gmail.com> 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.
>
So one of the issues with that is multiple Maven versions.
Once we change the settings schema, we either need to have two settings
files or we block older Maven versions sharing the settings file with newer
versions.
Now maybe for 4.0.0 we move to a ~/.m4 directory or ~/.maven
That could end up duplicating the local repo cache... unless we default the
cache to ~/.m2/repository anyway... otoh a concurrency safe local repo
cache may mandate a new location... but double the downloads for inter-op
with older Maven installs on the same machine seems not so good to me.
> On Sat, Nov 4, 2017 at 11:20 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> 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
Re: Maven 4.0.0
Posted by Chris Graham <ch...@gmail.com>.
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 <
stephen.alan.connolly@gmail.com> 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
>