Re: [PR] Make rootDirectory mandatory [maven]
gnodet merged PR #1787: URL: https://github.com/apache/maven/pull/1787 -- 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
Re: [PR] Ability to provide custom rootDirectory fallback [maven]
cstamas commented on PR #1787: URL: https://github.com/apache/maven/pull/1787#issuecomment-2400577161 Looks good +1 -- 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
Re: [PR] Bump org.apache.maven.shared:maven-filtering from 3.3.2 to 3.4.0 [maven-acr-plugin]
slachiewicz merged PR #41: URL: https://github.com/apache/maven-acr-plugin/pull/41 -- 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
Re: [PR] Bump commons-io:commons-io from 2.16.1 to 2.17.0 [maven-acr-plugin]
slachiewicz merged PR #42: URL: https://github.com/apache/maven-acr-plugin/pull/42 -- 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
Re: [PR] Bump org.junit.jupiter:junit-jupiter-api from 5.11.1 to 5.11.2 [maven-jdeprscan-plugin]
slachiewicz merged PR #27: URL: https://github.com/apache/maven-jdeprscan-plugin/pull/27 -- 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
Re: [PR] Bump org.apache.commons:commons-lang3 from 3.14.0 to 3.17.0 [maven-jdeprscan-plugin]
slachiewicz merged PR #25: URL: https://github.com/apache/maven-jdeprscan-plugin/pull/25 -- 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] (DOXIA-748) Support file filtering in Doxia ParserModule
[ https://issues.apache.org/jira/browse/DOXIA-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887504#comment-17887504 ] Abel Salgado Romero commented on DOXIA-748: --- > pity that you did not report before GA. I know, I though the same. But would a new constructor method break API? It could be considered a 2.1.0? > Support file filtering in Doxia ParserModule > > > Key: DOXIA-748 > URL: https://issues.apache.org/jira/browse/DOXIA-748 > Project: Maven Doxia > Issue Type: Improvement > Components: Core >Affects Versions: 2.0.0 >Reporter: Abel Salgado Romero >Priority: Minor > > When defining a module one can define the file extensions to process. > However, more complex scenarios require more than a extension. > For example, in the [Asciidoctor > module|https://github.com/asciidoctor/asciidoctor-maven-plugin/issues] it's > possible to have "hidden" (use _ prefix) files that are not to be converted > directly, instead these are to be included in others. > My first though is to be able to pass a `FilenameFilter` in the constructor. > The filter would be matched against files that comply with the file > extensions to confirm whether these should be processed or not. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-1432) Bump org.ow2.asm:asm from 9.7 to 9.7.1
[ https://issues.apache.org/jira/browse/MSHARED-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MSHARED-1432. Resolution: Fixed > Bump org.ow2.asm:asm from 9.7 to 9.7.1 > -- > > Key: MSHARED-1432 > URL: https://issues.apache.org/jira/browse/MSHARED-1432 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-dependency-analyzer >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: maven-dependency-analyzer-1.15.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1432) Bump org.ow2.asm:asm from 9.7 to 9.7.1
Slawomir Jaranowski created MSHARED-1432: Summary: Bump org.ow2.asm:asm from 9.7 to 9.7.1 Key: MSHARED-1432 URL: https://issues.apache.org/jira/browse/MSHARED-1432 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-dependency-analyzer Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: maven-dependency-analyzer-1.15.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARCHETYPE-688) Incompatibities with Velocity in Archetypes
Javid created ARCHETYPE-688: --- Summary: Incompatibities with Velocity in Archetypes Key: ARCHETYPE-688 URL: https://issues.apache.org/jira/browse/ARCHETYPE-688 Project: Maven Archetype Issue Type: Bug Components: Archetypes, Generator, Plugin Affects Versions: 3.3.0 Reporter: Javid Hello, I am having an issue caused by the new version of the maven-archetype-plugin:3.3.0 related with the recent upgrade of velocity 1.7 to velocity 2.3. As it is reported in the [Velocity configuration|https://velocity.apache.org/engine/2.3/upgrading.html#vtl-changes_1], from version 1.7 to version 2+, the use of hyphens have changed and now they are not supported in parameters, causing errors. To avoid this, there is a property that allow backwards compatibility [detailed here|https://velocity.apache.org/engine/2.3/configuration.html#backward-compatibility], but I believe there is no way to tell maven-archetype-plugin to allow this compatibility in the configuration. I have a very complex project that uses hyphens in multiple instances and now, it is impossible to generate a project with the new archetype:3.3.0 version. My problem is that changing the hyphen will cause a major impact in some other projects that rely on this archetype, so it is not a viable option for me to do. Could it be possible for you to include a way to modify Velocity configuration in maven-archetype-plugin:3.3.0? This would be extremely helpful so we can keep up with the future updates Thanks in advance! -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-8295] Dependency Manager Transitivity (now default) handles dependency management inconsistently [maven]
DidierLoiseau commented on PR #1788: URL: https://github.com/apache/maven/pull/1788#issuecomment-2400973468 I see you have now disabled `MavenITmng2196ParentResolutionTest` so I guess it is not relevant anymore. Regarding `MavenITmng7836AlternativePomSyntaxTest`, it succeeds when running the integration tests… _with maven built with this patch_. I also had this issue at some point, and after running the integration tests like that, it was gone, even when running under 3.9.7. However I now realize that it’s because the dependencies were in `` `pwd`/repo `` after the run under the patched Maven 4. If the integration tests still have to run under Maven 3, then I suppose it would be good to understand what changes, and maybe something needs to be added to the `bootstrap.txt`. The thing is, `pom.hocon` uses parent `maven-extensions:41`, which has `maven-parent:41` as parent. The latter runs `spotless-maven-plugin:2.40.0:check`, which appears to need `palantir-java-format:2.38.0` which _is_ in the repository despite not appearing in spotless’ dependency tree. Palantir, however, depends on `error_prone_annotations:2.19.1` and `checker-qual:3.35.0`, which _are not_ in the repository. This seems a bit weird, but maybe there is a good reason for that? Changing the test to run with `-X -Dorg.slf4j.simpleLogger.showLogName=true`, you can see the following: ``` [DEBUG] org.eclipse.aether.internal.impl.DefaultArtifactResolver - Resolving artifact com.google.errorprone:error_prone_annotations:pom:2.19.1 from [central (file:target/null, default, releases+snapshots), apache.snapshots (https://repository.apache.org/snapshots, default, snapshots)] [DEBUG] org.eclipse.aether.internal.impl.DefaultArtifactResolver - Resolving artifact org.checkerframework:checker-qual:pom:3.35.0 from [central (file:target/null, default, releases+snapshots), apache.snapshots (https://repository.apache.org/snapshots, default, snapshots)] [DEBUG] org.eclipse.aether.internal.impl.DefaultArtifactResolver - Resolving artifact com.google.errorprone:error_prone_annotations:pom:2.19.1 from [central (file:target/null, default, releases+snapshots), apache.snapshots (https://repository.apache.org/snapshots, default, snapshots)] [DEBUG] org.eclipse.aether.internal.impl.DefaultArtifactResolver - Resolving artifact org.checkerframework:checker-qual:pom:3.35.0 from [central (file:target/null, default, releases+snapshots), apache.snapshots (https://repository.apache.org/snapshots, default, snapshots)] [WARNING] org.apache.maven.internal.aether.DefaultRepositorySystemSessionFactory - The POM for org.checkerframework:checker-qual:jar:3.35.0 is missing, no dependency information available [WARNING] org.apache.maven.internal.aether.DefaultRepositorySystemSessionFactory - The POM for com.google.errorprone:error_prone_annotations:jar:2.19.1 is missing, no dependency information available ``` For some reason however, this does not cause the build to fail on 4.0.0-beta-4 or the current master, but it does with the `TransitiveDependencyManager`. It’s getting late so I’ll stop my investigations for today, but I put the test ouptut (with full stacktrace at the end) [as a gist here](https://gist.github.com/DidierLoiseau/679103e1338b12168170fdcc5ea5e1d9). -- 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
[PR] Bump ch.qos.logback:logback-classic from 1.5.8 to 1.5.9 [maven]
dependabot[bot] opened a new pull request, #1789: URL: https://github.com/apache/maven/pull/1789 Bumps [ch.qos.logback:logback-classic](https://github.com/qos-ch/logback) from 1.5.8 to 1.5.9. Commits https://github.com/qos-ch/logback/commit/49663a8898b6efdf061603a9caf35996462b0c4c";>49663a8 disable flaky test https://github.com/qos-ch/logback/commit/275664017e988ca2155728b250c3b3b6c38be7c1";>2756640 prepare release 1.5.9 https://github.com/qos-ch/logback/commit/81d8376fdc54fe2cd9ca455243a814bded5e5d11";>81d8376 test for properties change detection from URL/http https://github.com/qos-ch/logback/commit/a496a040fab5dae285bccc87f8431941ed390c5e";>a496a04 adding http scan capability, had to move tests https://github.com/qos-ch/logback/commit/67c24f682198d87a980086adaa74c489d09dd962";>67c24f6 minor changes in RollingFileAppenderTest https://github.com/qos-ch/logback/commit/42caff87ae6eb553dcbf77e25ba87a9d340357ee";>42caff8 fix writing the header for RollingFileAppender (https://redirect.github.com/qos-ch/logback/issues/862";>#862) https://github.com/qos-ch/logback/commit/91961ad72a1416185abe260c4d56a0762a452223";>91961ad add comments to OutputStreamAppender https://github.com/qos-ch/logback/commit/6d11eff9cd3ec0ae15a71455849f630819295934";>6d11eff deprecate Level.ALL and javadocs for Level.OFF https://github.com/qos-ch/logback/commit/895d92dc1c43ea22a02b59de6360af9667bf7acd";>895d92d clean comments https://github.com/qos-ch/logback/commit/5dfbb6185fdbc597ec0a3675ca9c0b6dc70871a0";>5dfbb61 fix issues/861 Additional commits viewable in https://github.com/qos-ch/logback/compare/v_1.5.8...v_1.5.9";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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] [Created] (ARCHETYPE-689) Archetype Plugin 3.3.0 introduced incompatibilities
Joe DiPol created ARCHETYPE-689:
---
Summary: Archetype Plugin 3.3.0 introduced incompatibilities
Key: ARCHETYPE-689
URL: https://issues.apache.org/jira/browse/ARCHETYPE-689
Project: Maven Archetype
Issue Type: Bug
Components: Plugin
Affects Versions: 3.3.0
Reporter: Joe DiPol
Archetype Plugin 3.3.0 introduced API incompatibilities that can break existing
maven archetypes. This is significant because when the plugin is invoked by
users the version of the plugin is rarely specified. An example of such a
breakage is [https://github.com/helidon-io/helidon/issues/9305] (where all
previously shipped versions of our maven archetypes broke).
The incompatibilities were introduced by
[https://github.com/apache/maven-archetype/pull/211] and
[https://github.com/apache/maven-archetype/pull/215]
Changes that broke our archetypes:
# The removal of {{ArchetypeGenerationRequest.getProjectBuildingRequest()}}
# The changing of the return type of
{{ArchetypeGenerationRequest.getRemoteArtifactRepositories()}} from
{{List}} to {{List}}
It also looks like a number of other methods were removed from
{{ArchetypeGenerationRequest}}.
As documented in
[https://maven.apache.org/archetype/maven-archetype-plugin/advanced-usage.html#post-generation-script]
the {{ArchetypeGenerationRequest}} object is the primary API for customization
by a post-generation groovy script. And the changed/removed methods were not
marked for deprecation. Any archetype released before 3.3.0 that relied on this
class is potentially broken.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [SUREFIRE-2276] - Fix for retries of JUnit TestTemplate tests [maven-surefire]
hubertgrzeskowiak commented on PR #788: URL: https://github.com/apache/maven-surefire/pull/788#issuecomment-2401154420 Ah, damn. I did not consider that this project needs to be buildable with older Java and Junit... Fixing now -- 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
[PR] Bump org.cyclonedx:cyclonedx-maven-plugin from 2.8.0 to 2.9.0 [maven-parent]
dependabot[bot] opened a new pull request, #207: URL: https://github.com/apache/maven-parent/pull/207 Bumps [org.cyclonedx:cyclonedx-maven-plugin](https://github.com/CycloneDX/cyclonedx-maven-plugin) from 2.8.0 to 2.9.0. Release notes Sourced from https://github.com/CycloneDX/cyclonedx-maven-plugin/releases";>org.cyclonedx:cyclonedx-maven-plugin's releases. 2.9.0 :tada: Major features and improvements Support 1.6 spec (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/556";>#556) https://github.com/thesurlydev";>@thesurlydev 🔧 Build run mvn verify in CI instead of package (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/560";>#560) https://github.com/hboutemy";>@hboutemy Avoid resources filtering warning (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/543";>#543) https://github.com/Bananeweizen";>@Bananeweizen fix site issues created by upgrades https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/issues/553";>#553 and https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/issues/552";>#552 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/559";>#559) https://github.com/hboutemy";>@hboutemy Bump org.apache.maven.plugins:maven-site-plugin from 3.12.1 to 3.20.0 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/553";>#553) https://github.com/dependabot";>@dependabot Bump actions/checkout from 4.1.7 to 4.2.0 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/555";>#555) https://github.com/dependabot";>@dependabot Bump org.apache.maven.plugins:maven-javadoc-plugin from 3.8.0 to 3.10.1 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/558";>#558) https://github.com/dependabot";>@dependabot 2.8.2 🐛 Bug Fixes display configured classifier from https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/issues/506";>#506 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/550";>#550) https://github.com/hboutemy";>@hboutemy 📦 Dependency updates Bump plugin-tools.version from 3.13.1 to 3.15.0 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/551";>#551) https://github.com/dependabot";>@dependabot Bump org.apache.maven.plugins:maven-project-info-reports-plugin from 3.6.1 to 3.7.0 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/552";>#552) https://github.com/dependabot";>@dependabot Bump org.apache.commons:commons-lang3 from 3.14.0 to 3.17.0 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/546";>#546) https://github.com/dependabot";>@dependabot Bump commons-codec:commons-codec from 1.17.0 to 1.17.1 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/537";>#537) https://github.com/dependabot";>@dependabot 2.8.1 🚀 New features and improvements replace CDX 1.5 deprecated tool (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/517";>#517) https://github.com/hboutemy";>@hboutemy make classifier used to attach the sbom configurable (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/506";>#506) https://github.com/hboutemy";>@hboutemy 📦 Dependency updates upgrade cyclonedx-maven-plugin from 2.7.9 to 2.8.0 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/536";>#536) https://github.com/hboutemy";>@hboutemy Bump net.javacrumbs.json-unit:json-unit-assertj from 2.38.0 to 2.40.1 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/532";>#532) https://github.com/dependabot";>@dependabot Bump org.apache.maven.plugins:maven-release-plugin from 3.0.1 to 3.1.1 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/535";>#535) https://github.com/dependabot";>@dependabot Bump org.apache.maven.plugins:maven-javadoc-plugin from 3.7.0 to 3.8.0 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/533";>#533) https://github.com/dependabot";>@dependabot Bump org.junit:junit-bom from 5.10.2 to 5.10.3 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/527";>#527) https://github.com/dependabot";>@dependabot Bump org.apache.maven.plugins:maven-jar-plugin from 3.4.1 to 3.4.2 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/528";>#528) https://github.com/dependabot";>@dependabot Bump plugin-tools.version from 3.13.0 to 3.13.1 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/519";>#519) https://github.com/dependabot";>@dependabot Bump org.apache.maven.plugins:maven-project-info-reports-plugin from 3.5.0 to 3.6.1 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/525";>#525) https://github.com/dependabot";>@dependabot Bump org.apache.maven.plugins:maven-javadoc-plugin from 3.6.3 to 3.7.0 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/511"
Re: [PR] Bump org.cyclonedx:cyclonedx-maven-plugin from 2.8.0 to 2.8.2 [maven-parent]
dependabot[bot] closed pull request #204: Bump org.cyclonedx:cyclonedx-maven-plugin from 2.8.0 to 2.8.2 URL: https://github.com/apache/maven-parent/pull/204 -- 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
Re: [PR] Bump org.cyclonedx:cyclonedx-maven-plugin from 2.8.0 to 2.8.2 [maven-parent]
dependabot[bot] commented on PR #204: URL: https://github.com/apache/maven-parent/pull/204#issuecomment-2401242532 Superseded by #207. -- 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
Re: [PR] Bump commons-io:commons-io from 2.7 to 2.16.1 [maven-ejb-plugin]
zeitiger commented on PR #28: URL: https://github.com/apache/maven-ejb-plugin/pull/28#issuecomment-2401415101 It would be great if this dependency could be merged and published, our security scanner would be pleased -- 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
Re: [PR] Bump org.codehaus.plexus:plexus-archiver from 4.9.2 to 4.10.0 [maven-ejb-plugin]
zeitiger commented on PR #34: URL: https://github.com/apache/maven-ejb-plugin/pull/34#issuecomment-2401413087 It would be great if this dependency could be merged and published, our security scanner would be pleased -- 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] (MSHARED-1430) Use a predefined constant for project.build.outputTimestamp
[
https://issues.apache.org/jira/browse/MSHARED-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887783#comment-17887783
]
Herve Boutemy commented on MSHARED-1430:
many people have many opinions: there are even more opinions than people :)
FYI, default value has been added in MNG-8258 for future Maven 4.0.0-beta-4,
with a Maven-specific timestamp (no reason to try to mimic others: there is no
perfect or wrong choice)
> Use a predefined constant for project.build.outputTimestamp
> ---
>
> Key: MSHARED-1430
> URL: https://issues.apache.org/jira/browse/MSHARED-1430
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Reporter: Sergey Ponomarev
>Priority: Minor
>
> The "Configuring for Reproducible Builds" guide shows and example how to
> specify a static outputTimestamp:
>
> 2023-01-01T00:00:00Z
> The date inside is really doesn't matter and I used the property as is but
> was afraid of being asked on a review why the 2023 year was used so used the
> current year.
> But still during a review I was asked:
> bq. these changes are likely going to confuse future developers ("This date
> shouldn't be static! Lets make it a variable!").
> The Gradle has an option preserveFileTimestamps = false that will just put 1
> Feb 1980 as a date. The 1 Jan 1980 is a minimal date in Zip archive but the 1
> Jan has some special treatment by Java that's why the Gradle team used the 1
> Feb.
> See more detailed description in CONSTANT_TIME_FOR_ZIP_ENTRIES
> https://github.com/gradle/gradle/blob/master/platforms/core-runtime/files/src/main/java/org/gradle/api/internal/file/archive/ZipEntryConstants.java#L39
> I don't think it worth to declare some new property e.g.
> true
> But we can simply make a special constant value like:
>
> REPRODUCIBLE_BUILD_STATIC_DATE
> Then the constant will be replaced with the same 1 Feb 1980 to be similar
> with Gradle produced artifacts.
> This constant should make it more clear intention of the outputTimestamp but
> also easier to find an explanation for this.
> The outputTimestamp parsing is performed in the maven-archiver but the
> maven-compiler-plugin and maven-jar-plugin would need to update a JavaDoc for
> the outputTimestamp config option
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7982] IT’s for transitive dependency management [maven-integration-testing]
DidierLoiseau commented on PR #379: URL: https://github.com/apache/maven-integration-testing/pull/379#issuecomment-2400745387 > @DidierLoiseau could you align the branch names for [this PR](https://github.com/apache/maven-integration-testing/pull/379) and [apache/maven#1785](https://github.com/apache/maven/pull/1785), this will allow running #1785 using the new ITs, else it will use master. I see you have created #384 and apache/maven#1788, so I guess this isn’t necessary anymore? -- 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] [Assigned] (ARCHETYPE-688) Incompatibities with Velocity in Archetypes
[ https://issues.apache.org/jira/browse/ARCHETYPE-688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski reassigned ARCHETYPE-688: - Assignee: Slawomir Jaranowski > Incompatibities with Velocity in Archetypes > --- > > Key: ARCHETYPE-688 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-688 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes, Generator, Plugin >Affects Versions: 3.3.0 >Reporter: Javid >Assignee: Slawomir Jaranowski >Priority: Major > > Hello, > I am having an issue caused by the new version of the > maven-archetype-plugin:3.3.0 related with the recent upgrade of velocity 1.7 > to velocity 2.3. > As it is reported in the [Velocity > configuration|https://velocity.apache.org/engine/2.3/upgrading.html#vtl-changes_1], > from version 1.7 to version 2+, the use of hyphens have changed and now they > are not supported in parameters, causing errors. > To avoid this, there is a property that allow backwards compatibility > [detailed > here|https://velocity.apache.org/engine/2.3/configuration.html#backward-compatibility], > but I believe there is no way to tell maven-archetype-plugin to allow this > compatibility in the configuration. > I have a very complex project that uses hyphens in multiple instances and > now, it is impossible to generate a project with the new archetype:3.3.0 > version. > My problem is that changing the hyphen will cause a major impact in some > other projects that rely on this archetype, so it is not a viable option for > me to do. > Could it be possible for you to include a way to modify Velocity > configuration in maven-archetype-plugin:3.3.0? This would be extremely > helpful so we can keep up with the future updates > Thanks in advance! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARCHETYPE-689) Archetype Plugin 3.3.0 introduced incompatibilities
[
https://issues.apache.org/jira/browse/ARCHETYPE-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1788#comment-1788
]
Slawomir Jaranowski commented on ARCHETYPE-689:
---
I missed that it is a public class ... I will try to restore old methods
> Archetype Plugin 3.3.0 introduced incompatibilities
> ---
>
> Key: ARCHETYPE-689
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-689
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.3.0
>Reporter: Joe DiPol
>Priority: Major
>
> Archetype Plugin 3.3.0 introduced API incompatibilities that can break
> existing maven archetypes. This is significant because when the plugin is
> invoked by users the version of the plugin is rarely specified. An example of
> such a breakage is [https://github.com/helidon-io/helidon/issues/9305] (where
> all previously shipped versions of our maven archetypes broke).
> The incompatibilities were introduced by
> [https://github.com/apache/maven-archetype/pull/211] and
> [https://github.com/apache/maven-archetype/pull/215]
> Changes that broke our archetypes:
> # The removal of {{ArchetypeGenerationRequest.getProjectBuildingRequest()}}
> # The changing of the return type of
> {{ArchetypeGenerationRequest.getRemoteArtifactRepositories()}} from
> {{List}} to {{List}}
> It also looks like a number of other methods were removed from
> {{ArchetypeGenerationRequest}}.
> As documented in
> [https://maven.apache.org/archetype/maven-archetype-plugin/advanced-usage.html#post-generation-script]
> the {{ArchetypeGenerationRequest}} object is the primary API for
> customization by a post-generation groovy script. And the changed/removed
> methods were not marked for deprecation. Any archetype released before 3.3.0
> that relied on this class is potentially broken.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARCHETYPE-689) Archetype Plugin 3.3.0 introduced incompatibilities
[
https://issues.apache.org/jira/browse/ARCHETYPE-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated ARCHETYPE-689:
--
Fix Version/s: 3.3.1
> Archetype Plugin 3.3.0 introduced incompatibilities
> ---
>
> Key: ARCHETYPE-689
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-689
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.3.0
>Reporter: Joe DiPol
>Priority: Major
> Fix For: 3.3.1
>
>
> Archetype Plugin 3.3.0 introduced API incompatibilities that can break
> existing maven archetypes. This is significant because when the plugin is
> invoked by users the version of the plugin is rarely specified. An example of
> such a breakage is [https://github.com/helidon-io/helidon/issues/9305] (where
> all previously shipped versions of our maven archetypes broke).
> The incompatibilities were introduced by
> [https://github.com/apache/maven-archetype/pull/211] and
> [https://github.com/apache/maven-archetype/pull/215]
> Changes that broke our archetypes:
> # The removal of {{ArchetypeGenerationRequest.getProjectBuildingRequest()}}
> # The changing of the return type of
> {{ArchetypeGenerationRequest.getRemoteArtifactRepositories()}} from
> {{List}} to {{List}}
> It also looks like a number of other methods were removed from
> {{ArchetypeGenerationRequest}}.
> As documented in
> [https://maven.apache.org/archetype/maven-archetype-plugin/advanced-usage.html#post-generation-script]
> the {{ArchetypeGenerationRequest}} object is the primary API for
> customization by a post-generation groovy script. And the changed/removed
> methods were not marked for deprecation. Any archetype released before 3.3.0
> that relied on this class is potentially broken.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARCHETYPE-688) Incompatibities with Velocity in Archetypes
[ https://issues.apache.org/jira/browse/ARCHETYPE-688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated ARCHETYPE-688: -- Fix Version/s: 3.3.1 > Incompatibities with Velocity in Archetypes > --- > > Key: ARCHETYPE-688 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-688 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes, Generator, Plugin >Affects Versions: 3.3.0 >Reporter: Javid >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.3.1 > > > Hello, > I am having an issue caused by the new version of the > maven-archetype-plugin:3.3.0 related with the recent upgrade of velocity 1.7 > to velocity 2.3. > As it is reported in the [Velocity > configuration|https://velocity.apache.org/engine/2.3/upgrading.html#vtl-changes_1], > from version 1.7 to version 2+, the use of hyphens have changed and now they > are not supported in parameters, causing errors. > To avoid this, there is a property that allow backwards compatibility > [detailed > here|https://velocity.apache.org/engine/2.3/configuration.html#backward-compatibility], > but I believe there is no way to tell maven-archetype-plugin to allow this > compatibility in the configuration. > I have a very complex project that uses hyphens in multiple instances and > now, it is impossible to generate a project with the new archetype:3.3.0 > version. > My problem is that changing the hyphen will cause a major impact in some > other projects that rely on this archetype, so it is not a viable option for > me to do. > Could it be possible for you to include a way to modify Velocity > configuration in maven-archetype-plugin:3.3.0? This would be extremely > helpful so we can keep up with the future updates > Thanks in advance! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-5910) Using both {{exists}} and {{missing}} in the same {{file}} element should lead to an exception
[
https://issues.apache.org/jira/browse/MNG-5910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-5910.
Resolution: Fixed
Fixed by [https://github.com/apache/maven/pull/1773]
> Using both {{exists}} and {{missing}} in the same {{file}} element should
> lead to an exception
> --
>
> Key: MNG-5910
> URL: https://issues.apache.org/jira/browse/MNG-5910
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.3.3
>Reporter: Konrad Windszus
>Assignee: Guillaume Nodet
>Priority: Minor
> Fix For: 4.0.0-beta-5
>
>
> Currently it is not clear from the POM reference
> (https://maven.apache.org/pom.html#Activation), that the elements {{exists}}
> and {{missing}} below {{file}} are mutually exclusive, because only
> {{exists}} is considered if it is there (see also
> https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/profile/activation/FileProfileActivator.java#L91).
> Please make it clearer in the POM reference that not both of them should be
> used at the same time and also throw an exception during build time if that
> is the case (in the effective POM).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8295] Dependency Manager Transitivity (now default) handles dependency management inconsistently [maven]
gnodet commented on PR #1788: URL: https://github.com/apache/maven/pull/1788#issuecomment-2400320851 Two failing ITs: * MavenITmng2196ParentResolutionTest * MavenITmng7836AlternativePomSyntaxTest -- 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
Re: [PR] Bump commons-io:commons-io from 2.16.1 to 2.17.0 [maven]
slachiewicz commented on PR #1738: URL: https://github.com/apache/maven/pull/1738#issuecomment-2400312801 @dependabot recreate -- 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] (ARCHETYPE-688) Incompatibities with Velocity in Archetypes
[ https://issues.apache.org/jira/browse/ARCHETYPE-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887555#comment-17887555 ] Slawomir Jaranowski commented on ARCHETYPE-688: --- Please provide a stack trace where Velocity is used or a simple project to reproduce. We have in place an compatibility configuration: [https://github.com/apache/maven-archetype/blob/master/archetype-common/src/main/java/org/apache/maven/archetype/VelocityConfigurator.java] > Incompatibities with Velocity in Archetypes > --- > > Key: ARCHETYPE-688 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-688 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes, Generator, Plugin >Affects Versions: 3.3.0 >Reporter: Javid >Priority: Major > > Hello, > I am having an issue caused by the new version of the > maven-archetype-plugin:3.3.0 related with the recent upgrade of velocity 1.7 > to velocity 2.3. > As it is reported in the [Velocity > configuration|https://velocity.apache.org/engine/2.3/upgrading.html#vtl-changes_1], > from version 1.7 to version 2+, the use of hyphens have changed and now they > are not supported in parameters, causing errors. > To avoid this, there is a property that allow backwards compatibility > [detailed > here|https://velocity.apache.org/engine/2.3/configuration.html#backward-compatibility], > but I believe there is no way to tell maven-archetype-plugin to allow this > compatibility in the configuration. > I have a very complex project that uses hyphens in multiple instances and > now, it is impossible to generate a project with the new archetype:3.3.0 > version. > My problem is that changing the hyphen will cause a major impact in some > other projects that rely on this archetype, so it is not a viable option for > me to do. > Could it be possible for you to include a way to modify Velocity > configuration in maven-archetype-plugin:3.3.0? This would be extremely > helpful so we can keep up with the future updates > Thanks in advance! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARCHETYPE-688) Incompatibities with Velocity in Archetypes
[
https://issues.apache.org/jira/browse/ARCHETYPE-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887565#comment-17887565
]
Javid edited comment on ARCHETYPE-688 at 10/8/24 11:19 AM:
---
Sure thing. Here you can see part of my plugin config and the
archetype-metadata.xml
{code:java}
Plugin Configuration
org.apache.maven.archetype
archetype-packaging
${maven-archetype.version}
maven-archetype-plugin
${maven-archetype.version}
${skipTests}
true
{code}
{code:java}
Archetype Metadata
1.0.0-SNAPSHOT
${component-name}
customerJob
com.mypack.${acronym-app}
${groupId}.${artifactId.replaceAll("-",
"").replaceAll("_", "")}
${acronym-app} project-arch:
${component-name}
{code}
As you can see, there are several parameters such as "component-name" or
"acronym-app" that contains the hyphen. Here is part of the stack trace when I
execute archetype:generate. I have focused mainly in the Velocity section of
it, as the error is produced there.
{code:java}
mvn -B archetype:generate -DarchetypeGroupId=com.mypack.project
-DarchetypeArtifactId=project-arch -DarchetypeVersion=4.0.0-RELEASE
-Dcomponent-name=greetings -Dacronym-app=project -X
[...]
[DEBUG] Entry found
[DEBUG] Creating ArchetypeConfiguration from fileset descriptor and Properties
[DEBUG] Adding requiredProperty version
[DEBUG] Setting property version=1.0.0-SNAPSHOT
[DEBUG] Setting defaultProperty version=1.0.0-SNAPSHOT
[DEBUG] Adding requiredProperty component-name
[DEBUG] Setting property component-name=greetings
[DEBUG] Adding requiredProperty acronym-app
[DEBUG] Setting property acronym-app=project
[DEBUG] Adding requiredProperty artifactId
[DEBUG] Setting defaultProperty artifactId=${component-name}
[DEBUG] Adding requiredProperty groupId
[DEBUG] Setting defaultProperty groupId=com.${acronym-app}
[DEBUG] Adding requiredProperty package
[DEBUG] Setting defaultProperty package=${groupId}.${artifactId.replaceAll("-",
"").replaceAll("_", "")}
[DEBUG] Adding requiredProperty description
[DEBUG] Setting defaultProperty description=${acronym-app} project-arch:
${component-name}
[DEBUG] Initializing Velocity, Calling init()...
[DEBUG] Starting Apache Velocity v2.3
[DEBUG] Default Properties resource:
org/apache/velocity/runtime/defaults/velocity.properties
[DEBUG] ResourceLoader instantiated:
org.apache.velocity.runtime.resource.loader.FileResourceLoader
[DEBUG] FileResourceLoader: adding path '.'
[DEBUG] initialized (class
org.apache.velocity.runtime.resource.ResourceCacheImpl) with class
java.util.Collections$SynchronizedMap cache map.
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Stop
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Define
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Break
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Evaluate
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Include
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
[DEBUG] Created '20' parsers.
[DEBUG] "velocimacro.library.path" is not set. Trying default library:
velocimacros.vtl
[DEBUG] Default library velocimacros.vtl not found. Trying old default library:
VM_global_library.vm
[DEBUG] Old default library VM_global_library.vm not found.
[DEBUG] allowInline = true: VMs can be defined inline in templates
[DEBUG] allowInlineToOverride = false: VMs defined inline may NOT replace
previous VM definitions
[DEBUG] allowInlineLocal = false: VMs defined inline will be global in scope if
allowed.
[DEBUG] autoload off: VM system will not automatically reload global library
macros
[ERROR] artifactId.default: Encountered "-name}" at line 1, column 12.
Was expecting one of:
"[" ...
"|" ...
"}" ...
"}" ...
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 4.065 s
[INFO] Finished at: 2024-10-08T12:49:55+02:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-archetype-plugin:3.3.0:generate (default-cli) on
project standalone-pom: Unparsable default value for property artifactId:
Encountered "-name}" at artifactId.default[line 1, column 12]
[ERROR] Was expe
[jira] [Commented] (DOXIA-748) Support file filtering in Doxia ParserModule
[ https://issues.apache.org/jira/browse/DOXIA-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887564#comment-17887564 ] Michael Osipov commented on DOXIA-748: -- I think that this is the wrong project. Isn't this for Doxia Sitetools? > Support file filtering in Doxia ParserModule > > > Key: DOXIA-748 > URL: https://issues.apache.org/jira/browse/DOXIA-748 > Project: Maven Doxia > Issue Type: Improvement > Components: Core >Affects Versions: 2.0.0 >Reporter: Abel Salgado Romero >Priority: Minor > > When defining a module one can define the file extensions to process. > However, more complex scenarios require more than a extension. > For example, in the [Asciidoctor > module|https://github.com/asciidoctor/asciidoctor-maven-plugin/issues] it's > possible to have "hidden" (use _ prefix) files that are not to be converted > directly, instead these are to be included in others. > My first though is to be able to pass a `FilenameFilter` in the constructor. > The filter would be matched against files that comply with the file > extensions to confirm whether these should be processed or not. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARCHETYPE-688) Incompatibities with Velocity in Archetypes
[
https://issues.apache.org/jira/browse/ARCHETYPE-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887565#comment-17887565
]
Javid commented on ARCHETYPE-688:
-
Sure thing. Here you can see part of my archetype-metadata.xml
{code:java}
1.0.0-SNAPSHOT
${component-name}
customerJob
com.mypack.${acronym-app}
${groupId}.${artifactId.replaceAll("-",
"").replaceAll("_", "")}
${acronym-app} project-arch:
${component-name}
{code}
As you can see, there are several parameters such as "component-name" or
"acronym-app" that contains the hyphen. Here is part of the stack trace when I
execute archetype:generate. I have focused mainly in the Velocity section of
it, as the error is produced there.
{code:java}
mvn -B archetype:generate -DarchetypeGroupId=com.mypack.project
-DarchetypeArtifactId=project-arch -DarchetypeVersion=4.0.0-RELEASE
-Dcomponent-name=greetings -Dacronym-app=project -X
[...]
[DEBUG] Entry found
[DEBUG] Creating ArchetypeConfiguration from fileset descriptor and Properties
[DEBUG] Adding requiredProperty version
[DEBUG] Setting property version=1.0.0-SNAPSHOT
[DEBUG] Setting defaultProperty version=1.0.0-SNAPSHOT
[DEBUG] Adding requiredProperty component-name
[DEBUG] Setting property component-name=greetings
[DEBUG] Adding requiredProperty acronym-app
[DEBUG] Setting property acronym-app=project
[DEBUG] Adding requiredProperty artifactId
[DEBUG] Setting defaultProperty artifactId=${component-name}
[DEBUG] Adding requiredProperty groupId
[DEBUG] Setting defaultProperty groupId=com.${acronym-app}
[DEBUG] Adding requiredProperty package
[DEBUG] Setting defaultProperty package=${groupId}.${artifactId.replaceAll("-",
"").replaceAll("_", "")}
[DEBUG] Adding requiredProperty description
[DEBUG] Setting defaultProperty description=${acronym-app} project-arch:
${component-name}
[DEBUG] Initializing Velocity, Calling init()...
[DEBUG] Starting Apache Velocity v2.3
[DEBUG] Default Properties resource:
org/apache/velocity/runtime/defaults/velocity.properties
[DEBUG] ResourceLoader instantiated:
org.apache.velocity.runtime.resource.loader.FileResourceLoader
[DEBUG] FileResourceLoader: adding path '.'
[DEBUG] initialized (class
org.apache.velocity.runtime.resource.ResourceCacheImpl) with class
java.util.Collections$SynchronizedMap cache map.
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Stop
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Define
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Break
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Evaluate
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Include
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
[DEBUG] Created '20' parsers.
[DEBUG] "velocimacro.library.path" is not set. Trying default library:
velocimacros.vtl
[DEBUG] Default library velocimacros.vtl not found. Trying old default library:
VM_global_library.vm
[DEBUG] Old default library VM_global_library.vm not found.
[DEBUG] allowInline = true: VMs can be defined inline in templates
[DEBUG] allowInlineToOverride = false: VMs defined inline may NOT replace
previous VM definitions
[DEBUG] allowInlineLocal = false: VMs defined inline will be global in scope if
allowed.
[DEBUG] autoload off: VM system will not automatically reload global library
macros
[ERROR] artifactId.default: Encountered "-name}" at line 1, column 12.
Was expecting one of:
"[" ...
"|" ...
"}" ...
"}" ...
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 4.065 s
[INFO] Finished at: 2024-10-08T12:49:55+02:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-archetype-plugin:3.3.0:generate (default-cli) on
project standalone-pom: Unparsable default value for property artifactId:
Encountered "-name}" at artifactId.default[line 1, column 12]
[ERROR] Was expecting one of:
[ERROR] "[" ...
[ERROR] "|" ...
[ERROR] "}" ...
[ERROR] "}" ...
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-archetype-plugin:3.3.0:generate (default-cli) on
project standalone-pom: Unparsable default value for property artifactId
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExe
[jira] [Commented] (DOXIA-748) Support file filtering in Doxia ParserModule
[ https://issues.apache.org/jira/browse/DOXIA-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887566#comment-17887566 ] Abel Salgado Romero commented on DOXIA-748: --- I am referring to these class https://github.com/apache/maven-doxia/blob/master/doxia-core/src/main/java/org/apache/maven/doxia/parser/module/AbstractParserModule.java, which is in `doxia-core` module. > Support file filtering in Doxia ParserModule > > > Key: DOXIA-748 > URL: https://issues.apache.org/jira/browse/DOXIA-748 > Project: Maven Doxia > Issue Type: Improvement > Components: Core >Affects Versions: 2.0.0 >Reporter: Abel Salgado Romero >Priority: Minor > > When defining a module one can define the file extensions to process. > However, more complex scenarios require more than a extension. > For example, in the [Asciidoctor > module|https://github.com/asciidoctor/asciidoctor-maven-plugin/issues] it's > possible to have "hidden" (use _ prefix) files that are not to be converted > directly, instead these are to be included in others. > My first though is to be able to pass a `FilenameFilter` in the constructor. > The filter would be matched against files that comply with the file > extensions to confirm whether these should be processed or not. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8295) Dependency Manager Transitivity (now default) handles dependency management inconsistently
[
https://issues.apache.org/jira/browse/MNG-8295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887609#comment-17887609
]
Michael Osipov commented on MNG-8295:
-
[~cstamas]
> Dependency Manager Transitivity (now default) handles dependency management
> inconsistently
> --
>
> Key: MNG-8295
> URL: https://issues.apache.org/jira/browse/MNG-8295
> Project: Maven
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 4.0.0-beta-4
>Reporter: Didier Loiseau
>Priority: Critical
> Attachments: dependency-transitivity-inconsistency.zip
>
>
> Since MNG-7982, {{maven.resolver.dependencyManagerTransitivity}}
> ({{{}true{}}} by default) configures the {{ClassicDependencyManager}} with
> the corresponding {{transitivity}} flag.
> It appears, however, that this behavior is inconsistent, because it ignores
> the dependency management of direct dependencies and only considers it for
> the transitive dependencies.
> I already described this in MNG-5761, but since the latter is originally a
> different issue (that should have been fixed by MNG-7982), I thought it would
> make more sense to track this inconsistency as a separate bug.
> The attached [^dependency-transitivity-inconsistency.zip] (copied from
> MNG-5761) can be used to show the issue.
> I’m running with
> {code:java}
> $ mvn -v
> Apache Maven 4.0.0-beta-4 (697c543b4e3bbec1b99e9d4d1ee8e0302e748f09)
> Maven home: /home/didier/.sdkman/candidates/maven/4.0.0-beta-4
> Java version: 21.0.2, vendor: Oracle Corporation, runtime:
> /home/didier/.sdkman/candidates/java/21.0.2-open
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "6.8.0-45-generic", arch: "amd64", family: "unix"
> {code}
> First you can see that {{dependent-pom}} manages the version of
> {{commons-collections}} to *3.2.2* ({{{}commons-beanutils:1.9.2{}}} depends
> on 3.2.1):
> {code:java}
> $ mvn dependency:tree -f dependent-pom.xml
> …
> [INFO] MNG-5761:dependent:pom:1.0-SNAPSHOT
> [INFO] \- commons-beanutils:commons-beanutils:jar:1.9.2:compile
> [INFO]+- commons-logging:commons-logging:jar:1.1.1:compile
> [INFO]\- commons-collections:commons-collections:jar:3.2.2:compile
> {code}
> Now install {{parent-pom}} and {{{}dependent-pom{}}}, and check the
> dependencies of {{{}depending-pom{}}}:
> {code:java}
> $ mvn install -f parent-pom.xml
> $ mvn install -f dependent-pom.xml
> $ mvn dependency:tree -f depending-pom.xml
> …
> [INFO] MNG-5761:depending:pom:1.0-SNAPSHOT
> [INFO] \- MNG-5761:dependent:pom:1.0-SNAPSHOT:compile
> [INFO]\- commons-beanutils:commons-beanutils:jar:1.9.2:compile
> [INFO] +- commons-logging:commons-logging:jar:1.1.1:compile
> [INFO] \- commons-collections:commons-collections:jar:3.2.1:compile
> {code}
> you can see that the {{}} of {{dependent}} is ignored
> (like with Maven 3), and we get {{commons-collections}} *3.2.1* instead.
> However, if we install {{dependent-pom}} and check the dependencies of
> {{{}dependent-pom2{}}}, we get:
> {code:java}
> $ mvn install -f depending-pom.xml
> $ mvn dependency:tree -f depending-pom2.xml
> …
> [INFO] MNG-5761:depending2:pom:1.0-SNAPSHOT
> [INFO] \- MNG-5761:depending:pom:1.0-SNAPSHOT:compile
> [INFO]\- MNG-5761:dependent:pom:1.0-SNAPSHOT:compile
> [INFO] \- commons-beanutils:commons-beanutils:jar:1.9.2:compile
> [INFO] +- commons-logging:commons-logging:jar:1.1.1:compile
> [INFO] \- commons-collections:commons-collections:jar:3.2.2:compile
> {code}
> So now we get {{commons-collections}} *3.2.2* again!
> {{}} is taken into account at depth 2+ (and 0) but not
> at depth 1.
> This is due to [these 3
> lines|https://github.com/apache/maven-resolver/blob/32844e4eb8d444838953f1d49be2ecb71db15b78/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/manager/ClassicDependencyManager.java#L91-L93]
> in {{{}ClassicDependencyManager{}}}:
> {code:java}
> @Override
> public DependencyManager deriveChildManager(DependencyCollectionContext
> context) {
> // MNG-4720: Maven2 backward compatibility
> // Removing this IF makes one IT fail here (read comment above):
> //
> https://github.com/apache/maven-integration-testing/blob/b4e8fd52b99a058336f9c7c5ec44fdbc1427759c/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng4720DependencyManagementExclusionMergeTest.java#L67
> if (depth == 1) {
> return newInstance(managedVersions, managedScopes,
> managedOptionals, managedLocalPaths, managedExclusions);
> }
> return super.deriveChildManager(context);
> }
> {code}
> I have also created [a PR with integration
> tests|https://github.com/apache/maven-integration-testing/pull/379] for
> MNG-7982, which
[jira] [Updated] (DOXIA-747) MarkdownSink: Section headings must be located at the beginning of a line
[
https://issues.apache.org/jira/browse/DOXIA-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated DOXIA-747:
--
Description:
If currently a {{Sink.text()}} is followed by a {{Sink.sectionTitle(...)}} with
some text it is not emitted on a dedicated line through the {{MarkdownSink}}.
However according to https://spec.commonmark.org/0.31.2/#atx-headings
{quote} The opening # character may be preceded by up to three spaces of
indentation {quote}
was:
If currently a {{Sink.comment()}} is followed by a {{Sink.sectionTitle(...)}}
with some text it is not emitted on a dedicated line through the
{{MarkdownSink}}/
However according to https://spec.commonmark.org/0.31.2/#atx-headings
{quote} The opening # character may be preceded by up to three spaces of
indentation {quote}
> MarkdownSink: Section headings must be located at the beginning of a line
> -
>
> Key: DOXIA-747
> URL: https://issues.apache.org/jira/browse/DOXIA-747
> Project: Maven Doxia
> Issue Type: Bug
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> If currently a {{Sink.text()}} is followed by a {{Sink.sectionTitle(...)}}
> with some text it is not emitted on a dedicated line through the
> {{MarkdownSink}}.
> However according to https://spec.commonmark.org/0.31.2/#atx-headings
> {quote} The opening # character may be preceded by up to three spaces of
> indentation {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-748) Support file filtering in Doxia ParserModule
[ https://issues.apache.org/jira/browse/DOXIA-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887582#comment-17887582 ] Michael Osipov commented on DOXIA-748: -- I think we have this already here: https://github.com/apache/maven-doxia-sitetools/blob/cd77672ba79e1ee42f16258706fc6a43c898b842/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L164-L177 You can define your excludes and solve your problem. See: https://maven.apache.org/plugins/maven-site-plugin/site-mojo.html#moduleExcludes > Support file filtering in Doxia ParserModule > > > Key: DOXIA-748 > URL: https://issues.apache.org/jira/browse/DOXIA-748 > Project: Maven Doxia > Issue Type: Improvement > Components: Core >Affects Versions: 2.0.0 >Reporter: Abel Salgado Romero >Priority: Minor > > When defining a module one can define the file extensions to process. > However, more complex scenarios require more than a extension. > For example, in the [Asciidoctor > module|https://github.com/asciidoctor/asciidoctor-maven-plugin/issues] it's > possible to have "hidden" (use _ prefix) files that are not to be converted > directly, instead these are to be included in others. > My first though is to be able to pass a `FilenameFilter` in the constructor. > The filter would be matched against files that comply with the file > extensions to confirm whether these should be processed or not. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [DOXIA-747] Emit headings at beginning of line for Markdown [maven-doxia]
kwin merged PR #235: URL: https://github.com/apache/maven-doxia/pull/235 -- 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] [Resolved] (DOXIA-747) MarkdownSink: Section headings must be located at the beginning of a line
[
https://issues.apache.org/jira/browse/DOXIA-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved DOXIA-747.
---
Fix Version/s: 2.0.1
Resolution: Fixed
> MarkdownSink: Section headings must be located at the beginning of a line
> -
>
> Key: DOXIA-747
> URL: https://issues.apache.org/jira/browse/DOXIA-747
> Project: Maven Doxia
> Issue Type: Bug
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.0.1
>
>
> If currently a {{Sink.text()}} is followed by a {{Sink.sectionTitle(...)}}
> with some text it is not emitted on a dedicated line through the
> {{MarkdownSink}}.
> However according to https://spec.commonmark.org/0.31.2/#atx-headings
> {quote} The opening # character may be preceded by up to three spaces of
> indentation {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-747) MarkdownSink: Section headings must be located at the beginning of a line
[
https://issues.apache.org/jira/browse/DOXIA-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887657#comment-17887657
]
Konrad Windszus commented on DOXIA-747:
---
Fixed in
https://github.com/apache/maven-doxia/commit/b054e5496398f3e3ab74aa50738c3f3b203d50c6.
> MarkdownSink: Section headings must be located at the beginning of a line
> -
>
> Key: DOXIA-747
> URL: https://issues.apache.org/jira/browse/DOXIA-747
> Project: Maven Doxia
> Issue Type: Bug
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.0.1
>
>
> If currently a {{Sink.text()}} is followed by a {{Sink.sectionTitle(...)}}
> with some text it is not emitted on a dedicated line through the
> {{MarkdownSink}}.
> However according to https://spec.commonmark.org/0.31.2/#atx-headings
> {quote} The opening # character may be preceded by up to three spaces of
> indentation {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7982] IT’s for transitive dependency management [maven-integration-testing]
gnodet closed pull request #379: [MNG-7982] IT’s for transitive dependency management URL: https://github.com/apache/maven-integration-testing/pull/379 -- 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
Re: [PR] [MNG-7982] IT’s for transitive dependency management [maven-integration-testing]
gnodet commented on PR #379: URL: https://github.com/apache/maven-integration-testing/pull/379#issuecomment-2400803258 > > @DidierLoiseau could you align the branch names for [this PR](https://github.com/apache/maven-integration-testing/pull/379) and [apache/maven#1785](https://github.com/apache/maven/pull/1785), this will allow running #1785 using the new ITs, else it will use master. > > I see you have created #384 and [apache/maven#1788](https://github.com/apache/maven/pull/1788), so I guess this isn’t necessary anymore? Right -- 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
Re: [PR] [MNG-8295] Dependency Manager Transitivity (now default) handles dependency management inconsistently [maven]
gnodet closed pull request #1785: [MNG-8295] Dependency Manager Transitivity (now default) handles dependency management inconsistently URL: https://github.com/apache/maven/pull/1785 -- 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
Re: [PR] [MNG-8295] Dependency Manager Transitivity (now default) handles dependency management inconsistently [maven]
gnodet commented on PR #1785: URL: https://github.com/apache/maven/pull/1785#issuecomment-2400804471 Superseded by https://github.com/apache/maven/pull/1788 -- 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] (DOXIA-748) Support file filtering in Doxia ParserModule
[
https://issues.apache.org/jira/browse/DOXIA-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887705#comment-17887705
]
Abel Salgado Romero commented on DOXIA-748:
---
Thanks, much appreciated! I was able to get something with
{quote}
**/_*.*,**/_*
{quote}
I could not make it to ignore folders though. But I think now that I am trying
to enforce the conventions from the AsciidoctorMojo in the Site module, and
that's probably not a good idea.
I'll document the differences and suggest the `moduleExcludes`.
Thanks again
> Support file filtering in Doxia ParserModule
>
>
> Key: DOXIA-748
> URL: https://issues.apache.org/jira/browse/DOXIA-748
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.0.0
>Reporter: Abel Salgado Romero
>Priority: Minor
>
> When defining a module one can define the file extensions to process.
> However, more complex scenarios require more than a extension.
> For example, in the [Asciidoctor
> module|https://github.com/asciidoctor/asciidoctor-maven-plugin/issues] it's
> possible to have "hidden" (use _ prefix) files that are not to be converted
> directly, instead these are to be included in others.
> My first though is to be able to pass a `FilenameFilter` in the constructor.
> The filter would be matched against files that comply with the file
> extensions to confirm whether these should be processed or not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (DOXIA-748) Support file filtering in Doxia ParserModule
[
https://issues.apache.org/jira/browse/DOXIA-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887705#comment-17887705
]
Abel Salgado Romero edited comment on DOXIA-748 at 10/8/24 8:45 PM:
Thanks, much appreciated! I was able to get something with
{quote}
**/_*.*,**/_*
{quote}
I could not make it to ignore folders though. But I think now that I am trying
to enforce the conventions from the AsciidoctorMojo in the Site module, and
that's probably not a good idea.
I'll document the differences and suggest the `moduleExcludes`.
Thanks again, feel free to close this issue
was (Author: abel s.romero):
Thanks, much appreciated! I was able to get something with
{quote}
**/_*.*,**/_*
{quote}
I could not make it to ignore folders though. But I think now that I am trying
to enforce the conventions from the AsciidoctorMojo in the Site module, and
that's probably not a good idea.
I'll document the differences and suggest the `moduleExcludes`.
Thanks again
> Support file filtering in Doxia ParserModule
>
>
> Key: DOXIA-748
> URL: https://issues.apache.org/jira/browse/DOXIA-748
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.0.0
>Reporter: Abel Salgado Romero
>Priority: Minor
>
> When defining a module one can define the file extensions to process.
> However, more complex scenarios require more than a extension.
> For example, in the [Asciidoctor
> module|https://github.com/asciidoctor/asciidoctor-maven-plugin/issues] it's
> possible to have "hidden" (use _ prefix) files that are not to be converted
> directly, instead these are to be included in others.
> My first though is to be able to pass a `FilenameFilter` in the constructor.
> The filter would be matched against files that comply with the file
> extensions to confirm whether these should be processed or not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-748) Support file filtering in Doxia ParserModule
[ https://issues.apache.org/jira/browse/DOXIA-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887498#comment-17887498 ] Michael Osipov commented on DOXIA-748: -- Yeah, those underscore files are very nice. We need to extend the API, pity that you did not report before GA. > Support file filtering in Doxia ParserModule > > > Key: DOXIA-748 > URL: https://issues.apache.org/jira/browse/DOXIA-748 > Project: Maven Doxia > Issue Type: Improvement > Components: Core >Affects Versions: 2.0.0 >Reporter: Abel Salgado Romero >Priority: Minor > > When defining a module one can define the file extensions to process. > However, more complex scenarios require more than a extension. > For example, in the [Asciidoctor > module|https://github.com/asciidoctor/asciidoctor-maven-plugin/issues] it's > possible to have "hidden" (use _ prefix) files that are not to be converted > directly, instead these are to be included in others. > My first though is to be able to pass a `FilenameFilter` in the constructor. > The filter would be matched against files that comply with the file > extensions to confirm whether these should be processed or not. -- This message was sent by Atlassian Jira (v8.20.10#820010)
