Re: [VOTE] Release Apache Maven 4.0.0-alpha-2
Hi. I noticed the vote passed for alpha-2, but I'm still getting this issue. Can someone comment? Is the flatten plugin still relevant in Maven 4? Thanks, Delany On Thu, 20 Oct 2022 at 09:26, Delany wrote: > hi. I just changed .mvn/wrapper/maven-wrapper.properties to > distributionUrl= > https://repository.apache.org/service/local/repositories/maven-1811/content/org/apache/maven/apache-maven/4.0.0-alpha-2/apache-maven-4.0.0-alpha-2-bin.zip > > The options now require an equals: --threads=1C, but the help page still > shows a space: -T,--threads > > After fixing that it fails with > [ERROR] Failed to execute goal > org.codehaus.mojo:flatten-maven-plugin:1.3.0:flatten (flatten) on project > maven-super: Execution flatten of goal > org.codehaus.mojo:flatten-maven-plugin:1.3.0:flatten failed: An API > incompatibility was encountered while executing > org.codehaus.mojo:flatten-maven-plugin:1.3.0:flatten: > java.lang.NoSuchMethodError: 'void > org.apache.maven.model.interpolation.MavenBuildTimestamp.(java.util.Date, > java.util.Properties)' > [ERROR] - > [ERROR] realm =plugin>org.codehaus.mojo:flatten-maven-plugin:1.3.0 > [ERROR] strategy = > org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy > [ERROR] urls[0] = > file:/home/sol/.m2/repository/org/codehaus/mojo/flatten-maven-plugin/1.3.0/flatten-maven-plugin-1.3.0.jar > [ERROR] urls[1] = > file:/home/sol/.m2/repository/org/apache/maven/shared/maven-dependency-tree/3.2.0/maven-dependency-tree-3.2.0.jar > [ERROR] urls[2] = > file:/home/sol/.m2/repository/org/codehaus/plexus/plexus-utils/3.4.2/plexus-utils-3.4.2.jar > [ERROR] urls[3] = > file:/home/sol/.m2/repository/org/apache/maven/shared/maven-artifact-transfer/0.13.1/maven-artifact-transfer-0.13.1.jar > [ERROR] urls[4] = > file:/home/sol/.m2/repository/javax/enterprise/cdi-api/1.0/cdi-api-1.0.jar > [ERROR] urls[5] = > file:/home/sol/.m2/repository/javax/annotation/jsr250-api/1.0/jsr250-api-1.0.jar > [ERROR] urls[6] = > file:/home/sol/.m2/repository/org/eclipse/sisu/org.eclipse.sisu.inject/0.3.0.M1/org.eclipse.sisu.inject-0.3.0.M1.jar > [ERROR] urls[7] = > file:/home/sol/.m2/repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar > [ERROR] urls[8] = > file:/home/sol/.m2/repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar > [ERROR] urls[9] = > file:/home/sol/.m2/repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar > [ERROR] urls[10] = > file:/home/sol/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar > [ERROR] urls[11] = > file:/home/sol/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar > [ERROR] urls[12] = > file:/home/sol/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar > [ERROR] urls[13] = > file:/home/sol/.m2/repository/org/codehaus/plexus/plexus-component-annotations/2.0.0/plexus-component-annotations-2.0.0.jar > [ERROR] urls[14] = > file:/home/sol/.m2/repository/org/apache/maven/shared/maven-common-artifact-filters/3.1.0/maven-common-artifact-filters-3.1.0.jar > [ERROR] urls[15] = > file:/home/sol/.m2/repository/org/apache/maven/shared/maven-shared-utils/3.1.0/maven-shared-utils-3.1.0.jar > [ERROR] urls[16] = > file:/home/sol/.m2/repository/commons-io/commons-io/2.11.0/commons-io-2.11.0.jar > [ERROR] Number of foreign imports: 1 > [ERROR] import: Entry[import from realm ClassRealm[maven.api, parent: > null]] > > Regards, > Delany > > On Sat, 15 Oct 2022 at 02:19, Guillaume Nodet wrote: > >> I've staged a release candidate at >> https://repository.apache.org/content/repositories/maven-1811 >> >> The binaries are available at: >> >> >> https://repository.apache.org/service/local/repositories/maven-1811/content/org/apache/maven/apache-maven/4.0.0-alpha-2/ >> >> The tag is available at: >> https://github.com/apache/maven/tree/maven-4.0.0-alpha-2 >> >> Please review and vote ! >> >> Cheers, >> Guillaume Nodet >> >
Re: Releases notes ... Jira, GitHub
You can find the list here https://docs.github.com/en/site-policy/other-site-policies/github-and-trade-controls On Tue, 8 Nov 2022 at 12:55 pm, Gary Gregory wrote: > What countries are those BTW? > > Gary > > On Mon, Nov 7, 2022, 21:52 Gary Gregory wrote: > > > > > > > On Mon, Nov 7, 2022, 20:05 Olivier Lamy wrote: > > > >> On Tue, 8 Nov 2022 at 10:59, Gary Gregory > wrote: > >> > > >> > FYI, and FWIW, Log4j is planning on switch from Jira to GitHub for > >> issues, > >> > and release notes: https://issues.apache.org/jira/browse/LOG4J2-3628 > >> > > >> > >> So you mean using ONLY gh for issues? > >> So by doing this, you will exclude people living in countries banned > >> from Github. > >> Is it acceptable from an Apache Foundation POV? > >> > > > > I don't know if this was considered. It must be an issue for other > > projects as well. > > > > Gary > > > > > >> argghhh only 2 answers and the thread is already forking 藍 > >> > >> > >> > Gary > >> > > >> > On Mon, Nov 7, 2022, 19:16 Olivier Lamy wrote: > >> > > >> > > well I just see GH release note as a cherry on the cake. > >> > > as long as the rest is done. > >> > > Just compare the result of generated dependabot PRs > >> > > no GH release notes > >> > > https://github.com/eclipse/jetty.project/pull/8853 > >> > > with GH release notes > >> > > https://github.com/eclipse/jetty.project/pull/7727 > >> > > I tend to find the second (e.g with GH release note auto generated) > >> > > more human readable and directly accessible (no need to go somewhere > >> > > else and there is even a link to the PR of the changelog entry). but > >> > > yeah maybe it's only me > >> > > > >> > > Regarding "each change must be done by PR", for some reasons we > can’t > >> > > really make it mandatory but let's be honest in real life everybody > >> > > does it :) > >> > > At the end, if release drafter is configured it's just one click, > and > >> > > if not it's 2 clicks or one command line if using github cli tool gh > >> > > > >> > > On a more general discussion, we are a very large project with > plenty > >> > > of sub projects (maintained by different people who are not > >> > > maintaining every project) and we can be happy having few people > >> > > maintaining those during their spare time. So not sure it's a very > >> > > good idea to have too strict policies/procedures especially when it > >> > > comes to adding a nice to have cherry on the top for users > >> > > Especially when the rest of our long procedure has been done. > >> > > > >> > > > >> > > > >> > > On Tue, 8 Nov 2022 at 09:00, Slawomir Jaranowski < > >> s.jaranow...@gmail.com> > >> > > wrote: > >> > > > > >> > > > Hi, > >> > > > I start a discussion ... as beginning - some my loose thoughts > >> > > > > >> > > > We use Jira (for most of) as our primary issues management system. > >> > > > We manage release notes in Jira - it is the source for > >> announcements. > >> > > > > >> > > > In some projects we have GitHub releases notes. > >> > > > In some cases we use release-drafter for preparing GitHub releases > >> notes. > >> > > > Some of release notes on GH - it is not actual > >> > > > > >> > > > Challenge: > >> > > > - make both release notes to have the same information > >> > > > - minimal additional manual work > >> > > > > >> > > > Release - drafter is fine, but > >> > > > - requires correct labeling on PR > >> > > > - eache change must be done by PR > >> > > > - each PR must be merged on GH with merged status > >> > > > - no additional issues > >> > > > > >> > > > > >> > > > -- > >> > > > Sławomir Jaranowski > >> > > > >> > > > - > >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> > > For additional commands, e-mail: dev-h...@maven.apache.org > >> > > > >> > > > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > >> >
Re: Releases notes ... Jira, GitHub
What countries are those BTW? Gary On Mon, Nov 7, 2022, 21:52 Gary Gregory wrote: > > > On Mon, Nov 7, 2022, 20:05 Olivier Lamy wrote: > >> On Tue, 8 Nov 2022 at 10:59, Gary Gregory wrote: >> > >> > FYI, and FWIW, Log4j is planning on switch from Jira to GitHub for >> issues, >> > and release notes: https://issues.apache.org/jira/browse/LOG4J2-3628 >> > >> >> So you mean using ONLY gh for issues? >> So by doing this, you will exclude people living in countries banned >> from Github. >> Is it acceptable from an Apache Foundation POV? >> > > I don't know if this was considered. It must be an issue for other > projects as well. > > Gary > > >> argghhh only 2 answers and the thread is already forking 藍 >> >> >> > Gary >> > >> > On Mon, Nov 7, 2022, 19:16 Olivier Lamy wrote: >> > >> > > well I just see GH release note as a cherry on the cake. >> > > as long as the rest is done. >> > > Just compare the result of generated dependabot PRs >> > > no GH release notes >> > > https://github.com/eclipse/jetty.project/pull/8853 >> > > with GH release notes >> > > https://github.com/eclipse/jetty.project/pull/7727 >> > > I tend to find the second (e.g with GH release note auto generated) >> > > more human readable and directly accessible (no need to go somewhere >> > > else and there is even a link to the PR of the changelog entry). but >> > > yeah maybe it's only me >> > > >> > > Regarding "each change must be done by PR", for some reasons we can’t >> > > really make it mandatory but let's be honest in real life everybody >> > > does it :) >> > > At the end, if release drafter is configured it's just one click, and >> > > if not it's 2 clicks or one command line if using github cli tool gh >> > > >> > > On a more general discussion, we are a very large project with plenty >> > > of sub projects (maintained by different people who are not >> > > maintaining every project) and we can be happy having few people >> > > maintaining those during their spare time. So not sure it's a very >> > > good idea to have too strict policies/procedures especially when it >> > > comes to adding a nice to have cherry on the top for users >> > > Especially when the rest of our long procedure has been done. >> > > >> > > >> > > >> > > On Tue, 8 Nov 2022 at 09:00, Slawomir Jaranowski < >> s.jaranow...@gmail.com> >> > > wrote: >> > > > >> > > > Hi, >> > > > I start a discussion ... as beginning - some my loose thoughts >> > > > >> > > > We use Jira (for most of) as our primary issues management system. >> > > > We manage release notes in Jira - it is the source for >> announcements. >> > > > >> > > > In some projects we have GitHub releases notes. >> > > > In some cases we use release-drafter for preparing GitHub releases >> notes. >> > > > Some of release notes on GH - it is not actual >> > > > >> > > > Challenge: >> > > > - make both release notes to have the same information >> > > > - minimal additional manual work >> > > > >> > > > Release - drafter is fine, but >> > > > - requires correct labeling on PR >> > > > - eache change must be done by PR >> > > > - each PR must be merged on GH with merged status >> > > > - no additional issues >> > > > >> > > > >> > > > -- >> > > > Sławomir Jaranowski >> > > >> > > - >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > > For additional commands, e-mail: dev-h...@maven.apache.org >> > > >> > > >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >>
Re: Releases notes ... Jira, GitHub
On Mon, Nov 7, 2022, 20:05 Olivier Lamy wrote: > On Tue, 8 Nov 2022 at 10:59, Gary Gregory wrote: > > > > FYI, and FWIW, Log4j is planning on switch from Jira to GitHub for > issues, > > and release notes: https://issues.apache.org/jira/browse/LOG4J2-3628 > > > > So you mean using ONLY gh for issues? > So by doing this, you will exclude people living in countries banned > from Github. > Is it acceptable from an Apache Foundation POV? > I don't know if this was considered. It must be an issue for other projects as well. Gary > argghhh only 2 answers and the thread is already forking 藍 > > > > Gary > > > > On Mon, Nov 7, 2022, 19:16 Olivier Lamy wrote: > > > > > well I just see GH release note as a cherry on the cake. > > > as long as the rest is done. > > > Just compare the result of generated dependabot PRs > > > no GH release notes > > > https://github.com/eclipse/jetty.project/pull/8853 > > > with GH release notes > > > https://github.com/eclipse/jetty.project/pull/7727 > > > I tend to find the second (e.g with GH release note auto generated) > > > more human readable and directly accessible (no need to go somewhere > > > else and there is even a link to the PR of the changelog entry). but > > > yeah maybe it's only me > > > > > > Regarding "each change must be done by PR", for some reasons we can’t > > > really make it mandatory but let's be honest in real life everybody > > > does it :) > > > At the end, if release drafter is configured it's just one click, and > > > if not it's 2 clicks or one command line if using github cli tool gh > > > > > > On a more general discussion, we are a very large project with plenty > > > of sub projects (maintained by different people who are not > > > maintaining every project) and we can be happy having few people > > > maintaining those during their spare time. So not sure it's a very > > > good idea to have too strict policies/procedures especially when it > > > comes to adding a nice to have cherry on the top for users > > > Especially when the rest of our long procedure has been done. > > > > > > > > > > > > On Tue, 8 Nov 2022 at 09:00, Slawomir Jaranowski < > s.jaranow...@gmail.com> > > > wrote: > > > > > > > > Hi, > > > > I start a discussion ... as beginning - some my loose thoughts > > > > > > > > We use Jira (for most of) as our primary issues management system. > > > > We manage release notes in Jira - it is the source for announcements. > > > > > > > > In some projects we have GitHub releases notes. > > > > In some cases we use release-drafter for preparing GitHub releases > notes. > > > > Some of release notes on GH - it is not actual > > > > > > > > Challenge: > > > > - make both release notes to have the same information > > > > - minimal additional manual work > > > > > > > > Release - drafter is fine, but > > > > - requires correct labeling on PR > > > > - eache change must be done by PR > > > > - each PR must be merged on GH with merged status > > > > - no additional issues > > > > > > > > > > > > -- > > > > Sławomir Jaranowski > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Releases notes ... Jira, GitHub
On Tue, 8 Nov 2022 at 10:59, Gary Gregory wrote: > > FYI, and FWIW, Log4j is planning on switch from Jira to GitHub for issues, > and release notes: https://issues.apache.org/jira/browse/LOG4J2-3628 > So you mean using ONLY gh for issues? So by doing this, you will exclude people living in countries banned from Github. Is it acceptable from an Apache Foundation POV? argghhh only 2 answers and the thread is already forking 藍 > Gary > > On Mon, Nov 7, 2022, 19:16 Olivier Lamy wrote: > > > well I just see GH release note as a cherry on the cake. > > as long as the rest is done. > > Just compare the result of generated dependabot PRs > > no GH release notes > > https://github.com/eclipse/jetty.project/pull/8853 > > with GH release notes > > https://github.com/eclipse/jetty.project/pull/7727 > > I tend to find the second (e.g with GH release note auto generated) > > more human readable and directly accessible (no need to go somewhere > > else and there is even a link to the PR of the changelog entry). but > > yeah maybe it's only me > > > > Regarding "each change must be done by PR", for some reasons we can’t > > really make it mandatory but let's be honest in real life everybody > > does it :) > > At the end, if release drafter is configured it's just one click, and > > if not it's 2 clicks or one command line if using github cli tool gh > > > > On a more general discussion, we are a very large project with plenty > > of sub projects (maintained by different people who are not > > maintaining every project) and we can be happy having few people > > maintaining those during their spare time. So not sure it's a very > > good idea to have too strict policies/procedures especially when it > > comes to adding a nice to have cherry on the top for users > > Especially when the rest of our long procedure has been done. > > > > > > > > On Tue, 8 Nov 2022 at 09:00, Slawomir Jaranowski > > wrote: > > > > > > Hi, > > > I start a discussion ... as beginning - some my loose thoughts > > > > > > We use Jira (for most of) as our primary issues management system. > > > We manage release notes in Jira - it is the source for announcements. > > > > > > In some projects we have GitHub releases notes. > > > In some cases we use release-drafter for preparing GitHub releases notes. > > > Some of release notes on GH - it is not actual > > > > > > Challenge: > > > - make both release notes to have the same information > > > - minimal additional manual work > > > > > > Release - drafter is fine, but > > > - requires correct labeling on PR > > > - eache change must be done by PR > > > - each PR must be merged on GH with merged status > > > - no additional issues > > > > > > > > > -- > > > Sławomir Jaranowski > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Releases notes ... Jira, GitHub
FYI, and FWIW, Log4j is planning on switch from Jira to GitHub for issues, and release notes: https://issues.apache.org/jira/browse/LOG4J2-3628 Gary On Mon, Nov 7, 2022, 19:16 Olivier Lamy wrote: > well I just see GH release note as a cherry on the cake. > as long as the rest is done. > Just compare the result of generated dependabot PRs > no GH release notes > https://github.com/eclipse/jetty.project/pull/8853 > with GH release notes > https://github.com/eclipse/jetty.project/pull/7727 > I tend to find the second (e.g with GH release note auto generated) > more human readable and directly accessible (no need to go somewhere > else and there is even a link to the PR of the changelog entry). but > yeah maybe it's only me > > Regarding "each change must be done by PR", for some reasons we can’t > really make it mandatory but let's be honest in real life everybody > does it :) > At the end, if release drafter is configured it's just one click, and > if not it's 2 clicks or one command line if using github cli tool gh > > On a more general discussion, we are a very large project with plenty > of sub projects (maintained by different people who are not > maintaining every project) and we can be happy having few people > maintaining those during their spare time. So not sure it's a very > good idea to have too strict policies/procedures especially when it > comes to adding a nice to have cherry on the top for users > Especially when the rest of our long procedure has been done. > > > > On Tue, 8 Nov 2022 at 09:00, Slawomir Jaranowski > wrote: > > > > Hi, > > I start a discussion ... as beginning - some my loose thoughts > > > > We use Jira (for most of) as our primary issues management system. > > We manage release notes in Jira - it is the source for announcements. > > > > In some projects we have GitHub releases notes. > > In some cases we use release-drafter for preparing GitHub releases notes. > > Some of release notes on GH - it is not actual > > > > Challenge: > > - make both release notes to have the same information > > - minimal additional manual work > > > > Release - drafter is fine, but > > - requires correct labeling on PR > > - eache change must be done by PR > > - each PR must be merged on GH with merged status > > - no additional issues > > > > > > -- > > Sławomir Jaranowski > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Releases notes ... Jira, GitHub
well I just see GH release note as a cherry on the cake. as long as the rest is done. Just compare the result of generated dependabot PRs no GH release notes https://github.com/eclipse/jetty.project/pull/8853 with GH release notes https://github.com/eclipse/jetty.project/pull/7727 I tend to find the second (e.g with GH release note auto generated) more human readable and directly accessible (no need to go somewhere else and there is even a link to the PR of the changelog entry). but yeah maybe it's only me Regarding "each change must be done by PR", for some reasons we can’t really make it mandatory but let's be honest in real life everybody does it :) At the end, if release drafter is configured it's just one click, and if not it's 2 clicks or one command line if using github cli tool gh On a more general discussion, we are a very large project with plenty of sub projects (maintained by different people who are not maintaining every project) and we can be happy having few people maintaining those during their spare time. So not sure it's a very good idea to have too strict policies/procedures especially when it comes to adding a nice to have cherry on the top for users Especially when the rest of our long procedure has been done. On Tue, 8 Nov 2022 at 09:00, Slawomir Jaranowski wrote: > > Hi, > I start a discussion ... as beginning - some my loose thoughts > > We use Jira (for most of) as our primary issues management system. > We manage release notes in Jira - it is the source for announcements. > > In some projects we have GitHub releases notes. > In some cases we use release-drafter for preparing GitHub releases notes. > Some of release notes on GH - it is not actual > > Challenge: > - make both release notes to have the same information > - minimal additional manual work > > Release - drafter is fine, but > - requires correct labeling on PR > - eache change must be done by PR > - each PR must be merged on GH with merged status > - no additional issues > > > -- > Sławomir Jaranowski - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Releases notes ... Jira, GitHub
Hi, I start a discussion ... as beginning - some my loose thoughts We use Jira (for most of) as our primary issues management system. We manage release notes in Jira - it is the source for announcements. In some projects we have GitHub releases notes. In some cases we use release-drafter for preparing GitHub releases notes. Some of release notes on GH - it is not actual Challenge: - make both release notes to have the same information - minimal additional manual work Release - drafter is fine, but - requires correct labeling on PR - eache change must be done by PR - each PR must be merged on GH with merged status - no additional issues -- Sławomir Jaranowski
Re: [ANN] Apache Maven Build Cache Extension 1.0.0 Released
Congrats - look forward to trying it out. I note however the site links to some missing files: https://maven.apache.org/extensions/resources/maven-build-cache-config.xml from the https://maven.apache.org/extensions/maven-build-cache-extension/getting-started.html page for one (which also still refers to 1.0.0-SNAPSHOT) https://maven.apache.org/extensions/maven-build-cache-extension/usage.html also mentioned “true” in the “disabling” section - counter to the property which is false. -- "Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree On 8/11/2022 at 3:45:06 AM, Guillaume Nodet wrote: > The Apache Maven team is pleased to announce the release of the Apache > Maven Build Cache Extension version 1.0.0 >https://maven.apache.org/extensions/maven-build-cache-extension/ > > You should specify the version in your project's configuration: > > > 1. > 2. org.apache.maven.extensions > 3. maven-build-cache-extension > 4. 1.0.0 > 5. > > > either in pom.xml's // or in > .mvn/extensions.xml > 's . > > Release Notes Maven Build Cache Extension 1.0.0 > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12351243=12324820 > > Release Notes - Maven Build Cache Extension - Version 1.0.0 > > ** Sub-task >* [MBUILDCACHE-2] - Extract caching system out of maven-core >* [MBUILDCACHE-3] - Use maven session properties instead of reading > directly from system properties >* [MBUILDCACHE-4] - Make opt-in as easy as possible using a command > line option / system property >* [MBUILDCACHE-5] - migrate from JAXB to Modello >* [MBUILDCACHE-6] - Rename schemas to be inlined with other schemas >* [MBUILDCACHE-7] - Rebase on top of master 4.x >* [MBUILDCACHE-8] - Avoid guava usage >* [MBUILDCACHE-9] - Remove the `Type` suffix on the generated model > classes >* [MBUILDCACHE-10] - Make the cache singletons reusable across maven > sessions >* [MBUILDCACHE-11] - Define a maven 4 Feature for the cache system >* [MBUILDCACHE-12] - Remove usage of plexus logger > > ** Bug >* [MBUILDCACHE-16] - Fix config file name >* [MBUILDCACHE-17] - IllegalStateException: Cache is not initialized. > Actual state: null >* [MBUILDCACHE-21] - Caching does not check permissions >* [MBUILDCACHE-24] - Cache cannot be processed in presence of forked > executions > > ** New Feature >* [MBUILDCACHE-1] - [Deutsche Bank contribution] Incremental build with > local and remote(shared) cache >* [MBUILDCACHE-22] - Add possibility to skip cache lookup > > ** Improvement >* [MBUILDCACHE-18] - Use m-resolver transport layer instead of > redefining another one >* [MBUILDCACHE-19] - Upgrade to resolver 1.8.0 > > ** Task >* [MBUILDCACHE-13] - rename remote.cache.* properties to build.cache.* >* [MBUILDCACHE-26] - Ensure the maven version is >= 3.9 > > Enjoy, > -- > > On behalf of the Apache Maven team > Guillaume Nodet >
[ANN] Apache Maven Plugin Tools 3.7.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Plugin Tools, version 3.7.0. https://maven.apache.org/plugin-tools/ Release Notes - Maven Plugin Tools - Version 3.7.0 ** Bug * [MPLUGIN-298] - The plugin descriptor generated by plugin:descriptor does not consider @see javadoc taglets * [MPLUGIN-394] - Report-Mojo doesn't respect input encoding * [MPLUGIN-403] - Generating site reports for plugin results in NoSuchMethodError * [MPLUGIN-404] - JDK Requirements in plugin-info.html: Consider property "maven.compiler.release" * [MPLUGIN-420] - Parameters documentation inheriting @since from Mojo can be confusing * [MPLUGIN-428] - Don't emit warning for missing javadoc URL of primitives * [MPLUGIN-429] - Don't emit warning for missing javadoc URI if no javadoc sources are configured * [MPLUGIN-438] - Parameter description should be taken from annotated item ** New Feature * [MPLUGIN-9] - Add link to javadoc in configuration description page for user defined types of Mojos. * [MPLUGIN-396] - Allow only @Deprecated annotation without @deprecated javadoc tag * [MPLUGIN-400] - add system requirements history section * [MPLUGIN-402] - report: allow to generate usage section in plugin-info.html with true * [MPLUGIN-419] - Allow @Parameter on setters methods * [MPLUGIN-423] - Extract plugin report into its own plugin * [MPLUGIN-427] - report: Expose generics information of Collection and Map types ** Improvement * [MPLUGIN-297] - plugin-info.html should contain a better Usage section * [MPLUGIN-390] - Do not overwrite generate files with no content change * [MPLUGIN-393] - Upgrade to JUnit 5 and @Inject annotations * [MPLUGIN-398] - Support for java 20 - ASM 9.4 * [MPLUGIN-405] - Don't print empty Memory, Disk Space in System Requirements * [MPLUGIN-408] - simplification in helpmojo build * [MPLUGIN-411] - Get rid of plexus-compiler-manager from tests * [MPLUGIN-412] - Use Maven core artifacts in provided scope * [MPLUGIN-417] - report and descriptor goal need to evaluate Javadoc comments differently * [MPLUGIN-433] - Allow to reference aggregator javadoc from plugin report ** Task * [MPLUGIN-378] - Detect legacy/javadoc Mojo definitions, warn to use Java 5 annotations * [MPLUGIN-389] - Update level to Java 8 * [MPLUGIN-391] - Deprecate scripting support for mojos * [MPLUGIN-406] - Deprecate requirements parameter in report Mojo * [MPLUGIN-407] - Remove duplicate code from PluginReport * [MPLUGIN-409] - Prepare for Doxia (Sitetools) 2.0.0 * [MPLUGIN-430] - Fix documentation for maven-plugin-report-plugin * [MPLUGIN-431] - Remove deprecated items from new maven-plugin-report-plugin * [MPLUGIN-432] - Improve site build * [MPLUGIN-434] - Improve dependency management * [MPLUGIN-437] - Plugin generator generation fails when the parent class comes from a different project ** Dependency upgrade * [MPLUGIN-395] - Upgrade Maven Reporting API/Impl to 3.1.0 * [MPLUGIN-397] - Upgrade Parent to 36 * [MPLUGIN-399] - Upgrade project dependencies after JDK 1.8 * [MPLUGIN-413] - Bump maven-parent from 36 to 37 * [MPLUGIN-415] - Upgrade Maven Reporting API to 3.1.1/Maven Reporting Impl to 3.2.0 * [MPLUGIN-422] - Upgrade plexus-utils to 3.5.0 Enjoy, -The Apache Maven team
[RESULT] [VOTE] Release Maven Plugin Tools 3.7.0
Hi, The vote has passed with the following result: +1: Michael Osipov, Konrad Windszus, Slawomir Jaranowski, Sylwester Lachiewicz, Guillaume Nodet, Tamás Cservenák PMC quorum: reached I will promote the source release zip file to Apache distribution area and the artifacts to the central repo. -- Sławomir Jaranowski
[ANN] Apache Maven Build Cache Extension 1.0.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Build Cache Extension version 1.0.0 https://maven.apache.org/extensions/maven-build-cache-extension/ You should specify the version in your project's configuration: 1. 2. org.apache.maven.extensions 3. maven-build-cache-extension 4. 1.0.0 5. either in pom.xml's // or in .mvn/extensions.xml 's . Release Notes Maven Build Cache Extension 1.0.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12351243=12324820 Release Notes - Maven Build Cache Extension - Version 1.0.0 ** Sub-task * [MBUILDCACHE-2] - Extract caching system out of maven-core * [MBUILDCACHE-3] - Use maven session properties instead of reading directly from system properties * [MBUILDCACHE-4] - Make opt-in as easy as possible using a command line option / system property * [MBUILDCACHE-5] - migrate from JAXB to Modello * [MBUILDCACHE-6] - Rename schemas to be inlined with other schemas * [MBUILDCACHE-7] - Rebase on top of master 4.x * [MBUILDCACHE-8] - Avoid guava usage * [MBUILDCACHE-9] - Remove the `Type` suffix on the generated model classes * [MBUILDCACHE-10] - Make the cache singletons reusable across maven sessions * [MBUILDCACHE-11] - Define a maven 4 Feature for the cache system * [MBUILDCACHE-12] - Remove usage of plexus logger ** Bug * [MBUILDCACHE-16] - Fix config file name * [MBUILDCACHE-17] - IllegalStateException: Cache is not initialized. Actual state: null * [MBUILDCACHE-21] - Caching does not check permissions * [MBUILDCACHE-24] - Cache cannot be processed in presence of forked executions ** New Feature * [MBUILDCACHE-1] - [Deutsche Bank contribution] Incremental build with local and remote(shared) cache * [MBUILDCACHE-22] - Add possibility to skip cache lookup ** Improvement * [MBUILDCACHE-18] - Use m-resolver transport layer instead of redefining another one * [MBUILDCACHE-19] - Upgrade to resolver 1.8.0 ** Task * [MBUILDCACHE-13] - rename remote.cache.* properties to build.cache.* * [MBUILDCACHE-26] - Ensure the maven version is >= 3.9 Enjoy, -- On behalf of the Apache Maven team Guillaume Nodet
JDK 20 EAb22, ZenGC EA builds, JavaFX 20 EAb5 and several heads-ups!
Greetings, With JavaOne in Las Vegas, last month was epically busy! It was great to finally have the ability to meet and discuss the Quality Outreach program with some of you... face-to-face! This installment of the newsletter is packed as we have several heads-ups, including new Early-Access builds being made available. The JDK 20 schedule has been proposed [1]. The next major milestone is Rampdown Phase One which should happen in just a month on December 8! The next few weeks will be particularly interesting as we will see which from the candidate JEPs recently announced (see 'Topics of Interest' section below) will be proposed to target JDK 20 [2]. And given that JDK 20 is getting closer, we are eagerly waiting for your test feedback on your projects running with the latest JDK 20 EA builds. [1] https://mail.openjdk.org/pipermail/jdk-dev/2022-October/007108.html [2] https://openjdk.org/projects/jdk/20/ ### Heads-up - JDK 20: `java.net.URL` parsing fix & behavior change Before JDK 20, some of the parsing/validation performed by the JDK built-in `URLStreamHander` implementations were delayed until `URL::openConnection` or `URLConnection::connect` was called. Starting JDK 20, some of these parsing/validations are now performed early, i.e. within URL constructors. An exception caused by a malformed URL that would have been delayed until the connection was opened or connected may starting JDK 20, throw a `MalformedURLException` at URL construction time. We suggest testing your project(s) against this change. And for those who want to rely on the old behavior, a new system property has been introduced to revert, on the command line, to the previous behavior. For more details, please see JBS-8293590 [3] and the release notes [4]. [3] https://bugs.openjdk.org/browse/JDK-8293590 [4] https://bugs.openjdk.org/browse/JDK-8295750 ### Heads-up - JDK 20: Thread.stop(), Thread.suspend() and Thread.resume() degradation The ability to stop, suspend, or resume a thread with the corresponding Thread.stop(), Thread.suspend() or Thread.resume() methods have been removed in JDK 20. Those methods have been degraded to throw a UOE exception (UnsupportedOperationException). Using those methods was inherently unsafe. That is also why they were deprecated since JDK 1.2 (1998!) and were flagged 'forRemoval' in previous features release. We do not expect this behavior change to cause issues on well-maintained codebase. For more details please check JDK-8289610 [5], JDK-8249627 [6], and the Java Thread Primitive Deprecation FAQ [7]. [5] https://bugs.openjdk.org/browse/JDK-8289610 [6] https://bugs.openjdk.org/browse/JDK-8249627 [7] https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html ### Heads-up - JDK 20: Deprecate and disable the legacy parallel class loading workaround for non-parallel-capable class loaders. Prior to JDK 7, custom class loaders using non-hierarchical class delegation model were prone to deadlock. A workaround was added in the HotSpot VM (JDK 6) to allow parallel class loading for non-parallel-capable class loaders to avoid deadlocks. Parallel-capable class loaders were introduced in Java SE 7 [8] to support parallel class loading to implement a deadlock-free class loader using a non-hierarchical class delegation model. [8] and [9] describe how to migrate those class loaders depending on this workaround to be multi-threaded parallel-capable class loaders. This workaround was intended to allow those developers to migrate to the new mechanism. JDK 7 was released 11 years ago so it is now expected that those deadlock-prone custom class loaders have been migrated to the parallel-capable class loaders. As a consequence, this workaround is removed in JDK 20 as it impedes eliminating the object monitors from pinning for virtual threads. We suggest confirming that your codebase is not relying on this legacy workaround. If it still is, you should migrate away from it ASAP. Please note that the legacy behavior can be temporary re-enabled using a special flag. For additional details, please check [10] and [11]. [8] https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html [9] https://openjdk.org/groups/core-libs/ClassLoaderProposal.html [10] https://bugs.openjdk.org/browse/JDK-8295848 [11] https://bugs.openjdk.org/browse/JDK-8296446 ### Heads-up - JavaFX builds Oracle is now publishing JavaFX builds, starting with early access builds of JavaFX 20, at jdk.java.net/javafx20 [12]. Developers are now able to download JavaFX and JDK builds from the same place, and use jlink to create a custom JDK that includes the JavaFX modules. The latest JavaFX 20 EA builds (b5-2022/10/28) are now available [12] along with the related javadoc [13]. These early-access builds are provided under the GNU General Public License, version 2, with the Classpath Exception. Feedback should
[RESULT] [VOTE] Maven Build Cache Extension 1.0.0
Closing this vote with the following votes: +1: Maximilian Novikov, sjaranowski, hboutemy, cstamas, gnodet no other votes I'll publish and announce the release asap. Thx to everyone ! Le jeu. 27 oct. 2022 à 13:11, Guillaume Nodet a écrit : > Hi, > > I've staged a release of Maven Build Cache Extension 1.0.0. > This is the first release of this component. > > Solved issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12324820=12351243 > > JIRA issues left: > > https://issues.apache.org/jira/browse/MBUILDCACHE?jql=project%20%3D%20MBUILDCACHE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-1817 > > https://repository.apache.org/content/repositories/maven-1817/org/apache/maven/extensions/maven-build-cache-extension/1.0.0/maven-build-cache-extension-1.0.0-source-release.zip > > Source release checksum: > maven-build-cache-extension-1.0.0-source-release.zip - SHA-512: > 2379d68b15a47d47bcb836e2f0e543adce49c430b8bfe63de98c603e9a75c48450e56e9aab439a7437bf22b83e79bbf51d3ab7da97b53257f8e86cdc887105c7 > > Staging site: > > https://maven.apache.org/extensions-archives/maven-build-cache-extension-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > -- > > Guillaume Nodet > > -- Guillaume Nodet
Re: [VOTE] Maven Build Cache Extension 1.0.0
+1 Le jeu. 27 oct. 2022 à 13:11, Guillaume Nodet a écrit : > Hi, > > I've staged a release of Maven Build Cache Extension 1.0.0. > This is the first release of this component. > > Solved issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12324820=12351243 > > JIRA issues left: > > https://issues.apache.org/jira/browse/MBUILDCACHE?jql=project%20%3D%20MBUILDCACHE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-1817 > > https://repository.apache.org/content/repositories/maven-1817/org/apache/maven/extensions/maven-build-cache-extension/1.0.0/maven-build-cache-extension-1.0.0-source-release.zip > > Source release checksum: > maven-build-cache-extension-1.0.0-source-release.zip - SHA-512: > 2379d68b15a47d47bcb836e2f0e543adce49c430b8bfe63de98c603e9a75c48450e56e9aab439a7437bf22b83e79bbf51d3ab7da97b53257f8e86cdc887105c7 > > Staging site: > > https://maven.apache.org/extensions-archives/maven-build-cache-extension-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > -- > > Guillaume Nodet > > -- Guillaume Nodet
[ANN] Apache Maven Shade Plugin 3.4.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin Version 3.4.1 https://maven.apache.org/plugins/maven-shade-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-shade-plugin 3.4.1 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-shade-plugin/download.cgi Release Notes Maven Shade Plugin 3.4.1 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12352285 Release Notes - Maven Shade Plugin - Version 3.4.1 ** Bug * [MSHADE-366] - The warning "Access denied" during 'minimizeJar' is always printed * [MSHADE-413] - Maven shade plugin enters endless loop * [MSHADE-417] - Fix null bytes appended to small files by maven-shade-plugin ** Task * [MSHADE-422] - Remove usage of deprecated Plugin#getGoals() * [MSHADE-430] - Remove usage of deprecated ModelBase#getReports() * [MSHADE-431] - Use a caching output stream * [MSHADE-432] - Duplicate services entries can be generated Enjoy, -- Guillaume Nodet on behalf of the Apache Maven Team
Re: [VOTE] Release Maven Plugin Tools 3.7.0
+1 On Sun, Oct 30, 2022 at 11:02 AM Slawomir Jaranowski wrote: > Hi, > > We solved 42 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317820=12344367 > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPLUGIN%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key > > Staging repo: > https://repository.apache.org/content/repositories/maven-1819/ > > https://repository.apache.org/content/repositories/maven-1819/org/apache/maven/plugin-tools/maven-plugin-tools/3.7.0/maven-plugin-tools-3.7.0-source-release.zip > > Source release checksum(s): > maven-plugin-tools-3.7.0-source-release.zip - SHA-512 : > > 7a208c35d273ebaca83fcd1dace1c255b3e805bb5765de675792c1ed6ccd5b5dd1beb6782003e9162e925fa8ca8354b54dde15f252f50c497bfe4274c97974e3 > > > Staging site: > https://maven.apache.org/plugin-tools-archives/plugin-tools-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > Sławomir Jaranowski >
Re: [VOTE] Release Maven Plugin Tools 3.7.0
+1 Le dim. 30 oct. 2022 à 11:02, Slawomir Jaranowski a écrit : > Hi, > > We solved 42 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317820=12344367 > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPLUGIN%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key > > Staging repo: > https://repository.apache.org/content/repositories/maven-1819/ > > https://repository.apache.org/content/repositories/maven-1819/org/apache/maven/plugin-tools/maven-plugin-tools/3.7.0/maven-plugin-tools-3.7.0-source-release.zip > > Source release checksum(s): > maven-plugin-tools-3.7.0-source-release.zip - SHA-512 : > > 7a208c35d273ebaca83fcd1dace1c255b3e805bb5765de675792c1ed6ccd5b5dd1beb6782003e9162e925fa8ca8354b54dde15f252f50c497bfe4274c97974e3 > > > Staging site: > https://maven.apache.org/plugin-tools-archives/plugin-tools-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > Sławomir Jaranowski > -- Guillaume Nodet
Re: [VOTE] Release Maven Plugin Tools 3.7.0
Kindly reminder czw., 3 lis 2022 o 19:23 Sylwester Lachiewicz napisał(a): > +1 > > niedz., 30 paź 2022, 11:02 użytkownik Slawomir Jaranowski < > s.jaranow...@gmail.com> napisał: > > > Hi, > > > > We solved 42 issues: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317820=12344367 > > > > There are still a couple of issues left in JIRA: > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPLUGIN%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-1819/ > > > > > https://repository.apache.org/content/repositories/maven-1819/org/apache/maven/plugin-tools/maven-plugin-tools/3.7.0/maven-plugin-tools-3.7.0-source-release.zip > > > > Source release checksum(s): > > maven-plugin-tools-3.7.0-source-release.zip - SHA-512 : > > > > > 7a208c35d273ebaca83fcd1dace1c255b3e805bb5765de675792c1ed6ccd5b5dd1beb6782003e9162e925fa8ca8354b54dde15f252f50c497bfe4274c97974e3 > > > > > > Staging site: > > https://maven.apache.org/plugin-tools-archives/plugin-tools-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for at least 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > -- > > Sławomir Jaranowski > > > -- Sławomir Jaranowski
