You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Mirko Friedenhagen <mf...@gmx.de> on 2021/02/19 17:52:05 UTC
Different plugin classpath in Maven 3.6.3 and 4.0.0?
Hello,
* I now gave Apache Maven 4.0.0-alpha-1-SNAPSHOT (84a1ff2d5cb7bf49fa3171dd92f7ac088e837185) a try.
* In my POM I configured the net.rumati.maven.plugins:velocity-maven-plugin which should render a HTML file.
* The parent of the project has a global extension in the build section.
* The jar of the extension does include a velocity which is picked up quite fine by the velocity-maven-plugin from
the classpath by 3.6.3 but when using 4.0.0 I now need to add the extension jar as a dependency to the plugin.
Is this an intended behavior?
Best Regards
Mirko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Different plugin classpath in Maven 3.6.3 and 4.0.0?
Posted by Robert Scholte <rf...@apache.org>.
I've created MNG-7110 to track this issue
Robert
[1] https://issues.apache.org/jira/browse/MNG-7110
On 27-2-2021 13:27:04, Robert Scholte <rf...@apache.org> wrote:
Interesting, MavenProjects classrealm is null with Maven 4 (Unlike Maven 3.6.3). I don't see any relation with that particular commit yet.
This needs more investigation.
Robert
On 23-2-2021 17:32:15, Mirko Friedenhagen <mf...@gmx.de> wrote:
And now I was able to reproduce this:
https://github.com/mfriedenhagen/plugin-classpath-maven-3-and-4
mvn clean verify succeeds with 3.6.3 and breaks with 619973b91cff5af7b5695bda11761a982a159349 ff.
> Am 23.02.2021 um 14:42 schrieb Mirko Friedenhagen :
>
> Not that deep in bisecting as of now. I wrote a small script `bisect`:
>
> ```
> #!/bin/bash -e -p
> mvn -q -B -s ~/.m2/settings-oss.xml clean package -Dmaven.test.skip=true -Denforcer.skip=true -Drat.skip=true
> bin_tar_gz=apache-maven/target/apache-maven-[3,4]*-bin.tar.gz
> test -f $bin_tar_gz
> gunzip -dc $bin_tar_gz | (cd /tmp/ && rm -rf apache-maven-*-SNAPSHOT && tar x)
> cd $HOME/ghq/gitlab.example.com/group/failing-project
> /tmp/apache-maven-*-SNAPSHOT/bin/mvn -B -V -q clean verify -DskipTests
> ```
>
> Running:
> ```
> $ git bisect start 84a1ff2d5cb7bf49fa3171dd92f7ac088e837185 maven-3.6.3
> $ git bisect run ./bisect
> ```
>
> led to:
>
> ```
> $ git bisect log
> # bad: [84a1ff2d5cb7bf49fa3171dd92f7ac088e837185] [MNG-7063] Add unittest to ensure rereading a pom won't return the cached Model
> …
> # first bad commit: [619973b91cff5af7b5695bda11761a982a159349] [MNG-7063] Infinite loop using Shade plugin and JUnit 5 dependency
> ```
>
> Best Regards
> Mirko
>
>
>> Am 23.02.2021 um 10:21 schrieb Michael Osipov :
>>
>> Am 2021-02-23 um 10:16 schrieb Mirko Friedenhagen:
>>> Hello Michal, hello Robert,
>>> Thanks for the answers.
>>> I am trying to reproduce this with a smaller project, but it is quite hard. The problem occurs with an inhouse project where we use inhouse plugins etc. We manage the lifecycle of standard packagings as well in the the extension. I wrote a FOSS derivate (not widely use) and will try to give a small example.
>>> Robert, did you mean to bisect the maven-core?
>>
>> Yes, he did. This is what I would do.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: Different plugin classpath in Maven 3.6.3 and 4.0.0?
Posted by Robert Scholte <rf...@apache.org>.
Interesting, MavenProjects classrealm is null with Maven 4 (Unlike Maven 3.6.3). I don't see any relation with that particular commit yet.
This needs more investigation.
Robert
On 23-2-2021 17:32:15, Mirko Friedenhagen <mf...@gmx.de> wrote:
And now I was able to reproduce this:
https://github.com/mfriedenhagen/plugin-classpath-maven-3-and-4
mvn clean verify succeeds with 3.6.3 and breaks with 619973b91cff5af7b5695bda11761a982a159349 ff.
> Am 23.02.2021 um 14:42 schrieb Mirko Friedenhagen :
>
> Not that deep in bisecting as of now. I wrote a small script `bisect`:
>
> ```
> #!/bin/bash -e -p
> mvn -q -B -s ~/.m2/settings-oss.xml clean package -Dmaven.test.skip=true -Denforcer.skip=true -Drat.skip=true
> bin_tar_gz=apache-maven/target/apache-maven-[3,4]*-bin.tar.gz
> test -f $bin_tar_gz
> gunzip -dc $bin_tar_gz | (cd /tmp/ && rm -rf apache-maven-*-SNAPSHOT && tar x)
> cd $HOME/ghq/gitlab.example.com/group/failing-project
> /tmp/apache-maven-*-SNAPSHOT/bin/mvn -B -V -q clean verify -DskipTests
> ```
>
> Running:
> ```
> $ git bisect start 84a1ff2d5cb7bf49fa3171dd92f7ac088e837185 maven-3.6.3
> $ git bisect run ./bisect
> ```
>
> led to:
>
> ```
> $ git bisect log
> # bad: [84a1ff2d5cb7bf49fa3171dd92f7ac088e837185] [MNG-7063] Add unittest to ensure rereading a pom won't return the cached Model
> …
> # first bad commit: [619973b91cff5af7b5695bda11761a982a159349] [MNG-7063] Infinite loop using Shade plugin and JUnit 5 dependency
> ```
>
> Best Regards
> Mirko
>
>
>> Am 23.02.2021 um 10:21 schrieb Michael Osipov :
>>
>> Am 2021-02-23 um 10:16 schrieb Mirko Friedenhagen:
>>> Hello Michal, hello Robert,
>>> Thanks for the answers.
>>> I am trying to reproduce this with a smaller project, but it is quite hard. The problem occurs with an inhouse project where we use inhouse plugins etc. We manage the lifecycle of standard packagings as well in the the extension. I wrote a FOSS derivate (not widely use) and will try to give a small example.
>>> Robert, did you mean to bisect the maven-core?
>>
>> Yes, he did. This is what I would do.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: Different plugin classpath in Maven 3.6.3 and 4.0.0?
Posted by Mirko Friedenhagen <mf...@gmx.de>.
And now I was able to reproduce this:
https://github.com/mfriedenhagen/plugin-classpath-maven-3-and-4 <https://github.com/mfriedenhagen/plugin-classpath-maven-3-and-4>
mvn clean verify succeeds with 3.6.3 and breaks with 619973b91cff5af7b5695bda11761a982a159349 ff.
> Am 23.02.2021 um 14:42 schrieb Mirko Friedenhagen <mf...@gmx.de>:
>
> Not that deep in bisecting as of now. I wrote a small script `bisect`:
>
> ```
> #!/bin/bash -e -p
> mvn -q -B -s ~/.m2/settings-oss.xml clean package -Dmaven.test.skip=true -Denforcer.skip=true -Drat.skip=true
> bin_tar_gz=apache-maven/target/apache-maven-[3,4]*-bin.tar.gz
> test -f $bin_tar_gz
> gunzip -dc $bin_tar_gz | (cd /tmp/ && rm -rf apache-maven-*-SNAPSHOT && tar x)
> cd $HOME/ghq/gitlab.example.com/group/failing-project
> /tmp/apache-maven-*-SNAPSHOT/bin/mvn -B -V -q clean verify -DskipTests
> ```
>
> Running:
> ```
> $ git bisect start 84a1ff2d5cb7bf49fa3171dd92f7ac088e837185 maven-3.6.3
> $ git bisect run ./bisect
> ```
>
> led to:
>
> ```
> $ git bisect log
> # bad: [84a1ff2d5cb7bf49fa3171dd92f7ac088e837185] [MNG-7063] Add unittest to ensure rereading a pom won't return the cached Model
> …
> # first bad commit: [619973b91cff5af7b5695bda11761a982a159349] [MNG-7063] Infinite loop using Shade plugin and JUnit 5 dependency
> ```
>
> Best Regards
> Mirko
>
>
>> Am 23.02.2021 um 10:21 schrieb Michael Osipov <mi...@apache.org>:
>>
>> Am 2021-02-23 um 10:16 schrieb Mirko Friedenhagen:
>>> Hello Michal, hello Robert,
>>> Thanks for the answers.
>>> I am trying to reproduce this with a smaller project, but it is quite hard. The problem occurs with an inhouse project where we use inhouse plugins etc. We manage the lifecycle of standard packagings as well in the the extension. I wrote a FOSS derivate (not widely use) and will try to give a small example.
>>> Robert, did you mean to bisect the maven-core?
>>
>> Yes, he did. This is what I would do.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: Different plugin classpath in Maven 3.6.3 and 4.0.0?
Posted by Mirko Friedenhagen <mf...@gmx.de>.
Not that deep in bisecting as of now. I wrote a small script `bisect`:
```
#!/bin/bash -e -p
mvn -q -B -s ~/.m2/settings-oss.xml clean package -Dmaven.test.skip=true -Denforcer.skip=true -Drat.skip=true
bin_tar_gz=apache-maven/target/apache-maven-[3,4]*-bin.tar.gz
test -f $bin_tar_gz
gunzip -dc $bin_tar_gz | (cd /tmp/ && rm -rf apache-maven-*-SNAPSHOT && tar x)
cd $HOME/ghq/gitlab.example.com/group/failing-project
/tmp/apache-maven-*-SNAPSHOT/bin/mvn -B -V -q clean verify -DskipTests
```
Running:
```
$ git bisect start 84a1ff2d5cb7bf49fa3171dd92f7ac088e837185 maven-3.6.3
$ git bisect run ./bisect
```
led to:
```
$ git bisect log
# bad: [84a1ff2d5cb7bf49fa3171dd92f7ac088e837185] [MNG-7063] Add unittest to ensure rereading a pom won't return the cached Model
…
# first bad commit: [619973b91cff5af7b5695bda11761a982a159349] [MNG-7063] Infinite loop using Shade plugin and JUnit 5 dependency
```
Best Regards
Mirko
> Am 23.02.2021 um 10:21 schrieb Michael Osipov <mi...@apache.org>:
>
> Am 2021-02-23 um 10:16 schrieb Mirko Friedenhagen:
>> Hello Michal, hello Robert,
>> Thanks for the answers.
>> I am trying to reproduce this with a smaller project, but it is quite hard. The problem occurs with an inhouse project where we use inhouse plugins etc. We manage the lifecycle of standard packagings as well in the the extension. I wrote a FOSS derivate (not widely use) and will try to give a small example.
>> Robert, did you mean to bisect the maven-core?
>
> Yes, he did. This is what I would do.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Different plugin classpath in Maven 3.6.3 and 4.0.0?
Posted by Michael Osipov <mi...@apache.org>.
Am 2021-02-23 um 10:16 schrieb Mirko Friedenhagen:
> Hello Michal, hello Robert,
>
> Thanks for the answers.
>
> I am trying to reproduce this with a smaller project, but it is quite hard. The problem occurs with an inhouse project where we use inhouse plugins etc. We manage the lifecycle of standard packagings as well in the the extension. I wrote a FOSS derivate (not widely use) and will try to give a small example.
>
> Robert, did you mean to bisect the maven-core?
Yes, he did. This is what I would do.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Different plugin classpath in Maven 3.6.3 and 4.0.0?
Posted by Mirko Friedenhagen <mf...@gmx.de>.
Hello Michal, hello Robert,
Thanks for the answers.
I am trying to reproduce this with a smaller project, but it is quite hard. The problem occurs with an inhouse project where we use inhouse plugins etc. We manage the lifecycle of standard packagings as well in the the extension. I wrote a FOSS derivate (not widely use) and will try to give a small example.
Robert, did you mean to bisect the maven-core?
Best Regards
Mirko
Robert wrote:
> Hard to say: can you do a git bi-sect to discover the commit that changed the behavior. Then we can see discuss if this change is intended or not.
> Am 21.02.2021 um 10:31 schrieb Michael Osipov <mi...@apache.org>:
>
> Am 2021-02-19 um 18:52 schrieb Mirko Friedenhagen:
>> Hello,
>> * I now gave Apache Maven 4.0.0-alpha-1-SNAPSHOT (84a1ff2d5cb7bf49fa3171dd92f7ac088e837185) a try.
>> * In my POM I configured the net.rumati.maven.plugins:velocity-maven-plugin which should render a HTML file.
>> * The parent of the project has a global extension in the build section.
>> * The jar of the extension does include a velocity which is picked up quite fine by the velocity-maven-plugin from
>> the classpath by 3.6.3 but when using 4.0.0 I now need to add the extension jar as a dependency to the plugin.
>> Is this an intended behavior?
>
> Can you reduce to a sample project?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Different plugin classpath in Maven 3.6.3 and 4.0.0?
Posted by Michael Osipov <mi...@apache.org>.
Am 2021-02-19 um 18:52 schrieb Mirko Friedenhagen:
> Hello,
>
> * I now gave Apache Maven 4.0.0-alpha-1-SNAPSHOT (84a1ff2d5cb7bf49fa3171dd92f7ac088e837185) a try.
> * In my POM I configured the net.rumati.maven.plugins:velocity-maven-plugin which should render a HTML file.
> * The parent of the project has a global extension in the build section.
> * The jar of the extension does include a velocity which is picked up quite fine by the velocity-maven-plugin from
> the classpath by 3.6.3 but when using 4.0.0 I now need to add the extension jar as a dependency to the plugin.
>
>
> Is this an intended behavior?
Can you reduce to a sample project?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Different plugin classpath in Maven 3.6.3 and 4.0.0?
Posted by Robert Scholte <rf...@apache.org>.
Hard to say: can you do a git bi-sect to discover the commit that changed the behavior. Then we can see discuss if this change is intended or not.
Robert
On 19-2-2021 18:52:24, Mirko Friedenhagen <mf...@gmx.de> wrote:
Hello,
* I now gave Apache Maven 4.0.0-alpha-1-SNAPSHOT (84a1ff2d5cb7bf49fa3171dd92f7ac088e837185) a try.
* In my POM I configured the net.rumati.maven.plugins:velocity-maven-plugin which should render a HTML file.
* The parent of the project has a global extension in the build section.
* The jar of the extension does include a velocity which is picked up quite fine by the velocity-maven-plugin from
the classpath by 3.6.3 but when using 4.0.0 I now need to add the extension jar as a dependency to the plugin.
Is this an intended behavior?
Best Regards
Mirko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org