Re: Different plugin classpath in Maven 3.6.3 and 4.0.0?

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

Re: Different plugin classpath in Maven 3.6.3 and 4.0.0?

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


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

Reply | Threaded
Open this post in threaded view
|

Re: Different plugin classpath in Maven 3.6.3 and 4.0.0?

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

Reply | Threaded
Open this post in threaded view
|

Re: Different plugin classpath in Maven 3.6.3 and 4.0.0?

Mirko Friedenhagen-5
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 <[hidden email]>:
>
> 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 <[hidden email]>:
>>
>> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>