Maven 4.0.0

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

Maven 4.0.0

stephenconnolly
The past two days, Hervé, Robert and I have been discussing our next steps.

I think we have a semi-consensus which I want to bring back to the list:

We keep 3.5.x as a stable branch with critical bug fixes only

We switch master to 4.0.0 and start to burn down a release scope.

4.0.0 will not change the pom modelVersion

The 4.0.0 scope should probably be:

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

Optional:
* (damn I forgot, maybe Robert remembers)
--
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

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

> The past two days, Hervé, Robert and I have been discussing our next steps.
>
> I think we have a semi-consensus which I want to bring back to the list:
>
> We keep 3.5.x as a stable branch with critical bug fixes only
>
> We switch master to 4.0.0 and start to burn down a release scope.
>
> 4.0.0 will not change the pom modelVersion
>
> The 4.0.0 scope should probably be:
>
> Required:
> * drop Java 7, switch codebase to Java 8 idioms (while maintaining binary
> api compatibility for plugins)
> * specify the classloader behaviour and fix impl to align with spec (may
> need a plugin flag to allow plugins to opt in to spec behaviour)
> * specify the extension spec
> * allow limited mutation of the runtime model (reducing transitive
> dependencies for consumers within the reactor, only for plugin goals that
> declare intent) use case: shade plugin
> * better CI integration hooks
> * nice error message for newer pom modelVersion
>
> Optional:
> * (damn I forgot, maybe Robert remembers)
>
* incremental build
* concurrent safe local repo cache

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

Re: Maven 4.0.0

stephenconnolly
In reply to this post by stephenconnolly
On Sat 4 Nov 2017 at 12:49, Michael Osipov <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

John Patrick
In reply to this post by stephenconnolly
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 <[hidden email]> wrote:

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

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

Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

stephenconnolly
On 4 November 2017 at 07:30, Hervé BOUTEMY <[hidden email]> 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 <[hidden email]> wrote:
> > >> > *3. More pluggable dependency resolver:*
> > >>
> > >> I am willing to let this be optional scope for now. May be yanked if
> too
> > >> risky or not ready in time
> > >
> > > I don't see how you can even make it optional without a pom specified
> way
> > > of saying "not maven central, this way/place instead"
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

stephenconnolly
On Sat 4 Nov 2017 at 17:11, Romain Manni-Bucau <[hidden email]>
wrote:

> My wishlist as a user would be:
>
> - incremental build (based on scm is fine)
> - some built in scripting (groovy based?)


I have a worry for groovy with Java 9+

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" <[hidden email]>
> a écrit :
>
> > On 4 November 2017 at 07:30, Hervé BOUTEMY <[hidden email]>
> 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 <[hidden email]> wrote:
> > > > >> > *3. More pluggable dependency resolver:*
> > > > >>
> > > > >> I am willing to let this be optional scope for now. May be yanked
> if
> > > too
> > > > >> risky or not ready in time
> > > > >
> > > > > I don't see how you can even make it optional without a pom
> specified
> > > way
> > > > > of saying "not maven central, this way/place instead"
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
>
--
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

Hervé BOUTEMY
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

rfscholte
In reply to this post by stephenconnolly
On Sat, 04 Nov 2017 21:42:34 +0100, Mark Derricutt <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

rfscholte
In reply to this post by stephenconnolly
On Sun, 05 Nov 2017 07:04:54 +0100, Hervé BOUTEMY <[hidden email]>  
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
>>
>> <[hidden email]> wrote:
>> > 2017-11-04 18:17 GMT+01:00 Stephen Connolly
>> >
>> > <[hidden email]>:
>> >> On Sat 4 Nov 2017 at 17:11, Romain Manni-Bucau  
>> <[hidden email]>
>> >>
>> >> wrote:
>> >>> My wishlist as a user would be:
>> >>>
>> >>> - incremental build (based on scm is fine)
>> >>> - some built in scripting (groovy based?)
>> >>
>> >> I have a worry for groovy with Java 9+
>> >
>> > Understand, here is the long version of that wish:
>> >
>> > 1. java -> groovy is very doable (compared to other language) so it is
>> > the natural language for maven IMHO
>> > 2. groovy will have to support Java 9 - to be honest I worry as much
>> > for a plain java lib than for groovy so guess it is 1-1
>> > 3. I'm happy to have a java scripting alternative (src/build/java)
>> > which is not available outside the scope of a plugin (= no inherited
>> > in compile or test scopes)
>> >
>> >> And scripting is the path to the dark side of imperative builds...  
>> but
>> >> proposals welcome
>> >
>> > This is true but this is also mandatory today. There is a small
>> > alternative to that and I would be as happy if maven can do it:
>> > support mojo from the reactor (ie having a project with this layout:
>> > parent/[module1, my-maven-plugin]). If this works then no need of
>> > scripting
>> > but today you must release the mojo before using it in your build
>> > which imposes to use scripting.
>>
>> sounds like https://issues.apache.org/jira/browse/MNG-6118
>> right?
>
> no: MNG-6118 is about restrictions where a plugin mojo runs
>
> here, it's about using a plugin *from the reactor*: sure, there is a
> restriction because the plugin module has to be built first, to be  
> available
> for other modules consumption, but it's just a consequence of the need,  
> not
> really a goal per se (unlike MNG-6118)

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: [hidden email]
> For additional commands, e-mail: [hidden email]

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

Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

stephenconnolly
In reply to this post by rfscholte
On Mon 6 Nov 2017 at 08:13, Romain Manni-Bucau <[hidden email]>
wrote:

> Forgot a user wish feature: some progress logging somehow. On "big" project
> (actually on project logging a lot) you are easily lost on the progress,
> you know current module is X but you don't know anymore if it is 50% of the
> build or 5%. Having at least "module X / Y" would be helpful. IMO it is
> enough to log it with the module name:
>
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building Foo 1.0.0-SNAPSHOT
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Module 10 / 100
>

Can you file a JIRA?

>
>
>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau>
>
> 2017-11-05 22:27 GMT+01:00 Bernd Eckenfels <[hidden email]>:
>
> > Hello,
> >
> >
> >
> > Adding annotations and processor as a compiletime dependency sounds like
> a
> > reasonable thing. It would however be cool if the JAR could describe
> which
> > package needs to go on the classpath and which is processor impl. (and
> > having a different artifact for runtime)
> >
> >
> >
> > Gruss
> >
> > Bernd
> >
> >
> >
> > *Von: *Mark Derricutt <[hidden email]>
> > *Gesendet: *Sonntag, 5. November 2017 22:20
> > *An: *Maven Developers List <[hidden email]>
> > *Betreff: *Re: Maven 4.0.0
> >
> >
> >
> > On 5 Nov 2017, at 10:42, Robert Scholte wrote:
> >
> > I would like to drop strict scopes in general and give plugins the
> > opportunity to depend on
> > specific scoped dependencies.
> >
> > How would this help with annotations tho? The main issue I'm facing is
> > having a standard m-c-p plugin definition in a parent ( or tile ) but
> > needing different annotation processors used per project. With the
> current
> > plugin, this means either listing them as standard dependencies and have
> > them auto-scanned, and pollute the compilation classpath, or list every
> > possible annotation processor dependency we may use in our projects in
> the
> > parent, which is less than ideal.
> >
> > I hope you are aware that modules already end up on the modulepath based
> > on the moduledescriptor(s). So I don't see the need for this scope.
> (unless
> > you have this wish that in the end Maven will create the module
> descriptor
> > based on this, but I still think we shouldn't do that)
> >
> > I remembered reading something about this, and assumed it was the case if
> > there was a module-info.class, but what if its a standard jar with an
> > Automatic-Module-Name header? Does that fall into the module path or
> > classpath? Having control for this case may be useful.
> >
> > I recognize this wish. The best solution is to make the dependency
> > optional.
> >
> > The problem with this is that the dependency is still on the classpath
> for
> > say surefire, which can influence behaviour.
> >
> > Mark
> >
> > "The ease with which a change can be implemented has no relevance at all
> > to whether it is the right change for the (Java) Platform for all time."
> —
> > Mark Reinhold.
> >
> > Mark Derricutt
> > http://www.theoryinpractice.net
> > http://www.chaliceofblood.net
> > http://plus.google.com/+MarkDerricutt
> > http://twitter.com/talios
> > http://facebook.com/mderricutt
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
--
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

stephenconnolly
FYI this seems something that doesnt need to wait for 4.0.0

If there was a PR for this and enough other small changes I'd be happy to
roll a 3.5.3

Do you want to take a stab at it?

(only complexity might be parallel execution, but we could just report the
linear plan number and when in parallel also log how many have completed)

On 6 November 2017 at 00:51, Romain Manni-Bucau <[hidden email]>
wrote:

> indeed: https://issues.apache.org/jira/browse/MNG-6302
>
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>
>
> 2017-11-06 9:37 GMT+01:00 Stephen Connolly <stephen.alan.connolly@gmail.
> com>:
> > On Mon 6 Nov 2017 at 08:13, Romain Manni-Bucau <[hidden email]>
> > wrote:
> >
> >> Forgot a user wish feature: some progress logging somehow. On "big"
> project
> >> (actually on project logging a lot) you are easily lost on the progress,
> >> you know current module is X but you don't know anymore if it is 50% of
> the
> >> build or 5%. Having at least "module X / Y" would be helpful. IMO it is
> >> enough to log it with the module name:
> >>
> >> [INFO]
> >> ------------------------------------------------------------
> ------------
> >> [INFO] Building Foo 1.0.0-SNAPSHOT
> >> [INFO]
> >> ------------------------------------------------------------
> ------------
> >> [INFO] Module 10 / 100
> >>
> >
> > Can you file a JIRA?
> >
> >>
> >>
> >>
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> <https://rmannibucau.metawerx.net/> | Old Blog
> >> <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn <https://www.linkedin.com/in/rmannibucau>
> >>
> >> 2017-11-05 22:27 GMT+01:00 Bernd Eckenfels <[hidden email]>:
> >>
> >> > Hello,
> >> >
> >> >
> >> >
> >> > Adding annotations and processor as a compiletime dependency sounds
> like
> >> a
> >> > reasonable thing. It would however be cool if the JAR could describe
> >> which
> >> > package needs to go on the classpath and which is processor impl. (and
> >> > having a different artifact for runtime)
> >> >
> >> >
> >> >
> >> > Gruss
> >> >
> >> > Bernd
> >> >
> >> >
> >> >
> >> > *Von: *Mark Derricutt <[hidden email]>
> >> > *Gesendet: *Sonntag, 5. November 2017 22:20
> >> > *An: *Maven Developers List <[hidden email]>
> >> > *Betreff: *Re: Maven 4.0.0
> >> >
> >> >
> >> >
> >> > On 5 Nov 2017, at 10:42, Robert Scholte wrote:
> >> >
> >> > I would like to drop strict scopes in general and give plugins the
> >> > opportunity to depend on
> >> > specific scoped dependencies.
> >> >
> >> > How would this help with annotations tho? The main issue I'm facing is
> >> > having a standard m-c-p plugin definition in a parent ( or tile ) but
> >> > needing different annotation processors used per project. With the
> >> current
> >> > plugin, this means either listing them as standard dependencies and
> have
> >> > them auto-scanned, and pollute the compilation classpath, or list
> every
> >> > possible annotation processor dependency we may use in our projects in
> >> the
> >> > parent, which is less than ideal.
> >> >
> >> > I hope you are aware that modules already end up on the modulepath
> based
> >> > on the moduledescriptor(s). So I don't see the need for this scope.
> >> (unless
> >> > you have this wish that in the end Maven will create the module
> >> descriptor
> >> > based on this, but I still think we shouldn't do that)
> >> >
> >> > I remembered reading something about this, and assumed it was the
> case if
> >> > there was a module-info.class, but what if its a standard jar with an
> >> > Automatic-Module-Name header? Does that fall into the module path or
> >> > classpath? Having control for this case may be useful.
> >> >
> >> > I recognize this wish. The best solution is to make the dependency
> >> > optional.
> >> >
> >> > The problem with this is that the dependency is still on the classpath
> >> for
> >> > say surefire, which can influence behaviour.
> >> >
> >> > Mark
> >> >
> >> > "The ease with which a change can be implemented has no relevance at
> all
> >> > to whether it is the right change for the (Java) Platform for all
> time."
> >> —
> >> > Mark Reinhold.
> >> >
> >> > Mark Derricutt
> >> > http://www.theoryinpractice.net
> >> > http://www.chaliceofblood.net
> >> > http://plus.google.com/+MarkDerricutt
> >> > http://twitter.com/talios
> >> > http://facebook.com/mderricutt
> >> >
> >> >
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [hidden email]
> >> > For additional commands, e-mail: [hidden email]
> >> >
> >>
> > --
> > Sent from my phone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

stephenconnolly
In reply to this post by stephenconnolly
On Sun 12 Nov 2017 at 07:41, Chris Graham <[hidden email]> wrote:

> required:
>  - *everything* in settings.xml can be put in a profile section in
> settings.xml.
>
> I often move around/between projects and having to redo mirrors section,
> and unable to add servers into the profile section for clarity is a pain.
>
> For me, it's just a matter of convienence.
>

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 <
> [hidden email]> wrote:
>
> > The past two days, Hervé, Robert and I have been discussing our next
> steps.
> >
> > I think we have a semi-consensus which I want to bring back to the list:
> >
> > We keep 3.5.x as a stable branch with critical bug fixes only
> >
> > We switch master to 4.0.0 and start to burn down a release scope.
> >
> > 4.0.0 will not change the pom modelVersion
> >
> > The 4.0.0 scope should probably be:
> >
> > Required:
> > * drop Java 7, switch codebase to Java 8 idioms (while maintaining binary
> > api compatibility for plugins)
> > * specify the classloader behaviour and fix impl to align with spec (may
> > need a plugin flag to allow plugins to opt in to spec behaviour)
> > * specify the extension spec
> > * allow limited mutation of the runtime model (reducing transitive
> > dependencies for consumers within the reactor, only for plugin goals that
> > declare intent) use case: shade plugin
> > * better CI integration hooks
> > * nice error message for newer pom modelVersion
> >
> > Optional:
> > * (damn I forgot, maybe Robert remembers)
> > --
> > Sent from my phone
> >
>
--
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

Jörg Schaible-5
In reply to this post by stephenconnolly
Hi Romain,

Am Thu, 09 Nov 2017 09:32:12 +0100 schrieb Romain Manni-Bucau:

> FYI opened https://github.com/apache/maven/pull/136 for the MNG-6302
> (guess we can switch from thread to discuss it now?)

How is this issue related with my topic regarding improved Tycho support
in Maven 4.0.0?

Regards,
Jörg


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

Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

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