[jira] [Commented] (MNG-8106) Maven Metadata corruption if directory role overlaps
[
https://issues.apache.org/jira/browse/MNG-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840438#comment-17840438
]
ASF GitHub Bot commented on MNG-8106:
-
cstamas commented on PR #1481:
URL: https://github.com/apache/maven/pull/1481#issuecomment-2074934664
Note: new IT did not run (it did on 3.9.x PR
https://github.com/apache/maven/pull/1480) as master is still alpha-14...
> Maven Metadata corruption if directory role overlaps
>
>
> Key: MNG-8106
> URL: https://issues.apache.org/jira/browse/MNG-8106
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.7, 4.0.0-beta-1
>
>
> In case certain directory role is manifold (which IS against best practices),
> data loss occurs. Metadata will contain this or that, but not both data.
> Example: consider project producing these artifacts
> * org.foo:bar:1.0
> * org.foo.bar:baz:1.0
> In this case, the local (and remote) repository path {{org/foo/bar}} that is
> a directory, will overlap in a way, it is G level for one artifact, and A
> level for another. Now, if org.foo.bar:baz is a Maven Plugin, the G level
> should contain plugin related (G level) metadata. At the same time, due
> org.foo:bar this directory should contain A level metadata (list of
> versions). Affected maven versions will simply drop "the other" metadata (so
> if last deployed using this directory as G, the A data will be missing, and
> other way around).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8106) Maven Metadata corruption if directory role overlaps
[
https://issues.apache.org/jira/browse/MNG-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840412#comment-17840412
]
ASF GitHub Bot commented on MNG-8106:
-
cstamas commented on PR #1480:
URL: https://github.com/apache/maven/pull/1480#issuecomment-2074807997
There is some CI (not IT) related issue on macOS?
> Maven Metadata corruption if directory role overlaps
>
>
> Key: MNG-8106
> URL: https://issues.apache.org/jira/browse/MNG-8106
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.7, 4.0.0-beta-1
>
>
> In case certain directory role is manifold (which IS against best practices),
> data loss occurs. Metadata will contain this or that, but not both data.
> Example: consider project producing these artifacts
> * org.foo:bar:1.0
> * org.foo.bar:baz:1.0
> In this case, the local (and remote) repository path {{org/foo/bar}} that is
> a directory, will overlap in a way, it is G level for one artifact, and A
> level for another. Now, if org.foo.bar:baz is a Maven Plugin, the G level
> should contain plugin related (G level) metadata. At the same time, due
> org.foo:bar this directory should contain A level metadata (list of
> versions). Affected maven versions will simply drop "the other" metadata (so
> if last deployed using this directory as G, the A data will be missing, and
> other way around).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MASSEMBLY-1029) Warning "failed to build parent project"
[
https://issues.apache.org/jira/browse/MASSEMBLY-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840394#comment-17840394
]
ASF GitHub Bot commented on MASSEMBLY-1029:
---
gnodet opened a new pull request, #204:
URL: https://github.com/apache/maven-assembly-plugin/pull/204
(no comment)
> Warning "failed to build parent project"
>
>
> Key: MASSEMBLY-1029
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-1029
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.7.1
>Reporter: Guillaume Nodet
>Priority: Major
>
> Here's what happens when building maven core
> (529d80a1697c8fd1d53a0a3842261a1343cc3510) during the assembly:
> {code}
> [WARNING] Failed to build parent project for
> jakarta.inject:jakarta.inject-api:jar:2.0.1
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:338)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.initParent(DefaultProjectBuilder.java:849)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.initProject(DefaultProjectBuilder.java:682)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:323)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:382)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:155)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:148)
> at
> org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:150)
> at
> org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:115)
> at
> org.apache.maven.plugins.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:84)
> at
> org.apache.maven.plugins.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:172)
> at
> org.apache.maven.plugins.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:493)
> at
> org.apache.maven.plugins.assembly.mojos.SingleAssemblyMojo.execute(SingleAssemblyMojo.java:54)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:144)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:323)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:311)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:178)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:167)
> at
> org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:164)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:107)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:60)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleStarter.execute(DefaultLifecycleStarter.java:123)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:311)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:225)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:149)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:958)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
> at
> jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke(Method.java:580)
> 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.La
[jira] [Updated] (MNG-8106) Maven Metadata corruption if directory role overlaps
[
https://issues.apache.org/jira/browse/MNG-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8106:
-
Description:
In case certain directory role is manifold (which IS against best practices),
data loss occurs. Metadata will contain this or that, but not both data.
Example: consider project producing these artifacts
* org.foo:bar:1.0
* org.foo.bar:baz:1.0
In this case, the local (and remote) repository path {{org/foo/bar}} that is a
directory, will overlap in a way, it is G level for one artifact, and A level
for another. Now, if org.foo.bar:baz is a Maven Plugin, the G level should
contain plugin related (G level) metadata. At the same time, due org.foo:bar
this directory should contain A level metadata (list of versions). Affected
maven versions will simply drop "the other" metadata (so if last deployed using
this directory as G, the A data will be missing, and other way around).
was:
In case certain directory role is manifold (which IS against best practices),
data loss occurs. Metadata will contain this or that, but not both data.
Example: consider project producing these artifacts
* org.foo:bar:1.0
* org.foo.bar:baz:1.0
In this case, the local (and remote) repository path {{org/foo/bar}} that is a
directory, will overlap in a way, it is G level for one artifact, and A level
for another. Now, if org.foo.bar:baz is a Maven Plugin, the G level should
contain plugin related (G level) metadata. At the same time, due org.foo:bar
this directory should contain A level metadata (list of versions).
> Maven Metadata corruption if directory role overlaps
>
>
> Key: MNG-8106
> URL: https://issues.apache.org/jira/browse/MNG-8106
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.7, 4.0.0-beta-1
>
>
> In case certain directory role is manifold (which IS against best practices),
> data loss occurs. Metadata will contain this or that, but not both data.
> Example: consider project producing these artifacts
> * org.foo:bar:1.0
> * org.foo.bar:baz:1.0
> In this case, the local (and remote) repository path {{org/foo/bar}} that is
> a directory, will overlap in a way, it is G level for one artifact, and A
> level for another. Now, if org.foo.bar:baz is a Maven Plugin, the G level
> should contain plugin related (G level) metadata. At the same time, due
> org.foo:bar this directory should contain A level metadata (list of
> versions). Affected maven versions will simply drop "the other" metadata (so
> if last deployed using this directory as G, the A data will be missing, and
> other way around).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-59) Accommodate Maven CI-friendly versions
[
https://issues.apache.org/jira/browse/MBUILDCACHE-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840386#comment-17840386
]
Marquis Wang commented on MBUILDCACHE-59:
-
I am observing the same thing - it seems to work correctly for dependencies,
but not with annotationProcessorPaths.
> Accommodate Maven CI-friendly versions
> --
>
> Key: MBUILDCACHE-59
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-59
> Project: Maven Build Cache Extension
> Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: Bas van Erp
>Priority: Major
>
> I would argue that the Maven Build Cache Extension (MBCE) can provide the
> greatest value for users that utilize large multi-module (mono-)repositories,
> since those projects tend to have large amounts of "stable" code which isn't
> modified frequently.
> Speeding up the build of these multi-module projects using the MBCE would be
> totally awesome!
> But for my particular project (200K LOC, 400 modules, mono-repo) our initial
> trials with the MBCE have proven somewhat troublesome.
> It has to do with our use of [https://maven.apache.org/maven-ci-friendly.html]
> h2. Example setup
> {{repo/.mvn/maven.config}}
> {code:java}
> -Drevision=0.0.0-local-SNAPSHOT {code}
> {{repo/pom.xml}}
> {code:java}
> com.corp
> parent
> ${revision}
> pom {code}
> {{repo/moduleX/pom.xml}}
> {code:java}
>
> com.corp
> parent
> ${revision}
> ../pom.xml
>
> moduleX
> jar{code}
> {{repo/moduleY/pom.xml}}
> {code:java}
>
> com.corp
> parent
> ${revision}
> ../pom.xml
>
> moduleY
> jar
>
>
> com.corp
> moduleX
> ${revision}
>
> {code}
> {{repo/Jenkinsfile}}
> {code:java}
> mvn clean deploy -Drevision=$(git describe){code}
> h2. Effect
> This setup effectively means that while all our 150 developers might
> theoretically get decent cache hit % since they are all always using version
> {{0.0.0-local-SNAPSHOT}} for every single POM for every single build, our CI
> pipelines are out of luck.
> Since the effective-POMs will change radically with each new Git commit, the
> hashes will virtually never collide.
> h2. Solution?
> I'm very new to the MBCE so I might be way off the mark, but I think
> accommodating this setup will not be trivial to implement. It would probably
> require parsing the effective-POM for every module picked-up by the reactor
> and then removing all clauses of the module, the parent, and each
> dependency and plugin which are part of the reactor build.
> Doesn't sound easy to me. But perhaps I'm missing something.
>
> p.s. Congrats on the v1.0.0 release :). I'm enjoying experimenting with it.
> But the documentation could use some love. It's pretty hard to read. Some
> paragraphs are confusing, terse or lacking in detail, are clearly written by
> non-English-native writers (like myself), or even stop mid-sentence.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MASSEMBLY-1029) Warning "failed to build parent project"
[
https://issues.apache.org/jira/browse/MASSEMBLY-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840364#comment-17840364
]
Guillaume Nodet commented on MASSEMBLY-1029:
So maybe simply setting the validation level to a lower value (than the default
one) in:
https://github.com/apache/maven-assembly-plugin/blob/07c6a2ee65e6505e40c0500d2ebc23893060a979/src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java#L168-L169
> Warning "failed to build parent project"
>
>
> Key: MASSEMBLY-1029
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-1029
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.7.1
>Reporter: Guillaume Nodet
>Priority: Major
>
> Here's what happens when building maven core
> (529d80a1697c8fd1d53a0a3842261a1343cc3510) during the assembly:
> {code}
> [WARNING] Failed to build parent project for
> jakarta.inject:jakarta.inject-api:jar:2.0.1
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:338)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.initParent(DefaultProjectBuilder.java:849)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.initProject(DefaultProjectBuilder.java:682)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:323)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:382)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:155)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:148)
> at
> org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:150)
> at
> org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:115)
> at
> org.apache.maven.plugins.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:84)
> at
> org.apache.maven.plugins.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:172)
> at
> org.apache.maven.plugins.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:493)
> at
> org.apache.maven.plugins.assembly.mojos.SingleAssemblyMojo.execute(SingleAssemblyMojo.java:54)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:144)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:323)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:311)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:178)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:167)
> at
> org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:164)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:107)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:60)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleStarter.execute(DefaultLifecycleStarter.java:123)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:311)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:225)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:149)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:958)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
> at
> jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke(Method.java:580)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> a
[jira] [Created] (MASSEMBLY-1029) Warning "failed to build parent project"
Guillaume Nodet created MASSEMBLY-1029:
--
Summary: Warning "failed to build parent project"
Key: MASSEMBLY-1029
URL: https://issues.apache.org/jira/browse/MASSEMBLY-1029
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 3.7.1
Reporter: Guillaume Nodet
Here's what happens when building maven core
(529d80a1697c8fd1d53a0a3842261a1343cc3510) during the assembly:
{code}
[WARNING] Failed to build parent project for
jakarta.inject:jakarta.inject-api:jar:2.0.1
org.apache.maven.project.ProjectBuildingException: Some problems were
encountered while processing the POMs
at
org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:338)
at
org.apache.maven.project.DefaultProjectBuilder$BuildSession.initParent(DefaultProjectBuilder.java:849)
at
org.apache.maven.project.DefaultProjectBuilder$BuildSession.initProject(DefaultProjectBuilder.java:682)
at
org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:323)
at
org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:382)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:155)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:148)
at
org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:150)
at
org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:115)
at
org.apache.maven.plugins.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:84)
at
org.apache.maven.plugins.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:172)
at
org.apache.maven.plugins.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:493)
at
org.apache.maven.plugins.assembly.mojos.SingleAssemblyMojo.execute(SingleAssemblyMojo.java:54)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:144)
at
org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:323)
at
org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:311)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:178)
at
org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:167)
at
org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:164)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:107)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:73)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:60)
at
org.apache.maven.lifecycle.internal.DefaultLifecycleStarter.execute(DefaultLifecycleStarter.java:123)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:311)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:225)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:149)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:958)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
at
jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.lang.reflect.Method.invoke(Method.java:580)
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: org.apache.maven.model.building.ModelBuildingException: 8 problems
were encountered while building the effective model for
/Users/gnodet/.m2/repository/org/eclipse/ee4j/project/1.0.6/project-1.0.6.pom
- [ERROR]
'profiles.profile[snapshots].repositories.repository.[sonatype-nexus-snapshots].url'
contains an expression but should be a constant. @
org.eclipse.ee4j:project:1.0.6,
/Users/gnodet/.m2/repository/org/eclipse/ee4j/project/1.0.6/project-1.0.6.pom,
line 252, column 21
- [ERROR]
'profiles.profile[snapshots].pluginRepositories.pluginRepository.[sonatype-nexus-snapshots].url'
contains an expression but should be a constant. @
org.eclipse.ee4j:project:1.0.6,
/Users/gnodet/.m2/repository/org/ec
[jira] [Commented] (MNG-8106) Maven Metadata corruption if directory role overlaps
[
https://issues.apache.org/jira/browse/MNG-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840358#comment-17840358
]
ASF GitHub Bot commented on MNG-8106:
-
cstamas opened a new pull request, #1481:
URL: https://github.com/apache/maven/pull/1481
As currently if given metadata serves multiple roles (G, A or V level), data
loss occurs.
---
https://issues.apache.org/jira/browse/MNG-8106
> Maven Metadata corruption if directory role overlaps
>
>
> Key: MNG-8106
> URL: https://issues.apache.org/jira/browse/MNG-8106
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.7, 4.0.0-beta-1
>
>
> In case certain directory role is manifold (which IS against best practices),
> data loss occurs. Metadata will contain this or that, but not both data.
> Example: consider project producing these artifacts
> * org.foo:bar:1.0
> * org.foo.bar:baz:1.0
> In this case, the local (and remote) repository path {{org/foo/bar}} that is
> a directory, will overlap in a way, it is G level for one artifact, and A
> level for another. Now, if org.foo.bar:baz is a Maven Plugin, the G level
> should contain plugin related (G level) metadata. At the same time, due
> org.foo:bar this directory should contain A level metadata (list of versions).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8106) Maven Metadata corruption if directory role overlaps
[
https://issues.apache.org/jira/browse/MNG-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840355#comment-17840355
]
ASF GitHub Bot commented on MNG-8106:
-
cstamas opened a new pull request, #1480:
URL: https://github.com/apache/maven/pull/1480
As currently if given metadata serves multiple roles (G, A or V level), data
loss occurs.
---
https://issues.apache.org/jira/browse/MNG-8106
> Maven Metadata corruption if directory role overlaps
>
>
> Key: MNG-8106
> URL: https://issues.apache.org/jira/browse/MNG-8106
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.7, 4.0.0-beta-1
>
>
> In case certain directory role is manifold (which IS against best practices),
> data loss occurs. Metadata will contain this or that, but not both data.
> Example: consider project producing these artifacts
> * org.foo:bar:1.0
> * org.foo.bar:baz:1.0
> In this case, the local (and remote) repository path {{org/foo/bar}} that is
> a directory, will overlap in a way, it is G level for one artifact, and A
> level for another. Now, if org.foo.bar:baz is a Maven Plugin, the G level
> should contain plugin related (G level) metadata. At the same time, due
> org.foo:bar this directory should contain A level metadata (list of versions).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-8106) Maven Metadata corruption if directory role overlaps
[
https://issues.apache.org/jira/browse/MNG-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reassigned MNG-8106:
Assignee: Tamas Cservenak
> Maven Metadata corruption if directory role overlaps
>
>
> Key: MNG-8106
> URL: https://issues.apache.org/jira/browse/MNG-8106
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.7, 4.0.0-beta-1
>
>
> In case certain directory role is manifold (which IS against best practices),
> data loss occurs. Metadata will contain this or that, but not both data.
> Example: consider project producing these artifacts
> * org.foo:bar:1.0
> * org.foo.bar:baz:1.0
> In this case, the local (and remote) repository path {{org/foo/bar}} that is
> a directory, will overlap in a way, it is G level for one artifact, and A
> level for another. Now, if org.foo.bar:baz is a Maven Plugin, the G level
> should contain plugin related (G level) metadata. At the same time, due
> org.foo:bar this directory should contain A level metadata (list of versions).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8106) Maven Metadata corruption if directory role overlaps
Tamas Cservenak created MNG-8106:
Summary: Maven Metadata corruption if directory role overlaps
Key: MNG-8106
URL: https://issues.apache.org/jira/browse/MNG-8106
Project: Maven
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.9.6, 3.9.5, 3.9.4, 3.9.3, 3.9.2, 3.9.1, 3.9.0
Reporter: Tamas Cservenak
Fix For: 3.9.7
In case certain directory role is manifold (which IS against best practices),
data loss occurs. Metadata will contain this or that, but not both data.
Example: consider project producing these artifacts
* org.foo:bar:1.0
* org.foo.bar:baz:1.0
In this case, the local (and remote) repository path {{org/foo/bar}} that is a
directory, will overlap in a way, it is G level for one artifact, and A level
for another. Now, if org.foo.bar:baz is a Maven Plugin, the G level should
contain plugin related (G level) metadata. At the same time, due org.foo:bar
this directory should contain A level metadata (list of versions).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8106) Maven Metadata corruption if directory role overlaps
[
https://issues.apache.org/jira/browse/MNG-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8106:
-
Fix Version/s: 4.0.0-beta-1
> Maven Metadata corruption if directory role overlaps
>
>
> Key: MNG-8106
> URL: https://issues.apache.org/jira/browse/MNG-8106
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.7, 4.0.0-beta-1
>
>
> In case certain directory role is manifold (which IS against best practices),
> data loss occurs. Metadata will contain this or that, but not both data.
> Example: consider project producing these artifacts
> * org.foo:bar:1.0
> * org.foo.bar:baz:1.0
> In this case, the local (and remote) repository path {{org/foo/bar}} that is
> a directory, will overlap in a way, it is G level for one artifact, and A
> level for another. Now, if org.foo.bar:baz is a Maven Plugin, the G level
> should contain plugin related (G level) metadata. At the same time, due
> org.foo:bar this directory should contain A level metadata (list of versions).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-86) Bugfix and enhancements with the restoration of outputs on disk
[ https://issues.apache.org/jira/browse/MBUILDCACHE-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840354#comment-17840354 ] ASF GitHub Bot commented on MBUILDCACHE-86: --- hboutemy commented on PR #104: URL: https://github.com/apache/maven-build-cache-extension/pull/104#issuecomment-2074492962 notice: if you build with Maven 3, you won't have this extra file, which is Maven 4 specific https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM > Bugfix and enhancements with the restoration of outputs on disk > --- > > Key: MBUILDCACHE-86 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-86 > Project: Maven Build Cache Extension > Issue Type: Improvement >Reporter: Kevin Buntrock >Priority: Major > Labels: pull-request-available > > *Fixes :* > * Files containing an underscore in their name can't be restored in the > cache directory correctly (not in the same directory location). > * The cache is able to extract/restore files in locations outside the > project. I guess the extraction part is not a vulnerability since someone > with commit permissions can guess other ways to extract data. But the > possibility of restoring at any place on the disk looks pretty dangerous to > me if a remote cache server is compromised. > *Enhancements :* > * Possibility to restore artefacts on disk, with a dedicated property : > maven.build.cache.restoreOnDiskArtefacts (default to true). Meaning in the > project directory, as opposed to the cache directory. > ** IDE integration and use of the cache locally in developement is way > easier. It is now possible to retrieve a cached jar in the "target" directory. > * Introduce "globs" to filter extra attached outputs by filenames. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MINSTALL-193) Upgrade Parent Version 42, require min Maven 3.6.3
[ https://issues.apache.org/jira/browse/MINSTALL-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840347#comment-17840347 ] ASF GitHub Bot commented on MINSTALL-193: - cstamas opened a new pull request, #64: URL: https://github.com/apache/maven-install-plugin/pull/64 --- https://issues.apache.org/jira/browse/MINSTALL-193 > Upgrade Parent Version 42, require min Maven 3.6.3 > -- > > Key: MINSTALL-193 > URL: https://issues.apache.org/jira/browse/MINSTALL-193 > Project: Maven Install Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.1.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.1.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINSTALL-193) Upgrade Parent Version 42, require min Maven 3.6.3
[ https://issues.apache.org/jira/browse/MINSTALL-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MINSTALL-193: - Summary: Upgrade Parent Version 42, require min Maven 3.6.3 (was: Upgrade Parent Version 42) > Upgrade Parent Version 42, require min Maven 3.6.3 > -- > > Key: MINSTALL-193 > URL: https://issues.apache.org/jira/browse/MINSTALL-193 > Project: Maven Install Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.1.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.1.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINSTALL-193) Upgrade Parent Version 42
[ https://issues.apache.org/jira/browse/MINSTALL-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MINSTALL-193: - Issue Type: Dependency upgrade (was: Task) > Upgrade Parent Version 42 > - > > Key: MINSTALL-193 > URL: https://issues.apache.org/jira/browse/MINSTALL-193 > Project: Maven Install Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.1.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.1.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINSTALL-197) Upgrade parent to 41, remove deprecations
[ https://issues.apache.org/jira/browse/MINSTALL-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MINSTALL-197: - Issue Type: Dependency upgrade (was: Task) > Upgrade parent to 41, remove deprecations > - > > Key: MINSTALL-197 > URL: https://issues.apache.org/jira/browse/MINSTALL-197 > Project: Maven Install Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.1.2 > > > Upgrade parent to 41, remove deprecations -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINSTALL-191) Metadata for submodules seems to be incomplete
[
https://issues.apache.org/jira/browse/MINSTALL-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MINSTALL-191:
-
Fix Version/s: 3.1.2
> Metadata for submodules seems to be incomplete
> --
>
> Key: MINSTALL-191
> URL: https://issues.apache.org/jira/browse/MINSTALL-191
> Project: Maven Install Plugin
> Issue Type: Bug
> Components: install:install
>Affects Versions: 3.0.0-M1, 3.0.0, 3.1.0, 3.1.1
> Environment: Apache Maven 3.8.8
> (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
> Java version: 11.0.18, vendor: Eclipse Adoptium
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.15.0-83-generic", arch: "amd64", family: "unix"
>Reporter: Dorian Vallant
>Priority: Major
> Fix For: 3.1.2
>
> Attachments: maven-install-plugin-bug.tgz
>
>
> maven-install-plugin 3.x (and maven-deploy-plugin 3.x too) seems to have a
> bug when generating maven-metadata-*.xml for submodules containing custom
> maven-plugins.
> With version 2.5.2 maven-install-plugin generates the local metadata as
> follows:
> {code:xml}
>
>
> at.dvallant.maven
> plugins
>
>
> 0.1.0-SNAPSHOT
>
> 20230831082036
>
>
>
> my-maven-plugin
> my
> my-maven-plugin
>
>
>
> {code}
>
> After upgrading to 3.1.1 (also testet with 3.0.0-M1, 3.0.0 and 3.1.0) the
> generated file looks this:
> {code:xml}
>
> at.dvallant.maven
> plugins
>
>
> 0.1.0-SNAPSHOT
>
> 20230831082207
>
>
> {code}
> A test-project to reproduce the issue is attached.
> To reproduce build the project by calling `mvn clean install` and then check
> the contents of
> `~/.m2/repository/at/dvallant/maven/plugins/maven-metadata-local.xml`.
> If you downgrade the version to 2.5.2, metadata generation works as expected.
> If you could give me a hint where the problem might be in the code I can try
> to fix it and open a pull request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MINSTALL-191) Metadata for submodules seems to be incomplete
[
https://issues.apache.org/jira/browse/MINSTALL-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840341#comment-17840341
]
Tamas Cservenak commented on MINSTALL-191:
--
This is a user mistake, and cannot be supported well by Maven repository
layout, hence, these things should be avoided. The example project has 3
artifacts:
{noformat}
at.dvallant.maven:maven-install-plugin-bug:0.1.0-SNAPSHOT (root/parent POM)
at.dvallant.maven:plugins:0.1.0-SNAPSHOT
at.dvalland.maven.plugins:my-maven-plugin:0.1.0-SNAPSHOT{noformat}
Clearly can be seen, that the two overlap: {{at.dwallant.maven:plugins}} (GA)
and {{at.dvallant.maven.plugins}} (G). This means that on disk (mapped by
layout) this directory contains once G level metadata (for
at.dvalland.maven.plugins:my-maven-plugin plugin) and once A level metadata
(for at.dvallant.maven:plugins artifact). These situations should be avoided.
> Metadata for submodules seems to be incomplete
> --
>
> Key: MINSTALL-191
> URL: https://issues.apache.org/jira/browse/MINSTALL-191
> Project: Maven Install Plugin
> Issue Type: Bug
> Components: install:install
>Affects Versions: 3.0.0-M1, 3.0.0, 3.1.0, 3.1.1
> Environment: Apache Maven 3.8.8
> (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
> Java version: 11.0.18, vendor: Eclipse Adoptium
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.15.0-83-generic", arch: "amd64", family: "unix"
>Reporter: Dorian Vallant
>Priority: Major
> Attachments: maven-install-plugin-bug.tgz
>
>
> maven-install-plugin 3.x (and maven-deploy-plugin 3.x too) seems to have a
> bug when generating maven-metadata-*.xml for submodules containing custom
> maven-plugins.
> With version 2.5.2 maven-install-plugin generates the local metadata as
> follows:
> {code:xml}
>
>
> at.dvallant.maven
> plugins
>
>
> 0.1.0-SNAPSHOT
>
> 20230831082036
>
>
>
> my-maven-plugin
> my
> my-maven-plugin
>
>
>
> {code}
>
> After upgrading to 3.1.1 (also testet with 3.0.0-M1, 3.0.0 and 3.1.0) the
> generated file looks this:
> {code:xml}
>
> at.dvallant.maven
> plugins
>
>
> 0.1.0-SNAPSHOT
>
> 20230831082207
>
>
> {code}
> A test-project to reproduce the issue is attached.
> To reproduce build the project by calling `mvn clean install` and then check
> the contents of
> `~/.m2/repository/at/dvallant/maven/plugins/maven-metadata-local.xml`.
> If you downgrade the version to 2.5.2, metadata generation works as expected.
> If you could give me a hint where the problem might be in the code I can try
> to fix it and open a pull request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-86) Bugfix and enhancements with the restoration of outputs on disk
[ https://issues.apache.org/jira/browse/MBUILDCACHE-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840338#comment-17840338 ] ASF GitHub Bot commented on MBUILDCACHE-86: --- kbuntrock commented on PR #104: URL: https://github.com/apache/maven-build-cache-extension/pull/104#issuecomment-2074391072 > > some "weird" pom files > > oh, this is Maven 4 consumer POMs, that seem to have been generated with random file names > > @gnodet do we really want these random file names? Do we need to create a hack in build cache extension to manage this randomness? To add a bit of context, I did some experiment yesterday evening. Here are some extract of the file `buildinfo.xml` after the execution of the goal package in different contexts: ### Test "IncrementalRestoreTest", on this branch: ```xml package org.apache.maven.caching.test mbuildcache-incremental 0.0.1-SNAPSHOT jar mbuildcache-incremental.jar 887c667918b9b71d 3119 target/mbuildcache-incremental-final.jar org.apache.maven.caching.test mbuildcache-incremental 0.0.1-SNAPSHOT consumer pom mbuildcache-incremental-consumer.pom bf52cc397806673a 430 target/consumer-4676390733155918308.pom ``` ### Test "IncrementalRestoreTest", on the branch master: ```xml package org.apache.maven.caching.test mbuildcache-incremental 0.0.1-SNAPSHOT jar mbuildcache-incremental.jar 41e8d89e0385f771 3119 org.apache.maven.caching.test mbuildcache-incremental 0.0.1-SNAPSHOT consumer pom mbuildcache-incremental-consumer.pom bf52cc397806673a 430 ``` ### On a standalone project based on "IncrementalRestoreTest", with the extension code of this branch: ```xml package org.apache.maven.caching.test mbuildcache-incremental 0.0.1-SNAPSHOT jar mbuildcache-incremental.jar 8d6a9a9795c1f249 3122 target/mbuildcache-incremental-final.jar ``` Meaning that: - It might be linked to the IT execution context - It is not related to this PR, so I will focus on updating the current tests and put this problem aside. > Bugfix and enhancements with the restoration of outputs on disk > --- > > Key: MBUILDCACHE-86 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-86 > Project: Maven Build Cache Extension > Issue Type: Improvement >Reporter: Kevin Buntrock >Priority: Major > Labels: pull-request-available > > *Fixes :* > * Files containing an underscore in their name can't be restored in the > cache directory correctly (not in the same directory location). > * The cache is able to extract/restore files in locations outside the > project. I guess the extraction part is not a vulnerability since someone > with commit permissions can guess other ways to extract data. But the > possibility of restoring at any place on the disk looks pretty dangerous to > me if a remote cache server is compromised. > *Enhancements :* > * Possibility to restore artefacts on disk, with a dedicated property : > maven.build.cache.restoreOnDiskArtefacts (default to true). Meaning in the > project directory, as opposed to the cache directory. > ** IDE integration and use of the cache locally in developement is way > easier. It is now possible to retrieve a cached jar in the "target" directory. > * Introduce "globs" to filter extra attached outputs by filenames. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MINSTALL-190) Fix Temporary File Information Disclosure Vulnerability
[ https://issues.apache.org/jira/browse/MINSTALL-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MINSTALL-190. Resolution: Fixed Fixed with https://github.com/apache/maven-install-plugin/pull/61 > Fix Temporary File Information Disclosure Vulnerability > --- > > Key: MINSTALL-190 > URL: https://issues.apache.org/jira/browse/MINSTALL-190 > Project: Maven Install Plugin > Issue Type: Bug >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.1.2 > > > https://github.com/apache/maven-install-plugin/pull/47 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINSTALL-193) Upgrade Parent Version 42
[ https://issues.apache.org/jira/browse/MINSTALL-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MINSTALL-193: - Summary: Upgrade Parent Version 42 (was: Upgrade Parent Version 40) > Upgrade Parent Version 42 > - > > Key: MINSTALL-193 > URL: https://issues.apache.org/jira/browse/MINSTALL-193 > Project: Maven Install Plugin > Issue Type: Task >Affects Versions: 3.1.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.1.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINSTALL-195) Include artifactId in messages of InstallMojo#processProject
[
https://issues.apache.org/jira/browse/MINSTALL-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MINSTALL-195:
-
Fix Version/s: 3.1.2
> Include artifactId in messages of InstallMojo#processProject
>
>
> Key: MINSTALL-195
> URL: https://issues.apache.org/jira/browse/MINSTALL-195
> Project: Maven Install Plugin
> Issue Type: Improvement
> Components: install:install
>Affects Versions: 3.1.1
>Reporter: András Péteri
>Priority: Major
> Fix For: 3.1.2
>
>
> A companion request for MDEPLOY-314: if an issue is encountered in "install
> at end" mode in the method mentioned in the title, the {{project}} method
> argument's artifact ID should be mentioned as it might not be the same as the
> {{project}} parameter on the class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8084) Make the v4 api usable outside the Maven runtime
[ https://issues.apache.org/jira/browse/MNG-8084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840324#comment-17840324 ] ASF GitHub Bot commented on MNG-8084: - gnodet commented on PR #1461: URL: https://github.com/apache/maven/pull/1461#issuecomment-2074335291 > > I'm happy to update it if you tell me what remains to do: it's just a small update of an OpenOffice document, save as .svg and run the update `prepare-svg.sh` script > > > It's not readable unfortunately, but it started from generated graph, so it's correct with current master. > > > > > > BTW, I'd be interested to be able to create this type of automatic drawing as a reference > `mvn org.fusesource.mvnplugins:maven-graph-plugin:reactor -Dhide-version -Dhide-group-id -Dhide-scope=test -Dhide-transitive` gives the following:  > Make the v4 api usable outside the Maven runtime > > > Key: MNG-8084 > URL: https://issues.apache.org/jira/browse/MNG-8084 > Project: Maven > Issue Type: New Feature >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8084) Make the v4 api usable outside the Maven runtime
[ https://issues.apache.org/jira/browse/MNG-8084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840320#comment-17840320 ] ASF GitHub Bot commented on MNG-8084: - gnodet commented on PR #1461: URL: https://github.com/apache/maven/pull/1461#issuecomment-2074304566 > I'm happy to update it if you tell me what remains to do: it's just a small update of an OpenOffice document, save as .svg and run the update `prepare-svg.sh` script > > > It's not readable unfortunately, but it started from generated graph, so it's correct with current master. > > BTW, I'd be interested to be able to create this type of automatic drawing as a reference `mvn org.fusesource.mvnplugins:maven-graph-plugin:reactor` does render something automatically...  > Make the v4 api usable outside the Maven runtime > > > Key: MNG-8084 > URL: https://issues.apache.org/jira/browse/MNG-8084 > Project: Maven > Issue Type: New Feature >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-86) Bugfix and enhancements with the restoration of outputs on disk
[ https://issues.apache.org/jira/browse/MBUILDCACHE-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840304#comment-17840304 ] ASF GitHub Bot commented on MBUILDCACHE-86: --- hboutemy commented on PR #104: URL: https://github.com/apache/maven-build-cache-extension/pull/104#issuecomment-2074220142 > some "weird" pom files oh, this is Maven 4 consumer POMs, that seem to have been generated with random file names @gnodet do we really want these random file names? Do we need to create a hack in build cache extension to manage this randomness? > Bugfix and enhancements with the restoration of outputs on disk > --- > > Key: MBUILDCACHE-86 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-86 > Project: Maven Build Cache Extension > Issue Type: Improvement >Reporter: Kevin Buntrock >Priority: Major > Labels: pull-request-available > > *Fixes :* > * Files containing an underscore in their name can't be restored in the > cache directory correctly (not in the same directory location). > * The cache is able to extract/restore files in locations outside the > project. I guess the extraction part is not a vulnerability since someone > with commit permissions can guess other ways to extract data. But the > possibility of restoring at any place on the disk looks pretty dangerous to > me if a remote cache server is compromised. > *Enhancements :* > * Possibility to restore artefacts on disk, with a dedicated property : > maven.build.cache.restoreOnDiskArtefacts (default to true). Meaning in the > project directory, as opposed to the cache directory. > ** IDE integration and use of the cache locally in developement is way > easier. It is now possible to retrieve a cached jar in the "target" directory. > * Introduce "globs" to filter extra attached outputs by filenames. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8084) Make the v4 api usable outside the Maven runtime
[ https://issues.apache.org/jira/browse/MNG-8084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840303#comment-17840303 ] ASF GitHub Bot commented on MNG-8084: - hboutemy commented on PR #1461: URL: https://github.com/apache/maven/pull/1461#issuecomment-2074207980 I'm happy to update it if you tell me what remains to do: it's just a small update of an OpenOffice document, save as .svg and run the update `prepare-svg.sh` script > Make the v4 api usable outside the Maven runtime > > > Key: MNG-8084 > URL: https://issues.apache.org/jira/browse/MNG-8084 > Project: Maven > Issue Type: New Feature >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MDEP-923) Code cleanups
[
https://issues.apache.org/jira/browse/MDEP-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840236#comment-17840236
]
ASF GitHub Bot commented on MDEP-923:
-
slawekjaranowski opened a new pull request, #383:
URL: https://github.com/apache/maven-dependency-plugin/pull/383
(no comment)
> Code cleanups
> -
>
> Key: MDEP-923
> URL: https://issues.apache.org/jira/browse/MDEP-923
> Project: Maven Dependency Plugin
> Issue Type: Task
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
>
> * remove usage of deprecated API where possible
> * cleanup pom after update to 42
> * exclude transitive dependencies on org.apache.maven
> * add {{@project.version@}} in ITs
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-88) Tests in failure when ran on jdk21
[
https://issues.apache.org/jira/browse/MBUILDCACHE-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840231#comment-17840231
]
ASF GitHub Bot commented on MBUILDCACHE-88:
---
olamy commented on PR #147:
URL:
https://github.com/apache/maven-build-cache-extension/pull/147#issuecomment-2073450704
Thanks for this.
To be sure this is tested maybe you could add build on jdk21 for both GHA
and Jenkins.
Thanks
> Tests in failure when ran on jdk21
> --
>
> Key: MBUILDCACHE-88
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-88
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Kevin Buntrock
>Priority: Minor
> Labels: pull-request-available
>
> The project tests cannot be run on jdk21. Result is :
> {code:java}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] CacheConfigImplTest.testInitializationDisabledInXML:234 expected:
> but was:
> [ERROR]
> CacheConfigImplTest.testRemoteDisableByUserPropertyOverride:330->assertDefaults:137->assertDefaults:201->lambda$testRemoteDisableByUserPropertyOverride$39:330
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteEnableByUserPropertyOverrideWithURL:313->assertDefaults:137->assertDefaults:201->lambda$testRemoteEnableByUserPropertyOverrideWithURL$38:315
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteEnableInXMLWithURL:288->assertDefaults:137->assertDefaults:201->lambda$testRemoteEnableInXMLWithURL$36:290
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteSaveIgnoredWhenRemoteDisabledByUserPropertyOverride:420->assertDefaults:137->assertDefaults:201->lambda$testRemoteSaveIgnoredWhenRemoteDisabledByUserPropertyOverride$48:420
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveDisabledByUserProperty:381->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveDisabledByUserProperty$47:383
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveEnabledByUserProperty:362->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveEnabledByUserProperty$45:365
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveEnabledInXML:344->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveEnabledInXML$42:347
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveFinalEnabledByUserProperty:436->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveFinalEnabledByUserProperty$51:439
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveFinalIgnoredWhenRemoteSaveDisabled:455->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveFinalIgnoredWhenRemoteSaveDisabled$54:457
> expected: but was:
> [INFO]
> [ERROR] Tests run: 71, Failures: 10, Errors: 0, Skipped: 4
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
> {code}
> In class "CacheConfigImplTest", a method "deepMockConfigFile" mocks the
> result of the call to java.nio.file.Files.exists (via
> "FileSystemProvider.checkAccess").
> In jdk21 version, "Files.exists" does not rely on the same underlying
> "FileSystemProvider" method, therefore breaking the mocking purpose.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MDEP-924) Get rid of maven-artifact-transfer from list-classes goal
[ https://issues.apache.org/jira/browse/MDEP-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840227#comment-17840227 ] ASF GitHub Bot commented on MDEP-924: - slawekjaranowski opened a new pull request, #382: URL: https://github.com/apache/maven-dependency-plugin/pull/382 https://issues.apache.org/jira/browse/MDEP-924 > Get rid of maven-artifact-transfer from list-classes goal > - > > Key: MDEP-924 > URL: https://issues.apache.org/jira/browse/MDEP-924 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: list-classes >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.7.0 > > > We can use Resolver API > Done in simple Mojo as preparing for other. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MDEP-924) Get rid of maven-artifact-transfer from list-classes goal
[ https://issues.apache.org/jira/browse/MDEP-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MDEP-924: - Component/s: list-classes > Get rid of maven-artifact-transfer from list-classes goal > - > > Key: MDEP-924 > URL: https://issues.apache.org/jira/browse/MDEP-924 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: list-classes >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.7.0 > > > We can use Resolver API > Done in simple Mojo as preparing for other. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8081) default profile activation should consider available system and user properties
[
https://issues.apache.org/jira/browse/MNG-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840226#comment-17840226
]
ASF GitHub Bot commented on MNG-8081:
-
gnodet commented on PR #1446:
URL: https://github.com/apache/maven/pull/1446#issuecomment-2073420753
@mbenson I've rebased the PR and ported it to the new v4 model builder,
please have a look
> default profile activation should consider available system and user
> properties
> ---
>
> Key: MNG-8081
> URL: https://issues.apache.org/jira/browse/MNG-8081
> Project: Maven
> Issue Type: Improvement
> Components: Profiles
>Affects Versions: 3.9.6, 4.0.0
>Reporter: Matthew Jason Benson
>Priority: Minor
> Fix For: 3.9.7, 4.0.0, 4.0.0-beta-1
>
>
> As discussed in my open PR, my use case is to compare between environment
> variables e.g.:
> {code:java}
>
>
> env.FOO
> ${env.BAR}
>
> {code}
> Limiting the interpolation to user/system properties means that there is no
> mindf*ck resulting from profile activation order, etc., and keeps this
> request nonthreatening.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DOXIASITETOOLS-321) Upgrade htmlunit 2.x to 3.x
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated DOXIASITETOOLS-321: Summary: Upgrade htmlunit 2.x to 3.x (was: Upgrade htmlunit 2.x to 4.0.0) > Upgrade htmlunit 2.x to 3.x > --- > > Key: DOXIASITETOOLS-321 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-321 > Project: Maven Doxia Sitetools > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 2.0.0, 2.0.0-M17, 2.0.0-M18 > > > https://github.com/advisories/GHSA-3xrr-7m6p-p7xh -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSITE-1003) Upgrade plugins and components (in ITs)
[ https://issues.apache.org/jira/browse/MSITE-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSITE-1003: -- Description: * Upgrade to Doxia 2.0.0-M10 * Upgrade to Doxia Sitetools 2.0.0-M18 * Upgrade to Maven Reporting API 4.0.0-M11 * Upgrade to Maven Reporting Impl 4.0.0-M14 * Upgrade to Maven Reporting Exec 4.0.0-M13 * Upgrade to Maven Plugin Tools 3.12.0 * Upgrade to Maven JXR Plugin 3.3.2 was: * Upgrade to Doxia 2.0.0-M9 * Upgrade to Doxia Sitetools 2.0.0-M17 * Upgrade to Maven Reporting API 4.0.0-M10 * Upgrade to Maven Reporting Impl 4.0.0-M14 * Upgrade to Maven Reporting Exec 4.0.0-M13 * Upgrade to Maven Plugin Tools 3.11.0 * Upgrade to Maven JXR Plugin 3.3.2 > Upgrade plugins and components (in ITs) > --- > > Key: MSITE-1003 > URL: https://issues.apache.org/jira/browse/MSITE-1003 > Project: Maven Site Plugin > Issue Type: Dependency upgrade >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-M14 > > > * Upgrade to Doxia 2.0.0-M10 > * Upgrade to Doxia Sitetools 2.0.0-M18 > * Upgrade to Maven Reporting API 4.0.0-M11 > * Upgrade to Maven Reporting Impl 4.0.0-M14 > * Upgrade to Maven Reporting Exec 4.0.0-M13 > * Upgrade to Maven Plugin Tools 3.12.0 > * Upgrade to Maven JXR Plugin 3.3.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHARED-1362) Upgrade plugins and components (in ITs)
[ https://issues.apache.org/jira/browse/MSHARED-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSHARED-1362: Description: * Upgrade to Maven Site Plugin 4.0.0-M13 * Upgrade to Doxia 2.0.0-M10 * Upgrade to Doxia Sitetools 2.0.0-M18 * Upgrade to Maven Reporting API 4.0.0-M11 * Upgrade to Maven Reporting Impl 4.0.0-M14 * Upgrade to Maven Plugin Tools 3.12.0 was: * Upgrade to Maven Site Plugin 4.0.0-M13 * Upgrade to Doxia 2.0.0-M10 * Upgrade to Doxia Sitetools 2.0.0-M19 * Upgrade to Maven Reporting API 4.0.0-M11 * Upgrade to Maven Reporting Impl 4.0.0-M15 * Upgrade to Maven Plugin Tools 3.12.0 > Upgrade plugins and components (in ITs) > --- > > Key: MSHARED-1362 > URL: https://issues.apache.org/jira/browse/MSHARED-1362 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-reporting-exec >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: maven-reporting-exec-2.0.0, > maven-reporting-exec-2.0.0-M13 > > > * Upgrade to Maven Site Plugin 4.0.0-M13 > * Upgrade to Doxia 2.0.0-M10 > * Upgrade to Doxia Sitetools 2.0.0-M18 > * Upgrade to Maven Reporting API 4.0.0-M11 > * Upgrade to Maven Reporting Impl 4.0.0-M14 > * Upgrade to Maven Plugin Tools 3.12.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MDEP-925) Require Maven 3.6.3
[ https://issues.apache.org/jira/browse/MDEP-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840207#comment-17840207 ] ASF GitHub Bot commented on MDEP-925: - slawekjaranowski merged PR #381: URL: https://github.com/apache/maven-dependency-plugin/pull/381 > Require Maven 3.6.3 > --- > > Key: MDEP-925 > URL: https://issues.apache.org/jira/browse/MDEP-925 > Project: Maven Dependency Plugin > Issue Type: Improvement >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.7.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MDEP-925) Require Maven 3.6.3
[ https://issues.apache.org/jira/browse/MDEP-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MDEP-925. Resolution: Fixed > Require Maven 3.6.3 > --- > > Key: MDEP-925 > URL: https://issues.apache.org/jira/browse/MDEP-925 > Project: Maven Dependency Plugin > Issue Type: Improvement >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.7.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHADE-471) still timestamp issues with timezones (DST)
[
https://issues.apache.org/jira/browse/MSHADE-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSHADE-471:
-
Summary: still timestamp issues with timezones (DST) (was: still timestamp
issues with timezones (DST?))
> still timestamp issues with timezones (DST)
> ---
>
> Key: MSHADE-471
> URL: https://issues.apache.org/jira/browse/MSHADE-471
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.5.3
>
>
> MSHADE-420 is incomplete, problems still appear like
> {noformat}1 / 1
> target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
> toolbox/target/toolbox-0.1.5-cli.jar
> --- target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
> +++ toolbox/target/toolbox-0.1.5-cli.jar
> ├── zipinfo {}
> │ @@ -735,96 +735,96 @@
> │ -rw 2.0 fat 50 bl defN 24-Jan-23 12:20
> META-INF/maven/org.jline/jline/pom.properties
> │ --rw 2.0 fat0 bl defN 23-Oct-12 07:38
> META-INF/native-image/jansi/
> │ --rw 2.0 fat12491 bl defN 23-Oct-12 07:38
> META-INF/native-image/jansi/jni-config.json
> ...
> │ --rw 2.0 fat17329 bl defN 23-Oct-12 07:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.xml
> │ --rw 2.0 fat 60 bl defN 23-Oct-12 07:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.properties
> │ +-rw 2.0 fat0 bl defN 23-Oct-12 06:38
> META-INF/native-image/jansi/
> │ +-rw 2.0 fat12491 bl defN 23-Oct-12 06:38
> META-INF/native-image/jansi/jni-config.json
> ...
> │ +-rw 2.0 fat17329 bl defN 23-Oct-12 06:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.xml
> │ +-rw 2.0 fat 60 bl defN 23-Oct-12 06:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.properties
> │ -rw 2.0 fat0 bl defN 24-Apr-11 20:18
> eu/maveniverse/maven/toolbox/shared/
> {noformat}
> https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/eu/maveniverse/maven/toolbox/README.md
> (fixed since then by using a TZ, but initial UTC shows the issue)
> looks related to DST: probably need to apply what has been done in
> plexus-archiver
> https://github.com/codehaus-plexus/plexus-archiver/commit/b9ea3bf0e4c25c0a5cf1bcbc76e691067003dc36
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSHARED-1361) Upgrade plugins and components (in ITs) (2)
[ https://issues.apache.org/jira/browse/MSHARED-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSHARED-1361: Description: * Upgrade to Doxia 2.0.0-M11 * Upgrade to Doxia Sitetools 2.0.0-M18 * Upgrade to Maven Reporting API 4.0.0-M11 * Upgrade to Maven Plugin Tools 3.12.0 was: * Upgrade to Doxia 2.0.0-M10 * Upgrade to Doxia Sitetools 2.0.0-M19 * Upgrade to Maven Reporting API 4.0.0-M11 * Upgrade to Maven Plugin Tools 3.12.0 > Upgrade plugins and components (in ITs) (2) > --- > > Key: MSHARED-1361 > URL: https://issues.apache.org/jira/browse/MSHARED-1361 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-reporting-impl >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: maven-reporting-impl-4.0.0, > maven-reporting-impl-4.0.0-M14 > > > * Upgrade to Doxia 2.0.0-M11 > * Upgrade to Doxia Sitetools 2.0.0-M18 > * Upgrade to Maven Reporting API 4.0.0-M11 > * Upgrade to Maven Plugin Tools 3.12.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHARED-1361) Upgrade plugins and components (in ITs) (2)
[ https://issues.apache.org/jira/browse/MSHARED-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSHARED-1361: Description: * Upgrade to Doxia 2.0.0-M10 * Upgrade to Doxia Sitetools 2.0.0-M18 * Upgrade to Maven Reporting API 4.0.0-M11 * Upgrade to Maven Plugin Tools 3.12.0 was: * Upgrade to Doxia 2.0.0-M11 * Upgrade to Doxia Sitetools 2.0.0-M18 * Upgrade to Maven Reporting API 4.0.0-M11 * Upgrade to Maven Plugin Tools 3.12.0 > Upgrade plugins and components (in ITs) (2) > --- > > Key: MSHARED-1361 > URL: https://issues.apache.org/jira/browse/MSHARED-1361 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-reporting-impl >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: maven-reporting-impl-4.0.0, > maven-reporting-impl-4.0.0-M14 > > > * Upgrade to Doxia 2.0.0-M10 > * Upgrade to Doxia Sitetools 2.0.0-M18 > * Upgrade to Maven Reporting API 4.0.0-M11 > * Upgrade to Maven Plugin Tools 3.12.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DOXIA-730) Update Asciidoctor Doxia Modules in doxia-site
[ https://issues.apache.org/jira/browse/DOXIA-730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated DOXIA-730: - Component/s: Documentation > Update Asciidoctor Doxia Modules in doxia-site > -- > > Key: DOXIA-730 > URL: https://issues.apache.org/jira/browse/DOXIA-730 > Project: Maven Doxia > Issue Type: Improvement > Components: Documentation >Reporter: Abel Salgado Romero >Assignee: Sylwester Lachiewicz >Priority: Major > > In v3.0.0, we renamed the current module and created a new one. > I am working on a PR to update the page > https://maven.apache.org/doxia/references/index.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DOXIA-730) Update Asciidoctor Doxia Modules in doxia-site
[ https://issues.apache.org/jira/browse/DOXIA-730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated DOXIA-730: - Fix Version/s: (was: 2.0.0) (was: 2.0.0-M10) > Update Asciidoctor Doxia Modules in doxia-site > -- > > Key: DOXIA-730 > URL: https://issues.apache.org/jira/browse/DOXIA-730 > Project: Maven Doxia > Issue Type: Improvement >Reporter: Abel Salgado Romero >Assignee: Sylwester Lachiewicz >Priority: Major > > In v3.0.0, we renamed the current module and created a new one. > I am working on a PR to update the page > https://maven.apache.org/doxia/references/index.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (DOXIASITETOOLS-336) Make SiteRenderingContext#siteDirectories editable aware
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed DOXIASITETOOLS-336.
-
Resolution: Fixed
Fixed with
[f76b6608ef1084cb125a8ab5e351af8f7022c92a|https://gitbox.apache.org/repos/asf?p=maven-doxia-sitetools.git;a=commit;h=f76b6608ef1084cb125a8ab5e351af8f7022c92a].
> Make SiteRenderingContext#siteDirectories editable aware
>
>
> Key: DOXIASITETOOLS-336
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-336
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 2.0.0-M16
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0, 2.0.0-M18
>
>
> Right now you cannot qualify a {{siteDirectory}} whether the content is
> editable or generated. You need to perform multiple calls with distinct
> {{SiteRenderingContexts}}. This causes computational overhead is hacks like
> MSITE-723.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-336) Make SiteRenderingContext#siteDirectories editable aware
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840193#comment-17840193
]
ASF GitHub Bot commented on DOXIASITETOOLS-336:
---
asfgit closed pull request #150: [DOXIASITETOOLS-336] Make
SiteRenderingContext#siteDirectories editab…
URL: https://github.com/apache/maven-doxia-sitetools/pull/150
> Make SiteRenderingContext#siteDirectories editable aware
>
>
> Key: DOXIASITETOOLS-336
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-336
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 2.0.0-M16
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0, 2.0.0-M18
>
>
> Right now you cannot qualify a {{siteDirectory}} whether the content is
> editable or generated. You need to perform multiple calls with distinct
> {{SiteRenderingContexts}}. This causes computational overhead is hacks like
> MSITE-723.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-336) Make SiteRenderingContext#siteDirectories editable aware
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840194#comment-17840194
]
ASF GitHub Bot commented on DOXIASITETOOLS-336:
---
asfgit merged PR #150:
URL: https://github.com/apache/maven-doxia-sitetools/pull/150
> Make SiteRenderingContext#siteDirectories editable aware
>
>
> Key: DOXIASITETOOLS-336
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-336
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 2.0.0-M16
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0, 2.0.0-M18
>
>
> Right now you cannot qualify a {{siteDirectory}} whether the content is
> editable or generated. You need to perform multiple calls with distinct
> {{SiteRenderingContexts}}. This causes computational overhead is hacks like
> MSITE-723.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-588) JUnit4 test framework to JUnit5 migration
[ https://issues.apache.org/jira/browse/MCOMPILER-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840161#comment-17840161 ] Mikhail Deviatov commented on MCOMPILER-588: [~sjaranowski] hi! Could you please provide a feedback? :) > JUnit4 test framework to JUnit5 migration > - > > Key: MCOMPILER-588 > URL: https://issues.apache.org/jira/browse/MCOMPILER-588 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: Mikhail Deviatov >Priority: Major > > We have JUnit5 test framework for a long time. > It have modular architecture, good support in IDE and quite fast. It would be > good to add support JUnit5 to the project. > The problem is that there are 2 library used for testing in project > *maven-plugin-testing-harness* and *org.eclipse.sisu.plexus* and they both > don't have JUnit5 support. > I created a solution that overrides parts of code used derived and my own > implementation. > Please take a look at it > https://github.com/apache/maven-compiler-plugin/pull/233 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8103) Upgrade default plugin bindings
[
https://issues.apache.org/jira/browse/MNG-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MNG-8103.
Fix Version/s: 4.0.0
Resolution: Fixed
> Upgrade default plugin bindings
> ---
>
> Key: MNG-8103
> URL: https://issues.apache.org/jira/browse/MNG-8103
> Project: Maven
> Issue Type: Dependency upgrade
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 4.0.0, 4.0.0-beta-1
>
>
> {noformat}
> 3.9.x
> compiler3.11.0 -> 3.13.0
> surefire3.2.2 -> 3.2.5
> jar 3.3.0 -> 3.4.1
> plugin 3.9.0 -> 3.12.0
> 4.x
> compiler3.11.0 -> 3.13.0
> surefire3.1.2 -> 3.2.5
> jar 3.3.0 -> 3.4.1
> plugin 3.9.0 -> 3.12.0
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8103) Upgrade default plugin bindings
[
https://issues.apache.org/jira/browse/MNG-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840141#comment-17840141
]
ASF GitHub Bot commented on MNG-8103:
-
slawekjaranowski merged PR #1475:
URL: https://github.com/apache/maven/pull/1475
> Upgrade default plugin bindings
> ---
>
> Key: MNG-8103
> URL: https://issues.apache.org/jira/browse/MNG-8103
> Project: Maven
> Issue Type: Dependency upgrade
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 4.0.0-beta-1
>
>
> {noformat}
> 3.9.x
> compiler3.11.0 -> 3.13.0
> surefire3.2.2 -> 3.2.5
> jar 3.3.0 -> 3.4.1
> plugin 3.9.0 -> 3.12.0
> 4.x
> compiler3.11.0 -> 3.13.0
> surefire3.1.2 -> 3.2.5
> jar 3.3.0 -> 3.4.1
> plugin 3.9.0 -> 3.12.0
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-336) Make SiteRenderingContext#siteDirectories editable aware
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840135#comment-17840135
]
ASF GitHub Bot commented on DOXIASITETOOLS-336:
---
michael-o commented on PR #150:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/150#issuecomment-2072684521
@kwin Just ran:
```
osipovmi@deblndw011x:~/var/Projekte/maven-project-info-reports-plugin
(doxia-2.0.0 *=)
$ git diff -U0
diff --git a/pom.xml b/pom.xml
index 9395b30..69c5416 100644
-
> Make SiteRenderingContext#siteDirectories editable aware
>
>
> Key: DOXIASITETOOLS-336
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-336
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 2.0.0-M16
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0, 2.0.0-M18
>
>
> Right now you cannot qualify a {{siteDirectory}} whether the content is
> editable or generated. You need to perform multiple calls with distinct
> {{SiteRenderingContexts}}. This causes computational overhead is hacks like
> MSITE-723.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-336) Make SiteRenderingContext#siteDirectories editable aware
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840110#comment-17840110
]
ASF GitHub Bot commented on DOXIASITETOOLS-336:
---
michael-o commented on PR #150:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/150#issuecomment-2072373572
I will run our plugins and see how it goes.
> Make SiteRenderingContext#siteDirectories editable aware
>
>
> Key: DOXIASITETOOLS-336
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-336
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 2.0.0-M16
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0, 2.0.0-M18
>
>
> Right now you cannot qualify a {{siteDirectory}} whether the content is
> editable or generated. You need to perform multiple calls with distinct
> {{SiteRenderingContexts}}. This causes computational overhead is hacks like
> MSITE-723.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-8102) Upgrade Parent to 42
[ https://issues.apache.org/jira/browse/MNG-8102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-8102. Fix Version/s: 4.0.0 Resolution: Fixed > Upgrade Parent to 42 > > > Key: MNG-8102 > URL: https://issues.apache.org/jira/browse/MNG-8102 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8102) Upgrade Parent to 42
[ https://issues.apache.org/jira/browse/MNG-8102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840105#comment-17840105 ] ASF GitHub Bot commented on MNG-8102: - gnodet merged PR #1476: URL: https://github.com/apache/maven/pull/1476 > Upgrade Parent to 42 > > > Key: MNG-8102 > URL: https://issues.apache.org/jira/browse/MNG-8102 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 4.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8025) API incompatibility with m-remote-resources-p
[
https://issues.apache.org/jira/browse/MNG-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840103#comment-17840103
]
ASF GitHub Bot commented on MNG-8025:
-
gnodet merged PR #1467:
URL: https://github.com/apache/maven/pull/1467
> API incompatibility with m-remote-resources-p
> -
>
> Key: MNG-8025
> URL: https://issues.apache.org/jira/browse/MNG-8025
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-12
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-beta-1
>
>
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-remote-resources-plugin:3.1.0:process
> (default) on project sshd: Execution default of goal
> org.apache.maven.plugins:maven-remote-resources-plugin:3.1.0:process failed:
> An API incompatibility was encountered while executing
> org.apache.maven.plugins:maven-remote-resources-plugin:3.1.0:process:
> java.lang.NoSuchMethodError: 'void
> org.apache.maven.model.Plugin.unsetInheritanceApplied()'
> [ERROR] -
> [ERROR] realm =
> plugin>org.apache.maven.plugins:maven-remote-resources-plugin:3.1.0
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-8025) API incompatibility with m-remote-resources-p
[
https://issues.apache.org/jira/browse/MNG-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-8025.
Resolution: Fixed
> API incompatibility with m-remote-resources-p
> -
>
> Key: MNG-8025
> URL: https://issues.apache.org/jira/browse/MNG-8025
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-12
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-beta-1
>
>
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-remote-resources-plugin:3.1.0:process
> (default) on project sshd: Execution default of goal
> org.apache.maven.plugins:maven-remote-resources-plugin:3.1.0:process failed:
> An API incompatibility was encountered while executing
> org.apache.maven.plugins:maven-remote-resources-plugin:3.1.0:process:
> java.lang.NoSuchMethodError: 'void
> org.apache.maven.model.Plugin.unsetInheritanceApplied()'
> [ERROR] -
> [ERROR] realm =
> plugin>org.apache.maven.plugins:maven-remote-resources-plugin:3.1.0
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8105) Upgrade to JLine 3.26.0
[ https://issues.apache.org/jira/browse/MNG-8105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840104#comment-17840104 ] ASF GitHub Bot commented on MNG-8105: - gnodet merged PR #1478: URL: https://github.com/apache/maven/pull/1478 > Upgrade to JLine 3.26.0 > --- > > Key: MNG-8105 > URL: https://issues.apache.org/jira/browse/MNG-8105 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8105) Upgrade to JLine 3.26.0
[ https://issues.apache.org/jira/browse/MNG-8105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-8105. Fix Version/s: 4.0.0 Resolution: Fixed > Upgrade to JLine 3.26.0 > --- > > Key: MNG-8105 > URL: https://issues.apache.org/jira/browse/MNG-8105 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8105) Upgrade to JLine 3.26.0
Guillaume Nodet created MNG-8105: Summary: Upgrade to JLine 3.26.0 Key: MNG-8105 URL: https://issues.apache.org/jira/browse/MNG-8105 Project: Maven Issue Type: Dependency upgrade Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 4.0.0-beta-1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8025) API incompatibility with m-remote-resources-p
[
https://issues.apache.org/jira/browse/MNG-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-8025:
-
Fix Version/s: 4.0.0
> API incompatibility with m-remote-resources-p
> -
>
> Key: MNG-8025
> URL: https://issues.apache.org/jira/browse/MNG-8025
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-12
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0, 4.0.0-beta-1
>
>
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-remote-resources-plugin:3.1.0:process
> (default) on project sshd: Execution default of goal
> org.apache.maven.plugins:maven-remote-resources-plugin:3.1.0:process failed:
> An API incompatibility was encountered while executing
> org.apache.maven.plugins:maven-remote-resources-plugin:3.1.0:process:
> java.lang.NoSuchMethodError: 'void
> org.apache.maven.model.Plugin.unsetInheritanceApplied()'
> [ERROR] -
> [ERROR] realm =
> plugin>org.apache.maven.plugins:maven-remote-resources-plugin:3.1.0
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-8038) Model builder API
[
https://issues.apache.org/jira/browse/MNG-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-8038.
Fix Version/s: (was: 4.0.0)
Resolution: Fixed
> Model builder API
> -
>
> Key: MNG-8038
> URL: https://issues.apache.org/jira/browse/MNG-8038
> Project: Maven
> Issue Type: Improvement
> Components: API
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-beta-1
>
>
> In some cases, it may be needed to access the _raw_ or the _effective_ model
> of artifacts downloaded from repositories (usually dependencies of the
> current project). The file model can already be read using the
> {{ModelXmlFactory}} but that's quite limited in scope.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-8082) Exceptions of proxied SessionScoped components are not working correctly
[
https://issues.apache.org/jira/browse/MNG-8082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-8082.
Fix Version/s: 4.0.0-alpha-14
Resolution: Fixed
> Exceptions of proxied SessionScoped components are not working correctly
>
>
> Key: MNG-8082
> URL: https://issues.apache.org/jira/browse/MNG-8082
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-13
>Reporter: Jonas Rutishauser
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-14
>
>
> As the {{InvocationTargetException}} is not handled in the proxy a runtime
> exception will be wrapped by an {{InvocationTargetException}} and an
> application exception is additional wrapped by an
> {{UndeclaredThrowableException}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8082) Exceptions of proxied SessionScoped components are not working correctly
[
https://issues.apache.org/jira/browse/MNG-8082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840092#comment-17840092
]
ASF GitHub Bot commented on MNG-8082:
-
gnodet merged PR #1449:
URL: https://github.com/apache/maven/pull/1449
> Exceptions of proxied SessionScoped components are not working correctly
>
>
> Key: MNG-8082
> URL: https://issues.apache.org/jira/browse/MNG-8082
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-13
>Reporter: Jonas Rutishauser
>Priority: Major
>
> As the {{InvocationTargetException}} is not handled in the proxy a runtime
> exception will be wrapped by an {{InvocationTargetException}} and an
> application exception is additional wrapped by an
> {{UndeclaredThrowableException}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-8038) Model builder API
[
https://issues.apache.org/jira/browse/MNG-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MNG-8038:
Assignee: Guillaume Nodet
> Model builder API
> -
>
> Key: MNG-8038
> URL: https://issues.apache.org/jira/browse/MNG-8038
> Project: Maven
> Issue Type: Improvement
> Components: API
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0, 4.0.0-beta-1
>
>
> In some cases, it may be needed to access the _raw_ or the _effective_ model
> of artifacts downloaded from repositories (usually dependencies of the
> current project). The file model can already be read using the
> {{ModelXmlFactory}} but that's quite limited in scope.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-8082) Exceptions of proxied SessionScoped components are not working correctly
[
https://issues.apache.org/jira/browse/MNG-8082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MNG-8082:
Assignee: Guillaume Nodet
> Exceptions of proxied SessionScoped components are not working correctly
>
>
> Key: MNG-8082
> URL: https://issues.apache.org/jira/browse/MNG-8082
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-13
>Reporter: Jonas Rutishauser
>Assignee: Guillaume Nodet
>Priority: Major
>
> As the {{InvocationTargetException}} is not handled in the proxy a runtime
> exception will be wrapped by an {{InvocationTargetException}} and an
> application exception is additional wrapped by an
> {{UndeclaredThrowableException}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8104) proxy settings ignored for dependencies
[ https://issues.apache.org/jira/browse/MNG-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840090#comment-17840090 ] Tamas Cservenak commented on MNG-8104: -- One more question: you say 3.9.2 "works" and 3.9.6 "does not work". Any info about used m-dependency-p version maybe? So m-dependency-p 3.6.1 works in Maven 3.9.2 but does not work in Maven 3.9.6? > proxy settings ignored for dependencies > --- > > Key: MNG-8104 > URL: https://issues.apache.org/jira/browse/MNG-8104 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.9.6 >Reporter: Patrick Mackinlay >Priority: Major > Attachments: image-2024-04-23-12-02-38-218.png, settings.xml > > > The proxy settings are ignored for dependencies in maven 3.9.6 (working in > 3.9.2). > On a machine with no direct internet access, if you clear your local > repository with a command like: > rm -rf ~/.m2/repository/org/apache/maven/maven-core/2.2.1 > and then try and download the dependency: > mvn dependency:get -DgroupId=org.apache.maven -DartifactId=maven-core > -Dversion=2.2.1 > > It will fail. The proxy settings are ignored. However, it should be noted > that for plugins they are used, its only for dependencies that they are > ignored. > maven version 3.9.2 works, so looks like this was introduced in 3.9.3 > probably when the dependency plugin version was upgraded. > > I used a minimal settings.xml with just one proxy entry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8104) proxy settings ignored for dependencies
[ https://issues.apache.org/jira/browse/MNG-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840089#comment-17840089 ] Tamas Cservenak commented on MNG-8104: -- Yes, but this is clearly m-dependency-p issue, as the plugin itself was downloaded (via proxy) as it runs... So, this issue is related to m-dependency-p and not Maven. Maven is fine. > proxy settings ignored for dependencies > --- > > Key: MNG-8104 > URL: https://issues.apache.org/jira/browse/MNG-8104 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.9.6 >Reporter: Patrick Mackinlay >Priority: Major > Attachments: image-2024-04-23-12-02-38-218.png, settings.xml > > > The proxy settings are ignored for dependencies in maven 3.9.6 (working in > 3.9.2). > On a machine with no direct internet access, if you clear your local > repository with a command like: > rm -rf ~/.m2/repository/org/apache/maven/maven-core/2.2.1 > and then try and download the dependency: > mvn dependency:get -DgroupId=org.apache.maven -DartifactId=maven-core > -Dversion=2.2.1 > > It will fail. The proxy settings are ignored. However, it should be noted > that for plugins they are used, its only for dependencies that they are > ignored. > maven version 3.9.2 works, so looks like this was introduced in 3.9.3 > probably when the dependency plugin version was upgraded. > > I used a minimal settings.xml with just one proxy entry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8104) proxy settings ignored for dependencies
[ https://issues.apache.org/jira/browse/MNG-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840074#comment-17840074 ] Patrick Mackinlay commented on MNG-8104: an error like [ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:3.6.1:get (default-cli) on project standalone-pom: Couldn't download artifact: org.eclipse.aether.resolution.DependencyResolutionException: Failed to read artifact descriptor for org.apache.maven:maven-core:jar:2.2.1: The following artifacts could not be resolved: org.apache.maven:maven-core:pom:2.2.1 (absent): Could not transfer artifact org.apache.maven:maven-core:pom:2.2.1 from/to central (https://repo.maven.apache.org/maven2): Connect to repo.maven.apache.org:443 [repo.maven.apache.org/146.75.72.215] failed: connect timed out -> [Help 1] [ERROR] > proxy settings ignored for dependencies > --- > > Key: MNG-8104 > URL: https://issues.apache.org/jira/browse/MNG-8104 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.9.6 >Reporter: Patrick Mackinlay >Priority: Major > Attachments: image-2024-04-23-12-02-38-218.png, settings.xml > > > The proxy settings are ignored for dependencies in maven 3.9.6 (working in > 3.9.2). > On a machine with no direct internet access, if you clear your local > repository with a command like: > rm -rf ~/.m2/repository/org/apache/maven/maven-core/2.2.1 > and then try and download the dependency: > mvn dependency:get -DgroupId=org.apache.maven -DartifactId=maven-core > -Dversion=2.2.1 > > It will fail. The proxy settings are ignored. However, it should be noted > that for plugins they are used, its only for dependencies that they are > ignored. > maven version 3.9.2 works, so looks like this was introduced in 3.9.3 > probably when the dependency plugin version was upgraded. > > I used a minimal settings.xml with just one proxy entry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8104) proxy settings ignored for dependencies
[ https://issues.apache.org/jira/browse/MNG-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840070#comment-17840070 ] Tamas Cservenak commented on MNG-8104: -- When you say "build fails", what error you get? > proxy settings ignored for dependencies > --- > > Key: MNG-8104 > URL: https://issues.apache.org/jira/browse/MNG-8104 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.9.6 >Reporter: Patrick Mackinlay >Priority: Major > Attachments: image-2024-04-23-12-02-38-218.png, settings.xml > > > The proxy settings are ignored for dependencies in maven 3.9.6 (working in > 3.9.2). > On a machine with no direct internet access, if you clear your local > repository with a command like: > rm -rf ~/.m2/repository/org/apache/maven/maven-core/2.2.1 > and then try and download the dependency: > mvn dependency:get -DgroupId=org.apache.maven -DartifactId=maven-core > -Dversion=2.2.1 > > It will fail. The proxy settings are ignored. However, it should be noted > that for plugins they are used, its only for dependencies that they are > ignored. > maven version 3.9.2 works, so looks like this was introduced in 3.9.3 > probably when the dependency plugin version was upgraded. > > I used a minimal settings.xml with just one proxy entry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-515) Plugin is NOT incremental, so let it go
[ https://issues.apache.org/jira/browse/MCOMPILER-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840067#comment-17840067 ] ASF GitHub Bot commented on MCOMPILER-515: -- desruisseaux commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2072026430 The use of Eclipse compiler would not be mandated. If no tool chain or `compilerId` parameter is specified, the plugin uses whatever compiler is returned by `ToolProvider.getSystemJavaCompiler()`. The Eclipse compiler was mentioned only for saying that its use should still be possible. The `JavaCompiler` API seems to have some support for giving the output files with `JavaFileManager.getJavaFileForOutput(StandardLocation.CLASS_OUTPUT, , JavaFileObject.Kind.CLASS, )` (I just tested it). However, it does not return the `*.class` files for inner (nested) classes, so some heuristic would still be needed. > Plugin is NOT incremental, so let it go > --- > > Key: MCOMPILER-515 > URL: https://issues.apache.org/jira/browse/MCOMPILER-515 > Project: Maven Compiler Plugin > Issue Type: Bug >Reporter: Tamas Cservenak >Priority: Major > > The maven-compiler-plugin is NOT incremental, so we should just let it go. > The shared incremental stuff is broken since it's last factual code change > (2012!). > Moreover, the broken incremental stuff just makes us look bad, see the "mvn > clean install" vs "mvn verify" issue: > [https://www.youtube.com/watch?v=XeQj-IbSxJI] > Accept it, that this plugins is not incremental, so it should not make users > believe it is. Moreover, the bugs in this feature exist for too long, that > just cause harm to users and to project as whole. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MNG-8104) proxy settings ignored for dependencies
[ https://issues.apache.org/jira/browse/MNG-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840064#comment-17840064 ] Patrick Mackinlay edited comment on MNG-8104 at 4/23/24 11:04 AM: -- Its not just "dependency:get". I used dependency get as an example and to resproduce the problem. All our builds fail with maven 3.9.6 and a cleared repository. Note that /app/apache-maven-3.9.6/bin/mvn eu.maveniverse.maven.plugins:toolbox:gav-resolve-transitive -Dgav=org.apache.maven:maven-core:2.2.1 works for me. So that must not use the same code path as dependency resolution. The proxy is used in some cases (such as plugin resolution), just not dependency resolution was (Author: JIRAUSER304196): Its not just "dependency:get". I used dependency get as an example and to resproduce the problem. All our builds fail with maven 3.9.6 and a cleared repository. > proxy settings ignored for dependencies > --- > > Key: MNG-8104 > URL: https://issues.apache.org/jira/browse/MNG-8104 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.9.6 >Reporter: Patrick Mackinlay >Priority: Major > Attachments: image-2024-04-23-12-02-38-218.png, settings.xml > > > The proxy settings are ignored for dependencies in maven 3.9.6 (working in > 3.9.2). > On a machine with no direct internet access, if you clear your local > repository with a command like: > rm -rf ~/.m2/repository/org/apache/maven/maven-core/2.2.1 > and then try and download the dependency: > mvn dependency:get -DgroupId=org.apache.maven -DartifactId=maven-core > -Dversion=2.2.1 > > It will fail. The proxy settings are ignored. However, it should be noted > that for plugins they are used, its only for dependencies that they are > ignored. > maven version 3.9.2 works, so looks like this was introduced in 3.9.3 > probably when the dependency plugin version was upgraded. > > I used a minimal settings.xml with just one proxy entry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8104) proxy settings ignored for dependencies
[ https://issues.apache.org/jira/browse/MNG-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840064#comment-17840064 ] Patrick Mackinlay commented on MNG-8104: Its not just "dependency:get". I used dependency get as an example and to resproduce the problem. All our builds fail with maven 3.9.6 and a cleared repository. > proxy settings ignored for dependencies > --- > > Key: MNG-8104 > URL: https://issues.apache.org/jira/browse/MNG-8104 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.9.6 >Reporter: Patrick Mackinlay >Priority: Major > Attachments: image-2024-04-23-12-02-38-218.png, settings.xml > > > The proxy settings are ignored for dependencies in maven 3.9.6 (working in > 3.9.2). > On a machine with no direct internet access, if you clear your local > repository with a command like: > rm -rf ~/.m2/repository/org/apache/maven/maven-core/2.2.1 > and then try and download the dependency: > mvn dependency:get -DgroupId=org.apache.maven -DartifactId=maven-core > -Dversion=2.2.1 > > It will fail. The proxy settings are ignored. However, it should be noted > that for plugins they are used, its only for dependencies that they are > ignored. > maven version 3.9.2 works, so looks like this was introduced in 3.9.3 > probably when the dependency plugin version was upgraded. > > I used a minimal settings.xml with just one proxy entry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-515) Plugin is NOT incremental, so let it go
[ https://issues.apache.org/jira/browse/MCOMPILER-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840059#comment-17840059 ] ASF GitHub Bot commented on MCOMPILER-515: -- gnodet commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2071969652 > > remove plexus-compiler layer but what about other compilers? > > `javax.tools.JavaCompiler` is an interface. From a quick search on internet, I think (but did not verified closely) that the Eclipse compiler implements this interface. If there is still a need for the Plexus compiler, we can write a wrapper. The `javax.tools` API is preferred to the Plexus API because it has some JPMS specific methods that I didn't saw in Plexus API. It also has a method telling us whether an option is valid, and a caching mechanism. > > For languages other than Java, we would need a separated plugin. With JPMS support, multi-releases support, incremental build (even incomplete), etc., this plugin is very Java-specific. The point is that this interface may not be sufficient. Ideally, we'd have a list of output files, that would help with the heuristic. I'm not sure the eclipse compiler is required for full incremental build, I think the requirement for the eclipse compiler is when only exposing direct dependencies for compiled classes (i.e. hide transitive dependencies so that the user is forced to declare those when the code is actually using them) > Plugin is NOT incremental, so let it go > --- > > Key: MCOMPILER-515 > URL: https://issues.apache.org/jira/browse/MCOMPILER-515 > Project: Maven Compiler Plugin > Issue Type: Bug >Reporter: Tamas Cservenak >Priority: Major > > The maven-compiler-plugin is NOT incremental, so we should just let it go. > The shared incremental stuff is broken since it's last factual code change > (2012!). > Moreover, the broken incremental stuff just makes us look bad, see the "mvn > clean install" vs "mvn verify" issue: > [https://www.youtube.com/watch?v=XeQj-IbSxJI] > Accept it, that this plugins is not incremental, so it should not make users > believe it is. Moreover, the bugs in this feature exist for too long, that > just cause harm to users and to project as whole. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8104) proxy settings ignored for dependencies
[
https://issues.apache.org/jira/browse/MNG-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840056#comment-17840056
]
Tamas Cservenak commented on MNG-8104:
--
As a workaround, you can try
{noformat}
eu.maveniverse.maven.plugins:toolbox:gav-resolve-transitive
-Dgav=org.apache.maven:maven-core:2.2.1 {noformat}
Tested it, and this one obeys HTTP proxy.
> proxy settings ignored for dependencies
> ---
>
> Key: MNG-8104
> URL: https://issues.apache.org/jira/browse/MNG-8104
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.6
>Reporter: Patrick Mackinlay
>Priority: Major
> Attachments: image-2024-04-23-12-02-38-218.png, settings.xml
>
>
> The proxy settings are ignored for dependencies in maven 3.9.6 (working in
> 3.9.2).
> On a machine with no direct internet access, if you clear your local
> repository with a command like:
> rm -rf ~/.m2/repository/org/apache/maven/maven-core/2.2.1
> and then try and download the dependency:
> mvn dependency:get -DgroupId=org.apache.maven -DartifactId=maven-core
> -Dversion=2.2.1
>
> It will fail. The proxy settings are ignored. However, it should be noted
> that for plugins they are used, its only for dependencies that they are
> ignored.
> maven version 3.9.2 works, so looks like this was introduced in 3.9.3
> probably when the dependency plugin version was upgraded.
>
> I used a minimal settings.xml with just one proxy entry.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-8104) proxy settings ignored for dependencies
[
https://issues.apache.org/jira/browse/MNG-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840056#comment-17840056
]
Tamas Cservenak edited comment on MNG-8104 at 4/23/24 10:35 AM:
As a workaround, you can try
{noformat}
mvn eu.maveniverse.maven.plugins:toolbox:gav-resolve-transitive
-Dgav=org.apache.maven:maven-core:2.2.1 {noformat}
Tested it, and this one obeys HTTP proxy.
was (Author: cstamas):
As a workaround, you can try
{noformat}
eu.maveniverse.maven.plugins:toolbox:gav-resolve-transitive
-Dgav=org.apache.maven:maven-core:2.2.1 {noformat}
Tested it, and this one obeys HTTP proxy.
> proxy settings ignored for dependencies
> ---
>
> Key: MNG-8104
> URL: https://issues.apache.org/jira/browse/MNG-8104
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.6
>Reporter: Patrick Mackinlay
>Priority: Major
> Attachments: image-2024-04-23-12-02-38-218.png, settings.xml
>
>
> The proxy settings are ignored for dependencies in maven 3.9.6 (working in
> 3.9.2).
> On a machine with no direct internet access, if you clear your local
> repository with a command like:
> rm -rf ~/.m2/repository/org/apache/maven/maven-core/2.2.1
> and then try and download the dependency:
> mvn dependency:get -DgroupId=org.apache.maven -DartifactId=maven-core
> -Dversion=2.2.1
>
> It will fail. The proxy settings are ignored. However, it should be noted
> that for plugins they are used, its only for dependencies that they are
> ignored.
> maven version 3.9.2 works, so looks like this was introduced in 3.9.3
> probably when the dependency plugin version was upgraded.
>
> I used a minimal settings.xml with just one proxy entry.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8104) proxy settings ignored for dependencies
[
https://issues.apache.org/jira/browse/MNG-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840053#comment-17840053
]
Tamas Cservenak commented on MNG-8104:
--
Ok I think I got it. This issue is not about Maven 3.9.6, is fine.
This issue is about dependency:get that it does not honors proxy. On my
reproducer I did this:
{noformat}
$ mvn -Dmaven.repo.local=local -s settings.xml dependency:get
-DgroupId=org.apache.maven -DartifactId=maven-core -Dversion=2.2.1
-Daether.connector.https.securityMode=insecure {noformat}
and plugin was dowloaded thru proxy, but the maven-core:2.2.1 (and transitive
hull) {*}was not{*}.
> proxy settings ignored for dependencies
> ---
>
> Key: MNG-8104
> URL: https://issues.apache.org/jira/browse/MNG-8104
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.6
>Reporter: Patrick Mackinlay
>Priority: Major
> Attachments: image-2024-04-23-12-02-38-218.png, settings.xml
>
>
> The proxy settings are ignored for dependencies in maven 3.9.6 (working in
> 3.9.2).
> On a machine with no direct internet access, if you clear your local
> repository with a command like:
> rm -rf ~/.m2/repository/org/apache/maven/maven-core/2.2.1
> and then try and download the dependency:
> mvn dependency:get -DgroupId=org.apache.maven -DartifactId=maven-core
> -Dversion=2.2.1
>
> It will fail. The proxy settings are ignored. However, it should be noted
> that for plugins they are used, its only for dependencies that they are
> ignored.
> maven version 3.9.2 works, so looks like this was introduced in 3.9.3
> probably when the dependency plugin version was upgraded.
>
> I used a minimal settings.xml with just one proxy entry.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8104) proxy settings ignored for dependencies
[ https://issues.apache.org/jira/browse/MNG-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Mackinlay updated MNG-8104: --- Attachment: settings.xml > proxy settings ignored for dependencies > --- > > Key: MNG-8104 > URL: https://issues.apache.org/jira/browse/MNG-8104 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.9.6 >Reporter: Patrick Mackinlay >Priority: Major > Attachments: image-2024-04-23-12-02-38-218.png, settings.xml > > > The proxy settings are ignored for dependencies in maven 3.9.6 (working in > 3.9.2). > On a machine with no direct internet access, if you clear your local > repository with a command like: > rm -rf ~/.m2/repository/org/apache/maven/maven-core/2.2.1 > and then try and download the dependency: > mvn dependency:get -DgroupId=org.apache.maven -DartifactId=maven-core > -Dversion=2.2.1 > > It will fail. The proxy settings are ignored. However, it should be noted > that for plugins they are used, its only for dependencies that they are > ignored. > maven version 3.9.2 works, so looks like this was introduced in 3.9.3 > probably when the dependency plugin version was upgraded. > > I used a minimal settings.xml with just one proxy entry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8104) proxy settings ignored for dependencies
[ https://issues.apache.org/jira/browse/MNG-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8104: - Attachment: image-2024-04-23-12-02-38-218.png > proxy settings ignored for dependencies > --- > > Key: MNG-8104 > URL: https://issues.apache.org/jira/browse/MNG-8104 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.9.6 >Reporter: Patrick Mackinlay >Priority: Major > Attachments: image-2024-04-23-12-02-38-218.png > > > The proxy settings are ignored for dependencies in maven 3.9.6 (working in > 3.9.2). > On a machine with no direct internet access, if you clear your local > repository with a command like: > rm -rf ~/.m2/repository/org/apache/maven/maven-core/2.2.1 > and then try and download the dependency: > mvn dependency:get -DgroupId=org.apache.maven -DartifactId=maven-core > -Dversion=2.2.1 > > It will fail. The proxy settings are ignored. However, it should be noted > that for plugins they are used, its only for dependencies that they are > ignored. > maven version 3.9.2 works, so looks like this was introduced in 3.9.3 > probably when the dependency plugin version was upgraded. > > I used a minimal settings.xml with just one proxy entry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8104) proxy settings ignored for dependencies
[ https://issues.apache.org/jira/browse/MNG-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840048#comment-17840048 ] Tamas Cservenak commented on MNG-8104: -- Created a reproducer [https://github.com/cstamas/MNG-8104] It works well locally: all went thru mitmproxy !image-2024-04-23-12-02-38-218.png! > proxy settings ignored for dependencies > --- > > Key: MNG-8104 > URL: https://issues.apache.org/jira/browse/MNG-8104 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.9.6 >Reporter: Patrick Mackinlay >Priority: Major > Attachments: image-2024-04-23-12-02-38-218.png > > > The proxy settings are ignored for dependencies in maven 3.9.6 (working in > 3.9.2). > On a machine with no direct internet access, if you clear your local > repository with a command like: > rm -rf ~/.m2/repository/org/apache/maven/maven-core/2.2.1 > and then try and download the dependency: > mvn dependency:get -DgroupId=org.apache.maven -DartifactId=maven-core > -Dversion=2.2.1 > > It will fail. The proxy settings are ignored. However, it should be noted > that for plugins they are used, its only for dependencies that they are > ignored. > maven version 3.9.2 works, so looks like this was introduced in 3.9.3 > probably when the dependency plugin version was upgraded. > > I used a minimal settings.xml with just one proxy entry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8104) proxy settings ignored for dependencies
[ https://issues.apache.org/jira/browse/MNG-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840046#comment-17840046 ] Tamas Cservenak commented on MNG-8104: -- And what kind of error you have? > proxy settings ignored for dependencies > --- > > Key: MNG-8104 > URL: https://issues.apache.org/jira/browse/MNG-8104 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.9.6 >Reporter: Patrick Mackinlay >Priority: Major > > The proxy settings are ignored for dependencies in maven 3.9.6 (working in > 3.9.2). > On a machine with no direct internet access, if you clear your local > repository with a command like: > rm -rf ~/.m2/repository/org/apache/maven/maven-core/2.2.1 > and then try and download the dependency: > mvn dependency:get -DgroupId=org.apache.maven -DartifactId=maven-core > -Dversion=2.2.1 > > It will fail. The proxy settings are ignored. However, it should be noted > that for plugins they are used, its only for dependencies that they are > ignored. > maven version 3.9.2 works, so looks like this was introduced in 3.9.3 > probably when the dependency plugin version was upgraded. > > I used a minimal settings.xml with just one proxy entry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8104) proxy settings ignored for dependencies
[ https://issues.apache.org/jira/browse/MNG-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840033#comment-17840033 ] Patrick Mackinlay commented on MNG-8104: Its a vanilla install of maven 3.9.6, with the ~/.m2 directory completely cleared and the settings containing just one http proxy (can't show the details of the corp network, but its just a regular http proxy). Nothing else, no extensions, no other plugins. Note that the mvn dependency:get command is run from an empty directory, so no pom is read (hence no plugins/extension ..). The problem is as simple as the proxy settings are completely ignored for dependencies. > proxy settings ignored for dependencies > --- > > Key: MNG-8104 > URL: https://issues.apache.org/jira/browse/MNG-8104 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.9.6 >Reporter: Patrick Mackinlay >Priority: Major > > The proxy settings are ignored for dependencies in maven 3.9.6 (working in > 3.9.2). > On a machine with no direct internet access, if you clear your local > repository with a command like: > rm -rf ~/.m2/repository/org/apache/maven/maven-core/2.2.1 > and then try and download the dependency: > mvn dependency:get -DgroupId=org.apache.maven -DartifactId=maven-core > -Dversion=2.2.1 > > It will fail. The proxy settings are ignored. However, it should be noted > that for plugins they are used, its only for dependencies that they are > ignored. > maven version 3.9.2 works, so looks like this was introduced in 3.9.3 > probably when the dependency plugin version was upgraded. > > I used a minimal settings.xml with just one proxy entry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8104) proxy settings ignored for dependencies
[ https://issues.apache.org/jira/browse/MNG-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840029#comment-17840029 ] Tamas Cservenak commented on MNG-8104: -- Can you tell us a bit more info? We talk about Maven 3.9.6, but what transport do you use? What kind of proxy you use? Any extension or alike? > proxy settings ignored for dependencies > --- > > Key: MNG-8104 > URL: https://issues.apache.org/jira/browse/MNG-8104 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.9.6 >Reporter: Patrick Mackinlay >Priority: Major > > The proxy settings are ignored for dependencies in maven 3.9.6 (working in > 3.9.2). > On a machine with no direct internet access, if you clear your local > repository with a command like: > rm -rf ~/.m2/repository/org/apache/maven/maven-core/2.2.1 > and then try and download the dependency: > mvn dependency:get -DgroupId=org.apache.maven -DartifactId=maven-core > -Dversion=2.2.1 > > It will fail. The proxy settings are ignored. However, it should be noted > that for plugins they are used, its only for dependencies that they are > ignored. > maven version 3.9.2 works, so looks like this was introduced in 3.9.3 > probably when the dependency plugin version was upgraded. > > I used a minimal settings.xml with just one proxy entry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8104) proxy settings ignored for dependencies
[ https://issues.apache.org/jira/browse/MNG-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840025#comment-17840025 ] Patrick Mackinlay commented on MNG-8104: Its about the full maven 3.9.6 release, in a corporate environment (no direct internet) nothing can be built with a fresh local repository. A build will result in all the plugins downloading, but then it fails on the first remote dependency. I dont know what component is actually broken... > proxy settings ignored for dependencies > --- > > Key: MNG-8104 > URL: https://issues.apache.org/jira/browse/MNG-8104 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.9.6 >Reporter: Patrick Mackinlay >Priority: Major > > The proxy settings are ignored for dependencies in maven 3.9.6 (working in > 3.9.2). > On a machine with no direct internet access, if you clear your local > repository with a command like: > rm -rf ~/.m2/repository/org/apache/maven/maven-core/2.2.1 > and then try and download the dependency: > mvn dependency:get -DgroupId=org.apache.maven -DartifactId=maven-core > -Dversion=2.2.1 > > It will fail. The proxy settings are ignored. However, it should be noted > that for plugins they are used, its only for dependencies that they are > ignored. > maven version 3.9.2 works, so looks like this was introduced in 3.9.3 > probably when the dependency plugin version was upgraded. > > I used a minimal settings.xml with just one proxy entry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8104) proxy settings ignored for dependencies
[ https://issues.apache.org/jira/browse/MNG-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840021#comment-17840021 ] Tamas Cservenak commented on MNG-8104: -- Is this issue about m-dependency-p plugin or Maven core? Like you cannot build as Maven fails to get dependencies when proxy used? > proxy settings ignored for dependencies > --- > > Key: MNG-8104 > URL: https://issues.apache.org/jira/browse/MNG-8104 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.9.6 >Reporter: Patrick Mackinlay >Priority: Major > > The proxy settings are ignored for dependencies in maven 3.9.6 (working in > 3.9.2). > On a machine with no direct internet access, if you clear your local > repository with a command like: > rm -rf ~/.m2/repository/org/apache/maven/maven-core/2.2.1 > and then try and download the dependency: > mvn dependency:get -DgroupId=org.apache.maven -DartifactId=maven-core > -Dversion=2.2.1 > > It will fail. The proxy settings are ignored. However, it should be noted > that for plugins they are used, its only for dependencies that they are > ignored. > maven version 3.9.2 works, so looks like this was introduced in 3.9.3 > probably when the dependency plugin version was upgraded. > > I used a minimal settings.xml with just one proxy entry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8104) proxy settings ignored for dependencies
Patrick Mackinlay created MNG-8104: -- Summary: proxy settings ignored for dependencies Key: MNG-8104 URL: https://issues.apache.org/jira/browse/MNG-8104 Project: Maven Issue Type: Bug Components: Core Affects Versions: 3.9.6 Reporter: Patrick Mackinlay The proxy settings are ignored for dependencies in maven 3.9.6 (working in 3.9.2). On a machine with no direct internet access, if you clear your local repository with a command like: rm -rf ~/.m2/repository/org/apache/maven/maven-core/2.2.1 and then try and download the dependency: mvn dependency:get -DgroupId=org.apache.maven -DartifactId=maven-core -Dversion=2.2.1 It will fail. The proxy settings are ignored. However, it should be noted that for plugins they are used, its only for dependencies that they are ignored. maven version 3.9.2 works, so looks like this was introduced in 3.9.3 probably when the dependency plugin version was upgraded. I used a minimal settings.xml with just one proxy entry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-515) Plugin is NOT incremental, so let it go
[ https://issues.apache.org/jira/browse/MCOMPILER-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1783#comment-1783 ] ASF GitHub Bot commented on MCOMPILER-515: -- rmannibucau commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2071704037 @desruisseaux +1 to drop plexus but also +1 to keep the current incremental feature support by default - whatever name is given if incremental is not considered accurate. > Plugin is NOT incremental, so let it go > --- > > Key: MCOMPILER-515 > URL: https://issues.apache.org/jira/browse/MCOMPILER-515 > Project: Maven Compiler Plugin > Issue Type: Bug >Reporter: Tamas Cservenak >Priority: Major > > The maven-compiler-plugin is NOT incremental, so we should just let it go. > The shared incremental stuff is broken since it's last factual code change > (2012!). > Moreover, the broken incremental stuff just makes us look bad, see the "mvn > clean install" vs "mvn verify" issue: > [https://www.youtube.com/watch?v=XeQj-IbSxJI] > Accept it, that this plugins is not incremental, so it should not make users > believe it is. Moreover, the bugs in this feature exist for too long, that > just cause harm to users and to project as whole. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-515) Plugin is NOT incremental, so let it go
[ https://issues.apache.org/jira/browse/MCOMPILER-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839995#comment-17839995 ] ASF GitHub Bot commented on MCOMPILER-515: -- desruisseaux commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2071683447 > remove plexus-compiler layer but what about other compilers? `javax.tools.JavaCompiler` is an interface. From a quick search on internet, I think (but did not verified closely) that the Eclipse compiler implements this interface. If there is still a need for the Plexus compiler, we can write a wrapper. The `javax.tools` API is preferred to the Plexus API because it has some JPMS specific methods that I didn't saw in Plexus API. It also has a method telling us whether an option is valid, and a caching mechanism. For languages other than Java, we would need a separated plugin. With JPMS support, multi-releases support, incremental build (even incomplete), etc., this plugin is very Java-specific. > Plugin is NOT incremental, so let it go > --- > > Key: MCOMPILER-515 > URL: https://issues.apache.org/jira/browse/MCOMPILER-515 > Project: Maven Compiler Plugin > Issue Type: Bug >Reporter: Tamas Cservenak >Priority: Major > > The maven-compiler-plugin is NOT incremental, so we should just let it go. > The shared incremental stuff is broken since it's last factual code change > (2012!). > Moreover, the broken incremental stuff just makes us look bad, see the "mvn > clean install" vs "mvn verify" issue: > [https://www.youtube.com/watch?v=XeQj-IbSxJI] > Accept it, that this plugins is not incremental, so it should not make users > believe it is. Moreover, the bugs in this feature exist for too long, that > just cause harm to users and to project as whole. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MARTIFACT-64) add diagnose and hints for Git commit timestamp support
[ https://issues.apache.org/jira/browse/MARTIFACT-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MARTIFACT-64. -- Assignee: Herve Boutemy Resolution: Fixed > add diagnose and hints for Git commit timestamp support > --- > > Key: MARTIFACT-64 > URL: https://issues.apache.org/jira/browse/MARTIFACT-64 > Project: Maven Artifact Plugin > Issue Type: Improvement >Affects Versions: 3.5.1 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Labels: pull-request-available > Fix For: 3.5.2 > > > some issues with Git commit timestamp support has been reported: need to > investigate root cause and provide help -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MARTIFACT-64) add diagnose and hints for Git commit timestamp support
[ https://issues.apache.org/jira/browse/MARTIFACT-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839961#comment-17839961 ] ASF GitHub Bot commented on MARTIFACT-64: - hboutemy merged PR #39: URL: https://github.com/apache/maven-artifact-plugin/pull/39 > add diagnose and hints for Git commit timestamp support > --- > > Key: MARTIFACT-64 > URL: https://issues.apache.org/jira/browse/MARTIFACT-64 > Project: Maven Artifact Plugin > Issue Type: Improvement >Affects Versions: 3.5.1 >Reporter: Herve Boutemy >Priority: Major > Labels: pull-request-available > Fix For: 3.5.2 > > > some issues with Git commit timestamp support has been reported: need to > investigate root cause and provide help -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARCHETYPE-626) mvn install deploy does not work with 3.2.1 but worked with 3.2.0
[
https://issues.apache.org/jira/browse/ARCHETYPE-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed ARCHETYPE-626.
---
Assignee: Herve Boutemy
Resolution: Fixed
> mvn install deploy does not work with 3.2.1 but worked with 3.2.0
> -
>
> Key: ARCHETYPE-626
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-626
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.2.1
> Environment: * Linux machine (Kernel 3.10.0)
> * OpenJDK 11.0.13.0.8-1.el7_9.x86_64 (11.0.1)
> * Maven 3.8.4 (did also occur with 3.3.9)
>Reporter: Jan Mosig
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.3.0
>
> Attachments: archetype-plugin-failed-build.txt,
> archetype-plugin-successful-build.txt
>
>
> Hi there,
> I've got an archetype build that used to work fine with 3.2.0 but fails with
> 3.2.1.
> The problem with 3.2.1 is that all the files in
> target/test-classes/projects/it-basic/project/basic-project do exist but are
> all empty (0 bytes).
> The build is run with {{mvn -U clean install deploy}}. If I run it with {{mvn
> -U clean deploy}} it works. Although the install goal may be superfluous, I
> guess there is something wrong there with version 3.2.1.
> I attached the logs of a successful run and a failed one to this ticket.
> You may find the failing project here (Branch archetype-plugin-321-bug):
> https://github.com/itemis/fluffyj-archetype/tree/archetype-plugin-321-bug
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARCHETYPE-657) create target/archetype-it instead of target/classes/archetype-it
[
https://issues.apache.org/jira/browse/ARCHETYPE-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed ARCHETYPE-657.
---
Assignee: Herve Boutemy
Resolution: Fixed
> create target/archetype-it instead of target/classes/archetype-it
> -
>
> Key: ARCHETYPE-657
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-657
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 2.2, 3.2.1
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.3.0
>
>
> in ARCHETYPE-389, {{archetype-it}} directory has been created to store
> interpolated settings file, which is local to current build
> this directory has been created in {{target/classes/}}: should have been in
> {{target/}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARCHETYPE-657) create target/archetype-it instead of target/classes/archetype-it
[
https://issues.apache.org/jira/browse/ARCHETYPE-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839960#comment-17839960
]
ASF GitHub Bot commented on ARCHETYPE-657:
--
hboutemy merged PR #188:
URL: https://github.com/apache/maven-archetype/pull/188
> create target/archetype-it instead of target/classes/archetype-it
> -
>
> Key: ARCHETYPE-657
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-657
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 2.2, 3.2.1
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.3.0
>
>
> in ARCHETYPE-389, {{archetype-it}} directory has been created to store
> interpolated settings file, which is local to current build
> this directory has been created in {{target/classes/}}: should have been in
> {{target/}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-336) Make SiteRenderingContext#siteDirectories editable aware
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839956#comment-17839956
]
ASF GitHub Bot commented on DOXIASITETOOLS-336:
---
michael-o commented on PR #150:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/150#issuecomment-2071492676
> According to
https://mvnrepository.com/artifact/org.apache.maven.doxia/doxia-site-renderer/usages
there is 180 downstream dependencies…
This is deceiving data because the only thing they use is
https://github.com/apache/maven-reporting-impl/blob/master/src/main/java/org/apache/maven/reporting/AbstractMavenReport.java#L283.
They will not interact with site directories or retrieve them. The
`SiteRenderingContext` does not contain any site directories.
> Make SiteRenderingContext#siteDirectories editable aware
>
>
> Key: DOXIASITETOOLS-336
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-336
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 2.0.0-M16
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0, 2.0.0-M18
>
>
> Right now you cannot qualify a {{siteDirectory}} whether the content is
> editable or generated. You need to perform multiple calls with distinct
> {{SiteRenderingContexts}}. This causes computational overhead is hacks like
> MSITE-723.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8043) Dependency properties should be provided by Resolver consumer
[ https://issues.apache.org/jira/browse/MNG-8043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839954#comment-17839954 ] ASF GitHub Bot commented on MNG-8043: - hboutemy merged PR #1463: URL: https://github.com/apache/maven/pull/1463 > Dependency properties should be provided by Resolver consumer > - > > Key: MNG-8043 > URL: https://issues.apache.org/jira/browse/MNG-8043 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0-alpha-13, 4.0.0 > > > Follow up of MRESOLVER-484 > The consumer, in this case Maven is the one who should provide Maven-specific > bits. Also, do not use deprecated stuff from Resolver. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-336) Make SiteRenderingContext#siteDirectories editable aware
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839953#comment-17839953
]
ASF GitHub Bot commented on DOXIASITETOOLS-336:
---
kwin commented on PR #150:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/150#issuecomment-2071479172
According to
https://mvnrepository.com/artifact/org.apache.maven.doxia/doxia-site-renderer/usages
there is 180 downstream dependencies…
> Make SiteRenderingContext#siteDirectories editable aware
>
>
> Key: DOXIASITETOOLS-336
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-336
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 2.0.0-M16
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0, 2.0.0-M18
>
>
> Right now you cannot qualify a {{siteDirectory}} whether the content is
> editable or generated. You need to perform multiple calls with distinct
> {{SiteRenderingContexts}}. This causes computational overhead is hacks like
> MSITE-723.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-336) Make SiteRenderingContext#siteDirectories editable aware
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839939#comment-17839939
]
ASF GitHub Bot commented on DOXIASITETOOLS-336:
---
hboutemy commented on code in PR #150:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/150#discussion_r1575656039
##
doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/SiteRenderingContext.java:
##
@@ -271,7 +290,7 @@ public void addSiteDirectory(File siteDirectory) {
*
* @return List of site directories files.
*/
-public List getSiteDirectories() {
+public List getSiteDirectories() {
Review Comment:
yes, Doxia Sitetools is only used by Maven Site plugin: binary compatibility
is not really a topic, particularly when we are working on 2.0 milestones of
Doxia Sitetools
> Make SiteRenderingContext#siteDirectories editable aware
>
>
> Key: DOXIASITETOOLS-336
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-336
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 2.0.0-M16
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0, 2.0.0-M18
>
>
> Right now you cannot qualify a {{siteDirectory}} whether the content is
> editable or generated. You need to perform multiple calls with distinct
> {{SiteRenderingContexts}}. This causes computational overhead is hacks like
> MSITE-723.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-515) Plugin is NOT incremental, so let it go
[ https://issues.apache.org/jira/browse/MCOMPILER-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839891#comment-17839891 ] ASF GitHub Bot commented on MCOMPILER-515: -- olamy commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2071121026 > > I can tell you with 100% certainty that only tracking file timestamps won't work and will be a bug farm. > > It is incomplete, but this is what the current plugin and the `javac` command line do. Implementing a better incremental build would probably be a multi-steps process. In medium term, my goal is to migrate the plugin from Maven 3 / Plexus API to Maven 4 / `javax.tools` API in order to improve JPMS support. Fixing some of the incremental build issues is a side effect of this work. The goal for now is only to preserve the existing functionalities (with bug fixes). > remove plexus-compiler layer but what about other compilers? > Plugin is NOT incremental, so let it go > --- > > Key: MCOMPILER-515 > URL: https://issues.apache.org/jira/browse/MCOMPILER-515 > Project: Maven Compiler Plugin > Issue Type: Bug >Reporter: Tamas Cservenak >Priority: Major > > The maven-compiler-plugin is NOT incremental, so we should just let it go. > The shared incremental stuff is broken since it's last factual code change > (2012!). > Moreover, the broken incremental stuff just makes us look bad, see the "mvn > clean install" vs "mvn verify" issue: > [https://www.youtube.com/watch?v=XeQj-IbSxJI] > Accept it, that this plugins is not incremental, so it should not make users > believe it is. Moreover, the bugs in this feature exist for too long, that > just cause harm to users and to project as whole. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-515) Plugin is NOT incremental, so let it go
[ https://issues.apache.org/jira/browse/MCOMPILER-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839889#comment-17839889 ] ASF GitHub Bot commented on MCOMPILER-515: -- hunterpayne commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2071110405 I agree it is a lot of work. But you can't say this implementation will work either. It will be a bug farm. Inner classes, enums, and interface inheritance will all probably have weird and unexpected issues in more complex cases. And if there are classes compiled by other plugins like scalac? That's why bugs like this exist, because the mapping between java files and class files isn't clean. > Plugin is NOT incremental, so let it go > --- > > Key: MCOMPILER-515 > URL: https://issues.apache.org/jira/browse/MCOMPILER-515 > Project: Maven Compiler Plugin > Issue Type: Bug >Reporter: Tamas Cservenak >Priority: Major > > The maven-compiler-plugin is NOT incremental, so we should just let it go. > The shared incremental stuff is broken since it's last factual code change > (2012!). > Moreover, the broken incremental stuff just makes us look bad, see the "mvn > clean install" vs "mvn verify" issue: > [https://www.youtube.com/watch?v=XeQj-IbSxJI] > Accept it, that this plugins is not incremental, so it should not make users > believe it is. Moreover, the bugs in this feature exist for too long, that > just cause harm to users and to project as whole. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-515) Plugin is NOT incremental, so let it go
[ https://issues.apache.org/jira/browse/MCOMPILER-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839883#comment-17839883 ] ASF GitHub Bot commented on MCOMPILER-515: -- desruisseaux commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2071095574 > I can tell you with 100% certainty that only tracking file timestamps won't work and will be a bug farm. It is incomplete, but this is what the current plugin and the `javac` command line do. Implementing a better incremental build would probably be a multi-steps process. In medium term, my goal is to migrate the plugin from Maven 3 / Plexus API to Maven 4 / `javax.tools` API in order to improve JPMS support. Fixing some of the incremental build issues is a side effect of this work. The goal for now is only to preserve the existing functionalities (with bug fixes). After a refactored compiler plugin become stable enough, it would be possible to investigate how to do better. The proposal to use comma-separated values in `incrementalCompilation` parameters leaves room for that. > Plugin is NOT incremental, so let it go > --- > > Key: MCOMPILER-515 > URL: https://issues.apache.org/jira/browse/MCOMPILER-515 > Project: Maven Compiler Plugin > Issue Type: Bug >Reporter: Tamas Cservenak >Priority: Major > > The maven-compiler-plugin is NOT incremental, so we should just let it go. > The shared incremental stuff is broken since it's last factual code change > (2012!). > Moreover, the broken incremental stuff just makes us look bad, see the "mvn > clean install" vs "mvn verify" issue: > [https://www.youtube.com/watch?v=XeQj-IbSxJI] > Accept it, that this plugins is not incremental, so it should not make users > believe it is. Moreover, the bugs in this feature exist for too long, that > just cause harm to users and to project as whole. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MDEP-925) Require Maven 3.6.3
[ https://issues.apache.org/jira/browse/MDEP-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839868#comment-17839868 ] ASF GitHub Bot commented on MDEP-925: - slawekjaranowski opened a new pull request, #381: URL: https://github.com/apache/maven-dependency-plugin/pull/381 https://issues.apache.org/jira/browse/MDEP-925 > Require Maven 3.6.3 > --- > > Key: MDEP-925 > URL: https://issues.apache.org/jira/browse/MDEP-925 > Project: Maven Dependency Plugin > Issue Type: Improvement >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.7.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MDEP-925) Require Maven 3.6.3
Slawomir Jaranowski created MDEP-925: Summary: Require Maven 3.6.3 Key: MDEP-925 URL: https://issues.apache.org/jira/browse/MDEP-925 Project: Maven Dependency Plugin Issue Type: Improvement Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: 3.7.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-515) Plugin is NOT incremental, so let it go
[ https://issues.apache.org/jira/browse/MCOMPILER-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839855#comment-17839855 ] ASF GitHub Bot commented on MCOMPILER-515: -- hunterpayne commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2070978534 I can tell you with 100% certainty that only tracking file timestamps won't work and will be a bug farm. You must know which .class files are generated from which .java files and in addition know which .class files depend upon which other .class files. If this isn't possible, then it isn't possible to implement this feature in a maintainable way. So either we need to track this additional information, or relax the requirement to so, module level or package level and track dependencies at that level. I am OK with either path but we shouldn't go ahead with only tracking file timestamps and acting like that is a working incremental build feature. On Monday, April 22, 2024 at 02:17:06 PM PDT, Martin Desruisseaux ***@***.***> wrote: While incremental builds is important, my reading of the source code inherited from Maven 3 suggests that in its current state, incremental build has bugs causing the opposite effect than what the plugin wanted to achieve. We could try to fix the Maven 3 compiler plugin, but I do not know if it is worth the effort given that the plugin is getting a significant rewrite for Maven 4. The current useIncrementalCompilation parameter is a boolean flag which is actually mixing at least two aspects: whether to check if a dependency changed, and how to detect which source files changed. I suggest to deprecate that parameter and replace it with a new incrementalCompilation parameter (same name but without use prefix). The value of that parameter would be a comma-separated list of the following: - dependencies: check whether a dependency changed. - sources: check whether a source file has been updated, or whether source files were added or removed. - classes: check whether a source file is more recent than its .class file. - modules (new): don't try to do incremental build in Maven, but delegate that task to javac instead. This is possible only with modular projects. It uses the --module compiler option, which is an alternative to enumerating all source files on the command-line. Equivalences with the current parameter: - useIncrementalCompilation = true is equivalent to incrementalCompilation = dependencies,sources (except maybe for the cases of newly added source files). - useIncrementalCompilation = false is equivalent to incrementalCompilation = classes. For an initial version of the Maven 4 compiler plugin, detection of changes would be based only on file timestamps. This is the same strategy than the current plugin. This approach would be unable to detect that a class needs to be recompiled because it depends on another class which has been changed. However, the current plugin cannot detect such cases neither, so we don't lost anything. If we support that feature in the future, it would be one new value in the above-cited list of comma-separated values. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***> > Plugin is NOT incremental, so let it go > --- > > Key: MCOMPILER-515 > URL: https://issues.apache.org/jira/browse/MCOMPILER-515 > Project: Maven Compiler Plugin > Issue Type: Bug >Reporter: Tamas Cservenak >Priority: Major > > The maven-compiler-plugin is NOT incremental, so we should just let it go. > The shared incremental stuff is broken since it's last factual code change > (2012!). > Moreover, the broken incremental stuff just makes us look bad, see the "mvn > clean install" vs "mvn verify" issue: > [https://www.youtube.com/watch?v=XeQj-IbSxJI] > Accept it, that this plugins is not incremental, so it should not make users > believe it is. Moreover, the bugs in this feature exist for too long, that > just cause harm to users and to project as whole. -- This message was sent by Atlassian Jira (v8.20.10#820010)
