[jira] [Created] (MRELEASE-1150) mvn release:perform should also invoke git lfs checkout after cloning the repo
zosrothko created MRELEASE-1150: --- Summary: mvn release:perform should also invoke git lfs checkout after cloning the repo Key: MRELEASE-1150 URL: https://issues.apache.org/jira/browse/MRELEASE-1150 Project: Maven Release Plugin Issue Type: Improvement Components: perform Affects Versions: 3.1.0 Environment: Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) Maven home: C:\ASF\apache-maven-3.8.4 Java version: 1.8.0_181, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk1.8.0_181\jre Default locale: fr_FR, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" Reporter: zosrothko Hello While the maven-release-plugin:perform is cloning a git repository in the 'checkout' subdirectory, it does not run the command 'git lfs checkout' to upate all lfs files with their real content which produces build failures Please add a option to run 'git lfs checkout' as needed for maven-release-plugin:perform -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRELEASE-1150) mvn release:perform should also invoke git lfs checkout after cloning the repo
[
https://issues.apache.org/jira/browse/MRELEASE-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
zosrothko updated MRELEASE-1150:
Description:
Hello
While the maven-release-plugin:perform is cloning a git repository in the
'target/checkout' subdirectory, it does not run the command 'git lfs checkout'
to upate all lfs files with their real content which produces build failures
like below
{{[ERROR] Failed to execute goal
org.codehaus.izpack:izpack-maven-plugin:5.2.1:izpack (default) on project
installer-izpack: Failure during compilation process: No compression or
archiving format detected for file
...\izpack\target\.\wildfly\wildfly-22.0.0.Final.zip marked to be unpacked
while processing ./wildfly/wildfly-22.0.0.Final.zip -> [Help 1]}}
Without the 'git lfs checkout' command, the content of the above zip file is
{{version https://git-lfs.github.com/spec/v1}}
{{oid sha256:9ac7490e2624a1bd73af89c6db25900031bdb6c673f2acd375f7e8c102a0d0d7}}
{{size 203150891}}
{{which is not a zip file.}}
Please add a option to run 'git lfs checkout' as needed for
maven-release-plugin:perform
was:
Hello
While the maven-release-plugin:perform is cloning a git repository in the
'checkout' subdirectory, it does not run the command 'git lfs checkout' to
upate all lfs files with their real content which produces build failures
Please add a option to run 'git lfs checkout' as needed for
maven-release-plugin:perform
> mvn release:perform should also invoke git lfs checkout after cloning the repo
> --
>
> Key: MRELEASE-1150
> URL: https://issues.apache.org/jira/browse/MRELEASE-1150
> Project: Maven Release Plugin
> Issue Type: Improvement
> Components: perform
>Affects Versions: 3.1.0
> Environment: Apache Maven 3.8.4
> (9b656c72d54e5bacbed989b64718c159fe39b537)
> Maven home: C:\ASF\apache-maven-3.8.4
> Java version: 1.8.0_181, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk1.8.0_181\jre
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: zosrothko
>Priority: Major
>
> Hello
> While the maven-release-plugin:perform is cloning a git repository in the
> 'target/checkout' subdirectory, it does not run the command 'git lfs
> checkout' to upate all lfs files with their real content which produces build
> failures like below
> {{[ERROR] Failed to execute goal
> org.codehaus.izpack:izpack-maven-plugin:5.2.1:izpack (default) on project
> installer-izpack: Failure during compilation process: No compression or
> archiving format detected for file
> ...\izpack\target\.\wildfly\wildfly-22.0.0.Final.zip marked to be unpacked
> while processing ./wildfly/wildfly-22.0.0.Final.zip -> [Help 1]}}
> Without the 'git lfs checkout' command, the content of the above zip file is
> {{version https://git-lfs.github.com/spec/v1}}
> {{oid
> sha256:9ac7490e2624a1bd73af89c6db25900031bdb6c673f2acd375f7e8c102a0d0d7}}
> {{size 203150891}}
> {{which is not a zip file.}}
>
> Please add a option to run 'git lfs checkout' as needed for
> maven-release-plugin:perform
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MSITE-1011) plugin broken when run with Maven 4
Herve Boutemy created MSITE-1011: Summary: plugin broken when run with Maven 4 Key: MSITE-1011 URL: https://issues.apache.org/jira/browse/MSITE-1011 Project: Maven Site Plugin Issue Type: Bug Affects Versions: 3.12.1 Reporter: Herve Boutemy seen at large scale when doing 4.0.0-beta-1 plugins releases: https://lists.apache.org/thread/ffc9rt57z6klk57v2k6xf06qmjmp37og -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MARTIFACT-67) build pom *-build.pom not checked when run with Maven 4
Herve Boutemy created MARTIFACT-67: -- Summary: build pom *-build.pom not checked when run with Maven 4 Key: MARTIFACT-67 URL: https://issues.apache.org/jira/browse/MARTIFACT-67 Project: Maven Artifact Plugin Issue Type: Bug Components: artifact:buildinfo, artifact:compare Affects Versions: 3.5.1 Reporter: Herve Boutemy found when doing 4.0.0-beta-1 plugins releases: https://lists.apache.org/thread/ffc9rt57z6klk57v2k6xf06qmjmp37og -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSOURCES-149) Switch to Maven 4 and the new api
[ https://issues.apache.org/jira/browse/MSOURCES-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MSOURCES-149: --- Description: https://github.com/apache/maven-source-plugin/commit/0853c4551866fb3183935f45ec8740fbac9ea6fc > Switch to Maven 4 and the new api > - > > Key: MSOURCES-149 > URL: https://issues.apache.org/jira/browse/MSOURCES-149 > Project: Maven Source Plugin > Issue Type: New Feature >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-1 > > > https://github.com/apache/maven-source-plugin/commit/0853c4551866fb3183935f45ec8740fbac9ea6fc -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHARED-1415) Switch to the Maven 4 API
[ https://issues.apache.org/jira/browse/MSHARED-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MSHARED-1415: --- Description: https://github.com/apache/maven-archiver/commit/07cc98665e8b859fd14c782eeb1921236a0ff9e8 > Switch to the Maven 4 API > - > > Key: MSHARED-1415 > URL: https://issues.apache.org/jira/browse/MSHARED-1415 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-archiver >Reporter: Guillaume Nodet >Priority: Major > > https://github.com/apache/maven-archiver/commit/07cc98665e8b859fd14c782eeb1921236a0ff9e8 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSITE-1010) site-deployment for POM projects does not create project directories in site repository
[
https://issues.apache.org/jira/browse/MSITE-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17861002#comment-17861002
]
Matthias Bünger commented on MSITE-1010:
Thanks, they were also helpfull and I think I got it now.
With this knowledge the docs on the [Building multi-module
sites|https://maven.apache.org/plugins/maven-site-plugin/examples/multimodule.html]
become kinda clear(er), I still see some pitfalls there in terms of the
inheritance together with a META-POM that you have to be aware that "the
topmost project" is not your parent POM of the multi-module project (what I
think about when I read about multi-module projects), but the META-POM as the
parent of the parent POM. I mean yes one of the "notes" listed there tells
about the inheritances, but I have not put it in the right context (esp. as the
"site" {{}} works different as the release/snapshot one.
What do you think? Shall I add a short documentation page about the inheritance
of the site distribution together with using a META-POM? The [siteDistribution
POM reference page|https://maven.apache.org/pom.html#Site_Distribution] doens't
make this difference clear too (in my opinion). But I totally understand when
you think it's clear enough and close the issue.
> site-deployment for POM projects does not create project directories in site
> repository
> ---
>
> Key: MSITE-1010
> URL: https://issues.apache.org/jira/browse/MSITE-1010
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.12.0, 4.0.0-M14
> Environment: Nexus, since at least Maven 3.6.3 (not tested with 3.9.7
> or 4.0.0-beta)
>Reporter: Matthias Bünger
>Priority: Minor
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: pom.xml, webdav.txt
>
>
> I noticed the following issue while updating the plugins in our teams
> META-POM and could backtrack it at least until 3.12 but might be an even
> older issue. Havn't checked 4.0.0-M15 but from the releases notes I doubt it
> is fixed.
> When you do "site-deploy" for a single module or multi module project the
> site files (.html, css-folders, etc.) are stored in the site-repository (we
> have current Nexus version) within a subfolder with the name of the project,
> e.g
> {code}
> / (root of site-repository)
> /- project-A
>/css
>report.html
> /- project-B
>/css
>report.html
> /project-C
> {code}
> If you do the same for a "POM" project (e.g. a META-POM or BOM) the site
> files are all stored at root level (instead of creating a project folder) and
> ofc overwriting the ones from other POM-projects:
> {code}
> / (root of site-repository)
> /css
> /project-A
> /project-B
> /project-C
> report.html
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7921) Allow plugins to control classpath extensions
[ https://issues.apache.org/jira/browse/MNG-7921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17861004#comment-17861004 ] Ozgun OZ commented on MNG-7921: --- just to give a bit more context on the problem we face: We are developing an [extension/library|https://github.com/HomeOfTheWizard/spring-bridge-maven-extension] that will allow the usage of spring libraries in maven plugins. This can be done by defining a custom Guice module so that the objects managed by the spring container be injected into SISU. *But* the definition of the custom Guice module currently requires exposing the Guice API from maven core to the external world (using the META-INF/maven/extension.xml) And this can only be done with a core extension. # if we put the custom module in the same extension that exports the Guice API, the custom module will be run in the beginning of the maven lifecycle (in the initialization of the Core class-world because its a core extension) where there is no plugin information yet. This module will also be exposed to all plugin class-worlds that will inherit from this core class-world. This can cause issues to plugins that does not require the custom module. # If we put the custom module as a dependency to a plugin that requires it only, and the the META-INF/maven/extension.xml file in a separate core extension, the module will exist only in the chosen plugin class-world. But this has the disadvantage of asking all applications using such plugins that use custom Guice modules to define and activate the extension that contains the META-INF/maven/extension.xml file. I see two solutions: # Exposing the Guice API by default. But this must be extensively tested to be sure we do not break something existing. # As David suggests, allowing plugins to define extensions for their own class-world only, or define their own exported APIs from the Core class-loader (probably requires creating a specific API class-loader). > Allow plugins to control classpath extensions > - > > Key: MNG-7921 > URL: https://issues.apache.org/jira/browse/MNG-7921 > Project: Maven > Issue Type: Improvement > Components: Class Loading, Core >Affects Versions: 3.9.5 >Reporter: Dave Syer >Priority: Major > > It's great that a plugin (or extension jar) can have `` > (specifically I want to use Google Guice in a plugin and this seems to be the > only way), but it can only be applied globally AFAIK, so all plugins get the > same exported packages and there might consequently be conflicts. It would be > nice if a plugin that declared it was an extension could elect to specify > exported packages independent of other plugins. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRELEASE-1150) mvn release:perform should also invoke git lfs checkout after cloning the repo
[
https://issues.apache.org/jira/browse/MRELEASE-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17861019#comment-17861019
]
Michael Osipov commented on MRELEASE-1150:
--
This is similiar to git submodules, there is not proper support. PRs welcome.
> mvn release:perform should also invoke git lfs checkout after cloning the repo
> --
>
> Key: MRELEASE-1150
> URL: https://issues.apache.org/jira/browse/MRELEASE-1150
> Project: Maven Release Plugin
> Issue Type: Improvement
> Components: perform
>Affects Versions: 3.1.0
> Environment: Apache Maven 3.8.4
> (9b656c72d54e5bacbed989b64718c159fe39b537)
> Maven home: C:\ASF\apache-maven-3.8.4
> Java version: 1.8.0_181, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk1.8.0_181\jre
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: zosrothko
>Priority: Major
>
> Hello
> While the maven-release-plugin:perform is cloning a git repository in the
> 'target/checkout' subdirectory, it does not run the command 'git lfs
> checkout' to upate all lfs files with their real content which produces build
> failures like below
> {{[ERROR] Failed to execute goal
> org.codehaus.izpack:izpack-maven-plugin:5.2.1:izpack (default) on project
> installer-izpack: Failure during compilation process: No compression or
> archiving format detected for file
> ...\izpack\target\.\wildfly\wildfly-22.0.0.Final.zip marked to be unpacked
> while processing ./wildfly/wildfly-22.0.0.Final.zip -> [Help 1]}}
> Without the 'git lfs checkout' command, the content of the above zip file is
> {{version https://git-lfs.github.com/spec/v1}}
> {{oid
> sha256:9ac7490e2624a1bd73af89c6db25900031bdb6c673f2acd375f7e8c102a0d0d7}}
> {{size 203150891}}
> {{which is not a zip file.}}
>
> Please add a option to run 'git lfs checkout' as needed for
> maven-release-plugin:perform
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8168) Core release 3.9.8 has impact to the invoker plugin.
Ozgun OZ created MNG-8168:
-
Summary: Core release 3.9.8 has impact to the invoker plugin.
Key: MNG-8168
URL: https://issues.apache.org/jira/browse/MNG-8168
Project: Maven
Issue Type: Bug
Components: Core
Affects Versions: 3.9.8
Reporter: Ozgun OZ
The integration tests of my
[extension|https://github.com/HomeOfTheWizard/spring-bridge-maven-extension] do
not work if I upgrade the maven-core dependency from 3.9.7 to 3.9.8.
The release seems to have an impact on the invoker plugin.
It does not see the extensions.xml in the .mvn directory of my IT tests.
When I run the project in the IT folder myself, all works good, but when run
with the invoker:run, the extension is not picked up.
{*}Might help{*}: the extension uses a custom Guice module and according to the
release note, 3.9.8 includes a new release of
[SISU|https://maven.apache.org/docs/3.9.8/release-notes.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8168) Core release 3.9.8 has impact to the invoker plugin.
[
https://issues.apache.org/jira/browse/MNG-8168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17861021#comment-17861021
]
Michael Osipov commented on MNG-8168:
-
[~cstamas]
> Core release 3.9.8 has impact to the invoker plugin.
>
>
> Key: MNG-8168
> URL: https://issues.apache.org/jira/browse/MNG-8168
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.8
>Reporter: Ozgun OZ
>Priority: Major
>
> The integration tests of my
> [extension|https://github.com/HomeOfTheWizard/spring-bridge-maven-extension]
> do not work if I upgrade the maven-core dependency from 3.9.7 to 3.9.8.
> The release seems to have an impact on the invoker plugin.
> It does not see the extensions.xml in the .mvn directory of my IT tests.
> When I run the project in the IT folder myself, all works good, but when run
> with the invoker:run, the extension is not picked up.
> {*}Might help{*}: the extension uses a custom Guice module and according to
> the release note, 3.9.8 includes a new release of
> [SISU|https://maven.apache.org/docs/3.9.8/release-notes.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNGSITE-531) Maven Plugins Compatibility Plan incorrect about Context
[ https://issues.apache.org/jira/browse/MNGSITE-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNGSITE-531. -- Resolution: Fixed Fixed with [f1a3ab862e88c34bc125a46075c1e694c4d85bf8|https://gitbox.apache.org/repos/asf?p=maven-site.git&a=commit&h=f1a3ab862e88c34bc125a46075c1e694c4d85bf8]. > Maven Plugins Compatibility Plan incorrect about Context > > > Key: MNGSITE-531 > URL: https://issues.apache.org/jira/browse/MNGSITE-531 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > > https://maven.apache.org/developers/compatibility-plan.html#context talks > about maintenance of OpenJDK, but those dates are wrong for OpenJDK 8 and > newer: > One example is Temurin: https://adoptium.net/de/support/ or Zulu is even > longer: https://endoflife.date/azul-zulu -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8168) Core release 3.9.8 has impact to the invoker plugin.
[
https://issues.apache.org/jira/browse/MNG-8168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17861025#comment-17861025
]
Ozgun OZ commented on MNG-8168:
---
upgrading the invoker plugin from 3.6.1 to 3.7.0 does the same effect (without
upgrading maven-core dependencies, or even with it)
> Core release 3.9.8 has impact to the invoker plugin.
>
>
> Key: MNG-8168
> URL: https://issues.apache.org/jira/browse/MNG-8168
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.8
>Reporter: Ozgun OZ
>Priority: Major
>
> The integration tests of my
> [extension|https://github.com/HomeOfTheWizard/spring-bridge-maven-extension]
> do not work if I upgrade the maven-core dependency from 3.9.7 to 3.9.8.
> The release seems to have an impact on the invoker plugin.
> It does not see the extensions.xml in the .mvn directory of my IT tests.
> When I run the project in the IT folder myself, all works good, but when run
> with the invoker:run, the extension is not picked up.
> {*}Might help{*}: the extension uses a custom Guice module and according to
> the release note, 3.9.8 includes a new release of
> [SISU|https://maven.apache.org/docs/3.9.8/release-notes.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7921) Allow plugins to control classpath extensions
[ https://issues.apache.org/jira/browse/MNG-7921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ozgun OZ updated MNG-7921: -- Attachment: maven-classWorlds.drawio.png > Allow plugins to control classpath extensions > - > > Key: MNG-7921 > URL: https://issues.apache.org/jira/browse/MNG-7921 > Project: Maven > Issue Type: Improvement > Components: Class Loading, Core >Affects Versions: 3.9.5 >Reporter: Dave Syer >Priority: Major > Attachments: maven-classWorlds.drawio.png > > > It's great that a plugin (or extension jar) can have `` > (specifically I want to use Google Guice in a plugin and this seems to be the > only way), but it can only be applied globally AFAIK, so all plugins get the > same exported packages and there might consequently be conflicts. It would be > nice if a plugin that declared it was an extension could elect to specify > exported packages independent of other plugins. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7921) Allow plugins to control classpath extensions
[ https://issues.apache.org/jira/browse/MNG-7921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17861028#comment-17861028 ] Ozgun OZ commented on MNG-7921: --- A core extension is by definition something that we would like it to impact all plugins, or at least more than one. So IMHO allowing plugins to define their own extensions is not the way to go. We can maybe consider the other way around. Giving extensions the ability to target specific plugins. Via configurations maybe like defined in [MNG-5897|https://issues.apache.org/jira/browse/MNG-5897] Or just specify a new config file for plugins to allow their classloader be created by exporting specific apis from the core class-loader. Smth like the below > Allow plugins to control classpath extensions > - > > Key: MNG-7921 > URL: https://issues.apache.org/jira/browse/MNG-7921 > Project: Maven > Issue Type: Improvement > Components: Class Loading, Core >Affects Versions: 3.9.5 >Reporter: Dave Syer >Priority: Major > Attachments: maven-classWorlds.drawio.png > > > It's great that a plugin (or extension jar) can have `` > (specifically I want to use Google Guice in a plugin and this seems to be the > only way), but it can only be applied globally AFAIK, so all plugins get the > same exported packages and there might consequently be conflicts. It would be > nice if a plugin that declared it was an extension could elect to specify > exported packages independent of other plugins. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7921) Allow plugins to control classpath extensions
[ https://issues.apache.org/jira/browse/MNG-7921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ozgun OZ updated MNG-7921: -- Attachment: (was: maven-classWorlds.drawio.png) > Allow plugins to control classpath extensions > - > > Key: MNG-7921 > URL: https://issues.apache.org/jira/browse/MNG-7921 > Project: Maven > Issue Type: Improvement > Components: Class Loading, Core >Affects Versions: 3.9.5 >Reporter: Dave Syer >Priority: Major > Attachments: image-2024-06-30-19-37-28-275.png > > > It's great that a plugin (or extension jar) can have `` > (specifically I want to use Google Guice in a plugin and this seems to be the > only way), but it can only be applied globally AFAIK, so all plugins get the > same exported packages and there might consequently be conflicts. It would be > nice if a plugin that declared it was an extension could elect to specify > exported packages independent of other plugins. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MNG-7921) Allow plugins to control classpath extensions
[ https://issues.apache.org/jira/browse/MNG-7921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17861028#comment-17861028 ] Ozgun OZ edited comment on MNG-7921 at 6/30/24 5:37 PM: A core extension is by definition something that we would like it to impact all plugins, or at least more than one. So IMHO allowing plugins to define their own extensions is not the way to go. We can maybe consider the other way around. Giving extensions the ability to target specific plugins. Via configurations maybe like defined in MNG-5897 Or just specify a new config file for plugins to allow their classloader be created by exporting specific apis from the core class-loader. Smth like the below !image-2024-06-30-19-37-28-275.png! was (Author: ozgun): A core extension is by definition something that we would like it to impact all plugins, or at least more than one. So IMHO allowing plugins to define their own extensions is not the way to go. We can maybe consider the other way around. Giving extensions the ability to target specific plugins. Via configurations maybe like defined in [MNG-5897|https://issues.apache.org/jira/browse/MNG-5897] Or just specify a new config file for plugins to allow their classloader be created by exporting specific apis from the core class-loader. Smth like the below > Allow plugins to control classpath extensions > - > > Key: MNG-7921 > URL: https://issues.apache.org/jira/browse/MNG-7921 > Project: Maven > Issue Type: Improvement > Components: Class Loading, Core >Affects Versions: 3.9.5 >Reporter: Dave Syer >Priority: Major > Attachments: image-2024-06-30-19-37-28-275.png, > maven-classWorlds.drawio.png > > > It's great that a plugin (or extension jar) can have `` > (specifically I want to use Google Guice in a plugin and this seems to be the > only way), but it can only be applied globally AFAIK, so all plugins get the > same exported packages and there might consequently be conflicts. It would be > nice if a plugin that declared it was an extension could elect to specify > exported packages independent of other plugins. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSITE-1010) site-deployment for POM projects does not create project directories in site repository
[
https://issues.apache.org/jira/browse/MSITE-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MSITE-1010.
-
Fix Version/s: (was: waiting-for-feedback)
(was: wontfix-candidate)
Resolution: Information Provided
If you think your docs aren't good enough -- which they obviously aren't -- I'd
be happy to merge a PR.
> site-deployment for POM projects does not create project directories in site
> repository
> ---
>
> Key: MSITE-1010
> URL: https://issues.apache.org/jira/browse/MSITE-1010
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.12.0, 4.0.0-M14
> Environment: Nexus, since at least Maven 3.6.3 (not tested with 3.9.7
> or 4.0.0-beta)
>Reporter: Matthias Bünger
>Priority: Minor
> Attachments: pom.xml, webdav.txt
>
>
> I noticed the following issue while updating the plugins in our teams
> META-POM and could backtrack it at least until 3.12 but might be an even
> older issue. Havn't checked 4.0.0-M15 but from the releases notes I doubt it
> is fixed.
> When you do "site-deploy" for a single module or multi module project the
> site files (.html, css-folders, etc.) are stored in the site-repository (we
> have current Nexus version) within a subfolder with the name of the project,
> e.g
> {code}
> / (root of site-repository)
> /- project-A
>/css
>report.html
> /- project-B
>/css
>report.html
> /project-C
> {code}
> If you do the same for a "POM" project (e.g. a META-POM or BOM) the site
> files are all stored at root level (instead of creating a project folder) and
> ofc overwriting the ones from other POM-projects:
> {code}
> / (root of site-repository)
> /css
> /project-A
> /project-B
> /project-C
> report.html
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MJAVADOC-799) `defaultVersion` parameter has incorrect default value
Marcono1234 created MJAVADOC-799:
Summary: `defaultVersion` parameter has incorrect default value
Key: MJAVADOC-799
URL: https://issues.apache.org/jira/browse/MJAVADOC-799
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: fix
Affects Versions: 3.7.0
Reporter: Marcono1234
The {{defaultVersion}} parameter of the {{javadoc:fix}} has an inconsistent /
incorrect default value (though I am not sure what the 'correct' value would
be).
h3. Inconsistencies
- The Javadoc says "By default, it is {{$Id:$}}"
- The actual and documented (on the Mojo help) default is {{$Id: $Id}}
- The field in the code has the initial value {{$Id: $}}, with a space (using
Unicode escapes)
This value seems to have no effect because {{@Parameter#defaultValue}}
overwrites the initial field value.
Maybe it would therefore be easiest to:
- Remove the "By default, it is ..." sentence from the Javadoc
- Remove the initial field value
- Optionally remove the {{DEFAULT_VERSION_VALUE}} field and directly inline the
value
- Optionally change the default to the intended default value (whatever that is)
h3. Historical background
It seems originally the default value was supposed to be {{$Id$}}, but that was
apparently causing issues with SVN, so commit
[0cecfaa|https://github.com/apache/maven-javadoc-plugin/commit/0cecfaac31113f44c7db4c29021fa6f92877e458]
tried to fix this by using the field initializer and Unicode escapes instead
of {{default-value=}}. But this caused the first inconsistency because the
Javadoc said {{$Id:$}} (without space) but the value was {{$Id: $}} (with
space).
Later commit
[3dcd209|https://github.com/apache/maven-javadoc-plugin/commit/3dcd209a1595a95effd824be5a080f1d19f6f37e#diff-987d1364c087fc6899bde7ad2cdeba3e3c883d3c26e9ffbe86ecdce23d7ee1faR204]
refactored the code to use {{@Parameter}} and added a {{defaultValue}}, but
that is {{$Id: $Id}} (with duplicate "Id").
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-799) `defaultVersion` parameter has incorrect default value
[
https://issues.apache.org/jira/browse/MJAVADOC-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcono1234 updated MJAVADOC-799:
-
Description:
The {{defaultVersion}} parameter of the {{javadoc:fix}} has an inconsistent /
incorrect default value (though I am not sure what the 'correct' value would
be).
h3. Inconsistencies
- The Javadoc says "By default, it is {{$Id:$}}"
- The actual and documented (on the Mojo help) default is {{$Id: $Id}}
- The field in the code has the initial value {{$Id: $}}, with a space (using
Unicode escapes)
This value seems to have no effect because {{@Parameter#defaultValue}}
overwrites the initial field value.
Maybe it would therefore be easiest to:
- Remove the "By default, it is ..." sentence from the Javadoc
It is redundant because the Mojo help documents the {{@Parameter#defaultValue}}.
- Remove the initial field value
- Optionally remove the {{DEFAULT_VERSION_VALUE}} field and directly inline the
value
- Optionally change the default to the intended default value (whatever that is)
h3. Historical background
It seems originally the default value was supposed to be {{$Id$}}, but that was
apparently causing issues with SVN, so commit
[0cecfaa|https://github.com/apache/maven-javadoc-plugin/commit/0cecfaac31113f44c7db4c29021fa6f92877e458]
tried to fix this by using the field initializer and Unicode escapes instead
of {{default-value=}}. But this caused the first inconsistency because the
Javadoc said {{$Id:$}} (without space) but the value was {{$Id: $}} (with
space).
Later commit
[3dcd209|https://github.com/apache/maven-javadoc-plugin/commit/3dcd209a1595a95effd824be5a080f1d19f6f37e#diff-987d1364c087fc6899bde7ad2cdeba3e3c883d3c26e9ffbe86ecdce23d7ee1faR204]
refactored the code to use {{@Parameter}} and added a {{defaultValue}}, but
that is {{$Id: $Id}} (with duplicate "Id").
was:
The {{defaultVersion}} parameter of the {{javadoc:fix}} has an inconsistent /
incorrect default value (though I am not sure what the 'correct' value would
be).
h3. Inconsistencies
- The Javadoc says "By default, it is {{$Id:$}}"
- The actual and documented (on the Mojo help) default is {{$Id: $Id}}
- The field in the code has the initial value {{$Id: $}}, with a space (using
Unicode escapes)
This value seems to have no effect because {{@Parameter#defaultValue}}
overwrites the initial field value.
Maybe it would therefore be easiest to:
- Remove the "By default, it is ..." sentence from the Javadoc
- Remove the initial field value
- Optionally remove the {{DEFAULT_VERSION_VALUE}} field and directly inline the
value
- Optionally change the default to the intended default value (whatever that is)
h3. Historical background
It seems originally the default value was supposed to be {{$Id$}}, but that was
apparently causing issues with SVN, so commit
[0cecfaa|https://github.com/apache/maven-javadoc-plugin/commit/0cecfaac31113f44c7db4c29021fa6f92877e458]
tried to fix this by using the field initializer and Unicode escapes instead
of {{default-value=}}. But this caused the first inconsistency because the
Javadoc said {{$Id:$}} (without space) but the value was {{$Id: $}} (with
space).
Later commit
[3dcd209|https://github.com/apache/maven-javadoc-plugin/commit/3dcd209a1595a95effd824be5a080f1d19f6f37e#diff-987d1364c087fc6899bde7ad2cdeba3e3c883d3c26e9ffbe86ecdce23d7ee1faR204]
refactored the code to use {{@Parameter}} and added a {{defaultValue}}, but
that is {{$Id: $Id}} (with duplicate "Id").
> `defaultVersion` parameter has incorrect default value
> --
>
> Key: MJAVADOC-799
> URL: https://issues.apache.org/jira/browse/MJAVADOC-799
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: fix
>Affects Versions: 3.7.0
>Reporter: Marcono1234
>Priority: Trivial
>
> The {{defaultVersion}} parameter of the {{javadoc:fix}} has an inconsistent /
> incorrect default value (though I am not sure what the 'correct' value would
> be).
> h3. Inconsistencies
> - The Javadoc says "By default, it is {{$Id:$}}"
> - The actual and documented (on the Mojo help) default is {{$Id: $Id}}
> - The field in the code has the initial value {{$Id: $}}, with a space (using
> Unicode escapes)
> This value seems to have no effect because {{@Parameter#defaultValue}}
> overwrites the initial field value.
> Maybe it would therefore be easiest to:
> - Remove the "By default, it is ..." sentence from the Javadoc
> It is redundant because the Mojo help documents the
> {{@Parameter#defaultValue}}.
> - Remove the initial field value
> - Optionally remove the {{DEFAULT_VERSION_VALUE}} field and directly inline
> the value
> - Optionally change the default to the intended default value (whatever that
> is)
> h3. Historical background
> It seems originally the default value was supposed to b
[jira] [Updated] (MDEPLOY-320) Unclear exception prompt
[ https://issues.apache.org/jira/browse/MDEPLOY-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Huang Xiao updated MDEPLOY-320: --- Description: Examples of unclear source code: !image-2024-06-26-20-21-58-461.png|width=869,height=527! !image-2024-06-26-20-23-51-491.png|width=872,height=514! Short message output from the console: !image-2024-06-26-20-52-10-086.png|width=839,height=645! *Suggest:* Use clearer longMessage instead of shortMessage. h3. *Optimization:* The following is the optimized effect. 1. example 1 !image-2024-06-27-15-13-14-762.png|width=1606,height=150! expected error message *!image-2024-06-27-15-03-23-770.png|width=1690,height=256!* 2. example 2 *!image-2024-06-27-15-12-23-385.png|width=1271,height=120!* expected error message *!image-2024-06-27-15-11-37-833.png|width=1390,height=212!* *PR：[[MDEPLOY-320] Unclear exception prompt by youngledo · Pull Request #64 · apache/maven-deploy-plugin (github.com)|https://github.com/apache/maven-deploy-plugin/pull/64]* was: Examples of unclear source code: !image-2024-06-26-20-21-58-461.png|width=869,height=527! !image-2024-06-26-20-23-51-491.png|width=872,height=514! Short message output from the console: !image-2024-06-26-20-52-10-086.png|width=839,height=645! *Suggest:* Use clearer longMessage instead of shortMessage. h3. *Optimization:* The following is the optimized effect. 1. example 1 !image-2024-06-27-15-13-14-762.png|width=1606,height=150! expected error message *!image-2024-06-27-15-03-23-770.png|width=1690,height=256!* 2. example 2 *!image-2024-06-27-15-12-23-385.png|width=1271,height=120!* expected error message *!image-2024-06-27-15-11-37-833.png|width=1390,height=212!* > Unclear exception prompt > > > Key: MDEPLOY-320 > URL: https://issues.apache.org/jira/browse/MDEPLOY-320 > Project: Maven Deploy Plugin > Issue Type: Improvement > Components: deploy:deploy >Reporter: Huang Xiao >Priority: Major > Attachments: image-2024-06-26-20-21-58-461.png, > image-2024-06-26-20-23-51-491.png, image-2024-06-26-20-52-10-086.png, > image-2024-06-27-14-48-46-433.png, image-2024-06-27-15-03-23-770.png, > image-2024-06-27-15-05-19-091.png, image-2024-06-27-15-11-37-833.png, > image-2024-06-27-15-12-23-385.png, image-2024-06-27-15-13-14-762.png > > > Examples of unclear source code: > !image-2024-06-26-20-21-58-461.png|width=869,height=527! > !image-2024-06-26-20-23-51-491.png|width=872,height=514! > Short message output from the console: > !image-2024-06-26-20-52-10-086.png|width=839,height=645! > *Suggest:* Use clearer longMessage instead of shortMessage. > > > h3. *Optimization:* > The following is the optimized effect. > > 1. example 1 > !image-2024-06-27-15-13-14-762.png|width=1606,height=150! > expected error message > *!image-2024-06-27-15-03-23-770.png|width=1690,height=256!* > > 2. example 2 > *!image-2024-06-27-15-12-23-385.png|width=1271,height=120!* > expected error message > *!image-2024-06-27-15-11-37-833.png|width=1390,height=212!* > > > *PR：[[MDEPLOY-320] Unclear exception prompt by youngledo · Pull Request #64 · > apache/maven-deploy-plugin > (github.com)|https://github.com/apache/maven-deploy-plugin/pull/64]* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-799) `defaultVersion` parameter has incorrect default value
[
https://issues.apache.org/jira/browse/MJAVADOC-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17861068#comment-17861068
]
Michael Osipov commented on MJAVADOC-799:
-
PRs welcome.
> `defaultVersion` parameter has incorrect default value
> --
>
> Key: MJAVADOC-799
> URL: https://issues.apache.org/jira/browse/MJAVADOC-799
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: fix
>Affects Versions: 3.7.0
>Reporter: Marcono1234
>Priority: Trivial
>
> The {{defaultVersion}} parameter of the {{javadoc:fix}} has an inconsistent /
> incorrect default value (though I am not sure what the 'correct' value would
> be).
> h3. Inconsistencies
> - The Javadoc says "By default, it is {{$Id:$}}"
> - The actual and documented (on the Mojo help) default is {{$Id: $Id}}
> - The field in the code has the initial value {{$Id: $}}, with a space (using
> Unicode escapes)
> This value seems to have no effect because {{@Parameter#defaultValue}}
> overwrites the initial field value.
> Maybe it would therefore be easiest to:
> - Remove the "By default, it is ..." sentence from the Javadoc
> It is redundant because the Mojo help documents the
> {{@Parameter#defaultValue}}.
> - Remove the initial field value
> - Optionally remove the {{DEFAULT_VERSION_VALUE}} field and directly inline
> the value
> - Optionally change the default to the intended default value (whatever that
> is)
> h3. Historical background
> It seems originally the default value was supposed to be {{$Id$}}, but that
> was apparently causing issues with SVN, so commit
> [0cecfaa|https://github.com/apache/maven-javadoc-plugin/commit/0cecfaac31113f44c7db4c29021fa6f92877e458]
> tried to fix this by using the field initializer and Unicode escapes instead
> of {{default-value=}}. But this caused the first inconsistency because the
> Javadoc said {{$Id:$}} (without space) but the value was {{$Id: $}} (with
> space).
> Later commit
> [3dcd209|https://github.com/apache/maven-javadoc-plugin/commit/3dcd209a1595a95effd824be5a080f1d19f6f37e#diff-987d1364c087fc6899bde7ad2cdeba3e3c883d3c26e9ffbe86ecdce23d7ee1faR204]
> refactored the code to use {{@Parameter}} and added a {{defaultValue}}, but
> that is {{$Id: $Id}} (with duplicate "Id").
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
