Re: maven 4.0.0 new XML stuff

[Matthieu Brouillard]

> Created https://issues.apache.org/jira/browse/MNG-7067 to start, now we
have an umbrella let's refine the description if needed.
Excellent and thanks.

> regarding jgitver ... Do you have a stacktrace for this?
there is no error/problem because it dumps the model manually to a pom.xml
file and reattached it to projects.
When above created issue https://issues.apache.org/jira/browse/MNG-7067
will be solved there should be no need for this specific stuff anymore.

Re: maven 4.0.0 new XML stuff

[Romain Manni-Bucau]

Created https://issues.apache.org/jira/browse/MNG-7067 to start, now we
have an umbrella let's refine the description if needed.

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



Le mar. 5 janv. 2021 à 13:52, Robert Scholte  a
écrit :

> Thank you, now we have something to work on.
>
> polyglot should still work, but it looks like it is getting the wrong set
> of options. So that needs to be fixed. Please create an issue[1]
> regarding jgitver and don't see an issue at first glance. It is using
> MavenXpp3Reader, which is low level, no inheritence.
> Do you have a stacktrace for this?
>
> thanks,
> Robert
> [1] https://issues.apache.org/jira/browse/MNG
> On 5-1-2021 13:17:21, Matthieu Brouillard  wrote:
> > You both keep talking about extensions, but I haven't touched that part.
> > I suggest to test current Maven 4 first and to find cases where those
> extensions don't work anymore.
> I do not know the exact internals of polyglot but for jgitver, in order to
> produce a pom-4.0.0.xml compliant file, either:
> - delegates to flatten-maven-plugin
> - uses an internal mojo
> for the production/attachment of a modified pom.xml file dump from the POM.
> So in both cases, there is somewhere in the code, some ugly code like:
>
> File dumpedModel = dumpFromModel(model);
> project.setPomFile(dumpedModel)
>
> In jgitver it is called from a Mojo(1) which in the end dump and update the
> model (2)
>
> I really thought that with 4.0 and the consumer pom this would be obsolete.
>
> For polyglot, I tried but it does not work with maven-4.0.0, see #224 (3)
>
> 1:
>
> https://github.com/jgitver/jgitver-maven-plugin/blob/master/src/main/java/fr/brouillard/oss/jgitver/mojos/JGitverAttachModifiedPomsMojo.java
> 2:
>
> https://github.com/jgitver/jgitver-maven-plugin/blob/master/src/main/java/fr/brouillard/oss/jgitver/JGitverUtils.java#L182
> 3: https://github.com/takari/polyglot-maven/issues/224
>
>
> On Tue, Jan 5, 2021 at 12:52 PM Robert Scholte wrote:
>
> > You both keep talking about extensions, but I haven't touched that part.
> > I suggest to test current Maven 4 first and to find cases where those
> > extensions don't work anymore.
> > Next we can see if this makes sense or not and how to solve it.
> >
> > Robert
> >
> > On 5-1-2021 12:28:59, Matthieu Brouillard wrote:
> > > Currently the model is mutable and this causes issues.
> > For me it is not the root cause, it does not help for sure but IMO the
> > problem is more that there are currently several sources of trust : the
> POM
> > & the pom.xml.
> >
> > Personally (only my opinion) I see no other way for the future of maven
> > than to go to a single source of trust: the POM (as in memory model).
> > During the build process this POM could (and has to) become immutable for
> > sure so that plugins cannot do ugly things anymore but there should be
> also
> > clear loading and extension mechanisms/hooks before it becomes immutable.
> >
> > > or do you push to drop extensions support?
> > I hope this is not the case.
> >
> > On Tue, Jan 5, 2021 at 11:58 AM Romain Manni-Bucau
> > wrote:
> >
> > > Hmm, extensions define this kind of lifecycle, at least the
> > afterModelRead
> > > which is a hook before it could be immutable no?
> > > So not sure how it changes the issue, or do you push to drop extensions
> > > support?
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau | Blog
> > > | Old Blog
> > > | Github
> > > https://github.com/rmannibucau> |
> > > LinkedIn | Book
> > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le mar. 5 janv. 2021 à 11:54, Robert Scholte a
> > > écrit :
> > >
> > > > Currently the model is mutable and this causes issues.
> > > > Instead I would like to see that once the BuildPlan is finished, the
> > > model
> > > > becomes immutable.
> > > >
> > > >
> > > > To give a concrete example: It must be possible for code generating
> > goals
> > > > to add dependencies.
> > > > Now, when using modello readers/writers you often need to add a
> > required
> > > > dependency by hand.
> > > > Ideally there will be a hook where a plugin can register additional
> > > > dependencies (e.g. dom4j).
> > > >
> > > > This will make any postprocessing of the pom during build obsolete
> > > >
> > > > Robert
> > > > On 5-1-2021 09:09:11, Matthieu Brouillard
> > > wrote:
> > > > > Can you give an example?
> > > > Like Romain has shown: dynamically added dependencies or a version
> > > > computation.
> > > >
> > > > > Most important is the support for CI-friendly versions
> > > > But if extensions dynamically compute and set the versions in the POM
> > > using
> > > > the API, the changes will not be reflected.
> > 

Re: maven 4.0.0 new XML stuff

[Robert Scholte]

Thank you, now we have something to work on.

polyglot should still work, but it looks like it is getting the wrong set of 
options. So that needs to be fixed. Please create an issue[1]
regarding jgitver and don't see an issue at first glance. It is using 
MavenXpp3Reader, which is low level, no inheritence.
Do you have a stacktrace for this?

thanks,
Robert
[1] https://issues.apache.org/jira/browse/MNG
On 5-1-2021 13:17:21, Matthieu Brouillard  wrote:
> You both keep talking about extensions, but I haven't touched that part.
> I suggest to test current Maven 4 first and to find cases where those
extensions don't work anymore.
I do not know the exact internals of polyglot but for jgitver, in order to
produce a pom-4.0.0.xml compliant file, either:
- delegates to flatten-maven-plugin
- uses an internal mojo
for the production/attachment of a modified pom.xml file dump from the POM.
So in both cases, there is somewhere in the code, some ugly code like:

File dumpedModel = dumpFromModel(model);
project.setPomFile(dumpedModel)

In jgitver it is called from a Mojo(1) which in the end dump and update the
model (2)

I really thought that with 4.0 and the consumer pom this would be obsolete.

For polyglot, I tried but it does not work with maven-4.0.0, see #224 (3)

1:
https://github.com/jgitver/jgitver-maven-plugin/blob/master/src/main/java/fr/brouillard/oss/jgitver/mojos/JGitverAttachModifiedPomsMojo.java
2:
https://github.com/jgitver/jgitver-maven-plugin/blob/master/src/main/java/fr/brouillard/oss/jgitver/JGitverUtils.java#L182
3: https://github.com/takari/polyglot-maven/issues/224


On Tue, Jan 5, 2021 at 12:52 PM Robert Scholte wrote:

> You both keep talking about extensions, but I haven't touched that part.
> I suggest to test current Maven 4 first and to find cases where those
> extensions don't work anymore.
> Next we can see if this makes sense or not and how to solve it.
>
> Robert
>
> On 5-1-2021 12:28:59, Matthieu Brouillard wrote:
> > Currently the model is mutable and this causes issues.
> For me it is not the root cause, it does not help for sure but IMO the
> problem is more that there are currently several sources of trust : the POM
> & the pom.xml.
>
> Personally (only my opinion) I see no other way for the future of maven
> than to go to a single source of trust: the POM (as in memory model).
> During the build process this POM could (and has to) become immutable for
> sure so that plugins cannot do ugly things anymore but there should be also
> clear loading and extension mechanisms/hooks before it becomes immutable.
>
> > or do you push to drop extensions support?
> I hope this is not the case.
>
> On Tue, Jan 5, 2021 at 11:58 AM Romain Manni-Bucau
> wrote:
>
> > Hmm, extensions define this kind of lifecycle, at least the
> afterModelRead
> > which is a hook before it could be immutable no?
> > So not sure how it changes the issue, or do you push to drop extensions
> > support?
> >
> > Romain Manni-Bucau
> > @rmannibucau | Blog
> > | Old Blog
> > | Github
> > https://github.com/rmannibucau> |
> > LinkedIn | Book
> >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mar. 5 janv. 2021 à 11:54, Robert Scholte a
> > écrit :
> >
> > > Currently the model is mutable and this causes issues.
> > > Instead I would like to see that once the BuildPlan is finished, the
> > model
> > > becomes immutable.
> > >
> > >
> > > To give a concrete example: It must be possible for code generating
> goals
> > > to add dependencies.
> > > Now, when using modello readers/writers you often need to add a
> required
> > > dependency by hand.
> > > Ideally there will be a hook where a plugin can register additional
> > > dependencies (e.g. dom4j).
> > >
> > > This will make any postprocessing of the pom during build obsolete
> > >
> > > Robert
> > > On 5-1-2021 09:09:11, Matthieu Brouillard
> > wrote:
> > > > Can you give an example?
> > > Like Romain has shown: dynamically added dependencies or a version
> > > computation.
> > >
> > > > Most important is the support for CI-friendly versions
> > > But if extensions dynamically compute and set the versions in the POM
> > using
> > > the API, the changes will not be reflected.
> > > That's why today one has to use flatten-maven-plugin or any other
> > > plugin/task modifying/dumping the POM model to a pom.xml file and
> > > setting/attaching it the POM.
> > >
> > > If the produced artifacts (consumer pom) were computed from the POM
> > (object
> > > model), every change done by any extension would be part of it.
> > >
> > > > but this happens AFTER using the pom
> > > Not always from the pom.xml. I thought extensions were allowed to
> provide
> > > ModelLocator & ModelReader to both decide which file to use for a
> project
> > > and how to build the in memory POM model.
> > > So the truth should not be considered to be in the pom.xml but in the
> > POM.
> > >
> > >
> > > On Mon, Jan 4, 2021 at 10:00 PM Robert Scholte 

Re: maven 4.0.0 new XML stuff

[Romain Manni-Bucau]

Robert,
Point is that without using in memory pom model, produced pom will always
require rework to be properly consumed.
We must avoid it I think and do what you said: read pom -> extend it ->
make it immutable (optional for me) -> dump *this* model.
This is what makes a consumable feature otherwise it is just a static pom
rewriting without advantages of a producer/consumer pattern (nobody cares
to put versions to be concrete).


Le mar. 5 janv. 2021 à 13:17, Matthieu Brouillard 
a écrit :

> > You both keep talking about extensions, but I haven't touched that part.
> > I suggest to test current Maven 4 first and to find cases where those
> extensions don't work anymore.
> I do not know the exact internals of polyglot but for jgitver, in order to
> produce a pom-4.0.0.xml compliant file, either:
> - delegates to flatten-maven-plugin
> - uses an internal mojo
> for the production/attachment of a modified pom.xml file dump from the POM.
> So in both cases, there is somewhere in the code, some ugly code like:
>
> File dumpedModel = dumpFromModel(model);
> project.setPomFile(dumpedModel)
>
> In jgitver it is called from a Mojo(1) which in the end dump and update the
> model (2)
>
> I really thought that with 4.0 and the consumer pom this would be obsolete.
>
> For polyglot, I tried but it does not work with maven-4.0.0, see #224 (3)
>
> 1:
>
> https://github.com/jgitver/jgitver-maven-plugin/blob/master/src/main/java/fr/brouillard/oss/jgitver/mojos/JGitverAttachModifiedPomsMojo.java
> 2:
>
> https://github.com/jgitver/jgitver-maven-plugin/blob/master/src/main/java/fr/brouillard/oss/jgitver/JGitverUtils.java#L182
> 3: https://github.com/takari/polyglot-maven/issues/224
>
>
> On Tue, Jan 5, 2021 at 12:52 PM Robert Scholte 
> wrote:
>
> > You both keep talking about extensions, but I haven't touched that part.
> > I suggest to test current Maven 4 first and to find cases where those
> > extensions don't work anymore.
> > Next we can see if this makes sense or not and how to solve it.
> >
> > Robert
> >
> > On 5-1-2021 12:28:59, Matthieu Brouillard 
> wrote:
> > > Currently the model is mutable and this causes issues.
> > For me it is not the root cause, it does not help for sure but IMO the
> > problem is more that there are currently several sources of trust : the
> POM
> > & the pom.xml.
> >
> > Personally (only my opinion) I see no other way for the future of maven
> > than to go to a single source of trust: the POM (as in memory model).
> > During the build process this POM could (and has to) become immutable for
> > sure so that plugins cannot do ugly things anymore but there should be
> also
> > clear loading and extension mechanisms/hooks before it becomes immutable.
> >
> > > or do you push to drop extensions support?
> > I hope this is not the case.
> >
> > On Tue, Jan 5, 2021 at 11:58 AM Romain Manni-Bucau
> > wrote:
> >
> > > Hmm, extensions define this kind of lifecycle, at least the
> > afterModelRead
> > > which is a hook before it could be immutable no?
> > > So not sure how it changes the issue, or do you push to drop extensions
> > > support?
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau | Blog
> > > | Old Blog
> > > | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le mar. 5 janv. 2021 à 11:54, Robert Scholte a
> > > écrit :
> > >
> > > > Currently the model is mutable and this causes issues.
> > > > Instead I would like to see that once the BuildPlan is finished, the
> > > model
> > > > becomes immutable.
> > > >
> > > >
> > > > To give a concrete example: It must be possible for code generating
> > goals
> > > > to add dependencies.
> > > > Now, when using modello readers/writers you often need to add a
> > required
> > > > dependency by hand.
> > > > Ideally there will be a hook where a plugin can register additional
> > > > dependencies (e.g. dom4j).
> > > >
> > > > This will make any postprocessing of the pom during build obsolete
> > > >
> > > > Robert
> > > > On 5-1-2021 09:09:11, Matthieu Brouillard
> > > wrote:
> > > > > Can you give an example?
> > > > Like Romain has shown: dynamically added dependencies or a version
> > > > computation.
> > > >
> > > > > Most important is the support for CI-friendly versions
> > > > But if extensions dynamically compute and set the versions in the POM
> > > using
> > > > the API, the changes will not be reflected.
> > > > That's why today one has to use flatten-maven-plugin or any other
> > > > plugin/task modifying/dumping the POM model to a pom.xml file and
> > > > setting/attaching it the POM.
> > > >
> > > > If the produced artifacts (consumer pom) were computed from the POM
> > > (object
> > > > model), every change done by any extension would be part of it.
> > > >
> > > > > but this happens AFTER using the pom
> > > > Not always from the pom.xml. I thought extensions were allowed to
> > provide
> 

Re: maven 4.0.0 new XML stuff

[Matthieu Brouillard]

> You both keep talking about extensions, but I haven't touched that part.
> I suggest to test current Maven 4 first and to find cases where those
extensions don't work anymore.
I do not know the exact internals of polyglot but for jgitver, in order to
produce a pom-4.0.0.xml compliant file, either:
- delegates to flatten-maven-plugin
- uses an internal mojo
for the production/attachment of a modified pom.xml file dump from the POM.
So in both cases, there is somewhere in the code, some ugly code like:

File dumpedModel = dumpFromModel(model);
project.setPomFile(dumpedModel)

In jgitver it is called from a Mojo(1) which in the end dump and update the
model (2)

I really thought that with 4.0 and the consumer pom this would be obsolete.

For polyglot, I tried but it does not work with maven-4.0.0, see #224 (3)

1:
https://github.com/jgitver/jgitver-maven-plugin/blob/master/src/main/java/fr/brouillard/oss/jgitver/mojos/JGitverAttachModifiedPomsMojo.java
2:
https://github.com/jgitver/jgitver-maven-plugin/blob/master/src/main/java/fr/brouillard/oss/jgitver/JGitverUtils.java#L182
3: https://github.com/takari/polyglot-maven/issues/224


On Tue, Jan 5, 2021 at 12:52 PM Robert Scholte  wrote:

> You both keep talking about extensions, but I haven't touched that part.
> I suggest to test current Maven 4 first and to find cases where those
> extensions don't work anymore.
> Next we can see if this makes sense or not and how to solve it.
>
> Robert
>
> On 5-1-2021 12:28:59, Matthieu Brouillard  wrote:
> > Currently the model is mutable and this causes issues.
> For me it is not the root cause, it does not help for sure but IMO the
> problem is more that there are currently several sources of trust : the POM
> & the pom.xml.
>
> Personally (only my opinion) I see no other way for the future of maven
> than to go to a single source of trust: the POM (as in memory model).
> During the build process this POM could (and has to) become immutable for
> sure so that plugins cannot do ugly things anymore but there should be also
> clear loading and extension mechanisms/hooks before it becomes immutable.
>
> > or do you push to drop extensions support?
> I hope this is not the case.
>
> On Tue, Jan 5, 2021 at 11:58 AM Romain Manni-Bucau
> wrote:
>
> > Hmm, extensions define this kind of lifecycle, at least the
> afterModelRead
> > which is a hook before it could be immutable no?
> > So not sure how it changes the issue, or do you push to drop extensions
> > support?
> >
> > Romain Manni-Bucau
> > @rmannibucau | Blog
> > | Old Blog
> > | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mar. 5 janv. 2021 à 11:54, Robert Scholte a
> > écrit :
> >
> > > Currently the model is mutable and this causes issues.
> > > Instead I would like to see that once the BuildPlan is finished, the
> > model
> > > becomes immutable.
> > >
> > >
> > > To give a concrete example: It must be possible for code generating
> goals
> > > to add dependencies.
> > > Now, when using modello readers/writers you often need to add a
> required
> > > dependency by hand.
> > > Ideally there will be a hook where a plugin can register additional
> > > dependencies (e.g. dom4j).
> > >
> > > This will make any postprocessing of the pom during build obsolete
> > >
> > > Robert
> > > On 5-1-2021 09:09:11, Matthieu Brouillard
> > wrote:
> > > > Can you give an example?
> > > Like Romain has shown: dynamically added dependencies or a version
> > > computation.
> > >
> > > > Most important is the support for CI-friendly versions
> > > But if extensions dynamically compute and set the versions in the POM
> > using
> > > the API, the changes will not be reflected.
> > > That's why today one has to use flatten-maven-plugin or any other
> > > plugin/task modifying/dumping the POM model to a pom.xml file and
> > > setting/attaching it the POM.
> > >
> > > If the produced artifacts (consumer pom) were computed from the POM
> > (object
> > > model), every change done by any extension would be part of it.
> > >
> > > > but this happens AFTER using the pom
> > > Not always from the pom.xml. I thought extensions were allowed to
> provide
> > > ModelLocator & ModelReader to both decide which file to use for a
> project
> > > and how to build the in memory POM model.
> > > So the truth should not be considered to be in the pom.xml but in the
> > POM.
> > >
> > >
> > > On Mon, Jan 4, 2021 at 10:00 PM Robert Scholte wrote:
> > >
> > > > answers are below.
> > > >
> > > > Robert
> > > >
> > > > On 4-1-2021 16:52:23, Matthieu Brouillard wrote:
> > > > @Robert nothing is broken atm, the changes for consumer/build are
> > > currently
> > > > behind your feature flag.
> > > > Robert Scholte:
> > > > It is active by default, so it is actually not hidden.
> > > >
> > > >
> > > >
> > > > But as I feared previously, and as Romain pointed it, by working at
> XML
> > > > 

Re: maven 4.0.0 new XML stuff

[Robert Scholte]

You both keep talking about extensions, but I haven't touched that part.
I suggest to test current Maven 4 first and to find cases where those 
extensions don't work anymore.
Next we can see if this makes sense or not and how to solve it.

Robert

On 5-1-2021 12:28:59, Matthieu Brouillard  wrote:
> Currently the model is mutable and this causes issues.
For me it is not the root cause, it does not help for sure but IMO the
problem is more that there are currently several sources of trust : the POM
& the pom.xml.

Personally (only my opinion) I see no other way for the future of maven
than to go to a single source of trust: the POM (as in memory model).
During the build process this POM could (and has to) become immutable for
sure so that plugins cannot do ugly things anymore but there should be also
clear loading and extension mechanisms/hooks before it becomes immutable.

> or do you push to drop extensions support?
I hope this is not the case.

On Tue, Jan 5, 2021 at 11:58 AM Romain Manni-Bucau
wrote:

> Hmm, extensions define this kind of lifecycle, at least the afterModelRead
> which is a hook before it could be immutable no?
> So not sure how it changes the issue, or do you push to drop extensions
> support?
>
> Romain Manni-Bucau
> @rmannibucau | Blog
> | Old Blog
> | Github <
> https://github.com/rmannibucau> |
> LinkedIn | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 5 janv. 2021 à 11:54, Robert Scholte a
> écrit :
>
> > Currently the model is mutable and this causes issues.
> > Instead I would like to see that once the BuildPlan is finished, the
> model
> > becomes immutable.
> >
> >
> > To give a concrete example: It must be possible for code generating goals
> > to add dependencies.
> > Now, when using modello readers/writers you often need to add a required
> > dependency by hand.
> > Ideally there will be a hook where a plugin can register additional
> > dependencies (e.g. dom4j).
> >
> > This will make any postprocessing of the pom during build obsolete
> >
> > Robert
> > On 5-1-2021 09:09:11, Matthieu Brouillard
> wrote:
> > > Can you give an example?
> > Like Romain has shown: dynamically added dependencies or a version
> > computation.
> >
> > > Most important is the support for CI-friendly versions
> > But if extensions dynamically compute and set the versions in the POM
> using
> > the API, the changes will not be reflected.
> > That's why today one has to use flatten-maven-plugin or any other
> > plugin/task modifying/dumping the POM model to a pom.xml file and
> > setting/attaching it the POM.
> >
> > If the produced artifacts (consumer pom) were computed from the POM
> (object
> > model), every change done by any extension would be part of it.
> >
> > > but this happens AFTER using the pom
> > Not always from the pom.xml. I thought extensions were allowed to provide
> > ModelLocator & ModelReader to both decide which file to use for a project
> > and how to build the in memory POM model.
> > So the truth should not be considered to be in the pom.xml but in the
> POM.
> >
> >
> > On Mon, Jan 4, 2021 at 10:00 PM Robert Scholte wrote:
> >
> > > answers are below.
> > >
> > > Robert
> > >
> > > On 4-1-2021 16:52:23, Matthieu Brouillard wrote:
> > > @Robert nothing is broken atm, the changes for consumer/build are
> > currently
> > > behind your feature flag.
> > > Robert Scholte:
> > > It is active by default, so it is actually not hidden.
> > >
> > >
> > >
> > > But as I feared previously, and as Romain pointed it, by working at XML
> > > level (and not at POM level) the produced consumer pom does not reflect
> > > changes from extensions.
> > > Robert Scholte:
> > > Can you give an example?
> > >
> > >
> > > I really thought that all the "consumer/build" stuff would make the
> > > maven-flatten-plugin useless but it looks like it will not be the case
> if
> > > working at XML level.
> > > Robert Scholte:
> > > Like with most questions: it depends. Most important is the support for
> > > CI-friendly versions. In this case you won't need the
> > flatten-maven-plugin
> > > anymore.
> > > However, the plugin can rewrite much more, but this happens AFTER using
> > > the pom.
> > > That's something I don't like, because this POM was not used to build
> the
> > > project, but it was reassembled afterwards.
> > > My idea is to provide hooks to parts of the pom that might be adjusted,
> > > but this is something we can work on during the 4.x releases
> > >
> > > Did Romain and I miss the whole point of the "consumer/build"
> > enhancements
> > > or is it "just" because current implementation has not yet reached the
> > > targets/outputs?
> > >
> > > On Mon, Jan 4, 2021 at 2:56 PM Romain Manni-Bucau
> > > wrote:
> > >
> > > > Hmm, I don't get a few things of this IT:
> > > >
> > > > 1. the formatting seems not expected even if valid (the comments are
> > > > finishing with the first tag for example "-->
> > > > public class MyListener 

Re: maven 4.0.0 new XML stuff

[Matthieu Brouillard]

 > Currently the model is mutable and this causes issues.
For me it is not the root cause, it does not help for sure but IMO the
problem is more that there are currently several sources of trust : the POM
& the pom.xml.

Personally (only my opinion) I see no other way for the future of maven
than to go to a single source of trust: the POM (as in memory model).
During the build process this POM could (and has to) become immutable for
sure so that plugins cannot do ugly things anymore but there should be also
clear loading and extension mechanisms/hooks before it becomes immutable.

> or do you push to drop extensions support?
I hope this is not the case.

On Tue, Jan 5, 2021 at 11:58 AM Romain Manni-Bucau 
wrote:

> Hmm, extensions define this kind of lifecycle, at least the afterModelRead
> which is a hook before it could be immutable no?
> So not sure how it changes the issue, or do you push to drop extensions
> support?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 5 janv. 2021 à 11:54, Robert Scholte  a
> écrit :
>
> > Currently the model is mutable and this causes issues.
> > Instead I would like to see that once the BuildPlan is finished, the
> model
> > becomes immutable.
> >
> >
> > To give a concrete example: It must be possible for code generating goals
> > to add dependencies.
> > Now, when using modello readers/writers you often need to add a required
> > dependency by hand.
> > Ideally there will be a hook where a plugin can register additional
> > dependencies (e.g. dom4j).
> >
> > This will make any postprocessing of the pom during build obsolete
> >
> > Robert
> > On 5-1-2021 09:09:11, Matthieu Brouillard 
> wrote:
> > > Can you give an example?
> > Like Romain has shown: dynamically added dependencies or a version
> > computation.
> >
> > > Most important is the support for CI-friendly versions
> > But if extensions dynamically compute and set the versions in the POM
> using
> > the API, the changes will not be reflected.
> > That's why today one has to use flatten-maven-plugin or any other
> > plugin/task modifying/dumping the POM model to a pom.xml file and
> > setting/attaching it the POM.
> >
> > If the produced artifacts (consumer pom) were computed from the POM
> (object
> > model), every change done by any extension would be part of it.
> >
> > > but this happens AFTER using the pom
> > Not always from the pom.xml. I thought extensions were allowed to provide
> > ModelLocator & ModelReader to both decide which file to use for a project
> > and how to build the in memory POM model.
> > So the truth should not be considered to be in the pom.xml but in the
> POM.
> >
> >
> > On Mon, Jan 4, 2021 at 10:00 PM Robert Scholte wrote:
> >
> > > answers are below.
> > >
> > > Robert
> > >
> > > On 4-1-2021 16:52:23, Matthieu Brouillard wrote:
> > > @Robert nothing is broken atm, the changes for consumer/build are
> > currently
> > > behind your feature flag.
> > > Robert Scholte:
> > > It is active by default, so it is actually not hidden.
> > >
> > >
> > >
> > > But as I feared previously, and as Romain pointed it, by working at XML
> > > level (and not at POM level) the produced consumer pom does not reflect
> > > changes from extensions.
> > > Robert Scholte:
> > > Can you give an example?
> > >
> > >
> > > I really thought that all the "consumer/build" stuff would make the
> > > maven-flatten-plugin useless but it looks like it will not be the case
> if
> > > working at XML level.
> > > Robert Scholte:
> > > Like with most questions: it depends. Most important is the support for
> > > CI-friendly versions. In this case you won't need the
> > flatten-maven-plugin
> > > anymore.
> > > However, the plugin can rewrite much more, but this happens AFTER using
> > > the pom.
> > > That's something I don't like, because this POM was not used to build
> the
> > > project, but it was reassembled afterwards.
> > > My idea is to provide hooks to parts of the pom that might be adjusted,
> > > but this is something we can work on during the 4.x releases
> > >
> > > Did Romain and I miss the whole point of the "consumer/build"
> > enhancements
> > > or is it "just" because current implementation has not yet reached the
> > > targets/outputs?
> > >
> > > On Mon, Jan 4, 2021 at 2:56 PM Romain Manni-Bucau
> > > wrote:
> > >
> > > > Hmm, I don't get a few things of this IT:
> > > >
> > > > 1. the formatting seems not expected even if valid (the comments are
> > > > finishing with the first tag for example "-->
> > > > public class MyListener extends AbstractMavenLifecycleParticipant {
> > > >
> > > > @Override
> > > > public void afterProjectsRead(final MavenSession session) throws
> > > 

Re: maven 4.0.0 new XML stuff

[Romain Manni-Bucau]

Hmm, extensions define this kind of lifecycle, at least the afterModelRead
which is a hook before it could be immutable no?
So not sure how it changes the issue, or do you push to drop extensions
support?

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



Le mar. 5 janv. 2021 à 11:54, Robert Scholte  a
écrit :

> Currently the model is mutable and this causes issues.
> Instead I would like to see that once the BuildPlan is finished, the model
> becomes immutable.
>
>
> To give a concrete example: It must be possible for code generating goals
> to add dependencies.
> Now, when using modello readers/writers you often need to add a required
> dependency by hand.
> Ideally there will be a hook where a plugin can register additional
> dependencies (e.g. dom4j).
>
> This will make any postprocessing of the pom during build obsolete
>
> Robert
> On 5-1-2021 09:09:11, Matthieu Brouillard  wrote:
> > Can you give an example?
> Like Romain has shown: dynamically added dependencies or a version
> computation.
>
> > Most important is the support for CI-friendly versions
> But if extensions dynamically compute and set the versions in the POM using
> the API, the changes will not be reflected.
> That's why today one has to use flatten-maven-plugin or any other
> plugin/task modifying/dumping the POM model to a pom.xml file and
> setting/attaching it the POM.
>
> If the produced artifacts (consumer pom) were computed from the POM (object
> model), every change done by any extension would be part of it.
>
> > but this happens AFTER using the pom
> Not always from the pom.xml. I thought extensions were allowed to provide
> ModelLocator & ModelReader to both decide which file to use for a project
> and how to build the in memory POM model.
> So the truth should not be considered to be in the pom.xml but in the POM.
>
>
> On Mon, Jan 4, 2021 at 10:00 PM Robert Scholte wrote:
>
> > answers are below.
> >
> > Robert
> >
> > On 4-1-2021 16:52:23, Matthieu Brouillard wrote:
> > @Robert nothing is broken atm, the changes for consumer/build are
> currently
> > behind your feature flag.
> > Robert Scholte:
> > It is active by default, so it is actually not hidden.
> >
> >
> >
> > But as I feared previously, and as Romain pointed it, by working at XML
> > level (and not at POM level) the produced consumer pom does not reflect
> > changes from extensions.
> > Robert Scholte:
> > Can you give an example?
> >
> >
> > I really thought that all the "consumer/build" stuff would make the
> > maven-flatten-plugin useless but it looks like it will not be the case if
> > working at XML level.
> > Robert Scholte:
> > Like with most questions: it depends. Most important is the support for
> > CI-friendly versions. In this case you won't need the
> flatten-maven-plugin
> > anymore.
> > However, the plugin can rewrite much more, but this happens AFTER using
> > the pom.
> > That's something I don't like, because this POM was not used to build the
> > project, but it was reassembled afterwards.
> > My idea is to provide hooks to parts of the pom that might be adjusted,
> > but this is something we can work on during the 4.x releases
> >
> > Did Romain and I miss the whole point of the "consumer/build"
> enhancements
> > or is it "just" because current implementation has not yet reached the
> > targets/outputs?
> >
> > On Mon, Jan 4, 2021 at 2:56 PM Romain Manni-Bucau
> > wrote:
> >
> > > Hmm, I don't get a few things of this IT:
> > >
> > > 1. the formatting seems not expected even if valid (the comments are
> > > finishing with the first tag for example "-->
> > > public class MyListener extends AbstractMavenLifecycleParticipant {
> > >
> > > @Override
> > > public void afterProjectsRead(final MavenSession session) throws
> > > MavenExecutionException {
> > > if (session.getCurrentProject() == null) {
> > > return;
> > > }
> > >
> > > session.getProjects().forEach(p -> {
> > > final Dependency dependency = new Dependency();
> > > dependency.setGroupId("junit");
> > > dependency.setArtifactId("junit");
> > > dependency.setVersion("3.8.1");
> > > p.getDependencies().add(dependency);
> > > });
> > > }
> > > }
> > >
> > >
> > > 2. If you run mvn (4 snapshot) dependency:tree you get this kind of
> > output:
> > >
> > > [INFO] -
> > > >-
> > > [INFO] Building Multi Chapter Simple Web Application Project
> > > 0.9-MNG6957-SNAPSHOT [6/6]
> > > [INFO] [ jar
> > > ]-
> > > [INFO]
> > > [INFO] --- maven-dependency-plugin:3.1.2:tree (default-cli) @
> > simple-webapp
> > > ---
> > > [INFO]
> > org.sonatype.mavenbook.multi:simple-webapp:jar:0.9-MNG6957-SNAPSHOT
> > > [INFO] +-
> > >
> > >
> 

Re: maven 4.0.0 new XML stuff

[Robert Scholte]

Currently the model is mutable and this causes issues.
Instead I would like to see that once the BuildPlan is finished, the model 
becomes immutable.


To give a concrete example: It must be possible for code generating goals to 
add dependencies. 
Now, when using modello readers/writers you often need to add a required 
dependency by hand.
Ideally there will be a hook where a plugin can register additional 
dependencies (e.g. dom4j).

This will make any postprocessing of the pom during build obsolete

Robert
On 5-1-2021 09:09:11, Matthieu Brouillard  wrote:
> Can you give an example?
Like Romain has shown: dynamically added dependencies or a version
computation.

> Most important is the support for CI-friendly versions
But if extensions dynamically compute and set the versions in the POM using
the API, the changes will not be reflected.
That's why today one has to use flatten-maven-plugin or any other
plugin/task modifying/dumping the POM model to a pom.xml file and
setting/attaching it the POM.

If the produced artifacts (consumer pom) were computed from the POM (object
model), every change done by any extension would be part of it.

> but this happens AFTER using the pom
Not always from the pom.xml. I thought extensions were allowed to provide
ModelLocator & ModelReader to both decide which file to use for a project
and how to build the in memory POM model.
So the truth should not be considered to be in the pom.xml but in the POM.


On Mon, Jan 4, 2021 at 10:00 PM Robert Scholte wrote:

> answers are below.
>
> Robert
>
> On 4-1-2021 16:52:23, Matthieu Brouillard wrote:
> @Robert nothing is broken atm, the changes for consumer/build are currently
> behind your feature flag.
> Robert Scholte:
> It is active by default, so it is actually not hidden.
>
>
>
> But as I feared previously, and as Romain pointed it, by working at XML
> level (and not at POM level) the produced consumer pom does not reflect
> changes from extensions.
> Robert Scholte:
> Can you give an example?
>
>
> I really thought that all the "consumer/build" stuff would make the
> maven-flatten-plugin useless but it looks like it will not be the case if
> working at XML level.
> Robert Scholte:
> Like with most questions: it depends. Most important is the support for
> CI-friendly versions. In this case you won't need the flatten-maven-plugin
> anymore.
> However, the plugin can rewrite much more, but this happens AFTER using
> the pom.
> That's something I don't like, because this POM was not used to build the
> project, but it was reassembled afterwards.
> My idea is to provide hooks to parts of the pom that might be adjusted,
> but this is something we can work on during the 4.x releases
>
> Did Romain and I miss the whole point of the "consumer/build" enhancements
> or is it "just" because current implementation has not yet reached the
> targets/outputs?
>
> On Mon, Jan 4, 2021 at 2:56 PM Romain Manni-Bucau
> wrote:
>
> > Hmm, I don't get a few things of this IT:
> >
> > 1. the formatting seems not expected even if valid (the comments are
> > finishing with the first tag for example "-->
> > public class MyListener extends AbstractMavenLifecycleParticipant {
> >
> > @Override
> > public void afterProjectsRead(final MavenSession session) throws
> > MavenExecutionException {
> > if (session.getCurrentProject() == null) {
> > return;
> > }
> >
> > session.getProjects().forEach(p -> {
> > final Dependency dependency = new Dependency();
> > dependency.setGroupId("junit");
> > dependency.setArtifactId("junit");
> > dependency.setVersion("3.8.1");
> > p.getDependencies().add(dependency);
> > });
> > }
> > }
> >
> >
> > 2. If you run mvn (4 snapshot) dependency:tree you get this kind of
> output:
> >
> > [INFO] -
> > >-
> > [INFO] Building Multi Chapter Simple Web Application Project
> > 0.9-MNG6957-SNAPSHOT [6/6]
> > [INFO] [ jar
> > ]-
> > [INFO]
> > [INFO] --- maven-dependency-plugin:3.1.2:tree (default-cli) @
> simple-webapp
> > ---
> > [INFO]
> org.sonatype.mavenbook.multi:simple-webapp:jar:0.9-MNG6957-SNAPSHOT
> > [INFO] +-
> >
> >
> org.sonatype.mavenbook.multi:simple-weather:jar:0.9-MNG6957-SNAPSHOT:compile
> > [INFO] \- junit:junit:jar:3.8.1:compile
> >
> > [INFO]
> > 
> >
> > 3. run the build to have produced pom and cat the simple-webapp one:
> >
> >
> > 4.0.0
> >
> > org.sonatype.mavenbook.multi
> > simple-parent
> > 0.9-MNG6957-SNAPSHOT
> >
> >
> > simple-webapp
> > Multi Chapter Simple Web Application Project
> >
> >
> > org.sonatype.mavenbook.multi
> > simple-weather
> > 0.9-MNG6957-SNAPSHOT
> >
> >
> >
> > simple-webapp
> >
> >
> >
> > org.apache.maven.plugins
> > maven-war-plugin
> > 2.6
> >
> >
> >
> >
> >
> >
> > As you see the dependency is not there. I guess the expected outout is:
> >
> >
> >
> > 4.0.0
> > simple-webapp
> > Multi Chapter Simple Web Application 

Re: maven 4.0.0 new XML stuff

[Romain Manni-Bucau]

So it seems we must enhance that read/write logic with these elements to
make them usable:

1. Make it extension/Maven-IoC (even without extensions you can have the
same issue with just guice components) friendly (code showing the bug is in
a previous response)
2. Decide what is the produced pom, either the exact same pom as the source
one without the model > 4 changes (= just a model N -> 4 converter) or a
pom optimized to be consumed (flattened, without build section etc).
Another point here is about comments, it should likely be a config in the
pom to know if they must be stripped or not. If I take all projects I
worked on, comments are build comments - except the license - so must not
end up in the consummed pom if designed to be used by user (even if it does
not hurt). Last pom is that it should also be configurable if some part of
the pom are kept or not (maybe using plexus attributes) since some tool
tend to parse poms at runtime to extract some metadata from there, guess it
will slowly move to other descriptors but pom were nice because 75% of the
time there so we should make the migration smooth IMHO by enabling to keep
these elements. All that can be seen differently, if you take it from the
outside, like from a gradle or sbt pespective, you kind of script the
mapping memory descriptor -> consumable pom. Maven is not different as soon
as it embraces this model so it must be user controlled - no way we do it
right without user inputs. Guess a trivial way is to just let the user give
a xslt in a maven pom producer plugin which would replace all this core
code. If the plugin is not define we can use the default behavior adding it
in the deploy phase out of the box.

So overall I to join Matthieu on the target since it is what makes sense
IMHO and seems to be widely used by people.

Side nice note for us: It also opens the door to way faster resolutions if
we add a property in these poms (maven.consumable.pom=true? or so) to cut
the recursive dependency resolution if already done at deploy time. Can
make it hundreds of time faster - used that in some previous work projects.

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



Le mar. 5 janv. 2021 à 09:09, Matthieu Brouillard 
a écrit :

> > Can you give an example?
> Like Romain has shown: dynamically added dependencies or a version
> computation.
>
> > Most important is the support for CI-friendly versions
> But if extensions dynamically compute and set the versions in the POM using
> the API, the changes will not be reflected.
> That's why today one has to use flatten-maven-plugin or any other
> plugin/task modifying/dumping the POM model to a pom.xml file and
> setting/attaching it the POM.
>
> If the produced artifacts (consumer pom) were computed from the POM (object
> model), every change done by any extension would be part of it.
>
> > but this happens AFTER using the pom
> Not always from the pom.xml. I thought extensions were allowed to provide
> ModelLocator & ModelReader to both decide which file to use for a project
> and how to build the in memory POM model.
> So the truth should not be considered to be in the pom.xml but in the POM.
>
>
> On Mon, Jan 4, 2021 at 10:00 PM Robert Scholte 
> wrote:
>
> > answers are below.
> >
> > Robert
> >
> > On 4-1-2021 16:52:23, Matthieu Brouillard 
> wrote:
> > @Robert nothing is broken atm, the changes for consumer/build are
> currently
> > behind your feature flag.
> > Robert Scholte:
> > It is active by default, so it is actually not hidden.
> >
> >
> >
> > But as I feared previously, and as Romain pointed it, by working at XML
> > level (and not at POM level) the produced consumer pom does not reflect
> > changes from extensions.
> > Robert Scholte:
> > Can you give an example?
> >
> >
> > I really thought that all the "consumer/build" stuff would make the
> > maven-flatten-plugin useless but it looks like it will not be the case if
> > working at XML level.
> > Robert Scholte:
> > Like with most questions: it depends. Most important is the support for
> > CI-friendly versions. In this case you won't need the
> flatten-maven-plugin
> > anymore.
> > However, the plugin can rewrite much more, but this happens AFTER using
> > the pom.
> > That's something I don't like, because this POM was not used to build the
> > project, but it was reassembled afterwards.
> > My idea is to provide hooks to parts of the pom that might be adjusted,
> > but this is something we can work on during the 4.x releases
> >
> > Did Romain and I miss the whole point of the "consumer/build"
> enhancements
> > or is it "just" because current implementation has not yet reached the
> > targets/outputs?
> >
> > On Mon, Jan 4, 2021 at 2:56 PM Romain 

Re: maven 4.0.0 new XML stuff

[Matthieu Brouillard]

> Can you give an example?
Like Romain has shown: dynamically added dependencies or a version
computation.

> Most important is the support for CI-friendly versions
But if extensions dynamically compute and set the versions in the POM using
the API, the changes will not be reflected.
That's why today one has to use flatten-maven-plugin or any other
plugin/task modifying/dumping the POM model to a pom.xml file and
setting/attaching it the POM.

If the produced artifacts (consumer pom) were computed from the POM (object
model), every change done by any extension would be part of it.

> but this happens AFTER using the pom
Not always from the pom.xml. I thought extensions were allowed to provide
ModelLocator & ModelReader to both decide which file to use for a project
and how to build the in memory POM model.
So the truth should not be considered to be in the pom.xml but in the POM.


On Mon, Jan 4, 2021 at 10:00 PM Robert Scholte  wrote:

> answers are below.
>
> Robert
>
> On 4-1-2021 16:52:23, Matthieu Brouillard  wrote:
> @Robert nothing is broken atm, the changes for consumer/build are currently
> behind your feature flag.
> Robert Scholte:
> It is active by default, so it is actually not hidden.
>
>
>
> But as I feared previously, and as Romain pointed it, by working at XML
> level (and not at POM level) the produced consumer pom does not reflect
> changes from extensions.
> Robert Scholte:
> Can you give an example?
>
>
> I really thought that all the "consumer/build" stuff would make the
> maven-flatten-plugin useless but it looks like it will not be the case if
> working at XML level.
> Robert Scholte:
> Like with most questions: it depends. Most important is the support for
> CI-friendly versions. In this case you won't need the flatten-maven-plugin
> anymore.
> However, the plugin can rewrite much more, but this happens AFTER using
> the pom.
> That's something I don't like, because this POM was not used to build the
> project, but it was reassembled afterwards.
> My idea is to provide hooks to parts of the pom that might be adjusted,
> but this is something we can work on during the 4.x releases
>
> Did Romain and I miss the whole point of the "consumer/build" enhancements
> or is it "just" because current implementation has not yet reached the
> targets/outputs?
>
> On Mon, Jan 4, 2021 at 2:56 PM Romain Manni-Bucau
> wrote:
>
> > Hmm, I don't get a few things of this IT:
> >
> > 1. the formatting seems not expected even if valid (the comments are
> > finishing with the first tag for example "-->
> > public class MyListener extends AbstractMavenLifecycleParticipant {
> >
> > @Override
> > public void afterProjectsRead(final MavenSession session) throws
> > MavenExecutionException {
> > if (session.getCurrentProject() == null) {
> > return;
> > }
> >
> > session.getProjects().forEach(p -> {
> > final Dependency dependency = new Dependency();
> > dependency.setGroupId("junit");
> > dependency.setArtifactId("junit");
> > dependency.setVersion("3.8.1");
> > p.getDependencies().add(dependency);
> > });
> > }
> > }
> >
> >
> > 2. If you run mvn (4 snapshot) dependency:tree you get this kind of
> output:
> >
> > [INFO] -< org.sonatype.mavenbook.multi:simple-webapp
> > >-
> > [INFO] Building Multi Chapter Simple Web Application Project
> > 0.9-MNG6957-SNAPSHOT [6/6]
> > [INFO] [ jar
> > ]-
> > [INFO]
> > [INFO] --- maven-dependency-plugin:3.1.2:tree (default-cli) @
> simple-webapp
> > ---
> > [INFO]
> org.sonatype.mavenbook.multi:simple-webapp:jar:0.9-MNG6957-SNAPSHOT
> > [INFO] +-
> >
> >
> org.sonatype.mavenbook.multi:simple-weather:jar:0.9-MNG6957-SNAPSHOT:compile
> > [INFO] \- junit:junit:jar:3.8.1:compile
> > <-- THIS IS WHAT WE WANT TO SEE
> > [INFO]
> > 
> >
> > 3. run the build to have produced pom and cat the simple-webapp one:
> >
> >
> > 4.0.0
> >
> > org.sonatype.mavenbook.multi
> > simple-parent
> > 0.9-MNG6957-SNAPSHOT
> >
> >
> > simple-webapp
> > Multi Chapter Simple Web Application Project
> >
> >
> > org.sonatype.mavenbook.multi
> > simple-weather
> > 0.9-MNG6957-SNAPSHOT
> >
> >
> >
> > simple-webapp
> >
> >
> >
> > org.apache.maven.plugins
> > maven-war-plugin
> > 2.6
> >
> >
> >
> >
> >
> >
> > As you see the dependency is not there. I guess the expected outout is:
> >
> >
> >
> > 4.0.0
> > simple-webapp
> > Multi Chapter Simple Web Application Project
> > [description, scm, ..., all central requires sections but not build ones]
> >
> >
> > org.sonatype.mavenbook.multi
> > simple-weather
> > 0.9-MNG6957-SNAPSHOT
> >
> >
> > junit
> > junit
> > 3.8.1
> >
> >
> >
> >
> > Am I missing something?
> >
> > Romain Manni-Bucau
> > @rmannibucau | Blog
> > | Old Blog
> > | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> 

Re: maven 4.0.0 new XML stuff

[Robert Scholte]

answers are below.

Robert

On 4-1-2021 16:52:23, Matthieu Brouillard  wrote:
@Robert nothing is broken atm, the changes for consumer/build are currently
behind your feature flag.
Robert Scholte: 
It is active by default, so it is actually not hidden.



But as I feared previously, and as Romain pointed it, by working at XML
level (and not at POM level) the produced consumer pom does not reflect
changes from extensions.
Robert Scholte: 
Can you give an example?


I really thought that all the "consumer/build" stuff would make the
maven-flatten-plugin useless but it looks like it will not be the case if
working at XML level.
Robert Scholte: 
Like with most questions: it depends. Most important is the support for 
CI-friendly versions. In this case you won't need the flatten-maven-plugin 
anymore.
However, the plugin can rewrite much more, but this happens AFTER using the pom.
That's something I don't like, because this POM was not used to build the 
project, but it was reassembled afterwards.
My idea is to provide hooks to parts of the pom that might be adjusted, but 
this is something we can work on during the 4.x releases

Did Romain and I miss the whole point of the "consumer/build" enhancements
or is it "just" because current implementation has not yet reached the
targets/outputs?

On Mon, Jan 4, 2021 at 2:56 PM Romain Manni-Bucau
wrote:

> Hmm, I don't get a few things of this IT:
>
> 1. the formatting seems not expected even if valid (the comments are
> finishing with the first tag for example "-->
> public class MyListener extends AbstractMavenLifecycleParticipant {
>
> @Override
> public void afterProjectsRead(final MavenSession session) throws
> MavenExecutionException {
> if (session.getCurrentProject() == null) {
> return;
> }
>
> session.getProjects().forEach(p -> {
> final Dependency dependency = new Dependency();
> dependency.setGroupId("junit");
> dependency.setArtifactId("junit");
> dependency.setVersion("3.8.1");
> p.getDependencies().add(dependency);
> });
> }
> }
>
>
> 2. If you run mvn (4 snapshot) dependency:tree you get this kind of output:
>
> [INFO] -< org.sonatype.mavenbook.multi:simple-webapp
> >-
> [INFO] Building Multi Chapter Simple Web Application Project
> 0.9-MNG6957-SNAPSHOT [6/6]
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-dependency-plugin:3.1.2:tree (default-cli) @ simple-webapp
> ---
> [INFO] org.sonatype.mavenbook.multi:simple-webapp:jar:0.9-MNG6957-SNAPSHOT
> [INFO] +-
>
> org.sonatype.mavenbook.multi:simple-weather:jar:0.9-MNG6957-SNAPSHOT:compile
> [INFO] \- junit:junit:jar:3.8.1:compile
> <-- THIS IS WHAT WE WANT TO SEE
> [INFO]
> 
>
> 3. run the build to have produced pom and cat the simple-webapp one:
>
>
> 4.0.0
>
> org.sonatype.mavenbook.multi
> simple-parent
> 0.9-MNG6957-SNAPSHOT
>
>
> simple-webapp
> Multi Chapter Simple Web Application Project
>
>
> org.sonatype.mavenbook.multi
> simple-weather
> 0.9-MNG6957-SNAPSHOT
>
>
>
> simple-webapp
>
>
>
> org.apache.maven.plugins
> maven-war-plugin
> 2.6
>
>
>
>
>
>
> As you see the dependency is not there. I guess the expected outout is:
>
>
>
> 4.0.0
> simple-webapp
> Multi Chapter Simple Web Application Project
> [description, scm, ..., all central requires sections but not build ones]
>
>
> org.sonatype.mavenbook.multi
> simple-weather
> 0.9-MNG6957-SNAPSHOT
>
>
> junit
> junit
> 3.8.1
>
>
>
>
> Am I missing something?
>
> Romain Manni-Bucau
> @rmannibucau | Blog
> | Old Blog
> | Github <
> https://github.com/rmannibucau> |
> LinkedIn | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 4 janv. 2021 à 13:41, Robert Scholte a
> écrit :
>
> >
> >
> https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6957-buildconsumer
> > is the most complete IT
> >
> > On 4-1-2021 12:59:51, Romain Manni-Bucau wrote:
> > Le lun. 4 janv. 2021 à 12:36, Robert Scholte a
> > écrit :
> >
> > > There's just one thing I want to say:
> > > I'm having trouble with the term "broken".
> > >
> >
> > Well, literally meant broken as decorelated from the user intent and
> > extension model.
> > Anyway, didn't intend to blame but more identify the blockers for a GA so
> > point was really that it seem that on the two sides only the producing
> one
> > is not yet ready since it keeps does not sanitize the model completely
> and
> > keeps build only data like comments, right? Also not yet clear for me if
> we
> > loose the extension enrichments there.
> >
> >
> > > If a Maven project could be built with M3.6.3, it can still be built
> with
> > > M4.
> > > If not, it is either regression (MNG-6957, MNG-7063) which must be
> fixed,
> > > or it requires changes to a plugin for understandable reasons
> > > (maven-pgp-plugin)
> > > AFAIK an interesting extension like the maven-tiles has been 

Re: maven 4.0.0 new XML stuff

[Matthieu Brouillard]

@Robert nothing is broken atm, the changes for consumer/build are currently
behind your feature flag.

But as I feared previously, and as Romain pointed it, by working at XML
level (and not at POM level) the produced consumer pom does not reflect
changes from extensions.
I really thought that all the "consumer/build" stuff would make the
maven-flatten-plugin useless but it looks like it will not be the case if
working at XML level.
Did Romain and I miss the whole point of the "consumer/build" enhancements
or is it "just" because current implementation has not yet reached the
targets/outputs?

On Mon, Jan 4, 2021 at 2:56 PM Romain Manni-Bucau 
wrote:

> Hmm, I don't get a few things of this IT:
>
> 1. the formatting seems not expected even if valid (the comments are
> finishing with the first tag for example "--> public class MyListener extends AbstractMavenLifecycleParticipant {
>
> @Override
> public void afterProjectsRead(final MavenSession session) throws
> MavenExecutionException {
> if (session.getCurrentProject() == null) {
> return;
> }
>
> session.getProjects().forEach(p -> {
> final Dependency dependency = new Dependency();
> dependency.setGroupId("junit");
> dependency.setArtifactId("junit");
> dependency.setVersion("3.8.1");
> p.getDependencies().add(dependency);
> });
> }
> }
>
>
> 2. If you run mvn (4 snapshot) dependency:tree you get this kind of output:
>
> [INFO] -< org.sonatype.mavenbook.multi:simple-webapp
> >-
> [INFO] Building Multi Chapter Simple Web Application Project
> 0.9-MNG6957-SNAPSHOT [6/6]
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-dependency-plugin:3.1.2:tree (default-cli) @ simple-webapp
> ---
> [INFO] org.sonatype.mavenbook.multi:simple-webapp:jar:0.9-MNG6957-SNAPSHOT
> [INFO] +-
>
> org.sonatype.mavenbook.multi:simple-weather:jar:0.9-MNG6957-SNAPSHOT:compile
> [INFO] \- junit:junit:jar:3.8.1:compile
> <-- THIS IS WHAT WE WANT TO SEE
> [INFO]
> 
>
> 3. run the build to have produced pom and cat the simple-webapp one:
>
> http://maven.apache.org/POM/4.0.0; xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="
> http://maven.apache.org/POM/4.0.0
> https://maven.apache.org/xsd/maven-4.0.0.xsd;>
>   4.0.0
>   
> org.sonatype.mavenbook.multi
> simple-parent
> 0.9-MNG6957-SNAPSHOT
>   
>
>   simple-webapp
>   Multi Chapter Simple Web Application Project
>   
> 
>   org.sonatype.mavenbook.multi
>   simple-weather
>   0.9-MNG6957-SNAPSHOT
> 
>   
>   
> simple-webapp
> 
>   
> 
>   org.apache.maven.plugins
>   maven-war-plugin
>   2.6
> 
>   
> 
>   
> 
>
> As you see the dependency is not there. I guess the expected outout is:
>
> 
> http://maven.apache.org/POM/4.0.0; xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="
> http://maven.apache.org/POM/4.0.0
> https://maven.apache.org/xsd/maven-4.0.0.xsd;>
>   4.0.0
>   simple-webapp
>   Multi Chapter Simple Web Application Project
>   [description, scm, ..., all central requires sections but not build ones]
>   
> 
>   org.sonatype.mavenbook.multi
>   simple-weather
>   0.9-MNG6957-SNAPSHOT
> 
> 
>   junit
>   junit
>   3.8.1
> 
>   
> 
>
> Am I missing something?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 4 janv. 2021 à 13:41, Robert Scholte  a
> écrit :
>
> >
> >
> https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6957-buildconsumer
> > is the most complete IT
> >
> > On 4-1-2021 12:59:51, Romain Manni-Bucau  wrote:
> > Le lun. 4 janv. 2021 à 12:36, Robert Scholte a
> > écrit :
> >
> > > There's just one thing I want to say:
> > > I'm having trouble with the term "broken".
> > >
> >
> > Well, literally meant broken as decorelated from the user intent and
> > extension model.
> > Anyway, didn't intend to blame but more identify the blockers for a GA so
> > point was really that it seem that on the two sides only the producing
> one
> > is not yet ready since it keeps does not sanitize the model completely
> and
> > keeps build only data like comments, right? Also not yet clear for me if
> we
> > loose the extension enrichments there.
> >
> >
> > > If a Maven project could be built with M3.6.3, it can still be built
> with
> > > M4.
> > > If not, it is either 

Re: maven 4.0.0 new XML stuff

[Romain Manni-Bucau]

Hmm, I don't get a few things of this IT:

1. the formatting seems not expected even if valid (the comments are
finishing with the first tag for example "--> {
final Dependency dependency = new Dependency();
dependency.setGroupId("junit");
dependency.setArtifactId("junit");
dependency.setVersion("3.8.1");
p.getDependencies().add(dependency);
});
}
}


2. If you run mvn (4 snapshot) dependency:tree you get this kind of output:

[INFO] -< org.sonatype.mavenbook.multi:simple-webapp
>-
[INFO] Building Multi Chapter Simple Web Application Project
0.9-MNG6957-SNAPSHOT [6/6]
[INFO] [ jar
]-
[INFO]
[INFO] --- maven-dependency-plugin:3.1.2:tree (default-cli) @ simple-webapp
---
[INFO] org.sonatype.mavenbook.multi:simple-webapp:jar:0.9-MNG6957-SNAPSHOT
[INFO] +-
org.sonatype.mavenbook.multi:simple-weather:jar:0.9-MNG6957-SNAPSHOT:compile
[INFO] \- junit:junit:jar:3.8.1:compile
<-- THIS IS WHAT WE WANT TO SEE
[INFO]


3. run the build to have produced pom and cat the simple-webapp one:

http://maven.apache.org/POM/4.0.0; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="
http://maven.apache.org/POM/4.0.0
https://maven.apache.org/xsd/maven-4.0.0.xsd;>
  4.0.0
  
org.sonatype.mavenbook.multi
simple-parent
0.9-MNG6957-SNAPSHOT
  

  simple-webapp
  Multi Chapter Simple Web Application Project
  

  org.sonatype.mavenbook.multi
  simple-weather
  0.9-MNG6957-SNAPSHOT

  
  
simple-webapp

  

  org.apache.maven.plugins
  maven-war-plugin
  2.6

  

  


As you see the dependency is not there. I guess the expected outout is:


http://maven.apache.org/POM/4.0.0; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="
http://maven.apache.org/POM/4.0.0
https://maven.apache.org/xsd/maven-4.0.0.xsd;>
  4.0.0
  simple-webapp
  Multi Chapter Simple Web Application Project
  [description, scm, ..., all central requires sections but not build ones]
  

  org.sonatype.mavenbook.multi
  simple-weather
  0.9-MNG6957-SNAPSHOT


  junit
  junit
  3.8.1

  


Am I missing something?

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



Le lun. 4 janv. 2021 à 13:41, Robert Scholte  a
écrit :

>
> https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6957-buildconsumer
> is the most complete IT
>
> On 4-1-2021 12:59:51, Romain Manni-Bucau  wrote:
> Le lun. 4 janv. 2021 à 12:36, Robert Scholte a
> écrit :
>
> > There's just one thing I want to say:
> > I'm having trouble with the term "broken".
> >
>
> Well, literally meant broken as decorelated from the user intent and
> extension model.
> Anyway, didn't intend to blame but more identify the blockers for a GA so
> point was really that it seem that on the two sides only the producing one
> is not yet ready since it keeps does not sanitize the model completely and
> keeps build only data like comments, right? Also not yet clear for me if we
> loose the extension enrichments there.
>
>
> > If a Maven project could be built with M3.6.3, it can still be built with
> > M4.
> > If not, it is either regression (MNG-6957, MNG-7063) which must be fixed,
> > or it requires changes to a plugin for understandable reasons
> > (maven-pgp-plugin)
> > AFAIK an interesting extension like the maven-tiles has been tested and
> > still works.
> >
>
> Do you have this handy, is it in our test suite? I'd like to check the
> produced pom matches the enriched model but happy to start from something
> already there.
>
>
> >
> > Robert
> >
> > On 3-1-2021 19:35:25, Romain Manni-Bucau wrote:
> > Le dim. 3 janv. 2021 à 19:04, Robert Scholte a
> > écrit :
> >
> > > I don't remember all those details anymore, because I hit those in the
> > > beginning.
> > > Trying things over and over again I decided that this is probably the
> > most
> > > successful approach.
> > >
> > >
> > > What of the goals was to keep the pom.xml as is as much as possible.
> > > We can only decide for the specific Maven elements how to handle them,
> we
> > > should not decide about comments and licenses.
> > > BTW, the license issue was hard to solve. You cannot use it from the
> > pom's
> > > , because there might be multiple licenses.
> > >
> >
> > I disagree, it is saner IMO to evolve to support that than doing
> > anything else.
> > Once again you keep things which don't 

Re: maven 4.0.0 new XML stuff

[Robert Scholte]

https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6957-buildconsumer
 is the most complete IT

On 4-1-2021 12:59:51, Romain Manni-Bucau  wrote:
Le lun. 4 janv. 2021 à 12:36, Robert Scholte a
écrit :

> There's just one thing I want to say:
> I'm having trouble with the term "broken".
>

Well, literally meant broken as decorelated from the user intent and
extension model.
Anyway, didn't intend to blame but more identify the blockers for a GA so
point was really that it seem that on the two sides only the producing one
is not yet ready since it keeps does not sanitize the model completely and
keeps build only data like comments, right? Also not yet clear for me if we
loose the extension enrichments there.


> If a Maven project could be built with M3.6.3, it can still be built with
> M4.
> If not, it is either regression (MNG-6957, MNG-7063) which must be fixed,
> or it requires changes to a plugin for understandable reasons
> (maven-pgp-plugin)
> AFAIK an interesting extension like the maven-tiles has been tested and
> still works.
>

Do you have this handy, is it in our test suite? I'd like to check the
produced pom matches the enriched model but happy to start from something
already there.


>
> Robert
>
> On 3-1-2021 19:35:25, Romain Manni-Bucau wrote:
> Le dim. 3 janv. 2021 à 19:04, Robert Scholte a
> écrit :
>
> > I don't remember all those details anymore, because I hit those in the
> > beginning.
> > Trying things over and over again I decided that this is probably the
> most
> > successful approach.
> >
> >
> > What of the goals was to keep the pom.xml as is as much as possible.
> > We can only decide for the specific Maven elements how to handle them, we
> > should not decide about comments and licenses.
> > BTW, the license issue was hard to solve. You cannot use it from the
> pom's
> > , because there might be multiple licenses.
> >
>
> I disagree, it is saner IMO to evolve to support that than doing
> anything else.
> Once again you keep things which don't make sense in a consumed pom in
> current impl so i'd say the sucess in a few cases breaks as much cases so
> we need to revisit anyway IMHO.
>
>
> >
> > The current implementation is a solid way to ensure we're not breaking
> too
> > much, because Maven controls the XML filters.
> >
>
> Hmm, breaking extensions seems to break too much (I'm not speaking of other
> parts which breaks the ecosystem there but just that is sufficient IMHO to
> say we must check back our solution).
>
>
> >
> > Also keep in mind, that I only want Maven to decide which modifications
> > are done.
> >
>
> For the consumed pom I agree but it is consistent with keeping everything
> working instead of breaking too, no?
>
>
> >
> > Current polyglot projects should still work, but they cannot benefit from
> > the build/consumer functions yet.
> >
>
> So pom -> build model is kept, build model -> produced pom is broken? Is it
> the complete status?
> Sounds ok for a 4.0 and a 4.1 can fix it if so.
> Just want to ensure first part is not broken at all.
>
>
> >
> > Robert
> > On 3-1-2021 16:38:38, Romain Manni-Bucau wrote:
> > Le dim. 3 janv. 2021 à 16:18, Robert Scholte a
> > écrit :
> >
> > > > So what I was expecting was: raw xml model -> converted to unified
> > > consumed model -> extensions -> model processing.
> > >
> > > This is only the build pom part. You're missing the consume part, where
> > > the xml is distributed.
> > >
> >
> > Yes but with previous chain the consume part is "clean/normalize -> dump"
> > since we are using consumed model - only standard model - in memory
> > already.
> >
> >
> > > Build is raw + enrich, consumer is raw + enrich + reduce (removing
> > > relativePath and modules are the first examples, but much more is
> > possible)
> > >
> > > Going for the in memory was also my first thought, but I would loose
> > > information, hence I came up with the current implementation.
> > >
> >
> > I don't see what you loose ot be honest.
> > You mentionned license but this one is in the pom so not a big deal,
> > comments which are undesired IMHO as mentionned and element order which
> can
> > really be discussed since we can desire to enforce an order to normalize
> > consumption + it shouldn't be important since from the project point of
> > view your pom is already "broken"/lost (as all your intelligence is lost
> by
> > this "not passthrough" process).
> > So overall I don't see what you would loose from the consumer side but I
> > see what you lost from maven ecosystem side.
> >
> >
> > > Again, we're at a point where we can have counter solutions, but don't
> > > expect me to implement it.
> > >
> >
> > For now I'm just trying to ensure we agree we don't want to break
> existing
> > extensions and the nice ecosystem we built after years.
> > This was really a move forward and it sounds like we broke it at maven 4
> > without any user gain which sounds terrible.
> >
> >
> > >
> > > thanks,
> > > 

Re: maven 4.0.0 new XML stuff

[Romain Manni-Bucau]

Le lun. 4 janv. 2021 à 12:36, Robert Scholte  a
écrit :

> There's just one thing I want to say:
> I'm having trouble with the term "broken".
>

Well, literally meant broken as decorelated from the user intent and
extension model.
Anyway, didn't intend to blame but more identify the blockers for a GA so
point was really that it seem that on the two sides only the producing one
is not yet ready since it keeps does not sanitize the model completely and
keeps build only data like comments, right? Also not yet clear for me if we
loose the extension enrichments there.


> If a Maven project could be built with M3.6.3, it can still be built with
> M4.
> If not, it is either regression (MNG-6957, MNG-7063) which must be fixed,
> or it requires changes to a plugin for understandable reasons
> (maven-pgp-plugin)
> AFAIK an interesting extension like the maven-tiles has been tested and
> still works.
>

Do you have this handy, is it in our test suite? I'd like to check the
produced pom matches the enriched model but happy to start from something
already there.


>
> Robert
>
> On 3-1-2021 19:35:25, Romain Manni-Bucau  wrote:
> Le dim. 3 janv. 2021 à 19:04, Robert Scholte a
> écrit :
>
> > I don't remember all those details anymore, because I hit those in the
> > beginning.
> > Trying things over and over again I decided that this is probably the
> most
> > successful approach.
> >
> >
> > What of the goals was to keep the pom.xml as is as much as possible.
> > We can only decide for the specific Maven elements how to handle them, we
> > should not decide about comments and licenses.
> > BTW, the license issue was hard to solve. You cannot use it from the
> pom's
> > , because there might be multiple licenses.
> >
>
> I disagree, it is saner IMO to evolve to support that than doing
> anything else.
> Once again you keep things which don't make sense in a consumed pom in
> current impl so i'd say the sucess in a few cases breaks as much cases so
> we need to revisit anyway IMHO.
>
>
> >
> > The current implementation is a solid way to ensure we're not breaking
> too
> > much, because Maven controls the XML filters.
> >
>
> Hmm, breaking extensions seems to break too much (I'm not speaking of other
> parts which breaks the ecosystem there but just that is sufficient IMHO to
> say we must check back our solution).
>
>
> >
> > Also keep in mind, that I only want Maven to decide which modifications
> > are done.
> >
>
> For the consumed pom I agree but it is consistent with keeping everything
> working instead of breaking too, no?
>
>
> >
> > Current polyglot projects should still work, but they cannot benefit from
> > the build/consumer functions yet.
> >
>
> So pom -> build model is kept, build model -> produced pom is broken? Is it
> the complete status?
> Sounds ok for a 4.0 and a 4.1 can fix it if so.
> Just want to ensure first part is not broken at all.
>
>
> >
> > Robert
> > On 3-1-2021 16:38:38, Romain Manni-Bucau wrote:
> > Le dim. 3 janv. 2021 à 16:18, Robert Scholte a
> > écrit :
> >
> > > > So what I was expecting was: raw xml model -> converted to unified
> > > consumed model -> extensions -> model processing.
> > >
> > > This is only the build pom part. You're missing the consume part, where
> > > the xml is distributed.
> > >
> >
> > Yes but with previous chain the consume part is "clean/normalize -> dump"
> > since we are using consumed model - only standard model - in memory
> > already.
> >
> >
> > > Build is raw + enrich, consumer is raw + enrich + reduce (removing
> > > relativePath and modules are the first examples, but much more is
> > possible)
> > >
> > > Going for the in memory was also my first thought, but I would loose
> > > information, hence I came up with the current implementation.
> > >
> >
> > I don't see what you loose ot be honest.
> > You mentionned license but this one is in the pom so not a big deal,
> > comments which are undesired IMHO as mentionned and element order which
> can
> > really be discussed since we can desire to enforce an order to normalize
> > consumption + it shouldn't be important since from the project point of
> > view your pom is already "broken"/lost (as all your intelligence is lost
> by
> > this "not passthrough" process).
> > So overall I don't see what you would loose from the consumer side but I
> > see what you lost from maven ecosystem side.
> >
> >
> > > Again, we're at a point where we can have counter solutions, but don't
> > > expect me to implement it.
> > >
> >
> > For now I'm just trying to ensure we agree we don't want to break
> existing
> > extensions and the nice ecosystem we built after years.
> > This was really a move forward and it sounds like we broke it at maven 4
> > without any user gain which sounds terrible.
> >
> >
> > >
> > > thanks,
> > > Robert
> > > On 3-1-2021 15:25:21, Romain Manni-Bucau wrote:
> > > Hi all,
> > >
> > > I kind of join Matthieu thoughts there, there is no point to work at
> xml
> > > level to create the 

Re: maven 4.0.0 new XML stuff

[Robert Scholte]

There's just one thing I want to say:
I'm having trouble with the term "broken".
If a Maven project could be built with M3.6.3, it can still be built with M4.
If not, it is either regression (MNG-6957, MNG-7063) which must be fixed, or it 
requires changes to a plugin for understandable reasons (maven-pgp-plugin)
AFAIK an interesting extension like the maven-tiles has been tested and still 
works.

Robert

On 3-1-2021 19:35:25, Romain Manni-Bucau  wrote:
Le dim. 3 janv. 2021 à 19:04, Robert Scholte a
écrit :

> I don't remember all those details anymore, because I hit those in the
> beginning.
> Trying things over and over again I decided that this is probably the most
> successful approach.
>
>
> What of the goals was to keep the pom.xml as is as much as possible.
> We can only decide for the specific Maven elements how to handle them, we
> should not decide about comments and licenses.
> BTW, the license issue was hard to solve. You cannot use it from the pom's
> , because there might be multiple licenses.
>

I disagree, it is saner IMO to evolve to support that than doing
anything else.
Once again you keep things which don't make sense in a consumed pom in
current impl so i'd say the sucess in a few cases breaks as much cases so
we need to revisit anyway IMHO.


>
> The current implementation is a solid way to ensure we're not breaking too
> much, because Maven controls the XML filters.
>

Hmm, breaking extensions seems to break too much (I'm not speaking of other
parts which breaks the ecosystem there but just that is sufficient IMHO to
say we must check back our solution).


>
> Also keep in mind, that I only want Maven to decide which modifications
> are done.
>

For the consumed pom I agree but it is consistent with keeping everything
working instead of breaking too, no?


>
> Current polyglot projects should still work, but they cannot benefit from
> the build/consumer functions yet.
>

So pom -> build model is kept, build model -> produced pom is broken? Is it
the complete status?
Sounds ok for a 4.0 and a 4.1 can fix it if so.
Just want to ensure first part is not broken at all.


>
> Robert
> On 3-1-2021 16:38:38, Romain Manni-Bucau wrote:
> Le dim. 3 janv. 2021 à 16:18, Robert Scholte a
> écrit :
>
> > > So what I was expecting was: raw xml model -> converted to unified
> > consumed model -> extensions -> model processing.
> >
> > This is only the build pom part. You're missing the consume part, where
> > the xml is distributed.
> >
>
> Yes but with previous chain the consume part is "clean/normalize -> dump"
> since we are using consumed model - only standard model - in memory
> already.
>
>
> > Build is raw + enrich, consumer is raw + enrich + reduce (removing
> > relativePath and modules are the first examples, but much more is
> possible)
> >
> > Going for the in memory was also my first thought, but I would loose
> > information, hence I came up with the current implementation.
> >
>
> I don't see what you loose ot be honest.
> You mentionned license but this one is in the pom so not a big deal,
> comments which are undesired IMHO as mentionned and element order which can
> really be discussed since we can desire to enforce an order to normalize
> consumption + it shouldn't be important since from the project point of
> view your pom is already "broken"/lost (as all your intelligence is lost by
> this "not passthrough" process).
> So overall I don't see what you would loose from the consumer side but I
> see what you lost from maven ecosystem side.
>
>
> > Again, we're at a point where we can have counter solutions, but don't
> > expect me to implement it.
> >
>
> For now I'm just trying to ensure we agree we don't want to break existing
> extensions and the nice ecosystem we built after years.
> This was really a move forward and it sounds like we broke it at maven 4
> without any user gain which sounds terrible.
>
>
> >
> > thanks,
> > Robert
> > On 3-1-2021 15:25:21, Romain Manni-Bucau wrote:
> > Hi all,
> >
> > I kind of join Matthieu thoughts there, there is no point to work at xml
> > level to create the consumed pom - comments is not a point since it can
> > commonly/easily refer to a dropped part of the pom so they should be
> > stripped.
> > Current extension model got proven adapted and adopted, using a lower
> level
> > extension API will not since XML is, even if still mainstream, often
> > replaced by alternative configurations and to have done the work to
> inject
> > XML configuration programmatically compred to current option, it is a
> pain.
> > The in memory model should stick to consumed model IMHO - being
> > programmatic there is no point to make it easier, worse case we can add
> > helper beans (injectable) but in terms of model it will not help.
> >
> > So what I was expecting was:
> >
> > raw xml model -> converted to unified consumed model -> extensions ->
> model
> > processing.
> >
> > Indeed, real chain adds a small processing over the first arrow (inject
> > 

Re: maven 4.0.0 new XML stuff

[Romain Manni-Bucau]

Le dim. 3 janv. 2021 à 19:04, Robert Scholte  a
écrit :

> I don't remember all those details anymore, because I hit those in the
> beginning.
> Trying things over and over again I decided that this is probably the most
> successful approach.
>
>
> What of the goals was to keep the pom.xml as is as much as possible.
> We can only decide for the specific Maven elements how to handle them, we
> should not decide about comments and licenses.
> BTW, the license issue was hard to solve. You cannot use it from the pom's
> , because there might be multiple licenses.
>

I disagree, it is saner IMO to evolve  to support that than doing
anything else.
Once again you keep things which don't make sense in a consumed pom in
current impl so i'd say the sucess in a few cases breaks as much cases so
we need to revisit anyway IMHO.


>
> The current implementation is a solid way to ensure we're not breaking too
> much, because Maven controls the XML filters.
>

Hmm, breaking extensions seems to break too much (I'm not speaking of other
parts which breaks the ecosystem there but just that is sufficient IMHO to
say we must check back our solution).


>
> Also keep in mind, that I only want Maven to decide which modifications
> are done.
>

For the consumed pom I agree but it is consistent with keeping everything
working instead of breaking too, no?


>
> Current polyglot projects should still work, but they cannot benefit from
> the build/consumer functions yet.
>

So pom -> build model is kept, build model -> produced pom is broken? Is it
the complete status?
Sounds ok for a 4.0 and a 4.1 can fix it if so.
Just want to ensure first part is not broken at all.


>
> Robert
> On 3-1-2021 16:38:38, Romain Manni-Bucau  wrote:
> Le dim. 3 janv. 2021 à 16:18, Robert Scholte a
> écrit :
>
> > > So what I was expecting was: raw xml model -> converted to unified
> > consumed model -> extensions -> model processing.
> >
> > This is only the build pom part. You're missing the consume part, where
> > the xml is distributed.
> >
>
> Yes but with previous chain the consume part is "clean/normalize -> dump"
> since we are using consumed model - only standard model - in memory
> already.
>
>
> > Build is raw + enrich, consumer is raw + enrich + reduce (removing
> > relativePath and modules are the first examples, but much more is
> possible)
> >
> > Going for the in memory was also my first thought, but I would loose
> > information, hence I came up with the current implementation.
> >
>
> I don't see what you loose ot be honest.
> You mentionned license but this one is in the pom so not a big deal,
> comments which are undesired IMHO as mentionned and element order which can
> really be discussed since we can desire to enforce an order to normalize
> consumption + it shouldn't be important since from the project point of
> view your pom is already "broken"/lost (as all your intelligence is lost by
> this "not passthrough" process).
> So overall I don't see what you would loose from the consumer side but I
> see what you lost from maven ecosystem side.
>
>
> > Again, we're at a point where we can have counter solutions, but don't
> > expect me to implement it.
> >
>
> For now I'm just trying to ensure we agree we don't want to break existing
> extensions and the nice ecosystem we built after years.
> This was really a move forward and it sounds like we broke it at maven 4
> without any user gain which sounds terrible.
>
>
> >
> > thanks,
> > Robert
> > On 3-1-2021 15:25:21, Romain Manni-Bucau wrote:
> > Hi all,
> >
> > I kind of join Matthieu thoughts there, there is no point to work at xml
> > level to create the consumed pom - comments is not a point since it can
> > commonly/easily refer to a dropped part of the pom so they should be
> > stripped.
> > Current extension model got proven adapted and adopted, using a lower
> level
> > extension API will not since XML is, even if still mainstream, often
> > replaced by alternative configurations and to have done the work to
> inject
> > XML configuration programmatically compred to current option, it is a
> pain.
> > The in memory model should stick to consumed model IMHO - being
> > programmatic there is no point to make it easier, worse case we can add
> > helper beans (injectable) but in terms of model it will not help.
> >
> > So what I was expecting was:
> >
> > raw xml model -> converted to unified consumed model -> extensions ->
> model
> > processing.
> >
> > Indeed, real chain adds a small processing over the first arrow (inject
> > versions for example) but nothing crazy and breaking this overall flow
> > which stays user friendly.
> >
> > Strictly speaking the new model is just a built-in extension for me which
> > is particular because it will enforce IDE to integrate a new format -
> > wheres polyglot extensions or others don't require static analyzis by
> > themself not being "standard".
> >
> > That said, there is nothing crazy with current implementation, it just
> > require 

Re: maven 4.0.0 new XML stuff

[Robert Scholte]

I don't remember all those details anymore, because I hit those in the 
beginning.
Trying things over and over again I decided that this is probably the most 
successful approach.


What of the goals was to keep the pom.xml as is as much as possible.
We can only decide for the specific Maven elements how to handle them, we 
should not decide about comments and licenses.
BTW, the license issue was hard to solve. You cannot use it from the pom's 
, because there might be multiple licenses. 

The current implementation is a solid way to ensure we're not breaking too 
much, because Maven controls the XML filters.

Also keep in mind, that I only want Maven to decide which modifications are 
done.

Current polyglot projects should still work, but they cannot benefit from the 
build/consumer functions yet.

Robert
On 3-1-2021 16:38:38, Romain Manni-Bucau  wrote:
Le dim. 3 janv. 2021 à 16:18, Robert Scholte a
écrit :

> > So what I was expecting was: raw xml model -> converted to unified
> consumed model -> extensions -> model processing.
>
> This is only the build pom part. You're missing the consume part, where
> the xml is distributed.
>

Yes but with previous chain the consume part is "clean/normalize -> dump"
since we are using consumed model - only standard model - in memory already.


> Build is raw + enrich, consumer is raw + enrich + reduce (removing
> relativePath and modules are the first examples, but much more is possible)
>
> Going for the in memory was also my first thought, but I would loose
> information, hence I came up with the current implementation.
>

I don't see what you loose ot be honest.
You mentionned license but this one is in the pom so not a big deal,
comments which are undesired IMHO as mentionned and element order which can
really be discussed since we can desire to enforce an order to normalize
consumption + it shouldn't be important since from the project point of
view your pom is already "broken"/lost (as all your intelligence is lost by
this "not passthrough" process).
So overall I don't see what you would loose from the consumer side but I
see what you lost from maven ecosystem side.


> Again, we're at a point where we can have counter solutions, but don't
> expect me to implement it.
>

For now I'm just trying to ensure we agree we don't want to break existing
extensions and the nice ecosystem we built after years.
This was really a move forward and it sounds like we broke it at maven 4
without any user gain which sounds terrible.


>
> thanks,
> Robert
> On 3-1-2021 15:25:21, Romain Manni-Bucau wrote:
> Hi all,
>
> I kind of join Matthieu thoughts there, there is no point to work at xml
> level to create the consumed pom - comments is not a point since it can
> commonly/easily refer to a dropped part of the pom so they should be
> stripped.
> Current extension model got proven adapted and adopted, using a lower level
> extension API will not since XML is, even if still mainstream, often
> replaced by alternative configurations and to have done the work to inject
> XML configuration programmatically compred to current option, it is a pain.
> The in memory model should stick to consumed model IMHO - being
> programmatic there is no point to make it easier, worse case we can add
> helper beans (injectable) but in terms of model it will not help.
>
> So what I was expecting was:
>
> raw xml model -> converted to unified consumed model -> extensions -> model
> processing.
>
> Indeed, real chain adds a small processing over the first arrow (inject
> versions for example) but nothing crazy and breaking this overall flow
> which stays user friendly.
>
> Strictly speaking the new model is just a built-in extension for me which
> is particular because it will enforce IDE to integrate a new format -
> wheres polyglot extensions or others don't require static analyzis by
> themself not being "standard".
>
> That said, there is nothing crazy with current implementation, it just
> require to be updated to be able to take extension changes into account.
> This can be done by making the extension model 'spyable' (ie if a
> dependency/plugin is added it will be reflected in the final written
> pom.xml).
> This sounds - instrumenting the extension model API or doing a diff after
> extension phase - like a compromise and let people gets the best of both
> worlds to me.
>
> Wdyt?
>
> Romain Manni-Bucau
> @rmannibucau | Blog
> | Old Blog
> | Github |
> LinkedIn | Book
>
>
>
> Le dim. 3 janv. 2021 à 14:46, Robert Scholte a
> écrit :
>
> > Hi Matthieu,
> >
> > As you understand, something had to be changed to move Maven forward.
> > I've decided to pick up that challenge and came up with the current
> > solution.
> >
> > My main concerns was that I wanted to keep the fileModel as much as is.
> > That includes the license, comments and element order.
> > This information if not available in the memory model, so I needed the
> > original pom file.
> > With that in mind, the usage of XMLFilters 

Re: maven 4.0.0 new XML stuff

[Romain Manni-Bucau]

Le dim. 3 janv. 2021 à 16:18, Robert Scholte  a
écrit :

> > So what I was expecting was: raw xml model -> converted to unified
> consumed model -> extensions -> model processing.
>
> This is only the build pom part. You're missing the consume part, where
> the xml is distributed.
>

Yes but with previous chain the consume part is "clean/normalize -> dump"
since we are using consumed model - only standard model - in memory already.


> Build is raw + enrich, consumer is raw + enrich + reduce (removing
> relativePath and modules are the first examples, but much more is possible)
>
> Going for the in memory was also my first thought, but I would loose
> information, hence I came up with the current implementation.
>

I don't see what you loose ot be honest.
You mentionned license but this one is in the pom so not a big deal,
comments which are undesired IMHO as mentionned and element order which can
really be discussed since we can desire to enforce an order to normalize
consumption + it shouldn't be important since from the project point of
view your pom is already "broken"/lost (as all your intelligence is lost by
this "not passthrough" process).
So overall I don't see what you would loose from the consumer side but I
see what you lost from maven ecosystem side.


> Again, we're at a point where we can have counter solutions, but don't
> expect me to implement it.
>

For now I'm just trying to ensure we agree we don't want to break existing
extensions and the nice ecosystem we built after years.
This was really a move forward and it sounds like we broke it at maven 4
without any user gain which sounds terrible.


>
> thanks,
> Robert
> On 3-1-2021 15:25:21, Romain Manni-Bucau  wrote:
> Hi all,
>
> I kind of join Matthieu thoughts there, there is no point to work at xml
> level to create the consumed pom - comments is not a point since it can
> commonly/easily refer to a dropped part of the pom so they should be
> stripped.
> Current extension model got proven adapted and adopted, using a lower level
> extension API will not since XML is, even if still mainstream, often
> replaced by alternative configurations and to have done the work to inject
> XML configuration programmatically compred to current option, it is a pain.
> The in memory model should stick to consumed model IMHO - being
> programmatic there is no point to make it easier, worse case we can add
> helper beans (injectable) but in terms of model it will not help.
>
> So what I was expecting was:
>
> raw xml model -> converted to unified consumed model -> extensions -> model
> processing.
>
> Indeed, real chain adds a small processing over the first arrow (inject
> versions for example) but nothing crazy and breaking this overall flow
> which stays user friendly.
>
> Strictly speaking the new model is just a built-in extension for me which
> is particular because it will enforce IDE to integrate a new format -
> wheres polyglot extensions or others don't require static analyzis by
> themself not being "standard".
>
> That said, there is nothing crazy with current implementation, it just
> require to be updated to be able to take extension changes into account.
> This can be done by making the extension model 'spyable' (ie if a
> dependency/plugin is added it will be reflected in the final written
> pom.xml).
> This sounds - instrumenting the extension model API or doing a diff after
> extension phase - like a compromise and let people gets the best of both
> worlds to me.
>
> Wdyt?
>
> Romain Manni-Bucau
> @rmannibucau | Blog
> | Old Blog
> | Github |
> LinkedIn | Book
>
>
>
> Le dim. 3 janv. 2021 à 14:46, Robert Scholte a
> écrit :
>
> > Hi Matthieu,
> >
> > As you understand, something had to be changed to move Maven forward.
> > I've decided to pick up that challenge and came up with the current
> > solution.
> >
> > My main concerns was that I wanted to keep the fileModel as much as is.
> > That includes the license, comments and element order.
> > This information if not available in the memory model, so I needed the
> > original pom file.
> > With that in mind, the usage of XMLFilters looks like the most
> appropriate
> > solution.
> >
> > I am certain that XML is still the most used format, so if we can have
> > improvements for those users, I'm already very happy.
> >
> > And yes, there are plugins that needs to be updated, but doing nothing is
> > not an option anymore.
> >
> > There are more people that share their concerns, but it took me several
> > years to reach this point.
> > We now have something that seems to work, anybody who can improve or can
> > come up with an alternative implementation can do so.
> >
> > thanks,
> > Robert
> > On 3-1-2021 12:55:41, Matthieu Brouillard wrote:
> > Thanks Robert for the video link.
> >
> > I fully understand the rationales behind the separation of
> > build/consumer pom and the video provides some insights on it and you
> > explain the actual implementation to introduce this change.
> > 

Re: maven 4.0.0 new XML stuff

[Robert Scholte]

> So what I was expecting was: raw xml model -> converted to unified consumed 
>model -> extensions -> model processing.

This is only the build pom part. You're missing the consume part, where the xml 
is distributed.
Build is raw + enrich, consumer is raw + enrich + reduce (removing relativePath 
and modules are the first examples, but much more is possible)

Going for the in memory was also my first thought, but I would loose 
information, hence I came up with the current implementation.

Again, we're at a point where we can have counter solutions, but don't expect 
me to implement it.

thanks,
Robert
On 3-1-2021 15:25:21, Romain Manni-Bucau  wrote:
Hi all,

I kind of join Matthieu thoughts there, there is no point to work at xml
level to create the consumed pom - comments is not a point since it can
commonly/easily refer to a dropped part of the pom so they should be
stripped.
Current extension model got proven adapted and adopted, using a lower level
extension API will not since XML is, even if still mainstream, often
replaced by alternative configurations and to have done the work to inject
XML configuration programmatically compred to current option, it is a pain.
The in memory model should stick to consumed model IMHO - being
programmatic there is no point to make it easier, worse case we can add
helper beans (injectable) but in terms of model it will not help.

So what I was expecting was:

raw xml model -> converted to unified consumed model -> extensions -> model
processing.

Indeed, real chain adds a small processing over the first arrow (inject
versions for example) but nothing crazy and breaking this overall flow
which stays user friendly.

Strictly speaking the new model is just a built-in extension for me which
is particular because it will enforce IDE to integrate a new format -
wheres polyglot extensions or others don't require static analyzis by
themself not being "standard".

That said, there is nothing crazy with current implementation, it just
require to be updated to be able to take extension changes into account.
This can be done by making the extension model 'spyable' (ie if a
dependency/plugin is added it will be reflected in the final written
pom.xml).
This sounds - instrumenting the extension model API or doing a diff after
extension phase - like a compromise and let people gets the best of both
worlds to me.

Wdyt?

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



Le dim. 3 janv. 2021 à 14:46, Robert Scholte a
écrit :

> Hi Matthieu,
>
> As you understand, something had to be changed to move Maven forward.
> I've decided to pick up that challenge and came up with the current
> solution.
>
> My main concerns was that I wanted to keep the fileModel as much as is.
> That includes the license, comments and element order.
> This information if not available in the memory model, so I needed the
> original pom file.
> With that in mind, the usage of XMLFilters looks like the most appropriate
> solution.
>
> I am certain that XML is still the most used format, so if we can have
> improvements for those users, I'm already very happy.
>
> And yes, there are plugins that needs to be updated, but doing nothing is
> not an option anymore.
>
> There are more people that share their concerns, but it took me several
> years to reach this point.
> We now have something that seems to work, anybody who can improve or can
> come up with an alternative implementation can do so.
>
> thanks,
> Robert
> On 3-1-2021 12:55:41, Matthieu Brouillard wrote:
> Thanks Robert for the video link.
>
> I fully understand the rationales behind the separation of
> build/consumer pom and the video provides some insights on it and you
> explain the actual implementation to introduce this change.
> Still I do not fully understand why it was decided to work on top of XML by
> filtering/enhancing it instead of working at the POM (in
> memory datamodel) level.
> With the current understanding I have, by doing this choice of working at
> XML level, it looks like it was decided to bypass (if not kill) core
> extensions that enhance the POM itself and not the pom.xml ; here I can
> think of (but probably not limited to):
> - polyglot-maven: do not use XML but other format to describe the POM
> (yaml, json, kotlin, java, other XML formats, ...)
> - jgitver-maven-plugin (or forks like maven-git-versioning-extension):
> dynamic computation of projects version based on git history
>
> With the introduction of core extensions, I thought it was a move to open
> the internals and let externals contribute to the capabilities of maven.
> With the move to a XML handling chain, I see it as a restriction/regress in
> favor of core closed functionalities. An example of that is what is
> provided as CIFriendly stuff, IMO it could/should have been provided by a
> plugin/extension but instead it is hard written in maven core and is not
> opened for external contribution (plugin/extension I mean).
>
> Perhaps 

Re: maven 4.0.0 new XML stuff

[Romain Manni-Bucau]

Hi all,

I kind of join Matthieu thoughts there, there is no point to work at xml
level to create the consumed pom - comments is not a point since it can
commonly/easily refer to a dropped part of the pom so they should be
stripped.
Current extension model got proven adapted and adopted, using a lower level
extension API will not since XML is, even if still mainstream, often
replaced by alternative configurations and to have done the work to inject
XML configuration programmatically compred to current option, it is a pain.
The in memory model should stick to consumed model IMHO - being
programmatic there is no point to make it easier, worse case we can add
helper beans (injectable) but in terms of model it will not help.

So what I was expecting was:

raw xml model -> converted to unified consumed model -> extensions -> model
processing.

Indeed, real chain adds a small processing over the first arrow (inject
versions for example) but nothing crazy and breaking this overall flow
which stays user friendly.

Strictly speaking the new model is just a built-in extension for me which
is particular because it will enforce IDE to integrate a new format -
wheres polyglot extensions or others don't require static analyzis by
themself not being "standard".

That said, there is nothing crazy with current implementation, it just
require to be updated to be able to take extension changes into account.
This can be done by making the extension model 'spyable' (ie if a
dependency/plugin is added it will be reflected in the final written
pom.xml).
This sounds - instrumenting the extension model API or doing a diff after
extension phase - like a compromise and let people gets the best of both
worlds to me.

Wdyt?

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



Le dim. 3 janv. 2021 à 14:46, Robert Scholte  a
écrit :

> Hi Matthieu,
>
> As you understand, something had to be changed to move Maven forward.
> I've decided to pick up that challenge and came up with the current
> solution.
>
> My main concerns was that I wanted to keep the fileModel as much as is.
> That includes the license, comments and element order.
> This information if not available in the memory model, so I needed the
> original pom file.
> With that in mind, the usage of XMLFilters looks like the most appropriate
> solution.
>
> I am certain that XML is still the most used format, so if we can have
> improvements for those users, I'm already very happy.
>
> And yes, there are plugins that needs to be updated, but doing nothing is
> not an option anymore.
>
> There are more people that share their concerns, but it took me several
> years to reach this point.
> We now have something that seems to work, anybody who can improve or can
> come up with an alternative implementation can do so.
>
> thanks,
> Robert
> On 3-1-2021 12:55:41, Matthieu Brouillard  wrote:
> Thanks Robert for the video link.
>
> I fully understand the rationales behind the separation of
> build/consumer pom and the video provides some insights on it and you
> explain the actual implementation to introduce this change.
> Still I do not fully understand why it was decided to work on top of XML by
> filtering/enhancing it instead of working at the POM (in
> memory datamodel) level.
> With the current understanding I have, by doing this choice of working at
> XML level, it looks like it was decided to bypass (if not kill) core
> extensions that enhance the POM itself and not the pom.xml ; here I can
> think of (but probably not limited to):
> - polyglot-maven: do not use XML but other format to describe the POM
> (yaml, json, kotlin, java, other XML formats, ...)
> - jgitver-maven-plugin (or forks like maven-git-versioning-extension):
> dynamic computation of projects version based on git history
>
> With the introduction of core extensions, I thought it was a move to open
> the internals and let externals contribute to the capabilities of maven.
> With the move to a XML handling chain, I see it as a restriction/regress in
> favor of core closed functionalities. An example of that is what is
> provided as CIFriendly stuff, IMO it could/should have been provided by a
> plugin/extension but instead it is hard written in maven core and is not
> opened for external contribution (plugin/extension I mean).
>
> Perhaps I am totally wrong but I think that maven core should define all
> its expectations at an API level so that extensions/plugins could hook at
> this API level. The default packaging of maven could/should provide default
> implementations of those expectations (for example reading a pom.xml file
> to a POM model, dumping a POM to a pom-4.0.0.xml, transforming/reducing a
> POM to POM-consumer, 

Re: maven 4.0.0 new XML stuff

[Robert Scholte]

Hi Matthieu,

As you understand, something had to be changed to move Maven forward.
I've decided to pick up that challenge and came up with the current solution.

My main concerns was that I wanted to keep the fileModel as much as is.
That includes the license, comments and element order. 
This information if not available in the memory model, so I needed the original 
pom file.
With that in mind, the usage of XMLFilters looks like the most appropriate 
solution.

I am certain that XML is still the most used format, so if we can have 
improvements for those users, I'm already very happy.

And yes, there are plugins that needs to be updated, but doing nothing is not 
an option anymore.

There are more people that share their concerns, but it took me several years 
to reach this point.
We now have something that seems to work, anybody who can improve or can come 
up with an alternative implementation can do so.

thanks,
Robert
On 3-1-2021 12:55:41, Matthieu Brouillard  wrote:
Thanks Robert for the video link.

I fully understand the rationales behind the separation of
build/consumer pom and the video provides some insights on it and you
explain the actual implementation to introduce this change.
Still I do not fully understand why it was decided to work on top of XML by
filtering/enhancing it instead of working at the POM (in
memory datamodel) level.
With the current understanding I have, by doing this choice of working at
XML level, it looks like it was decided to bypass (if not kill) core
extensions that enhance the POM itself and not the pom.xml ; here I can
think of (but probably not limited to):
- polyglot-maven: do not use XML but other format to describe the POM
(yaml, json, kotlin, java, other XML formats, ...)
- jgitver-maven-plugin (or forks like maven-git-versioning-extension):
dynamic computation of projects version based on git history

With the introduction of core extensions, I thought it was a move to open
the internals and let externals contribute to the capabilities of maven.
With the move to a XML handling chain, I see it as a restriction/regress in
favor of core closed functionalities. An example of that is what is
provided as CIFriendly stuff, IMO it could/should have been provided by a
plugin/extension but instead it is hard written in maven core and is not
opened for external contribution (plugin/extension I mean).

Perhaps I am totally wrong but I think that maven core should define all
its expectations at an API level so that extensions/plugins could hook at
this API level. The default packaging of maven could/should provide default
implementations of those expectations (for example reading a pom.xml file
to a POM model, dumping a POM to a pom-4.0.0.xml, transforming/reducing a
POM to POM-consumer, dumping POM-consumer to pom-consumer-5.0.0.xml, ...)
and let extensions/plugins/default implementations work along the build
process with the API & POMs to provide different features and capabilities.

Matthieu

On Thu, Dec 31, 2020 at 7:01 PM Robert Scholte wrote:

> I've made a recording[1] about it, which hopefully answers most questions.
>
> Robert
>
> [1] https://youtu.be/KDAmlNKZJto
>
> On 31-12-2020 16:18:57, Matthieu Brouillard
> wrote:
> > Not exactly sure what work you mean
> everything related to maven-xml: Build/ConsumerPomXMLFilterxxx,
> Build/ConsumerModelSource and the transformer stuff.
> Especially, when looking at classes like CiFriendlyXMLFilter, I would have
> thought that such things could have been done elsewhere, working on the
> object model (not on the XML stuff) especially for the BuildPom part.
>
> > however specifically the consumer POM integrates with so many external
> ecosystems
> We're aligned here, this has to be stable and well defined by a schema.
>
> Matthieu
>
> On Thu, Dec 31, 2020 at 3:59 PM Bernd Eckenfels
> wrote:
>
> > Hello,
> >
> > Not exactly sure what work you mean and I fully agree that using a core
> > model should still be the API for plugins and extensions to work with,
> > however specifically the consumer POM integrates with so many external
> > ecosystems, I would expect it to be defined in terms of XML Schema with
> > explicite semantic (and the inherent compatibility with exiting POMs).
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> > 
> > Von: Matthieu BROUILLARD
> > Gesendet: Thursday, December 31, 2020 3:19:09 PM
> > An: dev@maven.apache.org
> > Betreff: maven 4.0.0 new XML stuff
> >
> > Hello all,
> >
> > regarding the active work occurring for maven 4.0.0 I noticed the
> > introduction of a lot of new stuff around SAX parsing & filtering.
> > I am wondering if that means that it was decided that the input format of
> > maven projects will be XML forever meaning probably, among others, the
> end
> > of polyglot extensions.
> > Could you explain such a move (or point to rationals/documents) and why
> you
> > did not leverage working on the in memory object model allowing
> > 

Re: maven 4.0.0 new XML stuff

[Matthieu Brouillard]

Thanks Robert for the video link.

I fully understand the rationales behind the separation of
build/consumer pom and the video provides some insights on it and you
explain the actual implementation to introduce this change.
Still I do not fully understand why it was decided to work on top of XML by
filtering/enhancing it instead of working at the POM (in
memory datamodel) level.
With the current understanding I have, by doing this choice of working at
XML level, it looks like it was decided to bypass (if not kill) core
extensions that enhance the POM itself and not the pom.xml ; here I can
think of (but probably not limited to):
- polyglot-maven: do not use XML but other format to describe the POM
(yaml, json, kotlin, java, other XML formats, ...)
- jgitver-maven-plugin (or forks like maven-git-versioning-extension):
dynamic computation of projects version based on git history

With the introduction of core extensions, I thought it was a move to open
the internals and let externals contribute to the capabilities of maven.
With the move to a XML handling chain, I see it as a restriction/regress in
favor of core closed functionalities. An example of that is what is
provided as CIFriendly stuff, IMO it could/should have been provided by a
plugin/extension but instead it is hard written in maven core and is not
opened for external contribution (plugin/extension I mean).

Perhaps I am totally wrong but I think that maven core should define all
its expectations at an API level so that extensions/plugins could hook at
this API level. The default packaging of maven could/should provide default
implementations of those expectations (for example reading a pom.xml file
to a POM model, dumping a POM to a pom-4.0.0.xml, transforming/reducing a
POM to POM-consumer, dumping POM-consumer to pom-consumer-5.0.0.xml, ...)
and let extensions/plugins/default implementations work along the build
process with the API & POMs to provide different features and capabilities.

Matthieu

On Thu, Dec 31, 2020 at 7:01 PM Robert Scholte  wrote:

> I've made a recording[1] about it, which hopefully answers most questions.
>
> Robert
>
> [1] https://youtu.be/KDAmlNKZJto
>
> On 31-12-2020 16:18:57, Matthieu Brouillard 
> wrote:
> > Not exactly sure what work you mean
> everything related to maven-xml: Build/ConsumerPomXMLFilterxxx,
> Build/ConsumerModelSource and the transformer stuff.
> Especially, when looking at classes like CiFriendlyXMLFilter, I would have
> thought that such things could have been done elsewhere, working on the
> object model (not on the XML stuff) especially for the BuildPom part.
>
> > however specifically the consumer POM integrates with so many external
> ecosystems
> We're aligned here, this has to be stable and well defined by a schema.
>
> Matthieu
>
> On Thu, Dec 31, 2020 at 3:59 PM Bernd Eckenfels
> wrote:
>
> > Hello,
> >
> > Not exactly sure what work you mean and I fully agree that using a core
> > model should still be the API for plugins and extensions to work with,
> > however specifically the consumer POM integrates with so many external
> > ecosystems, I would expect it to be defined in terms of XML Schema with
> > explicite semantic (and the inherent compatibility with exiting POMs).
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> > 
> > Von: Matthieu BROUILLARD
> > Gesendet: Thursday, December 31, 2020 3:19:09 PM
> > An: dev@maven.apache.org
> > Betreff: maven 4.0.0 new XML stuff
> >
> > Hello all,
> >
> > regarding the active work occurring for maven 4.0.0 I noticed the
> > introduction of a lot of new stuff around SAX parsing & filtering.
> > I am wondering if that means that it was decided that the input format of
> > maven projects will be XML forever meaning probably, among others, the
> end
> > of polyglot extensions.
> > Could you explain such a move (or point to rationals/documents) and why
> you
> > did not leverage working on the in memory object model allowing
> > extensions/plugins to contribute/hook in the chain of building the
> BuildPOM
> > & ConsumePOM? In the past I really thought that this move to 'Build vs
> > Consumer' POM would make clear separations between the input format of
> > descriptors and the core system but I perhaps misunderstood things.
> >
> > Also, are there plans regarding the future of core extensions?
> > With core extensions it was possible to hook into the POM model loading
> and
> > do transformations to do dynamic changes but by working on the XML
> directly
> > I see a shift (if not red stop) in this contribution/delegation
> mechanism.
> >
> > Thanks for your time & answers.
> >
> > Matthieu Brouillard
> >
>

Re: maven 4.0.0 new XML stuff

[Robert Scholte]

Yes, I think so.
Per artifact, if it includes the POM, we need to decide which one to include.
It should never be the raw one (e.g. it might miss the version to its parent), 
most of the time the consumer POM, but sometimes the build POM.

Robert
On 1-1-2021 15:14:52, Gary Gregory  wrote:
Great idea to record this video, TY!

I would guess that the javadoc plugin would change in the same way the
source plugin needs to change, right?

Gary

On Thu, Dec 31, 2020, 13:01 Robert Scholte wrote:

> I've made a recording[1] about it, which hopefully answers most questions.
>
> Robert
>
> [1] https://youtu.be/KDAmlNKZJto
>
> On 31-12-2020 16:18:57, Matthieu Brouillard
> wrote:
> > Not exactly sure what work you mean
> everything related to maven-xml: Build/ConsumerPomXMLFilterxxx,
> Build/ConsumerModelSource and the transformer stuff.
> Especially, when looking at classes like CiFriendlyXMLFilter, I would have
> thought that such things could have been done elsewhere, working on the
> object model (not on the XML stuff) especially for the BuildPom part.
>
> > however specifically the consumer POM integrates with so many external
> ecosystems
> We're aligned here, this has to be stable and well defined by a schema.
>
> Matthieu
>
> On Thu, Dec 31, 2020 at 3:59 PM Bernd Eckenfels
> wrote:
>
> > Hello,
> >
> > Not exactly sure what work you mean and I fully agree that using a core
> > model should still be the API for plugins and extensions to work with,
> > however specifically the consumer POM integrates with so many external
> > ecosystems, I would expect it to be defined in terms of XML Schema with
> > explicite semantic (and the inherent compatibility with exiting POMs).
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> > 
> > Von: Matthieu BROUILLARD
> > Gesendet: Thursday, December 31, 2020 3:19:09 PM
> > An: dev@maven.apache.org
> > Betreff: maven 4.0.0 new XML stuff
> >
> > Hello all,
> >
> > regarding the active work occurring for maven 4.0.0 I noticed the
> > introduction of a lot of new stuff around SAX parsing & filtering.
> > I am wondering if that means that it was decided that the input format of
> > maven projects will be XML forever meaning probably, among others, the
> end
> > of polyglot extensions.
> > Could you explain such a move (or point to rationals/documents) and why
> you
> > did not leverage working on the in memory object model allowing
> > extensions/plugins to contribute/hook in the chain of building the
> BuildPOM
> > & ConsumePOM? In the past I really thought that this move to 'Build vs
> > Consumer' POM would make clear separations between the input format of
> > descriptors and the core system but I perhaps misunderstood things.
> >
> > Also, are there plans regarding the future of core extensions?
> > With core extensions it was possible to hook into the POM model loading
> and
> > do transformations to do dynamic changes but by working on the XML
> directly
> > I see a shift (if not red stop) in this contribution/delegation
> mechanism.
> >
> > Thanks for your time & answers.
> >
> > Matthieu Brouillard
> >
>

Re: maven 4.0.0 new XML stuff

[Gary Gregory]

Great idea to record this video, TY!

I would guess that the javadoc plugin would change in the same way the
source plugin needs to change, right?

Gary

On Thu, Dec 31, 2020, 13:01 Robert Scholte  wrote:

> I've made a recording[1] about it, which hopefully answers most questions.
>
> Robert
>
> [1] https://youtu.be/KDAmlNKZJto
>
> On 31-12-2020 16:18:57, Matthieu Brouillard 
> wrote:
> > Not exactly sure what work you mean
> everything related to maven-xml: Build/ConsumerPomXMLFilterxxx,
> Build/ConsumerModelSource and the transformer stuff.
> Especially, when looking at classes like CiFriendlyXMLFilter, I would have
> thought that such things could have been done elsewhere, working on the
> object model (not on the XML stuff) especially for the BuildPom part.
>
> > however specifically the consumer POM integrates with so many external
> ecosystems
> We're aligned here, this has to be stable and well defined by a schema.
>
> Matthieu
>
> On Thu, Dec 31, 2020 at 3:59 PM Bernd Eckenfels
> wrote:
>
> > Hello,
> >
> > Not exactly sure what work you mean and I fully agree that using a core
> > model should still be the API for plugins and extensions to work with,
> > however specifically the consumer POM integrates with so many external
> > ecosystems, I would expect it to be defined in terms of XML Schema with
> > explicite semantic (and the inherent compatibility with exiting POMs).
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> > 
> > Von: Matthieu BROUILLARD
> > Gesendet: Thursday, December 31, 2020 3:19:09 PM
> > An: dev@maven.apache.org
> > Betreff: maven 4.0.0 new XML stuff
> >
> > Hello all,
> >
> > regarding the active work occurring for maven 4.0.0 I noticed the
> > introduction of a lot of new stuff around SAX parsing & filtering.
> > I am wondering if that means that it was decided that the input format of
> > maven projects will be XML forever meaning probably, among others, the
> end
> > of polyglot extensions.
> > Could you explain such a move (or point to rationals/documents) and why
> you
> > did not leverage working on the in memory object model allowing
> > extensions/plugins to contribute/hook in the chain of building the
> BuildPOM
> > & ConsumePOM? In the past I really thought that this move to 'Build vs
> > Consumer' POM would make clear separations between the input format of
> > descriptors and the core system but I perhaps misunderstood things.
> >
> > Also, are there plans regarding the future of core extensions?
> > With core extensions it was possible to hook into the POM model loading
> and
> > do transformations to do dynamic changes but by working on the XML
> directly
> > I see a shift (if not red stop) in this contribution/delegation
> mechanism.
> >
> > Thanks for your time & answers.
> >
> > Matthieu Brouillard
> >
>

Re: maven 4.0.0 new XML stuff

[Robert Scholte]

I've made a recording[1] about it, which hopefully answers most questions.

Robert

[1] https://youtu.be/KDAmlNKZJto

On 31-12-2020 16:18:57, Matthieu Brouillard  wrote:
> Not exactly sure what work you mean
everything related to maven-xml: Build/ConsumerPomXMLFilterxxx,
Build/ConsumerModelSource and the transformer stuff.
Especially, when looking at classes like CiFriendlyXMLFilter, I would have
thought that such things could have been done elsewhere, working on the
object model (not on the XML stuff) especially for the BuildPom part.

> however specifically the consumer POM integrates with so many external
ecosystems
We're aligned here, this has to be stable and well defined by a schema.

Matthieu

On Thu, Dec 31, 2020 at 3:59 PM Bernd Eckenfels
wrote:

> Hello,
>
> Not exactly sure what work you mean and I fully agree that using a core
> model should still be the API for plugins and extensions to work with,
> however specifically the consumer POM integrates with so many external
> ecosystems, I would expect it to be defined in terms of XML Schema with
> explicite semantic (and the inherent compatibility with exiting POMs).
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> Von: Matthieu BROUILLARD
> Gesendet: Thursday, December 31, 2020 3:19:09 PM
> An: dev@maven.apache.org
> Betreff: maven 4.0.0 new XML stuff
>
> Hello all,
>
> regarding the active work occurring for maven 4.0.0 I noticed the
> introduction of a lot of new stuff around SAX parsing & filtering.
> I am wondering if that means that it was decided that the input format of
> maven projects will be XML forever meaning probably, among others, the end
> of polyglot extensions.
> Could you explain such a move (or point to rationals/documents) and why you
> did not leverage working on the in memory object model allowing
> extensions/plugins to contribute/hook in the chain of building the BuildPOM
> & ConsumePOM? In the past I really thought that this move to 'Build vs
> Consumer' POM would make clear separations between the input format of
> descriptors and the core system but I perhaps misunderstood things.
>
> Also, are there plans regarding the future of core extensions?
> With core extensions it was possible to hook into the POM model loading and
> do transformations to do dynamic changes but by working on the XML directly
> I see a shift (if not red stop) in this contribution/delegation mechanism.
>
> Thanks for your time & answers.
>
> Matthieu Brouillard
>

Re: maven 4.0.0 new XML stuff

[Matthieu Brouillard]

> Not exactly sure what work you mean
everything related to maven-xml: Build/ConsumerPomXMLFilterxxx,
Build/ConsumerModelSource and the transformer stuff.
Especially, when looking at classes like CiFriendlyXMLFilter, I would have
thought that such things could have been done elsewhere, working on the
object model (not on the XML stuff) especially for the BuildPom part.

> however specifically the consumer POM integrates with so many external
ecosystems
We're aligned here, this has to be stable and well defined by a schema.

Matthieu

On Thu, Dec 31, 2020 at 3:59 PM Bernd Eckenfels 
wrote:

> Hello,
>
> Not exactly sure what work you mean and I fully agree that using a core
> model should still be the API for plugins and extensions to work with,
> however specifically the consumer POM integrates with so many external
> ecosystems, I would expect it to be defined in terms of XML Schema with
> explicite semantic (and the inherent compatibility with exiting POMs).
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> Von: Matthieu BROUILLARD 
> Gesendet: Thursday, December 31, 2020 3:19:09 PM
> An: dev@maven.apache.org 
> Betreff: maven 4.0.0 new XML stuff
>
> Hello all,
>
> regarding the active work occurring for maven 4.0.0 I noticed the
> introduction of a lot of new stuff around SAX parsing & filtering.
> I am wondering if that means that it was decided that the input format of
> maven projects will be XML forever meaning probably, among others, the end
> of polyglot extensions.
> Could you explain such a move (or point to rationals/documents) and why you
> did not leverage working on the in memory object model allowing
> extensions/plugins to contribute/hook in the chain of building the BuildPOM
> & ConsumePOM? In the past I really thought that this move to 'Build vs
> Consumer' POM would make clear separations between the input format of
> descriptors and the core system but I perhaps misunderstood things.
>
> Also, are there plans regarding the future of core extensions?
> With core extensions it was possible to hook into the POM model loading and
> do transformations to do dynamic changes but by working on the XML directly
> I see a shift (if not red stop) in this contribution/delegation mechanism.
>
> Thanks for your time & answers.
>
> Matthieu Brouillard
>

Re: maven 4.0.0 new XML stuff

[Bernd Eckenfels]

Hello,

Not exactly sure what work you mean and I fully agree that using a core model 
should still be the API for plugins and extensions to work with, however 
specifically the consumer POM integrates with so many external ecosystems, I 
would expect it to be defined in terms of XML Schema with explicite semantic 
(and the inherent compatibility with exiting POMs).

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Matthieu BROUILLARD 
Gesendet: Thursday, December 31, 2020 3:19:09 PM
An: dev@maven.apache.org 
Betreff: maven 4.0.0 new XML stuff

Hello all,

regarding the active work occurring for maven 4.0.0 I noticed the
introduction of a lot of new stuff around SAX parsing & filtering.
I am wondering if that means that it was decided that the input format of
maven projects will be XML forever meaning probably, among others, the end
of polyglot extensions.
Could you explain such a move (or point to rationals/documents) and why you
did not leverage working on the in memory object model allowing
extensions/plugins to contribute/hook in the chain of building the BuildPOM
& ConsumePOM? In the past I really thought that this move to 'Build vs
Consumer' POM would make clear separations between the input format of
descriptors and the core system but I perhaps misunderstood things.

Also, are there plans regarding the future of core extensions?
With core extensions it was possible to hook into the POM model loading and
do transformations to do dynamic changes but by working on the XML directly
I see a shift (if not red stop) in this contribution/delegation mechanism.

Thanks for your time & answers.

Matthieu Brouillard

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 
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 :
> > 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-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven 4.0.0

[Romain Manni-Bucau]

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

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


2017-11-13 11:11 GMT+01:00 Jörg Schaible :
> 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-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 4.0.0

[Jörg Schaible]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 4.0.0

[Mark Derricutt]

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


signature.asc
Description: OpenPGP digital signature

Re: Maven 4.0.0

[Stephen Connolly]

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  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 
> 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.conno...@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

[Stephen Connolly]

On Sun 12 Nov 2017 at 07:41, Chris Graham  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.conno...@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

[Chris Graham]

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  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.conno...@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

[Chris Graham]

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.conno...@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

[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?)

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


2017-11-09 9:30 GMT+01:00 Jörg Schaible :
> 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 + 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-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 4.0.0

[Jörg Schaible]

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 + 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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 4.0.0

[Romain Manni-Bucau]

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

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


2017-11-06 11:16 GMT+01:00 Romain Manni-Bucau <rmannibu...@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 <stephen.alan.conno...@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 <rmannibu...@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 <rmannibu...@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 <e...@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 <m...@talios.com>
>>> >> > *Gesendet: *Sonntag, 5. November 2017 22:20
>>> >> > *An: *Maven Developers List <dev@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
&g

Re: Maven 4.0.0

[Romain Manni-Bucau]

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


2017-11-06 10:00 GMT+01:00 Stephen Connolly <stephen.alan.conno...@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 <rmannibu...@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 <rmannibu...@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 <e...@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 <m...@talios.com>
>> >> > *Gesendet: *Sonntag, 5. November 2017 22:20
>> >> > *An: *Maven Developers List <dev@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 o

Re: Maven 4.0.0

[Stephen Connolly]

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 <rmannibu...@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 <rmannibu...@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 <e...@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 <m...@talios.com>
> >> > *Gesendet: *Sonntag, 5. November 2017 22:20
> >> > *An: *Maven Developers List <dev@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-unsubscr...@maven.apache.org
> >> > For additional commands, e-mail: dev-h...@maven.apache.org
> >> >
> >>
> > --
> > Sent from my phone
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven 4.0.0

[Romain Manni-Bucau]

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

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


2017-11-06 9:37 GMT+01:00 Stephen Connolly <stephen.alan.conno...@gmail.com>:
> On Mon 6 Nov 2017 at 08:13, Romain Manni-Bucau <rmannibu...@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 <e...@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 <m...@talios.com>
>> > *Gesendet: *Sonntag, 5. November 2017 22:20
>> > *An: *Maven Developers List <dev@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-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: dev-h...@maven.apache.org
>> >
>>
> --
> Sent from my phone

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 4.0.0

[Stephen Connolly]

On Mon 6 Nov 2017 at 08:13, Romain Manni-Bucau <rmannibu...@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 <e...@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 <m...@talios.com>
> > *Gesendet: *Sonntag, 5. November 2017 22:20
> > *An: *Maven Developers List <dev@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-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
-- 
Sent from my phone

Re: Maven 4.0.0

[Romain Manni-Bucau]

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 <e...@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 <m...@talios.com>
> *Gesendet: *Sonntag, 5. November 2017 22:20
> *An: *Maven Developers List <dev@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-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

Re: Maven 4.0.0

[Mark Derricutt]

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

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

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

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

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


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

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

Mark



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

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


signature.asc
Description: OpenPGP digital signature

Re: Maven 4.0.0

[Robert Scholte]

On Sun, 05 Nov 2017 07:04:54 +0100, Hervé BOUTEMY   
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

 wrote:
> 2017-11-04 18:17 GMT+01:00 Stephen Connolly
>
> :
>> On Sat 4 Nov 2017 at 17:11, Romain Manni-Bucau  


>>
>> 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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 4.0.0

[Hervé BOUTEMY]

Le samedi 4 novembre 2017, 22:35:35 CET Robert Scholte a écrit :
> On Sat, 04 Nov 2017 18:34:14 +0100, Romain Manni-Bucau
> 
>  wrote:
> > 2017-11-04 18:17 GMT+01:00 Stephen Connolly
> > 
> > :
> >> On Sat 4 Nov 2017 at 17:11, Romain Manni-Bucau 
> >> 
> >> 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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 4.0.0

[Robert Scholte]

On Sat, 04 Nov 2017 21:42:34 +0100, Mark Derricutt  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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 4.0.0

[Robert Scholte]

On Sat, 04 Nov 2017 18:34:14 +0100, Romain Manni-Bucau  
 wrote:


2017-11-04 18:17 GMT+01:00 Stephen Connolly  
:

On Sat 4 Nov 2017 at 17:11, Romain Manni-Bucau 
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"  


a écrit :

> On 4 November 2017 at 07:30, Hervé BOUTEMY 
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   
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 

Re: Maven 4.0.0

[Mark Derricutt]

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

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

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

Mark

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

On Sun, Nov 5, 2017 at 1:20 AM, Stephen Connolly <
stephen.alan.conno...@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

[Stephen Connolly]

On Sat 4 Nov 2017 at 17:52, Hervé BOUTEMY  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-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 4.0.0

[Romain Manni-Bucau]

2017-11-04 18:17 GMT+01:00 Stephen Connolly :
> On Sat 4 Nov 2017 at 17:11, Romain Manni-Bucau 
> 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" 
>> a écrit :
>>
>> > On 4 November 2017 at 07:30, Hervé BOUTEMY 
>> 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  wrote:
>> > > > >> > *3. More pluggable dependency resolver:*
>> > > > >>
>> > > > >> I am willing to let this be optional scope for now. May be yanked
>> if
>> > > 

Re: Maven 4.0.0

[Stephen Connolly]

On Sat 4 Nov 2017 at 17:11, Romain Manni-Bucau 
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" 
> a écrit :
>
> > On 4 November 2017 at 07:30, Hervé BOUTEMY 
> 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  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-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>
-- 
Sent from my phone

Re: Maven 4.0.0

[Romain Manni-Bucau]

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" 
a écrit :

> On 4 November 2017 at 07:30, Hervé BOUTEMY  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  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-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Maven 4.0.0

[Stephen Connolly]

On 4 November 2017 at 07:30, Hervé BOUTEMY  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  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-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven 4.0.0

[Hervé BOUTEMY]

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  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-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 4.0.0

[John Patrick]

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  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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 4.0.0

[Stephen Connolly]

On Sat 4 Nov 2017 at 12:52, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On Sat 4 Nov 2017 at 12:49, Michael Osipov  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-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>> --
> Sent from my phone
>
-- 
Sent from my phone

Re: Maven 4.0.0

[Stephen Connolly]

On Sat 4 Nov 2017 at 13:18, Paul Hammant  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

[Paul Hammant]

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

[Stephen Connolly]

On Sat 4 Nov 2017 at 12:24, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On Sat 4 Nov 2017 at 12:20, Stephen Connolly <
> stephen.alan.conno...@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

[Stephen Connolly]

On Sat 4 Nov 2017 at 12:50, Paul Hammant  wrote:

> To add to scope for Maven 4, IMO:
>
> *1.  tag could have an optional  arg:*
>
> 
> my-team,mycorp
> com.thoughtworks.xstream
> xstream
> 1.4.10
> 


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):*
>
> 
> com.thoughtworks.xstream:xstream:1.4.10
> 
>
> or
>
> 
>
>
> 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

[Stephen Connolly]

On Sat 4 Nov 2017 at 12:49, Michael Osipov  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-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: Maven 4.0.0

[Paul Hammant]

To add to scope for Maven 4, IMO:

*1.  tag could have an optional  arg:*


my-team,mycorp
com.thoughtworks.xstream
xstream
1.4.10



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):*


com.thoughtworks.xstream:xstream:1.4.10


or




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

[Michael Osipov]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 4.0.0

[Stephen Connolly]

On Sat 4 Nov 2017 at 12:20, Stephen Connolly <
stephen.alan.conno...@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] Removing ability for plugins to dynamically inject dependencies

[Lennart Jörelid]

Hello all,

Let’s see if we can focus on the issue at hand here.

12 apr 2014 kl. 16:59 skrev Jason van Zyl ja...@takari.io:

 
 On Apr 12, 2014, at 7:24 AM, Lennart Jörelid lennart.jore...@gmail.com 
 wrote:
 
 Oh I know it is the recommended practise, but I believe that particular
 recommendation is flawed since it does not consider the needs of *big*
 systems with reactors containing lots of projects.
 
 This simply is not the case. It is precisely for manageability reasons in 
 large projects that you need to be specific.

You seem to consider transitive dependencies unspecific” or ”unmanageable” - 
as opposed to the nature of explicit dependency declarations repeated 
throughout the entire reactor. This is not the case; in declaring a dependency 
to an API project from an impl project within the same reactor I automatically 
say ”I will use/import the dependencies from the API I am implementing” … and 
then adding dependency declarations used only by the local impl project itself. 
I don’t want to repeat all dependency definitions from the API project *again* 
within the impl project since it would only add bloat to my impl project 
dependency definitions.

I believe that all of us agree that it is sensible to define a Parent POM 
containing a dependencyManagement section to harmonize versions and default 
scopes of dependencies used throughout the reactor. This implies that all 
[external] dependencies within POMs in the reactor are defined on the form

dependency
groupIdorg.slf4j/groupId
artifactIdslf4j-api/artifactId
/dependency

What you are suggesting is that we should change the current mechanics of Maven 
within compile scope (but not runtime/test scope since we would actually need 
the transitive dependencies there, if I understand your suggestion correctly) 
to force us to repeat all dependency definitions already present within 
projects I depend upon. I’m saying this is a poor idea, since it will require 
maven users to repeat the dependency (such as the example above) in all 
projects within the reactor - even if they depend on other projects in the 
reactor that already defined it. Your suggestion of ignoring today’s transitive 
dependencies in compile scope would only make sense if you believe that the 
majority of people using Maven out there do not understand transitive 
dependencies at all …. implying we should make them repeat dependency mechanics 
”for clarity”. In my view, this is an incorrect assumption.

Let’s compare the tasks required for refactoring a big reactor with the two 
mechanics:

Whenever I would like to change the version of the slf4j-api within my reactor 
I still would need only change the dependencyManagement element in the parent 
POM. No change from today’s mechanics there.
Whenever I would like to change the actual dependency from slf4j-api to 
something else I would need to change the code in all projects. No change from 
today.
If I use today’s transitive dependency mechanics, I could need to alter the 
actual dependency definition in 1 project within the reactor if I so choose. 
With your suggestion I would have to change the dependency in all 402 projects 
within the reactor instead. I’m suggestion therefore that this is a pretty poor 
idea since all projects require the slf4j-api during runtime anyways, implying 
that the explicit dependency definition in all the projects is completely 
redundant information. Having the version defined within the parent’s 
DependencyManagement and the dependency itself defined within a project I 
depend upon is sufficient, and requires no declaration repetition. 
Your suggestion is a change in current maven mechanics which makes sense only 
for reasons of internal Maven development, but no sense for the *users* of 
Maven. That is why I suggest that your view would be impractical for a sensible 
way forwards.

 Projects with 100, or 200, or 500 projects. If you do not declare your direct 
 dependencies all manner of problems abound.

Not at all. My last project built 402 OSGi compliant JARs without any problem 
using the current (transitive dependency) mechanics.
Going for your suggestion to change the maven mechanics would have caused us 
loads of extra, unnecessary work since any form of refactoring in terms of 
dependencies would have required us not only to change the code but also a 
flush of POMs. The current Maven mechanics for transitive dependencies implies 
we didn’t have to change the slush of POMs and therefore saved us loads of work.

Moreover, I am grateful that each POM defines only the dependencies unique to 
that project - implying I can easily see which dependencies are added in a 
chain of dependent projects within a reactor. This becomes difficult with your 
suggestion, since POMs would be cluttered with the transitive dependency 
definitions of its dependent projects.

 The problem of repeating the version of a particular dependency, which is 
 really the 

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jason van Zyl]

On Apr 13, 2014, at 8:11 AM, Lennart Jörelid lennart.jore...@gmail.com wrote:

 Hello all,
 
 Let’s see if we can focus on the issue at hand here.
 
 12 apr 2014 kl. 16:59 skrev Jason van Zyl ja...@takari.io:
 
 
 On Apr 12, 2014, at 7:24 AM, Lennart Jörelid lennart.jore...@gmail.com 
 wrote:
 
 Oh I know it is the recommended practise, but I believe that particular
 recommendation is flawed since it does not consider the needs of *big*
 systems with reactors containing lots of projects.
 
 This simply is not the case. It is precisely for manageability reasons in 
 large projects that you need to be specific.
 
 You seem to consider transitive dependencies unspecific” or ”unmanageable” - 
 as opposed to the nature of explicit dependency declarations repeated 
 throughout the entire reactor. This is not the case; in declaring a 
 dependency to an API project from an impl project within the same reactor I 
 automatically say ”I will use/import the dependencies from the API I am 
 implementing” … and then adding dependency declarations used only by the 
 local impl project itself. I don’t want to repeat all dependency definitions 
 from the API project *again* within the impl project since it would only add 
 bloat to my impl project dependency definitions.
 

I'm happy to chat in IRC, but in your first sentence you make an assumption 
which isn't true and then carry on to write the rest of the email. Transitive 
dependencies are certainly manageable. I am also not suggesting to change the 
current mechanics with compile scope, and I've never seen any OSGi project 
where it didn't explicitly define its direct requirements so I'm interested 
knowing you you got that working at all. And while this email chain could go on 
for days a 20 minute chat in IRC would be more productive. Just pop into #maven 
on irc.codehaus.org and we can carry on there.

 I believe that all of us agree that it is sensible to define a Parent POM 
 containing a dependencyManagement section to harmonize versions and default 
 scopes of dependencies used throughout the reactor. This implies that all 
 [external] dependencies within POMs in the reactor are defined on the form
 
dependency
groupIdorg.slf4j/groupId
artifactIdslf4j-api/artifactId
/dependency
 
 What you are suggesting is that we should change the current mechanics of 
 Maven within compile scope (but not runtime/test scope since we would 
 actually need the transitive dependencies there, if I understand your 
 suggestion correctly) to force us to repeat all dependency definitions 
 already present within projects I depend upon. I’m saying this is a poor 
 idea, since it will require maven users to repeat the dependency (such as the 
 example above) in all projects within the reactor - even if they depend on 
 other projects in the reactor that already defined it. Your suggestion of 
 ignoring today’s transitive dependencies in compile scope would only make 
 sense if you believe that the majority of people using Maven out there do not 
 understand transitive dependencies at all …. implying we should make them 
 repeat dependency mechanics ”for clarity”. In my view, this is an incorrect 
 assumption.
 
 Let’s compare the tasks required for refactoring a big reactor with the two 
 mechanics:
 
 Whenever I would like to change the version of the slf4j-api within my 
 reactor I still would need only change the dependencyManagement element in 
 the parent POM. No change from today’s mechanics there.
 Whenever I would like to change the actual dependency from slf4j-api to 
 something else I would need to change the code in all projects. No change 
 from today.
 If I use today’s transitive dependency mechanics, I could need to alter the 
 actual dependency definition in 1 project within the reactor if I so choose. 
 With your suggestion I would have to change the dependency in all 402 
 projects within the reactor instead. I’m suggestion therefore that this is a 
 pretty poor idea since all projects require the slf4j-api during runtime 
 anyways, implying that the explicit dependency definition in all the projects 
 is completely redundant information. Having the version defined within the 
 parent’s DependencyManagement and the dependency itself defined within a 
 project I depend upon is sufficient, and requires no declaration repetition. 
 Your suggestion is a change in current maven mechanics which makes sense only 
 for reasons of internal Maven development, but no sense for the *users* of 
 Maven. That is why I suggest that your view would be impractical for a 
 sensible way forwards.
 
 Projects with 100, or 200, or 500 projects. If you do not declare your 
 direct dependencies all manner of problems abound.
 
 Not at all. My last project built 402 OSGi compliant JARs without any problem 
 using the current (transitive dependency) mechanics.
 Going for your suggestion to change the maven mechanics would have caused us 
 loads of 

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Stephen Connolly]

Isn't the point here that compile scope would turn into runtime scope *when
transitive*?

So this is not the same as the current trick of putting
optionaltrue/optional on a dependency.

In general I am in favour if demoting dependencies to runtime when
transitive (we always warned this was the long term plan)... But I think we
do need a scope for dependencies that are an explicit contract, ie they
would *stay* compile scope, if we co that route

On Sunday, 13 April 2014, Jason van Zyl ja...@takari.io wrote:


 On Apr 13, 2014, at 8:11 AM, Lennart Jörelid 
 lennart.jore...@gmail.comjavascript:;
 wrote:

  Hello all,
 
  Let's see if we can focus on the issue at hand here.
 
  12 apr 2014 kl. 16:59 skrev Jason van Zyl ja...@takari.iojavascript:;
 :
 
 
  On Apr 12, 2014, at 7:24 AM, Lennart Jörelid 
  lennart.jore...@gmail.comjavascript:;
 wrote:
 
  Oh I know it is the recommended practise, but I believe that particular
  recommendation is flawed since it does not consider the needs of *big*
  systems with reactors containing lots of projects.
 
  This simply is not the case. It is precisely for manageability reasons
 in large projects that you need to be specific.
 
  You seem to consider transitive dependencies unspecific or
 unmanageable - as opposed to the nature of explicit dependency
 declarations repeated throughout the entire reactor. This is not the case;
 in declaring a dependency to an API project from an impl project within the
 same reactor I automatically say I will use/import the dependencies from
 the API I am implementing ... and then adding dependency declarations used
 only by the local impl project itself. I don't want to repeat all
 dependency definitions from the API project *again* within the impl project
 since it would only add bloat to my impl project dependency definitions.
 

 I'm happy to chat in IRC, but in your first sentence you make an
 assumption which isn't true and then carry on to write the rest of the
 email. Transitive dependencies are certainly manageable. I am also not
 suggesting to change the current mechanics with compile scope, and I've
 never seen any OSGi project where it didn't explicitly define its direct
 requirements so I'm interested knowing you you got that working at all. And
 while this email chain could go on for days a 20 minute chat in IRC would
 be more productive. Just pop into #maven on irc.codehaus.org and we can
 carry on there.

  I believe that all of us agree that it is sensible to define a Parent
 POM containing a dependencyManagement section to harmonize versions and
 default scopes of dependencies used throughout the reactor. This implies
 that all [external] dependencies within POMs in the reactor are defined on
 the form
 
 dependency
 groupIdorg.slf4j/groupId
 artifactIdslf4j-api/artifactId
 /dependency
 
  What you are suggesting is that we should change the current mechanics
 of Maven within compile scope (but not runtime/test scope since we would
 actually need the transitive dependencies there, if I understand your
 suggestion correctly) to force us to repeat all dependency definitions
 already present within projects I depend upon. I'm saying this is a poor
 idea, since it will require maven users to repeat the dependency (such as
 the example above) in all projects within the reactor - even if they depend
 on other projects in the reactor that already defined it. Your suggestion
 of ignoring today's transitive dependencies in compile scope would only
 make sense if you believe that the majority of people using Maven out there
 do not understand transitive dependencies at all  implying we should make
 them repeat dependency mechanics for clarity. In my view, this is an
 incorrect assumption.
 
  Let's compare the tasks required for refactoring a big reactor with the
 two mechanics:
 
  Whenever I would like to change the version of the slf4j-api within my
 reactor I still would need only change the dependencyManagement element in
 the parent POM. No change from today's mechanics there.
  Whenever I would like to change the actual dependency from slf4j-api to
 something else I would need to change the code in all projects. No change
 from today.
  If I use today's transitive dependency mechanics, I could need to alter
 the actual dependency definition in 1 project within the reactor if I so
 choose. With your suggestion I would have to change the dependency in all
 402 projects within the reactor instead. I'm suggestion therefore that this
 is a pretty poor idea since all projects require the slf4j-api during
 runtime anyways, implying that the explicit dependency definition in all
 the projects is completely redundant information. Having the version
 defined within the parent's DependencyManagement and the dependency itself
 defined within a project I depend upon is sufficient, and requires no
 declaration repetition.
  Your suggestion is a change in current maven mechanics which makes 

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Stephen Connolly]

The decision was we couldn't add scopes until the modelVersion gets a
bump... Which is on the cards for maven 4.0.

On Saturday, 12 April 2014, Benson Margulies bimargul...@gmail.com wrote:

 On Fri, Apr 11, 2014 at 5:57 PM, Stephen Connolly
 stephen.alan.conno...@gmail.com javascript:; wrote:
  That's a sign that we need a new scope...

 The person who decided that we couldn't just use an arbitrary custom
 value as a scope (thus breaking the tomcat plugin of the time) might
 want to reconsider that decision.


 
 
  On 11 April 2014 22:50, Benson Margulies 
  bimargul...@gmail.comjavascript:;
 wrote:
 
  On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
  stephen.alan.conno...@gmail.com javascript:; wrote:
   On 11 April 2014 22:10, Benson Margulies 
   bimargul...@gmail.comjavascript:;
 wrote:
  
   
Fwiw, I don't recall the dependency plugin actually injecting stuff
  into
the project class path but equally wish that the copy/unpack goals
  could
simply go away regardless. (in leu of the more normal
 xxx-dependencies
versions)
  
   If you make them go away, please find them a new home. I use them
   constantly to unpack data resources retrieved from a Maven repo. It
   seems odd that they live in a 'dependency' plugin, but it would be a
   disaster if they disappeared.
  
  
   You should be declaring the resources you are unpacking/copying as
   dependencies and then using the copy-dependencies or
 unpack-dependencies
   goal instead of the copy or unpack goal.
 
  I don't want them in the classpath. Even if their filenames end in
 '.jar'.
 
  
  
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@maven.apache.orgjavascript:;
   For additional commands, e-mail: dev-h...@maven.apache.orgjavascript:;
  
  
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:;
  For additional commands, e-mail: dev-h...@maven.apache.orgjavascript:;
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:;
 For additional commands, e-mail: dev-h...@maven.apache.org javascript:;



-- 
Sent from my phone

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Robert Scholte]

Op Fri, 11 Apr 2014 23:50:54 +0200 schreef Benson Margulies  
bimargul...@gmail.com:



On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:

On 11 April 2014 22:10, Benson Margulies bimargul...@gmail.com wrote:



 Fwiw, I don't recall the dependency plugin actually injecting stuff  
into
 the project class path but equally wish that the copy/unpack goals  
could
 simply go away regardless. (in leu of the more normal  
xxx-dependencies

 versions)

If you make them go away, please find them a new home. I use them
constantly to unpack data resources retrieved from a Maven repo. It
seems odd that they live in a 'dependency' plugin, but it would be a
disaster if they disappeared.



You should be declaring the resources you are unpacking/copying as
dependencies and then using the copy-dependencies or unpack-dependencies
goal instead of the copy or unpack goal.


I don't want them in the classpath. Even if their filenames end in  
'.jar'.




The current proposal is to add an artifacts-element[1] to the plugin.
Dependencies are for the classpath, artifacts are additional files which  
must be resolved, but don't belong on the classpath.


Robert

[1]  
https://cwiki.apache.org/confluence/display/MAVEN/Resolution+scenarios+for+plugins









-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Lennart Jörelid]

Oh I know it is the recommended practise, but I believe that particular
recommendation is flawed since it does not consider the needs of *big*
systems with reactors containing lots of projects.
Basically the recommendation is to repeat some information (i.e. dependency
specs) which is already implied/required (by depending on a project where
the information is already provided).

Repeating redundant information is not too much of a hassle when
considering small reactors with few maven projects.
It is hugely annoying already when a reactor consists of around 40 projects
- and such a reactor would equate only a small enterprise project,
particularly if modularization like JBoss Modules, OSGi or Jigsaw is
applied.

I can see the merit in using an immutable classpath for projects, since
Maven core would get simpler and smoother mechanics.
I can also see the need for some plugins to add dependencies to various
classpaths - to facilitate some common operations such as instrumenting
classes or the like.

I just don't want to have to repeat dependencies all over a reactor when
these dependencies are already implied by normal transitive dependency
mechanics - that would imply a huge and completely unneccessary workload.

My recommendation is to provide a core-controlled mechanics to enable
plugins to add dependencies to *their own execution* if we want to make the
classpath immutable otherwise. Overriding the I want to add dependencies
method can easily be detected by analysis tools and computed for reports,
while preserving a simpler logic in the core for dependency resolution.

My recommendation is also to completely ignore the suggestion that we would
have to repeat dependencies which are implied by transitive dependency
mechanics. This would create lots of unnecessary work for bigger projects.


2014-04-11 1:23 GMT+02:00 Barrie Treloar baerr...@gmail.com:

 On 10 April 2014 23:37, Lennart Jörelid lennart.jore...@gmail.com wrote:

  So ... the consequence of your approach would be that POMs throughout a
  maven reactor would have to repeat a dependency declaration if the
 classes
  in your maven project directly import a type. This - to me - seems not
  only complex to resolve in a big reactor, but quite user-unfriendly as
  well. An example shows this, I think:
 

 This is the *recommended* best practice.

 If you use something directly, then you should be explicit about that
 dependency.


 http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.htmlwill
 report failures for you so you can check.




-- 

--
+==+
| Bästa hälsningar,
| [sw. Best regards]
|
| Lennart Jörelid
| EAI Architect  Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: l...@jguru.se
| URL:   www.jguru.se
| Phone
| (skype):jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==+

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Hervé BOUTEMY]

Le vendredi 11 avril 2014 15:10:01 Chris Graham a écrit :
 Sent from my iPhone
 
 On 11/04/2014, at 9:23 AM, Barrie Treloar baerr...@gmail.com wrote:
  On 10 April 2014 23:37, Lennart Jörelid lennart.jore...@gmail.com wrote:
  So ... the consequence of your approach would be that POMs throughout a
  maven reactor would have to repeat a dependency declaration if the
  classes
  in your maven project directly import a type. This - to me - seems not
  only complex to resolve in a big reactor, but quite user-unfriendly as
  
  well. An example shows this, I think:
  This is the *recommended* best practice.
  
  If you use something directly, then you should be explicit about that
  dependency.
 
 If I've followed this thread and fully understood it, the proposal is to
 force the declaration of a dependency in the current Pom, even if they are
 declared as dependencies of your declared dependency, ie transitive
 dependencies.
 
 Does this not effectively disable the use of transitive dependencies?
no, not completely: you still have automatic version calculation, and 
calculated complete transitive dependencies for run
but yes, forcing direct dependencies delclaration gives developer more work: 
we expect this gives developer more precise knowledge of his code

 
 I find transitive dependencies one of the most useful, powerful features of
 Maven.
+1

 
 Without them, it takes me back to the (horrid) Ant days of manually having
 walk the dependency tree.
 
 And what of consolidation/library poms, where one Pom lists 100's of other
 jars needed? The WebSphere Process Server one (172 jars!) comes to mind.
 
 In short, if I've followed and understood this correctly, and I may not have
 (holiday time for me), it sounds a very bad idea Igon.
IMHO, each choice is debatable: this should be an option in compiler plugin. 
Something like disableTransitiveDependencies. Notice that this wouldn't 
require core change

Regards,

Hervé

 
 -Chris
 
  http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.htmlw
  ill report failures for you so you can check.
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Hervé BOUTEMY]

after thinking more at it, it seems the scope for such artifacts is the 
plugin parameter name

so why not resolve artifacts (or collections of artifacts)  when injecting 
parameters?
I'm not sure we really need a need elemen in pom.

Regards,

Hervé

Le samedi 12 avril 2014 10:14:51 Robert Scholte a écrit :
 Op Fri, 11 Apr 2014 23:50:54 +0200 schreef Benson Margulies
 
 bimargul...@gmail.com:
  On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
  
  stephen.alan.conno...@gmail.com wrote:
  On 11 April 2014 22:10, Benson Margulies bimargul...@gmail.com wrote:
   Fwiw, I don't recall the dependency plugin actually injecting stuff
  
  into
  
   the project class path but equally wish that the copy/unpack goals
  
  could
  
   simply go away regardless. (in leu of the more normal
  
  xxx-dependencies
  
   versions)
  
  If you make them go away, please find them a new home. I use them
  constantly to unpack data resources retrieved from a Maven repo. It
  seems odd that they live in a 'dependency' plugin, but it would be a
  disaster if they disappeared.
  
  You should be declaring the resources you are unpacking/copying as
  dependencies and then using the copy-dependencies or unpack-dependencies
  goal instead of the copy or unpack goal.
  
  I don't want them in the classpath. Even if their filenames end in
  '.jar'.
 
 The current proposal is to add an artifacts-element[1] to the plugin.
 Dependencies are for the classpath, artifacts are additional files which
 must be resolved, but don't belong on the classpath.
 
 Robert
 
 [1]
 https://cwiki.apache.org/confluence/display/MAVEN/Resolution+scenarios+for+p
 lugins
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
  
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Mirko Friedenhagen]

What about (ab-)using the runtime scope for this? The core could inspect
the pom and inject runtime dependencies into the class path.

Regards
Mirko
-- 
Sent from my mobile
On Apr 12, 2014 2:08 PM, Hervé BOUTEMY herve.bout...@free.fr wrote:

 after thinking more at it, it seems the scope for such artifacts is the
 plugin parameter name

 so why not resolve artifacts (or collections of artifacts)  when injecting
 parameters?
 I'm not sure we really need a need elemen in pom.

 Regards,

 Hervé

 Le samedi 12 avril 2014 10:14:51 Robert Scholte a écrit :
  Op Fri, 11 Apr 2014 23:50:54 +0200 schreef Benson Margulies
 
  bimargul...@gmail.com:
   On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
  
   stephen.alan.conno...@gmail.com wrote:
   On 11 April 2014 22:10, Benson Margulies bimargul...@gmail.com
 wrote:
Fwiw, I don't recall the dependency plugin actually injecting stuff
  
   into
  
the project class path but equally wish that the copy/unpack goals
  
   could
  
simply go away regardless. (in leu of the more normal
  
   xxx-dependencies
  
versions)
  
   If you make them go away, please find them a new home. I use them
   constantly to unpack data resources retrieved from a Maven repo. It
   seems odd that they live in a 'dependency' plugin, but it would be a
   disaster if they disappeared.
  
   You should be declaring the resources you are unpacking/copying as
   dependencies and then using the copy-dependencies or
 unpack-dependencies
   goal instead of the copy or unpack goal.
  
   I don't want them in the classpath. Even if their filenames end in
   '.jar'.
 
  The current proposal is to add an artifacts-element[1] to the plugin.
  Dependencies are for the classpath, artifacts are additional files which
  must be resolved, but don't belong on the classpath.
 
  Robert
 
  [1]
 
 https://cwiki.apache.org/confluence/display/MAVEN/Resolution+scenarios+for+p
  lugins
   -
   To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
   For additional commands, e-mail: dev-h...@maven.apache.org
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
   For additional commands, e-mail: dev-h...@maven.apache.org
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jason van Zyl]

On Apr 12, 2014, at 7:24 AM, Lennart Jörelid lennart.jore...@gmail.com wrote:

 Oh I know it is the recommended practise, but I believe that particular
 recommendation is flawed since it does not consider the needs of *big*
 systems with reactors containing lots of projects.

This simply is not the case. It is precisely for manageability reasons in large 
projects that you need to be specific. Projects with 100, or 200, or 500 
projects. If you do not declare your direct dependencies all manner of problems 
abound. The problem of repeating the version of a particular dependency, which 
is really the important aspect, is mitigated by dependencyManagement but a 
project should always declare its dependencies. We do not enforce this right 
now and if you want to rely on a transitive dependency without the use of 
dependencyManagement then you are subject to a version of dependency that the 
conflict resolver hands over. You're not going to convince anyone here that's a 
good idea. The heuristics and data don't exist, yet, to have the system make 
the correct choice or at least help you make a correct choice as there are many 
possible correct choices. In practice you know your points of integration where 
you mesh conflict in your dependencies until many parts are integrated into a 
final runtime where you simply have to manage what goes into it, there's no 
real way around that. Being explicit all the way along makes analysis, 
integration and final provisioning manageable.

 Basically the recommendation is to repeat some information (i.e. dependency
 specs) which is already implied/required (by depending on a project where
 the information is already provided).
 

We are not. One project cannot imply the requirements of another.

 Repeating redundant information is not too much of a hassle when
 considering small reactors with few maven projects.
 It is hugely annoying already when a reactor consists of around 40 projects
 - and such a reactor would equate only a small enterprise project,
 particularly if modularization like JBoss Modules, OSGi or Jigsaw is
 applied.
 

In practice for many years I have not found this to be the case with large 
Maven projects. Not specifying your requirements, in any situation really, 
leads to problems.

 I can see the merit in using an immutable classpath for projects, since
 Maven core would get simpler and smoother mechanics.
 I can also see the need for some plugins to add dependencies to various
 classpaths - to facilitate some common operations such as instrumenting
 classes or the like.
 

Or find tools which are better that don't require that. In the case of code 
coverage I've used Jacoco for years, it is a simple agent model and does 
everything else required itself without the need for other mucking with the 
classes. Well, it does have a offline instrumentation mode but I don't 
recommend using that method and neither do the Jacoco folks. So in light of 
modern techniques this classpath monkey patching or static instrumentation is 
not required anymore.

 I just don't want to have to repeat dependencies all over a reactor when
 these dependencies are already implied by normal transitive dependency
 mechanics - that would imply a huge and completely unneccessary workload.
 
 My recommendation is to provide a core-controlled mechanics to enable
 plugins to add dependencies to *their own execution*

We do. The standard mechanism for a plugin to declare its dependencies if it 
requires something to run. Furthermore a plugin declaration by a user can 
provider additional dependencies if the plugin itself has extension points that 
a user can provide. Or if the plugin author has provided options where you need 
to have one thing on the classpath vs another then the user is instructed to 
add set A of dependencies to the plugin declaration vs set B. Instead of 
providing a configuration which the plugin acts upon internally to go fetch 
dependencies and modify the execution classpath. What we have is declarative 
and I believe is sufficient for all reasonable requirements.

 if we want to make the
 classpath immutable otherwise. Overriding the I want to add dependencies
 method can easily be detected by analysis tools and computed for reports,
 while preserving a simpler logic in the core for dependency resolution.
 
 My recommendation is also to completely ignore the suggestion that we would
 have to repeat dependencies which are implied by transitive dependency
 mechanics. This would create lots of unnecessary work for bigger projects.
 

Like I said above you can do that if you want, but it's not manageable at all. 
We may one day enforce that you declare all direct requirements but nothing 
stops you in Maven 3.x from putting a blindfold on and throwing the darts at 
the version selection board.

 
 2014-04-11 1:23 GMT+02:00 Barrie Treloar baerr...@gmail.com:
 
 On 10 April 2014 23:37, Lennart Jörelid lennart.jore...@gmail.com wrote:
 
 So ... the consequence of 

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jason van Zyl]

On Apr 12, 2014, at 8:02 AM, Hervé BOUTEMY herve.bout...@free.fr wrote:

 
 In short, if I've followed and understood this correctly, and I may not have
 (holiday time for me), it sounds a very bad idea Igon.
 IMHO, each choice is debatable: this should be an option in compiler plugin. 
 Something like disableTransitiveDependencies. Notice that this wouldn't 
 require core change
 

Only requires the use of access rules in the compiler which JDT supports and 
you can implement them with the modern Javac compiler. 

 Regards,
 
 Hervé
 
 
 -Chris
 
 http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.htmlw
 ill report failures for you so you can check.
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

There's no sense in being precise when you don't even know what you're talking 
about.

 -- John von Neumann

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jason van Zyl]

I think allowing plugins to resolve things with annotations is not a good idea 
as we already have project dependencies resolution that happens on the fly per 
project. This means it's impossible to fully reason about the requirements of a 
project being built up front. This, in practice, leads to users building, 
getting a resolution error, building, getting a resolution error. While not 
problems can be determined from up-front analysis most of them can. I am more 
in favor of going the other direction where we have something purely 
declarative, all dependencies for the project and plugins can be reasoned about 
up-front and reported to the user for correction.

Ultimately I would like to get rid of on-the-fly resolution and replace it with 
a stage in Maven's execution that occurs before the build starts.

On Apr 12, 2014, at 8:07 AM, Hervé BOUTEMY herve.bout...@free.fr wrote:

 after thinking more at it, it seems the scope for such artifacts is the 
 plugin parameter name
 
 so why not resolve artifacts (or collections of artifacts)  when injecting 
 parameters?
 I'm not sure we really need a need elemen in pom.
 
 Regards,
 
 Hervé
 
 Le samedi 12 avril 2014 10:14:51 Robert Scholte a écrit :
 Op Fri, 11 Apr 2014 23:50:54 +0200 schreef Benson Margulies
 
 bimargul...@gmail.com:
 On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
 
 stephen.alan.conno...@gmail.com wrote:
 On 11 April 2014 22:10, Benson Margulies bimargul...@gmail.com wrote:
 Fwiw, I don't recall the dependency plugin actually injecting stuff
 
 into
 
 the project class path but equally wish that the copy/unpack goals
 
 could
 
 simply go away regardless. (in leu of the more normal
 
 xxx-dependencies
 
 versions)
 
 If you make them go away, please find them a new home. I use them
 constantly to unpack data resources retrieved from a Maven repo. It
 seems odd that they live in a 'dependency' plugin, but it would be a
 disaster if they disappeared.
 
 You should be declaring the resources you are unpacking/copying as
 dependencies and then using the copy-dependencies or unpack-dependencies
 goal instead of the copy or unpack goal.
 
 I don't want them in the classpath. Even if their filenames end in
 '.jar'.
 
 The current proposal is to add an artifacts-element[1] to the plugin.
 Dependencies are for the classpath, artifacts are additional files which
 must be resolved, but don't belong on the classpath.
 
 Robert
 
 [1]
 https://cwiki.apache.org/confluence/display/MAVEN/Resolution+scenarios+for+p
 lugins
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

Three people can keep a secret provided two of them are dead.

 -- Benjamin Franklin

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Brian Fox]

 My proposal is strictly to prohibit a plugin from modifying a project's
 classpath implicitly. That this become fully explicit such that I can
 remove some of the convoluted logic in the core to account for this.


Not allowing plugins to randomly inject new dependencies makes sense. I see
some cases where you still want to add a new dependency to the plugin class
path, but from above that sounds unrelated to what you are proposing
changing?

Fwiw, I don't recall the dependency plugin actually injecting stuff into
the project class path but equally wish that the copy/unpack goals could
simply go away regardless. (in leu of the more normal xxx-dependencies
versions)

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Robert Scholte]

Op Fri, 11 Apr 2014 22:57:01 +0200 schreef Brian Fox bri...@infinity.nu:


My proposal is strictly to prohibit a plugin from modifying a project's
classpath implicitly. That this become fully explicit such that I can
remove some of the convoluted logic in the core to account for this.


Not allowing plugins to randomly inject new dependencies makes sense. I  
see
some cases where you still want to add a new dependency to the plugin  
class

path, but from above that sounds unrelated to what you are proposing
changing?

Fwiw, I don't recall the dependency plugin actually injecting stuff into
the project class path but equally wish that the copy/unpack goals could
simply go away regardless. (in leu of the more normal xxx-dependencies
versions)


The dependency:get is the most tricky goal here, since it's probably a  
pomless execution and you specify the GAV and additional properties. When  
we don't allow the plugin to do this kind of resolution, it's probably  
something which needs to be moved to Maven Core.


Robert

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Benson Margulies]

 Fwiw, I don't recall the dependency plugin actually injecting stuff into
 the project class path but equally wish that the copy/unpack goals could
 simply go away regardless. (in leu of the more normal xxx-dependencies
 versions)

If you make them go away, please find them a new home. I use them
constantly to unpack data resources retrieved from a Maven repo. It
seems odd that they live in a 'dependency' plugin, but it would be a
disaster if they disappeared.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Stephen Connolly]

On 11 April 2014 22:10, Benson Margulies bimargul...@gmail.com wrote:

 
  Fwiw, I don't recall the dependency plugin actually injecting stuff into
  the project class path but equally wish that the copy/unpack goals could
  simply go away regardless. (in leu of the more normal xxx-dependencies
  versions)

 If you make them go away, please find them a new home. I use them
 constantly to unpack data resources retrieved from a Maven repo. It
 seems odd that they live in a 'dependency' plugin, but it would be a
 disaster if they disappeared.


You should be declaring the resources you are unpacking/copying as
dependencies and then using the copy-dependencies or unpack-dependencies
goal instead of the copy or unpack goal.



 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Benson Margulies]

On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 On 11 April 2014 22:10, Benson Margulies bimargul...@gmail.com wrote:

 
  Fwiw, I don't recall the dependency plugin actually injecting stuff into
  the project class path but equally wish that the copy/unpack goals could
  simply go away regardless. (in leu of the more normal xxx-dependencies
  versions)

 If you make them go away, please find them a new home. I use them
 constantly to unpack data resources retrieved from a Maven repo. It
 seems odd that they live in a 'dependency' plugin, but it would be a
 disaster if they disappeared.


 You should be declaring the resources you are unpacking/copying as
 dependencies and then using the copy-dependencies or unpack-dependencies
 goal instead of the copy or unpack goal.

I don't want them in the classpath. Even if their filenames end in '.jar'.




 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Stephen Connolly]

That's a sign that we need a new scope...


On 11 April 2014 22:50, Benson Margulies bimargul...@gmail.com wrote:

 On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
 stephen.alan.conno...@gmail.com wrote:
  On 11 April 2014 22:10, Benson Margulies bimargul...@gmail.com wrote:
 
  
   Fwiw, I don't recall the dependency plugin actually injecting stuff
 into
   the project class path but equally wish that the copy/unpack goals
 could
   simply go away regardless. (in leu of the more normal xxx-dependencies
   versions)
 
  If you make them go away, please find them a new home. I use them
  constantly to unpack data resources retrieved from a Maven repo. It
  seems odd that they live in a 'dependency' plugin, but it would be a
  disaster if they disappeared.
 
 
  You should be declaring the resources you are unpacking/copying as
  dependencies and then using the copy-dependencies or unpack-dependencies
  goal instead of the copy or unpack goal.

 I don't want them in the classpath. Even if their filenames end in '.jar'.

 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Benson Margulies]

On Fri, Apr 11, 2014 at 5:57 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 That's a sign that we need a new scope...

The person who decided that we couldn't just use an arbitrary custom
value as a scope (thus breaking the tomcat plugin of the time) might
want to reconsider that decision.




 On 11 April 2014 22:50, Benson Margulies bimargul...@gmail.com wrote:

 On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
 stephen.alan.conno...@gmail.com wrote:
  On 11 April 2014 22:10, Benson Margulies bimargul...@gmail.com wrote:
 
  
   Fwiw, I don't recall the dependency plugin actually injecting stuff
 into
   the project class path but equally wish that the copy/unpack goals
 could
   simply go away regardless. (in leu of the more normal xxx-dependencies
   versions)
 
  If you make them go away, please find them a new home. I use them
  constantly to unpack data resources retrieved from a Maven repo. It
  seems odd that they live in a 'dependency' plugin, but it would be a
  disaster if they disappeared.
 
 
  You should be declaring the resources you are unpacking/copying as
  dependencies and then using the copy-dependencies or unpack-dependencies
  goal instead of the copy or unpack goal.

 I don't want them in the classpath. Even if their filenames end in '.jar'.

 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Brian Fox]

On Fri, Apr 11, 2014 at 5:50 PM, Benson Margulies bimargul...@gmail.comwrote:

 On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
 stephen.alan.conno...@gmail.com wrote:
  On 11 April 2014 22:10, Benson Margulies bimargul...@gmail.com wrote:
 
  
   Fwiw, I don't recall the dependency plugin actually injecting stuff
 into
   the project class path but equally wish that the copy/unpack goals
 could
   simply go away regardless. (in leu of the more normal xxx-dependencies
   versions)
 
  If you make them go away, please find them a new home. I use them
  constantly to unpack data resources retrieved from a Maven repo. It
  seems odd that they live in a 'dependency' plugin, but it would be a
  disaster if they disappeared.
 
 
  You should be declaring the resources you are unpacking/copying as
  dependencies and then using the copy-dependencies or unpack-dependencies
  goal instead of the copy or unpack goal.

 I don't want them in the classpath. Even if their filenames end in '.jar'.


Well, that is the use case I had when I created them originally. I just see
too many people abuse these when they simply could have used the
-dependencies versions just as effectively and with better compatibility to
other plugins.

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jason van Zyl]

I realize folks are busy, I'll just run with this given I think we all agree 
immutable classpaths are better and fiddly magic in the core is bad. I'm going 
to remove the capability to dynamically fiddle with the project classpath and 
the IT for MNG-4363 will be omitted from the run for Maven 4.0.0.

On Apr 6, 2014, at 9:55 AM, Jason van Zyl ja...@takari.io wrote:

 Hi,
 
 I started making of list of things I'd like to remove in Maven 4.0.0, but I 
 would like to start getting some agreement on what we can yank and this is 
 the first concrete request. I would like to remove the ability for plugins to 
 magically inject dependencies. Plugins can either declare their dependencies 
 or instruct users to add dependencies to the plugins in their POMs. This 
 weird logic for plugins to add dependencies dynamically is the cause of some 
 extremely convoluted logic in the resolution code and I want to remove it.
 
 The original issue is here: http://jira.codehaus.org/browse/MNG-4363
 
 I encountered this when trying to hoist all the resolution logic into once 
 place so that from our Aether provider resolution as it is done in the core 
 can be done everywhere. Right now we have plugins like the assembly plugin, 
 WAR plugin, dependency plugin that all do their own weird, inconsistent thing 
 and when I tried to put it all in one place so that it can be analyzed, 
 optimized and then executed this issue cropped up. We never should have 
 allowed this in the first place but carried it over from 2.x for 
 compatibilities sake. This might affect the code coverage tools but we can 
 find a cleaner way. This logic is totally bizarro and needs to go.
 
 If everyone agrees we can start systematically documenting what has been 
 removed, as we have lost track of this accurately in the past. I'd like to 
 make a 4.x branch in 4 weeks or so and this will be one of the first things 
 I'd like to cut. It will be one of those radical simplifications that will 
 start allowing people to get a better understanding of the core as I can put 
 the resolution logic in one place as it is currently in many.
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 http://twitter.com/takari_io
 -
 
 We all have problems. How we deal with them is a measure of our worth.
 
 -- Unknown
 
 
 
 
 
 
 
 
 

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

-- Thoreau 

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Lennart Jörelid]

So ... the consequence of your approach would be that POMs throughout a
maven reactor would have to repeat a dependency declaration if the classes
in your maven project directly import a type. This - to me - seems not
only complex to resolve in a big reactor, but quite user-unfriendly as
well. An example shows this, I think:

You have an API Maven project where you create class AbstractSuperType as
follows which declares a dependency to an artifact (exemplified by the
Logger/LoggerFactory/Membership classes):

public abstract AbstractSuperType {
   protected static final Logger log =
LoggerFactory.getLogger(Membership.class);

   protected AbstractSuperType(String something) {
   }

   
}

You then create an Impl project where you define a class ConcreteType as
follows:

public ConcreteType extends AbstractSuperType {

   public ConcreteType() { super(some text); }

   private void someUtilityMethod() { log.debug(... ); }
}

As the ConcreteType extends AbstractSuperType, which uses the
Logger/LoggerFactory/Membership classes, Maven will be required to
synthesize a classpath including the dependencies for all three of these
classes in order to run the unit tests - we both agree on that. If I
understand you correctly, you suggest that Maven's mechanics to synthesize
the test scope classpath should include all required transitive
dependencies (in effect runtime dependencies for jUnit) - but that Maven's
mechanics to synthesize the compile scope class path should not. This
implies that Maven users must understand that Maven uses two different ways
to construct its classpath in compile and test scopes. Also, the user must
understand that the compilation fails if the someUtilityMethod is added to
the ConcreteType - because you would now be required to add a dependency to
the Impl project as well.

I find it more usable to simply use the same mechanics to synthesize class
path in compile and test scopes, implying  that transitive dependencies are
included in the respective class path without any extra pom dependencies
being added to parent and child projects.



2014-04-08 2:21 GMT+02:00 Mark Derricutt m...@talios.com:

 On 7 Apr 2014, at 19:37, Lennart Jörelid wrote:

  I don't understand the difference between what you suggest here, Mark, and
 simply disabling transitive dependencies.
 Could you elaborate somewhat?


 Well, the basics are:

 * When compiling code, all I need to do is satisfy the contracts my
 dependencies interfaces/public signatures. If my code fails to compile due
 to some absent dependency ( note, this is different from a non-resolvable,
 declared dependency ), then I should go an add a `dependency/` element to
 my pom.
 * When running tests however, you require the transitive dependencies on
 the classpath so the upstream code _actually works_.
 * When packaging for distribution, you require the transitives for a
 running solution.





-- 

--
+==+
| Bästa hälsningar,
| [sw. Best regards]
|
| Lennart Jörelid
| EAI Architect  Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: l...@jguru.se
| URL:   www.jguru.se
| Phone
| (skype):jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==+

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Barrie Treloar]

On 10 April 2014 23:37, Lennart Jörelid lennart.jore...@gmail.com wrote:

 So ... the consequence of your approach would be that POMs throughout a
 maven reactor would have to repeat a dependency declaration if the classes
 in your maven project directly import a type. This - to me - seems not
 only complex to resolve in a big reactor, but quite user-unfriendly as
 well. An example shows this, I think:


This is the *recommended* best practice.

If you use something directly, then you should be explicit about that
dependency.

http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.htmlwill
report failures for you so you can check.

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jason van Zyl]

On Apr 10, 2014, at 10:07 AM, Lennart Jörelid lennart.jore...@gmail.com wrote:

 So ... the consequence of your approach would be that POMs throughout a
 maven reactor would have to repeat a dependency declaration if the classes
 in your maven project directly import a type. This - to me - seems not
 only complex to resolve in a big reactor, but quite user-unfriendly as
 well. An example shows this, I think:

It is not as, it can very hard to debug what version of a dependency you are 
using which will be pull in transitively in the case there are conflicting 
versions. We always recommend users declare their direct compile time 
dependencies, we also recommend users declare their direct test compile time 
dependencies. While I may not be a complete fan of OSGi, I share their 
promotion of being as explicit as possible about what you directly require. The 
resolving mechanism can be deterministic once the requirements of a particular 
project is known. It's far friendlier to be able to reason about your 
dependencies correctly. If you don't state them all sorts of other problems 
arise.

 
 You have an API Maven project where you create class AbstractSuperType as
 follows which declares a dependency to an artifact (exemplified by the
 Logger/LoggerFactory/Membership classes):
 
 public abstract AbstractSuperType {
   protected static final Logger log =
 LoggerFactory.getLogger(Membership.class);
 
   protected AbstractSuperType(String something) {
   }
 
   
 }
 
 You then create an Impl project where you define a class ConcreteType as
 follows:
 
 public ConcreteType extends AbstractSuperType {
 
   public ConcreteType() { super(some text); }
 
   private void someUtilityMethod() { log.debug(... ); }
 }
 
 As the ConcreteType extends AbstractSuperType, which uses the
 Logger/LoggerFactory/Membership classes, Maven will be required to
 synthesize a classpath including the dependencies for all three of these
 classes in order to run the unit tests - we both agree on that. If I
 understand you correctly, you suggest that Maven's mechanics to synthesize
 the test scope classpath should include all required transitive
 dependencies (in effect runtime dependencies for jUnit) - but that Maven's
 mechanics to synthesize the compile scope class path should not. This
 implies that Maven users must understand that Maven uses two different ways
 to construct its classpath in compile and test scopes. Also, the user must
 understand that the compilation fails if the someUtilityMethod is added to
 the ConcreteType - because you would now be required to add a dependency to
 the Impl project as well.
 
 I find it more usable to simply use the same mechanics to synthesize class
 path in compile and test scopes, implying  that transitive dependencies are
 included in the respective class path without any extra pom dependencies
 being added to parent and child projects.

I'm not recommending classpaths used different mechanisms, I'm not sure where 
in the thread you inferred otherwise. The issue I started this thread with is a 
very specific issue that applies to handful of plugins in the Maven ecosystem 
that non-declaratively and programmatically push dependencies into a project.

 
 
 
 2014-04-08 2:21 GMT+02:00 Mark Derricutt m...@talios.com:
 
 On 7 Apr 2014, at 19:37, Lennart Jörelid wrote:
 
 I don't understand the difference between what you suggest here, Mark, and
 simply disabling transitive dependencies.
 Could you elaborate somewhat?
 
 
 Well, the basics are:
 
 * When compiling code, all I need to do is satisfy the contracts my
 dependencies interfaces/public signatures. If my code fails to compile due
 to some absent dependency ( note, this is different from a non-resolvable,
 declared dependency ), then I should go an add a `dependency/` element to
 my pom.
 * When running tests however, you require the transitive dependencies on
 the classpath so the upstream code _actually works_.
 * When packaging for distribution, you require the transitives for a
 running solution.
 
 
 
 
 
 -- 
 
 --
 +==+
 | Bästa hälsningar,
 | [sw. Best regards]
 |
 | Lennart Jörelid
 | EAI Architect  Integrator
 |
 | jGuru Europe AB
 | Mölnlycke - Kista
 |
 | Email: l...@jguru.se
 | URL:   www.jguru.se
 | Phone
 | (skype):jgurueurope
 | (intl): +46 708 507 603
 | (domestic): 0708 - 507 603
 +==+

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

I never make the mistake of arguing with people for whose opinions I have no 
respect.

-- Edward Gibbon

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Chris Graham]

Sent from my iPhone

On 11/04/2014, at 9:23 AM, Barrie Treloar baerr...@gmail.com wrote:

 On 10 April 2014 23:37, Lennart Jörelid lennart.jore...@gmail.com wrote:
 
 So ... the consequence of your approach would be that POMs throughout a
 maven reactor would have to repeat a dependency declaration if the classes
 in your maven project directly import a type. This - to me - seems not
 only complex to resolve in a big reactor, but quite user-unfriendly as
 well. An example shows this, I think:
 
 
 This is the *recommended* best practice.
 
 If you use something directly, then you should be explicit about that
 dependency.

If I've followed this thread and fully understood it, the proposal is to force 
the declaration of a dependency in the current Pom, even if they are declared 
as dependencies of your declared dependency, ie transitive dependencies.

Does this not effectively disable the use of transitive dependencies?

I find transitive dependencies one of the most useful, powerful features of 
Maven. 

Without them, it takes me back to the (horrid) Ant days of manually having walk 
the dependency tree.

And what of consolidation/library poms, where one Pom lists 100's of other jars 
needed? The WebSphere Process Server one (172 jars!) comes to mind.

In short, if I've followed and understood this correctly, and I may not have 
(holiday time for me), it sounds a very bad idea Igon.

-Chris

 
 http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.htmlwill
 report failures for you so you can check.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Barrie Treloar]

On 11 April 2014 14:40, Chris Graham chrisgw...@gmail.com wrote:



 Sent from my iPhone

 On 11/04/2014, at 9:23 AM, Barrie Treloar baerr...@gmail.com wrote:

  On 10 April 2014 23:37, Lennart Jörelid lennart.jore...@gmail.com
 wrote:
 
  So ... the consequence of your approach would be that POMs throughout a
  maven reactor would have to repeat a dependency declaration if the
 classes
  in your maven project directly import a type. This - to me - seems not
  only complex to resolve in a big reactor, but quite user-unfriendly as
  well. An example shows this, I think:
 
 
  This is the *recommended* best practice.
 
  If you use something directly, then you should be explicit about that
  dependency.

 If I've followed this thread and fully understood it, the proposal is to
 force the declaration of a dependency in the current Pom, even if they are
 declared as dependencies of your declared dependency, ie transitive
 dependencies.


This thread is about making the classpath immutable to plugins.
As per Jason's original email if a plugin wants to change the classpath
they should declare it in the plugin pom, or document that users should
declare it in their pom.



 Does this not effectively disable the use of transitive dependencies?


Additionally this thread had stuff included around Mark Derricutt's email
that suggested Maven change its behaviour so that compile time dependencies
are not transitive.
Which is what the recommended best practice is to do anyway.

Runtime would still be transitive.


 I find transitive dependencies one of the most useful, powerful features
 of Maven.

 Without them, it takes me back to the (horrid) Ant days of manually having
 walk the dependency tree.

 And what of consolidation/library poms, where one Pom lists 100's of other
 jars needed? The WebSphere Process Server one (172 jars!) comes to mind.


Consolidation or library poms would mostly contain runtime dependencies and
not be a problem.

For compile time dependencies the two ways to do this are via inheritance
or includes.
Inheritance (i.e. parent poms) works because the dependency management
defines what versions to use, and in the child you select what you actually
want.
If there are too many things to define in the child then maybe the include
way would be better.
I can't remember whether include is vaporware though...

http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-best-practice.htmlsays
There's a certain point defined more by style and experience where you
decide that minimal duplication of configuration is a small price to pay
for allowing projects [...] to remain completely independent. Designing a
huge set of thirty plus projects which all inherit five levels of POM
configuration isn't always the best idea.

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jörg Schaible]

Hi Mark,

Mark Derricutt wrote:

 On 7 Apr 2014, at 12:32, Benson Margulies wrote:
 
 We then have other logical classpaths. . Something like javadoc should
 be able to define another named classpath structure; combining the
 dependencies of the plugin's implementation with dynamic code
 (doclets, whatever) seems like a category confusion to me.
 
 If we change/break this - can we PLEASE make the compilation path IGNORE
 transitive dependencies of 'compile' dependencies - if I -need- it to
 compile, -I- should depend on it up front.

I made the same request more than 7 years ago 
(https://jira.codehaus.org/browse/MNG-2589). However, you can already force 
such a mode with some own effort using a common POM with a depMgmt section 
declaring anything with runtime scope. Unfortunately such a mode reveals 
some nasty effects of the Java model and we finally gave in. See my comment 
in MNG-2589 of last year.

- Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jörg Schaible]

Hi Jason,

Jason van Zyl wrote:

 Hi,
 
 I started making of list of things I'd like to remove in Maven 4.0.0, but
 I would like to start getting some agreement on what we can yank and this
 is the first concrete request. I would like to remove the ability for
 plugins to magically inject dependencies. Plugins can either declare their
 dependencies or instruct users to add dependencies to the plugins in their
 POMs. This weird logic for plugins to add dependencies dynamically is the
 cause of some extremely convoluted logic in the resolution code and I want
 to remove it.
 
 The original issue is here: http://jira.codehaus.org/browse/MNG-4363
 
 I encountered this when trying to hoist all the resolution logic into once
 place so that from our Aether provider resolution as it is done in the
 core can be done everywhere. Right now we have plugins like the assembly
 plugin, WAR plugin, dependency plugin that all do their own weird,
 inconsistent thing and when I tried to put it all in one place so that it
 can be analyzed, optimized and then executed this issue cropped up. We
 never should have allowed this in the first place but carried it over from
 2.x for compatibilities sake. This might affect the code coverage tools
 but we can find a cleaner way. This logic is totally bizarro and needs to
 go.
 
 If everyone agrees we can start systematically documenting what has been
 removed, as we have lost track of this accurately in the past. I'd like to
 make a 4.x branch in 4 weeks or so and this will be one of the first
 things I'd like to cut. It will be one of those radical simplifications
 that will start allowing people to get a better understanding of the core
 as I can put the resolution logic in one place as it is currently in many.

Do you only mean injecting new dependencies into the classpath or injecting 
new ones into the reactor that will have to be considered for dependency 
resolution? MNG-4363 talks of the former, your proposal seems to include the 
latter.

How do you then intent to resolve dynamically dependencies with different 
classifiers?

The dependency plugin does this explicitly for its sources and javadoc goals 
(resolving artifacts with corresponding classifier). The site plugin does it 
implicitly with an artifact having a site classifier. And we have 
developed an own plugin doing the same to aggregate documentation from the 
dependencies.

It does not make sense for these cases to declare those artifacts with a 
(different) classifier. What about this scenario?

- Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Lennart Jörelid]

I don't understand the difference between what you suggest here, Mark, and
simply disabling transitive dependencies.
Could you elaborate somewhat?


2014-04-07 3:41 GMT+02:00 Mark Derricutt m...@talios.com:

 On 7 Apr 2014, at 12:32, Benson Margulies wrote:

  We then have other logical classpaths. . Something like javadoc should
 be able to define another named classpath structure; combining the
 dependencies of the plugin's implementation with dynamic code
 (doclets, whatever) seems like a category confusion to me.


 If we change/break this - can we PLEASE make the compilation path IGNORE
 transitive dependencies of 'compile' dependencies - if I -need- it to
 compile, -I- should depend on it up front.


 Mark

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




-- 

--
+==+
| Bästa hälsningar,
| [sw. Best regards]
|
| Lennart Jörelid
| EAI Architect  Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: l...@jguru.se
| URL:   www.jguru.se
| Phone
| (skype):jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==+

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Anders Hammar]

I believe he's talking about what's mentioned here (see the asterix):
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope

/Anders


On Mon, Apr 7, 2014 at 9:37 AM, Lennart Jörelid
lennart.jore...@gmail.comwrote:

 I don't understand the difference between what you suggest here, Mark, and
 simply disabling transitive dependencies.
 Could you elaborate somewhat?


 2014-04-07 3:41 GMT+02:00 Mark Derricutt m...@talios.com:

  On 7 Apr 2014, at 12:32, Benson Margulies wrote:
 
   We then have other logical classpaths. . Something like javadoc should
  be able to define another named classpath structure; combining the
  dependencies of the plugin's implementation with dynamic code
  (doclets, whatever) seems like a category confusion to me.
 
 
  If we change/break this - can we PLEASE make the compilation path IGNORE
  transitive dependencies of 'compile' dependencies - if I -need- it to
  compile, -I- should depend on it up front.
 
 
  Mark
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 


 --

 --
 +==+
 | Bästa hälsningar,
 | [sw. Best regards]
 |
 | Lennart Jörelid
 | EAI Architect  Integrator
 |
 | jGuru Europe AB
 | Mölnlycke - Kista
 |
 | Email: l...@jguru.se
 | URL:   www.jguru.se
 | Phone
 | (skype):jgurueurope
 | (intl): +46 708 507 603
 | (domestic): 0708 - 507 603
 +==+

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[William Ferguson]

Just wanted to through 2c in.

Jason, you mentioned supporting other uses cases such an Android builds. I
thought I'd explain what's required from that perspective.

The Android team have defined an Android archive (AAR) that holds a JAR and
various Android resources. When the AAR is declared as a dependency the JAR
needs to be added to the classpath during compilation and the Android
resources need to be processed at various phases. At the moment the
classpath needs to be modified dynamically via a LifecycleParticipant during
*afterProjectsRead*, but this has problems in certain multi-module builds.

I'd love to see a way in which the definition of the AAR dependency results
in a declarative addition of the embedded JAR to the classpath.

For mine, if a few things need to break in 4.0 to get a cleaner underlying
structure that provides more long term flexibility and stability then so be
it.

William


On Mon, Apr 7, 2014 at 5:42 PM, Anders Hammar and...@hammar.net wrote:

 I believe he's talking about what's mentioned here (see the asterix):

 http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope

 /Anders


 On Mon, Apr 7, 2014 at 9:37 AM, Lennart Jörelid
 lennart.jore...@gmail.comwrote:

  I don't understand the difference between what you suggest here, Mark,
 and
  simply disabling transitive dependencies.
  Could you elaborate somewhat?
 
 
  2014-04-07 3:41 GMT+02:00 Mark Derricutt m...@talios.com:
 
   On 7 Apr 2014, at 12:32, Benson Margulies wrote:
  
We then have other logical classpaths. . Something like javadoc should
   be able to define another named classpath structure; combining the
   dependencies of the plugin's implementation with dynamic code
   (doclets, whatever) seems like a category confusion to me.
  
  
   If we change/break this - can we PLEASE make the compilation path
 IGNORE
   transitive dependencies of 'compile' dependencies - if I -need- it to
   compile, -I- should depend on it up front.
  
  
   Mark
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
   For additional commands, e-mail: dev-h...@maven.apache.org
  
  
 
 
  --
 
  --
  +==+
  | Bästa hälsningar,
  | [sw. Best regards]
  |
  | Lennart Jörelid
  | EAI Architect  Integrator
  |
  | jGuru Europe AB
  | Mölnlycke - Kista
  |
  | Email: l...@jguru.se
  | URL:   www.jguru.se
  | Phone
  | (skype):jgurueurope
  | (intl): +46 708 507 603
  | (domestic): 0708 - 507 603
  +==+
 

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Lennart Jörelid]

Yes, I realize what Mark was referring to - but I still cannot see the
point in having to repeat oneself WRT importing an already imported
compile-scope dependency in all projects where it would be used. This would
imply loads of redundant imports in all dependent poms in a multi-module
reactor along the lines of:

dependency
groupIda.project.a.domain/groupId
artifactIdmydomain-model/artifactId
/dependency

I would claim the contrary position to Mark's - I would not want to litter
all poms in the reactor with the dependency above just because it is
imported in a project onto which several/most/all other projects in the
reactor depends. This approach violates the DontRepeatYourself principle
quite a lot. Moreover, since the dependency *is* required to get the
dependent projects to run properly I can see quite a few reasons why it
would break existing builds. Simply passing a type from the mydomain-model
as an argument to a method in a publicly available interface implies that
the mydomain-model project is required transitively.

Moreover - I find the dependency mechanism broken in the other direction
compared to Mark's view; presently we have to repeat all provided-scope
depedencies in the reactor since they are not transitively spread as
dependencies to importing projects. Loads of unnecessary POM repetition
follows, which is less than ideal since the POM can get quite bloated as
is. I would rather suggest that we need new transitive scope semantics for
provided-scope dependencies to prevent us from unnecessarily repeating
these several times in a multimodule reactor.

Thus ... I'm asking because I assume that Mark sees something I have missed
in the pom transitivity mechanism, and I want to know what that might be.


2014-04-07 9:42 GMT+02:00 Anders Hammar and...@hammar.net:

 I believe he's talking about what's mentioned here (see the asterix):

 http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope

 /Anders


 On Mon, Apr 7, 2014 at 9:37 AM, Lennart Jörelid
 lennart.jore...@gmail.comwrote:

  I don't understand the difference between what you suggest here, Mark,
 and
  simply disabling transitive dependencies.
  Could you elaborate somewhat?
 
 
  2014-04-07 3:41 GMT+02:00 Mark Derricutt m...@talios.com:
 
   On 7 Apr 2014, at 12:32, Benson Margulies wrote:
  
We then have other logical classpaths. . Something like javadoc should
   be able to define another named classpath structure; combining the
   dependencies of the plugin's implementation with dynamic code
   (doclets, whatever) seems like a category confusion to me.
  
  
   If we change/break this - can we PLEASE make the compilation path
 IGNORE
   transitive dependencies of 'compile' dependencies - if I -need- it to
   compile, -I- should depend on it up front.
  
  
   Mark
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
   For additional commands, e-mail: dev-h...@maven.apache.org
  
  
 
 
  --
 
  --
  +==+
  | Bästa hälsningar,
  | [sw. Best regards]
  |
  | Lennart Jörelid
  | EAI Architect  Integrator
  |
  | jGuru Europe AB
  | Mölnlycke - Kista
  |
  | Email: l...@jguru.se
  | URL:   www.jguru.se
  | Phone
  | (skype):jgurueurope
  | (intl): +46 708 507 603
  | (domestic): 0708 - 507 603
  +==+
 




-- 

--
+==+
| Bästa hälsningar,
| [sw. Best regards]
|
| Lennart Jörelid
| EAI Architect  Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: l...@jguru.se
| URL:   www.jguru.se
| Phone
| (skype):jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==+