[jira] [Commented] (MCHECKSTYLE-440) how to reuse the checkstyle cache from a new environment
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752292#comment-17752292 ] Michael Osipov commented on MCHECKSTYLE-440: I don't exactly know whether it is us or the actual component. Do you want to try with the Checkstyle team first? > how to reuse the checkstyle cache from a new environment > > > Key: MCHECKSTYLE-440 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-440 > Project: Maven Checkstyle Plugin > Issue Type: Task > Components: checkstyle:check >Affects Versions: 3.3.0 >Reporter: Nianjun Sun >Priority: Major > > Hi, dear Checkstyle plugin team, > > This is Nianjun from the Apache/ShardingSphere team. Recently, we added the > checkstyle:check as required check in our GitHub action. This action is > triggered by every single pull request and checks the Java code style for all > modules. > > I noticed that running checkstyle:check takes almost 1 minute to check nearly > 300 modules.this takes too much time for the reviewer to merge the code. I > know that Checkstyle generates a cache file called 'checkstyle-cachefile' in > the target folder. So, I tried caching all 'checkstyle-cachefile' files in > the target folder by > actions/cache@v3 for the next GitHub action run. > However, this approach didn't work and I'm not sure how the Checkstyle cache > works... > > Interestingly, when I execute the command `mvn checkstyle:check > -Dcheckstyle.skip=false -T1C` twice in our GitHub action, it only takes 15 > seconds on the second run. This makes me think that the cache file is working. > > I also tried downloading these 'checkstyle-cachefile' files from GitHub's > cache and putting them in each module's target folder, but it still takes 1 > minute to complete. > > I'm not sure if 'checkstyle-cachefile' has an expiration period or if it > depends on some environment information or something else entirely. Could you > please provide some tips or give me a brief description of how > 'checkstyle-cachefile' works? > > Thank you! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCHECKSTYLE-440) how to reuse the checkstyle cache from a new environment
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752295#comment-17752295 ] Nianjun Sun commented on MCHECKSTYLE-440: - Hi, Michael. I already try to rised up a post in Checkstyle GitHub discussion. After read some checkstyle source codes briefly, I think checkstyle team may understand how that cache works. thanks Michael. this ticket should be closed. > how to reuse the checkstyle cache from a new environment > > > Key: MCHECKSTYLE-440 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-440 > Project: Maven Checkstyle Plugin > Issue Type: Task > Components: checkstyle:check >Affects Versions: 3.3.0 >Reporter: Nianjun Sun >Priority: Major > > Hi, dear Checkstyle plugin team, > > This is Nianjun from the Apache/ShardingSphere team. Recently, we added the > checkstyle:check as required check in our GitHub action. This action is > triggered by every single pull request and checks the Java code style for all > modules. > > I noticed that running checkstyle:check takes almost 1 minute to check nearly > 300 modules.this takes too much time for the reviewer to merge the code. I > know that Checkstyle generates a cache file called 'checkstyle-cachefile' in > the target folder. So, I tried caching all 'checkstyle-cachefile' files in > the target folder by > actions/cache@v3 for the next GitHub action run. > However, this approach didn't work and I'm not sure how the Checkstyle cache > works... > > Interestingly, when I execute the command `mvn checkstyle:check > -Dcheckstyle.skip=false -T1C` twice in our GitHub action, it only takes 15 > seconds on the second run. This makes me think that the cache file is working. > > I also tried downloading these 'checkstyle-cachefile' files from GitHub's > cache and putting them in each module's target folder, but it still takes 1 > minute to complete. > > I'm not sure if 'checkstyle-cachefile' has an expiration period or if it > depends on some environment information or something else entirely. Could you > please provide some tips or give me a brief description of how > 'checkstyle-cachefile' works? > > Thank you! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MCHECKSTYLE-440) how to reuse the checkstyle cache from a new environment
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MCHECKSTYLE-440. -- Resolution: Information Provided > how to reuse the checkstyle cache from a new environment > > > Key: MCHECKSTYLE-440 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-440 > Project: Maven Checkstyle Plugin > Issue Type: Task > Components: checkstyle:check >Affects Versions: 3.3.0 >Reporter: Nianjun Sun >Priority: Major > > Hi, dear Checkstyle plugin team, > > This is Nianjun from the Apache/ShardingSphere team. Recently, we added the > checkstyle:check as required check in our GitHub action. This action is > triggered by every single pull request and checks the Java code style for all > modules. > > I noticed that running checkstyle:check takes almost 1 minute to check nearly > 300 modules.this takes too much time for the reviewer to merge the code. I > know that Checkstyle generates a cache file called 'checkstyle-cachefile' in > the target folder. So, I tried caching all 'checkstyle-cachefile' files in > the target folder by > actions/cache@v3 for the next GitHub action run. > However, this approach didn't work and I'm not sure how the Checkstyle cache > works... > > Interestingly, when I execute the command `mvn checkstyle:check > -Dcheckstyle.skip=false -T1C` twice in our GitHub action, it only takes 15 > seconds on the second run. This makes me think that the cache file is working. > > I also tried downloading these 'checkstyle-cachefile' files from GitHub's > cache and putting them in each module's target folder, but it still takes 1 > minute to complete. > > I'm not sure if 'checkstyle-cachefile' has an expiration period or if it > depends on some environment information or something else entirely. Could you > please provide some tips or give me a brief description of how > 'checkstyle-cachefile' works? > > Thank you! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGINTESTING-45) Use of MojoRule causes Guice injection error
[
https://issues.apache.org/jira/browse/MPLUGINTESTING-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752386#comment-17752386
]
Richard Eckart de Castilho commented on MPLUGINTESTING-45:
--
Upgrading to maven-plugin-testing-harness version 3.3.0 fixed the issue for me.
> Use of MojoRule causes Guice injection error
>
>
> Key: MPLUGINTESTING-45
> URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-45
> Project: Maven Plugin Testing
> Issue Type: Bug
>Reporter: Samuel James Corbett
>Priority: Major
>
> I'm trying to write some tests for a plugin. I am using:
> * Maven version 3.2.3
> * maven-plugin-testing-harness version 3.2.0
> * JUnit version 4.12
> I'm following the instructions at
> http://maven.apache.org/plugin-testing/maven-plugin-testing-harness/getting-started/index.html
> that may or may not be out of date.
> Any use of the {{MojoRule}} class causes all tests to fail with a Guice
> injection error.
> For example, this useless class:
> {code}
> package io.brooklyn.maven;
> import org.apache.maven.plugin.testing.MojoRule;
> import org.junit.Rule;
> import org.junit.Test;
> public class FakeTest {
> @Rule
> public MojoRule mojoRule = new MojoRule() {
> @Override
> protected void after() {
> super.after();
> }
> @Override
> protected void before() throws Throwable {
> super.before();
> }
> };
> @Test
> public void testNothing() {
> }
> }
> {code}
> fails with:
> {code}
> Running io.brooklyn.maven.FakeTest
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.04 sec <<<
> FAILURE!
> testNothing(io.brooklyn.maven.FakeTest) Time elapsed: 0.934 sec <<< ERROR!
> com.google.inject.CreationException: Unable to create injector, see the
> following errors:
> 1) Scope org.apache.maven.execution.scope.internal.MojoExecutionScope@eac4a5f
> is already bound to org.apache.maven.execution.scope.MojoExecutionScoped at
> org.apache.maven.plugin.
> testing.AbstractMojoTestCase$1.configure(AbstractMojoTestCase.java:236) (via
> modules: org.eclipse.sisu.wire.WireModule ->
> org.codehaus.plexus.DefaultPlexusContainer$BootModule ->
> org.apache.maven.plugin.testing.AbstractMojoTestCase$1).
> Cannot bind
> org.apache.maven.execution.scope.internal.MojoExecutionScope@5146aa7f.
> at ClassRealm[plexus.core, parent: null] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule ->
> org.apache.maven.execution.scope.inter
> nal.MojoExecutionScopeCoreModule)
> 1 error
> at
> com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:448)
> at
> com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:155)
> at
> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107)
> at com.google.inject.Guice.createInjector(Guice.java:96)
> at com.google.inject.Guice.createInjector(Guice.java:73)
> at com.google.inject.Guice.createInjector(Guice.java:62)
> at
> org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector(DefaultPlexusContainer.java:481)
> at
> org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:206)
> at
> org.apache.maven.plugin.testing.AbstractMojoTestCase.setupContainer(AbstractMojoTestCase.java:243)
> at
> org.apache.maven.plugin.testing.AbstractMojoTestCase.getContainer(AbstractMojoTestCase.java:277)
> at
> org.apache.maven.plugin.testing.AbstractMojoTestCase.setUp(AbstractMojoTestCase.java:118)
> at
> org.apache.maven.plugin.testing.MojoRule$2.evaluate(MojoRule.java:304)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUn
[jira] [Created] (MSHADE-454) Shade Plugin does not work with JDK 20
Patrick Barry created MSHADE-454: Summary: Shade Plugin does not work with JDK 20 Key: MSHADE-454 URL: https://issues.apache.org/jira/browse/MSHADE-454 Project: Maven Shade Plugin Issue Type: Bug Affects Versions: 3.5.0 Reporter: Patrick Barry We have been getting ready to use Virtual Threads while using JDK 20 and this was the only plugin we had to work-around because it would not work. Are there plans to update this plugin to support JDK 20+? Is there a work-around until changes are made? Our current work-around is using assembly plugin, but we use shade plugin in many of the apps we are migrating and our preference is to continue to use Shade-plugin. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHADE-455) Shade Plugin does not work with JDK 20
Patrick Barry created MSHADE-455: Summary: Shade Plugin does not work with JDK 20 Key: MSHADE-455 URL: https://issues.apache.org/jira/browse/MSHADE-455 Project: Maven Shade Plugin Issue Type: Bug Affects Versions: 3.5.0 Reporter: Patrick Barry We have been getting ready to use Virtual Threads while using JDK 20 and this was the only plugin we had to work-around because it would not work. Are there plans to update this plugin to support JDK 20+? Is there a work-around until changes are made? Our current work-around is using assembly plugin, but we use shade plugin in many of the apps we are migrating and our preference is to continue to use Shade-plugin. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Deleted] (MSHADE-455) Shade Plugin does not work with JDK 20
[ https://issues.apache.org/jira/browse/MSHADE-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov deleted MSHADE-455: -- > Shade Plugin does not work with JDK 20 > -- > > Key: MSHADE-455 > URL: https://issues.apache.org/jira/browse/MSHADE-455 > Project: Maven Shade Plugin > Issue Type: Bug >Reporter: Patrick Barry >Priority: Major > > We have been getting ready to use Virtual Threads while using JDK 20 and this > was the only plugin we had to work-around because it would not work. Are > there plans to update this plugin to support JDK 20+? Is there a work-around > until changes are made? > > Our current work-around is using assembly plugin, but we use shade plugin in > many of the apps we are migrating and our preference is to continue to use > Shade-plugin. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHADE-454) Shade Plugin does not work with JDK 20
[ https://issues.apache.org/jira/browse/MSHADE-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752422#comment-17752422 ] Michael Osipov commented on MSHADE-454: --- How does this one relate to virtual threads? > Shade Plugin does not work with JDK 20 > -- > > Key: MSHADE-454 > URL: https://issues.apache.org/jira/browse/MSHADE-454 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Patrick Barry >Priority: Major > > We have been getting ready to use Virtual Threads while using JDK 20 and this > was the only plugin we had to work-around because it would not work. Are > there plans to update this plugin to support JDK 20+? Is there a work-around > until changes are made? > > Our current work-around is using assembly plugin, but we use shade plugin in > many of the apps we are migrating and our preference is to continue to use > Shade-plugin. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHADE-454) Shade Plugin does not work with JDK 20
[ https://issues.apache.org/jira/browse/MSHADE-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752443#comment-17752443 ] Patrick Barry commented on MSHADE-454: -- It relates to jdk 20. Virtual threads is simply a feature in that jdk we are very interested in. On Wed, Aug 9, 2023 at 10:14 AM Michael Osipov (Jira) > Shade Plugin does not work with JDK 20 > -- > > Key: MSHADE-454 > URL: https://issues.apache.org/jira/browse/MSHADE-454 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Patrick Barry >Priority: Major > > We have been getting ready to use Virtual Threads while using JDK 20 and this > was the only plugin we had to work-around because it would not work. Are > there plans to update this plugin to support JDK 20+? Is there a work-around > until changes are made? > > Our current work-around is using assembly plugin, but we use shade plugin in > many of the apps we are migrating and our preference is to continue to use > Shade-plugin. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHADE-454) Shade Plugin does not work with JDK 20
[ https://issues.apache.org/jira/browse/MSHADE-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752457#comment-17752457 ] Michael Osipov commented on MSHADE-454: --- How does this answer the question? > Shade Plugin does not work with JDK 20 > -- > > Key: MSHADE-454 > URL: https://issues.apache.org/jira/browse/MSHADE-454 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Patrick Barry >Priority: Major > > We have been getting ready to use Virtual Threads while using JDK 20 and this > was the only plugin we had to work-around because it would not work. Are > there plans to update this plugin to support JDK 20+? Is there a work-around > until changes are made? > > Our current work-around is using assembly plugin, but we use shade plugin in > many of the apps we are migrating and our preference is to continue to use > Shade-plugin. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] kun-lu20 opened a new pull request, #1216: [MNG-7848] Remove `Configure deploy` stage from s390x pipeline
kun-lu20 opened a new pull request, #1216: URL: https://github.com/apache/maven/pull/1216 This PR aims to address the issue in this [comment](https://github.com/apache/maven/pull/1207#discussion_r1285167844) by removing `Configure deploy` stage from s390x pipeline. - Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. - [x] Also format the first line of the commit message like `[MNG-XXX] SUMMARY`. Best practice is to use the JIRA issue title in both the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7848) Add s390x pipeline to Jenkins CI
[ https://issues.apache.org/jira/browse/MNG-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752460#comment-17752460 ] ASF GitHub Bot commented on MNG-7848: - kun-lu20 opened a new pull request, #1216: URL: https://github.com/apache/maven/pull/1216 This PR aims to address the issue in this [comment](https://github.com/apache/maven/pull/1207#discussion_r1285167844) by removing `Configure deploy` stage from s390x pipeline. - Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. - [x] Also format the first line of the commit message like `[MNG-XXX] SUMMARY`. Best practice is to use the JIRA issue title in both the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ > Add s390x pipeline to Jenkins CI > > > Key: MNG-7848 > URL: https://issues.apache.org/jira/browse/MNG-7848 > Project: Maven > Issue Type: New Feature > Components: Bootstrap & Build, Integration Tests >Reporter: Kun Lu >Priority: Major > Labels: pull-request-available > > Apache INFRA team has installed necessary JDK flavours on all s390x nodes > (Please check issue > [https://issues.apache.org/jira/projects/INFRA/issues/INFRA-24781]). We’d > like to add the s390x pipeline to Jenkins CI by raising a PR to add ` > Jenkinsfile.s390x` to the Maven code base. > Can anyone from Maven team help us review the PR and create the s390x > pipeline on Jenkins? Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] kun-lu20 commented on pull request #1216: [MNG-7848] Remove `Configure deploy` stage from s390x pipeline
kun-lu20 commented on PR #1216: URL: https://github.com/apache/maven/pull/1216#issuecomment-1671720478 Hi @olamy , Could you please review this PR when you have a chance? Thank you very much! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7848) Add s390x pipeline to Jenkins CI
[ https://issues.apache.org/jira/browse/MNG-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752461#comment-17752461 ] ASF GitHub Bot commented on MNG-7848: - kun-lu20 commented on PR #1216: URL: https://github.com/apache/maven/pull/1216#issuecomment-1671720478 Hi @olamy , Could you please review this PR when you have a chance? Thank you very much! > Add s390x pipeline to Jenkins CI > > > Key: MNG-7848 > URL: https://issues.apache.org/jira/browse/MNG-7848 > Project: Maven > Issue Type: New Feature > Components: Bootstrap & Build, Integration Tests >Reporter: Kun Lu >Priority: Major > Labels: pull-request-available > > Apache INFRA team has installed necessary JDK flavours on all s390x nodes > (Please check issue > [https://issues.apache.org/jira/projects/INFRA/issues/INFRA-24781]). We’d > like to add the s390x pipeline to Jenkins CI by raising a PR to add ` > Jenkinsfile.s390x` to the Maven code base. > Can anyone from Maven team help us review the PR and create the s390x > pipeline on Jenkins? Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHADE-454) Shade Plugin does not work with JDK 20
[ https://issues.apache.org/jira/browse/MSHADE-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Barry updated MSHADE-454: - Description: We are trying to use JDK 20 and this was the only plugin we had to work-around because it would not work. Are there plans to update this plugin to support JDK 20+? Is there a work-around until changes are made? Our current work-around is using assembly plugin, but we use shade plugin in many of the apps we are migrating and our preference is to continue to use Shade-plugin. was: We have been getting ready to use Virtual Threads while using JDK 20 and this was the only plugin we had to work-around because it would not work. Are there plans to update this plugin to support JDK 20+? Is there a work-around until changes are made? Our current work-around is using assembly plugin, but we use shade plugin in many of the apps we are migrating and our preference is to continue to use Shade-plugin. > Shade Plugin does not work with JDK 20 > -- > > Key: MSHADE-454 > URL: https://issues.apache.org/jira/browse/MSHADE-454 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Patrick Barry >Priority: Major > > We are trying to use JDK 20 and this was the only plugin we had to > work-around because it would not work. Are there plans to update this plugin > to support JDK 20+? Is there a work-around until changes are made? > > Our current work-around is using assembly plugin, but we use shade plugin in > many of the apps we are migrating and our preference is to continue to use > Shade-plugin. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHADE-454) Shade Plugin does not work with JDK 20
[ https://issues.apache.org/jira/browse/MSHADE-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752491#comment-17752491 ] Patrick Barry commented on MSHADE-454: -- [~michael-o] The ticket asks if there are plans to support jdk20 and if there is currently a work-around to make it work before a permanent fix is provided. I am sorry I mentioned the feature in jdk 20 that we are trying to use, because I think it confused our intention. I have updated description with the problem. > Shade Plugin does not work with JDK 20 > -- > > Key: MSHADE-454 > URL: https://issues.apache.org/jira/browse/MSHADE-454 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Patrick Barry >Priority: Major > > We are trying to use JDK 20 and this was the only plugin we had to > work-around because it would not work. Are there plans to update this plugin > to support JDK 20+? Is there a work-around until changes are made? > > Our current work-around is using assembly plugin, but we use shade plugin in > many of the apps we are migrating and our preference is to continue to use > Shade-plugin. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHADE-454) Shade Plugin does not work with JDK 20
[ https://issues.apache.org/jira/browse/MSHADE-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Barry updated MSHADE-454: - Description: We are trying to use JDK 20 and this was the only plugin we had to work-around because it would not work. Are there plans to update this plugin to support JDK 20+? Is there a work-around until changes are made? Our current work-around is using assembly plugin, but we use shade plugin in many of the apps we are migrating and our preference is to continue to use Shade-plugin. Currently- if you try to use shade plugin with JDK 20, you get : Unsupported class file major version 64 was: We are trying to use JDK 20 and this was the only plugin we had to work-around because it would not work. Are there plans to update this plugin to support JDK 20+? Is there a work-around until changes are made? Our current work-around is using assembly plugin, but we use shade plugin in many of the apps we are migrating and our preference is to continue to use Shade-plugin. > Shade Plugin does not work with JDK 20 > -- > > Key: MSHADE-454 > URL: https://issues.apache.org/jira/browse/MSHADE-454 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Patrick Barry >Priority: Major > > We are trying to use JDK 20 and this was the only plugin we had to > work-around because it would not work. Are there plans to update this plugin > to support JDK 20+? Is there a work-around until changes are made? > > Our current work-around is using assembly plugin, but we use shade plugin in > many of the apps we are migrating and our preference is to continue to use > Shade-plugin. > Currently- if you try to use shade plugin with JDK 20, you get : Unsupported > class file major version 64 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHADE-454) Shade Plugin does not work with JDK 20
[
https://issues.apache.org/jira/browse/MSHADE-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Barry updated MSHADE-454:
-
Description:
We are trying to use JDK 20 and this was the only plugin we had to work-around
because it would not work. Are there plans to update this plugin to support
JDK 20+? Is there a work-around until changes are made?
Our current work-around is using assembly plugin, but we use shade plugin in
many of the apps we are migrating and our preference is to continue to use
Shade-plugin.
Currently- if you try to use shade plugin with JDK 20, you get : Unsupported
class file major version 64
{noformat}
Error creating shaded jar: Unsupported class file major version 64
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:333)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:316)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:212)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:174)
at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
(MojoExecutor.java:75)
at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
(MojoExecutor.java:162)
at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
(DefaultMojosExecutionStrategy.java:39)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:159)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:105)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:73)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:53)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:118)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
(DirectMethodHandleAccessor.java:104)
at java.lang.reflect.Method.invoke (Method.java:578)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:283)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:226)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:407)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:348)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating
shaded jar: Unsupported class file major version 64
at org.apache.maven.plugins.shade.mojo.ShadeMojo.execute
(ShadeMojo.java:624)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:126)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:328)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:316)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:212)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:174)
at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
(MojoExecutor.java:75)
at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
(MojoExecutor.java:162)
at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
(DefaultMojosExecutionStrategy.java:39)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:159)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:105)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:73)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:53)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:118)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
(DirectMethodHandleAccessor.java:104)
at java.lang.reflect.Method.invoke (Method.java:578)
at org.codehaus.plexus.classwo
[GitHub] [maven-dependency-plugin] jshbrntt commented on pull request #135: [MDEP-568] go offline filter
jshbrntt commented on PR #135: URL: https://github.com/apache/maven-dependency-plugin/pull/135#issuecomment-1672139836 Is this going to be merged anytime soon? It would be really helpful to install and cache dependencies prior to `mvn package`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MDEP-568) dependency:go-offline -DexcludeGroupIds=xxxx still try to resolve artifacts in the excluded group xxxx
[ https://issues.apache.org/jira/browse/MDEP-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752517#comment-17752517 ] ASF GitHub Bot commented on MDEP-568: - jshbrntt commented on PR #135: URL: https://github.com/apache/maven-dependency-plugin/pull/135#issuecomment-1672139836 Is this going to be merged anytime soon? It would be really helpful to install and cache dependencies prior to `mvn package`. > dependency:go-offline -DexcludeGroupIds= still try to resolve artifacts > in the excluded group > -- > > Key: MDEP-568 > URL: https://issues.apache.org/jira/browse/MDEP-568 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: go-offline, resolve >Affects Versions: 2.3, 3.0.0 > Environment: windows / cygwin xp64 bit / bash / maven 3.0.3 >Reporter: Archimedes Trajano >Priority: Major > Attachments: MDEP-568-maven-dependency-plugin.patch, > go-offline_copy-dependencies_patch_sample.zip, test.tgz > > > see thread: > http://mail-archives.apache.org/mod_mbox/maven-users/201109.mbox/%3c0B02C46601D44673A4A2DF4C4F907E9E@black%3e > in attached sample pom structure: > mvn org.apache.maven.plugins:maven-dependency-plugin:2.3:go-offline > -DexcludeGroupIds=us.pdinc.foo.maven.test > fails -- This message was sent by Atlassian Jira (v8.20.10#820010)
