[jira] [Commented] (MNG-7479) Export the package org.apache.maven.eventspy
[ https://issues.apache.org/jira/browse/MNG-7479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790920#comment-17790920 ] ASF GitHub Bot commented on MNG-7479: - laeubi commented on PR #740: URL: https://github.com/apache/maven/pull/740#issuecomment-1831278444 @gnodet would be great to have a solution for Maven4 so extensions can participate in producing events. > Export the package org.apache.maven.eventspy > > > Key: MNG-7479 > URL: https://issues.apache.org/jira/browse/MNG-7479 > Project: Maven > Issue Type: Improvement > Components: Core >Affects Versions: 3.8.5 >Reporter: Christoph Läubrich >Priority: Major > > I'm currently try to fetch a specific EventSpy to inject an event there > (maven-profiler). > Sadly in my maven plugin when I try to get it injected: > @Requirement(role = EventSpy.class, hint = "profiler", optional = true) > EventSpy eventSpy; > This results in ClassNotFoundException: org.apache.maven.eventspy.EventSpy > I noticed that the maven-core do not export the 'org.apache.maven.eventspy' > package and that is the cause of this, I'd like to suggest to export the > package as there seem no other standard way to interact/access event spys > otherwise. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] MNG-7479 - Export the package org.apache.maven.eventspy [maven]
laeubi commented on PR #740: URL: https://github.com/apache/maven/pull/740#issuecomment-1831278444 @gnodet would be great to have a solution for Maven4 so extensions can participate in producing events. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7479) Export the package org.apache.maven.eventspy
[ https://issues.apache.org/jira/browse/MNG-7479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790919#comment-17790919 ] ASF GitHub Bot commented on MNG-7479: - laeubi closed pull request #740: MNG-7479 - Export the package org.apache.maven.eventspy URL: https://github.com/apache/maven/pull/740 > Export the package org.apache.maven.eventspy > > > Key: MNG-7479 > URL: https://issues.apache.org/jira/browse/MNG-7479 > Project: Maven > Issue Type: Improvement > Components: Core >Affects Versions: 3.8.5 >Reporter: Christoph Läubrich >Priority: Major > > I'm currently try to fetch a specific EventSpy to inject an event there > (maven-profiler). > Sadly in my maven plugin when I try to get it injected: > @Requirement(role = EventSpy.class, hint = "profiler", optional = true) > EventSpy eventSpy; > This results in ClassNotFoundException: org.apache.maven.eventspy.EventSpy > I noticed that the maven-core do not export the 'org.apache.maven.eventspy' > package and that is the cause of this, I'd like to suggest to export the > package as there seem no other standard way to interact/access event spys > otherwise. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] MNG-7479 - Export the package org.apache.maven.eventspy [maven]
laeubi closed pull request #740: MNG-7479 - Export the package org.apache.maven.eventspy URL: https://github.com/apache/maven/pull/740 -- 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] (MJAVADOC-682) Reactor builds fail when multiple modules with same groupId:artifactId, but different versions
[
https://issues.apache.org/jira/browse/MJAVADOC-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790896#comment-17790896
]
AO Industries, Inc. commented on MJAVADOC-682:
--
[~michael-o] Thank you and understood. I have forked the repository, including
all branches, and have MJAVADOC-682 checked-out. I will create integration
test in the morning.
> Reactor builds fail when multiple modules with same groupId:artifactId, but
> different versions
> --
>
> Key: MJAVADOC-682
> URL: https://issues.apache.org/jira/browse/MJAVADOC-682
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0, 3.1.1, 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0, 3.4.1,
> 3.5.0, 3.6.0, 3.6.2
> Environment: Debian Linux versions 10.10 through 12.2
> OpenJDK 64-bit versions 11.0.11 through 17.0.9
> Maven versions 3.8.1 through 3.9.5
>Reporter: AO Industries, Inc.
>Assignee: Michael Osipov
>Priority: Major
> Labels: jpms
> Fix For: 3.6.3
>
>
> In versions 3.1.0 through 3.6.2, when a reactor build has multiple projects
> with the same groupId and artifactId, even when different versions, the
> javadoc fails with:
> Exit code: 1 - error: module not found: com.aoindustries.example
> Plugin 3.0.1 works.
> We have created a minimal example project that demonstrates this bug:
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name]
>
> — Copy from demo project README.md —
> h2. To Reproduce:
> # Clone this project: {{git clone
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name.git]}}
> # Change to project directory: {{cd
> maven-javadoc-plugin-failing-multiple-projects-same-name}}
> # Perform build to see error in {{jar}} goal: {{mvn verify}}
> # Also fails with {{javadoc}} goal: {{mvn clean compile javadoc:javadoc}}
> h2. Notes:
> * Can build individual modules directly, such as {{(cd module-1 && mvn
> verify)}}
> * Reverting to maven-javadoc-plugin version 3.0.1 makes it work
> * Changing the groupId or artifactId in either module-1 or module-2 makes it
> work.
> * Changing module names, package names, or class names in modules has no
> effect.
> * We believe this to be distinct from [Issue
> #673|https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-673]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1285) DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
[
https://issues.apache.org/jira/browse/MSHARED-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790895#comment-17790895
]
ASF GitHub Bot commented on MSHARED-1285:
-
laeubi commented on PR #77:
URL: https://github.com/apache/maven-filtering/pull/77#issuecomment-1831210021
@lalmeras many many thanks for looking into the test!
> So the issue for this test failure is in TestIncrementalBuildContext
(org.sonatype.plexus:plexus-build-api:tests). Not sure how to handle this.
This is actually deprecated/removed in later versions exactly because no one
can know what the test wants to assert... so the best would be to simply copy
it in the plugin here and adjust as needed, or even better using a mock.
> DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
> --
>
> Key: MSHARED-1285
> URL: https://issues.apache.org/jira/browse/MSHARED-1285
> Project: Maven Shared Components
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> The maven resources plugin uses
> [https://github.com/apache/maven-filtering/blob/master/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java]
> to copy resources, but that component has some subtile flaws reported here:
> [https://github.com/eclipse-m2e/m2e-core/discussions/1468]
> The problematic part is the usage of BuildContext#newScanner that already
> mentions in the javadoc that passing ignoreDelta to neScanner might not
> reveal all required items +*for copy-resources*+ form A -> B and instead
> BuildContext#isUpTodate should be used.
> Just from a quick look I assume that part of code actually wants to use
> something like this:
> {code:java}
> DirectoryScanner ds = new DirectoryScanner() {
> @Override
> protected boolean isSelected(String name, File file) {
> if (file.isFile() && buildContext.isUptodate(getTargetFile(file), file))
> {
> return false;
> }
> return true;
> }
> };
> ds.setBasedir(basedir); {code}
> That way all the code that currently checks for if output directory existed
> before can also be removed what is another issue because it leads to a full
> resources copy even if source+target are already even if a single class file
> is changed while the idea seems more that if the output was not there it
> should not try to be incremental!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-1285] use an up-to-date scanner instead the newscanner [maven-filtering]
laeubi commented on PR #77: URL: https://github.com/apache/maven-filtering/pull/77#issuecomment-1831210021 @lalmeras many many thanks for looking into the test! > So the issue for this test failure is in TestIncrementalBuildContext (org.sonatype.plexus:plexus-build-api:tests). Not sure how to handle this. This is actually deprecated/removed in later versions exactly because no one can know what the test wants to assert... so the best would be to simply copy it in the plugin here and adjust as needed, or even better using a mock. -- 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] (MNG-7949) Dependency management import should support explicit inclusion
[
https://issues.apache.org/jira/browse/MNG-7949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Maxwell updated MNG-7949:
--
Description:
There are many cases where a project will publish a bom that has a mix of that
project's artifacts and 3rd party ones.
While the exclusion feature is an improvement in scenarios where one wants to
limit the dependencies to just those owned by the project the exclusion list
can be quite large and would require updating whenever the project adds another
3rd party dependency.
Explicit inclusions would avoid both of those issues.
Example:
Suppose we wanted to exclude all non-spring dependencies from
{{org.springframework.boot:spring-boot-dependencies}} with {{exclusions}} a
reasonable attempt, one that would retain clarity, would take 172 lines with
{{includes}} it would take 12.
{code:java}
org.springframework.boot
spring-boot-dependencies
${spring-boot.version}
pom
import
ch*
co*
io.*
jakarta*
javax*
jaxen*
junit*
net*
nz*
org.apache*
org.aspectj*
org.assertj*
org.awaitility*
org.cache2k*
org.codehaus.janino*
org.crac*
org.eclipse*
org.ehcache*
org.elasticsearch.client*
org.firebirdsql.jdbc*
org.flywaydb*
org.freemarker*
org.glassfish*
org.hamcrest*
org.hibernate*
org.hsqldb*
org.infinispan*
org.influxdb*
org.jboss.logging*
org.jdom*
org.jetbrains*
org.jooq*
org.junit*
org.liquibase*
org.mariadb*
org.messaginghub*
org.mockito*
org.mongodb*
org.neo4j.driver*
org.postgresql*
org.projectlombok*
org.quartz-scheduler*
org.reactivestreams*
org.seleniumhq.selenium*
org.skyscreamer*
org.slf4j*
org.testcontainers*
org.thymeleaf*
org.webjars*
org.xerial*
org.xmlunit*
org.yaml*
redis.clients*
wsdl4j*
{code}
vs:
{code:java}
org.springframework.boot
spring-boot-dependencies
${spring-boot.version}
pom
import
org.springframework*
{code}
was:
There are many cases where a project will publish a bom that has a mix of that
project's artifacts and 3rd party ones.
While the exclusion feature is an improvement in scenarios where one wants to
limit the dependencies to just those owned by the project the exclusion list
can be quite large and would require updating whenever the project adds another
3rd party dependency.
Example:
Suppose we wanted to exclude all non-spring dependencies from
{{org.springframework.boot:spring-boot-dependencies}} with {{exclusions}} a
reasonable attempt, one that would retain clarity, would take 172 lines with
{{includes}} it would take 12.
{code:java}
org.springframework.boot
spring-boot-dependencies
${spring-boot.version}
pom
import
ch*
co*
io.*
jakarta*
javax*
jaxen*
junit*
net*
[jira] [Created] (MNG-7949) Dependency management import should support explicit inclusion
Jeff Maxwell created MNG-7949:
-
Summary: Dependency management import should support explicit
inclusion
Key: MNG-7949
URL: https://issues.apache.org/jira/browse/MNG-7949
Project: Maven
Issue Type: Improvement
Components: Dependencies
Reporter: Jeff Maxwell
There are many cases where a project will publish a bom that has a mix of that
project's artifacts and 3rd party ones.
While the exclusion feature is an improvement in scenarios where one wants to
limit the dependencies to just those owned by the project the exclusion list
can be quite large and would require updating whenever the project adds another
3rd party dependency.
Example:
Suppose we wanted to exclude all non-spring dependencies from
{{org.springframework.boot:spring-boot-dependencies}} with {{exclusions}} a
reasonable attempt, one that would retain clarity, would take 172 lines with
{{includes}} it would take 12.
{code:java}
org.springframework.boot
spring-boot-dependencies
${spring-boot.version}
pom
import
ch*
co*
io.*
jakarta*
javax*
jaxen*
junit*
net*
nz*
org.apache*
org.aspectj*
org.assertj*
org.awaitility*
org.cache2k*
org.codehaus.janino*
org.crac*
org.eclipse*
org.ehcache*
org.elasticsearch.client*
org.firebirdsql.jdbc*
org.flywaydb*
org.freemarker*
org.glassfish*
org.hamcrest*
org.hibernate*
org.hsqldb*
org.infinispan*
org.influxdb*
org.jboss.logging*
org.jdom*
org.jetbrains*
org.jooq*
org.junit*
org.liquibase*
org.mariadb*
org.messaginghub*
org.mockito*
org.mongodb*
org.neo4j.driver*
org.postgresql*
org.projectlombok*
org.quartz-scheduler*
org.reactivestreams*
org.seleniumhq.selenium*
org.skyscreamer*
org.slf4j*
org.testcontainers*
org.thymeleaf*
org.webjars*
org.xerial*
org.xmlunit*
org.yaml*
redis.clients*
wsdl4j*
{code}
vs:
{code:java}
org.springframework.boot
spring-boot-dependencies
${spring-boot.version}
pom
import
org.springframework*
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-803) Add file name mapping option when extracting dependencies
[
https://issues.apache.org/jira/browse/MASSEMBLY-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790818#comment-17790818
]
Vladimir I edited comment on MASSEMBLY-803 at 11/28/23 11:32 PM:
-
I've tried to play around with {{outputFileNameMapping}} but I couldn't get
much progress with it. Maybe you could explain what is supposed to be written
there?
Like in the case above the original file named as
{{apache-tomcat-9.0.82/bin/bootstrap.jar}} and I want to add it to assembly as
{{bin/bootstrap.jar}}.
The only possible way so far is to use \{{dependencies:unpack-dependencies /
fileMappers }} but it doesn't seem natural for solving a simple task.
Also as stated https://issues.apache.org/jira/browse/MASSEMBLY-312 this
attribute shouldn't be used with {{{}unpack=true{}}}.
https://issues.apache.org/jira/browse/MASSEMBLY-45 seems about the same as well.
was (Author: bade7n):
I've tried to play around with {{outputFileNameMapping}} but I couldn't get
much progress with it. Maybe you could explain what is supposed to be written
there?
Like in the case above original file named as
{{apache-tomcat-9.0.82/bin/bootstrap.jar}} I want to add it to assembly as
{{bin/bootstrap.jar}} as simple as that. I haven't found a way to
strip/rename/map folders.
The only possible way so far is to use \{{dependencies:unpack-dependencies /
fileMappers }} but it doesn't seem natural for solving a simple task.
Also as stated https://issues.apache.org/jira/browse/MASSEMBLY-312 this
attribute shouldn't be used with {{{}unpack=true{}}}.
https://issues.apache.org/jira/browse/MASSEMBLY-45 seems about the same as well.
> Add file name mapping option when extracting dependencies
> -
>
> Key: MASSEMBLY-803
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-803
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: dependencySet, moduleSet
>Reporter: Plamen Totev
>Priority: Minor
>
> Hi,
> Currently when using {{dependencySets}} with {{unpack}} set to {{true}},
> there is no way to set the output file names mapping. As plexus-io supports
> file names mapping, I think it will be relatively easy to add such option.
> Consider the following scenario. You want to distribute tomcat as part of
> your product. You could add something like that;
> {code:xml}
>
>
>
> org.apache.tomcat:tomcat:8.0.33:zip
>
> true
>
>
> {code}
> So far so good. But the zip archive contains {{apache-tomcat-8.0.33}} as root
> folder.What if I want to distribute it under {{tomcat}}? There is no
> way(AFAIK) to just extract sub folder of the archive. Of course there is
> {{}} tag but the matched files will be still under
> {{apache-tomcat-8.0.33/...}}
> The use of {{FileMapper}} for example may strip the root folder (the
> {{RegExpFileMapper}} seems like a perfect candidate).
> What do you think about such feature?
> p.s. Not quite sure where is the proper place to discuss such improvements
> requests - here or in the mailing list. So excuse me if this is not the
> proper place.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MASSEMBLY-803) Add file name mapping option when extracting dependencies
[
https://issues.apache.org/jira/browse/MASSEMBLY-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790818#comment-17790818
]
Vladimir I commented on MASSEMBLY-803:
--
I've tried to play around with {{outputFileNameMapping}} but I couldn't get
much progress with it. Maybe you could explain what is supposed to be written
there?
Like in the case above original file named as
{{apache-tomcat-9.0.82/bin/bootstrap.jar}} I want to add it to assembly as
{{bin/bootstrap.jar}} as simple as that. I haven't found a way to
strip/rename/map folders.
The only possible way so far is to use \{{dependencies:unpack-dependencies /
fileMappers }} but it doesn't seem natural for solving a simple task.
Also as stated https://issues.apache.org/jira/browse/MASSEMBLY-312 this
attribute shouldn't be used with {{{}unpack=true{}}}.
https://issues.apache.org/jira/browse/MASSEMBLY-45 seems about the same as well.
> Add file name mapping option when extracting dependencies
> -
>
> Key: MASSEMBLY-803
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-803
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: dependencySet, moduleSet
>Reporter: Plamen Totev
>Priority: Minor
>
> Hi,
> Currently when using {{dependencySets}} with {{unpack}} set to {{true}},
> there is no way to set the output file names mapping. As plexus-io supports
> file names mapping, I think it will be relatively easy to add such option.
> Consider the following scenario. You want to distribute tomcat as part of
> your product. You could add something like that;
> {code:xml}
>
>
>
> org.apache.tomcat:tomcat:8.0.33:zip
>
> true
>
>
> {code}
> So far so good. But the zip archive contains {{apache-tomcat-8.0.33}} as root
> folder.What if I want to distribute it under {{tomcat}}? There is no
> way(AFAIK) to just extract sub folder of the archive. Of course there is
> {{}} tag but the matched files will be still under
> {{apache-tomcat-8.0.33/...}}
> The use of {{FileMapper}} for example may strip the root folder (the
> {{RegExpFileMapper}} seems like a perfect candidate).
> What do you think about such feature?
> p.s. Not quite sure where is the proper place to discuss such improvements
> requests - here or in the mailing list. So excuse me if this is not the
> proper place.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [I] Failed to install artifact xxx [maven-mvnd]
harryssuperman commented on issue #862: URL: https://github.com/apache/maven-mvnd/issues/862#issuecomment-1830877324 Thank you very much @cstamas for the vote and the binaries. I've just installed it in our CI Windows Server. It seems running pretty fine now und all the builds for the CI are running fine. Dev Team will be really happy with it. Lets see also the nightly builds. Many thanks to all of you and the devteam and specially to @slawekjaranowski because the link to MRESOLVER-372 -- 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-1285) DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
[
https://issues.apache.org/jira/browse/MSHARED-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790787#comment-17790787
]
ASF GitHub Bot commented on MSHARED-1285:
-
lalmeras commented on PR #77:
URL: https://github.com/apache/maven-filtering/pull/77#issuecomment-1830852620
I dig into the test issue.
Test verifies the following behavior:
* two files with resource filtering are filtered; both files are copied to
target with `${time}` replaced by `time`
* one file is touched and an incremental build with time=notime is launched
* expected behavior is that only the touched file is updated; other file
keeps time value (instead of notime)
* after proposed fix, both files are processed
I think there is an issue with the test implementation.
`TestIncrementalBuildContext.isUptodate(File, File)` (that is called by custom
DirectoryScanner#isSelected, cf `buildContext.isUptodate(...)`) implementation
always return false, because `hasDelta(target)` always return true, because
hasDelta fails to resolve target path as a source path (cf getRelpath).
Not sure why, but the original code does not trigger
`TestIncrementalBuildContext.isUptodate()`. Other tests from project does not
call this method either.
So the issue for this test failure is in TestIncrementalBuildContext
(org.sonatype.plexus:plexus-build-api:tests). Not sure how to handle this.
> DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
> --
>
> Key: MSHARED-1285
> URL: https://issues.apache.org/jira/browse/MSHARED-1285
> Project: Maven Shared Components
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> The maven resources plugin uses
> [https://github.com/apache/maven-filtering/blob/master/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java]
> to copy resources, but that component has some subtile flaws reported here:
> [https://github.com/eclipse-m2e/m2e-core/discussions/1468]
> The problematic part is the usage of BuildContext#newScanner that already
> mentions in the javadoc that passing ignoreDelta to neScanner might not
> reveal all required items +*for copy-resources*+ form A -> B and instead
> BuildContext#isUpTodate should be used.
> Just from a quick look I assume that part of code actually wants to use
> something like this:
> {code:java}
> DirectoryScanner ds = new DirectoryScanner() {
> @Override
> protected boolean isSelected(String name, File file) {
> if (file.isFile() && buildContext.isUptodate(getTargetFile(file), file))
> {
> return false;
> }
> return true;
> }
> };
> ds.setBasedir(basedir); {code}
> That way all the code that currently checks for if output directory existed
> before can also be removed what is another issue because it leads to a full
> resources copy even if source+target are already even if a single class file
> is changed while the idea seems more that if the output was not there it
> should not try to be incremental!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-1285] use an up-to-date scanner instead the newscanner [maven-filtering]
lalmeras commented on PR #77:
URL: https://github.com/apache/maven-filtering/pull/77#issuecomment-1830852620
I dig into the test issue.
Test verifies the following behavior:
* two files with resource filtering are filtered; both files are copied to
target with `${time}` replaced by `time`
* one file is touched and an incremental build with time=notime is launched
* expected behavior is that only the touched file is updated; other file
keeps time value (instead of notime)
* after proposed fix, both files are processed
I think there is an issue with the test implementation.
`TestIncrementalBuildContext.isUptodate(File, File)` (that is called by custom
DirectoryScanner#isSelected, cf `buildContext.isUptodate(...)`) implementation
always return false, because `hasDelta(target)` always return true, because
hasDelta fails to resolve target path as a source path (cf getRelpath).
Not sure why, but the original code does not trigger
`TestIncrementalBuildContext.isUptodate()`. Other tests from project does not
call this method either.
So the issue for this test failure is in TestIncrementalBuildContext
(org.sonatype.plexus:plexus-build-api:tests). Not sure how to handle this.
--
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] [MJAVADOC-722] Log javadoc warnings and errors to file [maven-javadoc-plugin]
michael-o commented on PR #159: URL: https://github.com/apache/maven-javadoc-plugin/pull/159#issuecomment-1830747943 So I reviewed it again and still consider is as flawed. `@files` are pure input files to the Javadoc process, they have nothing in common with the output of the process. I still consider `errorFile` as the param to go. -- 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] (MJAVADOC-722) Allow Logging Javadoc Warnings and Errors to File
[ https://issues.apache.org/jira/browse/MJAVADOC-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790754#comment-17790754 ] ASF GitHub Bot commented on MJAVADOC-722: - michael-o commented on PR #159: URL: https://github.com/apache/maven-javadoc-plugin/pull/159#issuecomment-1830747943 So I reviewed it again and still consider is as flawed. `@files` are pure input files to the Javadoc process, they have nothing in common with the output of the process. I still consider `errorFile` as the param to go. > Allow Logging Javadoc Warnings and Errors to File > - > > Key: MJAVADOC-722 > URL: https://issues.apache.org/jira/browse/MJAVADOC-722 > Project: Maven Javadoc Plugin > Issue Type: New Feature > Components: javadoc >Reporter: Alan Zimmer >Priority: Trivial > > Allow for Javadoc generation, either implicitly or through a new > configuration, to generate a file containing the warnings and errors that > were found during Javadoc generation. Possibly following a similar pattern to > the argfile and options that are generated containing parameters passed to > Javadoc create an errors files that will be placed in the Javadoc output > folder that is ignored during Javadoc JAR creation. > > This change would allow for CI systems to run Javadoc builds in parallel > while still easily capturing any errors without the need for complex logging > systems and would strongly ensure that there is a unique error report for > each project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-739) Null pointer exception when executing javadoc:fix goal
[
https://issues.apache.org/jira/browse/MJAVADOC-739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790746#comment-17790746
]
Michael Osipov commented on MJAVADOC-739:
-
I get this one from master:
{noformat}
[INFO] OpenRefine - Wikibase extension SUCCESS [ 20.844 s]
[INFO] OpenRefine - Database extension FAILURE [ 28.740 s]
[INFO] OpenRefine - Gdata extension ... SKIPPED
[INFO] OpenRefine - PC-axis extension . SKIPPED
[INFO] OpenRefine - Phonetic clustering extension . SKIPPED
[INFO] OpenRefine - packaging . SKIPPED
[INFO] OpenRefine Java JMH benchmarks . SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 04:34 min
[INFO] Finished at: 2023-11-28T21:42:37+01:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.6.2:fix (default-cli) on
project database: Execution default-cli of goal
org.apache.maven.plugins:maven-javadoc-plugin:3.6.2:fix failed: A required
class was missing while executing
org.apache.maven.plugins:maven-javadoc-plugin:3.6.2:fix: java/sql/Connection
[ERROR] -
[ERROR] realm =plugin>org.apache.maven.plugins:maven-javadoc-plugin:3.6.2
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] =
file:/C:/Users/mosipov/.m2/repository/org/apache/maven/plugins/maven-javadoc-plugin/3.6.2/maven-javadoc-plugin-3.6.2.jar
[ERROR] urls[1] =
file:/C:/Users/mosipov/.m2/repository/org/apache/maven/reporting/maven-reporting-api/3.1.1/maven-reporting-api-3.1.1.jar
[ERROR] urls[2] =
file:/C:/Users/mosipov/.m2/repository/org/apache/maven/maven-archiver/3.6.0/maven-archiver-3.6.0.jar
[ERROR] urls[3] =
file:/C:/Users/mosipov/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.26/plexus-interpolation-1.26.jar
[ERROR] urls[4] =
file:/C:/Users/mosipov/.m2/repository/org/apache/maven/shared/maven-invoker/3.2.0/maven-invoker-3.2.0.jar
{noformat}
It makes no sense...
> Null pointer exception when executing javadoc:fix goal
> --
>
> Key: MJAVADOC-739
> URL: https://issues.apache.org/jira/browse/MJAVADOC-739
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.4.1
>Reporter: Antonin Delpeuch
>Priority: Major
> Labels: starter
>
> Running `mvn -e javadoc:fix` on my project, I get the following error:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:fix (default-cli) on
> project refine-model: Execution default-cli of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:fix failed.:
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:fix (default-cli) on
> project refine-model: Execution default-cli of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:fix failed.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at
[jira] [Commented] (MNG-7787) Introduce new options for plugin validation
[ https://issues.apache.org/jira/browse/MNG-7787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790743#comment-17790743 ] ASF GitHub Bot commented on MNG-7787: - slawekjaranowski commented on PR #1116: URL: https://github.com/apache/maven/pull/1116#issuecomment-1830689106 Issue is closed https://issues.apache.org/jira/browse/MNG-7787 @hgschmie - I hope this PR can also be closed. > Introduce new options for plugin validation > --- > > Key: MNG-7787 > URL: https://issues.apache.org/jira/browse/MNG-7787 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 3.9.2 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-7, 4.0.0 > > > Currently we offer following values for maven.plugin.validation: > * BRIEF - emits one liner WARN with count of plugins having validation > issues (IF count > 0) > * DEFAULT - emits one line for each plugin GAV having validation issues > * VERBOSE - emits detailed report for each plugin (declaration, use and > problems) for each plugin having validation issue > We should introduce more: > * NONE - mute validation (usable on CI where plethora of WARNING lines could > lead to falsely detect build as unhealthy) > * INLINE - produce validation WARNs inline, as 3.9.1 did > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7787] Introduce new options for plugin validation report [maven]
slawekjaranowski commented on PR #1116: URL: https://github.com/apache/maven/pull/1116#issuecomment-1830689106 Issue is closed https://issues.apache.org/jira/browse/MNG-7787 @hgschmie - I hope this PR can also be closed. -- 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] (DOXIASITETOOLS-320) Inconsistent anchors between toc macro and headers
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790738#comment-17790738
]
ASF GitHub Bot commented on DOXIASITETOOLS-320:
---
michael-o commented on code in PR #180:
URL: https://github.com/apache/maven-doxia/pull/180#discussion_r1408359647
##
doxia-core/src/main/java/org/apache/maven/doxia/macro/MacroRequest.java:
##
@@ -40,15 +40,23 @@ public class MacroRequest {
/** A map of parameters. */
private Map parameters;
+private final Parser currentParser;
/**
* Constructor for MacroRequest.
*
+ * @param currentParser a {@link org.apache.maven.doxia.parser.Parser}
object (which is the parser triggering this macro).
* @param sourceContent a {@link java.lang.String} object.
- * @param parser a {@link org.apache.maven.doxia.parser.AbstractParser}
object.
+ * @param parser a new {@link
org.apache.maven.doxia.parser.AbstractParser} object acting as secondary parser.
* @param param a {@link java.util.Map} object.
* @param basedir a {@link java.io.File} object.
*/
-public MacroRequest(String sourceContent, AbstractParser parser,
Map param, File basedir) {
+public MacroRequest(
+Parser currentParser,
Review Comment:
This is exactly the idea I had, but rejected it because the I consider a
macro something which should not push back, i.e., side effect free.
> Inconsistent anchors between toc macro and headers
> --
>
> Key: DOXIASITETOOLS-320
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-320
> Project: Maven Doxia Sitetools
> Issue Type: Bug
> Components: Site renderer
>Reporter: Slawomir Jaranowski
>Assignee: Konrad Windszus
>Priority: Critical
>
> In markdown document add:
> {code:java}
>
> {code}
> Then anchors generated by toc macro looks like: {{#Your_First_Mojo}}
> and anchors generated by skin looks like: {{#your-first-plugin}}
> - Doxia Site Renderer 2.0.0-M4
> - Fluido Skin 1.11.1
> Tested on Maven main site without more investigate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIASITETOOLS-320] Auto-generate anchor for TOC entries [maven-doxia]
michael-o commented on code in PR #180:
URL: https://github.com/apache/maven-doxia/pull/180#discussion_r1408359647
##
doxia-core/src/main/java/org/apache/maven/doxia/macro/MacroRequest.java:
##
@@ -40,15 +40,23 @@ public class MacroRequest {
/** A map of parameters. */
private Map parameters;
+private final Parser currentParser;
/**
* Constructor for MacroRequest.
*
+ * @param currentParser a {@link org.apache.maven.doxia.parser.Parser}
object (which is the parser triggering this macro).
* @param sourceContent a {@link java.lang.String} object.
- * @param parser a {@link org.apache.maven.doxia.parser.AbstractParser}
object.
+ * @param parser a new {@link
org.apache.maven.doxia.parser.AbstractParser} object acting as secondary parser.
* @param param a {@link java.util.Map} object.
* @param basedir a {@link java.io.File} object.
*/
-public MacroRequest(String sourceContent, AbstractParser parser,
Map param, File basedir) {
+public MacroRequest(
+Parser currentParser,
Review Comment:
This is exactly the idea I had, but rejected it because the I consider a
macro something which should not push back, i.e., side effect free.
--
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] (DOXIA-709) Clarify usage of overlapping Sink methods
[
https://issues.apache.org/jira/browse/DOXIA-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated DOXIA-709:
--
Description:
With Doxia 1.1 new methods have been added taking an additional
{{SinkEventAttributes}} parameter. Semantically there is now an overlap, e.g.
between {{Sink.sectionTitle1}} and {{Sink.sectionTitle(1, null)}}
It should be clear from the javadoc when which one is supposed to be called,
and also which one is the preferred method now.
E.g. in {{SinkAdapter}} all new Doxia 1.1 methods taking a
{{SinkEventAttributes}} just forward to the equivalent method not taking it.
OTOH {{Xhtml5BaseSink}} delegates the other way around (e.g. for
{{link(String)}}) or does not delegate at all (e.g. for {{sectionTitle(int,
SinkEventAttributes)}} and {{sectionTitle1()}}).
That leads to the fact that things are often not rendered consistently although
from their javadoc they should lead to the same result.
was:
With Doxia 1.1 new methods have been added taking an additional
{{SinkEventAttributes}} parameter. Semantically there is now an overlap, e.g.
between {{Sink.sectionTitle1}} and {{Sink.sectionTitle(1, null)}}
It should be clear from the javadoc when which one is supposed to be called,
and also which one is the preferred method now.
E.g. in {{SinkAdapter}} all new Doxia 1.1 methods taking a
{{SinkEventAttribute}} just forward to the equivalent method not taking it.
OTOH {{Xhtml5BaseSink}} delegates the other way around (e.g. for
{{link(String)}}) or does not delegate at all (e.g. for {{sectionTitle(int,
SinkEventAttributes)}} and {{sectionTitle1()}}).
That leads to the fact that things are often not rendered consistently although
from their javadoc they should lead to the same result.
> Clarify usage of overlapping Sink methods
> -
>
> Key: DOXIA-709
> URL: https://issues.apache.org/jira/browse/DOXIA-709
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Sink API
>Reporter: Konrad Windszus
>Priority: Major
>
> With Doxia 1.1 new methods have been added taking an additional
> {{SinkEventAttributes}} parameter. Semantically there is now an overlap, e.g.
> between {{Sink.sectionTitle1}} and {{Sink.sectionTitle(1, null)}}
> It should be clear from the javadoc when which one is supposed to be called,
> and also which one is the preferred method now.
> E.g. in {{SinkAdapter}} all new Doxia 1.1 methods taking a
> {{SinkEventAttributes}} just forward to the equivalent method not taking it.
> OTOH {{Xhtml5BaseSink}} delegates the other way around (e.g. for
> {{link(String)}}) or does not delegate at all (e.g. for {{sectionTitle(int,
> SinkEventAttributes)}} and {{sectionTitle1()}}).
> That leads to the fact that things are often not rendered consistently
> although from their javadoc they should lead to the same result.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (DOXIA-709) Clarify usage of overlapping Sink methods
Konrad Windszus created DOXIA-709:
-
Summary: Clarify usage of overlapping Sink methods
Key: DOXIA-709
URL: https://issues.apache.org/jira/browse/DOXIA-709
Project: Maven Doxia
Issue Type: Improvement
Components: Sink API
Reporter: Konrad Windszus
With Doxia 1.1 new methods have been added taking an additional
{{SinkEventAttributes}} parameter. Semantically there is now an overlap, e.g.
between {{Sink.sectionTitle1}} and {{Sink.sectionTitle(1, null)}}
It should be clear from the javadoc when which one is supposed to be called,
and also which one is the preferred method now.
E.g. in {{SinkAdapter}} all new Doxia 1.1 methods taking a
{{SinkEventAttribute}} just forward to the equivalent method not taking it.
OTOH {{Xhtml5BaseSink}} delegates the other way around (e.g. for
{{link(String)}}) or does not delegate at all (e.g. for {{sectionTitle(int,
SinkEventAttributes)}} and {{sectionTitle1()}}).
That leads to the fact that things are often not rendered consistently although
from their javadoc they should lead to the same result.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-320) Inconsistent anchors between toc macro and headers
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790728#comment-17790728
]
ASF GitHub Bot commented on DOXIASITETOOLS-320:
---
kwin opened a new pull request, #30:
URL: https://github.com/apache/maven-doxia-site/pull/30
of anchor names for TOC entries
> Inconsistent anchors between toc macro and headers
> --
>
> Key: DOXIASITETOOLS-320
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-320
> Project: Maven Doxia Sitetools
> Issue Type: Bug
> Components: Site renderer
>Reporter: Slawomir Jaranowski
>Assignee: Konrad Windszus
>Priority: Critical
>
> In markdown document add:
> {code:java}
>
> {code}
> Then anchors generated by toc macro looks like: {{#Your_First_Mojo}}
> and anchors generated by skin looks like: {{#your-first-plugin}}
> - Doxia Site Renderer 2.0.0-M4
> - Fluido Skin 1.11.1
> Tested on Maven main site without more investigate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [DOXIASITETOOLS-320] Document Sink wrappers and the automatic generation [maven-doxia-site]
kwin opened a new pull request, #30: URL: https://github.com/apache/maven-doxia-site/pull/30 of anchor names for TOC entries -- 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] (MNG-7948) Upgrade to Resolver 2.0.0-alpha-3
[ https://issues.apache.org/jira/browse/MNG-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MNG-7948: Assignee: Tamas Cservenak > Upgrade to Resolver 2.0.0-alpha-3 > - > > Key: MNG-7948 > URL: https://issues.apache.org/jira/browse/MNG-7948 > Project: Maven > Issue Type: Dependency upgrade > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-9 > > > Upgrade to alpha-3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-7946) Undo JDK transport related changes once on alpha-3
[ https://issues.apache.org/jira/browse/MNG-7946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MNG-7946: Assignee: Tamas Cservenak > Undo JDK transport related changes once on alpha-3 > -- > > Key: MNG-7946 > URL: https://issues.apache.org/jira/browse/MNG-7946 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-9 > > > When we switched to Resolver 2 alpha, the JDK transport caused changes in > some ITs due changed error message. MRESOLVER-429 fixes that, will be in > alpha-3. > Once we are on alpha-3, this IT change should be undone: > https://github.com/apache/maven-integration-testing/commit/53d7ae5492ef58cf5a43c3cfa421e6457b5f6f9d -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7948) Upgrade to Resolver 2.0.0-alpha-3
[ https://issues.apache.org/jira/browse/MNG-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7948: - Fix Version/s: 4.0.0 > Upgrade to Resolver 2.0.0-alpha-3 > - > > Key: MNG-7948 > URL: https://issues.apache.org/jira/browse/MNG-7948 > Project: Maven > Issue Type: Dependency upgrade > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-9 > > > Upgrade to alpha-3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Preparations for resolver alpha-3 [maven]
cstamas commented on PR #1328: URL: https://github.com/apache/maven/pull/1328#issuecomment-1830418033 Now I failed intentionally this build: it uses 2.0.0-alpha-3. Once it lands in central, dance starts... -- 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] (MNG-7948) Upgrade to Resolver 2.0.0-alpha-3
Tamas Cservenak created MNG-7948: Summary: Upgrade to Resolver 2.0.0-alpha-3 Key: MNG-7948 URL: https://issues.apache.org/jira/browse/MNG-7948 Project: Maven Issue Type: Dependency upgrade Components: Artifacts and Repositories Reporter: Tamas Cservenak Fix For: 4.0.0-alpha-9 Upgrade to alpha-3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7924) Better control over and better integration with Resolver
[ https://issues.apache.org/jira/browse/MNG-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MNG-7924. Resolution: Fixed > Better control over and better integration with Resolver > > > Key: MNG-7924 > URL: https://issues.apache.org/jira/browse/MNG-7924 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0-alpha-9 > > > Integrate better and obtain better control over Resolver. These changes did > stem from "[JPMS module > experiment|https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support]; > and are considered improvement but *does not implement any functionality* > related to JPMS module support. > Changes: > * Maven4 should stop "disconnected coexistence" of two type systems > (ArtifactHandlers and Resolver ArtifactTypeRegistry), it should unify them. > * Maven4 Core should provide generic and extensible means to introduce new > artifact types (fully in extension, and extension should get extended data > via "roundtrip" in core/resolver) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-7924) Better control over and better integration with Resolver
[ https://issues.apache.org/jira/browse/MNG-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MNG-7924: Assignee: Tamas Cservenak > Better control over and better integration with Resolver > > > Key: MNG-7924 > URL: https://issues.apache.org/jira/browse/MNG-7924 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0-alpha-9 > > > Integrate better and obtain better control over Resolver. These changes did > stem from "[JPMS module > experiment|https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support]; > and are considered improvement but *does not implement any functionality* > related to JPMS module support. > Changes: > * Maven4 should stop "disconnected coexistence" of two type systems > (ArtifactHandlers and Resolver ArtifactTypeRegistry), it should unify them. > * Maven4 Core should provide generic and extensible means to introduce new > artifact types (fully in extension, and extension should get extended data > via "roundtrip" in core/resolver) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-320) Inconsistent anchors between toc macro and headers
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790700#comment-17790700
]
ASF GitHub Bot commented on DOXIASITETOOLS-320:
---
kwin commented on code in PR #180:
URL: https://github.com/apache/maven-doxia/pull/180#discussion_r1408134053
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/NamesForIndexEntriesSinkWrapper.java:
##
@@ -0,0 +1,136 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.doxia.sink.impl;
+
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.maven.doxia.index.IndexEntry;
+import org.apache.maven.doxia.index.SectionLocation;
+import org.apache.maven.doxia.macro.toc.TocMacro;
+import org.apache.maven.doxia.parser.SinkWrapper;
+import org.apache.maven.doxia.sink.Sink;
+import org.apache.maven.doxia.sink.SinkEventAttributes;
+
+/**
+ * Sink wrapper which emits anchors for each section represented by the given
{@link IndexEntry}.
+ * @see TocMacro
+ */
+public class NamesForIndexEntriesSinkWrapper extends SinkWrapper {
+
+private final Map entryByLocation;
+private SectionLocation currentLocation;
+
+public NamesForIndexEntriesSinkWrapper(Sink delegate, IndexEntry index) {
+super(delegate);
+entryByLocation = new HashMap<>();
+populateMap(entryByLocation, index);
+this.currentLocation = new SectionLocation();
+}
+
+private static void populateMap(Map
entryByLocation, IndexEntry entry) {
+entryByLocation.put(entry.getLocation(), entry);
+entry.getChildEntries().forEach(e -> populateMap(entryByLocation, e));
+}
+
+@Override
+public void section(int level, SinkEventAttributes attributes) {
+onStartSection(level);
+super.section(level, attributes);
+}
+
+@Override
+public void section_(int level) {
+super.section_(level);
+onEndSection();
+}
+
+@Override
+public void section1() {
+super.section1();
+onStartSection(1);
+}
+
+@Override
+public void section1_() {
+super.section1_();
+onEndSection();
+}
+
+@Override
+public void section2() {
+super.section2();
+onStartSection(2);
+}
+
+@Override
+public void section2_() {
+super.section2_();
+onEndSection();
+}
+
+@Override
+public void section3() {
+super.section3();
+onStartSection(3);
+}
+
+@Override
+public void section3_() {
+super.section3_();
+onEndSection();
+}
+
+@Override
+public void section4() {
+super.section4();
+onStartSection(4);
+}
+
+@Override
+public void section4_() {
+super.section4_();
+onEndSection();
+}
+
+@Override
+public void section5() {
+super.section5();
+onStartSection(5);
+}
+
+@Override
+public void section5_() {
+super.section5_();
+onEndSection();
+}
+
+private void onStartSection(int level) {
+currentLocation = currentLocation.createChildSection(level);
+IndexEntry entry = entryByLocation.get(currentLocation);
+if (entry != null) {
Review Comment:
Probably a guard similar to
https://github.com/apache/maven-doxia-sitetools/pull/58/files#diff-dabe16ceeba5dc7cb0a15e30dcb7c204a78f4763346f016ab7639ab2f59e78d4L250
needs to be introduced to at least prevent double anchors for APT format.
> Inconsistent anchors between toc macro and headers
> --
>
> Key: DOXIASITETOOLS-320
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-320
> Project: Maven Doxia Sitetools
> Issue Type: Bug
> Components: Site renderer
>Reporter: Slawomir Jaranowski
>Assignee: Konrad Windszus
>Priority: Critical
>
> In markdown document add:
> {code:java}
>
> {code}
> Then anchors generated by toc macro looks like: {{#Your_First_Mojo}}
> and anchors generated by skin looks like:
Re: [PR] [DOXIASITETOOLS-320] Auto-generate anchor for TOC entries [maven-doxia]
kwin commented on code in PR #180:
URL: https://github.com/apache/maven-doxia/pull/180#discussion_r1408134053
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/NamesForIndexEntriesSinkWrapper.java:
##
@@ -0,0 +1,136 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.doxia.sink.impl;
+
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.maven.doxia.index.IndexEntry;
+import org.apache.maven.doxia.index.SectionLocation;
+import org.apache.maven.doxia.macro.toc.TocMacro;
+import org.apache.maven.doxia.parser.SinkWrapper;
+import org.apache.maven.doxia.sink.Sink;
+import org.apache.maven.doxia.sink.SinkEventAttributes;
+
+/**
+ * Sink wrapper which emits anchors for each section represented by the given
{@link IndexEntry}.
+ * @see TocMacro
+ */
+public class NamesForIndexEntriesSinkWrapper extends SinkWrapper {
+
+private final Map entryByLocation;
+private SectionLocation currentLocation;
+
+public NamesForIndexEntriesSinkWrapper(Sink delegate, IndexEntry index) {
+super(delegate);
+entryByLocation = new HashMap<>();
+populateMap(entryByLocation, index);
+this.currentLocation = new SectionLocation();
+}
+
+private static void populateMap(Map
entryByLocation, IndexEntry entry) {
+entryByLocation.put(entry.getLocation(), entry);
+entry.getChildEntries().forEach(e -> populateMap(entryByLocation, e));
+}
+
+@Override
+public void section(int level, SinkEventAttributes attributes) {
+onStartSection(level);
+super.section(level, attributes);
+}
+
+@Override
+public void section_(int level) {
+super.section_(level);
+onEndSection();
+}
+
+@Override
+public void section1() {
+super.section1();
+onStartSection(1);
+}
+
+@Override
+public void section1_() {
+super.section1_();
+onEndSection();
+}
+
+@Override
+public void section2() {
+super.section2();
+onStartSection(2);
+}
+
+@Override
+public void section2_() {
+super.section2_();
+onEndSection();
+}
+
+@Override
+public void section3() {
+super.section3();
+onStartSection(3);
+}
+
+@Override
+public void section3_() {
+super.section3_();
+onEndSection();
+}
+
+@Override
+public void section4() {
+super.section4();
+onStartSection(4);
+}
+
+@Override
+public void section4_() {
+super.section4_();
+onEndSection();
+}
+
+@Override
+public void section5() {
+super.section5();
+onStartSection(5);
+}
+
+@Override
+public void section5_() {
+super.section5_();
+onEndSection();
+}
+
+private void onStartSection(int level) {
+currentLocation = currentLocation.createChildSection(level);
+IndexEntry entry = entryByLocation.get(currentLocation);
+if (entry != null) {
Review Comment:
Probably a guard similar to
https://github.com/apache/maven-doxia-sitetools/pull/58/files#diff-dabe16ceeba5dc7cb0a15e30dcb7c204a78f4763346f016ab7639ab2f59e78d4L250
needs to be introduced to at least prevent double anchors for APT format.
--
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] Upgrade to Maven 4.0.0-alpha-9 [maven-plugin-testing]
gnodet opened a new pull request, #39: URL: https://github.com/apache/maven-plugin-testing/pull/39 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7920) Usage of packaging BOM fails in maven-install-plugin
[
https://issues.apache.org/jira/browse/MNG-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790685#comment-17790685
]
ASF GitHub Bot commented on MNG-7920:
-
gnodet commented on PR #1305:
URL: https://github.com/apache/maven/pull/1305#issuecomment-1830332653
> > This will conflict with #1323 ...
>
> @gnodet I think you can deal with #1323 first. I'll deal with the conflict
when merging #1323.
@CrazyHZM #1323 has been merged now.
> Usage of packaging BOM fails in maven-install-plugin
>
>
> Key: MNG-7920
> URL: https://issues.apache.org/jira/browse/MNG-7920
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 4.0.0-alpha-8
>Reporter: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 4.0.0, 4.0.0-alpha-9
>
>
> Using to use the {{bom}} packaging in a module it will fail with:
> {code}
> [INFO]
> --
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install (default-install)
> on project bom: The packaging plugin for this project did not assign a main
> file to the project but it has attachments. Change packaging to 'pom'. ->
> [Help 1]
> {code}
> The bom module looks like this:
> {code:xml}
>xmlns="http://maven.apache.org/POM/4.1.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.1.0
> http://maven.apache.org/maven-v4_1_0.xsd;>
> 4.1.0
>
> maven4
> bom-example
>
> bom
> bom
>
>
>
> ...maven4
> mod-1
>
>
> maven4
> mod-2
>
>
>
>
> {code}
> I would assume that I need to upgrade the maven-install-plugin which is
> capable of handling that...but I assumed that this conversion is done by core?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7920] Fix usage of packaging BOM fails in maven-install-plugin [maven]
gnodet commented on PR #1305: URL: https://github.com/apache/maven/pull/1305#issuecomment-1830332653 > > This will conflict with #1323 ... > > @gnodet I think you can deal with #1323 first. I'll deal with the conflict when merging #1323. @CrazyHZM #1323 has been merged now. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MNG-7945] Fix profile settings being injected into consumer POM [maven]
gnodet merged PR #1323: URL: https://github.com/apache/maven/pull/1323 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MNG-7945) Fix profile settings being injected into consumer POMs
[ https://issues.apache.org/jira/browse/MNG-7945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-7945. Resolution: Fixed > Fix profile settings being injected into consumer POMs > -- > > Key: MNG-7945 > URL: https://issues.apache.org/jira/browse/MNG-7945 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-alpha-8 >Reporter: Tamas Cservenak >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-9 > > > The consumer POMs may end up containing information from user settings. > The reason is that they are currently built from the effective POMs. They > need to be rebuilt based on raw models. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7945) Fix profile settings being injected into consumer POMs
[ https://issues.apache.org/jira/browse/MNG-7945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790684#comment-17790684 ] ASF GitHub Bot commented on MNG-7945: - gnodet merged PR #1323: URL: https://github.com/apache/maven/pull/1323 > Fix profile settings being injected into consumer POMs > -- > > Key: MNG-7945 > URL: https://issues.apache.org/jira/browse/MNG-7945 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-alpha-8 >Reporter: Tamas Cservenak >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-9 > > > The consumer POMs may end up containing information from user settings. > The reason is that they are currently built from the effective POMs. They > need to be rebuilt based on raw models. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-320) Inconsistent anchors between toc macro and headers
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790677#comment-17790677
]
ASF GitHub Bot commented on DOXIASITETOOLS-320:
---
kwin opened a new pull request, #180:
URL: https://github.com/apache/maven-doxia/pull/180
Introduce SinkWrapper concept
Enforce anchor name uniqueness across documents
> Inconsistent anchors between toc macro and headers
> --
>
> Key: DOXIASITETOOLS-320
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-320
> Project: Maven Doxia Sitetools
> Issue Type: Bug
> Components: Site renderer
>Reporter: Slawomir Jaranowski
>Assignee: Konrad Windszus
>Priority: Critical
>
> In markdown document add:
> {code:java}
>
> {code}
> Then anchors generated by toc macro looks like: {{#Your_First_Mojo}}
> and anchors generated by skin looks like: {{#your-first-plugin}}
> - Doxia Site Renderer 2.0.0-M4
> - Fluido Skin 1.11.1
> Tested on Maven main site without more investigate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (DOXIASITETOOLS-320) Inconsistent anchors between toc macro and headers
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned DOXIASITETOOLS-320:
--
Assignee: Konrad Windszus
> Inconsistent anchors between toc macro and headers
> --
>
> Key: DOXIASITETOOLS-320
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-320
> Project: Maven Doxia Sitetools
> Issue Type: Bug
> Components: Site renderer
>Reporter: Slawomir Jaranowski
>Assignee: Konrad Windszus
>Priority: Critical
>
> In markdown document add:
> {code:java}
>
> {code}
> Then anchors generated by toc macro looks like: {{#Your_First_Mojo}}
> and anchors generated by skin looks like: {{#your-first-plugin}}
> - Doxia Site Renderer 2.0.0-M4
> - Fluido Skin 1.11.1
> Tested on Maven main site without more investigate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7945) Fix profile settings being injected into consumer POMs
[
https://issues.apache.org/jira/browse/MNG-7945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790669#comment-17790669
]
ASF GitHub Bot commented on MNG-7945:
-
gnodet commented on code in PR #1323:
URL: https://github.com/apache/maven/pull/1323#discussion_r1408081356
##
maven-core/src/main/java/org/apache/maven/internal/transformation/impl/TransformedArtifact.java:
##
@@ -0,0 +1,148 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.internal.transformation.impl;
+
+import javax.xml.stream.XMLStreamException;
+
+import java.io.File;
+import java.io.IOException;
+import java.io.InputStream;
+import java.nio.file.Files;
+import java.nio.file.Path;
+import java.security.MessageDigest;
+import java.security.NoSuchAlgorithmException;
+import java.util.Objects;
+import java.util.concurrent.atomic.AtomicReference;
+import java.util.function.Supplier;
+
+import org.apache.maven.artifact.DefaultArtifact;
+import org.apache.maven.internal.transformation.TransformationFailedException;
+import org.apache.maven.model.building.ModelBuildingException;
+import org.apache.maven.project.MavenProject;
+import
org.codehaus.plexus.component.repository.exception.ComponentLookupException;
+import org.eclipse.aether.RepositorySystemSession;
+
+/**
+ * Transformed artifact is derived with some transformation from source
artifact.
+ *
+ * @since TBD
+ */
+class TransformedArtifact extends DefaultArtifact {
+
+private static final int SHA1_BUFFER_SIZE = 8192;
+private final DefaultConsumerPomArtifactTransformer
defaultConsumerPomArtifactTransformer;
+private final MavenProject project;
+private final Supplier sourcePathProvider;
+private final Path target;
+private final RepositorySystemSession session;
+private final AtomicReference sourceState;
+
+TransformedArtifact(
+DefaultConsumerPomArtifactTransformer
defaultConsumerPomArtifactTransformer,
+MavenProject project,
+Path target,
+RepositorySystemSession session,
+org.apache.maven.artifact.Artifact source,
+Supplier sourcePathProvider,
+String classifier,
+String extension) {
+super(
+source.getGroupId(),
+source.getArtifactId(),
+source.getVersionRange(),
+source.getScope(),
+extension,
+classifier,
+new TransformedArtifactHandler(
+classifier, extension,
source.getArtifactHandler().getPackaging()));
+this.defaultConsumerPomArtifactTransformer =
defaultConsumerPomArtifactTransformer;
+this.project = project;
+this.target = target;
+this.session = session;
+this.sourcePathProvider = sourcePathProvider;
+this.sourceState = new AtomicReference<>(null);
+}
+
+@Override
+public boolean isResolved() {
+return getFile() != null;
+}
+
+@Override
+public void setFile(File file) {
+throw new IllegalStateException("transformed artifact file cannot be
set");
Review Comment:
Fixed the exception thrown.
> Fix profile settings being injected into consumer POMs
> --
>
> Key: MNG-7945
> URL: https://issues.apache.org/jira/browse/MNG-7945
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-8
>Reporter: Tamas Cservenak
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> The consumer POMs may end up containing information from user settings.
> The reason is that they are currently built from the effective POMs. They
> need to be rebuilt based on raw models.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7945) Fix profile settings being injected into consumer POMs
[ https://issues.apache.org/jira/browse/MNG-7945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790670#comment-17790670 ] ASF GitHub Bot commented on MNG-7945: - gnodet commented on PR #1323: URL: https://github.com/apache/maven/pull/1323#issuecomment-1830288831 > > I am blocked by this, so can this be soon merged please? @elharo any counter arguments? > > Counter-arguments to what claim? The use of exceptions in this PR does not align with Java standard practices. I don't think that's changed yet. I've done a big refactoring of the package yesterday evening. Please have a look at the latest code. > Fix profile settings being injected into consumer POMs > -- > > Key: MNG-7945 > URL: https://issues.apache.org/jira/browse/MNG-7945 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-alpha-8 >Reporter: Tamas Cservenak >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-9 > > > The consumer POMs may end up containing information from user settings. > The reason is that they are currently built from the effective POMs. They > need to be rebuilt based on raw models. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7945] Fix profile settings being injected into consumer POM [maven]
gnodet commented on PR #1323: URL: https://github.com/apache/maven/pull/1323#issuecomment-1830288831 > > I am blocked by this, so can this be soon merged please? @elharo any counter arguments? > > Counter-arguments to what claim? The use of exceptions in this PR does not align with Java standard practices. I don't think that's changed yet. I've done a big refactoring of the package yesterday evening. Please have a look at the latest code. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MNG-7945] Fix profile settings being injected into consumer POM [maven]
gnodet commented on code in PR #1323:
URL: https://github.com/apache/maven/pull/1323#discussion_r1408081356
##
maven-core/src/main/java/org/apache/maven/internal/transformation/impl/TransformedArtifact.java:
##
@@ -0,0 +1,148 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.internal.transformation.impl;
+
+import javax.xml.stream.XMLStreamException;
+
+import java.io.File;
+import java.io.IOException;
+import java.io.InputStream;
+import java.nio.file.Files;
+import java.nio.file.Path;
+import java.security.MessageDigest;
+import java.security.NoSuchAlgorithmException;
+import java.util.Objects;
+import java.util.concurrent.atomic.AtomicReference;
+import java.util.function.Supplier;
+
+import org.apache.maven.artifact.DefaultArtifact;
+import org.apache.maven.internal.transformation.TransformationFailedException;
+import org.apache.maven.model.building.ModelBuildingException;
+import org.apache.maven.project.MavenProject;
+import
org.codehaus.plexus.component.repository.exception.ComponentLookupException;
+import org.eclipse.aether.RepositorySystemSession;
+
+/**
+ * Transformed artifact is derived with some transformation from source
artifact.
+ *
+ * @since TBD
+ */
+class TransformedArtifact extends DefaultArtifact {
+
+private static final int SHA1_BUFFER_SIZE = 8192;
+private final DefaultConsumerPomArtifactTransformer
defaultConsumerPomArtifactTransformer;
+private final MavenProject project;
+private final Supplier sourcePathProvider;
+private final Path target;
+private final RepositorySystemSession session;
+private final AtomicReference sourceState;
+
+TransformedArtifact(
+DefaultConsumerPomArtifactTransformer
defaultConsumerPomArtifactTransformer,
+MavenProject project,
+Path target,
+RepositorySystemSession session,
+org.apache.maven.artifact.Artifact source,
+Supplier sourcePathProvider,
+String classifier,
+String extension) {
+super(
+source.getGroupId(),
+source.getArtifactId(),
+source.getVersionRange(),
+source.getScope(),
+extension,
+classifier,
+new TransformedArtifactHandler(
+classifier, extension,
source.getArtifactHandler().getPackaging()));
+this.defaultConsumerPomArtifactTransformer =
defaultConsumerPomArtifactTransformer;
+this.project = project;
+this.target = target;
+this.session = session;
+this.sourcePathProvider = sourcePathProvider;
+this.sourceState = new AtomicReference<>(null);
+}
+
+@Override
+public boolean isResolved() {
+return getFile() != null;
+}
+
+@Override
+public void setFile(File file) {
+throw new IllegalStateException("transformed artifact file cannot be
set");
Review Comment:
Fixed the exception thrown.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7945) Fix profile settings being injected into consumer POMs
[
https://issues.apache.org/jira/browse/MNG-7945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790667#comment-17790667
]
ASF GitHub Bot commented on MNG-7945:
-
gnodet commented on code in PR #1323:
URL: https://github.com/apache/maven/pull/1323#discussion_r1408080323
##
maven-core/src/main/java/org/apache/maven/internal/transformation/TransformedArtifact.java:
##
@@ -38,7 +38,11 @@
*/
abstract class TransformedArtifact extends DefaultArtifact {
-private final OnChangeTransformer onChangeTransformer;
+interface Transformer {
+Path transform() throws Exception;
Review Comment:
You're looking at old code. I've removed `throws Exception` clauses from
this package.
> Fix profile settings being injected into consumer POMs
> --
>
> Key: MNG-7945
> URL: https://issues.apache.org/jira/browse/MNG-7945
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-8
>Reporter: Tamas Cservenak
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> The consumer POMs may end up containing information from user settings.
> The reason is that they are currently built from the effective POMs. They
> need to be rebuilt based on raw models.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7945) Fix profile settings being injected into consumer POMs
[
https://issues.apache.org/jira/browse/MNG-7945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790668#comment-17790668
]
ASF GitHub Bot commented on MNG-7945:
-
gnodet commented on code in PR #1323:
URL: https://github.com/apache/maven/pull/1323#discussion_r1408080921
##
maven-core/src/main/java/org/apache/maven/internal/transformation/impl/DefaultConsumerPomBuilder.java:
##
@@ -0,0 +1,230 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.internal.transformation.impl;
+
+import javax.inject.Inject;
+import javax.inject.Named;
+
+import java.nio.file.Path;
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.List;
+import java.util.Map;
+import java.util.Properties;
+import java.util.stream.Collectors;
+
+import org.apache.maven.api.model.DistributionManagement;
+import org.apache.maven.api.model.Model;
+import org.apache.maven.api.model.ModelBase;
+import org.apache.maven.api.model.Profile;
+import org.apache.maven.api.model.Repository;
+import org.apache.maven.model.building.DefaultModelBuilder;
+import org.apache.maven.model.building.DefaultModelBuilderFactory;
+import org.apache.maven.model.building.DefaultModelBuildingRequest;
+import org.apache.maven.model.building.ModelBuildingException;
+import org.apache.maven.model.building.ModelBuildingRequest;
+import org.apache.maven.model.building.ModelBuildingResult;
+import org.apache.maven.model.building.ModelProblemCollector;
+import org.apache.maven.model.building.ModelProcessor;
+import org.apache.maven.model.composition.DependencyManagementImporter;
+import org.apache.maven.model.inheritance.InheritanceAssembler;
+import org.apache.maven.model.interpolation.ModelInterpolator;
+import org.apache.maven.model.management.DependencyManagementInjector;
+import org.apache.maven.model.management.PluginManagementInjector;
+import org.apache.maven.model.normalization.ModelNormalizer;
+import org.apache.maven.model.path.ModelPathTranslator;
+import org.apache.maven.model.path.ModelUrlNormalizer;
+import org.apache.maven.model.plugin.LifecycleBindingsInjector;
+import org.apache.maven.model.plugin.PluginConfigurationExpander;
+import org.apache.maven.model.plugin.ReportConfigurationExpander;
+import org.apache.maven.model.profile.DefaultProfileSelector;
+import org.apache.maven.model.profile.ProfileActivationContext;
+import org.apache.maven.model.profile.ProfileInjector;
+import org.apache.maven.model.profile.ProfileSelector;
+import org.apache.maven.model.superpom.SuperPomProvider;
+import org.apache.maven.model.v4.MavenModelVersion;
+import org.apache.maven.model.validation.ModelValidator;
+import org.apache.maven.project.MavenProject;
+import org.apache.maven.project.ProjectBuildingRequest;
+import org.apache.maven.project.ProjectModelResolver;
+import org.apache.maven.repository.internal.ModelCacheFactory;
+import org.codehaus.plexus.PlexusContainer;
+import
org.codehaus.plexus.component.repository.exception.ComponentLookupException;
+import org.eclipse.aether.RepositorySystem;
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.RequestTrace;
+import org.eclipse.aether.impl.RemoteRepositoryManager;
+
+@Named
+class DefaultConsumerPomBuilder implements ConsumerPomBuilder {
+
+private static final String BOM_PACKAGING = "bom";
+
+public static final String POM_PACKAGING = "pom";
+
+@Inject
+PlexusContainer container;
+
+@Inject
+ModelCacheFactory modelCacheFactory;
+
+public Model build(RepositorySystemSession session, MavenProject project,
Path src)
+throws ModelBuildingException, ComponentLookupException {
+Model model = project.getModel().getDelegate();
+String packaging = model.getPackaging();
+if (POM_PACKAGING.equals(packaging)) {
+return buildPom(session, project, src);
+} else {
+return buildNonPom(session, project, src);
+}
+}
+
+protected Model buildPom(RepositorySystemSession session, MavenProject
project, Path src)
+throws ModelBuildingException, ComponentLookupException {
+
Re: [PR] [MNG-7945] Fix profile settings being injected into consumer POM [maven]
gnodet commented on code in PR #1323:
URL: https://github.com/apache/maven/pull/1323#discussion_r1408080921
##
maven-core/src/main/java/org/apache/maven/internal/transformation/impl/DefaultConsumerPomBuilder.java:
##
@@ -0,0 +1,230 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.internal.transformation.impl;
+
+import javax.inject.Inject;
+import javax.inject.Named;
+
+import java.nio.file.Path;
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.List;
+import java.util.Map;
+import java.util.Properties;
+import java.util.stream.Collectors;
+
+import org.apache.maven.api.model.DistributionManagement;
+import org.apache.maven.api.model.Model;
+import org.apache.maven.api.model.ModelBase;
+import org.apache.maven.api.model.Profile;
+import org.apache.maven.api.model.Repository;
+import org.apache.maven.model.building.DefaultModelBuilder;
+import org.apache.maven.model.building.DefaultModelBuilderFactory;
+import org.apache.maven.model.building.DefaultModelBuildingRequest;
+import org.apache.maven.model.building.ModelBuildingException;
+import org.apache.maven.model.building.ModelBuildingRequest;
+import org.apache.maven.model.building.ModelBuildingResult;
+import org.apache.maven.model.building.ModelProblemCollector;
+import org.apache.maven.model.building.ModelProcessor;
+import org.apache.maven.model.composition.DependencyManagementImporter;
+import org.apache.maven.model.inheritance.InheritanceAssembler;
+import org.apache.maven.model.interpolation.ModelInterpolator;
+import org.apache.maven.model.management.DependencyManagementInjector;
+import org.apache.maven.model.management.PluginManagementInjector;
+import org.apache.maven.model.normalization.ModelNormalizer;
+import org.apache.maven.model.path.ModelPathTranslator;
+import org.apache.maven.model.path.ModelUrlNormalizer;
+import org.apache.maven.model.plugin.LifecycleBindingsInjector;
+import org.apache.maven.model.plugin.PluginConfigurationExpander;
+import org.apache.maven.model.plugin.ReportConfigurationExpander;
+import org.apache.maven.model.profile.DefaultProfileSelector;
+import org.apache.maven.model.profile.ProfileActivationContext;
+import org.apache.maven.model.profile.ProfileInjector;
+import org.apache.maven.model.profile.ProfileSelector;
+import org.apache.maven.model.superpom.SuperPomProvider;
+import org.apache.maven.model.v4.MavenModelVersion;
+import org.apache.maven.model.validation.ModelValidator;
+import org.apache.maven.project.MavenProject;
+import org.apache.maven.project.ProjectBuildingRequest;
+import org.apache.maven.project.ProjectModelResolver;
+import org.apache.maven.repository.internal.ModelCacheFactory;
+import org.codehaus.plexus.PlexusContainer;
+import
org.codehaus.plexus.component.repository.exception.ComponentLookupException;
+import org.eclipse.aether.RepositorySystem;
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.RequestTrace;
+import org.eclipse.aether.impl.RemoteRepositoryManager;
+
+@Named
+class DefaultConsumerPomBuilder implements ConsumerPomBuilder {
+
+private static final String BOM_PACKAGING = "bom";
+
+public static final String POM_PACKAGING = "pom";
+
+@Inject
+PlexusContainer container;
+
+@Inject
+ModelCacheFactory modelCacheFactory;
+
+public Model build(RepositorySystemSession session, MavenProject project,
Path src)
+throws ModelBuildingException, ComponentLookupException {
+Model model = project.getModel().getDelegate();
+String packaging = model.getPackaging();
+if (POM_PACKAGING.equals(packaging)) {
+return buildPom(session, project, src);
+} else {
+return buildNonPom(session, project, src);
+}
+}
+
+protected Model buildPom(RepositorySystemSession session, MavenProject
project, Path src)
+throws ModelBuildingException, ComponentLookupException {
+ModelBuildingResult result = buildModel(session, project, src);
+Model model = result.getRawModel().getDelegate();
+return transform(model);
+}
+
+protected Model buildNonPom(RepositorySystemSession session, MavenProject
Re: [PR] [MNG-7945] Fix profile settings being injected into consumer POM [maven]
gnodet commented on code in PR #1323:
URL: https://github.com/apache/maven/pull/1323#discussion_r1408080323
##
maven-core/src/main/java/org/apache/maven/internal/transformation/TransformedArtifact.java:
##
@@ -38,7 +38,11 @@
*/
abstract class TransformedArtifact extends DefaultArtifact {
-private final OnChangeTransformer onChangeTransformer;
+interface Transformer {
+Path transform() throws Exception;
Review Comment:
You're looking at old code. I've removed `throws Exception` clauses from
this package.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7945) Fix profile settings being injected into consumer POMs
[
https://issues.apache.org/jira/browse/MNG-7945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790665#comment-17790665
]
ASF GitHub Bot commented on MNG-7945:
-
gnodet commented on code in PR #1323:
URL: https://github.com/apache/maven/pull/1323#discussion_r1408078692
##
maven-core/src/main/java/org/apache/maven/internal/transformation/impl/TransformedArtifact.java:
##
@@ -0,0 +1,148 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.internal.transformation.impl;
+
+import javax.xml.stream.XMLStreamException;
+
+import java.io.File;
+import java.io.IOException;
+import java.io.InputStream;
+import java.nio.file.Files;
+import java.nio.file.Path;
+import java.security.MessageDigest;
+import java.security.NoSuchAlgorithmException;
+import java.util.Objects;
+import java.util.concurrent.atomic.AtomicReference;
+import java.util.function.Supplier;
+
+import org.apache.maven.artifact.DefaultArtifact;
+import org.apache.maven.internal.transformation.TransformationFailedException;
+import org.apache.maven.model.building.ModelBuildingException;
+import org.apache.maven.project.MavenProject;
+import
org.codehaus.plexus.component.repository.exception.ComponentLookupException;
+import org.eclipse.aether.RepositorySystemSession;
+
+/**
+ * Transformed artifact is derived with some transformation from source
artifact.
+ *
+ * @since TBD
+ */
+class TransformedArtifact extends DefaultArtifact {
+
+private static final int SHA1_BUFFER_SIZE = 8192;
+private final DefaultConsumerPomArtifactTransformer
defaultConsumerPomArtifactTransformer;
+private final MavenProject project;
+private final Supplier sourcePathProvider;
+private final Path target;
+private final RepositorySystemSession session;
+private final AtomicReference sourceState;
+
+TransformedArtifact(
+DefaultConsumerPomArtifactTransformer
defaultConsumerPomArtifactTransformer,
+MavenProject project,
+Path target,
+RepositorySystemSession session,
+org.apache.maven.artifact.Artifact source,
+Supplier sourcePathProvider,
+String classifier,
+String extension) {
+super(
+source.getGroupId(),
+source.getArtifactId(),
+source.getVersionRange(),
+source.getScope(),
+extension,
+classifier,
+new TransformedArtifactHandler(
+classifier, extension,
source.getArtifactHandler().getPackaging()));
+this.defaultConsumerPomArtifactTransformer =
defaultConsumerPomArtifactTransformer;
+this.project = project;
+this.target = target;
+this.session = session;
+this.sourcePathProvider = sourcePathProvider;
+this.sourceState = new AtomicReference<>(null);
+}
+
+@Override
+public boolean isResolved() {
+return getFile() != null;
+}
+
+@Override
+public void setFile(File file) {
+throw new IllegalStateException("transformed artifact file cannot be
set");
Review Comment:
Because the whole point of `TransformedArtifact` is to generate lazily the
file. So if a plugin tries to set a file, it would be ignored, which would
tricky to debug. Better fail early in such a case.
> Fix profile settings being injected into consumer POMs
> --
>
> Key: MNG-7945
> URL: https://issues.apache.org/jira/browse/MNG-7945
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-8
>Reporter: Tamas Cservenak
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> The consumer POMs may end up containing information from user settings.
> The reason is that they are currently built from the effective POMs. They
> need to be rebuilt based on raw models.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7945] Fix profile settings being injected into consumer POM [maven]
gnodet commented on code in PR #1323:
URL: https://github.com/apache/maven/pull/1323#discussion_r1408078692
##
maven-core/src/main/java/org/apache/maven/internal/transformation/impl/TransformedArtifact.java:
##
@@ -0,0 +1,148 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.internal.transformation.impl;
+
+import javax.xml.stream.XMLStreamException;
+
+import java.io.File;
+import java.io.IOException;
+import java.io.InputStream;
+import java.nio.file.Files;
+import java.nio.file.Path;
+import java.security.MessageDigest;
+import java.security.NoSuchAlgorithmException;
+import java.util.Objects;
+import java.util.concurrent.atomic.AtomicReference;
+import java.util.function.Supplier;
+
+import org.apache.maven.artifact.DefaultArtifact;
+import org.apache.maven.internal.transformation.TransformationFailedException;
+import org.apache.maven.model.building.ModelBuildingException;
+import org.apache.maven.project.MavenProject;
+import
org.codehaus.plexus.component.repository.exception.ComponentLookupException;
+import org.eclipse.aether.RepositorySystemSession;
+
+/**
+ * Transformed artifact is derived with some transformation from source
artifact.
+ *
+ * @since TBD
+ */
+class TransformedArtifact extends DefaultArtifact {
+
+private static final int SHA1_BUFFER_SIZE = 8192;
+private final DefaultConsumerPomArtifactTransformer
defaultConsumerPomArtifactTransformer;
+private final MavenProject project;
+private final Supplier sourcePathProvider;
+private final Path target;
+private final RepositorySystemSession session;
+private final AtomicReference sourceState;
+
+TransformedArtifact(
+DefaultConsumerPomArtifactTransformer
defaultConsumerPomArtifactTransformer,
+MavenProject project,
+Path target,
+RepositorySystemSession session,
+org.apache.maven.artifact.Artifact source,
+Supplier sourcePathProvider,
+String classifier,
+String extension) {
+super(
+source.getGroupId(),
+source.getArtifactId(),
+source.getVersionRange(),
+source.getScope(),
+extension,
+classifier,
+new TransformedArtifactHandler(
+classifier, extension,
source.getArtifactHandler().getPackaging()));
+this.defaultConsumerPomArtifactTransformer =
defaultConsumerPomArtifactTransformer;
+this.project = project;
+this.target = target;
+this.session = session;
+this.sourcePathProvider = sourcePathProvider;
+this.sourceState = new AtomicReference<>(null);
+}
+
+@Override
+public boolean isResolved() {
+return getFile() != null;
+}
+
+@Override
+public void setFile(File file) {
+throw new IllegalStateException("transformed artifact file cannot be
set");
Review Comment:
Because the whole point of `TransformedArtifact` is to generate lazily the
file. So if a plugin tries to set a file, it would be ignored, which would
tricky to debug. Better fail early in such a case.
--
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] (MNG-7947) Plugin API
Guillaume Nodet created MNG-7947: Summary: Plugin API Key: MNG-7947 URL: https://issues.apache.org/jira/browse/MNG-7947 Project: Maven Issue Type: New Feature Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 4.0.0-alpha-9 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-722) Allow Logging Javadoc Warnings and Errors to File
[ https://issues.apache.org/jira/browse/MJAVADOC-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790624#comment-17790624 ] ASF GitHub Bot commented on MJAVADOC-722: - michael-o commented on PR #159: URL: https://github.com/apache/maven-javadoc-plugin/pull/159#issuecomment-1830063175 I will get back to you as soon as possible. > Allow Logging Javadoc Warnings and Errors to File > - > > Key: MJAVADOC-722 > URL: https://issues.apache.org/jira/browse/MJAVADOC-722 > Project: Maven Javadoc Plugin > Issue Type: New Feature > Components: javadoc >Reporter: Alan Zimmer >Priority: Trivial > > Allow for Javadoc generation, either implicitly or through a new > configuration, to generate a file containing the warnings and errors that > were found during Javadoc generation. Possibly following a similar pattern to > the argfile and options that are generated containing parameters passed to > Javadoc create an errors files that will be placed in the Javadoc output > folder that is ignored during Javadoc JAR creation. > > This change would allow for CI systems to run Javadoc builds in parallel > while still easily capturing any errors without the need for complex logging > systems and would strongly ensure that there is a unique error report for > each project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MJAVADOC-722] Log javadoc warnings and errors to file [maven-javadoc-plugin]
michael-o commented on PR #159: URL: https://github.com/apache/maven-javadoc-plugin/pull/159#issuecomment-1830063175 I will get back to you as soon as possible. -- 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] [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-1830036015 @kriegaex, look what I have found: * https://maven.apache.org/plugins/maven-site-plugin/examples/configuring-reports.html: > Note: Many report plugins provide a parameter called outputDirectory or similar to specify the destination for their report outputs. This parameter is only relevant if the report plugin is run standalone, i.e. by invocation directly from the command line. In contrast, when reports are generated as part of the site, the configuration of the Maven Site Plugin will determine the effective output directory to ensure that all reports end up in a common location. * https://maven.apache.org/surefire/maven-surefire-report-plugin/examples/report-custom-location.html I think we need to make a proper design decision whether `outputDirectory` in `AbstractMavenReport` should be read-only. I would expect it to be consistent throughout the board and the docs accordingly regardless of the approach. -- 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=17790620#comment-17790620
]
ASF GitHub Bot commented on MSHARED-1327:
-
michael-o commented on PR #26:
URL:
https://github.com/apache/maven-reporting-impl/pull/26#issuecomment-1830036015
@kriegaex, look what I have found:
*
https://maven.apache.org/plugins/maven-site-plugin/examples/configuring-reports.html:
> Note: Many report plugins provide a parameter called outputDirectory or
similar to specify the destination for their report outputs. This parameter is
only relevant if the report plugin is run standalone, i.e. by invocation
directly from the command line. In contrast, when reports are generated as part
of the site, the configuration of the Maven Site Plugin will determine the
effective output directory to ensure that all reports end up in a common
location.
*
https://maven.apache.org/surefire/maven-surefire-report-plugin/examples/report-custom-location.html
I think we need to make a proper design decision whether `outputDirectory`
in `AbstractMavenReport` should be read-only. I would expect it to be
consistent throughout the board and the docs accordingly regardless of the
approach.
> 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-M13
>
>
> 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] (MRESOLVER-443) Integrate "configuration page generator" tool into build/site
[
https://issues.apache.org/jira/browse/MRESOLVER-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790616#comment-17790616
]
Michael Osipov commented on MRESOLVER-443:
--
You have two options:
(a) Use
https://maven.apache.org/plugins/maven-site-plugin/site-mojo.html#generatedSiteDirectory
(b) or drop the file at https://maven.apache.org/pom.html#reporting at
{{post-site}} phase
> Integrate "configuration page generator" tool into build/site
> -
>
> Key: MRESOLVER-443
> URL: https://issues.apache.org/jira/browse/MRESOLVER-443
> Project: Maven Resolver
> Issue Type: Task
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> As part of MRESOLVER-440 we got a "tool" that basically generates this page:
> [https://maven.apache.org/resolver/configuration.html]
> It was manually authored before, that had many issues, was laborious and was
> error prone.
> This tool should be integrated somehow into "site", but unsure how.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-440) Clean up transport names, configuration properties and documentation
[ https://issues.apache.org/jira/browse/MRESOLVER-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790597#comment-17790597 ] ASF GitHub Bot commented on MRESOLVER-440: -- cstamas merged PR #382: URL: https://github.com/apache/maven-resolver/pull/382 > Clean up transport names, configuration properties and documentation > > > Key: MRESOLVER-440 > URL: https://issues.apache.org/jira/browse/MRESOLVER-440 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-3 > > > Currently ApacheHC transport is called "http" while JDK transport is called > "jdk" and JettyHC is "jetty". Also, historically all transports were > connectors, and later was "basic" connector added and transports introduced, > but many transport related configuration properties remained as "connector". > Proposed changes: > * Rename ApacheHC to "apache" transport, to "free" the "http" config key. > There will be no "http" transport anymore, it is reserved for "shared HTTP > related config" that is shared among multiple HTTP transports (apache, jdk, > jetty...). > * Rename transport specific configurations from "aether.connector.apache..." > and "aether.connector.jdk..." to their proper names "aether.transport..." > * keep "aether.transport.http..." for generic HTTP protocol related > configuration (that may be used by all HTTP using transports). > * align many other (for historical reason) badly keyed property to "proper > place". > * sort out documentation for these, ideally the page should be generated > As part of this work along with source changes (mostly javadoc) a "tool" has > been made that auto-generates this page > https://maven.apache.org/resolver/configuration.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-440] Addendum [maven-resolver]
cstamas merged PR #382: URL: https://github.com/apache/maven-resolver/pull/382 -- 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] (MRESOLVER-440) Clean up transport names, configuration properties and documentation
[ https://issues.apache.org/jira/browse/MRESOLVER-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790594#comment-17790594 ] ASF GitHub Bot commented on MRESOLVER-440: -- cstamas opened a new pull request, #382: URL: https://github.com/apache/maven-resolver/pull/382 Seems the "atypical" modules like supplier and demo snippets were completely omitted from the transport rename, and were still using renamed transport-http instead the new transport-apache. --- https://issues.apache.org/jira/browse/MRESOLVER-440 > Clean up transport names, configuration properties and documentation > > > Key: MRESOLVER-440 > URL: https://issues.apache.org/jira/browse/MRESOLVER-440 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-3 > > > Currently ApacheHC transport is called "http" while JDK transport is called > "jdk" and JettyHC is "jetty". Also, historically all transports were > connectors, and later was "basic" connector added and transports introduced, > but many transport related configuration properties remained as "connector". > Proposed changes: > * Rename ApacheHC to "apache" transport, to "free" the "http" config key. > There will be no "http" transport anymore, it is reserved for "shared HTTP > related config" that is shared among multiple HTTP transports (apache, jdk, > jetty...). > * Rename transport specific configurations from "aether.connector.apache..." > and "aether.connector.jdk..." to their proper names "aether.transport..." > * keep "aether.transport.http..." for generic HTTP protocol related > configuration (that may be used by all HTTP using transports). > * align many other (for historical reason) badly keyed property to "proper > place". > * sort out documentation for these, ideally the page should be generated > As part of this work along with source changes (mostly javadoc) a "tool" has > been made that auto-generates this page > https://maven.apache.org/resolver/configuration.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [MRESOLVER-440] Addendum [maven-resolver]
cstamas opened a new pull request, #382: URL: https://github.com/apache/maven-resolver/pull/382 Seems the "atypical" modules like supplier and demo snippets were completely omitted from the transport rename, and were still using renamed transport-http instead the new transport-apache. --- https://issues.apache.org/jira/browse/MRESOLVER-440 -- 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-542) clean JDK patch version in module-info.class
[ https://issues.apache.org/jira/browse/MCOMPILER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790584#comment-17790584 ] ASF GitHub Bot commented on MCOMPILER-542: -- hboutemy merged PR #208: URL: https://github.com/apache/maven-compiler-plugin/pull/208 > clean JDK patch version in module-info.class > > > Key: MCOMPILER-542 > URL: https://issues.apache.org/jira/browse/MCOMPILER-542 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.11.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.12.0 > > > as seen in MJAR-275, JDK patch version in module-info.class is NOT included > only when building with a newer JDK release using "--release" flag, see > [https://github.com/jvm-repo-rebuild/module-info] > issue [https://bugs.openjdk.org/browse/JDK-8318913] created in JDK to get a > proper fix at javac level (probably for Java 22) > and waiting for that, we need a workaround to drop the JDK patch version in > other cases: we'll need to define where is the best place – > m-jar-p?m-compiler-p? other? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MCOMPILER-542) clean JDK patch version in module-info.class
[ https://issues.apache.org/jira/browse/MCOMPILER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MCOMPILER-542. --- Resolution: Fixed > clean JDK patch version in module-info.class > > > Key: MCOMPILER-542 > URL: https://issues.apache.org/jira/browse/MCOMPILER-542 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.11.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.12.0 > > > as seen in MJAR-275, JDK patch version in module-info.class is NOT included > only when building with a newer JDK release using "--release" flag, see > [https://github.com/jvm-repo-rebuild/module-info] > issue [https://bugs.openjdk.org/browse/JDK-8318913] created in JDK to get a > proper fix at javac level (probably for Java 22) > and waiting for that, we need a workaround to drop the JDK patch version in > other cases: we'll need to define where is the best place – > m-jar-p?m-compiler-p? other? -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MCOMPILER-542] Clean JDK patch version in module-info.class [maven-compiler-plugin]
hboutemy merged PR #208: URL: https://github.com/apache/maven-compiler-plugin/pull/208 -- 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] (MRESOLVER-442) New JDK transport JAR mixes classes with different bytecode
[ https://issues.apache.org/jira/browse/MRESOLVER-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790580#comment-17790580 ] ASF GitHub Bot commented on MRESOLVER-442: -- rmannibucau commented on PR #381: URL: https://github.com/apache/maven-resolver/pull/381#issuecomment-1829884012 @struberg yep. Agree it needs some tuning of m-enforcer-plugin but isnt it the case anyway? Also is it that much used (have to admit I abandonned it years ago cause it had too much false positives for me and the cost to tune it was way too high for what it was bringing - validating the bytecode version is almost useless if you have tests with acceptable coverage for ex)? > New JDK transport JAR mixes classes with different bytecode > --- > > Key: MRESOLVER-442 > URL: https://issues.apache.org/jira/browse/MRESOLVER-442 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-3 > > > And hence is unusable in projects that use Enforcer to enforce highest > allowed bytecode (like Maven is). -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-442] Build JDK transport MR JAR the proper way [maven-resolver]
rmannibucau commented on PR #381: URL: https://github.com/apache/maven-resolver/pull/381#issuecomment-1829884012 @struberg yep. Agree it needs some tuning of m-enforcer-plugin but isnt it the case anyway? Also is it that much used (have to admit I abandonned it years ago cause it had too much false positives for me and the cost to tune it was way too high for what it was bringing - validating the bytecode version is almost useless if you have tests with acceptable coverage for ex)? -- 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] (MRESOLVER-442) New JDK transport JAR mixes classes with different bytecode
[ https://issues.apache.org/jira/browse/MRESOLVER-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790576#comment-17790576 ] ASF GitHub Bot commented on MRESOLVER-442: -- struberg commented on PR #381: URL: https://github.com/apache/maven-resolver/pull/381#issuecomment-1829876470 you mean you have additional classes which will get picked up dynamically by the app *only* if you run on a jvm which is suitable? I've seen this done, yes, but that cries for an exclude in m-enforcer-plugin or some other trick. > New JDK transport JAR mixes classes with different bytecode > --- > > Key: MRESOLVER-442 > URL: https://issues.apache.org/jira/browse/MRESOLVER-442 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-3 > > > And hence is unusable in projects that use Enforcer to enforce highest > allowed bytecode (like Maven is). -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-442] Build JDK transport MR JAR the proper way [maven-resolver]
struberg commented on PR #381: URL: https://github.com/apache/maven-resolver/pull/381#issuecomment-1829876470 you mean you have additional classes which will get picked up dynamically by the app *only* if you run on a jvm which is suitable? I've seen this done, yes, but that cries for an exclude in m-enforcer-plugin or some other trick. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] Failed to install artifact xxx [maven-mvnd]
cstamas commented on issue #862: URL: https://github.com/apache/maven-mvnd/issues/862#issuecomment-1829870519 Vote is here: https://lists.apache.org/thread/sc5rgz3qzm9b8b6gwg622xokpqpsxmyv Feel free to test the binaries! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] Failed to install artifact xxx [maven-mvnd]
harryssuperman commented on issue #862: URL: https://github.com/apache/maven-mvnd/issues/862#issuecomment-1829864194 Thank you so much @cstamas. I was checking the next release version for 3.9.6. Our windows build server will be waiting for it! ;-) -- 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] (MRESOLVER-444) Make build time requirement for Java 17
[ https://issues.apache.org/jira/browse/MRESOLVER-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-444: - Assignee: Tamas Cservenak > Make build time requirement for Java 17 > --- > > Key: MRESOLVER-444 > URL: https://issues.apache.org/jira/browse/MRESOLVER-444 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-3 > > > Supersed MRESOLVER-430 as there were some simplifications, so no Java21 is > must, while features from it are supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-444) Make build time requirement for Java 17
[ https://issues.apache.org/jira/browse/MRESOLVER-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-444: -- Description: Supersed MRESOLVER-430 as there were some simplifications, so no Java21 is must, while features from it are supported. Is fixed by https://github.com/apache/maven-resolver/commit/3e56c51ba66ffb338bea7453f2db0239ae8b13f3 was:Supersed MRESOLVER-430 as there were some simplifications, so no Java21 is must, while features from it are supported. > Make build time requirement for Java 17 > --- > > Key: MRESOLVER-444 > URL: https://issues.apache.org/jira/browse/MRESOLVER-444 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-3 > > > Supersed MRESOLVER-430 as there were some simplifications, so no Java21 is > must, while features from it are supported. > Is fixed by > https://github.com/apache/maven-resolver/commit/3e56c51ba66ffb338bea7453f2db0239ae8b13f3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-444) Make build time requirement for Java 17
[ https://issues.apache.org/jira/browse/MRESOLVER-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-444. - Resolution: Fixed > Make build time requirement for Java 17 > --- > > Key: MRESOLVER-444 > URL: https://issues.apache.org/jira/browse/MRESOLVER-444 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-3 > > > Supersed MRESOLVER-430 as there were some simplifications, so no Java21 is > must, while features from it are supported. > Is fixed by > https://github.com/apache/maven-resolver/commit/3e56c51ba66ffb338bea7453f2db0239ae8b13f3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-444) Make build time requirement for Java 17
Tamas Cservenak created MRESOLVER-444: - Summary: Make build time requirement for Java 17 Key: MRESOLVER-444 URL: https://issues.apache.org/jira/browse/MRESOLVER-444 Project: Maven Resolver Issue Type: Task Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.0, 2.0.0-alpha-3 Supersed MRESOLVER-430 as there were some simplifications, so no Java21 is must, while features from it are supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7913) Upgrade Sisu version to 0.9.0.M2
[ https://issues.apache.org/jira/browse/MNG-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7913: - Summary: Upgrade Sisu version to 0.9.0.M2 (was: Upgrade Sisu version) > Upgrade Sisu version to 0.9.0.M2 > > > Key: MNG-7913 > URL: https://issues.apache.org/jira/browse/MNG-7913 > Project: Maven > Issue Type: Dependency upgrade > Components: Core >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.6 > > > Recently, as new Java versions are pushed out more aggressively (with Java 21 > out this autumn), seemingly it became normal that users developing Maven > plugins (and components used by those plugins) using bytecode level that is > Java14+. > But alas, Maven 3.9.x line uses Sisu 0.3.5 that is capable to glean bytecode > only up to Java 14. Components having higher version bytecode are silently > skipped by Sisu (no output about this, only at Sisu DEBUG level not emitted > by default). > Hence, it would make sense to up Sisu version to at least 0.9.0.M2 in Maven > 3.9.x as well, that would allow use of JSR330 components using bytecode more > recent that Java 14 is, up to 19. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-744) Maven coordinates in Javadoc
[ https://issues.apache.org/jira/browse/MJAVADOC-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790558#comment-17790558 ] Peter Verhas commented on MJAVADOC-744: --- You suggest using a special Doclet integrated with the Maven JavaDoc plugin. Such Doclet will only be usable for projects that use Maven as a build tool. If you want to include the Maven coordinated into the JavaDoc, the header and the footer configuration parameters are the tools for that. You can write the maven coordinates or whatever you want to be included on all pages. Suppose you want to get the maven coordinates or some other information already available somewhere to get there automated. In that case, you can use the Jamal Maven Extension and maintain a `pom.jam` file. With that you can use macros that fetch the coordinates automatically from the pom.xml file. > Maven coordinates in Javadoc > > > Key: MJAVADOC-744 > URL: https://issues.apache.org/jira/browse/MJAVADOC-744 > Project: Maven Javadoc Plugin > Issue Type: New Feature >Reporter: Elliotte Rusty Harold >Priority: Minor > > Add an option to the javadoc plugin to include the Maven coordinates > (group:artifact:version) of a class in its Javadoc. > I noticed this morning for about the 173rd time that I could google for the > API doc of a class I needed, but still couldn't figure out which artifact I > needed to add to my pom.xml to include that class in my project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7913) Upgrade Sisu version
[ https://issues.apache.org/jira/browse/MNG-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790555#comment-17790555 ] Michael Osipov commented on MNG-7913: - Issue summary should contain the Sisu version. > Upgrade Sisu version > > > Key: MNG-7913 > URL: https://issues.apache.org/jira/browse/MNG-7913 > Project: Maven > Issue Type: Dependency upgrade > Components: Core >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.6 > > > Recently, as new Java versions are pushed out more aggressively (with Java 21 > out this autumn), seemingly it became normal that users developing Maven > plugins (and components used by those plugins) using bytecode level that is > Java14+. > But alas, Maven 3.9.x line uses Sisu 0.3.5 that is capable to glean bytecode > only up to Java 14. Components having higher version bytecode are silently > skipped by Sisu (no output about this, only at Sisu DEBUG level not emitted > by default). > Hence, it would make sense to up Sisu version to at least 0.9.0.M2 in Maven > 3.9.x as well, that would allow use of JSR330 components using bytecode more > recent that Java 14 is, up to 19. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-744) Maven coordinates in Javadoc
[ https://issues.apache.org/jira/browse/MJAVADOC-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790553#comment-17790553 ] Elliotte Rusty Harold commented on MJAVADOC-744: Might require a custom doclet. The javadoc tool doesn't know about this since these coordinates aren't in .java files. It needs to come from the javadoc plugi, which is going to be tricky since we'd need to inject something into the javadoc generation process. > Maven coordinates in Javadoc > > > Key: MJAVADOC-744 > URL: https://issues.apache.org/jira/browse/MJAVADOC-744 > Project: Maven Javadoc Plugin > Issue Type: New Feature >Reporter: Elliotte Rusty Harold >Priority: Minor > > Add an option to the javadoc plugin to include the Maven coordinates > (group:artifact:version) of a class in its Javadoc. > I noticed this morning for about the 173rd time that I could google for the > API doc of a class I needed, but still couldn't figure out which artifact I > needed to add to my pom.xml to include that class in my project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MJAVADOC-739) Null pointer exception when executing javadoc:fix goal
[
https://issues.apache.org/jira/browse/MJAVADOC-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MJAVADOC-739:
---
Labels: starter (was: )
> Null pointer exception when executing javadoc:fix goal
> --
>
> Key: MJAVADOC-739
> URL: https://issues.apache.org/jira/browse/MJAVADOC-739
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.4.1
>Reporter: Antonin Delpeuch
>Priority: Major
> Labels: starter
>
> Running `mvn -e javadoc:fix` on my project, I get the following error:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:fix (default-cli) on
> project refine-model: Execution default-cli of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:fix failed.:
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:fix (default-cli) on
> project refine-model: Execution default-cli of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:fix failed.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-cli of goal org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:fix
> failed.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:148)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at
[jira] [Updated] (MJAVADOC-739) Null pointer exception when executing javadoc:fix goal
[
https://issues.apache.org/jira/browse/MJAVADOC-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MJAVADOC-739:
---
Component/s: javadoc
(was: fix)
> Null pointer exception when executing javadoc:fix goal
> --
>
> Key: MJAVADOC-739
> URL: https://issues.apache.org/jira/browse/MJAVADOC-739
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.4.1
>Reporter: Antonin Delpeuch
>Priority: Major
>
> Running `mvn -e javadoc:fix` on my project, I get the following error:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:fix (default-cli) on
> project refine-model: Execution default-cli of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:fix failed.:
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:fix (default-cli) on
> project refine-model: Execution default-cli of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:fix failed.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-cli of goal org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:fix
> failed.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:148)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke
[jira] [Commented] (MJAVADOC-755) Clean up deprecated and unpreferred methods in JavadocUtil
[ https://issues.apache.org/jira/browse/MJAVADOC-755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790550#comment-17790550 ] ASF GitHub Bot commented on MJAVADOC-755: - elharo commented on PR #210: URL: https://github.com/apache/maven-javadoc-plugin/pull/210#issuecomment-1829783909 I might be wrong about the differences between Java 8 and Java 9+. There are differences but it looks like the ToolProvider API might call the right methods on whichever platform it's running on. > Clean up deprecated and unpreferred methods in JavadocUtil > -- > > Key: MJAVADOC-755 > URL: https://issues.apache.org/jira/browse/MJAVADOC-755 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > Fix For: 3.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MJAVADOC-755] plexus --> maven-shared-utils [maven-javadoc-plugin]
elharo commented on PR #210: URL: https://github.com/apache/maven-javadoc-plugin/pull/210#issuecomment-1829783909 I might be wrong about the differences between Java 8 and Java 9+. There are differences but it looks like the ToolProvider API might call the right methods on whichever platform it's running on. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (MJAVADOC-756) Use ToolProvider API, not CLI to invoke javadoc
[ https://issues.apache.org/jira/browse/MJAVADOC-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MJAVADOC-756. Resolution: Duplicate > Use ToolProvider API, not CLI to invoke javadoc > --- > > Key: MJAVADOC-756 > URL: https://issues.apache.org/jira/browse/MJAVADOC-756 > Project: Maven Javadoc Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Major > > In JavadocUtil > ' > see > https://stackoverflow.com/questions/54040274/what-is-the-alternative-of-com-sun-tools-javadoc-main-execute-to-run-doclet-in-j -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MJAVADOC-756) Use ToolProvider API, not CLI to invoke javadoc
[ https://issues.apache.org/jira/browse/MJAVADOC-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MJAVADOC-756. -- > Use ToolProvider API, not CLI to invoke javadoc > --- > > Key: MJAVADOC-756 > URL: https://issues.apache.org/jira/browse/MJAVADOC-756 > Project: Maven Javadoc Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Major > > In JavadocUtil > ' > see > https://stackoverflow.com/questions/54040274/what-is-the-alternative-of-com-sun-tools-javadoc-main-execute-to-run-doclet-in-j -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-732) Use javax.tools API for calling javadoc
[
https://issues.apache.org/jira/browse/MJAVADOC-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790549#comment-17790549
]
Elliotte Rusty Harold commented on MJAVADOC-732:
see
https://stackoverflow.com/questions/54040274/what-is-the-alternative-of-com-sun-tools-javadoc-main-execute-to-run-doclet-in-j
> Use javax.tools API for calling javadoc
> ---
>
> Key: MJAVADOC-732
> URL: https://issues.apache.org/jira/browse/MJAVADOC-732
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently javadoc is called as external process which makes
> consuming/exposing warnings and errors a bit cumbersome and also prevents
> proper m2e integration.
> As https://openjdk.org/jeps/106 added javadoc support to {{javax.tools}} with
> Java 8 it should be safe to adopt that given that m-javadoc-p has been
> updated to require Java 8 in MJAVADOC-675
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-775) Option 'tagletpath' not working, completely ignored
[
https://issues.apache.org/jira/browse/MJAVADOC-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790545#comment-17790545
]
Elliotte Rusty Harold commented on MJAVADOC-775:
If that's so, we should probably just remove tagletpath from the docs
> Option 'tagletpath' not working, completely ignored
> ---
>
> Key: MJAVADOC-775
> URL: https://issues.apache.org/jira/browse/MJAVADOC-775
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.6.0
>Reporter: Alexander Kriegisch
>Priority: Major
>
> The [{{tagletpath}}
> option|https://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html#tagletpath]
> seems to be completely ignored, despite being documented. It looks as if
> this never worked before. It is also utterly untested. There is an old bug
> MJAVADOC-231, but whatever that was meant to fix, it seems to be unrelated to
> this one. If I have a local JAR unavailable on Maven Central sitting in a
> libraries folder, I cannot use it in any other way than to contrive to put a
> copy into my local Maven repository and use {{tagletArtifact}} instead of
> {{tagletpath}}.
> I noticed this, when trying to help someone asking a question on the [Maven
> users mailing
> list|https://lists.apache.org/thread/zv25z3hx9gbmbt6wwhby6cy0t5lr542l]. In
> his [sample repository|https://github.com/jkesselm/xalan-java-mvn], an effort
> to convert the Xalan Ant Build to Maven, the commit to check out is is
> [6daf2890|https://github.com/jkesselm/xalan-java-mvn/tree/6daf2890bc03b13cd741b963d33897d61dcf4e5f].
> Just run {{mvn -DskipTests=true site}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] fix style [maven-site]
slawekjaranowski merged PR #460: URL: https://github.com/apache/maven-site/pull/460 -- 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] (MJAVADOC-689) When I run "javadoc:fix" , I get an error .
[ https://issues.apache.org/jira/browse/MJAVADOC-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MJAVADOC-689. -- > When I run "javadoc:fix" , I get an error . > --- > > Key: MJAVADOC-689 > URL: https://issues.apache.org/jira/browse/MJAVADOC-689 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: fix >Affects Versions: 3.3.0 >Reporter: si changxu >Priority: Major > Fix For: waiting-for-feedback > > Attachments: Log.zip > > > My English is not good, Sorry `(*>﹏<*)′ > When I run "javadoc:fix" , I get an error . > I try debug . > In "AbstractFixJavadocMojo.java" LineNumber : 2945 . > I find a method named "getFullClirrGoal " . and in this return a string like > "org.codehaus.mojo:clirr-maven-plugin:2.2.2:check" > I think the problem may be in the version "2.2.2" so i change it to "2.8" , > and it`s work . > So I want to know is a bug or I made a mistake. > I put the log in attachment. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MJAVADOC-689) When I run "javadoc:fix" , I get an error .
[ https://issues.apache.org/jira/browse/MJAVADOC-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MJAVADOC-689. Resolution: Not A Bug > When I run "javadoc:fix" , I get an error . > --- > > Key: MJAVADOC-689 > URL: https://issues.apache.org/jira/browse/MJAVADOC-689 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: fix >Affects Versions: 3.3.0 >Reporter: si changxu >Priority: Major > Fix For: waiting-for-feedback > > Attachments: Log.zip > > > My English is not good, Sorry `(*>﹏<*)′ > When I run "javadoc:fix" , I get an error . > I try debug . > In "AbstractFixJavadocMojo.java" LineNumber : 2945 . > I find a method named "getFullClirrGoal " . and in this return a string like > "org.codehaus.mojo:clirr-maven-plugin:2.2.2:check" > I think the problem may be in the version "2.2.2" so i change it to "2.8" , > and it`s work . > So I want to know is a bug or I made a mistake. > I put the log in attachment. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MJAVADOC-764) javadoc:aggregate fails after Java 11 upgrade
[
https://issues.apache.org/jira/browse/MJAVADOC-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MJAVADOC-764.
--
> javadoc:aggregate fails after Java 11 upgrade
> --
>
> Key: MJAVADOC-764
> URL: https://issues.apache.org/jira/browse/MJAVADOC-764
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Sirisha Pratha
>Priority: Critical
> Labels: jpms
> Fix For: waiting-for-feedback
>
>
> We have a multi-module project that is failing for javadoc:aggregate goal
> after upgrading to Java 11 for maven-javadoc-plugin versions 3.4.1 and 3.5.0.
> It worked fine without any issues for Java 1.8.
> This is our maven-javadoc plugin configuration for Java 8 -
> {color:#00875a}*SUCCESS*{color}
>
> {noformat}
> 8
>
> maven-javadoc-plugin
>
> ${maven.compiler.source}
> Eclipse Collections -
> ${project.version}
> Eclipse Collections -
> ${project.version}
> public
> true
>
> https://junit.org/junit4/javadoc/latest
>
> https://docs.oracle.com/javase/8/docs/api/
>
> ${project.version}
> html,syntax,accessibility
>
>
> org.openjdk,org.eclipse.collections.impl.jmh,org.eclipse.collections.codegenerator,org.eclipse.collections.codegenerator.maven
>
>
>
>
> aggregate
> false
>
> aggregate
>
>
>
>
> {noformat}
> This is our maven-javadoc plugin configuration for Java 11 - (the only
> difference is values in source and links tags) -
> *{color:#ff}FAILS{color}* {color:#ff}(See error below){color}
>
> {noformat}
> 11
>
> maven-javadoc-plugin
>
> ${maven.compiler.source}
> Eclipse Collections -
> ${project.version}
> Eclipse Collections -
> ${project.version}
> public
> true
>
> https://junit.org/junit4/javadoc/latest
>
> https://docs.oracle.com/en/java/javase/11/docs/api
>
> ${project.version}
> html,syntax,accessibility
>
>
> org.openjdk,org.eclipse.collections.impl.jmh,org.eclipse.collections.codegenerator,org.eclipse.collections.codegenerator.maven
>
>
>
>
> aggregate
> false
>
> aggregate
>
>
>
> {noformat}
>
> _javadoc:aggregate_ fails with the following error on our GitHub workflow
> (nothing changed in the way we run this job - we have always used Java 17 to
> run this)
>
> {noformat}
> Error: 6:236 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:aggregate (default-cli)
> on project eclipse-collections-parent: An error has occurred in Javadoc
> report generation:
> 515Error: 6:236 [ERROR] Exit code: 2 - Loading source files for package
> org.eclipse.collections.codegenerator.model...
> 516Error: 02:14:46:236 [ERROR] error: No source files for package
> org.eclipse.collections.codegenerator.model
> 517Error: 02:14:46:237 [ERROR] 1 error
> 518Error: 6:237 [ERROR]
> 519Error: 6:238 [ERROR] Command line was:
> /opt/hostedtoolcache/Java_Zulu_jdk/17.0.7-7/x64/bin/javadoc @options @packages
> 520Error: 6:238 [ERROR]
> 521Error: 6:238 [ERROR] Refer to the generated Javadoc files in
> '/home/runner/work/eclipse-collections/eclipse-collections/target/site/apidocs/12.0.0-SNAPSHOT'
> dir.
> 522Error: 6:239 [ERROR]
> 523Error: 6:240 [ERROR] -> [Help 1]{noformat}
>
>
> Solutions we tried -
> # Configuring sourcePath (see below) - in this case, *no Javadoc was
> created* in target/site/apidocs.
> {noformat}
> ${project.build.sourceDirectory}{noformat}
> # Tried both plugin versions 3.4.1 and 3.5.0 - *fails* with both versions.
> # Tried to add source = 1.8 but maven.compiler.source = 11, which seems to
> be the only combination that {*}works{*}. Like so -
> {noformat}
> 11
>
> maven-javadoc-plugin
>
> 1.8
>
[jira] [Resolved] (MJAVADOC-764) javadoc:aggregate fails after Java 11 upgrade
[
https://issues.apache.org/jira/browse/MJAVADOC-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MJAVADOC-764.
Resolution: Not A Bug
> javadoc:aggregate fails after Java 11 upgrade
> --
>
> Key: MJAVADOC-764
> URL: https://issues.apache.org/jira/browse/MJAVADOC-764
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Sirisha Pratha
>Priority: Critical
> Labels: jpms
> Fix For: waiting-for-feedback
>
>
> We have a multi-module project that is failing for javadoc:aggregate goal
> after upgrading to Java 11 for maven-javadoc-plugin versions 3.4.1 and 3.5.0.
> It worked fine without any issues for Java 1.8.
> This is our maven-javadoc plugin configuration for Java 8 -
> {color:#00875a}*SUCCESS*{color}
>
> {noformat}
> 8
>
> maven-javadoc-plugin
>
> ${maven.compiler.source}
> Eclipse Collections -
> ${project.version}
> Eclipse Collections -
> ${project.version}
> public
> true
>
> https://junit.org/junit4/javadoc/latest
>
> https://docs.oracle.com/javase/8/docs/api/
>
> ${project.version}
> html,syntax,accessibility
>
>
> org.openjdk,org.eclipse.collections.impl.jmh,org.eclipse.collections.codegenerator,org.eclipse.collections.codegenerator.maven
>
>
>
>
> aggregate
> false
>
> aggregate
>
>
>
>
> {noformat}
> This is our maven-javadoc plugin configuration for Java 11 - (the only
> difference is values in source and links tags) -
> *{color:#ff}FAILS{color}* {color:#ff}(See error below){color}
>
> {noformat}
> 11
>
> maven-javadoc-plugin
>
> ${maven.compiler.source}
> Eclipse Collections -
> ${project.version}
> Eclipse Collections -
> ${project.version}
> public
> true
>
> https://junit.org/junit4/javadoc/latest
>
> https://docs.oracle.com/en/java/javase/11/docs/api
>
> ${project.version}
> html,syntax,accessibility
>
>
> org.openjdk,org.eclipse.collections.impl.jmh,org.eclipse.collections.codegenerator,org.eclipse.collections.codegenerator.maven
>
>
>
>
> aggregate
> false
>
> aggregate
>
>
>
> {noformat}
>
> _javadoc:aggregate_ fails with the following error on our GitHub workflow
> (nothing changed in the way we run this job - we have always used Java 17 to
> run this)
>
> {noformat}
> Error: 6:236 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:aggregate (default-cli)
> on project eclipse-collections-parent: An error has occurred in Javadoc
> report generation:
> 515Error: 6:236 [ERROR] Exit code: 2 - Loading source files for package
> org.eclipse.collections.codegenerator.model...
> 516Error: 02:14:46:236 [ERROR] error: No source files for package
> org.eclipse.collections.codegenerator.model
> 517Error: 02:14:46:237 [ERROR] 1 error
> 518Error: 6:237 [ERROR]
> 519Error: 6:238 [ERROR] Command line was:
> /opt/hostedtoolcache/Java_Zulu_jdk/17.0.7-7/x64/bin/javadoc @options @packages
> 520Error: 6:238 [ERROR]
> 521Error: 6:238 [ERROR] Refer to the generated Javadoc files in
> '/home/runner/work/eclipse-collections/eclipse-collections/target/site/apidocs/12.0.0-SNAPSHOT'
> dir.
> 522Error: 6:239 [ERROR]
> 523Error: 6:240 [ERROR] -> [Help 1]{noformat}
>
>
> Solutions we tried -
> # Configuring sourcePath (see below) - in this case, *no Javadoc was
> created* in target/site/apidocs.
> {noformat}
> ${project.build.sourceDirectory}{noformat}
> # Tried both plugin versions 3.4.1 and 3.5.0 - *fails* with both versions.
> # Tried to add source = 1.8 but maven.compiler.source = 11, which seems to
> be the only combination that {*}works{*}. Like so -
> {noformat}
> 11
>
> maven-javadoc-plugin
[jira] [Commented] (MNG-7945) Fix profile settings being injected into consumer POMs
[ https://issues.apache.org/jira/browse/MNG-7945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790542#comment-17790542 ] ASF GitHub Bot commented on MNG-7945: - elharo commented on PR #1323: URL: https://github.com/apache/maven/pull/1323#issuecomment-1829751076 > I am blocked by this, so can this be soon merged please? @elharo any counter arguments? Counter-arguments to what claim? The use of exceptions in this PR does not align with Java standard practices. I don't think that's changed yet. > Fix profile settings being injected into consumer POMs > -- > > Key: MNG-7945 > URL: https://issues.apache.org/jira/browse/MNG-7945 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-alpha-8 >Reporter: Tamas Cservenak >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-9 > > > The consumer POMs may end up containing information from user settings. > The reason is that they are currently built from the effective POMs. They > need to be rebuilt based on raw models. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7945] Fix profile settings being injected into consumer POM [maven]
elharo commented on PR #1323: URL: https://github.com/apache/maven/pull/1323#issuecomment-1829751076 > I am blocked by this, so can this be soon merged please? @elharo any counter arguments? Counter-arguments to what claim? The use of exceptions in this PR does not align with Java standard practices. I don't think that's changed yet. -- 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] (MRESOLVER-442) New JDK transport JAR mixes classes with different bytecode
[ https://issues.apache.org/jira/browse/MRESOLVER-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790540#comment-17790540 ] ASF GitHub Bot commented on MRESOLVER-442: -- rmannibucau commented on PR #381: URL: https://github.com/apache/maven-resolver/pull/381#issuecomment-1829749022 @cstamas these are two ok things: * enforcer config, not a big deal IMHO and anyway enforcer is doomed by mjar - and once again 2 jars solve it without issues * IoC/scanners must ignore classes they can't run so it is fine IMHO - and once again 2 jars solve it without issues since you will not scan the java 11 one @struberg literally means that `if some dependency has a *NOT* a multi-release-jar but has additional support for newer java versions, then this is also perfectly fine as long as it can execute on the requested jvm version.`, no idea why it wouldn't, this is how most relocaed packages had been handled since 10+ years without issues. so overall multi jar release is *always* pointless and it is better to stay away from it due to the downsides mentionned earlier. I have really a hard time to see why jumping on a feature which breaks the library nature of the project is good since technically there is nothing which can explain it. > New JDK transport JAR mixes classes with different bytecode > --- > > Key: MRESOLVER-442 > URL: https://issues.apache.org/jira/browse/MRESOLVER-442 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-3 > > > And hence is unusable in projects that use Enforcer to enforce highest > allowed bytecode (like Maven is). -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-442] Build JDK transport MR JAR the proper way [maven-resolver]
rmannibucau commented on PR #381: URL: https://github.com/apache/maven-resolver/pull/381#issuecomment-1829749022 @cstamas these are two ok things: * enforcer config, not a big deal IMHO and anyway enforcer is doomed by mjar - and once again 2 jars solve it without issues * IoC/scanners must ignore classes they can't run so it is fine IMHO - and once again 2 jars solve it without issues since you will not scan the java 11 one @struberg literally means that `if some dependency has a *NOT* a multi-release-jar but has additional support for newer java versions, then this is also perfectly fine as long as it can execute on the requested jvm version.`, no idea why it wouldn't, this is how most relocaed packages had been handled since 10+ years without issues. so overall multi jar release is *always* pointless and it is better to stay away from it due to the downsides mentionned earlier. I have really a hard time to see why jumping on a feature which breaks the library nature of the project is good since technically there is nothing which can explain it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7945) Fix profile settings being injected into consumer POMs
[
https://issues.apache.org/jira/browse/MNG-7945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790539#comment-17790539
]
ASF GitHub Bot commented on MNG-7945:
-
elharo commented on code in PR #1323:
URL: https://github.com/apache/maven/pull/1323#discussion_r1407684809
##
maven-core/src/main/java/org/apache/maven/internal/transformation/TransformedArtifact.java:
##
@@ -38,7 +38,11 @@
*/
abstract class TransformedArtifact extends DefaultArtifact {
-private final OnChangeTransformer onChangeTransformer;
+interface Transformer {
+Path transform() throws Exception;
Review Comment:
I'm not yet convinced that a full java.lang.Exception is desirable here.
Possibly an IOException if it's writing/reading files. Possibly no exception at
all should be allowed.
> Fix profile settings being injected into consumer POMs
> --
>
> Key: MNG-7945
> URL: https://issues.apache.org/jira/browse/MNG-7945
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-8
>Reporter: Tamas Cservenak
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> The consumer POMs may end up containing information from user settings.
> The reason is that they are currently built from the effective POMs. They
> need to be rebuilt based on raw models.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7945] Fix profile settings being injected into consumer POM [maven]
elharo commented on code in PR #1323:
URL: https://github.com/apache/maven/pull/1323#discussion_r1407684809
##
maven-core/src/main/java/org/apache/maven/internal/transformation/TransformedArtifact.java:
##
@@ -38,7 +38,11 @@
*/
abstract class TransformedArtifact extends DefaultArtifact {
-private final OnChangeTransformer onChangeTransformer;
+interface Transformer {
+Path transform() throws Exception;
Review Comment:
I'm not yet convinced that a full java.lang.Exception is desirable here.
Possibly an IOException if it's writing/reading files. Possibly no exception at
all should be allowed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7945) Fix profile settings being injected into consumer POMs
[
https://issues.apache.org/jira/browse/MNG-7945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790538#comment-17790538
]
ASF GitHub Bot commented on MNG-7945:
-
elharo commented on code in PR #1323:
URL: https://github.com/apache/maven/pull/1323#discussion_r1407676979
##
maven-core/src/main/java/org/apache/maven/internal/transformation/impl/DefaultConsumerPomBuilder.java:
##
@@ -0,0 +1,230 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.internal.transformation.impl;
+
+import javax.inject.Inject;
+import javax.inject.Named;
+
+import java.nio.file.Path;
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.List;
+import java.util.Map;
+import java.util.Properties;
+import java.util.stream.Collectors;
+
+import org.apache.maven.api.model.DistributionManagement;
+import org.apache.maven.api.model.Model;
+import org.apache.maven.api.model.ModelBase;
+import org.apache.maven.api.model.Profile;
+import org.apache.maven.api.model.Repository;
+import org.apache.maven.model.building.DefaultModelBuilder;
+import org.apache.maven.model.building.DefaultModelBuilderFactory;
+import org.apache.maven.model.building.DefaultModelBuildingRequest;
+import org.apache.maven.model.building.ModelBuildingException;
+import org.apache.maven.model.building.ModelBuildingRequest;
+import org.apache.maven.model.building.ModelBuildingResult;
+import org.apache.maven.model.building.ModelProblemCollector;
+import org.apache.maven.model.building.ModelProcessor;
+import org.apache.maven.model.composition.DependencyManagementImporter;
+import org.apache.maven.model.inheritance.InheritanceAssembler;
+import org.apache.maven.model.interpolation.ModelInterpolator;
+import org.apache.maven.model.management.DependencyManagementInjector;
+import org.apache.maven.model.management.PluginManagementInjector;
+import org.apache.maven.model.normalization.ModelNormalizer;
+import org.apache.maven.model.path.ModelPathTranslator;
+import org.apache.maven.model.path.ModelUrlNormalizer;
+import org.apache.maven.model.plugin.LifecycleBindingsInjector;
+import org.apache.maven.model.plugin.PluginConfigurationExpander;
+import org.apache.maven.model.plugin.ReportConfigurationExpander;
+import org.apache.maven.model.profile.DefaultProfileSelector;
+import org.apache.maven.model.profile.ProfileActivationContext;
+import org.apache.maven.model.profile.ProfileInjector;
+import org.apache.maven.model.profile.ProfileSelector;
+import org.apache.maven.model.superpom.SuperPomProvider;
+import org.apache.maven.model.v4.MavenModelVersion;
+import org.apache.maven.model.validation.ModelValidator;
+import org.apache.maven.project.MavenProject;
+import org.apache.maven.project.ProjectBuildingRequest;
+import org.apache.maven.project.ProjectModelResolver;
+import org.apache.maven.repository.internal.ModelCacheFactory;
+import org.codehaus.plexus.PlexusContainer;
+import
org.codehaus.plexus.component.repository.exception.ComponentLookupException;
+import org.eclipse.aether.RepositorySystem;
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.RequestTrace;
+import org.eclipse.aether.impl.RemoteRepositoryManager;
+
+@Named
+class DefaultConsumerPomBuilder implements ConsumerPomBuilder {
+
+private static final String BOM_PACKAGING = "bom";
+
+public static final String POM_PACKAGING = "pom";
+
+@Inject
+PlexusContainer container;
+
+@Inject
+ModelCacheFactory modelCacheFactory;
+
+public Model build(RepositorySystemSession session, MavenProject project,
Path src)
+throws ModelBuildingException, ComponentLookupException {
+Model model = project.getModel().getDelegate();
+String packaging = model.getPackaging();
+if (POM_PACKAGING.equals(packaging)) {
+return buildPom(session, project, src);
+} else {
+return buildNonPom(session, project, src);
+}
+}
+
+protected Model buildPom(RepositorySystemSession session, MavenProject
project, Path src)
+throws ModelBuildingException, ComponentLookupException {
+
Re: [PR] [MNG-7945] Fix profile settings being injected into consumer POM [maven]
elharo commented on code in PR #1323:
URL: https://github.com/apache/maven/pull/1323#discussion_r1407676979
##
maven-core/src/main/java/org/apache/maven/internal/transformation/impl/DefaultConsumerPomBuilder.java:
##
@@ -0,0 +1,230 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.internal.transformation.impl;
+
+import javax.inject.Inject;
+import javax.inject.Named;
+
+import java.nio.file.Path;
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.List;
+import java.util.Map;
+import java.util.Properties;
+import java.util.stream.Collectors;
+
+import org.apache.maven.api.model.DistributionManagement;
+import org.apache.maven.api.model.Model;
+import org.apache.maven.api.model.ModelBase;
+import org.apache.maven.api.model.Profile;
+import org.apache.maven.api.model.Repository;
+import org.apache.maven.model.building.DefaultModelBuilder;
+import org.apache.maven.model.building.DefaultModelBuilderFactory;
+import org.apache.maven.model.building.DefaultModelBuildingRequest;
+import org.apache.maven.model.building.ModelBuildingException;
+import org.apache.maven.model.building.ModelBuildingRequest;
+import org.apache.maven.model.building.ModelBuildingResult;
+import org.apache.maven.model.building.ModelProblemCollector;
+import org.apache.maven.model.building.ModelProcessor;
+import org.apache.maven.model.composition.DependencyManagementImporter;
+import org.apache.maven.model.inheritance.InheritanceAssembler;
+import org.apache.maven.model.interpolation.ModelInterpolator;
+import org.apache.maven.model.management.DependencyManagementInjector;
+import org.apache.maven.model.management.PluginManagementInjector;
+import org.apache.maven.model.normalization.ModelNormalizer;
+import org.apache.maven.model.path.ModelPathTranslator;
+import org.apache.maven.model.path.ModelUrlNormalizer;
+import org.apache.maven.model.plugin.LifecycleBindingsInjector;
+import org.apache.maven.model.plugin.PluginConfigurationExpander;
+import org.apache.maven.model.plugin.ReportConfigurationExpander;
+import org.apache.maven.model.profile.DefaultProfileSelector;
+import org.apache.maven.model.profile.ProfileActivationContext;
+import org.apache.maven.model.profile.ProfileInjector;
+import org.apache.maven.model.profile.ProfileSelector;
+import org.apache.maven.model.superpom.SuperPomProvider;
+import org.apache.maven.model.v4.MavenModelVersion;
+import org.apache.maven.model.validation.ModelValidator;
+import org.apache.maven.project.MavenProject;
+import org.apache.maven.project.ProjectBuildingRequest;
+import org.apache.maven.project.ProjectModelResolver;
+import org.apache.maven.repository.internal.ModelCacheFactory;
+import org.codehaus.plexus.PlexusContainer;
+import
org.codehaus.plexus.component.repository.exception.ComponentLookupException;
+import org.eclipse.aether.RepositorySystem;
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.RequestTrace;
+import org.eclipse.aether.impl.RemoteRepositoryManager;
+
+@Named
+class DefaultConsumerPomBuilder implements ConsumerPomBuilder {
+
+private static final String BOM_PACKAGING = "bom";
+
+public static final String POM_PACKAGING = "pom";
+
+@Inject
+PlexusContainer container;
+
+@Inject
+ModelCacheFactory modelCacheFactory;
+
+public Model build(RepositorySystemSession session, MavenProject project,
Path src)
+throws ModelBuildingException, ComponentLookupException {
+Model model = project.getModel().getDelegate();
+String packaging = model.getPackaging();
+if (POM_PACKAGING.equals(packaging)) {
+return buildPom(session, project, src);
+} else {
+return buildNonPom(session, project, src);
+}
+}
+
+protected Model buildPom(RepositorySystemSession session, MavenProject
project, Path src)
+throws ModelBuildingException, ComponentLookupException {
+ModelBuildingResult result = buildModel(session, project, src);
+Model model = result.getRawModel().getDelegate();
+return transform(model);
+}
+
+protected Model buildNonPom(RepositorySystemSession session, MavenProject
