[jira] [Created] (MNG-8033) versions:set does not consider relocations
Christoph Läubrich created MNG-8033:
---
Summary: versions:set does not consider relocations
Key: MNG-8033
URL: https://issues.apache.org/jira/browse/MNG-8033
Project: Maven
Issue Type: Bug
Reporter: Christoph Läubrich
If one performs a {code}mvn versions:set -DnewVersion=<..>{code} then items in
a relocation section are not updated e.g. this should both be updated if
version matches:
{code}
http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";
xmlns="http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
4.0.0
tycho-extras
org.eclipse.tycho.extras
4.0.5-SNAPSHOT
tycho-eclipserun-plugin
maven-plugin
${minimal-maven-version}
org.eclipse.tycho
tycho-eclipse-plugin
4.0.5-SNAPSHOT
The eclipse-run mojo is now part of the
tycho-eclipse-plugin
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[I] How long will it take to support packaging and running in Jenkins? [maven-mvnd]
ErQire opened a new issue, #906: URL: https://github.com/apache/maven-mvnd/issues/906 May I ask the developer a question? I think it would be very interesting and important if we could build and execute in Jenkins. The Maven packaging in the original version is very slow, so it would be great to know which version will support the use of Jenkins and whether it can be used in a production environment. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MNG-8034) User properties do not correctly override
Tamas Cservenak created MNG-8034:
Summary: User properties do not correctly override
Key: MNG-8034
URL: https://issues.apache.org/jira/browse/MNG-8034
Project: Maven
Issue Type: Bug
Components: Core
Affects Versions: 3.9.6
Reporter: Tamas Cservenak
It seems that user properties are unable to correctly override in certain
cases. Am actually unsure is this Surefire or Maven Core issue at all.
Setup:
* parent POM enlists surefire plugin in build/pluginMgmt and sets
configuration {{failIfNoTests=true}}
* child module uses surefire to execute tests
Project set up like this is NOT BUILDABLE without tests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8034) User properties do not correctly override
[
https://issues.apache.org/jira/browse/MNG-8034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8034:
-
Description:
It seems that user properties are unable to correctly override in certain
cases. Am actually unsure is this Surefire or Maven Core issue at all.
Setup:
* parent POM enlists surefire plugin in build/pluginMgmt and sets
configuration {{failIfNoTests=true}}
* child module uses surefire to execute tests
Project set up like this is NOT BUILDABLE without tests.
Reproducer: [https://github.com/cstamas/mng-8034]
Steps:
* build the project from top: {{mvn clean package}} => OK (and UTs run)
* now try to build {{mvn clean package -Dtest=void}} => surefire fails, tells
to set {{-Dsurefire.failIfNoSpecifiedTests=false}}
* set it {{mvn clean package -Dtest=void
-Dsurefire.failIfNoSpecifiedTests=false}} => surefire fails, tells to set
{{-DfailIfNoTests=false}}
* set it {{mvn clean package -Dtest=void
-Dsurefire.failIfNoSpecifiedTests=false -DfailIfNoTests=false}} => surefire
fails, tells to set thing from step 3 (endless loop), basically the user
property we set in 3rd step is not detected at all?
was:
It seems that user properties are unable to correctly override in certain
cases. Am actually unsure is this Surefire or Maven Core issue at all.
Setup:
* parent POM enlists surefire plugin in build/pluginMgmt and sets
configuration {{failIfNoTests=true}}
* child module uses surefire to execute tests
Project set up like this is NOT BUILDABLE without tests.
> User properties do not correctly override
> -
>
> Key: MNG-8034
> URL: https://issues.apache.org/jira/browse/MNG-8034
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.6
>Reporter: Tamas Cservenak
>Priority: Major
>
> It seems that user properties are unable to correctly override in certain
> cases. Am actually unsure is this Surefire or Maven Core issue at all.
> Setup:
> * parent POM enlists surefire plugin in build/pluginMgmt and sets
> configuration {{failIfNoTests=true}}
> * child module uses surefire to execute tests
> Project set up like this is NOT BUILDABLE without tests.
> Reproducer: [https://github.com/cstamas/mng-8034]
> Steps:
> * build the project from top: {{mvn clean package}} => OK (and UTs run)
> * now try to build {{mvn clean package -Dtest=void}} => surefire fails,
> tells to set {{-Dsurefire.failIfNoSpecifiedTests=false}}
> * set it {{mvn clean package -Dtest=void
> -Dsurefire.failIfNoSpecifiedTests=false}} => surefire fails, tells to set
> {{-DfailIfNoTests=false}}
> * set it {{mvn clean package -Dtest=void
> -Dsurefire.failIfNoSpecifiedTests=false -DfailIfNoTests=false}} => surefire
> fails, tells to set thing from step 3 (endless loop), basically the user
> property we set in 3rd step is not detected at all?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8033) versions:set does not consider relocations
[
https://issues.apache.org/jira/browse/MNG-8033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811799#comment-17811799
]
Slawomir Jaranowski commented on MNG-8033:
--
# What output do you expect for your example?
# versions-m-p is a separated project at MojoHaus, so issues should be reported
here: https://github.com/mojohaus/versions/issues
> versions:set does not consider relocations
> --
>
> Key: MNG-8033
> URL: https://issues.apache.org/jira/browse/MNG-8033
> Project: Maven
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> If one performs a {code}mvn versions:set -DnewVersion=<..>{code} then items
> in a relocation section are not updated e.g. this should both be updated if
> version matches:
> {code}
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";
> xmlns="http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> 4.0.0
>
> tycho-extras
> org.eclipse.tycho.extras
> 4.0.5-SNAPSHOT
>
> tycho-eclipserun-plugin
> maven-plugin
>
> ${minimal-maven-version}
>
>
>
> org.eclipse.tycho
> tycho-eclipse-plugin
> 4.0.5-SNAPSHOT
> The eclipse-run mojo is now part of the
> tycho-eclipse-plugin
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8034) User properties do not correctly override
[
https://issues.apache.org/jira/browse/MNG-8034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8034:
-
Affects Version/s: 4.0.0-alpha-12
> User properties do not correctly override
> -
>
> Key: MNG-8034
> URL: https://issues.apache.org/jira/browse/MNG-8034
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.6, 4.0.0-alpha-12
>Reporter: Tamas Cservenak
>Priority: Major
>
> It seems that user properties are unable to correctly override in certain
> cases. Am actually unsure is this Surefire or Maven Core issue at all.
> Setup:
> * parent POM enlists surefire plugin in build/pluginMgmt and sets
> configuration {{failIfNoTests=true}}
> * child module uses surefire to execute tests
> Project set up like this is NOT BUILDABLE without tests.
> Reproducer: [https://github.com/cstamas/mng-8034]
> Steps:
> * build the project from top: {{mvn clean package}} => OK (and UTs run)
> * now try to build {{mvn clean package -Dtest=void}} => surefire fails,
> tells to set {{-Dsurefire.failIfNoSpecifiedTests=false}}
> * set it {{mvn clean package -Dtest=void
> -Dsurefire.failIfNoSpecifiedTests=false}} => surefire fails, tells to set
> {{-DfailIfNoTests=false}}
> * set it {{mvn clean package -Dtest=void
> -Dsurefire.failIfNoSpecifiedTests=false -DfailIfNoTests=false}} => surefire
> fails, tells to set thing from step 3 (endless loop), basically the user
> property we set in 3rd step is not detected at all?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [I] How long will it take to support packaging and running in Jenkins? [maven-mvnd]
ppalaga commented on issue #906: URL: https://github.com/apache/maven-mvnd/issues/906#issuecomment-1914357232 `mvnd` is primarily an interactive tool for Java developers. It was not designed for Jenkins and similar environments. When doing it anyway, you should consider that deamon re-use may cause serious build reproducibility issues. Please read more in other issues, e.g. here: https://github.com/apache/maven-mvnd/issues/704 To overcome the reproducibility issue, but still profit from parallel builds and sane console output, you may want to try `mvnd.sh` with the `-Dmvnd.noDaemon` flag. Check `mvnd --help` for more info. -- 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: [I] How long will it take to support packaging and running in Jenkins? [maven-mvnd]
ppalaga closed issue #906: How long will it take to support packaging and running in Jenkins? URL: https://github.com/apache/maven-mvnd/issues/906 -- 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: [I] Non-resolvable parent POM [maven-mvnd]
ppalaga closed issue #905: Non-resolvable parent POM URL: https://github.com/apache/maven-mvnd/issues/905 -- 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: [I] How long will it take to support packaging and running in Jenkins? [maven-mvnd]
ppalaga closed issue #906: How long will it take to support packaging and running in Jenkins? URL: https://github.com/apache/maven-mvnd/issues/906 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-8034) User properties do not correctly override
[
https://issues.apache.org/jira/browse/MNG-8034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811809#comment-17811809
]
Tamas Cservenak commented on MNG-8034:
--
Ok, it was me: this is defined as such (hence "affects" all Maven versions).
When you _configure_ something in parent, that cannot be overridden by user
properties (that MAY provide value if no configuration present), but in this
case explicit configuration (in parent) "wins".
Still, I consider this as "bad practice": configuring plugins in parent POMs
should happen with caution, and leaving some options for parent POM users,
hence indirection via property is "best practice" (define a project property
with value you want, and use that in plugin configuration, instead to use final
value).
Overriding these configurations are possible only in child POM plugin
configuration section, so requires more work and is not dynamic anymore.
> User properties do not correctly override
> -
>
> Key: MNG-8034
> URL: https://issues.apache.org/jira/browse/MNG-8034
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.6, 4.0.0-alpha-12
>Reporter: Tamas Cservenak
>Priority: Major
>
> It seems that user properties are unable to correctly override in certain
> cases. Am actually unsure is this Surefire or Maven Core issue at all.
> Setup:
> * parent POM enlists surefire plugin in build/pluginMgmt and sets
> configuration {{failIfNoTests=true}}
> * child module uses surefire to execute tests
> Project set up like this is NOT BUILDABLE without tests.
> Reproducer: [https://github.com/cstamas/mng-8034]
> Steps:
> * build the project from top: {{mvn clean package}} => OK (and UTs run)
> * now try to build {{mvn clean package -Dtest=void}} => surefire fails,
> tells to set {{-Dsurefire.failIfNoSpecifiedTests=false}}
> * set it {{mvn clean package -Dtest=void
> -Dsurefire.failIfNoSpecifiedTests=false}} => surefire fails, tells to set
> {{-DfailIfNoTests=false}}
> * set it {{mvn clean package -Dtest=void
> -Dsurefire.failIfNoSpecifiedTests=false -DfailIfNoTests=false}} => surefire
> fails, tells to set thing from step 3 (endless loop), basically the user
> property we set in 3rd step is not detected at all?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-8034) User properties do not correctly override
[
https://issues.apache.org/jira/browse/MNG-8034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MNG-8034.
Resolution: Not A Bug
> User properties do not correctly override
> -
>
> Key: MNG-8034
> URL: https://issues.apache.org/jira/browse/MNG-8034
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.6, 4.0.0-alpha-12
>Reporter: Tamas Cservenak
>Priority: Major
>
> It seems that user properties are unable to correctly override in certain
> cases. Am actually unsure is this Surefire or Maven Core issue at all.
> Setup:
> * parent POM enlists surefire plugin in build/pluginMgmt and sets
> configuration {{failIfNoTests=true}}
> * child module uses surefire to execute tests
> Project set up like this is NOT BUILDABLE without tests.
> Reproducer: [https://github.com/cstamas/mng-8034]
> Steps:
> * build the project from top: {{mvn clean package}} => OK (and UTs run)
> * now try to build {{mvn clean package -Dtest=void}} => surefire fails,
> tells to set {{-Dsurefire.failIfNoSpecifiedTests=false}}
> * set it {{mvn clean package -Dtest=void
> -Dsurefire.failIfNoSpecifiedTests=false}} => surefire fails, tells to set
> {{-DfailIfNoTests=false}}
> * set it {{mvn clean package -Dtest=void
> -Dsurefire.failIfNoSpecifiedTests=false -DfailIfNoTests=false}} => surefire
> fails, tells to set thing from step 3 (endless loop), basically the user
> property we set in 3rd step is not detected at all?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8034) User properties do not correctly override
[
https://issues.apache.org/jira/browse/MNG-8034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811811#comment-17811811
]
Tamas Cservenak commented on MNG-8034:
--
Related problem is that in this case surefire (but this is not surefire
problem!) advises me to do something that simply cannot work (as parent
configures something).
> User properties do not correctly override
> -
>
> Key: MNG-8034
> URL: https://issues.apache.org/jira/browse/MNG-8034
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.6, 4.0.0-alpha-12
>Reporter: Tamas Cservenak
>Priority: Major
>
> It seems that user properties are unable to correctly override in certain
> cases. Am actually unsure is this Surefire or Maven Core issue at all.
> Setup:
> * parent POM enlists surefire plugin in build/pluginMgmt and sets
> configuration {{failIfNoTests=true}}
> * child module uses surefire to execute tests
> Project set up like this is NOT BUILDABLE without tests.
> Reproducer: [https://github.com/cstamas/mng-8034]
> Steps:
> * build the project from top: {{mvn clean package}} => OK (and UTs run)
> * now try to build {{mvn clean package -Dtest=void}} => surefire fails,
> tells to set {{-Dsurefire.failIfNoSpecifiedTests=false}}
> * set it {{mvn clean package -Dtest=void
> -Dsurefire.failIfNoSpecifiedTests=false}} => surefire fails, tells to set
> {{-DfailIfNoTests=false}}
> * set it {{mvn clean package -Dtest=void
> -Dsurefire.failIfNoSpecifiedTests=false -DfailIfNoTests=false}} => surefire
> fails, tells to set thing from step 3 (endless loop), basically the user
> property we set in 3rd step is not detected at all?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJLINK-76) Upgrade maven-plugin parent to 41
[ https://issues.apache.org/jira/browse/MJLINK-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811859#comment-17811859 ] ASF GitHub Bot commented on MJLINK-76: -- slachiewicz opened a new pull request, #193: URL: https://github.com/apache/maven-jlink-plugin/pull/193 (no comment) > Upgrade maven-plugin parent to 41 > - > > Key: MJLINK-76 > URL: https://issues.apache.org/jira/browse/MJLINK-76 > Project: Maven JLink Plugin > Issue Type: Improvement >Affects Versions: 3.1.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8035) Upgrade Resolver version to 2.0.0-alpha-7
Tamas Cservenak created MNG-8035: Summary: Upgrade Resolver version to 2.0.0-alpha-7 Key: MNG-8035 URL: https://issues.apache.org/jira/browse/MNG-8035 Project: Maven Issue Type: Dependency upgrade Components: Dependencies Reporter: Tamas Cservenak Fix For: 4.0.0, 4.0.0-alpha-13 Upgrade Resolver version to 2.0.0-alpha-7. Sort out TODOs and related stuff as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [MNG-8035] Update to Resolver 2.0.0-alpha-7 [maven]
cstamas opened a new pull request, #1394: URL: https://github.com/apache/maven/pull/1394 This is also one simple change "sneaked in" for RAT, to ignore local `.mvn` that is unrelated to all this, but does not make any harm. In turn, it allows dev local checkout to have various stuff set without decorating those with headers or fighing RAT plugin. --- https://issues.apache.org/jira/browse/MNG-8035 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-8035) Upgrade Resolver version to 2.0.0-alpha-7
[ https://issues.apache.org/jira/browse/MNG-8035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811881#comment-17811881 ] ASF GitHub Bot commented on MNG-8035: - cstamas opened a new pull request, #1394: URL: https://github.com/apache/maven/pull/1394 This is also one simple change "sneaked in" for RAT, to ignore local `.mvn` that is unrelated to all this, but does not make any harm. In turn, it allows dev local checkout to have various stuff set without decorating those with headers or fighing RAT plugin. --- https://issues.apache.org/jira/browse/MNG-8035 > Upgrade Resolver version to 2.0.0-alpha-7 > - > > Key: MNG-8035 > URL: https://issues.apache.org/jira/browse/MNG-8035 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-13 > > > Upgrade Resolver version to 2.0.0-alpha-7. Sort out TODOs and related stuff > as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARCHETYPE-654) Clarify repository/server id used for custom repository catalog
Konrad Windszus created ARCHETYPE-654:
-
Summary: Clarify repository/server id used for custom repository
catalog
Key: ARCHETYPE-654
URL: https://issues.apache.org/jira/browse/ARCHETYPE-654
Project: Maven Archetype
Issue Type: Improvement
Components: Generator
Affects Versions: 3.2.1
Reporter: Konrad Windszus
According to
https://maven.apache.org/archetype/maven-archetype-plugin/generate-mojo.html#archetypeArtifactId
a repository with id {{archetype}} can be used to resolve catalogs from a
remote repository. The same id is supposed to be used in case that repo uses
authentication. This contradicts the FAQ entry at
https://maven.apache.org/archetype/maven-archetype-plugin/faq.html#authentication
which states that the id is supposed to be {{-repo}}
which would require one server section per archetype in a repo requiring
authentication.
Also it is unclear which value {{archetypeArtifact}} should be set to to
consider the catalog from a specific remote repository as {{remote}} is the
shortcut for Maven Central repository or its mirror. But in case there is no
mirror for Maven Central but rather a dedicated catalog of custom archetypes
maintained in a a custom repo the value is unclear.
Also adding a repository with id {{archetype}} to settings would not only
affect m-archetype-p but every resolution with Maven.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARCHETYPE-654) Clarify repository/server id used for custom repository catalog
[
https://issues.apache.org/jira/browse/ARCHETYPE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated ARCHETYPE-654:
--
Description:
According to
https://maven.apache.org/archetype/maven-archetype-plugin/generate-mojo.html#archetypeArtifactId
a repository with id {{archetype}} can be used to resolve catalogs from a
remote repository. The same id is supposed to be used in case that repo uses
authentication. This contradicts the FAQ entry at
https://maven.apache.org/archetype/maven-archetype-plugin/faq.html#authentication
which states that the id is supposed to be {{-repo}}
which would require one server section per archetype in a repo requiring
authentication.
Also it is unclear which value {{archetypeArtifact}} should be set to to
consider the catalog from a specific remote repository as
bq. {{remote}} is the shortcut for Maven Central repository or its mirror.
But in case there is no mirror for Maven Central but rather a dedicated catalog
of custom archetypes maintained in a a custom repo the value is unclear.
Also adding a repository with id {{archetype}} to settings would not only
affect m-archetype-p but every resolution with Maven.
was:
According to
https://maven.apache.org/archetype/maven-archetype-plugin/generate-mojo.html#archetypeArtifactId
a repository with id {{archetype}} can be used to resolve catalogs from a
remote repository. The same id is supposed to be used in case that repo uses
authentication. This contradicts the FAQ entry at
https://maven.apache.org/archetype/maven-archetype-plugin/faq.html#authentication
which states that the id is supposed to be {{-repo}}
which would require one server section per archetype in a repo requiring
authentication.
Also it is unclear which value {{archetypeArtifact}} should be set to to
consider the catalog from a specific remote repository as {{remote}} is the
shortcut for Maven Central repository or its mirror. But in case there is no
mirror for Maven Central but rather a dedicated catalog of custom archetypes
maintained in a a custom repo the value is unclear.
Also adding a repository with id {{archetype}} to settings would not only
affect m-archetype-p but every resolution with Maven.
> Clarify repository/server id used for custom repository catalog
> ---
>
> Key: ARCHETYPE-654
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-654
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Generator
>Affects Versions: 3.2.1
>Reporter: Konrad Windszus
>Priority: Major
>
> According to
> https://maven.apache.org/archetype/maven-archetype-plugin/generate-mojo.html#archetypeArtifactId
> a repository with id {{archetype}} can be used to resolve catalogs from a
> remote repository. The same id is supposed to be used in case that repo uses
> authentication. This contradicts the FAQ entry at
> https://maven.apache.org/archetype/maven-archetype-plugin/faq.html#authentication
> which states that the id is supposed to be {{-repo}}
> which would require one server section per archetype in a repo requiring
> authentication.
> Also it is unclear which value {{archetypeArtifact}} should be set to to
> consider the catalog from a specific remote repository as
> bq. {{remote}} is the shortcut for Maven Central repository or its mirror.
> But in case there is no mirror for Maven Central but rather a dedicated
> catalog of custom archetypes maintained in a a custom repo the value is
> unclear.
> Also adding a repository with id {{archetype}} to settings would not only
> affect m-archetype-p but every resolution with Maven.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARCHETYPE-654) Clarify repository/server id used for custom repository catalog
[
https://issues.apache.org/jira/browse/ARCHETYPE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811907#comment-17811907
]
Konrad Windszus commented on ARCHETYPE-654:
---
According to
[https://github.com/apache/maven-archetype/blob/3a2b725198c3823fd5d7e9f88b665b2e4515a202/archetype-common/src/main/java/org/apache/maven/archetype/source/RemoteCatalogArchetypeDataSource.java#L86C31-L86C54]
the repository id is
# `archetype`/the mirror id for repo `archetype` or
# `central`/the mirror id for repo `central`
That means that indeed the `settings.xml` would need to have an (enabled)
repository with id `archetype` which would basically prevent using two
different custom catalogs.
> Clarify repository/server id used for custom repository catalog
> ---
>
> Key: ARCHETYPE-654
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-654
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Generator
>Affects Versions: 3.2.1
>Reporter: Konrad Windszus
>Priority: Major
>
> According to
> https://maven.apache.org/archetype/maven-archetype-plugin/generate-mojo.html#archetypeArtifactId
> a repository with id {{archetype}} can be used to resolve catalogs from a
> remote repository. The same id is supposed to be used in case that repo uses
> authentication. This contradicts the FAQ entry at
> https://maven.apache.org/archetype/maven-archetype-plugin/faq.html#authentication
> which states that the id is supposed to be {{-repo}}
> which would require one server section per archetype in a repo requiring
> authentication.
> Also it is unclear which value {{archetypeArtifact}} should be set to to
> consider the catalog from a specific remote repository as
> bq. {{remote}} is the shortcut for Maven Central repository or its mirror.
> But in case there is no mirror for Maven Central but rather a dedicated
> catalog of custom archetypes maintained in a a custom repo the value is
> unclear.
> Also adding a repository with id {{archetype}} to settings would not only
> affect m-archetype-p but every resolution with Maven.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (ARCHETYPE-655) Get rid of Wagon API to download catalogs
Konrad Windszus created ARCHETYPE-655:
-
Summary: Get rid of Wagon API to download catalogs
Key: ARCHETYPE-655
URL: https://issues.apache.org/jira/browse/ARCHETYPE-655
Project: Maven Archetype
Issue Type: Improvement
Reporter: Konrad Windszus
Currently the {{RemoteCatalogArchetypeDataSource}} relies on Wagon API to
download the catalog from a Maven repository
(https://github.com/apache/maven-archetype/blob/3a2b725198c3823fd5d7e9f88b665b2e4515a202/archetype-common/src/main/java/org/apache/maven/archetype/source/RemoteCatalogArchetypeDataSource.java#L127-L149).
Instead the Maven Resolver API should be used directly. At the same time some
more flexibility with regards to repository ids would be beneficial (in order
to support multiple custom catalogs or to reuse existing repository/server
sections in the {{{}settings.xml{}}})
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (ARCHETYPE-654) Clarify repository/server id used for custom repository catalog
[
https://issues.apache.org/jira/browse/ARCHETYPE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811907#comment-17811907
]
Konrad Windszus edited comment on ARCHETYPE-654 at 1/29/24 2:25 PM:
According to
[https://github.com/apache/maven-archetype/blob/3a2b725198c3823fd5d7e9f88b665b2e4515a202/archetype-common/src/main/java/org/apache/maven/archetype/source/RemoteCatalogArchetypeDataSource.java#L86C31-L86C54]
the repository id is
# {{archetype }}/ the mirror id for repo {{archetype}} or
# {{central / }}the mirror id for repo {{central}}
That means that indeed the {{settings.xml}} would need to have an (enabled)
repository with id {{archetype}} which would basically prevent using two
different custom catalogs.
was (Author: kwin):
According to
[https://github.com/apache/maven-archetype/blob/3a2b725198c3823fd5d7e9f88b665b2e4515a202/archetype-common/src/main/java/org/apache/maven/archetype/source/RemoteCatalogArchetypeDataSource.java#L86C31-L86C54]
the repository id is
# `archetype`/the mirror id for repo `archetype` or
# `central`/the mirror id for repo `central`
That means that indeed the `settings.xml` would need to have an (enabled)
repository with id `archetype` which would basically prevent using two
different custom catalogs.
> Clarify repository/server id used for custom repository catalog
> ---
>
> Key: ARCHETYPE-654
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-654
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Generator
>Affects Versions: 3.2.1
>Reporter: Konrad Windszus
>Priority: Major
>
> According to
> https://maven.apache.org/archetype/maven-archetype-plugin/generate-mojo.html#archetypeArtifactId
> a repository with id {{archetype}} can be used to resolve catalogs from a
> remote repository. The same id is supposed to be used in case that repo uses
> authentication. This contradicts the FAQ entry at
> https://maven.apache.org/archetype/maven-archetype-plugin/faq.html#authentication
> which states that the id is supposed to be {{-repo}}
> which would require one server section per archetype in a repo requiring
> authentication.
> Also it is unclear which value {{archetypeArtifact}} should be set to to
> consider the catalog from a specific remote repository as
> bq. {{remote}} is the shortcut for Maven Central repository or its mirror.
> But in case there is no mirror for Maven Central but rather a dedicated
> catalog of custom archetypes maintained in a a custom repo the value is
> unclear.
> Also adding a repository with id {{archetype}} to settings would not only
> affect m-archetype-p but every resolution with Maven.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (ARCHETYPE-654) Clarify repository/server id used for custom repository catalog
[
https://issues.apache.org/jira/browse/ARCHETYPE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811907#comment-17811907
]
Konrad Windszus edited comment on ARCHETYPE-654 at 1/29/24 2:25 PM:
According to
[https://github.com/apache/maven-archetype/blob/3a2b725198c3823fd5d7e9f88b665b2e4515a202/archetype-common/src/main/java/org/apache/maven/archetype/source/RemoteCatalogArchetypeDataSource.java#L86C31-L86C54]
the repository id is
# {{archetype}} / the mirror id for repo {{archetype}} or
# {{central}} / the mirror id for repo {{central}}
That means that indeed the {{settings.xml}} would need to have an (enabled)
repository with id {{archetype}} which would basically prevent using two
different custom catalogs.
was (Author: kwin):
According to
[https://github.com/apache/maven-archetype/blob/3a2b725198c3823fd5d7e9f88b665b2e4515a202/archetype-common/src/main/java/org/apache/maven/archetype/source/RemoteCatalogArchetypeDataSource.java#L86C31-L86C54]
the repository id is
# {{archetype }}/ the mirror id for repo {{archetype}} or
# {{central / }}the mirror id for repo {{central}}
That means that indeed the {{settings.xml}} would need to have an (enabled)
repository with id {{archetype}} which would basically prevent using two
different custom catalogs.
> Clarify repository/server id used for custom repository catalog
> ---
>
> Key: ARCHETYPE-654
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-654
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Generator
>Affects Versions: 3.2.1
>Reporter: Konrad Windszus
>Priority: Major
>
> According to
> https://maven.apache.org/archetype/maven-archetype-plugin/generate-mojo.html#archetypeArtifactId
> a repository with id {{archetype}} can be used to resolve catalogs from a
> remote repository. The same id is supposed to be used in case that repo uses
> authentication. This contradicts the FAQ entry at
> https://maven.apache.org/archetype/maven-archetype-plugin/faq.html#authentication
> which states that the id is supposed to be {{-repo}}
> which would require one server section per archetype in a repo requiring
> authentication.
> Also it is unclear which value {{archetypeArtifact}} should be set to to
> consider the catalog from a specific remote repository as
> bq. {{remote}} is the shortcut for Maven Central repository or its mirror.
> But in case there is no mirror for Maven Central but rather a dedicated
> catalog of custom archetypes maintained in a a custom repo the value is
> unclear.
> Also adding a repository with id {{archetype}} to settings would not only
> affect m-archetype-p but every resolution with Maven.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8035] Update to Resolver 2.0.0-alpha-7 [maven]
cstamas merged PR #1394: URL: https://github.com/apache/maven/pull/1394 -- 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] [Closed] (MNG-8035) Upgrade Resolver version to 2.0.0-alpha-7
[ https://issues.apache.org/jira/browse/MNG-8035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MNG-8035. Resolution: Fixed > Upgrade Resolver version to 2.0.0-alpha-7 > - > > Key: MNG-8035 > URL: https://issues.apache.org/jira/browse/MNG-8035 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-13 > > > Upgrade Resolver version to 2.0.0-alpha-7. Sort out TODOs and related stuff > as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8035) Upgrade Resolver version to 2.0.0-alpha-7
[ https://issues.apache.org/jira/browse/MNG-8035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811944#comment-17811944 ] ASF GitHub Bot commented on MNG-8035: - cstamas merged PR #1394: URL: https://github.com/apache/maven/pull/1394 > Upgrade Resolver version to 2.0.0-alpha-7 > - > > Key: MNG-8035 > URL: https://issues.apache.org/jira/browse/MNG-8035 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-13 > > > Upgrade Resolver version to 2.0.0-alpha-7. Sort out TODOs and related stuff > as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7954) Provide a cleaner DI api
[
https://issues.apache.org/jira/browse/MNG-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7954:
-
Fix Version/s: 4.0.0-alpha-13
> Provide a cleaner DI api
>
>
> Key: MNG-7954
> URL: https://issues.apache.org/jira/browse/MNG-7954
> Project: Maven
> Issue Type: New Feature
> Components: API
>Reporter: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-13
>
>
> With https://issues.apache.org/jira/browse/MNG-7947 the {{jakarta.inject}}
> package has been brought into the API.
> We need a cleaner way and not depend on any third party library if possible.
> The
> [{{SessionScope}}|https://github.com/apache/maven/blob/23bca281fcd084ac21d80f5a2950dcee30a19080/maven-core/src/main/java/org/apache/maven/session/scope/internal/SessionScope.java#L123-L125]
> would also require some cleaning to avoid having to rely on
> {{{}(org.eclipse.sisu|javax.enterprise.inject|jakarta.enterprise.inject).Typed{}}}.
> For complete DI, we may also miss the sisu annotations
> ({{{}PostConstruct{}}}, {{PreDestroy}} and {{Priority}} and
> {{{}EagerSingleton{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8036) Upgrade to JLine 3.25.1
Guillaume Nodet created MNG-8036: Summary: Upgrade to JLine 3.25.1 Key: MNG-8036 URL: https://issues.apache.org/jira/browse/MNG-8036 Project: Maven Issue Type: Dependency upgrade Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 4.0.0, 4.0.0-alpha-13 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8022) 'mvn -version' results in NullPointerException
[
https://issues.apache.org/jira/browse/MNG-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-8022:
-
Fix Version/s: 4.0.0
> 'mvn -version' results in NullPointerException
> --
>
> Key: MNG-8022
> URL: https://issues.apache.org/jira/browse/MNG-8022
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 4.0.0-alpha-12
> Environment: Java version: 21.0.2, vendor: Oracle Corporation,
> runtime: C:\Program Files\Java\jdk-21
> Default locale: en_US, platform encoding: UTF-8
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"
>Reporter: Kedar Joshi
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-13
>
> Attachments: Exception.txt
>
>
> Running `mvn -version` with Maven 4.0.0-alpha-12 on Windows results in
> NullPointerException (see attached).
>
> However, same works as expected with *4.0.0-alpha-10*
>
> {code:java}
> C:\Users\Kedar>mvn -version
> Apache Maven 4.0.0-alpha-10 (89d3c0321dda868c432edf504f1884e6fd706f00)
> Maven home: C:\Users\Kedar\Programs\Maven-4.0
> Java version: 21.0.2, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk-21
> Default locale: en_US, platform encoding: UTF-8
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos" {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8036] [MNG-8017] [MNG-8022] Upgrade JLine to 3.25.1 [maven]
gnodet merged PR #1390: URL: https://github.com/apache/maven/pull/1390 -- 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] [Closed] (MNG-8022) 'mvn -version' results in NullPointerException
[
https://issues.apache.org/jira/browse/MNG-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-8022.
Resolution: Fixed
> 'mvn -version' results in NullPointerException
> --
>
> Key: MNG-8022
> URL: https://issues.apache.org/jira/browse/MNG-8022
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 4.0.0-alpha-12
> Environment: Java version: 21.0.2, vendor: Oracle Corporation,
> runtime: C:\Program Files\Java\jdk-21
> Default locale: en_US, platform encoding: UTF-8
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"
>Reporter: Kedar Joshi
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-13
>
> Attachments: Exception.txt
>
>
> Running `mvn -version` with Maven 4.0.0-alpha-12 on Windows results in
> NullPointerException (see attached).
>
> However, same works as expected with *4.0.0-alpha-10*
>
> {code:java}
> C:\Users\Kedar>mvn -version
> Apache Maven 4.0.0-alpha-10 (89d3c0321dda868c432edf504f1884e6fd706f00)
> Maven home: C:\Users\Kedar\Programs\Maven-4.0
> Java version: 21.0.2, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk-21
> Default locale: en_US, platform encoding: UTF-8
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos" {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-8036) Upgrade to JLine 3.25.1
[ https://issues.apache.org/jira/browse/MNG-8036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-8036. Resolution: Fixed > Upgrade to JLine 3.25.1 > --- > > Key: MNG-8036 > URL: https://issues.apache.org/jira/browse/MNG-8036 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-13 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8036) Upgrade to JLine 3.25.1
[ https://issues.apache.org/jira/browse/MNG-8036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811951#comment-17811951 ] ASF GitHub Bot commented on MNG-8036: - gnodet merged PR #1390: URL: https://github.com/apache/maven/pull/1390 > Upgrade to JLine 3.25.1 > --- > > Key: MNG-8036 > URL: https://issues.apache.org/jira/browse/MNG-8036 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-13 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8017) Maven fails at start with "Cannot run program "infocmp": error=2, No such file or directory"
[
https://issues.apache.org/jira/browse/MNG-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-8017.
Resolution: Fixed
> Maven fails at start with "Cannot run program "infocmp": error=2, No such
> file or directory"
>
>
> Key: MNG-8017
> URL: https://issues.apache.org/jira/browse/MNG-8017
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 4.0.0-alpha-12
> Environment: Apache Maven 4.0.0-alpha-13-SNAPSHOT
> (7f70467aa3e74a9bba602e5c61a0b5d33ae8f699)
> Maven home:
> /usr/home/mosipov/var/Projekte/apache-maven-4.0.0-alpha-13-SNAPSHOT
> Java version: 1.8.0_382, vendor: OpenJDK BSD Porting Team, runtime:
> /usr/local/openjdk8/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "freebsd", version: "13.2-release-p8", arch: "amd64", family: "unix"
>Reporter: Michael Osipov
>Assignee: Guillaume Nodet
>Priority: Critical
> Fix For: 4.0.0, 4.0.0-alpha-13
>
>
> From {{mvn -v}}:
> {noformat}
> mosipov@bsd1srv:/usr/home/mosipov/var/Projekte/maven (master =)
> $ ../apache-maven-4.0.0-alpha-13-SNAPSHOT/bin/mvn -v
> Jan 14, 2024 9:30:35 PM org.jline.utils.Log logr
> WARNUNG: Unable to retrieve infocmp for type xterm-color
> java.io.IOException: Cannot run program "infocmp": error=2, No such file or
> directory
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
> at org.jline.utils.InfoCmp.getInfoCmp(InfoCmp.java:544)
> at
> org.jline.terminal.impl.AbstractTerminal.parseInfoCmp(AbstractTerminal.java:207)
> at
> org.jline.terminal.impl.PosixSysTerminal.(PosixSysTerminal.java:47)
> at
> org.jline.terminal.impl.exec.ExecTerminalProvider.posixSysTerminal(ExecTerminalProvider.java:100)
> at
> org.jline.terminal.impl.exec.ExecTerminalProvider.sysTerminal(ExecTerminalProvider.java:66)
> at
> org.jline.terminal.TerminalBuilder.doBuild(TerminalBuilder.java:428)
> at org.jline.terminal.TerminalBuilder.build(TerminalBuilder.java:362)
> at
> org.apache.maven.cli.jline.MessageUtils.systemInstall(MessageUtils.java:47)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> Caused by: java.io.IOException: error=2, No such file or directory
> at java.lang.UNIXProcess.forkAndExec(Native Method)
> at java.lang.UNIXProcess.(UNIXProcess.java:251)
> at java.lang.ProcessImpl.start(ProcessImpl.java:134)
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
> ... 17 more
> Apache Maven 4.0.0-alpha-13-SNAPSHOT
> (7f70467aa3e74a9bba602e5c61a0b5d33ae8f699)
> Maven home:
> /usr/home/mosipov/var/Projekte/apache-maven-4.0.0-alpha-13-SNAPSHOT
> Java version: 1.8.0_382, vendor: OpenJDK BSD Porting Team, runtime:
> /usr/local/openjdk8/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "freebsd", version: "13.2-release-p8", arch: "amd64", family: "unix"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8029) improve documentation of mirror in settings
[ https://issues.apache.org/jira/browse/MNG-8029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811956#comment-17811956 ] ASF GitHub Bot commented on MNG-8029: - hboutemy opened a new pull request, #1395: URL: https://github.com/apache/maven/pull/1395 https://issues.apache.org/jira/browse/MNG-8029 > improve documentation of mirror in settings > --- > > Key: MNG-8029 > URL: https://issues.apache.org/jira/browse/MNG-8029 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.9.6, 4.0.0-alpha-12 >Reporter: Herve Boutemy >Priority: Major > Fix For: 3.9.7, 4.0.0-alpha-13 > > > reading > https://maven.apache.org/ref/3.9.6/maven-settings/settings.html#class_mirror > and comparing to > https://maven.apache.org/guides/mini/guide-mirror-settings.html > model documentation does not explain that mirrorOf is not just an id, but has > much more flexibility (since Maven versions to be clarified) > and id has no description > it's time to clarify > and also update "reference settings documentation" which is completely > obsolete on mirror: https://maven.apache.org/settings.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (ARCHETYPE-654) Clarify repository/server id used for custom repository catalog
[
https://issues.apache.org/jira/browse/ARCHETYPE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned ARCHETYPE-654:
-
Assignee: Konrad Windszus
> Clarify repository/server id used for custom repository catalog
> ---
>
> Key: ARCHETYPE-654
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-654
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Generator
>Affects Versions: 3.2.1
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> According to
> https://maven.apache.org/archetype/maven-archetype-plugin/generate-mojo.html#archetypeArtifactId
> a repository with id {{archetype}} can be used to resolve catalogs from a
> remote repository. The same id is supposed to be used in case that repo uses
> authentication. This contradicts the FAQ entry at
> https://maven.apache.org/archetype/maven-archetype-plugin/faq.html#authentication
> which states that the id is supposed to be {{-repo}}
> which would require one server section per archetype in a repo requiring
> authentication.
> Also it is unclear which value {{archetypeArtifact}} should be set to to
> consider the catalog from a specific remote repository as
> bq. {{remote}} is the shortcut for Maven Central repository or its mirror.
> But in case there is no mirror for Maven Central but rather a dedicated
> catalog of custom archetypes maintained in a a custom repo the value is
> unclear.
> Also adding a repository with id {{archetype}} to settings would not only
> affect m-archetype-p but every resolution with Maven.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARCHETYPE-654) Clarify repository/server id used for custom repository catalog
[
https://issues.apache.org/jira/browse/ARCHETYPE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812008#comment-17812008
]
ASF GitHub Bot commented on ARCHETYPE-654:
--
kwin opened a new pull request, #185:
URL: https://github.com/apache/maven-archetype/pull/185
(no comment)
> Clarify repository/server id used for custom repository catalog
> ---
>
> Key: ARCHETYPE-654
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-654
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Generator
>Affects Versions: 3.2.1
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> According to
> https://maven.apache.org/archetype/maven-archetype-plugin/generate-mojo.html#archetypeArtifactId
> a repository with id {{archetype}} can be used to resolve catalogs from a
> remote repository. The same id is supposed to be used in case that repo uses
> authentication. This contradicts the FAQ entry at
> https://maven.apache.org/archetype/maven-archetype-plugin/faq.html#authentication
> which states that the id is supposed to be {{-repo}}
> which would require one server section per archetype in a repo requiring
> authentication.
> Also it is unclear which value {{archetypeArtifact}} should be set to to
> consider the catalog from a specific remote repository as
> bq. {{remote}} is the shortcut for Maven Central repository or its mirror.
> But in case there is no mirror for Maven Central but rather a dedicated
> catalog of custom archetypes maintained in a a custom repo the value is
> unclear.
> Also adding a repository with id {{archetype}} to settings would not only
> affect m-archetype-p but every resolution with Maven.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [ARCHETYPE-654] Clarify used repository/server ids for catalog "remote" [maven-archetype]
kwin commented on code in PR #185: URL: https://github.com/apache/maven-archetype/pull/185#discussion_r1470033071 ## maven-archetype-plugin/src/site/fml/faq.fml: ## @@ -35,11 +35,13 @@ under the License. - How to generate a project from an archetype in an authenticated repository? + How to generate a project from an archetype in a custom (potentially authenticated) repository? -The server id used to download the artifact is [archetypeArtifactId]-repo: you have to Review Comment: this repo id is format is still used in https://github.com/apache/maven-archetype/blob/3a2b725198c3823fd5d7e9f88b665b2e4515a202/archetype-common/src/main/java/org/apache/maven/archetype/generator/DefaultArchetypeGenerator.java#L70 (i.e. for downloading the actual archetype (not the catalog)), not sure if it just acts as a fallback though. -- 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-654) Clarify repository/server id used for custom repository catalog
[
https://issues.apache.org/jira/browse/ARCHETYPE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812012#comment-17812012
]
ASF GitHub Bot commented on ARCHETYPE-654:
--
kwin commented on code in PR #185:
URL: https://github.com/apache/maven-archetype/pull/185#discussion_r1470033071
##
maven-archetype-plugin/src/site/fml/faq.fml:
##
@@ -35,11 +35,13 @@ under the License.
- How to generate a project from an archetype in an
authenticated repository?
+ How to generate a project from an archetype in a custom
(potentially authenticated) repository?
-The server id used to download the artifact is
[archetypeArtifactId]-repo: you have to
Review Comment:
this repo id is format is still used in
https://github.com/apache/maven-archetype/blob/3a2b725198c3823fd5d7e9f88b665b2e4515a202/archetype-common/src/main/java/org/apache/maven/archetype/generator/DefaultArchetypeGenerator.java#L70
(i.e. for downloading the actual archetype (not the catalog)), not sure if it
just acts as a fallback though.
> Clarify repository/server id used for custom repository catalog
> ---
>
> Key: ARCHETYPE-654
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-654
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Generator
>Affects Versions: 3.2.1
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> According to
> https://maven.apache.org/archetype/maven-archetype-plugin/generate-mojo.html#archetypeArtifactId
> a repository with id {{archetype}} can be used to resolve catalogs from a
> remote repository. The same id is supposed to be used in case that repo uses
> authentication. This contradicts the FAQ entry at
> https://maven.apache.org/archetype/maven-archetype-plugin/faq.html#authentication
> which states that the id is supposed to be {{-repo}}
> which would require one server section per archetype in a repo requiring
> authentication.
> Also it is unclear which value {{archetypeArtifact}} should be set to to
> consider the catalog from a specific remote repository as
> bq. {{remote}} is the shortcut for Maven Central repository or its mirror.
> But in case there is no mirror for Maven Central but rather a dedicated
> catalog of custom archetypes maintained in a a custom repo the value is
> unclear.
> Also adding a repository with id {{archetype}} to settings would not only
> affect m-archetype-p but every resolution with Maven.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MJLINK-76] Cleanup aftr parent pom update [maven-jlink-plugin]
bmarwell merged PR #193: URL: https://github.com/apache/maven-jlink-plugin/pull/193 -- 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] (MJLINK-76) Upgrade maven-plugin parent to 41
[ https://issues.apache.org/jira/browse/MJLINK-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812028#comment-17812028 ] ASF GitHub Bot commented on MJLINK-76: -- bmarwell merged PR #193: URL: https://github.com/apache/maven-jlink-plugin/pull/193 > Upgrade maven-plugin parent to 41 > - > > Key: MJLINK-76 > URL: https://issues.apache.org/jira/browse/MJLINK-76 > Project: Maven JLink Plugin > Issue Type: Improvement >Affects Versions: 3.1.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-79) MBUILDCACHE-67 broke the partial restore process
[
https://issues.apache.org/jira/browse/MBUILDCACHE-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812029#comment-17812029
]
Igor Dianov commented on MBUILDCACHE-79:
This problem already existed in 1.1.0 release before MBUILDCACHE-67 was merged.
There is a fix for this issue I submitted in MBUILDCACHE-80 and a PR with the
fix waiting for review in
https://github.com/apache/maven-build-cache-extension/pull/128
> MBUILDCACHE-67 broke the partial restore process
>
>
> Key: MBUILDCACHE-79
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-79
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Components: remote build cache
>Affects Versions: 1.1.0
>Reporter: Amir Hadadi
>Priority: Critical
>
> In MBUILDCACHE-67 a bug was introduced in
> BuildCacheMojosExecutionStrategy#execute. Due to the bug, after a partial
> restore from cache all executions that were restored are executed for the
> second time.
> The bug was introduced by changing:
>
> {code:java}
> boolean restorable = result.isSuccess() || result.isPartialSuccess();
> boolean restored = result.isSuccess(); // if partially restored need to save
> increment
> if (restorable) {
> restored &= restoreProject(result, mojoExecutions, mojoExecutionRunner,
> cacheConfig);
> } else {
> for (MojoExecution mojoExecution : mojoExecutions) {{code}
> to:
>
> {code:java}
> boolean restorable = result.isSuccess() || result.isPartialSuccess();
> boolean restored = result.isSuccess(); // if partially restored need to save
> increment
> if (restorable) {
> CacheRestorationStatus cacheRestorationStatus =
> restoreProject(result, mojoExecutions, mojoExecutionRunner, cacheConfig);
> restored &= CacheRestorationStatus.SUCCESS == cacheRestorationStatus;
> executeExtraCleanPhaseIfNeeded(cacheRestorationStatus, cleanPhase,
> mojoExecutionRunner);
> }
> if (!restored) {
> ...{code}
>
> Since partially restored builds have
> {code:java}
> restored == false{code}
> The
> {code:java}
> if (!restored){code}
> block is always executed, rerunning all the plugins (including the restored
> ones).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MBUILDCACHE-79) MBUILDCACHE-67 broke the partial restore process
[
https://issues.apache.org/jira/browse/MBUILDCACHE-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812029#comment-17812029
]
Igor Dianov edited comment on MBUILDCACHE-79 at 1/29/24 7:12 PM:
-
This problem already existed in 1.1.0 release after MBUILDCACHE-67 was merged.
There is a fix for this issue I submitted in MBUILDCACHE-80 and a PR with the
fix waiting for review in
[https://github.com/apache/maven-build-cache-extension/pull/128]
was (Author: JIRAUSER303977):
This problem already existed in 1.1.0 release before MBUILDCACHE-67 was merged.
There is a fix for this issue I submitted in MBUILDCACHE-80 and a PR with the
fix waiting for review in
https://github.com/apache/maven-build-cache-extension/pull/128
> MBUILDCACHE-67 broke the partial restore process
>
>
> Key: MBUILDCACHE-79
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-79
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Components: remote build cache
>Affects Versions: 1.1.0
>Reporter: Amir Hadadi
>Priority: Critical
>
> In MBUILDCACHE-67 a bug was introduced in
> BuildCacheMojosExecutionStrategy#execute. Due to the bug, after a partial
> restore from cache all executions that were restored are executed for the
> second time.
> The bug was introduced by changing:
>
> {code:java}
> boolean restorable = result.isSuccess() || result.isPartialSuccess();
> boolean restored = result.isSuccess(); // if partially restored need to save
> increment
> if (restorable) {
> restored &= restoreProject(result, mojoExecutions, mojoExecutionRunner,
> cacheConfig);
> } else {
> for (MojoExecution mojoExecution : mojoExecutions) {{code}
> to:
>
> {code:java}
> boolean restorable = result.isSuccess() || result.isPartialSuccess();
> boolean restored = result.isSuccess(); // if partially restored need to save
> increment
> if (restorable) {
> CacheRestorationStatus cacheRestorationStatus =
> restoreProject(result, mojoExecutions, mojoExecutionRunner, cacheConfig);
> restored &= CacheRestorationStatus.SUCCESS == cacheRestorationStatus;
> executeExtraCleanPhaseIfNeeded(cacheRestorationStatus, cleanPhase,
> mojoExecutionRunner);
> }
> if (!restored) {
> ...{code}
>
> Since partially restored builds have
> {code:java}
> restored == false{code}
> The
> {code:java}
> if (!restored){code}
> block is always executed, rerunning all the plugins (including the restored
> ones).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MBUILDCACHE-81) Cache portability between project versions is broken due to [MBUILDCACHE-76]
Igor Dianov created MBUILDCACHE-81: -- Summary: Cache portability between project versions is broken due to [MBUILDCACHE-76] Key: MBUILDCACHE-81 URL: https://issues.apache.org/jira/browse/MBUILDCACHE-81 Project: Maven Build Cache Extension Issue Type: Bug Affects Versions: 1.2.0 Reporter: Igor Dianov *Current* *Behavior* The MBUILDCACHE-76 has broken cache reuse between project versions in a multi-module projects, i.e. changing version from 1.0.0-SNAPSHOT to 1.0.0 causes the cache to miss the checksum validation which causes full rebuild of the project. *Expected Behavior* The build cache version normalization should support project version agnostic caches, so that restoring project from cache avoids repeating expensive tasks like running tests according to features: https://maven.apache.org/extensions/maven-build-cache-extension/index.html *Possible Solutions* * Disable cache for releases if the build requires rebuild due to version changes. * Introduce a feature flag configuration to use project version in checksum calculations. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-81) Cache portability between project versions is broken due to [MBUILDCACHE-76]
[ https://issues.apache.org/jira/browse/MBUILDCACHE-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Dianov updated MBUILDCACHE-81: --- Description: *Current* *Behavior* The MBUILDCACHE-76 has broken cache reuse between project versions in a multi-module projects, i.e. changing version from 1.0.0-SNAPSHOT to 1.0.0 causes the cache to miss the checksum validation which causes full rebuild of the project. *Expected Behavior* The build cache version normalization should support project version agnostic caches, so that restoring project from cache avoids repeating expensive tasks like running tests according to features: [https://maven.apache.org/extensions/maven-build-cache-extension/index.html] *Possible Solutions* * Disable cache for releases if the build requires rebuild due to version changes. * Introduce a feature flag configuration to use project version in checksum calculations for cache invalidation was: *Current* *Behavior* The MBUILDCACHE-76 has broken cache reuse between project versions in a multi-module projects, i.e. changing version from 1.0.0-SNAPSHOT to 1.0.0 causes the cache to miss the checksum validation which causes full rebuild of the project. *Expected Behavior* The build cache version normalization should support project version agnostic caches, so that restoring project from cache avoids repeating expensive tasks like running tests according to features: https://maven.apache.org/extensions/maven-build-cache-extension/index.html *Possible Solutions* * Disable cache for releases if the build requires rebuild due to version changes. * Introduce a feature flag configuration to use project version in checksum calculations. > Cache portability between project versions is broken due to [MBUILDCACHE-76] > - > > Key: MBUILDCACHE-81 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-81 > Project: Maven Build Cache Extension > Issue Type: Bug >Affects Versions: 1.2.0 >Reporter: Igor Dianov >Priority: Major > > *Current* *Behavior* > The MBUILDCACHE-76 has broken cache reuse between project versions in a > multi-module projects, i.e. changing version from 1.0.0-SNAPSHOT to 1.0.0 > causes the cache to miss the checksum validation which causes full rebuild of > the project. > *Expected Behavior* > The build cache version normalization should support project version agnostic > caches, so that restoring project from cache avoids repeating expensive tasks > like running tests according to features: > [https://maven.apache.org/extensions/maven-build-cache-extension/index.html] > *Possible Solutions* > * Disable cache for releases if the build requires rebuild due to version > changes. > * Introduce a feature flag configuration to use project version in checksum > calculations for cache invalidation > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MBUILDCACHE-79) MBUILDCACHE-67 broke the partial restore process
[
https://issues.apache.org/jira/browse/MBUILDCACHE-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812029#comment-17812029
]
Igor Dianov edited comment on MBUILDCACHE-79 at 1/29/24 7:28 PM:
-
This problem existed in 1.1.0 release after MBUILDCACHE-67 was merged. There is
a fix for this issue I already submitted in MBUILDCACHE-80 and a PR with the
fix waiting for review in
[https://github.com/apache/maven-build-cache-extension/pull/128]
was (Author: JIRAUSER303977):
This problem already existed in 1.1.0 release after MBUILDCACHE-67 was merged.
There is a fix for this issue I submitted in MBUILDCACHE-80 and a PR with the
fix waiting for review in
[https://github.com/apache/maven-build-cache-extension/pull/128]
> MBUILDCACHE-67 broke the partial restore process
>
>
> Key: MBUILDCACHE-79
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-79
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Components: remote build cache
>Affects Versions: 1.1.0
>Reporter: Amir Hadadi
>Priority: Critical
>
> In MBUILDCACHE-67 a bug was introduced in
> BuildCacheMojosExecutionStrategy#execute. Due to the bug, after a partial
> restore from cache all executions that were restored are executed for the
> second time.
> The bug was introduced by changing:
>
> {code:java}
> boolean restorable = result.isSuccess() || result.isPartialSuccess();
> boolean restored = result.isSuccess(); // if partially restored need to save
> increment
> if (restorable) {
> restored &= restoreProject(result, mojoExecutions, mojoExecutionRunner,
> cacheConfig);
> } else {
> for (MojoExecution mojoExecution : mojoExecutions) {{code}
> to:
>
> {code:java}
> boolean restorable = result.isSuccess() || result.isPartialSuccess();
> boolean restored = result.isSuccess(); // if partially restored need to save
> increment
> if (restorable) {
> CacheRestorationStatus cacheRestorationStatus =
> restoreProject(result, mojoExecutions, mojoExecutionRunner, cacheConfig);
> restored &= CacheRestorationStatus.SUCCESS == cacheRestorationStatus;
> executeExtraCleanPhaseIfNeeded(cacheRestorationStatus, cleanPhase,
> mojoExecutionRunner);
> }
> if (!restored) {
> ...{code}
>
> Since partially restored builds have
> {code:java}
> restored == false{code}
> The
> {code:java}
> if (!restored){code}
> block is always executed, rerunning all the plugins (including the restored
> ones).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MJLINK-78) Project cleanups
Sylwester Lachiewicz created MJLINK-78: -- Summary: Project cleanups Key: MJLINK-78 URL: https://issues.apache.org/jira/browse/MJLINK-78 Project: Maven JLink Plugin Issue Type: Task Reporter: Sylwester Lachiewicz -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [MBUILDCACHE-81] - Fix Cache portability between project versions is broken due to [MBUILDCACHE-76] [maven-build-cache-extension]
igdianov opened a new pull request, #129: URL: https://github.com/apache/maven-build-cache-extension/pull/129 Fixes https://issues.apache.org/jira/projects/MBUILDCACHE/issues/MBUILDCACHE-81 - Add new `calculateProjectVersionChecksum' configuration attribute to project versioning to enable/disable calculation of the project version checksum input. The default is false to maintain original behavior for cache portability between versions. - Add/update unit and integration tests to cover possible use cases. Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [MBUILDCACHE JIRA issue](https://issues.apache.org/jira/browse/MBUILDCACHE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MBUILDCACHE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MBUILDCACHE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MBUILDCACHE-81) Cache portability between project versions is broken due to [MBUILDCACHE-76]
[ https://issues.apache.org/jira/browse/MBUILDCACHE-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated MBUILDCACHE-81: -- Labels: pull-request-available (was: ) > Cache portability between project versions is broken due to [MBUILDCACHE-76] > - > > Key: MBUILDCACHE-81 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-81 > Project: Maven Build Cache Extension > Issue Type: Bug >Affects Versions: 1.2.0 >Reporter: Igor Dianov >Priority: Major > Labels: pull-request-available > > *Current* *Behavior* > The MBUILDCACHE-76 has broken cache reuse between project versions in a > multi-module projects, i.e. changing version from 1.0.0-SNAPSHOT to 1.0.0 > causes the cache to miss the checksum validation which causes full rebuild of > the project. > *Expected Behavior* > The build cache version normalization should support project version agnostic > caches, so that restoring project from cache avoids repeating expensive tasks > like running tests according to features: > [https://maven.apache.org/extensions/maven-build-cache-extension/index.html] > *Possible Solutions* > * Disable cache for releases if the build requires rebuild due to version > changes. > * Introduce a feature flag configuration to use project version in checksum > calculations for cache invalidation > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-81) Cache portability between project versions is broken due to [MBUILDCACHE-76]
[ https://issues.apache.org/jira/browse/MBUILDCACHE-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812068#comment-17812068 ] ASF GitHub Bot commented on MBUILDCACHE-81: --- igdianov opened a new pull request, #129: URL: https://github.com/apache/maven-build-cache-extension/pull/129 Fixes https://issues.apache.org/jira/projects/MBUILDCACHE/issues/MBUILDCACHE-81 - Add new `calculateProjectVersionChecksum' configuration attribute to project versioning to enable/disable calculation of the project version checksum input. The default is false to maintain original behavior for cache portability between versions. - Add/update unit and integration tests to cover possible use cases. Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [MBUILDCACHE JIRA issue](https://issues.apache.org/jira/browse/MBUILDCACHE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MBUILDCACHE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MBUILDCACHE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ > Cache portability between project versions is broken due to [MBUILDCACHE-76] > - > > Key: MBUILDCACHE-81 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-81 > Project: Maven Build Cache Extension > Issue Type: Bug >Affects Versions: 1.2.0 >Reporter: Igor Dianov >Priority: Major > > *Current* *Behavior* > The MBUILDCACHE-76 has broken cache reuse between project versions in a > multi-module projects, i.e. changing version from 1.0.0-SNAPSHOT to 1.0.0 > causes the cache to miss the checksum validation which causes full rebuild of > the project. > *Expected Behavior* > The build cache version normalization should support project version agnostic > caches, so that restoring project from cache avoids repeating expensive tasks > like running tests according to features: > [https://maven.apache.org/extensions/maven-build-cache-extension/index.html] > *Possible Solutions* > * Disable cache for releases if the build requires rebuild due to version > changes. > * Introduce a feature flag configuration to use project version in checksum > calculations for cache invalidation > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump org.apache.rat:apache-rat-plugin from 0.15 to 0.16.1 [maven-apache-parent]
ottlinger commented on PR #193: URL: https://github.com/apache/maven-apache-parent/pull/193#issuecomment-1915723884 Release information: https://creadur.apache.org/rat/RELEASE_NOTES.txt Configuration updates for maven users can be found here: https://creadur.apache.org/rat/apache-rat-plugin/examples/custom-license.html -- 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] (MBUILDCACHE-81) Cache portability between project versions is broken due to [MBUILDCACHE-76]
[ https://issues.apache.org/jira/browse/MBUILDCACHE-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reassigned MBUILDCACHE-81: --- Assignee: Olivier Lamy > Cache portability between project versions is broken due to [MBUILDCACHE-76] > - > > Key: MBUILDCACHE-81 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-81 > Project: Maven Build Cache Extension > Issue Type: Bug >Affects Versions: 1.2.0 >Reporter: Igor Dianov >Assignee: Olivier Lamy >Priority: Major > Labels: pull-request-available > > *Current* *Behavior* > The MBUILDCACHE-76 has broken cache reuse between project versions in a > multi-module projects, i.e. changing version from 1.0.0-SNAPSHOT to 1.0.0 > causes the cache to miss the checksum validation which causes full rebuild of > the project. > *Expected Behavior* > The build cache version normalization should support project version agnostic > caches, so that restoring project from cache avoids repeating expensive tasks > like running tests according to features: > [https://maven.apache.org/extensions/maven-build-cache-extension/index.html] > *Possible Solutions* > * Disable cache for releases if the build requires rebuild due to version > changes. > * Introduce a feature flag configuration to use project version in checksum > calculations for cache invalidation > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-81) Cache portability between project versions is broken due to [MBUILDCACHE-76]
[ https://issues.apache.org/jira/browse/MBUILDCACHE-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MBUILDCACHE-81: Fix Version/s: 1.2.0 > Cache portability between project versions is broken due to [MBUILDCACHE-76] > - > > Key: MBUILDCACHE-81 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-81 > Project: Maven Build Cache Extension > Issue Type: Bug >Affects Versions: 1.2.0 >Reporter: Igor Dianov >Assignee: Olivier Lamy >Priority: Major > Labels: pull-request-available > Fix For: 1.2.0 > > > *Current* *Behavior* > The MBUILDCACHE-76 has broken cache reuse between project versions in a > multi-module projects, i.e. changing version from 1.0.0-SNAPSHOT to 1.0.0 > causes the cache to miss the checksum validation which causes full rebuild of > the project. > *Expected Behavior* > The build cache version normalization should support project version agnostic > caches, so that restoring project from cache avoids repeating expensive tasks > like running tests according to features: > [https://maven.apache.org/extensions/maven-build-cache-extension/index.html] > *Possible Solutions* > * Disable cache for releases if the build requires rebuild due to version > changes. > * Introduce a feature flag configuration to use project version in checksum > calculations for cache invalidation > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] Bump com.thoughtworks.qdox:qdox from 2.0.3 to 2.1.0 [maven-javadoc-plugin]
dependabot[bot] opened a new pull request, #266: URL: https://github.com/apache/maven-javadoc-plugin/pull/266 Bumps [com.thoughtworks.qdox:qdox](https://github.com/paul-hammant/qdox) from 2.0.3 to 2.1.0. Commits https://github.com/paul-hammant/qdox/commit/4eb0dd8aa6037eba926933a2212a038fa0c1ad2b";>4eb0dd8 [maven-release-plugin] prepare release qdox-2.1.0 https://github.com/paul-hammant/qdox/commit/a9177f61fe2a4abce8d15435cf5118ee6e1fe454";>a9177f6 Fix the bug that does not allow the use of permits as field names. (https://redirect.github.com/paul-hammant/qdox/issues/202";>#202) https://github.com/paul-hammant/qdox/commit/54b0534c325f573f49ef6e5706095cd654dee9d0";>54b0534 maven-gpg-plugin is not a managed plugin in oss-parent, move it to build.plugins https://github.com/paul-hammant/qdox/commit/df6bfa17ff3015018042dc202c00d38f08d89bf1";>df6bfa1 Bump actions/cache from 3.3.2 to 4.0.0 (https://redirect.github.com/paul-hammant/qdox/issues/203";>#203) https://github.com/paul-hammant/qdox/commit/91e049571a4ce62f1592924fb4414caa00ba4e1a";>91e0495 Bump actions/setup-java from 3.13.0 to 4.0.0 (https://redirect.github.com/paul-hammant/qdox/issues/189";>#189) https://github.com/paul-hammant/qdox/commit/a3570dcf3feb70f17ebc4540fe97dc2bdd57c792";>a3570dc update maven-gpg-plugin https://github.com/paul-hammant/qdox/commit/4bef054294aad97676f543745457ff2dd27e42b0";>4bef054 [maven-release-plugin] rollback the release of qdox-2.1.0 https://github.com/paul-hammant/qdox/commit/cf92b4f4ad8435aa96e9681037d83769016bf881";>cf92b4f [maven-release-plugin] prepare release qdox-2.1.0 https://github.com/paul-hammant/qdox/commit/5853a23d8ef1969b5f30ff9ea8454ee3f704a3da";>5853a23 Merge pull request https://redirect.github.com/paul-hammant/qdox/issues/184";>#184 from paul-hammant/dependabot/maven/master/org.apache https://github.com/paul-hammant/qdox/commit/293363a33ac128226399f42a667e1fecaad40f61";>293363a Merge pull request https://redirect.github.com/paul-hammant/qdox/issues/188";>#188 from paul-hammant/dependabot/maven/master/org.apache Additional commits viewable in https://github.com/paul-hammant/qdox/compare/qdox-2.0.3...qdox-2.1.0";>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
[PR] Bump lucene.version from 9.9.1 to 9.9.2 [maven-indexer]
dependabot[bot] opened a new pull request, #352: URL: https://github.com/apache/maven-indexer/pull/352 Bumps `lucene.version` from 9.9.1 to 9.9.2. Updates `org.apache.lucene:lucene-core` from 9.9.1 to 9.9.2 Updates `org.apache.lucene:lucene-queryparser` from 9.9.1 to 9.9.2 Updates `org.apache.lucene:lucene-analysis-common` from 9.9.1 to 9.9.2 Updates `org.apache.lucene:lucene-highlighter` from 9.9.1 to 9.9.2 Updates `org.apache.lucene:lucene-backward-codecs` from 9.9.1 to 9.9.2 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] (MDEP-905) add repository id to dependency:tree/list
Herve Boutemy created MDEP-905: -- Summary: add repository id to dependency:tree/list Key: MDEP-905 URL: https://issues.apache.org/jira/browse/MDEP-905 Project: Maven Dependency Plugin Issue Type: New Feature Components: list, tree Reporter: Herve Boutemy knowing the origin of a dependency would help people understand a lot about repositories -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-80) Incremental builds with a higher goal than the highest cached goal is rebuilding the full project from scratch
[
https://issues.apache.org/jira/browse/MBUILDCACHE-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812182#comment-17812182
]
ASF GitHub Bot commented on MBUILDCACHE-80:
---
amirhadadi commented on code in PR #128:
URL:
https://github.com/apache/maven-build-cache-extension/pull/128#discussion_r1470721805
##
src/main/java/org/apache/maven/buildcache/BuildCacheMojosExecutionStrategy.java:
##
@@ -134,7 +134,7 @@ public void execute(
if (restorable) {
CacheRestorationStatus cacheRestorationStatus =
restoreProject(result, mojoExecutions,
mojoExecutionRunner, cacheConfig);
-restored &= CacheRestorationStatus.SUCCESS ==
cacheRestorationStatus;
+restored = CacheRestorationStatus.SUCCESS ==
cacheRestorationStatus;
Review Comment:
The `restored` variable name is misleading since it has 2 meanings:
1) It starts as meaning _The build is fully cached_.
2) The meaning may then change to _The build was restored from cache_.
I suggest changing
`boolean restored = result.isSuccess()`
to
`boolean restored = false`
To improve that.
> Incremental builds with a higher goal than the highest cached goal is
> rebuilding the full project from scratch
> --
>
> Key: MBUILDCACHE-80
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-80
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1, 1.1.0, 1.2.0
> Environment: Apache Maven 3.9.6
> (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: C:\Users\sdkman\candidates\maven\current
> Java version: 21.0.1, vendor: Eclipse Adoptium, runtime:
> C:\Users\sdkman\candidates\java\current
> Default locale: en_US, platform encoding: UTF8
> OS name: "windows 11", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Igor Dianov
>Priority: Major
> Labels: pull-request-available
>
> We are trying to use the Maven build cache extension on a large multi-module
> project with ~180 modules by caching builds in the CI workflows to be able to
> reuse artifacts in the build cache between main and feature branches. The
> final build artifacts (i.e. jar, sources, apidocs) are used to build
> application Docker images and publish Maven modules into Nexus repository
> during deploy phase for releases.
> *Expected Behavior*
> When executing a build for a higher goal then the currently highest cached
> goal, the build extension should skip cached mojo executions, restore the
> cached artifacts (i.e. jar, javadocs, sources) into the project build
> directory and run remaining mojo executions for the increment, i.e. javadocs,
> sources, Docker images between verify -> deploy incremental build. After
> successful completion, the build cache info should be updated to record the
> new highest cached goal with incremental mojo executions and artifacts.
> *Current Behavior*
> When executing a build for a higher goal (i.e. deploy) then the currently
> highest cached goal (i.e. verify), the extension skips cached executions and
> runs mojos between cached and current goals while missing to restore cached
> final artifacts into the project build directory. After that, it runs the
> full build again from the begining to rebuild the artifacts and save build
> cache. Instead of reducing the build time by reusing already packaged
> artifacts and executions, it almost doubles the time to re-run the deploy for
> release from scratch. It also causes the Maven source plugin (3.3.0) to fail
> due to a duplicate sources artifact error, causing the deploy build to fail.
> *Possible Solution*
> It should be possible to restore cached artifacts into project build
> directory while avoiding to re-run full build again after restoring already
> cached mojo executions.
> *Steps to Reproduce*
> 1. Run *mvn clean package -DprojectVersion=1.1.0* from the
> *tests/java/projects/build-extensions* directory.
> {code:java}
> [INFO] Scanning for projects...
> [INFO] Loading cache configuration from
> C:\Users\git\igdianov\maven-build-cache-extension\src\test\projects\build-extension\.mvn\maven-build-cache-config.xml
> [INFO] Using XX hash algorithm for cache
> [INFO]
> [INFO] ---{-}< org.apache.maven.caching.test.simple:simple
> >{-}
> [INFO] Building simple 0.0.1-SNAPSHOT
> [INFO] from pom.xml
> [INFO] ---{-}[ jar
> ]{-}
> [INFO]
> [INFO] — clean:3.2.0:clean (default-clean) @ simple —
> [INFO] Going to calculate checksum for project
> [groupId=org.apache.maven.caching.test.simple, artifactId=simple]
> [INFO] Scanning plugins configurations to find
Re: [PR] [MBUILDCACHE-80] - Fix for incremental builds with a higher goal than the highest cached goal is rebuilding the full project from scratch [maven-build-cache-extension]
amirhadadi commented on code in PR #128:
URL:
https://github.com/apache/maven-build-cache-extension/pull/128#discussion_r1470721805
##
src/main/java/org/apache/maven/buildcache/BuildCacheMojosExecutionStrategy.java:
##
@@ -134,7 +134,7 @@ public void execute(
if (restorable) {
CacheRestorationStatus cacheRestorationStatus =
restoreProject(result, mojoExecutions,
mojoExecutionRunner, cacheConfig);
-restored &= CacheRestorationStatus.SUCCESS ==
cacheRestorationStatus;
+restored = CacheRestorationStatus.SUCCESS ==
cacheRestorationStatus;
Review Comment:
The `restored` variable name is misleading since it has 2 meanings:
1) It starts as meaning _The build is fully cached_.
2) The meaning may then change to _The build was restored from cache_.
I suggest changing
`boolean restored = result.isSuccess()`
to
`boolean restored = false`
To improve that.
--
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
