[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=17792317#comment-17792317
]
ASF GitHub Bot commented on MSHARED-1285:
-
laeubi commented on PR #77:
URL: https://github.com/apache/maven-filtering/pull/77#issuecomment-1837037738
@lalmeras great to see you make progress on this :+1:
For the second case assume the following:
1. A resource (e.g. `source.txt`) was recently copied to the output folder
`output`
2. There is another resource (e.g. `source2.txt`) also copied to the output
folder `output`
3. Now it happens that `output/source.txt` is modified e.g. by the user
outside the scope of changes
4. Now `source2.txt` is modified and only this edit is part of the change
scope
What happens now is that `source2.txt` is copied correctly to folder
`output` as it is part of the changed files, but `source.txt` is not copied
even though it is out-of-date with `output/source.txt`.
> 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-1837037738 @lalmeras great to see you make progress on this :+1: For the second case assume the following: 1. A resource (e.g. `source.txt`) was recently copied to the output folder `output` 2. There is another resource (e.g. `source2.txt`) also copied to the output folder `output` 3. Now it happens that `output/source.txt` is modified e.g. by the user outside the scope of changes 4. Now `source2.txt` is modified and only this edit is part of the change scope What happens now is that `source2.txt` is copied correctly to folder `output` as it is part of the changed files, but `source.txt` is not copied even though it is out-of-date with `output/source.txt`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Moten updated MBUILDCACHE-76:
--
Description:
When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension does
not detect this and skips all modules in a multimodule project (and fails when
it encounters a module that depends on one of the other modules (a maven
plugin)).
To duplicate
```
git clone [https://github.com/davidmoten/openapi-codegen.git]
cd openapi-codegen
mvn clean install
mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
mvn clean install
```
Output:
```
[ERROR] Invalid plugin descriptor for
com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
(/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
```
Here is my maven-build-cache-config.xml:
```
http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
[https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
true
{{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
{*}Jenkinsfile{*}
./idea/*
systemPropertyVariables
install
deploy
```
was:
When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension does
not detect this and skips all modules in a multimodule project (and fails when
it encounters a module that depends on one of the other modules).
To duplicate
```
git clone [https://github.com/davidmoten/openapi-codegen.git]
cd openapi-codegen
mvn clean install
mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
mvn clean install
```
Output:
```
[ERROR] Invalid plugin descriptor for
com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
(/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
```
Here is my maven-build-cache-config.xml:
```
http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd;>
true
\{*.java,*.xml,*.properties,*.mod,*.adoc}
*Jenkinsfile*
./idea/*
systemPropertyVariables
install
deploy
```
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Priority: Minor
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
>
[jira] [Updated] (SUREFIRE-2219) Option to include stdOut/stdErr console logs into test report
[
https://issues.apache.org/jira/browse/SUREFIRE-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Kriegisch updated SUREFIRE-2219:
--
Description:
Surefire report XML includes tags capturing console logs, e.g.
{{testsuite/testcase/system-err}}:
!image-2023-12-02-11-16-11-109.png!
As a report reader, I want to see the stdOut/stdErr console logs per test case
in the HTML report, ideally in a monotype font to easily be able to read stack
traces.
This requirement has been discussed online a lot, e.g. on Stack Overflow or
Reddit. I wonder why such a feature is missing. The HTML report basically being
an XML transformation from the surefire report, it should not be super
complicated to implement.
was:
Surefire report XML includes tags capturing console logs, e.g.
{{testsuite/testcase/system-err}}:
!image-2023-12-02-11-16-11-109.png!
As a report reader, I want to see the stdOut/stdErr console logs per test case
in the HTML report, ideally in a monotype font to easily be able to read stack
traces.
This requirement has been discussed online a lot, e.g. on Stack Overflow or
Reddit. I wonder why such a feature is missing. The HTML report basically being
an XML transformation from the surefire report, it should not be super
complicated to implement that.
> Option to include stdOut/stdErr console logs into test report
> -
>
> Key: SUREFIRE-2219
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2219
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Report Plugin
>Affects Versions: 3.2.2
>Reporter: Alexander Kriegisch
>Priority: Major
> Attachments: image-2023-12-02-11-16-11-109.png
>
>
> Surefire report XML includes tags capturing console logs, e.g.
> {{testsuite/testcase/system-err}}:
> !image-2023-12-02-11-16-11-109.png!
> As a report reader, I want to see the stdOut/stdErr console logs per test
> case in the HTML report, ideally in a monotype font to easily be able to read
> stack traces.
> This requirement has been discussed online a lot, e.g. on Stack Overflow or
> Reddit. I wonder why such a feature is missing. The HTML report basically
> being an XML transformation from the surefire report, it should not be super
> complicated to implement.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2219) Option to include stdOut/stdErr console logs into test report
[
https://issues.apache.org/jira/browse/SUREFIRE-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Kriegisch updated SUREFIRE-2219:
--
Description:
Surefire report XML includes tags capturing console logs, e.g.
{{testsuite/testcase/system-err}}:
!image-2023-12-02-11-16-11-109.png!
As a report reader, I want to see the stdOut/stdErr console logs per test case
in the HTML report, ideally in a monotype font to easily be able to read stack
traces.
This requirement has been discussed online a lot, e.g. on Stack Overflow or
Reddit. I wonder why such a feature is missing. The HTML report basically being
an XML transformation from the surefire report, it should not be super
complicated to implement that.
was:
Surefire report XML includes tags capturing console logs, e.g.
{{testsuite/testcase/system-err}}:
!image-2023-12-02-11-16-11-109.png!
As an report reader, I want to see the stdOut/stdErr console logs per test case
in the HTML report, ideally in a monotype font to easily be able to read stack
traces.
This requirement has been discussed online a lot, e.g. on Stack Overflow or
Reddit. I wonder why such a feature is missing. The HTML report basically being
an XML transformation from the surefire report, it should not be super
complicated to implement that.
> Option to include stdOut/stdErr console logs into test report
> -
>
> Key: SUREFIRE-2219
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2219
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Report Plugin
>Affects Versions: 3.2.2
>Reporter: Alexander Kriegisch
>Priority: Major
> Attachments: image-2023-12-02-11-16-11-109.png
>
>
> Surefire report XML includes tags capturing console logs, e.g.
> {{testsuite/testcase/system-err}}:
> !image-2023-12-02-11-16-11-109.png!
> As a report reader, I want to see the stdOut/stdErr console logs per test
> case in the HTML report, ideally in a monotype font to easily be able to read
> stack traces.
> This requirement has been discussed online a lot, e.g. on Stack Overflow or
> Reddit. I wonder why such a feature is missing. The HTML report basically
> being an XML transformation from the surefire report, it should not be super
> complicated to implement that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SUREFIRE-2219) Option to include stdOut/stdErr console logs into test report
Alexander Kriegisch created SUREFIRE-2219:
-
Summary: Option to include stdOut/stdErr console logs into test
report
Key: SUREFIRE-2219
URL: https://issues.apache.org/jira/browse/SUREFIRE-2219
Project: Maven Surefire
Issue Type: New Feature
Components: Maven Surefire Report Plugin
Affects Versions: 3.2.2
Reporter: Alexander Kriegisch
Attachments: image-2023-12-02-11-16-11-109.png
Surefire report XML includes tags capturing console logs, e.g.
{{testsuite/testcase/system-err}}:
!image-2023-12-02-11-16-11-109.png!
As an report reader, I want to see the stdOut/stdErr console logs per test case
in the HTML report, ideally in a monotype font to easily be able to read stack
traces.
This requirement has been discussed online a lot, e.g. on Stack Overflow or
Reddit. I wonder why such a feature is missing. The HTML report basically being
an XML transformation from the surefire report, it should not be super
complicated to implement that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Moten updated MBUILDCACHE-76:
--
Description:
When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension does
not detect this and skips all modules in a multimodule project (and fails when
it encounters a module that depends on one of the other modules).
To duplicate
```
git clone [https://github.com/davidmoten/openapi-codegen.git]
cd openapi-codegen
mvn clean install
mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
mvn clean install
```
Output:
```
[ERROR] Invalid plugin descriptor for
com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
(/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
```
Here is my maven-build-cache-config.xml:
```
http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd;>
true
\{*.java,*.xml,*.properties,*.mod,*.adoc}
*Jenkinsfile*
./idea/*
systemPropertyVariables
install
deploy
```
was:
When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension does
not detect this and skips all modules in a multimodule project (and fails when
it encounters a module that depends on one of the other modules).
To duplicate
```
git clone [https://github.com/davidmoten/openapi-codegen.git]
cd openapi-codegen
mvn clean install
mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
mvn clean install
```
Output:
```
[ERROR] Invalid plugin descriptor for
com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
(/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
```
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Priority: Minor
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules).
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd;>
>
> true
>
>
>
>
>
> \{*.java,*.xml,*.properties,*.mod,*.adoc}
>
> *Jenkinsfile*
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
[jira] [Created] (MBUILDCACHE-76) pom project version change not detected
Dave Moten created MBUILDCACHE-76: - Summary: pom project version change not detected Key: MBUILDCACHE-76 URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76 Project: Maven Build Cache Extension Issue Type: Bug Affects Versions: 1.1.0 Reporter: Dave Moten When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension does not detect this and skips all modules in a multimodule project (and fails when it encounters a module that depends on one of the other modules). To duplicate ``` git clone [https://github.com/davidmoten/openapi-codegen.git] cd openapi-codegen mvn clean install mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT mvn clean install ``` Output: ``` [ERROR] Invalid plugin descriptor for com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar), Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1] ``` -- 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=17792200#comment-17792200
]
ASF GitHub Bot commented on MSHARED-1285:
-
lalmeras commented on PR #77:
URL: https://github.com/apache/maven-filtering/pull/77#issuecomment-1836797752
I update my branch
https://github.com/lalmeras/maven-filtering/commits/MSHARED-1285 with the
following change :
* rebased on origin/master with the refactored tests
* I added a test-case demonstrating the usecase described by @laeubi : if
target files are removed, an incremental build fails to regenerate missing
resources
> Another case is that you modify the target file (but not the source) then
the mojo will never update that file as long as one do not modify the source
file.
@laeubi I'm not sure to understand what is the current / expected behavior
for this use-case. Can you give a more precise description ?
> 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-1836797752 I update my branch https://github.com/lalmeras/maven-filtering/commits/MSHARED-1285 with the following change : * rebased on origin/master with the refactored tests * I added a test-case demonstrating the usecase described by @laeubi : if target files are removed, an incremental build fails to regenerate missing resources > Another case is that you modify the target file (but not the source) then the mojo will never update that file as long as one do not modify the source file. @laeubi I'm not sure to understand what is the current / expected behavior for this use-case. Can you give a more precise description ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (ARCHETYPE-64) groupId and version redundant when executing archetype with parent
[
https://issues.apache.org/jira/browse/ARCHETYPE-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792195#comment-17792195
]
ASF GitHub Bot commented on ARCHETYPE-64:
-
WolfgangHG commented on PR #160:
URL: https://github.com/apache/maven-archetype/pull/160#issuecomment-1836736679
About empty directories: one could think that it could be feature in the new
version that empty directories are also included in the jar file. But I tried
to add empty folders in different places in the archetype source directory
structure, and none of them was included in the archetype jar (using archetype
plugin 3.2.1, which creates jar entries for all directories, but without my
workaround).
Several StackOverflow answers suggest to achieve this by using filesets.
Then I found this suggestion which does not work any more with my
workaround:
https://stackoverflow.com/questions/2786966/how-to-create-empty-folders-with-maven-archetype
When adding the "maven-resources-plugin" with "includeEmptyDirs=true", then
this will work with 3.2.1 as expected: all empty dirs are added. But my
workaround breaks this code.
The only solution I could think of: parse "archetype-metadata.xml" and
exclude all directories that are defined as root dirs of filesets. But how to
do this and how to handle the excludes? As I wrote above, I did not manage to
specify exclusions on "DefaultFileSet".
> groupId and version redundant when executing archetype with parent
> --
>
> Key: ARCHETYPE-64
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-64
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Generator
>Affects Versions: 1.0-alpha-4
>Reporter: Rod Coffin
>Priority: Major
> Attachments: ARCHETYPE-64-maven-archetype-core.patch
>
>
> Running the archetype plugin in a parent project creates a sub-project
> (module). Although the parent elements are properly set in the child pom,
> the group id and version are repeated. These are not necessary since they
> will be inherited from the parent. Ex:
> {code:xml}
>
> parent
> com.rfc.archetypes.example
> 1.0-SNAPSHOT
>
> 4.0.0
> com.rfc.archetypes.example
> example-web
> 1.0-SNAPSHOT
> {code}
> Having this information is two places is bad in principle because it violates
> the DRY principle and in practice because they can get out of sync
> accidentally and it could be confusing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [ARCHETYPE-64] work around warning 'Don't override file...' [maven-archetype]
WolfgangHG commented on PR #160: URL: https://github.com/apache/maven-archetype/pull/160#issuecomment-1836736679 About empty directories: one could think that it could be feature in the new version that empty directories are also included in the jar file. But I tried to add empty folders in different places in the archetype source directory structure, and none of them was included in the archetype jar (using archetype plugin 3.2.1, which creates jar entries for all directories, but without my workaround). Several StackOverflow answers suggest to achieve this by using filesets. Then I found this suggestion which does not work any more with my workaround: https://stackoverflow.com/questions/2786966/how-to-create-empty-folders-with-maven-archetype When adding the "maven-resources-plugin" with "includeEmptyDirs=true", then this will work with 3.2.1 as expected: all empty dirs are added. But my workaround breaks this code. The only solution I could think of: parse "archetype-metadata.xml" and exclude all directories that are defined as root dirs of filesets. But how to do this and how to handle the excludes? As I wrote above, I did not manage to specify exclusions on "DefaultFileSet". -- 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] (MDEP-902) plugin has dependency on log4j version with vulnerability
[ https://issues.apache.org/jira/browse/MDEP-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792168#comment-17792168 ] Michael Osipov commented on MDEP-902: - Patches are welcome. > plugin has dependency on log4j version with vulnerability > - > > Key: MDEP-902 > URL: https://issues.apache.org/jira/browse/MDEP-902 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.6.1 >Reporter: Cary Mader >Priority: Major > > We have Maven projects using dependency plugin, when it executes it's causing > maven to pull the log4j jar version 1.2.12 to local maven repos on build > servers, and then scanners are flagging that jar as having a vulnerability, > which causes us a lot of noise. > dependency gav is log4j / log4j / 1.2.12 > have seen this with latest version, 3.6.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MDEP-902) plugin has dependency on log4j version with vulnerability
Cary Mader created MDEP-902: --- Summary: plugin has dependency on log4j version with vulnerability Key: MDEP-902 URL: https://issues.apache.org/jira/browse/MDEP-902 Project: Maven Dependency Plugin Issue Type: Dependency upgrade Affects Versions: 3.6.1 Reporter: Cary Mader We have Maven projects using dependency plugin, when it executes it's causing maven to pull the log4j jar version 1.2.12 to local maven repos on build servers, and then scanners are flagging that jar as having a vulnerability, which causes us a lot of noise. dependency gav is log4j / log4j / 1.2.12 have seen this with latest version, 3.6.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [PR-104] bugfix / enhancements restoration of outputs on disk [maven-build-cache-extension]
AlexanderAshitkin commented on code in PR #104:
URL:
https://github.com/apache/maven-build-cache-extension/pull/104#discussion_r1412177562
##
src/main/java/org/apache/maven/buildcache/artifact/OutputType.java:
##
@@ -0,0 +1,49 @@
+/*
+ * 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.buildcache.artifact;
+
+public enum OutputType {
+// generated project artefact
+ARTEFACT(""),
Review Comment:
typo "I"
--
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] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with Maven Failsafe Plugin
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792059#comment-17792059 ] ASF GitHub Bot commented on SUREFIRE-2211: -- michael-o commented on PR #689: URL: https://github.com/apache/maven-surefire/pull/689#issuecomment-1836148945 > Sorry, I didn't see your changes. I applied this PR's changes to the current master branch (and removed another tab character in my changes, which was interfering with the build before). I hope everything fits now. Still not the commit message I have applied. > additionalClasspathElement with UNC path not working with Maven Failsafe > Plugin > --- > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Assignee: Michael Osipov >Priority: Major > Fix For: 3.2.3 > > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [SUREFIRE-2211] Fix UNC classpath elements [maven-surefire]
michael-o commented on PR #689: URL: https://github.com/apache/maven-surefire/pull/689#issuecomment-1836148945 > Sorry, I didn't see your changes. I applied this PR's changes to the current master branch (and removed another tab character in my changes, which was interfering with the build before). I hope everything fits now. Still not the commit message I have applied. -- 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] (MRELEASE-1109) update-versions removes the CI-friendly ${revisions}
[
https://issues.apache.org/jira/browse/MRELEASE-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792048#comment-17792048
]
ASF GitHub Bot commented on MRELEASE-1109:
--
mkolesnikov commented on code in PR #202:
URL: https://github.com/apache/maven-release/pull/202#discussion_r1412084550
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/RewritePomsForReleasePhase.java:
##
@@ -214,6 +217,15 @@ private boolean translateScm(
return result;
}
+@Override
Review Comment:
That one I missed and forgot to revert. It was part of the spontaneous
refactoring, the goal is to make Abstract classes to be abstract as they
intended to be by their names, then to combine CI Friendly logic in one place,
but the code is more coupled then I thought. So I gave up on it for now. Maybe
someday I'll complete it
> update-versions removes the CI-friendly ${revisions}
>
>
> Key: MRELEASE-1109
> URL: https://issues.apache.org/jira/browse/MRELEASE-1109
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare, update-versions
>Affects Versions: 2.5.3, 3.0.0-M7
>Reporter: Marcel Stör
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: next-release
>
>
> Given: a project using CI-friendly versions as per
> [https://maven.apache.org/maven-ci-friendly.html]
> {code:xml}
> ${revision}
> ...
>
> 1.0.0-SNAPSHOT
>
> {code}
> If I run {{mvn release:update-versions}} (with or without
> {{{}-DautoVersionSubmodules=true{}}}) I expect the release plugin to change
> the {{$revision}} property. Instead it blindly replaces
> {{${revision}}} with the hard-coded version set on the CLI.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRELEASE-1109] Snapshot detection and support for versions like `${revision}${sha1}${changelist}` [maven-release]
mkolesnikov commented on code in PR #202: URL: https://github.com/apache/maven-release/pull/202#discussion_r1412084550 ## maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/RewritePomsForReleasePhase.java: ## @@ -214,6 +217,15 @@ private boolean translateScm( return result; } +@Override Review Comment: That one I missed and forgot to revert. It was part of the spontaneous refactoring, the goal is to make Abstract classes to be abstract as they intended to be by their names, then to combine CI Friendly logic in one place, but the code is more coupled then I thought. So I gave up on it for now. Maybe someday I'll complete 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] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with Maven Failsafe Plugin
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792046#comment-17792046 ] ASF GitHub Bot commented on SUREFIRE-2211: -- robseidel commented on PR #689: URL: https://github.com/apache/maven-surefire/pull/689#issuecomment-1836089883 Sorry, I didn't see your changes. I applied this PR's changes to the current master branch (and removed another tab character in my changes, which was interfering with the build before). I hope everything fits now. > additionalClasspathElement with UNC path not working with Maven Failsafe > Plugin > --- > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Assignee: Michael Osipov >Priority: Major > Fix For: 3.2.3 > > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [SUREFIRE-2211] Fix UNC classpath elements [maven-surefire]
robseidel commented on PR #689: URL: https://github.com/apache/maven-surefire/pull/689#issuecomment-1836089883 Sorry, I didn't see your changes. I applied this PR's changes to the current master branch (and removed another tab character in my changes, which was interfering with the build before). I hope everything fits 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
[jira] [Commented] (SUREFIRE-2218) Add support for fetching test classes from a jar
[
https://issues.apache.org/jira/browse/SUREFIRE-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792014#comment-17792014
]
Sebb commented on SUREFIRE-2218:
That would be fine as a name.
BTW, the documentation is a bit ambiguous as to what 'test classpath' means.
AFAICT it is only used for the classes under test, but the description for
{{testClassesDirectory}} suggests otherwise.
> Add support for fetching test classes from a jar
>
>
> Key: SUREFIRE-2218
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2218
> Project: Maven Surefire
> Issue Type: New Feature
>Reporter: Sebb
>Priority: Minor
>
> Surefire provides a way to test classes that are in a jar.
> The parameter additionalClasspathElements can used to specify the jar (and
> the
> classesDirectory parameter can be redirected to prevent access to the default
> classes)
>
> It would be useful to be able to do the same for the test classes, i.e.
> provide a parameter that can be used to update the classpath used to find
> tests
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] refactor IncrementalResourceFilteringTest [maven-filtering]
elharo merged PR #82: URL: https://github.com/apache/maven-filtering/pull/82 -- 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] Mavek 3.9.6 release notes [maven-site]
cstamas merged PR #469: URL: https://github.com/apache/maven-site/pull/469 -- 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] (SUREFIRE-2218) Add support for fetching test classes from a jar
[
https://issues.apache.org/jira/browse/SUREFIRE-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17791994#comment-17791994
]
Michael Osipov commented on SUREFIRE-2218:
--
You mean {{additionalTestClasspathElements}}?
> Add support for fetching test classes from a jar
>
>
> Key: SUREFIRE-2218
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2218
> Project: Maven Surefire
> Issue Type: New Feature
>Reporter: Sebb
>Priority: Minor
>
> Surefire provides a way to test classes that are in a jar.
> The parameter additionalClasspathElements can used to specify the jar (and
> the
> classesDirectory parameter can be redirected to prevent access to the default
> classes)
>
> It would be useful to be able to do the same for the test classes, i.e.
> provide a parameter that can be used to update the classpath used to find
> tests
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with Maven Failsafe Plugin
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17791955#comment-17791955 ] Robert Seidel edited comment on SUREFIRE-2211 at 12/1/23 8:50 AM: -- Sorry again. I didn't rerun the build after adding the assumption. I've removed the line that was too much, rerun the test locally and updated the PR. was (Author: JIRAUSER295788): Sorry again. I didn't rerun the build after adding the assumption. I've removed the line that was too much an updated the PR. > additionalClasspathElement with UNC path not working with Maven Failsafe > Plugin > --- > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Assignee: Michael Osipov >Priority: Major > Fix For: 3.2.3 > > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with Maven Failsafe Plugin
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17791955#comment-17791955 ] Robert Seidel commented on SUREFIRE-2211: - Sorry again. I didn't rerun the build after adding the assumption. I've removed the line that was too much an updated the PR. > additionalClasspathElement with UNC path not working with Maven Failsafe > Plugin > --- > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Assignee: Michael Osipov >Priority: Major > Fix For: 3.2.3 > > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-381) Refactoring needed for isDependencyChanged / Using fileExtensions (AbstractCompilerMojo)
[
https://issues.apache.org/jira/browse/MCOMPILER-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17791940#comment-17791940
]
ASF GitHub Bot commented on MCOMPILER-381:
--
slawekjaranowski commented on PR #181:
URL:
https://github.com/apache/maven-compiler-plugin/pull/181#issuecomment-1835652536
@olamy - any more remarks on it, I would like to merge
> Refactoring needed for isDependencyChanged / Using fileExtensions
> (AbstractCompilerMojo)
>
>
> Key: MCOMPILER-381
> URL: https://issues.apache.org/jira/browse/MCOMPILER-381
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.12.0
>
>
> The code in the class AbstractCompilerMojo has a method
> {{isDependencyChanged}} which uses the attribute {{fileExtensions}} which is
> being changed within the {{isDependencyChanged}} method. This attribute is
> also being used by the method {{hasNewFile}} which is a kind of confusing (a
> control via a global variable).
> Furthermore a change in {{isDependencyChanged}} where replacing {{".class"}}
> with {{"class"}} results in a [fail which is described here|MCOMPILER-379].
> It should be investigated how this code can be made more clear and maybe
> easier to understand.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MCOMPILER-381] - Refactor incremental detection [maven-compiler-plugin]
slawekjaranowski commented on PR #181: URL: https://github.com/apache/maven-compiler-plugin/pull/181#issuecomment-1835652536 @olamy - any more remarks on it, I would like to merge -- 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
