[jira] [Commented] (DOXIA-707) Ability to define lineneding for generated content
[
https://issues.apache.org/jira/browse/DOXIA-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779329#comment-17779329
]
Roman Ivanov commented on DOXIA-707:
[~michael-o], do you think that implementation of PrintWriter
As is done at https://github.com/checkstyle/checkstyle/pull/13947 is good
approach?
It looks weird that method
public void write(String line, int offset, int length) {
needs to be override with replacement of what is done by some other content
generator.
Method exists to fix problems of other logic.
> Ability to define lineneding for generated content
> --
>
> Key: DOXIA-707
> URL: https://issues.apache.org/jira/browse/DOXIA-707
> Project: Maven Doxia
> Issue Type: Improvement
>Reporter: Roman Ivanov
>Priority: Major
>
> in Checkstyle project we use doxia classes to generate xml files in xdoc
> format
> https://github.com/checkstyle/checkstyle/issues/13770
> We have a rule that all files in our git repo are Linux line-ending.
> Lunux/unix users are ok, but windows users have inconvenience that after
> build execution xdoc files are marked as changes in git, due to change in
> lineending.
> Right now we do hack with override of some doxia classes to enforce
> lineending that we need.
> It would be awesome if we can defined lineending in some config or system
> variable or
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MENFORCER-493) Provide a more meaningful hint after deprecation of goal display-info
[
https://issues.apache.org/jira/browse/MENFORCER-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MENFORCER-493.
Resolution: Information Provided
Use {{mvn -V ...}}.
> Provide a more meaningful hint after deprecation of goal display-info
> -
>
> Key: MENFORCER-493
> URL: https://issues.apache.org/jira/browse/MENFORCER-493
> Project: Maven Enforcer Plugin
> Issue Type: Wish
>Affects Versions: 3.4.1
>Reporter: Philipp Ottlinger
>Priority: Major
>
> After upgrading to 3.4.1 I see many warnings in my builds
> {{[WARNING] Goal 'display-info' is deprecated: please use mvn --version}}
> as I use
> {{enforcer:display-info}}
> as part of my defaultGoal definition.
>
> I do know mvn --version but I'm not sure how to integrate it into my build as
> I did with display-info as part of my defaultGoal. Adding a new build step to
> all my projects seems a rather cumbersome way of deprecating this
> functionality.
>
> Is there a better way to get these build informations into my build logs? If
> so, I'd love to see this instead of a build warning.
>
> Thanks
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MASSEMBLY-999) Upgrade Parent to 40
Slawomir Jaranowski created MASSEMBLY-999: - Summary: Upgrade Parent to 40 Key: MASSEMBLY-999 URL: https://issues.apache.org/jira/browse/MASSEMBLY-999 Project: Maven Assembly Plugin Issue Type: Dependency upgrade Reporter: Slawomir Jaranowski Fix For: next-release -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MCOMPILER-553) Multi-release build generates compilerSourceRoots is read-only warning
[
https://issues.apache.org/jira/browse/MCOMPILER-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MCOMPILER-553.
-
Resolution: Information Provided
Was fixed in MCOMPILER-501 - please use version 3.11.0
> Multi-release build generates compilerSourceRoots is read-only warning
> --
>
> Key: MCOMPILER-553
> URL: https://issues.apache.org/jira/browse/MCOMPILER-553
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.10.1
>Reporter: Robert Patrick
>Priority: Minor
>
> We are building a multi-release jar in a module of our project. As such, the
> directory structure looks like this:
> {{src/main}}
> {{ java}}
> {{{} java17{}}}{{{}{}}}
> To get this to work, we are doing the following:
> {{}}
> {{ org.apache.maven.plugins}}
> {{ maven-compiler-plugin}}
> {{ }}
> {{ }}
> {{ default-compile}}
> {{ }}
> {{ compile}}
> {{ }}
> {{ }}
> {{ 7}}
> {{ 7}}
> {{ }}
> {{ }}
> {{ }}
> {{ compile-java-17}}
> {{ }}
> {{ compile}}
> {{ }}
> {{ }}
> {{ 17}}
> {{ 17}}
> {{ 17}}
> {{ }}
> {{
> ${project.basedir}/src/main/java17}}
> {{ }}
> {{ true}}
> {{ }}
> {{ }}
> {{ }}
> {{}}
> The build works fine but I am getting this annoying warning:
> [*INFO*] *---* compiler:3.10.1:compile *(compile-java-17)* @
> weblogic-deploy-core *---*
> [*WARNING*] Parameter 'compileSourceRoots' is read-only, must not be used in
> configuration
> [*INFO*] Changes detected - recompiling the module!
> [*INFO*] Compiling 2 source files to
> /Users/rpatrick/Projects/weblogic-deploy-tooling/core/target/classes/META-INF/versions/17
> [*INFO*]
>
> I have tried using includes and excludes instead but that results in all
> classes from src/main/java in the JAR file's META_INF/versions/17 directory.
> If there is a better way to accomplish this, please let me know. Otherwise,
> I think it is wrong to print a warning for something that appears to be the
> only way to make it work.
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1327) Change output directory default in AbstractMavenReport
[
https://issues.apache.org/jira/browse/MSHARED-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779236#comment-17779236
]
ASF GitHub Bot commented on MSHARED-1327:
-
michael-o commented on PR #26:
URL:
https://github.com/apache/maven-reporting-impl/pull/26#issuecomment-1777999520
@hboutemy, WDYT? Build directory or rather a subdir? I tend to a subdir for
consistency reasons.
> Change output directory default in AbstractMavenReport
> --
>
> Key: MSHARED-1327
> URL: https://issues.apache.org/jira/browse/MSHARED-1327
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-4.0.0-M11
>Reporter: Alexander Kriegisch
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-reporting-impl-4.0.0-M12
>
>
> The output directory should default to {{${project.build.directory}}} instead
> of {{${project.reporting.outputDirectory}}}. Quoting my reasoning from
> https://github.com/apache/maven-jxr/commit/ae81a34ac616bf7e4ea4fa9d4eb09f0979eaccb1#commitcomment-130639906:
> {quote}
> (...) because the latter is simply wrong IMO. For stand-alone mojo execution,
> a plugin should not mess with Maven Site's default directory. Imagine a
> situation in which each module should get its own, self-consistent report
> when called stand-alone, but the site should contain an aggregate with a
> different structure or maybe no report from that plugin at all. The default
> would then pollute the site directory. This is why on the ML I asked you
> ([~michaelo]), if overriding a {{@Parameter}} annotation on a base class
> field by another {{@Parameter}} annotation on a setter in a subclass it is
> the right or canonical way to implement such a default override.
> BTW, like I also said before, Maven Javadoc Plugin, even though it does not
> use the abstract base class, implements the default correctly: build dir for
> stand-alone, report dir in site generation context.
> {quote}
> The javadoc is, BTW, still correct and does not need to be changed: In a site
> generation context, the reporting base directory will be set here
> automatically without any further changes due to:
> {code:java}
> @Override
> public void setReportOutputDirectory(File reportOutputDirectory) {
> this.reportOutputDirectory = reportOutputDirectory;
> this.outputDirectory = reportOutputDirectory;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-1327] Change output directory default [maven-reporting-impl]
michael-o commented on PR #26: URL: https://github.com/apache/maven-reporting-impl/pull/26#issuecomment-1777999520 @hboutemy, WDYT? Build directory or rather a subdir? I tend to a subdir for consistency reasons. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (MASSEMBLY-994) Items from unpacked dependency are not refreshed
[
https://issues.apache.org/jira/browse/MASSEMBLY-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski reassigned MASSEMBLY-994:
-
Assignee: Slawomir Jaranowski
> Items from unpacked dependency are not refreshed
>
>
> Key: MASSEMBLY-994
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-994
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.6.0
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> For assembly descriptor like:
> {code:java}
>
> dir
>
>
>
>
> groupId:ArtifactId
>
> true
>
>
> {code}
> Where {{groupId:ArtifactId}} comes from reactor build, even when content of
> artifact was changed, items in destination directory contains old files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1327) Change output directory default in AbstractMavenReport
[
https://issues.apache.org/jira/browse/MSHARED-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779234#comment-17779234
]
ASF GitHub Bot commented on MSHARED-1327:
-
michael-o commented on code in PR #26:
URL:
https://github.com/apache/maven-reporting-impl/pull/26#discussion_r1370778946
##
src/main/java/org/apache/maven/reporting/AbstractMavenReport.java:
##
@@ -74,11 +74,16 @@
*/
public abstract class AbstractMavenReport extends AbstractMojo implements
MavenMultiPageReport {
/**
- * The output directory for the report. Note that this parameter is only
evaluated if the goal is run directly from
- * the command line. If the goal is run indirectly as part of a site
generation, the output directory configured in
- * the Maven Site Plugin is used instead.
+ * The output base directory for the report. Note that this parameter is
only evaluated if the goal is run directly
+ * from the command line. If the goal is run indirectly as part of a site
generation, the output base directory
+ * configured in the https://maven.apache.org/plugins/maven-site-plugin/site-mojo.html#outputDirectory;>
+ * Maven Site Plugin is used instead.
+ *
+ * To the respective base directory for each use case (direct mojo call
vs.site generation), implementing plugins
+ * might want to add their specific subdirectories for multi-page reports,
either using a hard-coded name or,
+ * ideally, an additional user-defined mojo parameter with a default value.
Review Comment:
This must be logically synchronized in terms of wording with
https://github.com/apache/maven-reporting-api/pull/19/files#diff-b76424d2221f7618825101fa2e7b169f2d87b90bac5cbc6a8cdaeb7cbf575e71
to be consistent throughout.
> Change output directory default in AbstractMavenReport
> --
>
> Key: MSHARED-1327
> URL: https://issues.apache.org/jira/browse/MSHARED-1327
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-4.0.0-M11
>Reporter: Alexander Kriegisch
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-reporting-impl-4.0.0-M12
>
>
> The output directory should default to {{${project.build.directory}}} instead
> of {{${project.reporting.outputDirectory}}}. Quoting my reasoning from
> https://github.com/apache/maven-jxr/commit/ae81a34ac616bf7e4ea4fa9d4eb09f0979eaccb1#commitcomment-130639906:
> {quote}
> (...) because the latter is simply wrong IMO. For stand-alone mojo execution,
> a plugin should not mess with Maven Site's default directory. Imagine a
> situation in which each module should get its own, self-consistent report
> when called stand-alone, but the site should contain an aggregate with a
> different structure or maybe no report from that plugin at all. The default
> would then pollute the site directory. This is why on the ML I asked you
> ([~michaelo]), if overriding a {{@Parameter}} annotation on a base class
> field by another {{@Parameter}} annotation on a setter in a subclass it is
> the right or canonical way to implement such a default override.
> BTW, like I also said before, Maven Javadoc Plugin, even though it does not
> use the abstract base class, implements the default correctly: build dir for
> stand-alone, report dir in site generation context.
> {quote}
> The javadoc is, BTW, still correct and does not need to be changed: In a site
> generation context, the reporting base directory will be set here
> automatically without any further changes due to:
> {code:java}
> @Override
> public void setReportOutputDirectory(File reportOutputDirectory) {
> this.reportOutputDirectory = reportOutputDirectory;
> this.outputDirectory = reportOutputDirectory;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-1327] Change output directory default [maven-reporting-impl]
michael-o commented on code in PR #26:
URL:
https://github.com/apache/maven-reporting-impl/pull/26#discussion_r1370778946
##
src/main/java/org/apache/maven/reporting/AbstractMavenReport.java:
##
@@ -74,11 +74,16 @@
*/
public abstract class AbstractMavenReport extends AbstractMojo implements
MavenMultiPageReport {
/**
- * The output directory for the report. Note that this parameter is only
evaluated if the goal is run directly from
- * the command line. If the goal is run indirectly as part of a site
generation, the output directory configured in
- * the Maven Site Plugin is used instead.
+ * The output base directory for the report. Note that this parameter is
only evaluated if the goal is run directly
+ * from the command line. If the goal is run indirectly as part of a site
generation, the output base directory
+ * configured in the https://maven.apache.org/plugins/maven-site-plugin/site-mojo.html#outputDirectory;>
+ * Maven Site Plugin is used instead.
+ *
+ * To the respective base directory for each use case (direct mojo call
vs.site generation), implementing plugins
+ * might want to add their specific subdirectories for multi-page reports,
either using a hard-coded name or,
+ * ideally, an additional user-defined mojo parameter with a default value.
Review Comment:
This must be logically synchronized in terms of wording with
https://github.com/apache/maven-reporting-api/pull/19/files#diff-b76424d2221f7618825101fa2e7b169f2d87b90bac5cbc6a8cdaeb7cbf575e71
to be consistent throughout.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MSHARED-1327) Change output directory default in AbstractMavenReport
[
https://issues.apache.org/jira/browse/MSHARED-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779232#comment-17779232
]
Michael Osipov commented on MSHARED-1327:
-
Regarding not using {{AbstractMavenReport}}: If you cannot or will not use it,
that is fine, but don't expect us to play nicely. The purpose of this class is
to ease life for everyone. The Javadoc Plugin can't, granted, but then we have
to live with that.
> Change output directory default in AbstractMavenReport
> --
>
> Key: MSHARED-1327
> URL: https://issues.apache.org/jira/browse/MSHARED-1327
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-4.0.0-M11
>Reporter: Alexander Kriegisch
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-reporting-impl-4.0.0-M12
>
>
> The output directory should default to {{${project.build.directory}}} instead
> of {{${project.reporting.outputDirectory}}}. Quoting my reasoning from
> https://github.com/apache/maven-jxr/commit/ae81a34ac616bf7e4ea4fa9d4eb09f0979eaccb1#commitcomment-130639906:
> {quote}
> (...) because the latter is simply wrong IMO. For stand-alone mojo execution,
> a plugin should not mess with Maven Site's default directory. Imagine a
> situation in which each module should get its own, self-consistent report
> when called stand-alone, but the site should contain an aggregate with a
> different structure or maybe no report from that plugin at all. The default
> would then pollute the site directory. This is why on the ML I asked you
> ([~michaelo]), if overriding a {{@Parameter}} annotation on a base class
> field by another {{@Parameter}} annotation on a setter in a subclass it is
> the right or canonical way to implement such a default override.
> BTW, like I also said before, Maven Javadoc Plugin, even though it does not
> use the abstract base class, implements the default correctly: build dir for
> stand-alone, report dir in site generation context.
> {quote}
> The javadoc is, BTW, still correct and does not need to be changed: In a site
> generation context, the reporting base directory will be set here
> automatically without any further changes due to:
> {code:java}
> @Override
> public void setReportOutputDirectory(File reportOutputDirectory) {
> this.reportOutputDirectory = reportOutputDirectory;
> this.outputDirectory = reportOutputDirectory;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MASSEMBLY-996) Bump zstd-jni from 1.5.5-4 to 1.5.5-5
[ https://issues.apache.org/jira/browse/MASSEMBLY-996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779228#comment-17779228 ] ASF GitHub Bot commented on MASSEMBLY-996: -- slawekjaranowski merged PR #154: URL: https://github.com/apache/maven-assembly-plugin/pull/154 > Bump zstd-jni from 1.5.5-4 to 1.5.5-5 > - > > Key: MASSEMBLY-996 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-996 > Project: Maven Assembly Plugin > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: next-release > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MASSEMBLY-996) Bump zstd-jni from 1.5.5-4 to 1.5.5-6
[ https://issues.apache.org/jira/browse/MASSEMBLY-996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MASSEMBLY-996: -- Summary: Bump zstd-jni from 1.5.5-4 to 1.5.5-6 (was: Bump zstd-jni from 1.5.5-4 to 1.5.5-5) > Bump zstd-jni from 1.5.5-4 to 1.5.5-6 > - > > Key: MASSEMBLY-996 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-996 > Project: Maven Assembly Plugin > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: next-release > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MASSEMBLY-996] Bump com.github.luben:zstd-jni from 1.5.5-5 to 1.5.5-6 [maven-assembly-plugin]
slawekjaranowski merged PR #154: URL: https://github.com/apache/maven-assembly-plugin/pull/154 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (SUREFIRE-2205) Mojo documentation links are broken
[ https://issues.apache.org/jira/browse/SUREFIRE-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed SUREFIRE-2205. Resolution: Fixed Fixed with [a540ef4a95bfd78f9487b282fa04efa9c48ccd3e|https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=a540ef4a95bfd78f9487b282fa04efa9c48ccd3e]. Republished broken pages. > Mojo documentation links are broken > --- > > Key: SUREFIRE-2205 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2205 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Affects Versions: 3.2.1 >Reporter: Daniel Huss >Assignee: Michael Osipov >Priority: Minor > Fix For: version-next > > Attachments: image-2023-10-24-16-45-11-220.png > > > To reproduce: > # Go to [https://maven.apache.org/surefire/maven-surefire-plugin/] > # Click link to "goals" or "surefire:test" > Expected: Goals or goal documentation is shown. > Actual: !image-2023-10-24-16-45-11-220.png|width=299,height=182! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2205) Mojo documentation links are broken
[ https://issues.apache.org/jira/browse/SUREFIRE-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SUREFIRE-2205: - Fix Version/s: version-next > Mojo documentation links are broken > --- > > Key: SUREFIRE-2205 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2205 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Affects Versions: 3.2.1 >Reporter: Daniel Huss >Assignee: Michael Osipov >Priority: Minor > Fix For: version-next > > Attachments: image-2023-10-24-16-45-11-220.png > > > To reproduce: > # Go to [https://maven.apache.org/surefire/maven-surefire-plugin/] > # Click link to "goals" or "surefire:test" > Expected: Goals or goal documentation is shown. > Actual: !image-2023-10-24-16-45-11-220.png|width=299,height=182! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JXR-183) Plugin Documentation not generated
[
https://issues.apache.org/jira/browse/JXR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed JXR-183.
--
Fix Version/s: version-next
Resolution: Fixed
Fixed with
[ebdbc95b884dd4c16e22fa62c08f97a55e2ceacd|https://gitbox.apache.org/repos/asf?p=maven-jxr.git;a=commit;h=ebdbc95b884dd4c16e22fa62c08f97a55e2ceacd].
Affected site has been republished.
> Plugin Documentation not generated
> --
>
> Key: JXR-183
> URL: https://issues.apache.org/jira/browse/JXR-183
> Project: Maven JXR
> Issue Type: Bug
> Components: maven-jxr-plugin
>Affects Versions: 3.3.1
>Reporter: Brad Larrick
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: version-next
>
>
> The plugin pages aren't being generated. Looks like the plugin pom references
> the wrong plugin in the reporting section:
> {quote}{{ }}
> {{ }}
> {{ }}
> {{ org.apache.maven.plugins}}
> {{ maven-plugin-plugin}}
> {{ }}
> {{ }}
> {{ }}
> {quote}
> should be:
> {quote}
>
>
> org.apache.maven.plugins
> maven-plugin-report-plugin
>
>
>
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Automatic code improvement, no semantic change [maven-resolver]
cstamas merged PR #349: URL: https://github.com/apache/maven-resolver/pull/349 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Automatic code change [maven-resolver]
cstamas opened a new pull request, #349: URL: https://github.com/apache/maven-resolver/pull/349 Some archaic contructs were replaced with more appropriate methods around string handling. This PR does not introduce any semantic change. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (JXR-183) Plugin Documentation not generated
[
https://issues.apache.org/jira/browse/JXR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779204#comment-17779204
]
Michael Osipov commented on JXR-183:
Bah, someone has messed this up in the new parent 40. Will fix this. Thanks for
the report.
> Plugin Documentation not generated
> --
>
> Key: JXR-183
> URL: https://issues.apache.org/jira/browse/JXR-183
> Project: Maven JXR
> Issue Type: Bug
> Components: maven2 jxr plugin
>Affects Versions: 3.3.1
>Reporter: Brad Larrick
>Assignee: Michael Osipov
>Priority: Minor
>
> The plugin pages aren't being generated. Looks like the plugin pom references
> the wrong plugin in the reporting section:
> {quote}{{ }}
> {{ }}
> {{ }}
> {{ org.apache.maven.plugins}}
> {{ maven-plugin-plugin}}
> {{ }}
> {{ }}
> {{ }}
> {quote}
> should be:
> {quote}
>
>
> org.apache.maven.plugins
> maven-plugin-report-plugin
>
>
>
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (JXR-183) Plugin Documentation not generated
[
https://issues.apache.org/jira/browse/JXR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned JXR-183:
--
Assignee: Michael Osipov
> Plugin Documentation not generated
> --
>
> Key: JXR-183
> URL: https://issues.apache.org/jira/browse/JXR-183
> Project: Maven JXR
> Issue Type: Bug
> Components: maven2 jxr plugin
>Affects Versions: 3.3.1
>Reporter: Brad Larrick
>Assignee: Michael Osipov
>Priority: Minor
>
> The plugin pages aren't being generated. Looks like the plugin pom references
> the wrong plugin in the reporting section:
> {quote}{{ }}
> {{ }}
> {{ }}
> {{ org.apache.maven.plugins}}
> {{ maven-plugin-plugin}}
> {{ }}
> {{ }}
> {{ }}
> {quote}
> should be:
> {quote}
>
>
> org.apache.maven.plugins
> maven-plugin-report-plugin
>
>
>
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (SUREFIRE-2205) Mojo documentation links are broken
[ https://issues.apache.org/jira/browse/SUREFIRE-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned SUREFIRE-2205: Assignee: Michael Osipov > Mojo documentation links are broken > --- > > Key: SUREFIRE-2205 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2205 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Affects Versions: 3.2.1 >Reporter: Daniel Huss >Assignee: Michael Osipov >Priority: Minor > Attachments: image-2023-10-24-16-45-11-220.png > > > To reproduce: > # Go to [https://maven.apache.org/surefire/maven-surefire-plugin/] > # Click link to "goals" or "surefire:test" > Expected: Goals or goal documentation is shown. > Actual: !image-2023-10-24-16-45-11-220.png|width=299,height=182! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MINSTALL-193) Upgrade Parent Version 40
Karl Heinz Marbaise created MINSTALL-193: Summary: Upgrade Parent Version 40 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 Fix For: 3.1.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MINSTALL-192) Code cleanups
[ https://issues.apache.org/jira/browse/MINSTALL-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779191#comment-17779191 ] Karl Heinz Marbaise commented on MINSTALL-192: -- Done in [30d2b530f7199bed86a03caf53cf884f68e76376|https://gitbox.apache.org/repos/asf?p=maven-install-plugin.git;a=commitdiff;h=30d2b530f7199bed86a03caf53cf884f68e76376] > Code cleanups > - > > Key: MINSTALL-192 > URL: https://issues.apache.org/jira/browse/MINSTALL-192 > Project: Maven Install Plugin > Issue Type: Task > Components: install:install, install:install-file >Affects Versions: 3.1.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.1.2 > > > Cleaning up code parts > * Remove manually close calles with try-with-resources > * Inverse reverse logic > * Replace some parts with Streams. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MINSTALL-192) Code cleanups
[ https://issues.apache.org/jira/browse/MINSTALL-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MINSTALL-192. Resolution: Done > Code cleanups > - > > Key: MINSTALL-192 > URL: https://issues.apache.org/jira/browse/MINSTALL-192 > Project: Maven Install Plugin > Issue Type: Task > Components: install:install, install:install-file >Affects Versions: 3.1.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.1.2 > > > Cleaning up code parts > * Remove manually close calles with try-with-resources > * Inverse reverse logic > * Replace some parts with Streams. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINSTALL-192) Code cleanups
[ https://issues.apache.org/jira/browse/MINSTALL-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MINSTALL-192: - Description: Cleaning up code parts * Remove manually close calles with try-with-resources * Inverse reverse logic * Replace some parts with Streams. > Code cleanups > - > > Key: MINSTALL-192 > URL: https://issues.apache.org/jira/browse/MINSTALL-192 > Project: Maven Install Plugin > Issue Type: Task > Components: install:install, install:install-file >Affects Versions: 3.1.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.1.2 > > > Cleaning up code parts > * Remove manually close calles with try-with-resources > * Inverse reverse logic > * Replace some parts with Streams. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MINSTALL-192) Code cleanups
Karl Heinz Marbaise created MINSTALL-192: Summary: Code cleanups Key: MINSTALL-192 URL: https://issues.apache.org/jira/browse/MINSTALL-192 Project: Maven Install Plugin Issue Type: Task Components: install:install, install:install-file Affects Versions: 3.1.1 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: 3.1.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JXR-183) Plugin Documentation not generated
[
https://issues.apache.org/jira/browse/JXR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Larrick updated JXR-183:
-
Description:
The plugin pages aren't being generated. Looks like the plugin pom references
the wrong plugin in the reporting section:
{quote}{{ }}
{{ }}
{{ }}
{{ org.apache.maven.plugins}}
{{ maven-plugin-plugin}}
{{ }}
{{ }}
{{ }}
{quote}
should be:
{quote}
org.apache.maven.plugins
maven-plugin-report-plugin
{quote}
was:
The plugin pages aren't being generated. Looks like the plugin pom references
the wrong plugin in the reporting section:
```
org.apache.maven.plugins
maven-plugin-plugin
```
should be:
```
org.apache.maven.plugins
maven-plugin-report-plugin
```
> Plugin Documentation not generated
> --
>
> Key: JXR-183
> URL: https://issues.apache.org/jira/browse/JXR-183
> Project: Maven JXR
> Issue Type: Bug
> Components: maven2 jxr plugin
>Affects Versions: 3.3.1
>Reporter: Brad Larrick
>Priority: Minor
>
> The plugin pages aren't being generated. Looks like the plugin pom references
> the wrong plugin in the reporting section:
> {quote}{{ }}
> {{ }}
> {{ }}
> {{ org.apache.maven.plugins}}
> {{ maven-plugin-plugin}}
> {{ }}
> {{ }}
> {{ }}
> {quote}
> should be:
> {quote}
>
>
> org.apache.maven.plugins
> maven-plugin-report-plugin
>
>
>
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JXR-183) Plugin Documentation not generated
Brad Larrick created JXR-183: Summary: Plugin Documentation not generated Key: JXR-183 URL: https://issues.apache.org/jira/browse/JXR-183 Project: Maven JXR Issue Type: Bug Components: maven2 jxr plugin Affects Versions: 3.3.1 Reporter: Brad Larrick The plugin pages aren't being generated. Looks like the plugin pom references the wrong plugin in the reporting section: ``` org.apache.maven.plugins maven-plugin-plugin ``` should be: ``` org.apache.maven.plugins maven-plugin-report-plugin ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-548) JDK 21 throws annotations processing warning that can not be turned off
[
https://issues.apache.org/jira/browse/MCOMPILER-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779139#comment-17779139
]
ASF GitHub Bot commented on MCOMPILER-548:
--
hgschmie commented on code in PR #200:
URL:
https://github.com/apache/maven-compiler-plugin/pull/200#discussion_r1370409335
##
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java:
##
@@ -279,8 +279,11 @@ public abstract class AbstractCompilerMojo extends
AbstractMojo {
*
* none - no annotation processing is performed.
* only - only annotation processing is done, no
compilation.
+ * full - annotation processing and compilation.
*
*
+ * full is the default. Starting with JDK 21, this option
must be set explicitly.
Review Comment:
Interesting. Thank you for suggesting this. I can see the problems with
incremental compilation but it still might be an acceptable workaround. Does
that increase build times? Without static code analysis and tests, running the
compiler is dominating build times and this seems to double those.
> JDK 21 throws annotations processing warning that can not be turned off
> ---
>
> Key: MCOMPILER-548
> URL: https://issues.apache.org/jira/browse/MCOMPILER-548
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.11.0
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> maven compiler plugin 3.11 on Java 21 reports
> {quote}
> [INFO] Annotation processing is enabled because one or more processors were
> found
> on the class path. A future release of javac may disable annotation
> processing
> unless at least one processor is specified by name (-processor), or a search
> path is specified (--processor-path, --processor-module-path), or annotation
> processing is enabled explicitly (-proc:only, -proc:full).
> Use -Xlint:-options to suppress this message.
> Use -proc:none to disable annotation processing.
> {quote}
> However, the {{}} option only supports "none" and "proc", not "full"
> (which is the implicit default).
> Adding this through a compiler option:
> {quote}
>
>
> -proc:full
>
>
> {quote}
> fixes this warning. Adding "full" as a value for the compiler plugin would
> fix it, too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MCOMPILER-548] JDK 21 throws annotations processing warning that can not be turned off [maven-compiler-plugin]
hgschmie commented on code in PR #200:
URL:
https://github.com/apache/maven-compiler-plugin/pull/200#discussion_r1370409335
##
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java:
##
@@ -279,8 +279,11 @@ public abstract class AbstractCompilerMojo extends
AbstractMojo {
*
* none - no annotation processing is performed.
* only - only annotation processing is done, no
compilation.
+ * full - annotation processing and compilation.
*
*
+ * full is the default. Starting with JDK 21, this option
must be set explicitly.
Review Comment:
Interesting. Thank you for suggesting this. I can see the problems with
incremental compilation but it still might be an acceptable workaround. Does
that increase build times? Without static code analysis and tests, running the
compiler is dominating build times and this seems to double those.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Created] (SUREFIRE-2205) Mojo documentation links are broken
Daniel Huss created SUREFIRE-2205: - Summary: Mojo documentation links are broken Key: SUREFIRE-2205 URL: https://issues.apache.org/jira/browse/SUREFIRE-2205 Project: Maven Surefire Issue Type: Bug Components: documentation Affects Versions: 3.2.1 Reporter: Daniel Huss Attachments: image-2023-10-24-16-45-11-220.png To reproduce: # Go to [https://maven.apache.org/surefire/maven-surefire-plugin/] # Click link to "goals" or "surefire:test" Expected: Goals or goal documentation is shown. Actual: !image-2023-10-24-16-45-11-220.png|width=299,height=182! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MCOMPILER-553) Multi-release build generates compilerSourceRoots is read-only warning
Robert Patrick created MCOMPILER-553:
Summary: Multi-release build generates compilerSourceRoots is
read-only warning
Key: MCOMPILER-553
URL: https://issues.apache.org/jira/browse/MCOMPILER-553
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.10.1
Reporter: Robert Patrick
We are building a multi-release jar in a module of our project. As such, the
directory structure looks like this:
{{src/main}}
{{ java}}
{{{} java17{}}}{{{}{}}}
To get this to work, we are doing the following:
{{}}
{{ org.apache.maven.plugins}}
{{ maven-compiler-plugin}}
{{ }}
{{ }}
{{ default-compile}}
{{ }}
{{ compile}}
{{ }}
{{ }}
{{ 7}}
{{ 7}}
{{ }}
{{ }}
{{ }}
{{ compile-java-17}}
{{ }}
{{ compile}}
{{ }}
{{ }}
{{ 17}}
{{ 17}}
{{ 17}}
{{ }}
{{
${project.basedir}/src/main/java17}}
{{ }}
{{ true}}
{{ }}
{{ }}
{{ }}
{{}}
The build works fine but I am getting this annoying warning:
[*INFO*] *---* compiler:3.10.1:compile *(compile-java-17)* @
weblogic-deploy-core *---*
[*WARNING*] Parameter 'compileSourceRoots' is read-only, must not be used in
configuration
[*INFO*] Changes detected - recompiling the module!
[*INFO*] Compiling 2 source files to
/Users/rpatrick/Projects/weblogic-deploy-tooling/core/target/classes/META-INF/versions/17
[*INFO*]
I have tried using includes and excludes instead but that results in all
classes from src/main/java in the JAR file's META_INF/versions/17 directory.
If there is a better way to accomplish this, please let me know. Otherwise, I
think it is wrong to print a warning for something that appears to be the only
way to make it work.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-548) JDK 21 throws annotations processing warning that can not be turned off
[
https://issues.apache.org/jira/browse/MCOMPILER-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779108#comment-17779108
]
ASF GitHub Bot commented on MCOMPILER-548:
--
cstamas commented on code in PR #200:
URL:
https://github.com/apache/maven-compiler-plugin/pull/200#discussion_r1370248141
##
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java:
##
@@ -279,8 +279,11 @@ public abstract class AbstractCompilerMojo extends
AbstractMojo {
*
* none - no annotation processing is performed.
* only - only annotation processing is done, no
compilation.
+ * full - annotation processing and compilation.
*
*
+ * full is the default. Starting with JDK 21, this option
must be set explicitly.
Review Comment:
... and I keep forgetting about this, and for me this sounds like "most
correct" solution as well: split steps and use existing phases even we provide.
> JDK 21 throws annotations processing warning that can not be turned off
> ---
>
> Key: MCOMPILER-548
> URL: https://issues.apache.org/jira/browse/MCOMPILER-548
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.11.0
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> maven compiler plugin 3.11 on Java 21 reports
> {quote}
> [INFO] Annotation processing is enabled because one or more processors were
> found
> on the class path. A future release of javac may disable annotation
> processing
> unless at least one processor is specified by name (-processor), or a search
> path is specified (--processor-path, --processor-module-path), or annotation
> processing is enabled explicitly (-proc:only, -proc:full).
> Use -Xlint:-options to suppress this message.
> Use -proc:none to disable annotation processing.
> {quote}
> However, the {{}} option only supports "none" and "proc", not "full"
> (which is the implicit default).
> Adding this through a compiler option:
> {quote}
>
>
> -proc:full
>
>
> {quote}
> fixes this warning. Adding "full" as a value for the compiler plugin would
> fix it, too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MCOMPILER-548] JDK 21 throws annotations processing warning that can not be turned off [maven-compiler-plugin]
cstamas commented on code in PR #200:
URL:
https://github.com/apache/maven-compiler-plugin/pull/200#discussion_r1370248141
##
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java:
##
@@ -279,8 +279,11 @@ public abstract class AbstractCompilerMojo extends
AbstractMojo {
*
* none - no annotation processing is performed.
* only - only annotation processing is done, no
compilation.
+ * full - annotation processing and compilation.
*
*
+ * full is the default. Starting with JDK 21, this option
must be set explicitly.
Review Comment:
... and I keep forgetting about this, and for me this sounds like "most
correct" solution as well: split steps and use existing phases even we provide.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] fix DeployAtEnd failures [maven-deploy-plugin]
NersesAM commented on PR #1: URL: https://github.com/apache/maven-deploy-plugin/pull/1#issuecomment-1777295783 I thought GH uses latest maven! lessons learned I guess :) I agree controlling the version is the best. Thanks for your help -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] fix DeployAtEnd failures [maven-deploy-plugin]
cstamas commented on PR #1: URL: https://github.com/apache/maven-deploy-plugin/pull/1#issuecomment-1777280821 Well,... * 3.8.x should be left for oblivion, use 3.9.x * your best bet is wrapper, as you fully control Maven in use, and not rely on any 3rd party things like GH Action, some preinstalled software, or whatever. Always keep yourself in control :smile: * `-pl` and friends in Maven 3 can have unexpected (side) effects, especially when project observed "as whole" (is what deployAtEnd tries to do)/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] fix DeployAtEnd failures [maven-deploy-plugin]
NersesAM commented on PR #1:
URL:
https://github.com/apache/maven-deploy-plugin/pull/1#issuecomment-1777268274
I tried to create small reproducible case but I am not able to.
I started playing a bit more with my project and I noticed that github
actions runner was using maven version 3.8.8, same project running with 3.9.5
works just fine! I have no idea what has changed in between the 2.
the project I am trying to deploy is https://github.com/ExpediaGroup/styx
in github actions I run
```
./mvnw --settings /home/settings.xml deploy -DskipTests=true -Prelease
-Dlibs.release.url=${{env.MAVEN_URL}}/maven-release-local
-Dlibs.snapshot.url=${{env.MAVEN_URL}}/maven-snapshot-local -DdeployAtEnd=true
-Dlicense.skip=true
```
If you have local server repo server to deploy and can try against. you can
skip tests to make the build faster
3.8.8
```
[INFO] --- maven-deploy-plugin:3.1.1:deploy (default-deploy) @
styx-distribution ---
[INFO] Deferring deploy for com.hotels.styx:styx-distribution:1.0-SNAPSHOT
at end
[INFO]
[INFO] --- maven-deploy-plugin:3.1.1:deploy-file (deploy-file) @
styx-distribution ---
[INFO] pom.xml not found in styx-1.0-SNAPSHOT.zip
Downloading from central:
https://artfactory/com/hotels/styx/styx/1.0-SNAPSHOT/maven-metadata.xml
[WARNING] Could not transfer metadata
com.hotels.styx:styx:1.0-SNAPSHOT/maven-metadata.xml from/to central
(https://artifactory): authentication failed for
https://artifactory/com/hotels/styx/styx/1.0-SNAPSHOT/maven-metadata.xml,
status: 401 Unauthorized
```
vs
3.9.5
```
[INFO] --- deploy:3.1.1:deploy (default-deploy) @ styx-distribution ---
Downloading from snapshots:
https://artifactory/com/hotels/styx/styx-parent/1.0-SNAPSHOT/maven-metadata.xml
[WARNING] Could not transfer metadata
com.hotels.styx:styx-parent:1.0-SNAPSHOT/maven-metadata.xml from/to snapshots
(https://artifactory): status code: 401, reason phrase: Unauthorized (401)
```
Ignore it fails, but you can see with 3.8.8 it is failing at
deploy:deploy-file skipping deploy:deploy while with 3.9.5 it is actually
failing at deploy:deploy phase which was supposed to do deployment of all the
modules
another interesting thing is if you remove one of the modules with `-pl
!plugin-examples` it works with 3.8.8
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MCOMPILER-548) JDK 21 throws annotations processing warning that can not be turned off
[
https://issues.apache.org/jira/browse/MCOMPILER-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779091#comment-17779091
]
ASF GitHub Bot commented on MCOMPILER-548:
--
bmarwell commented on code in PR #200:
URL:
https://github.com/apache/maven-compiler-plugin/pull/200#discussion_r1370169302
##
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java:
##
@@ -279,8 +279,11 @@ public abstract class AbstractCompilerMojo extends
AbstractMojo {
*
* none - no annotation processing is performed.
* only - only annotation processing is done, no
compilation.
+ * full - annotation processing and compilation.
*
*
+ * full is the default. Starting with JDK 21, this option
must be set explicitly.
Review Comment:
Another solution (which is probably intended by the JDK folks):
I used to do two executions in my projects:
* generate-sources: execute with `proc:only`
* default-compile: execute with `proc:none`
Worked like a charm and only changed it because Tamas hinted me to do so
(because with this setup, some things like caching, incremental compilation
etc. won't work that well or not at all).
However, this solution would not run into those problems at all.
> JDK 21 throws annotations processing warning that can not be turned off
> ---
>
> Key: MCOMPILER-548
> URL: https://issues.apache.org/jira/browse/MCOMPILER-548
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.11.0
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> maven compiler plugin 3.11 on Java 21 reports
> {quote}
> [INFO] Annotation processing is enabled because one or more processors were
> found
> on the class path. A future release of javac may disable annotation
> processing
> unless at least one processor is specified by name (-processor), or a search
> path is specified (--processor-path, --processor-module-path), or annotation
> processing is enabled explicitly (-proc:only, -proc:full).
> Use -Xlint:-options to suppress this message.
> Use -proc:none to disable annotation processing.
> {quote}
> However, the {{}} option only supports "none" and "proc", not "full"
> (which is the implicit default).
> Adding this through a compiler option:
> {quote}
>
>
> -proc:full
>
>
> {quote}
> fixes this warning. Adding "full" as a value for the compiler plugin would
> fix it, too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MCOMPILER-548] JDK 21 throws annotations processing warning that can not be turned off [maven-compiler-plugin]
bmarwell commented on code in PR #200:
URL:
https://github.com/apache/maven-compiler-plugin/pull/200#discussion_r1370169302
##
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java:
##
@@ -279,8 +279,11 @@ public abstract class AbstractCompilerMojo extends
AbstractMojo {
*
* none - no annotation processing is performed.
* only - only annotation processing is done, no
compilation.
+ * full - annotation processing and compilation.
*
*
+ * full is the default. Starting with JDK 21, this option
must be set explicitly.
Review Comment:
Another solution (which is probably intended by the JDK folks):
I used to do two executions in my projects:
* generate-sources: execute with `proc:only`
* default-compile: execute with `proc:none`
Worked like a charm and only changed it because Tamas hinted me to do so
(because with this setup, some things like caching, incremental compilation
etc. won't work that well or not at all).
However, this solution would not run into those problems at all.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (MRELEASE-1131) When preparing a release on Windows 10, the pom.xml is not read properly when building the code
[
https://issues.apache.org/jira/browse/MRELEASE-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Voorn updated MRELEASE-1131:
---
Description:
I created a project on a Macbook Pro laptop that uses the Maven Release Plugin
(tried with 2.5.3 and 3.0.1) and works as desired and documented. However, when
I clone this project on a Windows 10 machine and to the same 'mvn
release:prepare' command, it behaves differently. It will do the checks
regarding -SNAPSHOT should be in the version, the new release version is
suggested and can be modified, the tag name is suggested and can be modified,
and the new SNAPSHOT version is suggested and can be modified. After that, on
Macbook it will the package maven goal (as configured in the plugin). On
Windows I get the following error:
{noformat}
The goal you specified requires a project to execute but there is no POM in
this directory (C:\). Please verify you invoked
Maven from the correct directory.
{noformat}
It looks like when the release:prepare goal is executed on the maven project,
it first can read it (hence the version suggestions are correct) but when the
'package' goal is executed after that it tries to find the pom.xml in my home
folder (when the maven command is not executed and the pom.xml is indeed not
present.
I also tried to explicitly give the full path to the pom.xml file using the -f
option and that also does not work.
The plugin configuration is as follows:
{code:xml}
org.apache.maven.plugins
maven-release-plugin
pre-integration-test
package
true
v@{project.version}
false
{code}
I use the following spring-boot-starter-parent:
{code:xml}
org.springframework.boot
spring-boot-starter-parent
2.5.8
{code}
Is there something that needs to change when using this plugin in Windows
instead of Macbook?
On windows I use the git-bash linux shell application to run the maven command.
The problem also happens using the regular cmd.exe from windows (even when
running with administrator rights). The Windows 10 machine I am working on is a
restricted virtual machine, but should have full administrative rights when the
cmd.exe is started as adminitrator. I am convinced that the configuration is
correct since it works fine on Macbook. Maybe someone can point out some
differences that are happening on Linux based machines and Windows 10. I have
tried to find some solutions using google and these solutions do not work.
was:
I created a project on a Macbook Pro laptop that uses the Maven Release Plugin
(tried with 2.5.3 and 3.0.1) and works as desired and documented. However, when
I clone this project on a Windows 10 machine and to the same 'mvn
release:prepare' command, I behaves differently. I will do the checks regarding
-SNAPSHOT should be in the version, the new release version is suggested and
can be modified, the tag name is suggested and can be modified, and the new
SNAPSHOT version is suggested and can be modified. After that, on Macbook it
will the package maven goal (as configured in the plugin). On Windows I get the
following error:
{noformat}
The goal you specified requires a project to execute but there is no POM in
this directory (C:\). Please verify you invoked
Maven from the correct directory.
{noformat}
It looks like when the release:prepare goal is executed on the maven project,
it first can read it (hence the version suggestions are correct) but when the
'package' goal is executed after that it tries to find the pom.xml in my home
folder (when the maven command is not executed and the pom.xml is indeed not
present.
I also tried to explicitly give the full path to the pom.xml file using the -f
option and that also does not work.
The plugin configuration is as follows:
{code:xml}
org.apache.maven.plugins
maven-release-plugin
pre-integration-test
package
true
v@{project.version}
false
{code}
I use the following spring-boot-starter-parent:
{code:xml}
org.springframework.boot
spring-boot-starter-parent
2.5.8
{code}
Is there something that needs to change when using this plugin in Windows
instead of Macbook?
On windows I use the git-bash linux shell application to run the maven command.
The problem also happens using the regular cmd.exe from windows (even when
running with administrator rights). The Windows 10 machine I am working on is a
restricted virtual machine, but should have full administrative rights when the
cmd.exe is started as adminitrator. I am convinced
[jira] [Commented] (MSHARED-1327) Change output directory default in AbstractMavenReport
[
https://issues.apache.org/jira/browse/MSHARED-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778967#comment-17778967
]
Michael Osipov commented on MSHARED-1327:
-
I will try to go through your posts in the next couple of days. I am fine to
break things since: (a) we do release new major versions and at some point we
need to make progress, (b) I will look at Javadoc plugin to fix it as well.
> Change output directory default in AbstractMavenReport
> --
>
> Key: MSHARED-1327
> URL: https://issues.apache.org/jira/browse/MSHARED-1327
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-4.0.0-M11
>Reporter: Alexander Kriegisch
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-reporting-impl-4.0.0-M12
>
>
> The output directory should default to {{${project.build.directory}}} instead
> of {{${project.reporting.outputDirectory}}}. Quoting my reasoning from
> https://github.com/apache/maven-jxr/commit/ae81a34ac616bf7e4ea4fa9d4eb09f0979eaccb1#commitcomment-130639906:
> {quote}
> (...) because the latter is simply wrong IMO. For stand-alone mojo execution,
> a plugin should not mess with Maven Site's default directory. Imagine a
> situation in which each module should get its own, self-consistent report
> when called stand-alone, but the site should contain an aggregate with a
> different structure or maybe no report from that plugin at all. The default
> would then pollute the site directory. This is why on the ML I asked you
> ([~michaelo]), if overriding a {{@Parameter}} annotation on a base class
> field by another {{@Parameter}} annotation on a setter in a subclass it is
> the right or canonical way to implement such a default override.
> BTW, like I also said before, Maven Javadoc Plugin, even though it does not
> use the abstract base class, implements the default correctly: build dir for
> stand-alone, report dir in site generation context.
> {quote}
> The javadoc is, BTW, still correct and does not need to be changed: In a site
> generation context, the reporting base directory will be set here
> automatically without any further changes due to:
> {code:java}
> @Override
> public void setReportOutputDirectory(File reportOutputDirectory) {
> this.reportOutputDirectory = reportOutputDirectory;
> this.outputDirectory = reportOutputDirectory;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
