Re: Maven moving to the next level: the build/consumer pom

[Jaroslav Tulach]

Hello Robert,
I am not sure how to deal with your announcement and given no reaction on
the dev@netbeans mailing list, I am probably not alone. Can you formulate
your issue as a bug report? E.g. have you tried to use your new Maven with
NetBeans and did you face a problem? Having steps to reproduce would make
it more real for the NetBeans community to take action.

-jt

po 22. 6. 2020 v 23:18 odesílatel Robert Scholte 
napsal:

> Hi,
>
> One of my long standing wishes has made it to the master branch of Maven:
> the support for build/consumer pom.
> With this we can finally start improving the pom without breaking the
> Maven eco system.
>
> Up until now the pom.xml has been distributed (installed/deployed) as is
> to both local and remote repositories.
> The good thing is that is it fast and there is no magic.
> However, it sometimes implies adding redundant information and it also
> blocks any chance of improvement for Maven
>
> The challenge is to make it possible to have an locally an improved
> "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
>
> The whole architecture of Maven was built upon an immutable pom.xml, so it
> took a while to split this, but I managed to solve this.
> And to confirm that it works, some transformations have been added for the
> next Maven release
> The local pom it still model 4.0.0 compatible, but some redundant elements
> are not required anymore.
> - in case the  is located at its relativePath (default:
> ../pom.xml), the version can be removed. groupId and artifactId are still
> required to ensure it is being matched with the right parent.
>
> - dependencies that are part of the reactor don't need a version anymore
> These are implemented steps to get from the file model to the raw model,
> where the required versions are added.
>
> When distributing the pom, the previous transformations are done, but also:
> - cifriendly placeholders in versions (${sha1}, ${revision},
> ${changelist}) will be resolved.
> -  from  will be removed
> -  from  will be removed
> These cleanups are context aware, if they appear in some configuration,
> they won't be touched.
> One of our integration-tests[1] demonstrates how new poms in a multimodule
> project might look like.
>
> Even though the latter steps look quite small (removing elements with
> relative paths), it should give us enough feedback about the whole process.
>
> The status is that it is ready to be embedded in supporting tools like
> IDEs.
> We should give them time to work on this and share feedback.
> It might require some adjustments in Maven to improve user experience.
>
> In the meantime we need to work on plugins that will have impact by these
> changes.
> Most significant is are signing maven plugins such as the
> maven-gpg-plugin, which needs to work with the distributed pom instead of
> the local pom.
> Also all packaging plugin that can include the pom.xml and pom.properties
> in their archive should switch to the distributed pom.
> The maven-shade-plugin was marked as well, but at first glance this looks
> fine.
> In the end all our plugins must be verified, just to be sure.
> So there's enough to work on.
>
> In general I avoid giving timelines about how fast a new release will be
> available.
> Due to the overhead, the small amount of available time of the few
> volunteers working on Maven, I prefer to have a worth set of changes.
> In this case the impact of the changes can be huge, and I want to have
> enough faith that we won't introduce irreversible mistakes.
> Don't expect a new official release in the 3 next months, however we might
> have alpha or beta releases.
>
> There is a wiki page that explains this topic in more detail[2]
> It is still a draft, as there are still parts where we need to reach
> consensus.
> This page is intended as a base for discussions by Maven developers, users
> and related projects, such as IDEs, Repository Managers, CI Servers, etc.
>
> Looking forward for any feedback,
>
> Robert Scholte
> Apache Maven project
>
> [1]
> https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6656-buildconsumer
> [2]
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM

Re: CPD goal in maven plugin does not support txt format.

[Greg Chabala]

>> 'text' doesn't work.
>> In my opinion, txt and text should both be viable options.
>>
>> The PMD goal rejects 'text' and only accepts 'txt'.

Sorry about that. Just a guess on my part from looking at the source of
TextRenderer
,
since it registers itself using "text". But that's in PMD itself, looks
like the plugin is doing its own thing with configuration codes.

>> Any particular reason why Maven developers don't seem to like outputting
>> text output? I see something similar with the Spotbugs plugin. There's no
>> text output either and the XML output is too verbose for my liking.

I've used maven-pmd-plugin myself, and I think it works great. I reference
the plugin in the reporting section of my build, and the reports get
generated with the site goal. I expect reading the HTML reports as part of
the generated site does the job for most folks. And if one wanted to do
something with the report programmatically, there's the xml report for
that. It seems your wish for text output is a bit far from the happy path,
since no one noticed it was broken.

Just poking around in the blame, this looks like the commit that removed
the "txt" support, 14 years ago:
https://github.com/apache/maven-pmd-plugin/commit/e64025962e6babb82435099673a635ab497f2a6b#diff-b57f29ee2de2392a1af539fb7c05ec76L224

>> Specifying sourceforge.pmd.cpd.SimpleRenderer
>> works but it outputs a file as the full class name and ignores the
>> skipEmptyReport configuration value set to true.

That sounds pretty good to me. Could still try the TextRenderer to see if
it performs more to your liking.

>> It also generates a cpd.xml file.

Always. It says that right in the code:
https://github.com/apache/maven-pmd-plugin/blob/master/src/main/java/org/apache/maven/plugins/pmd/CpdReport.java#L311

// always create XML format. we need to output it even if the file list is
> empty or we have no duplications
> // so the "check" goals can check for violations
> writeXmlReport( cpd );


Greg

On Fri, Jul 3, 2020 at 6:14 PM LINUS FERNANDES 
wrote:

> >You want the text renderer?
>
> https://github.com/pmd/pmd/blob/master/pmd-core/src/main/java/net/sourceforge/pmd/renderers/TextRenderer.java
>
> What do you mean? Obviously, I want text output, not XML. I prefer less
> verbose output since I'm looking at it through a text editor.
>
>
On Fri, Jul 3, 2020 at 5:40 PM LINUS FERNANDES 
wrote:

> Thanks, Greg.
>
> On Sat, 4 Jul 2020, 04:05 LINUS FERNANDES, 
> wrote:
>
> > The goals need an output file name as well, I think.
> >
> > On Sat, 4 Jul 2020, 03:52 LINUS FERNANDES, 
> > wrote:
> >
> >> Any particular reason why Maven developers don't seem to like outputting
> >> text output? I see something similar with the Spotbugs plugin. There's
> no
> >> text output either and the XML output is too verbose for my liking.
> >> I've already filed an issue concerning that.
> >>
> >> 'text' doesn't work.
> >> In my opinion, txt and text should both be viable options.
> >>
> >> The PMD goal rejects 'text' and only accepts 'txt'.
> >>
> >> Since they're from the same Maven family, the CPD goal must accept txt
> as
> >> an option as well. And the documentation is misleading when it says it
> >> supports specifying 'txt' as an input.
> >>
> >> Specifying sourceforge.pmd.cpd.SimpleRenderer
> >> works but it outputs a file as the full class name and ignores the
> >> skipEmptyReport configuration value set to true.
> >>
> >> It also generates a cpd.xml file.
> >>
> >> Where does a bug report go?
> >> Jira or the pmd Github repo?
> >>
> >> Is there a specific tag for the pmd maven plugin?
> >>
> >>
> >>
> >>
> >> On Sat, 4 Jul 2020, 01:56 Greg Chabala,  wrote:
> >>
> >>> Better still, use the full classname of the renderer, looks like the
> >>> plugin
> >>> only know how to handle xml and csv:
> >>>
> >>>
> https://github.com/apache/maven-pmd-plugin/blob/master/src/main/java/org/apache/maven/plugins/pmd/CpdReport.java#L456
> >>>
> >>> On Fri, Jul 3, 2020 at 3:22 PM Greg Chabala 
> >>> wrote:
> >>>
> >>> > Looks like a typo in the documentation. From your link "See the
> >>> > net.sourceforge.pmd.renderers package javadoc for available
> renderers".
> >>> >
> >>> > You want the text renderer?
> >>> >
> >>>
> https://github.com/pmd/pmd/blob/master/pmd-core/src/main/java/net/sourceforge/pmd/renderers/TextRenderer.java
> >>> >
> >>> > Try "text" instead of "txt".
> >>> >
> >>> > On Fri, Jul 3, 2020 at 2:18 AM LINUS FERNANDES <
> >>> linus.fernan...@gmail.com>
> >>> > wrote:
> >>> >
> >>> >> If this is a bug, where do I file it?
> >>> >>
> >>> >> On Fri, 3 Jul 2020, 11:46 LINUS FERNANDES, <
> linus.fernan...@gmail.com
> >>> >
> >>> >> wrote:
> >>> >>
> >>> >> >
> >>> >> > I receive the following message while using the cpd goal in the
> PMD
> >>> >> maven
> >>> >> > plugin.
> >>> >> >
> >>> >> > maven.plugins:maven-pmd-plugin:3.13.0:cpd 

Re: CPD goal in maven plugin does not support txt format.

[LINUS FERNANDES]

>You want the text renderer?
https://github.com/pmd/pmd/blob/master/pmd-core/src/main/java/net/sourceforge/pmd/renderers/TextRenderer.java

What do you mean? Obviously, I want text output, not XML. I prefer less
verbose output since I'm looking at it through a text editor.




On Sat, 4 Jul 2020, 01:53 Greg Chabala,  wrote:

> Looks like a typo in the documentation. From your link "See the
> net.sourceforge.pmd.renderers package javadoc for available renderers".
>
> You want the text renderer?
>
> https://github.com/pmd/pmd/blob/master/pmd-core/src/main/java/net/sourceforge/pmd/renderers/TextRenderer.java
>
> Try "text" instead of "txt".
>
> On Fri, Jul 3, 2020 at 2:18 AM LINUS FERNANDES 
> wrote:
>
> > If this is a bug, where do I file it?
> >
> > On Fri, 3 Jul 2020, 11:46 LINUS FERNANDES, 
> > wrote:
> >
> > >
> > > I receive the following message while using the cpd goal in the PMD
> maven
> > > plugin.
> > >
> > > maven.plugins:maven-pmd-plugin:3.13.0:cpd (cpd) on project DSAlgos:
> > > Execution cpd of goal
> > org.apache.maven.plugins:maven-pmd-plugin:3.13.0:cpd
> > > failed: org.apache.maven.reporting.MavenReportException: Can't find CPD
> > > custom format txt: java.lang.ClassNotFoundException
> > >
> > > The documentation states that the txt format is supported.
> > >
> > > https://maven.apache.org/plugins/maven-pmd-plugin/cpd-mojo.html#format
> > >
> > > The pmd goal supports the txt format.
> > >
> > >
> > > Regards,
> > > Linus.
> > >
> > >
> > >
> > >
> >
>

Re: CPD goal in maven plugin does not support txt format.

[LINUS FERNANDES]

Thanks, Greg.

On Sat, 4 Jul 2020, 04:05 LINUS FERNANDES, 
wrote:

> The goals need an output file name as well, I think.
>
> On Sat, 4 Jul 2020, 03:52 LINUS FERNANDES, 
> wrote:
>
>> Any particular reason why Maven developers don't seem to like outputting
>> text output? I see something similar with the Spotbugs plugin. There's no
>> text output either and the XML output is too verbose for my liking.
>> I've already filed an issue concerning that.
>>
>> 'text' doesn't work.
>> In my opinion, txt and text should both be viable options.
>>
>> The PMD goal rejects 'text' and only accepts 'txt'.
>>
>> Since they're from the same Maven family, the CPD goal must accept txt as
>> an option as well. And the documentation is misleading when it says it
>> supports specifying 'txt' as an input.
>>
>> Specifying sourceforge.pmd.cpd.SimpleRenderer
>> works but it outputs a file as the full class name and ignores the
>> skipEmptyReport configuration value set to true.
>>
>> It also generates a cpd.xml file.
>>
>> Where does a bug report go?
>> Jira or the pmd Github repo?
>>
>> Is there a specific tag for the pmd maven plugin?
>>
>>
>>
>>
>> On Sat, 4 Jul 2020, 01:56 Greg Chabala,  wrote:
>>
>>> Better still, use the full classname of the renderer, looks like the
>>> plugin
>>> only know how to handle xml and csv:
>>>
>>> https://github.com/apache/maven-pmd-plugin/blob/master/src/main/java/org/apache/maven/plugins/pmd/CpdReport.java#L456
>>>
>>> On Fri, Jul 3, 2020 at 3:22 PM Greg Chabala 
>>> wrote:
>>>
>>> > Looks like a typo in the documentation. From your link "See the
>>> > net.sourceforge.pmd.renderers package javadoc for available renderers".
>>> >
>>> > You want the text renderer?
>>> >
>>> https://github.com/pmd/pmd/blob/master/pmd-core/src/main/java/net/sourceforge/pmd/renderers/TextRenderer.java
>>> >
>>> > Try "text" instead of "txt".
>>> >
>>> > On Fri, Jul 3, 2020 at 2:18 AM LINUS FERNANDES <
>>> linus.fernan...@gmail.com>
>>> > wrote:
>>> >
>>> >> If this is a bug, where do I file it?
>>> >>
>>> >> On Fri, 3 Jul 2020, 11:46 LINUS FERNANDES, >> >
>>> >> wrote:
>>> >>
>>> >> >
>>> >> > I receive the following message while using the cpd goal in the PMD
>>> >> maven
>>> >> > plugin.
>>> >> >
>>> >> > maven.plugins:maven-pmd-plugin:3.13.0:cpd (cpd) on project DSAlgos:
>>> >> > Execution cpd of goal
>>> >> org.apache.maven.plugins:maven-pmd-plugin:3.13.0:cpd
>>> >> > failed: org.apache.maven.reporting.MavenReportException: Can't find
>>> CPD
>>> >> > custom format txt: java.lang.ClassNotFoundException
>>> >> >
>>> >> > The documentation states that the txt format is supported.
>>> >> >
>>> >> >
>>> https://maven.apache.org/plugins/maven-pmd-plugin/cpd-mojo.html#format
>>> >> >
>>> >> > The pmd goal supports the txt format.
>>> >> >
>>> >> >
>>> >> > Regards,
>>> >> > Linus.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> >
>>>
>>

Re: CPD goal in maven plugin does not support txt format.

[LINUS FERNANDES]

The goals need an output file name as well, I think.

On Sat, 4 Jul 2020, 03:52 LINUS FERNANDES, 
wrote:

> Any particular reason why Maven developers don't seem to like outputting
> text output? I see something similar with the Spotbugs plugin. There's no
> text output either and the XML output is too verbose for my liking.
> I've already filed an issue concerning that.
>
> 'text' doesn't work.
> In my opinion, txt and text should both be viable options.
>
> The PMD goal rejects 'text' and only accepts 'txt'.
>
> Since they're from the same Maven family, the CPD goal must accept txt as
> an option as well. And the documentation is misleading when it says it
> supports specifying 'txt' as an input.
>
> Specifying sourceforge.pmd.cpd.SimpleRenderer
> works but it outputs a file as the full class name and ignores the
> skipEmptyReport configuration value set to true.
>
> It also generates a cpd.xml file.
>
> Where does a bug report go?
> Jira or the pmd Github repo?
>
> Is there a specific tag for the pmd maven plugin?
>
>
>
>
> On Sat, 4 Jul 2020, 01:56 Greg Chabala,  wrote:
>
>> Better still, use the full classname of the renderer, looks like the
>> plugin
>> only know how to handle xml and csv:
>>
>> https://github.com/apache/maven-pmd-plugin/blob/master/src/main/java/org/apache/maven/plugins/pmd/CpdReport.java#L456
>>
>> On Fri, Jul 3, 2020 at 3:22 PM Greg Chabala 
>> wrote:
>>
>> > Looks like a typo in the documentation. From your link "See the
>> > net.sourceforge.pmd.renderers package javadoc for available renderers".
>> >
>> > You want the text renderer?
>> >
>> https://github.com/pmd/pmd/blob/master/pmd-core/src/main/java/net/sourceforge/pmd/renderers/TextRenderer.java
>> >
>> > Try "text" instead of "txt".
>> >
>> > On Fri, Jul 3, 2020 at 2:18 AM LINUS FERNANDES <
>> linus.fernan...@gmail.com>
>> > wrote:
>> >
>> >> If this is a bug, where do I file it?
>> >>
>> >> On Fri, 3 Jul 2020, 11:46 LINUS FERNANDES, 
>> >> wrote:
>> >>
>> >> >
>> >> > I receive the following message while using the cpd goal in the PMD
>> >> maven
>> >> > plugin.
>> >> >
>> >> > maven.plugins:maven-pmd-plugin:3.13.0:cpd (cpd) on project DSAlgos:
>> >> > Execution cpd of goal
>> >> org.apache.maven.plugins:maven-pmd-plugin:3.13.0:cpd
>> >> > failed: org.apache.maven.reporting.MavenReportException: Can't find
>> CPD
>> >> > custom format txt: java.lang.ClassNotFoundException
>> >> >
>> >> > The documentation states that the txt format is supported.
>> >> >
>> >> >
>> https://maven.apache.org/plugins/maven-pmd-plugin/cpd-mojo.html#format
>> >> >
>> >> > The pmd goal supports the txt format.
>> >> >
>> >> >
>> >> > Regards,
>> >> > Linus.
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >
>>
>

Re: CPD goal in maven plugin does not support txt format.

[LINUS FERNANDES]

Any particular reason why Maven developers don't seem to like outputting
text output? I see something similar with the Spotbugs plugin. There's no
text output either and the XML output is too verbose for my liking.
I've already filed an issue concerning that.

'text' doesn't work.
In my opinion, txt and text should both be viable options.

The PMD goal rejects 'text' and only accepts 'txt'.

Since they're from the same Maven family, the CPD goal must accept txt as
an option as well. And the documentation is misleading when it says it
supports specifying 'txt' as an input.

Specifying sourceforge.pmd.cpd.SimpleRenderer
works but it outputs a file as the full class name and ignores the
skipEmptyReport configuration value set to true.

It also generates a cpd.xml file.

Where does a bug report go?
Jira or the pmd Github repo?

Is there a specific tag for the pmd maven plugin?




On Sat, 4 Jul 2020, 01:56 Greg Chabala,  wrote:

> Better still, use the full classname of the renderer, looks like the plugin
> only know how to handle xml and csv:
>
> https://github.com/apache/maven-pmd-plugin/blob/master/src/main/java/org/apache/maven/plugins/pmd/CpdReport.java#L456
>
> On Fri, Jul 3, 2020 at 3:22 PM Greg Chabala 
> wrote:
>
> > Looks like a typo in the documentation. From your link "See the
> > net.sourceforge.pmd.renderers package javadoc for available renderers".
> >
> > You want the text renderer?
> >
> https://github.com/pmd/pmd/blob/master/pmd-core/src/main/java/net/sourceforge/pmd/renderers/TextRenderer.java
> >
> > Try "text" instead of "txt".
> >
> > On Fri, Jul 3, 2020 at 2:18 AM LINUS FERNANDES <
> linus.fernan...@gmail.com>
> > wrote:
> >
> >> If this is a bug, where do I file it?
> >>
> >> On Fri, 3 Jul 2020, 11:46 LINUS FERNANDES, 
> >> wrote:
> >>
> >> >
> >> > I receive the following message while using the cpd goal in the PMD
> >> maven
> >> > plugin.
> >> >
> >> > maven.plugins:maven-pmd-plugin:3.13.0:cpd (cpd) on project DSAlgos:
> >> > Execution cpd of goal
> >> org.apache.maven.plugins:maven-pmd-plugin:3.13.0:cpd
> >> > failed: org.apache.maven.reporting.MavenReportException: Can't find
> CPD
> >> > custom format txt: java.lang.ClassNotFoundException
> >> >
> >> > The documentation states that the txt format is supported.
> >> >
> >> >
> https://maven.apache.org/plugins/maven-pmd-plugin/cpd-mojo.html#format
> >> >
> >> > The pmd goal supports the txt format.
> >> >
> >> >
> >> > Regards,
> >> > Linus.
> >> >
> >> >
> >> >
> >> >
> >>
> >
>

Re: CPD goal in maven plugin does not support txt format.

[Greg Chabala]

Better still, use the full classname of the renderer, looks like the plugin
only know how to handle xml and csv:
https://github.com/apache/maven-pmd-plugin/blob/master/src/main/java/org/apache/maven/plugins/pmd/CpdReport.java#L456

On Fri, Jul 3, 2020 at 3:22 PM Greg Chabala  wrote:

> Looks like a typo in the documentation. From your link "See the
> net.sourceforge.pmd.renderers package javadoc for available renderers".
>
> You want the text renderer?
> https://github.com/pmd/pmd/blob/master/pmd-core/src/main/java/net/sourceforge/pmd/renderers/TextRenderer.java
>
> Try "text" instead of "txt".
>
> On Fri, Jul 3, 2020 at 2:18 AM LINUS FERNANDES 
> wrote:
>
>> If this is a bug, where do I file it?
>>
>> On Fri, 3 Jul 2020, 11:46 LINUS FERNANDES, 
>> wrote:
>>
>> >
>> > I receive the following message while using the cpd goal in the PMD
>> maven
>> > plugin.
>> >
>> > maven.plugins:maven-pmd-plugin:3.13.0:cpd (cpd) on project DSAlgos:
>> > Execution cpd of goal
>> org.apache.maven.plugins:maven-pmd-plugin:3.13.0:cpd
>> > failed: org.apache.maven.reporting.MavenReportException: Can't find CPD
>> > custom format txt: java.lang.ClassNotFoundException
>> >
>> > The documentation states that the txt format is supported.
>> >
>> > https://maven.apache.org/plugins/maven-pmd-plugin/cpd-mojo.html#format
>> >
>> > The pmd goal supports the txt format.
>> >
>> >
>> > Regards,
>> > Linus.
>> >
>> >
>> >
>> >
>>
>

Re: CPD goal in maven plugin does not support txt format.

[Greg Chabala]

Looks like a typo in the documentation. From your link "See the
net.sourceforge.pmd.renderers package javadoc for available renderers".

You want the text renderer?
https://github.com/pmd/pmd/blob/master/pmd-core/src/main/java/net/sourceforge/pmd/renderers/TextRenderer.java

Try "text" instead of "txt".

On Fri, Jul 3, 2020 at 2:18 AM LINUS FERNANDES 
wrote:

> If this is a bug, where do I file it?
>
> On Fri, 3 Jul 2020, 11:46 LINUS FERNANDES, 
> wrote:
>
> >
> > I receive the following message while using the cpd goal in the PMD maven
> > plugin.
> >
> > maven.plugins:maven-pmd-plugin:3.13.0:cpd (cpd) on project DSAlgos:
> > Execution cpd of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.13.0:cpd
> > failed: org.apache.maven.reporting.MavenReportException: Can't find CPD
> > custom format txt: java.lang.ClassNotFoundException
> >
> > The documentation states that the txt format is supported.
> >
> > https://maven.apache.org/plugins/maven-pmd-plugin/cpd-mojo.html#format
> >
> > The pmd goal supports the txt format.
> >
> >
> > Regards,
> > Linus.
> >
> >
> >
> >
>

Re[2]: How does surefire 3.0.0-M5 run JPMS with junit5?

[Alex Orlov]

Hi Tibor,
 
Thank you for your answer. I’ve read the link you provided but didn’t find the
answer to my question. I don’t have any questions about how to run jpms tests.
I can’t understand how tests are executed without junit platform in boot layer.
As I understand we have the following chain:
maven → surefire → junit-platform-launcher → junit-platform-engine.
 
However, I can’t find maven, surefire, launcher, engine in boot layer. How
does it work? Could you explain what magic I miss?
 
Alex 
>Пятница, 3 июля 2020, 17:40 +03:00 от Tibor Digana :
> 
>Hi Alex,
> 
>This is the documentation regarding this topic
>https://maven.apache.org/surefire/maven-surefire-plugin/examples/jpms.html
>and you can see the links with the integration tests for TestNG, JUnit4 and 
>JUnit5.
>These tests use JPMS in main and tests as well. You should be able to access 
>"org.junit" packages of course.
>The class-path may be empty, or it contains only surefire libraries.
> 
>Try to copy the ITs and try to run "mvn test". It should work for you.
> 
>Cheers
>T
>   
>On Fri, Jul 3, 2020 at 2:57 PM Alex Orlov < ooo_satu...@mail.ru.invalid > 
>wrote:
>  
>>Hi all,
>> 
>>I want to understand how surefire 3.0.0-M5 run JPMS with junit5. When I run my
>>tests on boot layer I see only two junit modules:
>> 
>>org.junit.jupiter.api
>>org.junit.platform.commons
>> 
>>And there is no platform, no engine. Besides "java.class.path" is empty. 
>>Could anyone
>>explain where is platform, engine etc.
>> 
>>--
>>Alex Orlov 
 
 
--
Alex Orlov
 

Re: How does surefire 3.0.0-M5 run JPMS with junit5?

[Tibor Digana]

Hi Alex,

This is the documentation regarding this topic
https://maven.apache.org/surefire/maven-surefire-plugin/examples/jpms.html
and you can see the links with the integration tests for TestNG, JUnit4 and
JUnit5.
These tests use JPMS in main and tests as well. You should be able to
access "org.junit" packages of course.
The class-path may be empty, or it contains only surefire libraries.

Try to copy the ITs and try to run "mvn test". It should work for you.

Cheers
T


On Fri, Jul 3, 2020 at 2:57 PM Alex Orlov 
wrote:

>
> Hi all,
>
> I want to understand how surefire 3.0.0-M5 run JPMS with junit5. When I
> run my
> tests on boot layer I see only two junit modules:
>
> org.junit.jupiter.api
> org.junit.platform.commons
>
> And there is no platform, no engine. Besides "java.class.path" is empty.
> Could anyone
> explain where is platform, engine etc.
>
> --
> Alex Orlov

Re: Maven moving to the next level: the build/consumer pom

[Robert Scholte]

On 25-6-2020 02:03:42, Anton Vodonosov  wrote:
Can this work also allow arbitrary property expression in a module ?
Robert Scholte:
Currently only the ci-friendly version placeholders are supported.


Currently, this practice is discouraged because the deployed pom with property
expression is meaningless.
The flatten-maven-plugin can produce correct poms for deployment,
with all properties resolved; despite maven prints the hardcoded warning
"'version' contains an expression but should be a constant".
Robert Scholte: 
The statement is still that versions should be constants and not expressions. 
It is likely that this is one of the next things that will be implemented.
This announcement is especially for tools needing to read the new local pom.xml
There's a small set of features added, so they can investigate if it works.
It would be a huge waste of time if we discover that the current implementation 
makes it impossible for IDEs to embed Maven.



Links on the topic:
http://mail-archives.apache.org/mod_mbox/maven-users/201201.mbox/%3cca+npnmyb_w4ldrg5ztn5nx3f2kcrpxdefs4gjzz3oe0cuy1...@mail.gmail.com%3E
https://issues.apache.org/jira/browse/MNG-4715
https://stackoverflow.com/questions/19123013/maven-version-with-a-property/19123130

Why I'm interested in property expressions for versions is because I want to 
generate
versions automatically as a hash code of all sources and dependencies.

And also skip building of modules whose has-version has not changed.

That way the large multi-module project can vary significantly improve build 
speed
and reduce the artifact storage consumption. Similar to what build caches
give for gradle and bazel, only a bit simplified, less granular - caching done
on the level of final artifacts, but not for intermediate outputs
(compiled file, generated resources).

If would be very convenient if maven-flatten-plugin become unnecessary
and maven supported property expressions in version spec out of box.
Robert Scholte:
The flatten-maven-plugin was written because there was a direct need for 
manipulating poms that could not be solved easily inside Maven itself.
This is one step into the right direction.



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

Re: Maven moving to the next level: the build/consumer pom

[Robert Scholte]

On 24-6-2020 00:48:48, Mark Derricutt  wrote:
Love the work here - I'll definitely be keen on trying this out and see how it 
interacts with our tiles-maven-plugin.

Regarding this "reactor" bit tho - just because a module is in the reactor, 
doesn't always mean it has the same parent - the version of the dependency 
could be elided if the parent version matched AND that dependency is part of 
the reactor.
Robert Scholte: 
The parent isn't used to resolve the version. If a dependency is missing a 
version, Maven will look up the version by finding the reactor module based on 
the groupId and artifactId.




However, I have seem people use reactors purely as build-coordinators, and not 
always used. I'd much rather seeing them stay - esp. if using version ranges ( 
we force [] ranges for instance ).
Robert Scholte: 
Current behavior shouldn't change, there's just an extra option: don't include 
the version and let Maven embed the right value.




Mark

On 24/06/20, 9:20 AM, "Matthieu BROUILLARD" wrote:

> dependencies that are part of the reactor don't need a version anymore
What is meant here ? Is it that in a multimodule project a dependency from
a module to another of the same multimodule does not need the version ? For
example when having an api and impl in the same multimodule, the impl will
not require the version of the api?

B�CB��[��X��ܚX�KK[XZ[�\�\��][��X��ܚX�PX]�[��\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[�\�\��Z[X]�[��\X�K�ܙ�B

Re: Maven moving to the next level: the build/consumer pom

[Robert Scholte]

On 23-6-2020 23:20:31, Matthieu BROUILLARD  wrote:
Hi Robert,

congrats this looks like a great achievement.

I presume that the consumer pom means the end of the flatten plugin or is
there still some benefit in using flatten plugin?
Robert Scholte:
The flatten-maven-plugin was introduced when the installAtEnd/deployAtEnd was 
introduced and users couldn't define their own pom anymore.
In the meantime it has a lot of configurable filters to manipulate the pom, not 
sure if everything will be possible.


> dependencies that are part of the reactor don't need a version anymore
What is meant here ? Is it that in a multimodule project a dependency from
a module to another of the same multimodule does not need the version ? For
example when having an api and impl in the same multimodule, the impl will
not require the version of the api?
Robert Scholte: 
Exactly, you don't need to specify it in the local pom, the distributed pom 
will be enriched with the correct version.



> These are implemented steps to get from the file model to the raw model,
where the required versions are added.
Are those replacements still part of the pom loading by ModelProcessor?
I'll give it a try especially to see the compliance with my existing core
extensions.
Robert Scholte:
Yes, I've tried to implement it without need of changes for plugins and 
extensions.


Matthieu Brouillard

On Mon, Jun 22, 2020 at 11:18 PM Robert Scholte
wrote:

> Hi,
>
> One of my long standing wishes has made it to the master branch of Maven:
> the support for build/consumer pom.
> With this we can finally start improving the pom without breaking the
> Maven eco system.
>
> Up until now the pom.xml has been distributed (installed/deployed) as is
> to both local and remote repositories.
> The good thing is that is it fast and there is no magic.
> However, it sometimes implies adding redundant information and it also
> blocks any chance of improvement for Maven
>
> The challenge is to make it possible to have an locally an improved
> "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
>
> The whole architecture of Maven was built upon an immutable pom.xml, so it
> took a while to split this, but I managed to solve this.
> And to confirm that it works, some transformations have been added for the
> next Maven release
> The local pom it still model 4.0.0 compatible, but some redundant elements
> are not required anymore.
> - in case the is located at its relativePath (default:
> ../pom.xml), the version can be removed. groupId and artifactId are still
> required to ensure it is being matched with the right parent.
>
> - dependencies that are part of the reactor don't need a version anymore
> These are implemented steps to get from the file model to the raw model,
> where the required versions are added.
>
> When distributing the pom, the previous transformations are done, but also:
> - cifriendly placeholders in versions (${sha1}, ${revision},
> ${changelist}) will be resolved.
> - from will be removed
> - from will be removed
> These cleanups are context aware, if they appear in some configuration,
> they won't be touched.
> One of our integration-tests[1] demonstrates how new poms in a multimodule
> project might look like.
>
> Even though the latter steps look quite small (removing elements with
> relative paths), it should give us enough feedback about the whole process.
>
> The status is that it is ready to be embedded in supporting tools like
> IDEs.
> We should give them time to work on this and share feedback.
> It might require some adjustments in Maven to improve user experience.
>
> In the meantime we need to work on plugins that will have impact by these
> changes.
> Most significant is are signing maven plugins such as the
> maven-gpg-plugin, which needs to work with the distributed pom instead of
> the local pom.
> Also all packaging plugin that can include the pom.xml and pom.properties
> in their archive should switch to the distributed pom.
> The maven-shade-plugin was marked as well, but at first glance this looks
> fine.
> In the end all our plugins must be verified, just to be sure.
> So there's enough to work on.
>
> In general I avoid giving timelines about how fast a new release will be
> available.
> Due to the overhead, the small amount of available time of the few
> volunteers working on Maven, I prefer to have a worth set of changes.
> In this case the impact of the changes can be huge, and I want to have
> enough faith that we won't introduce irreversible mistakes.
> Don't expect a new official release in the 3 next months, however we might
> have alpha or beta releases.
>
> There is a wiki page that explains this topic in more detail[2]
> It is still a draft, as there are still parts where we need to reach
> consensus.
> This page is intended as a base for discussions by Maven developers, users
> and related projects, such as IDEs, Repository Managers, CI Servers, etc.
>
> Looking forward for any feedback,
>

How does surefire 3.0.0-M5 run JPMS with junit5?

[Alex Orlov]

Hi all,
 
I want to understand how surefire 3.0.0-M5 run JPMS with junit5. When I run my
tests on boot layer I see only two junit modules:
 
org.junit.jupiter.api
org.junit.platform.commons
 
And there is no platform, no engine. Besides "java.class.path" is empty. Could 
anyone
explain where is platform, engine etc.
 
--
Alex Orlov

Re: maven failsafe plugin & POJO tests

[Nigel Jones]

Thanks for all the replies

I did try the test project from @tibordigana which worked well. I was able to 
change names etc and still have the tests working, but oddly could still not 
figure out why my main project was failing to find all the correct classes & 
methods.

I ended up abandoning trying to get the pojos working & just created some 
JUnit5 tests to wrap the existing tests. Not perfect as it's a small handful of 
large tests and should be decomposed, but that is independent of the framework. 
The key thing was with JUnit5 there was no issue locating and running the tests 
- and in any case it's a better model for future tests.

Regards
Nigel.

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

Re: Build behavior differences between 3.2.5 and 3.3.9 with dependency shading

[Robert Metzger]

Hi all,

sorry for bringing up this very old thread again: The Flink project is
still using Maven 3.2.5 to have the shading behave as we need it. Using
such an old Maven version has some issues in our development workflow, as
the http library is quite outdated, and developers are working with much
newer maven versions locally, leading to some inconsistent dependency
resolutions.

I was wondering if there was any progress in the last years, so that we can
switch to a newer Maven version?

On Mon, Nov 7, 2016 at 12:04 AM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> yes that was the advice I gave on this thread originally. you do have to
> fight a bit with the shade plugin to get them shaded in though... which is
> why I think we may need to rethink how we do shade
>
> On 6 November 2016 at 22:36, Jörg Schaible  wrote:
>
> > Stephen Connolly wrote:
> >
> > > Hmmm I did some digging...
> > >
> > >
> > https://maven.apache.org/ref/3.2.3/apidocs/org/apache/
> > maven/artifact/handler/ArtifactHandler.html#isIncludesDependencies()
> > > is i think the idea JvZ was hinting at.
> > >
> > > For the case where a shaded JAR shades *everything* then a custom
> > > packaging will work as we could set this flag and it would stop the
> > > transitive dependencies being propagated... but most people do not
> shade
> > > *all* dependencies, rather they shade a subset.
> > >
> > > I think we may need to re-think how we do this or rethink the model
> being
> > > read-only
> >
> > Set the shaded dependencies as optional. This might at least technically
> > produce the proper dependency tree for dependent artifacts.
> >
> > Cheers,
> > Jörg
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

RE: Surefire - Forking - Identifying Tests that run in a particular fork

[Martin Lambert]

Hi Falko,

Thanks for the suggestion. In the end I created a simple Junit 
TestExecutionListener class that overrode executionStarted() and 
executionFinished(); both methods have a TestIdentifier parameter, if this is 
actually an instance of MethodSource 
(https://junit.org/junit5/docs/current/api/org.junit.platform.engine/org/junit/platform/engine/support/descriptor/MethodSource.html)
 you can downcast it, this allows you can get hold of the test class' name 
using getClassName() on the same object; somewhere I was able to call an 
isTest() method to filter out noise - I can't remember where off the top of my 
head. To make the whole thing work you have to create a ServiceLoader file as 
mentioned in 6.1.4 here: 
https://junit.org/junit5/docs/current/user-guide/#launcher-api-listeners-custom 
(it really does just involve creating the specific file in the location 
mentioned, containing only the fully qualified name of your 
TestExecutionListener class  ).

Cheers,

Martin.

-Original Message-
From: Falko Modler  
Sent: 01 July 2020 23:48
To: users@maven.apache.org
Subject: Re: Surefire - Forking - Identifying Tests that run in a particular 
fork

Hi Martin,

OOTB you'll probably have to resort to -X (which logs way too much) and even 
then I am not 100% sure you'll get what you need.

Did you have a look at |${surefire.forkNumber}| (see 
https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html)?

I've been using this as a system property in my projects to:

- write one logfile per fork (e.g. via Logback)
- prefix each logged line with the fork number (also via Logback, especially 
useful for Jenins console log)
- log each test method in a JUnit4 listener together with the log file 
(certainly also possible with JUnit5 etc.)
- separate working directories, generate tracing ids etc.

I can really recommend to take these extra measures, otherwise analyzing test 
failures with multiple forks and/or parallel modules (-T) will be a real pain 
in the long run.

Cheers,

Falko

Am 02.07.2020 um 00:12 schrieb Martin Lambert:
> Hello,
>
>
>
> I'm currently using the Surefire plugin with Maven 3.6.3 and would 
> like to know if there is any way to identify what tests were run in a 
> given fork? I haven't seen any option for it in the current 
> documentation. I'm running around ~10K test cases hence using the fork 
> option to speed things up. The problem I'm trying to solve is that a 
> single test intermittently fails, which, when run individually 
> succeeds; I suspect this is due to a prior test case not cleaning up 
> properly and would therefore like to be able to identify at a minimum 
> what test cases are in a fork group so that I can take a divide and 
> conquer approach to resolving the issue, even better would be to know which 
> test cases ran before the failing test case.
>
>
>
> Thanks for your help,
>
>
>
> Martin.
>
>
>
>



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

Re: CPD goal in maven plugin does not support txt format.

[LINUS FERNANDES]

If this is a bug, where do I file it?

On Fri, 3 Jul 2020, 11:46 LINUS FERNANDES, 
wrote:

>
> I receive the following message while using the cpd goal in the PMD maven
> plugin.
>
> maven.plugins:maven-pmd-plugin:3.13.0:cpd (cpd) on project DSAlgos:
> Execution cpd of goal org.apache.maven.plugins:maven-pmd-plugin:3.13.0:cpd
> failed: org.apache.maven.reporting.MavenReportException: Can't find CPD
> custom format txt: java.lang.ClassNotFoundException
>
> The documentation states that the txt format is supported.
>
> https://maven.apache.org/plugins/maven-pmd-plugin/cpd-mojo.html#format
>
> The pmd goal supports the txt format.
>
>
> Regards,
> Linus.
>
>
>
>

CPD goal in maven plugin does not support txt format.

[LINUS FERNANDES]

I receive the following message while using the cpd goal in the PMD maven
plugin.

maven.plugins:maven-pmd-plugin:3.13.0:cpd (cpd) on project DSAlgos:
Execution cpd of goal org.apache.maven.plugins:maven-pmd-plugin:3.13.0:cpd
failed: org.apache.maven.reporting.MavenReportException: Can't find CPD
custom format txt: java.lang.ClassNotFoundException

The documentation states that the txt format is supported.

https://maven.apache.org/plugins/maven-pmd-plugin/cpd-mojo.html#format

The pmd goal supports the txt format.


Regards,
Linus.