[jira] [Commented] (MDEP-932) Don't log successful file copies
[
https://issues.apache.org/jira/browse/MDEP-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849058#comment-17849058
]
Elliotte Rusty Harold commented on MDEP-932:
Might be a moot point after
https://github.com/apache/maven-dependency-plugin/pull/389 lands
> Don't log successful file copies
>
>
> Key: MDEP-932
> URL: https://issues.apache.org/jira/browse/MDEP-932
> Project: Maven Dependency Plugin
> Issue Type: Improvement
>Reporter: Elliotte Rusty Harold
>Priority: Minor
>
> In AbstractDependencyMojo
> Either a file is copied successfully and no one wants to read this message or
> it fails and an exception is thrown. Either way, the log message simply isn't
> needed and gets in the way of debugging real failures.
> /**
> * Does the actual copy of the file and logging.
> *
> * @param artifact represents the file to copy.
> * @param destFile file name of destination file.
> * @throws MojoExecutionException with a message if an error occurs.
> */
> protected void copyFile(File artifact, File destFile) throws
> MojoExecutionException {
> try {
> getLog().info("Copying "
> + (this.outputAbsoluteArtifactFilename ?
> artifact.getAbsolutePath() : artifact.getName()) + " to "
> + destFile);
> if (artifact.isDirectory()) {
> // usual case is a future jar packaging, but there are
> special cases: classifier and other packaging
> throw new MojoExecutionException("Artifact has not been
> packaged yet. When used on reactor artifact, "
> + "copy should be executed after packaging: see
> MDEP-187.");
> }
> FileUtils.copyFile(artifact, destFile);
> buildContext.refresh(destFile);
> } catch (IOException e) {
> throw new MojoExecutionException("Error copying artifact from " +
> artifact + " to " + destFile, e);
> }
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MDEP-932) Don't log successful file copies
[
https://issues.apache.org/jira/browse/MDEP-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MDEP-932:
---
Description:
In AbstractDependencyMojo
Either a file is copied successfully and no one wants to read this message or
it fails and an exception is thrown. Either way, the log message simply isn't
needed and gets in the way of debugging real failures.
/**
* Does the actual copy of the file and logging.
*
* @param artifact represents the file to copy.
* @param destFile file name of destination file.
* @throws MojoExecutionException with a message if an error occurs.
*/
protected void copyFile(File artifact, File destFile) throws
MojoExecutionException {
try {
getLog().info("Copying "
+ (this.outputAbsoluteArtifactFilename ?
artifact.getAbsolutePath() : artifact.getName()) + " to "
+ destFile);
if (artifact.isDirectory()) {
// usual case is a future jar packaging, but there are special
cases: classifier and other packaging
throw new MojoExecutionException("Artifact has not been
packaged yet. When used on reactor artifact, "
+ "copy should be executed after packaging: see
MDEP-187.");
}
FileUtils.copyFile(artifact, destFile);
buildContext.refresh(destFile);
} catch (IOException e) {
throw new MojoExecutionException("Error copying artifact from " +
artifact + " to " + destFile, e);
}
}
was:
In AbstarctDependencyMojo
Either a is file copied successfully and no one wants to read this message or
it fails and an exception is thrown. Either way, the log message simply isn';t
needed and gets in the way of debugging real failures.
/**
* Does the actual copy of the file and logging.
*
* @param artifact represents the file to copy.
* @param destFile file name of destination file.
* @throws MojoExecutionException with a message if an error occurs.
*/
protected void copyFile(File artifact, File destFile) throws
MojoExecutionException {
try {
getLog().info("Copying "
+ (this.outputAbsoluteArtifactFilename ?
artifact.getAbsolutePath() : artifact.getName()) + " to "
+ destFile);
if (artifact.isDirectory()) {
// usual case is a future jar packaging, but there are special
cases: classifier and other packaging
throw new MojoExecutionException("Artifact has not been
packaged yet. When used on reactor artifact, "
+ "copy should be executed after packaging: see
MDEP-187.");
}
FileUtils.copyFile(artifact, destFile);
buildContext.refresh(destFile);
} catch (IOException e) {
throw new MojoExecutionException("Error copying artifact from " +
artifact + " to " + destFile, e);
}
}
> Don't log successful file copies
>
>
> Key: MDEP-932
> URL: https://issues.apache.org/jira/browse/MDEP-932
> Project: Maven Dependency Plugin
> Issue Type: Improvement
>Reporter: Elliotte Rusty Harold
>Priority: Minor
>
> In AbstractDependencyMojo
> Either a file is copied successfully and no one wants to read this message or
> it fails and an exception is thrown. Either way, the log message simply isn't
> needed and gets in the way of debugging real failures.
> /**
> * Does the actual copy of the file and logging.
> *
> * @param artifact represents the file to copy.
> * @param destFile file name of destination file.
> * @throws MojoExecutionException with a message if an error occurs.
> */
> protected void copyFile(File artifact, File destFile) throws
> MojoExecutionException {
> try {
> getLog().info("Copying "
> + (this.outputAbsoluteArtifactFilename ?
> artifact.getAbsolutePath() : artifact.getName()) + " to "
> + destFile);
> if (artifact.isDirectory()) {
> // usual case is a future jar packaging, but there are
> special cases: classifier and other packaging
> throw new MojoExecutionException("Artifact has not been
> packaged yet. When used on reactor artifact, "
> + "copy should be executed after packaging: see
> MDEP-187.");
> }
> FileUtils.copyFile(artifact, destFile);
> buildContext.refresh(destFile);
> } catch (IOException e) {
> throw new MojoExecutionException("Error copying artifact from " +
> artifact + " to " + destFile, e);
> }
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPMD-391) Log what developers care about and not what they don't
[ https://issues.apache.org/jira/browse/MPMD-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849039#comment-17849039 ] Elliotte Rusty Harold commented on MPMD-391: I don't know. If so it's probably part of maven core rather than this plugin since it comes up in every failure from any plugin. > Log what developers care about and not what they don't > -- > > Key: MPMD-391 > URL: https://issues.apache.org/jira/browse/MPMD-391 > Project: Maven PMD Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Major > > Here's output from a recent PMD plugin run that failed: > [INFO] >>> maven-pmd-plugin:3.21.2:check (default-cli) > :pmd @ commons-io >>> > [INFO] > [INFO] --- maven-pmd-plugin:3.21.2:pmd (pmd) @ commons-io --- > [INFO] PMD version: 6.55.0 > [INFO] Rendering content with > org.apache.maven.skins:maven-default-skin:jar:1.3 skin. > [INFO] > [INFO] <<< maven-pmd-plugin:3.21.2:check (default-cli) < :pmd @ commons-io <<< > [INFO] > [INFO] > [INFO] --- maven-pmd-plugin:3.21.2:check (default-cli) @ commons-io --- > [INFO] PMD version: 6.55.0 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 05:22 min > [INFO] Finished at: 2024-01-14T14:11:30Z > [INFO] > > Error: Failed to execute goal > org.apache.maven.plugins:maven-pmd-plugin:3.21.2:check (default-cli) on > project commons-io: You have 1 PMD violation. For more details see: > /home/runner/work/commons-io/commons-io/target/pmd.xml -> [Help 1] > Error: > Error: To see the full stack trace of the errors, re-run Maven with the -e > switch. > Error: Re-run Maven using the -X switch to enable full debug logging. > Error: > Error: For more information about the errors and possible solutions, please > read the following articles: > Error: [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > Error: Process completed with exit code 1. > Things I don't care about that are printed: > * PMD version > * Doxia skin > * Blank lines > * Total time > * Timestamp when it finished > * Generic information about Mojo failures > * Exit code from Mojo > The one thing I care about: > * The actual error that caused the failure > Everything in the first list can be hidden in some random log file no one > will ever look at. Everything in the second list should be front and center. > Instead Maven gets this exactly backwards, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MDEP-932) Don't log successful file copies
Elliotte Rusty Harold created MDEP-932:
--
Summary: Don't log successful file copies
Key: MDEP-932
URL: https://issues.apache.org/jira/browse/MDEP-932
Project: Maven Dependency Plugin
Issue Type: Improvement
Reporter: Elliotte Rusty Harold
In AbstarctDependencyMojo
Either a is file copied successfully and no one wants to read this message or
it fails and an exception is thrown. Either way, the log message simply isn';t
needed and gets in the way of debugging real failures.
/**
* Does the actual copy of the file and logging.
*
* @param artifact represents the file to copy.
* @param destFile file name of destination file.
* @throws MojoExecutionException with a message if an error occurs.
*/
protected void copyFile(File artifact, File destFile) throws
MojoExecutionException {
try {
getLog().info("Copying "
+ (this.outputAbsoluteArtifactFilename ?
artifact.getAbsolutePath() : artifact.getName()) + " to "
+ destFile);
if (artifact.isDirectory()) {
// usual case is a future jar packaging, but there are special
cases: classifier and other packaging
throw new MojoExecutionException("Artifact has not been
packaged yet. When used on reactor artifact, "
+ "copy should be executed after packaging: see
MDEP-187.");
}
FileUtils.copyFile(artifact, destFile);
buildContext.refresh(destFile);
} catch (IOException e) {
throw new MojoExecutionException("Error copying artifact from " +
artifact + " to " + destFile, e);
}
}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MDEP-799) improve mvn dependency:tree - add optional JSON output of the results
[ https://issues.apache.org/jira/browse/MDEP-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MDEP-799. -- > improve mvn dependency:tree - add optional JSON output of the results > - > > Key: MDEP-799 > URL: https://issues.apache.org/jira/browse/MDEP-799 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: tree >Reporter: Zhenxu Ke >Priority: Major > Fix For: 3.7.0 > > > I'd like to add an output type JSON, will open a pull request soon -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MDEP-799) improve mvn dependency:tree - add optional JSON output of the results
[ https://issues.apache.org/jira/browse/MDEP-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MDEP-799. Fix Version/s: 3.7.0 Resolution: Fixed > improve mvn dependency:tree - add optional JSON output of the results > - > > Key: MDEP-799 > URL: https://issues.apache.org/jira/browse/MDEP-799 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: tree >Reporter: Zhenxu Ke >Priority: Major > Fix For: 3.7.0 > > > I'd like to add an output type JSON, will open a pull request soon -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MDEP-931) AbstractSerializingVisitor should not use PrintWriter
Elliotte Rusty Harold created MDEP-931: -- Summary: AbstractSerializingVisitor should not use PrintWriter Key: MDEP-931 URL: https://issues.apache.org/jira/browse/MDEP-931 Project: Maven Dependency Plugin Issue Type: Improvement Reporter: Elliotte Rusty Harold See https://github.com/apache/maven-dependency-plugin/pull/391/files AbstractSerializingVisitor uses a PrintWriter which swallows exceptions. It should use a regular Writer instead. This is exposed in the protected API so fixing this is ugly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MDEP-930) runTreeMojo in TestTreeMojo ignores encoding
[
https://issues.apache.org/jira/browse/MDEP-930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MDEP-930:
---
Description:
Should probably use something like Files.readAllLines with a charset or
equivalent instead here.
```
BufferedReader fp1 = new BufferedReader(new FileReader(outputFileName));
List contents = new ArrayList<>();
String line;
while ((line = fp1.readLine()) != null) {
contents.add(line);
}
fp1.close();
```
was:
Should probably use something like Files.readAllLines witha charset or
equivalent instead here.
```
BufferedReader fp1 = new BufferedReader(new FileReader(outputFileName));
List contents = new ArrayList<>();
String line;
while ((line = fp1.readLine()) != null) {
contents.add(line);
}
fp1.close();
```
> runTreeMojo in TestTreeMojo ignores encoding
>
>
> Key: MDEP-930
> URL: https://issues.apache.org/jira/browse/MDEP-930
> Project: Maven Dependency Plugin
> Issue Type: Test
>Reporter: Elliotte Rusty Harold
>Priority: Minor
>
> Should probably use something like Files.readAllLines with a charset or
> equivalent instead here.
> ```
> BufferedReader fp1 = new BufferedReader(new
> FileReader(outputFileName));
> List contents = new ArrayList<>();
> String line;
> while ((line = fp1.readLine()) != null) {
> contents.add(line);
> }
> fp1.close();
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MDEP-930) runTreeMojo in TestTreeMojo ignores encoding
Elliotte Rusty Harold created MDEP-930:
--
Summary: runTreeMojo in TestTreeMojo ignores encoding
Key: MDEP-930
URL: https://issues.apache.org/jira/browse/MDEP-930
Project: Maven Dependency Plugin
Issue Type: Test
Reporter: Elliotte Rusty Harold
Should probably use something like Files.readAllLines witha charset or
equivalent instead here.
```
BufferedReader fp1 = new BufferedReader(new FileReader(outputFileName));
List contents = new ArrayList<>();
String line;
while ((line = fp1.readLine()) != null) {
contents.add(line);
}
fp1.close();
```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOURCES-306) Delete Extracting Javadoc metadata for log message
Elliotte Rusty Harold created MRESOURCES-306: Summary: Delete Extracting Javadoc metadata for log message Key: MRESOURCES-306 URL: https://issues.apache.org/jira/browse/MRESOURCES-306 Project: Maven Resources Plugin Issue Type: Improvement Reporter: Elliotte Rusty Harold More log junk no one cares about that gets in the way while trying to debug real failures in a build: [INFO] [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ presto-client --- [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.valuesets.PrestoThriftRangeValueSet [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.valuesets.PrestoThriftRangeValueSet.PrestoThriftMarker [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.valuesets.PrestoThriftRangeValueSet.PrestoThriftRange [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.connector.PrestoThriftDomain [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.datatypes.PrestoThriftVarchar [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.datatypes.PrestoThriftDouble [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.datatypes.PrestoThriftBoolean [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.datatypes.PrestoThriftHyperLogLog [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.connector.PrestoThriftNullableSchemaName [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.datatypes.PrestoThriftJson [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.datatypes.PrestoThriftInteger [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.connector.PrestoThriftServiceException [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.connector.PrestoThriftNullableColumnSet [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.connector.PrestoThriftNullableToken [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.udf.ThriftUdfRequest [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.connector.PrestoThriftHostAddress [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.valuesets.PrestoThriftValueSet [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.valuesets.PrestoThriftEquatableValueSet [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.valuesets.PrestoThriftAllOrNoneValueSet [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.connector.PrestoThriftSchemaTableName [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.datatypes.PrestoThriftBigintArray [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.connector.PrestoThriftNullableTableMetadata [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.connector.PrestoThriftColumnMetadata [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.udf.ThriftFunctionHandle [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.udf.ThriftUdfStats [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.connector.PrestoThriftPageResult [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.udf.ThriftUdfServiceException [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.udf.ThriftUdfResult [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.connector.PrestoThriftTupleDomain [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.udf.UdfExecutionFailureInfo [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.udf.ThriftSerializedPage [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.udf.PrestoThriftPage [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.connector.PrestoThriftTableMetadata [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.datatypes.PrestoThriftTimestamp [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.connector.PrestoThriftSplit [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.datatypes.PrestoThriftBlock [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.connector.PrestoThriftId [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.udf.ThriftUdfPage [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.datatypes.PrestoThriftDate [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.datatypes.PrestoThriftBigint [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.connector.PrestoThriftSplitBatch [INFO] Extracting Javadoc metadata for com.facebook.presto.thrift.api.valuesets.PrestoThriftRangeValueSet.PrestoThriftBound [INFO] Extracting Javadoc
[jira] [Created] (MNGSITE-537) Set up CI for the Giothub repo
Elliotte Rusty Harold created MNGSITE-537: - Summary: Set up CI for the Giothub repo Key: MNGSITE-537 URL: https://issues.apache.org/jira/browse/MNGSITE-537 Project: Maven Project Web Site Issue Type: Task Reporter: Elliotte Rusty Harold https://github.com/apache/maven-site/ seems to have no Continuous integration checks. We should set some up. I'm pretty sure I've broken the site build in the past by merging bad code, and if I haven't yet, I will in the future without some guard rails. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MTOOLCHAINS-52) Explain what a toolchain is
[ https://issues.apache.org/jira/browse/MTOOLCHAINS-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MTOOLCHAINS-52: - Summary: Explain what a toolchain is (was: Explain what a custiom toolcahin is) > Explain what a toolchain is > --- > > Key: MTOOLCHAINS-52 > URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-52 > Project: Maven Toolchains Plugin > Issue Type: Improvement >Affects Versions: 3.2.0 >Reporter: Elliotte Rusty Harold >Priority: Major > Labels: doc > > The page at > https://maven.apache.org/plugins/maven-toolchains-plugin/toolchains/custom.html > never explains what a custom toolchain is, or how it differs from a > toolchain. It should start with this information. > In fact, nothing I see on the maven-toolchains-plugin website ever says what > a toolchain *is*. I think this might help explain why I've found this so hard > to understand. We need to make sure the docs clearly define "toolchain". > Either that or don't use the word at all. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MTOOLCHAINS-52) Explain what a custiom toolcahin is
[ https://issues.apache.org/jira/browse/MTOOLCHAINS-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MTOOLCHAINS-52: - Labels: doc (was: ) > Explain what a custiom toolcahin is > --- > > Key: MTOOLCHAINS-52 > URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-52 > Project: Maven Toolchains Plugin > Issue Type: Improvement >Affects Versions: 3.2.0 >Reporter: Elliotte Rusty Harold >Priority: Major > Labels: doc > > The page at > https://maven.apache.org/plugins/maven-toolchains-plugin/toolchains/custom.html > never explains what a custom toolchain is, or how it differs from a > toolchain. It should start with this information. > In fact, nothing I see on the maven-toolchains-plugin website ever says what > a toolchain *is*. I think this might help explain why I've found this so hard > to understand. We need to make sure the docs clearly define "toolchain". > Either that or don't use the word at all. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MTOOLCHAINS-52) Explain what a custiom toolcahin is
Elliotte Rusty Harold created MTOOLCHAINS-52: Summary: Explain what a custiom toolcahin is Key: MTOOLCHAINS-52 URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-52 Project: Maven Toolchains Plugin Issue Type: Improvement Affects Versions: 3.2.0 Reporter: Elliotte Rusty Harold The page at https://maven.apache.org/plugins/maven-toolchains-plugin/toolchains/custom.html never explains what a custom toolchain is, or how it differs from a toolchain. It should start with this information. In fact, nothing I see on the maven-toolchains-plugin website ever says what a toolchain *is*. I think this might help explain why I've found this so hard to understand. We need to make sure the docs clearly define "toolchain". Either that or don't use the word at all. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MGPG-111) Clean upn dependency declarations
[ https://issues.apache.org/jira/browse/MGPG-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824936#comment-17824936 ] Elliotte Rusty Harold edited comment on MGPG-111 at 3/9/24 12:42 PM: - Interesting blog article. After reading it, I'm not surprised that maven-dependency-analyzer doesn't pick up "dependency grouping". It's essentially a hack that uses undeclared transitive dependencies instead of declared direct dependencies,. I suppose you might make a case for that, but it's the opposite of what maven-dependency-plugin: analyze is trying to check. My personal opinion is that developers should bite the bullet and declare all their direct dependencies and only direct dependencies. Use a BOM to set versions of related projects, but not to add dependencies to the tree. Anything else runs counter to the design of Maven and the Maven repository system, and will cause more problems than it solves.The design of the Maven repo system is far from perfect, but it's what we've got, and we can't hack changes into it. Anything better would require a complete rethink of everything beyond jar files and classpaths. It's the classic antipattern of someone wishing the system were other than it is, and trying to pound the round peg into a square hole by using a bigger hammer. Other examples of this antipattern include "functional" programming in Java, various schemes to avoid declaring and handling checked exceptions, and any number of faster XML parsers that achieve speed by changing or subsetting the XML spec. was (Author: elharo): Interesting blog article. After reading it, I'm not surprised that maven-dependency-analyzer doesn't pick up "dependency grouping". It's essentially a hack that uses undeclared transitive dependencies instead of declared direct dependencies,. I suppose you might make a case for that, but it's the opposite of what maven-dependency-plugin: analyze is trying to check. My personal opinion is that developers should bite the bullet and declare all their direct dependencies and only direct dependencies. Use a BOM to set versions of related projects, but not to add dependencies to the tree. > Clean upn dependency declarations > - > > Key: MGPG-111 > URL: https://issues.apache.org/jira/browse/MGPG-111 > Project: Maven GPG Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Minor > > [WARNING] Used undeclared dependencies found: > [WARNING]org.apache.maven:maven-artifact:jar:3.9.6:provided > [WARNING]org.apache.maven:maven-settings:jar:3.9.6:provided > [WARNING]com.kohlschutter.junixsocket:junixsocket-common:jar:2.9.0:compile > [WARNING]org.apache.maven.resolver:maven-resolver-impl:jar:1.9.18:provided > [WARNING] Unused declared dependencies found: > [WARNING]com.kohlschutter.junixsocket:junixsocket-core:pom:2.9.0:compile > [WARNING]org.codehaus.plexus:plexus-cipher:jar:2.0:compile -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MGPG-111) Clean upn dependency declarations
[ https://issues.apache.org/jira/browse/MGPG-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824936#comment-17824936 ] Elliotte Rusty Harold commented on MGPG-111: Interesting blog article. After reading it, I'm not surprised that maven-dependency-analyzer doesn't pick up "dependency grouping". It's essentially a hack that uses undeclared transitive dependencies instead of declared direct dependencies,. I suppose you might make a case for that, but it's the opposite of what maven-dependency-plugin: analyze is trying to check. My personal opinion is that developers should bite the bullet and declare all their direct dependencies and only direct dependencies. Use a BOM to set versions of related projects, but not to add dependencies to the tree. > Clean upn dependency declarations > - > > Key: MGPG-111 > URL: https://issues.apache.org/jira/browse/MGPG-111 > Project: Maven GPG Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Minor > > [WARNING] Used undeclared dependencies found: > [WARNING]org.apache.maven:maven-artifact:jar:3.9.6:provided > [WARNING]org.apache.maven:maven-settings:jar:3.9.6:provided > [WARNING]com.kohlschutter.junixsocket:junixsocket-common:jar:2.9.0:compile > [WARNING]org.apache.maven.resolver:maven-resolver-impl:jar:1.9.18:provided > [WARNING] Unused declared dependencies found: > [WARNING]com.kohlschutter.junixsocket:junixsocket-core:pom:2.9.0:compile > [WARNING]org.codehaus.plexus:plexus-cipher:jar:2.0:compile -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MGPG-111) Clean upn dependency declarations
[ https://issues.apache.org/jira/browse/MGPG-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824935#comment-17824935 ] Elliotte Rusty Harold commented on MGPG-111: so com.kohlschutter.junixsocket:junixsocket-common:jar:2.9.0:compile is used but not declared. Definitely something to fix. In fact, it sems klikely 3 if not 4 of Used undeclared dependencies detected should be fixed. plexus-cipher needs further investigation. junixsocket-core might need some thought as to how the dependency analyzer can recognize this. > Clean upn dependency declarations > - > > Key: MGPG-111 > URL: https://issues.apache.org/jira/browse/MGPG-111 > Project: Maven GPG Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Minor > > [WARNING] Used undeclared dependencies found: > [WARNING]org.apache.maven:maven-artifact:jar:3.9.6:provided > [WARNING]org.apache.maven:maven-settings:jar:3.9.6:provided > [WARNING]com.kohlschutter.junixsocket:junixsocket-common:jar:2.9.0:compile > [WARNING]org.apache.maven.resolver:maven-resolver-impl:jar:1.9.18:provided > [WARNING] Unused declared dependencies found: > [WARNING]com.kohlschutter.junixsocket:junixsocket-core:pom:2.9.0:compile > [WARNING]org.codehaus.plexus:plexus-cipher:jar:2.0:compile -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MGPG-111) Clean upn dependency declarations
[ https://issues.apache.org/jira/browse/MGPG-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824784#comment-17824784 ] Elliotte Rusty Harold commented on MGPG-111: I don't. These reports also help figure out where maven-dependency-analyzer has issues that need to be fixed. The "dependency grouping" pattern is interesting. I haven't encountered that before. I'll have to look into it. Do note that junix-socket common is reported as used but undeclared, so perhaps it does need to be declared. plexus-sec-dispatcher and plexus-cipher I'm not sure about. It sounds like there might be a better way to handle this. If maven-resolver-impl is used in test, then perhaps the scope is wrong or perhaps this is a bug in maven-dependency-analyzer. I know it's had problems with test dependencies before. > Clean upn dependency declarations > - > > Key: MGPG-111 > URL: https://issues.apache.org/jira/browse/MGPG-111 > Project: Maven GPG Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Minor > > [WARNING] Used undeclared dependencies found: > [WARNING]org.apache.maven:maven-artifact:jar:3.9.6:provided > [WARNING]org.apache.maven:maven-settings:jar:3.9.6:provided > [WARNING]com.kohlschutter.junixsocket:junixsocket-common:jar:2.9.0:compile > [WARNING]org.apache.maven.resolver:maven-resolver-impl:jar:1.9.18:provided > [WARNING] Unused declared dependencies found: > [WARNING]com.kohlschutter.junixsocket:junixsocket-core:pom:2.9.0:compile > [WARNING]org.codehaus.plexus:plexus-cipher:jar:2.0:compile -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MGPG-111) Clean upn dependency declarations
Elliotte Rusty Harold created MGPG-111: -- Summary: Clean upn dependency declarations Key: MGPG-111 URL: https://issues.apache.org/jira/browse/MGPG-111 Project: Maven GPG Plugin Issue Type: Dependency upgrade Reporter: Elliotte Rusty Harold [WARNING] Used undeclared dependencies found: [WARNING]org.apache.maven:maven-artifact:jar:3.9.6:provided [WARNING]org.apache.maven:maven-settings:jar:3.9.6:provided [WARNING]com.kohlschutter.junixsocket:junixsocket-common:jar:2.9.0:compile [WARNING]org.apache.maven.resolver:maven-resolver-impl:jar:1.9.18:provided [WARNING] Unused declared dependencies found: [WARNING]com.kohlschutter.junixsocket:junixsocket-core:pom:2.9.0:compile [WARNING]org.codehaus.plexus:plexus-cipher:jar:2.0:compile -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SUREFIRE-2239) Rerun TestNG tests
Elliotte Rusty Harold created SUREFIRE-2239: --- Summary: Rerun TestNG tests Key: SUREFIRE-2239 URL: https://issues.apache.org/jira/browse/SUREFIRE-2239 Project: Maven Surefire Issue Type: New Feature Reporter: Elliotte Rusty Harold support rerunFailingTestsCount for TestNG, as we already do for JUnit 4 and 5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPLUGIN-506) Translation required between V3 and V4 Mojo annotations
[ https://issues.apache.org/jira/browse/MPLUGIN-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MPLUGIN-506: -- Summary: Translation required between V3 and V4 Mojo annotations (was: Trasnlation required between V3 and V4 Mojo annotations) > Translation required between V3 and V4 Mojo annotations > --- > > Key: MPLUGIN-506 > URL: https://issues.apache.org/jira/browse/MPLUGIN-506 > Project: Maven Plugin Tools > Issue Type: Task > Components: maven-plugin-tools-annotations >Reporter: Tamas Cservenak >Priority: Blocker > > The Maven4 API Mojo annotations and Maven3 Mojo annotations have slight > differences causing build issues when used. > Simplest would be if we would "translate" these. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MTOOLCHAINS-38) Add skipToolchains parameter for ToolchainMojo
[
https://issues.apache.org/jira/browse/MTOOLCHAINS-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MTOOLCHAINS-38.
> Add skipToolchains parameter for ToolchainMojo
> --
>
> Key: MTOOLCHAINS-38
> URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-38
> Project: Maven Toolchains Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Jacky Chan
>Priority: Minor
>
> If you use Github actions actions/setup-java@v2 to setup Java env, java
> version and vendor are all defined well, and it's not necessary to active
> maven-tools-plugin.
> {code:java}
> - uses: actions/setup-java@v2
> with:
> distribution: 'temurin'
> java-version: '11'
> {code}
> If you can not skip maven-tools-plugin, and you should create a
> `~/.m2/toolchains.xml` file for CI.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MTOOLCHAINS-38) Add skipToolchains parameter for ToolchainMojo
[
https://issues.apache.org/jira/browse/MTOOLCHAINS-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MTOOLCHAINS-38.
--
Resolution: Not A Bug
As you point out this is a CI configuration issue, and can be addressed in
toolchains.xml.
> Add skipToolchains parameter for ToolchainMojo
> --
>
> Key: MTOOLCHAINS-38
> URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-38
> Project: Maven Toolchains Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Jacky Chan
>Priority: Minor
>
> If you use Github actions actions/setup-java@v2 to setup Java env, java
> version and vendor are all defined well, and it's not necessary to active
> maven-tools-plugin.
> {code:java}
> - uses: actions/setup-java@v2
> with:
> distribution: 'temurin'
> java-version: '11'
> {code}
> If you can not skip maven-tools-plugin, and you should create a
> `~/.m2/toolchains.xml` file for CI.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MTOOLCHAINS-37) Toolchain plugin does not show compile errors in Windows 10
[ https://issues.apache.org/jira/browse/MTOOLCHAINS-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822834#comment-17822834 ] Elliotte Rusty Harold commented on MTOOLCHAINS-37: -- This is going to be hard to impossible to debug remotely. I really do doubt it has anything to do with the toolchains plugin. Just maybe it has something to do with the maven-compiler-plugin, but as you surmise this is mostly an idiosyncrasy in your local environment. The question I will ask is what happens if you call the same javac directly rather than using Maven at all? Does the output show up then? > Toolchain plugin does not show compile errors in Windows 10 > --- > > Key: MTOOLCHAINS-37 > URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-37 > Project: Maven Toolchains Plugin > Issue Type: Bug > Environment: Windows 10 (version 1909) >Reporter: Francois Loriot >Priority: Minor > > I have recently tried to build some java projects on Windows 10 using the > toolchain plugin, but I see that when there are java compilation errors, the > output of the build does not list the errors. The same build with identical > setup on Windows 7 correctly shows the errors. I'm running Maven with Oracle > JDK 1.8 (I have also tried Open JDK 1.8 and Oracle 9) and the toolchain for > the compilation points to IBM SDK 1.6 (I have also tried SDK 1.6 and 1.8). > I'm using the default/latest toolchain and compiler plugins. > I have also noticed that every time the compiler is being called during the > build, it briefly pops up a command prompt window with some output. I'm > thinking the actual error description in case of java errors goes in these > windows, instead of the build output. > I can reproduce the same behavior running the maven goals from within > JetBrains Intelli J. > I have confirmed the same behavior with other developers in my company. > Running with -X or -e did not help either. > Here is an example: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile > (default-compile) on project ebill-webcommon: Compilation failure -> *= > MISSING THE ERRORS HERE ===* [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the > command > [ERROR] mvn -rf :ebill-webcommon > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MTOOLCHAINS-37) Toolchain plugin does not show compile errors in Windows 10
[ https://issues.apache.org/jira/browse/MTOOLCHAINS-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MTOOLCHAINS-37: - Priority: Minor (was: Major) > Toolchain plugin does not show compile errors in Windows 10 > --- > > Key: MTOOLCHAINS-37 > URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-37 > Project: Maven Toolchains Plugin > Issue Type: Bug > Environment: Windows 10 (version 1909) >Reporter: Francois Loriot >Priority: Minor > > I have recently tried to build some java projects on Windows 10 using the > toolchain plugin, but I see that when there are java compilation errors, the > output of the build does not list the errors. The same build with identical > setup on Windows 7 correctly shows the errors. I'm running Maven with Oracle > JDK 1.8 (I have also tried Open JDK 1.8 and Oracle 9) and the toolchain for > the compilation points to IBM SDK 1.6 (I have also tried SDK 1.6 and 1.8). > I'm using the default/latest toolchain and compiler plugins. > I have also noticed that every time the compiler is being called during the > build, it briefly pops up a command prompt window with some output. I'm > thinking the actual error description in case of java errors goes in these > windows, instead of the build output. > I can reproduce the same behavior running the maven goals from within > JetBrains Intelli J. > I have confirmed the same behavior with other developers in my company. > Running with -X or -e did not help either. > Here is an example: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile > (default-compile) on project ebill-webcommon: Compilation failure -> *= > MISSING THE ERRORS HERE ===* [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the > command > [ERROR] mvn -rf :ebill-webcommon > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MTOOLCHAINS-35) No javac in jdk toolchain should be an error
[ https://issues.apache.org/jira/browse/MTOOLCHAINS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MTOOLCHAINS-35: - Issue Type: New Feature (was: Bug) > No javac in jdk toolchain should be an error > > > Key: MTOOLCHAINS-35 > URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-35 > Project: Maven Toolchains Plugin > Issue Type: New Feature >Affects Versions: 3.0.0 >Reporter: Delany >Priority: Major > > If the selected jdk toolchain is configured to point to a JRE instead of a > JDK, it should fail with an error. Instead there is a warning. > [WARNING] Unable to autodetect 'javac' path, using 'javac' from the > environment. > I'm assuming it falls back to whatever javac is available on the system? > Edited to indicate that this only applies to the jdk toolchain, not to all > toolchains which might select other things like Eclipse versions that aren't > even JDKs at all. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MTOOLCHAINS-35) No javac in jdk toolchain should be an error
[ https://issues.apache.org/jira/browse/MTOOLCHAINS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MTOOLCHAINS-35: - Summary: No javac in jdk toolchain should be an error (was: No javac should be an error) > No javac in jdk toolchain should be an error > > > Key: MTOOLCHAINS-35 > URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-35 > Project: Maven Toolchains Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Delany >Priority: Major > > If the selected jdk toolchain is configured to point to a JRE instead of a > JDK, it should fail with an error. Instead there is a warning. > [WARNING] Unable to autodetect 'javac' path, using 'javac' from the > environment. > I'm assuming it falls back to whatever javac is available on the system? > Edited to indicate that this only applies to the jdk toolchain, not to all > toolchains which might select other things like Eclipse versions that aren't > even JDKs at all. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MTOOLCHAINS-35) No javac should be an error
[ https://issues.apache.org/jira/browse/MTOOLCHAINS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MTOOLCHAINS-35: - Description: If the selected jdk toolchain is configured to point to a JRE instead of a JDK, it should fail with an error. Instead there is a warning. [WARNING] Unable to autodetect 'javac' path, using 'javac' from the environment. I'm assuming it falls back to whatever javac is available on the system? Edited to indicate that this only applies to the jdk toolchain, not to all toolchains which might select other things like Eclipse versions that aren't even JDKs at all. was: If the selected toolchain is configured to point to a JRE instead of a JDK, it should fail with an error. Instead there is a warning. [WARNING] Unable to autodetect 'javac' path, using 'javac' from the environment. I'm assuming it falls back to whatever javac is available on the system? > No javac should be an error > --- > > Key: MTOOLCHAINS-35 > URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-35 > Project: Maven Toolchains Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Delany >Priority: Major > > If the selected jdk toolchain is configured to point to a JRE instead of a > JDK, it should fail with an error. Instead there is a warning. > [WARNING] Unable to autodetect 'javac' path, using 'javac' from the > environment. > I'm assuming it falls back to whatever javac is available on the system? > Edited to indicate that this only applies to the jdk toolchain, not to all > toolchains which might select other things like Eclipse versions that aren't > even JDKs at all. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MTOOLCHAINS-44) Use default JDK if it matches the request and no other toolchain is defined
[ https://issues.apache.org/jira/browse/MTOOLCHAINS-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822833#comment-17822833 ] Elliotte Rusty Harold commented on MTOOLCHAINS-44: -- The problem with this idea is that we can match JDK versions, but the configuration can have arbitrary other properties like vendor or willy_wonka. We have no way of matching anything else against the system installed libraries absent a toolchains.xml file. That said, a jdk matched only by version is common enough that maybe we should special case that. > Use default JDK if it matches the request and no other toolchain is defined > --- > > Key: MTOOLCHAINS-44 > URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-44 > Project: Maven Toolchains Plugin > Issue Type: Improvement >Affects Versions: 3.1.0 >Reporter: dennis lucero >Priority: Major > > Currently it is needed to have the toolchains defined in the toolchains.xml > file. The [Maven Docker images|https://hub.docker.com/_/maven] do not > [include a useful toolchains > file|https://github.com/carlossg/docker-maven/issues/303]. But since it’s > possible to [derive a usable toolchain from the system > properties|https://github.com/carlossg/docker-maven/issues/303#issuecomment-1310895631], > it should not be required to store that information in the toolchains.xml > file. Instead, Maven should check if the toolchain request could be fulfilled > by the JDK running Maven. > I’m not sure if it’s reasonable to do this in all cases or only if the > toolchains file does not contain any toolchain. For example, if the > toolchains file only contains a Java 16 toolchain and the project requires > Java 17 (exactly, not 17 or later) and Maven is run with Java 17, it would be > possible to build the project (with Java 17), but probably not a good idea > since it will fail when the Java installation Maven is running on is updated > to version 18. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MTOOLCHAINS-48) Document how conflicting toolchains are resolved
Elliotte Rusty Harold created MTOOLCHAINS-48: Summary: Document how conflicting toolchains are resolved Key: MTOOLCHAINS-48 URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-48 Project: Maven Toolchains Plugin Issue Type: Improvement Reporter: Elliotte Rusty Harold That is, what happens if more than one toolchain matches? E.g. there are two configs for jdk with version 17, one for oracle and one for temurin, but the user only specified version 17. Which jdk do they get? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MTOOLCHAINS-44) Use default JDK if it matches the request and no other toolchain is defined
[
https://issues.apache.org/jira/browse/MTOOLCHAINS-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820485#comment-17820485
]
Elliotte Rusty Harold commented on MTOOLCHAINS-44:
--
My gut is that if a toolchain can't be located, we shouldn't simply use
JAVA_HOME. Erroring is better here.
However, we might be able to define some defaults for certain JDK toolchains.
The common case for toolchains is that the user wants a specific JDK version.
If that's all they request, and toolchains.xml can't be found, or doesn't
contain a matching JDK version, maven could still search in standard locations
locally. For instance, suppose this is the configuration
{{
1.8
}}
On a Mac you could run "/usr/libexec/java_home -V" to find a JDK that provides
version 1.8.
> Use default JDK if it matches the request and no other toolchain is defined
> ---
>
> Key: MTOOLCHAINS-44
> URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-44
> Project: Maven Toolchains Plugin
> Issue Type: Improvement
>Affects Versions: 3.1.0
>Reporter: dennis lucero
>Priority: Major
>
> Currently it is needed to have the toolchains defined in the toolchains.xml
> file. The [Maven Docker images|https://hub.docker.com/_/maven] do not
> [include a useful toolchains
> file|https://github.com/carlossg/docker-maven/issues/303]. But since it’s
> possible to [derive a usable toolchain from the system
> properties|https://github.com/carlossg/docker-maven/issues/303#issuecomment-1310895631],
> it should not be required to store that information in the toolchains.xml
> file. Instead, Maven should check if the toolchain request could be fulfilled
> by the JDK running Maven.
> I’m not sure if it’s reasonable to do this in all cases or only if the
> toolchains file does not contain any toolchain. For example, if the
> toolchains file only contains a Java 16 toolchain and the project requires
> Java 17 (exactly, not 17 or later) and Maven is run with Java 17, it would be
> possible to build the project (with Java 17), but probably not a good idea
> since it will fail when the Java installation Maven is running on is updated
> to version 18.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MTOOLCHAINS-46) Maven Toolchains Plugin to add JDK management
[ https://issues.apache.org/jira/browse/MTOOLCHAINS-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MTOOLCHAINS-46. Resolution: Won't Do Per comment below > Maven Toolchains Plugin to add JDK management > - > > Key: MTOOLCHAINS-46 > URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-46 > Project: Maven Toolchains Plugin > Issue Type: New Feature >Reporter: Jacky Chan >Priority: Major > > Integrated with Disco API and add JDK management, such as JDK auto download, > GraalVM support. > > The plugin prototype: https://github.com/linux-china/toolchains-maven-plugin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MJAR-286) NullPointerException when includes are empty
[ https://issues.apache.org/jira/browse/MJAR-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MJAR-286. Fix Version/s: 3.3.0 Resolution: Fixed closing per below comment > NullPointerException when includes are empty > > > Key: MJAR-286 > URL: https://issues.apache.org/jira/browse/MJAR-286 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 3.1.2, 3.2.2 > Environment: Maven 3.8.4, Windows 10 >Reporter: Markus Dangl >Priority: Major > Fix For: 3.3.0 > > Attachments: mvn-clean-package.log > > > When includes are empty, but a `src/main/resources` directory exists, maven > fails with a NullPointerException. If this is a misconfigured pom, it should > at least give a proper error message. > > I produced a minimized case here: > [https://github.com/xicesky/bug-in-maven-jar-plugin] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SUREFIRE-2238) Let CI systems plug into the output for locations
Elliotte Rusty Harold created SUREFIRE-2238: --- Summary: Let CI systems plug into the output for locations Key: SUREFIRE-2238 URL: https://issues.apache.org/jira/browse/SUREFIRE-2238 Project: Maven Surefire Issue Type: New Feature Components: surefire-logger-api Reporter: Elliotte Rusty Harold Saw this for about the 8000th time this morning: [INFO] Finished at: 2024-02-23T19:26:07-06:00 [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M7:test (default-test) on project presto-native-execution: There are test failures. [ERROR] [ERROR] Please refer to /root/project/presto-native-execution/target/surefire-reports for the individual test results. [ERROR] Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump and [date].dumpstream. [ERROR] -> [Help 1] Not a bug in Maven. As usual something in my project is broken. That's why we use continuous integration (CI). However, these messages assume that I'm building and testing locally on my local file system. Often I'm not. /root/project/presto-native-execution/target/surefire-reports and [date].dump, [date]-jvmRun[N].dump and [date].dumpstream. aren't necessarily accessible from the CI. Some devs with limited privileges can't read the CI filesystem, and even those who can will have to do a lot of digging to find where they've actually been put. And of course this will vary from one CI software to the next and from one installation to the next. What's needed is some way a CI system like Travis or CircleCI or github actions or whatever to inject file path and most importantly URLS into the log messages that Maven outputs. That way the dev can just click through the links to find the debugging information they need. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MSHADE-236) Document artifacts that went into the shade.
[ https://issues.apache.org/jira/browse/MSHADE-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MSHADE-236. -- Resolution: Fixed > Document artifacts that went into the shade. > > > Key: MSHADE-236 > URL: https://issues.apache.org/jira/browse/MSHADE-236 > Project: Maven Shade Plugin > Issue Type: New Feature >Affects Versions: 2.4.3 >Reporter: Phil Wilkinson >Priority: Minor > > Hi I asked a question a while ago on > http://stackoverflow.com/questions/38096958/how-do-i-embed-artifact-information-in-maven-shaded-jar > basically I wanted to be able to look at the shaded jar that's being used by > a custom and figure out exactly what versions of the artifacts went in to it. > It looks this isn't supported currently by the plugin and I think it would be > a nice feature. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHADE-453) Relocation hangs indefinitely in all releases > 3.2.2 with basepom
[
https://issues.apache.org/jira/browse/MSHADE-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MSHADE-453:
-
Priority: Critical (was: Major)
> Relocation hangs indefinitely in all releases > 3.2.2 with basepom
> --
>
> Key: MSHADE-453
> URL: https://issues.apache.org/jira/browse/MSHADE-453
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.3, 3.2.4, 3.3.0, 3.4.0, 3.5.0
> Environment: Maven home: /Users/jkebinger/Downloads/apache-maven-3.9.3
> Java version: 17.0.1, vendor: BellSoft, runtime:
> /Users/jkebinger/.asdf/installs/java/liberica-17.0.1+12
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac"
>Reporter: James Kebinger
>Priority: Critical
>
> TL;DR - relocation code in CollectingManifestResourceTransformer,
> ManifestResourceTransformer don't cope well when the shaded package name
> includes the original package name. The
> [docs|https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#relocations]
> on relocations include such an example
> ---
> I'm relocating some packages in a project and have found that all the newest
> versions of the shading plugin appear to hang after printing the list of
> artifacts to include/exclude.
> {{Doing a thread dump shows all the time spent in SimpleRelocator and regex
> classes}}
> {code:java}
> "main" #1 [10243] prio=5 os_prio=31 cpu=72973.77ms elapsed=81.89s
> tid=0x00014f00d200 nid=10243 runnable [0x00016dbf1000]
> java.lang.Thread.State: RUNNABLE
> at java.util.regex.Pattern$Start.match(java.base@19.0.2/Pattern.java:3627)
> at java.util.regex.Matcher.search(java.base@19.0.2/Matcher.java:1728)
> at java.util.regex.Matcher.find(java.base@19.0.2/Matcher.java:745)
> at java.util.regex.Matcher.replaceFirst(java.base@19.0.2/Matcher.java:1404)
> at java.lang.String.replaceFirst(java.base@19.0.2/String.java:2906)
> at
> org.apache.maven.plugins.shade.relocation.SimpleRelocator.relocateClass(SimpleRelocator.java:245)
> at
> org.basepom.maven.shade.CollectingManifestResourceTransformer.relocate(CollectingManifestResourceTransformer.java:202)
> at
> org.basepom.maven.shade.CollectingManifestResourceTransformer.processResource(CollectingManifestResourceTransformer.java:116)
> at
> org.apache.maven.plugins.shade.DefaultShader.goThroughAllJarEntriesForManifestTransformer(DefaultShader.java:364)
> at org.apache.maven.plugins.shade.DefaultShader.shade(DefaultShader.java:122)
> at org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:500)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:126)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:342)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:330)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:175)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.access$000(MojoExecutor.java:76)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:163){code}
> {{ }}
> Can reproduce against this sample project
> [https://github.com/prefab-cloud/mvn-shade-test]
>
> Have only tested on an Apple silicon Mac
>
> It appears to be repeatedly transforming the clazz variable in this method in
> SimpleRelocator
> pattern=org.yaml.snakeyaml
> shadedPattern=prefab.shaded.org.yaml.snakeyaml
>
> {code:java}
> public String relocateClass(String clazz) {
> return rawString ? clazz : clazz.replaceFirst(pattern, shadedPattern);
> }{code}
> So it'll start with eg
>
> {code:java}
> org.yaml.snakeyaml;version="1.33",org.yaml.snakeyaml.comments;version="1.33",org.yaml.snakeyaml.composer;version="1.33",org.yaml.snakeyaml.constructor;version="1.33",org.yaml.snakeyaml.emitter;version="1.33",org.yaml.snakeyaml.env;version="1.33",org.yaml.snakeyaml.error;version="1.33",org.yaml.snakeyaml.events;version="1.33",org.yaml.snakeyaml.extensions.compactnotation;version="1.33",org.yaml.snakeyaml.introspector;version="1.33",org.yaml.snakeyaml.nodes;version="1.33",org.yaml.snakeyaml.parser;version="1.33",org.yaml.snakeyaml.reader;version="1.33",org.yaml.snakeyaml.representer;version="1.33",org.yaml.snakeyaml.resolver;version="1.33",org.yaml.snakeyaml.scanner;version="1.33",org.yaml.snakeyaml.serializer;version="1.33",org.yaml.snakeyaml.tokens;version="1.33",org.yaml.snakeyaml.util;version="1.33"
>
> {code}
> and keep substituting the shaded pattern to build longer and longer string eg
>
>
[jira] [Updated] (MSHADE-452) Shade plugin can't replace SPI content correct when pattern not end with dot
[
https://issues.apache.org/jira/browse/MSHADE-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MSHADE-452:
-
Issue Type: Bug (was: Improvement)
> Shade plugin can't replace SPI content correct when pattern not end with dot
>
>
> Key: MSHADE-452
> URL: https://issues.apache.org/jira/browse/MSHADE-452
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: hk__lrzy
>Priority: Critical
> Attachments: 20230720-205856.png, 20230720-205900.png
>
>
> We have java path as below
> _*org.apache.demo1*_
> _*org.apache.demo2*_
> In {_}*maven-shade-plugin 3.2.1*{_}, we use relocation to process path and
> SPI Service file at the same time, and we will follow result.
> {code:java}
>
> org.apache.demo
> shaded.org.apache.demo
> {code}
> {code:java}
> META-INF/services/shaded.org.apache.demo{code}
> But in _*maven-shaded-plugin 3.5.0,*_ it can't work as before, alouthght it
> SPI file name alao could be changed, but the SPI file content will {_}*have
> no change*{_}.
> I see the differneces between the _*maven-shaded-plugin 3.5.0 and
> maven-shaded-plugin 3.2.1,*_ finally find in _*maven-shaded-plugin 3.2.1,*_
> file content changed by follow code
>
> {code:java}
> public String applyToSourceContent( String sourceContent )
> {
> if ( rawString )
> {
> return sourceContent;
> }
> else
> {
> return sourceContent.replaceAll( "\\b" + pattern, shadedPattern );
> }
> }{code}
> but in {_}*maven-shaded-plugin 3.5.0*{_}, _**_ the code change to
> {code:java}
> private String shadeSourceWithExcludes( String sourceContent, String
> patternFrom, String patternTo,
> Set excludedPatterns )
> {
> // Usually shading makes package names a bit longer, so make buffer 10%
> bigger than original source
> StringBuilder shadedSourceContent = new StringBuilder(
> sourceContent.length() * 11 / 10 );
> boolean isFirstSnippet = true;
> // Make sure that search pattern starts at word boundary and we look for
> literal ".", not regex jokers
> for ( String snippet : sourceContent.split( "\\b" + patternFrom.replace(
> ".", "[.]" + "\\b" ) ) )
> {
> boolean doExclude = false;
> for ( String excludedPattern : excludedPatterns )
> {
> if ( snippet.startsWith( excludedPattern ) )
> {
> doExclude = true;
> break;
> }
> }
> if ( isFirstSnippet )
> {
> shadedSourceContent.append( snippet );
> isFirstSnippet = false;
> }
> else
> {
> shadedSourceContent.append( doExclude ? patternFrom : patternTo
> ).append( snippet );
> }
> }
> return shadedSourceContent.toString();
> } {code}
> In my cases, source content is {_}*org.apache.demo1*{_}, pattern from is
> {_}*org.apache.demo*{_}, pattern to is _*shaded.org.apache.demo.*_
> and the code _*sourceContent.split( "\\b" + patternFrom.replace( ".", "[.]" +
> "\\b" ) )*_ __ will only have one response.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MDEP-713) dependency:tree should not log info the user doesn't ask for
[ https://issues.apache.org/jira/browse/MDEP-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816096#comment-17816096 ] Elliotte Rusty Harold commented on MDEP-713: Turn this around. Instead of thinking about what the code does, start from the user experience. Then design the code to produce that. This is hardly only a problem in this plugin with this goal. I see it all over the Maven ecosystem. More generically, perhaps what maven needs is a silent build option that is turned on by default. I run a compile and I see javac errors, and nothing else. I run mvn test and I see test failures, and nothing else. Genuinely blocking errors might be shown. I can't test if I can't compile the tests, for instance. But everything else should be invisible by default. Only the actual user supplied goal should be allowed to print anything to the console at a level below fatal error. > dependency:tree should not log info the user doesn't ask for > > > Key: MDEP-713 > URL: https://issues.apache.org/jira/browse/MDEP-713 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: tree >Reporter: Elliotte Rusty Harold >Priority: Major > Fix For: waiting-for-feedback > > > I'm going to start this report here, though I kind of expect it slips into > core and a lot of other components. Suppose I run mvn dependency:tree on > Guava. As a user here's what I want to see (though probably minus the [INFO] > prefix): > [INFO] com.google.guava:guava-gwt:jar:HEAD-jre-SNAPSHOT > [INFO] +- com.google.guava:failureaccess:jar:1.0.1:compile > [INFO] +- com.google.guava:guava:jar:HEAD-jre-SNAPSHOT:compile > [INFO] | +- > com.google.guava:listenablefuture:jar:.0-empty-to-avoid-conflict-with-guava:compile > [INFO] | +- com.google.code.findbugs:jsr305:jar:3.0.2:compile > [INFO] | +- com.google.errorprone:error_prone_annotations:jar:2.3.4:compile > [INFO] | \- com.google.j2objc:j2objc-annotations:jar:1.3:compile > [INFO] +- com.google.elemental2:elemental2-promise:jar:1.0.0-RC1:compile > [INFO] | +- com.google.jsinterop:jsinterop-annotations:jar:1.0.2:compile > [INFO] | \- com.google.jsinterop:base:jar:1.0.0-RC1:compile > [INFO] +- com.google.guava:guava-testlib:jar:HEAD-jre-SNAPSHOT:test > [INFO] | \- junit:junit:jar:4.13:test > [INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:test > [INFO] +- com.google.guava:guava-testlib:jar:tests:HEAD-jre-SNAPSHOT:test > [INFO] +- com.google.guava:guava-tests:jar:tests:HEAD-jre-SNAPSHOT:test > [INFO] +- com.google.gwt:gwt-dev:jar:2.8.2:provided > [INFO] | +- com.google.code.gson:gson:jar:2.6.2:provided > [INFO] | +- org.ow2.asm:asm:jar:5.0.3:provided > [INFO] | +- org.ow2.asm:asm-util:jar:5.0.3:provided > [INFO] | | \- org.ow2.asm:asm-tree:jar:5.0.3:provided > [INFO] | +- org.ow2.asm:asm-commons:jar:5.0.3:provided > [INFO] | +- colt:colt:jar:1.2.0:provided > [INFO] | +- ant:ant:jar:1.6.5:provided > [INFO] | +- commons-collections:commons-collections:jar:3.2.2:provided > [INFO] | +- commons-io:commons-io:jar:2.4:provided > [INFO] | +- com.ibm.icu:icu4j:jar:50.1.1:provided > [INFO] | +- tapestry:tapestry:jar:4.0.2:provided > [INFO] | +- net.sourceforge.htmlunit:htmlunit:jar:2.19:provided > [INFO] | | +- xalan:xalan:jar:2.7.2:provided > [INFO] | | | \- xalan:serializer:jar:2.7.2:provided > [INFO] | | +- org.apache.commons:commons-lang3:jar:3.4:provided > [INFO] | | +- org.apache.httpcomponents:httpclient:jar:4.5.1:provided > [INFO] | | | \- org.apache.httpcomponents:httpcore:jar:4.4.3:provided > [INFO] | | +- org.apache.httpcomponents:httpmime:jar:4.5.1:provided > [INFO] | | +- commons-codec:commons-codec:jar:1.10:provided > [INFO] | | +- net.sourceforge.htmlunit:htmlunit-core-js:jar:2.17:provided > [INFO] | | +- xerces:xercesImpl:jar:2.11.0:provided > [INFO] | | | \- xml-apis:xml-apis:jar:1.4.01:provided > [INFO] | | +- net.sourceforge.nekohtml:nekohtml:jar:1.9.22:provided > [INFO] | | +- net.sourceforge.cssparser:cssparser:jar:0.9.18:provided > [INFO] | | +- commons-logging:commons-logging:jar:1.2:provided > [INFO] | | \- > org.eclipse.jetty.websocket:websocket-client:jar:9.2.13.v20150730:provided > [INFO] | | \- > org.eclipse.jetty.websocket:websocket-common:jar:9.2.13.v20150730:provided > [INFO] | |\- > org.eclipse.jetty.websocket:websocket-api:jar:9.2.13.v20150730:provided > [INFO] | +- org.eclipse.jetty:jetty-webapp:jar:9.2.14.v20151106:provided > [INFO] | | +- org.eclipse.jetty:jetty-xml:jar:9.2.14.v20151106:provided > [INFO] | | \- org.eclipse.jetty:jetty-servlet:jar:9.2.14.v20151106:provided > [INFO] | | \- > org.eclipse.jetty:jetty-security:jar:9.2.14.v20151106:provided > [INFO] | +- org.eclipse.jetty:jetty-servlets:jar:9.2.14.v20151106:provided >
[jira] [Created] (MDEP-906) AbstractSerializingVisitor should use a writer, not a printwriter
Elliotte Rusty Harold created MDEP-906: -- Summary: AbstractSerializingVisitor should use a writer, not a printwriter Key: MDEP-906 URL: https://issues.apache.org/jira/browse/MDEP-906 Project: Maven Dependency Plugin Issue Type: Bug Reporter: Elliotte Rusty Harold PrintWriter swallows exceptions. This is unfortunately an API breaking change, but it's an important one,. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MDEP-713) dependency:tree should not log info the user doesn't ask for
[ https://issues.apache.org/jira/browse/MDEP-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816042#comment-17816042 ] Elliotte Rusty Harold edited comment on MDEP-713 at 2/9/24 12:42 PM: - No, outputFile is not what I'm asking for. I want to see what I asked for, on the console, and nothing else (unless the project can't be built at all). The single command mvn dependency:tree should not do anything but print the dependency tree. Everything else is an implementation detail. Some of this can be fixed by reducing excess logging in other components like the resolver. However, ultimately we need a way to redirect and suppress all those logs and only print output from this plugin. was (Author: elharo): No, outputFile is not what I'm asking for. I want to see what I asked for, on the console, and nothing else (unless the project can't be built at all). The single command mvn dependency:tree should not do anything but print the dependency tree. Everything else is an implementation detail. > dependency:tree should not log info the user doesn't ask for > > > Key: MDEP-713 > URL: https://issues.apache.org/jira/browse/MDEP-713 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: tree >Reporter: Elliotte Rusty Harold >Priority: Major > Fix For: waiting-for-feedback > > > I'm going to start this report here, though I kind of expect it slips into > core and a lot of other components. Suppose I run mvn dependency:tree on > Guava. As a user here's what I want to see (though probably minus the [INFO] > prefix): > [INFO] com.google.guava:guava-gwt:jar:HEAD-jre-SNAPSHOT > [INFO] +- com.google.guava:failureaccess:jar:1.0.1:compile > [INFO] +- com.google.guava:guava:jar:HEAD-jre-SNAPSHOT:compile > [INFO] | +- > com.google.guava:listenablefuture:jar:.0-empty-to-avoid-conflict-with-guava:compile > [INFO] | +- com.google.code.findbugs:jsr305:jar:3.0.2:compile > [INFO] | +- com.google.errorprone:error_prone_annotations:jar:2.3.4:compile > [INFO] | \- com.google.j2objc:j2objc-annotations:jar:1.3:compile > [INFO] +- com.google.elemental2:elemental2-promise:jar:1.0.0-RC1:compile > [INFO] | +- com.google.jsinterop:jsinterop-annotations:jar:1.0.2:compile > [INFO] | \- com.google.jsinterop:base:jar:1.0.0-RC1:compile > [INFO] +- com.google.guava:guava-testlib:jar:HEAD-jre-SNAPSHOT:test > [INFO] | \- junit:junit:jar:4.13:test > [INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:test > [INFO] +- com.google.guava:guava-testlib:jar:tests:HEAD-jre-SNAPSHOT:test > [INFO] +- com.google.guava:guava-tests:jar:tests:HEAD-jre-SNAPSHOT:test > [INFO] +- com.google.gwt:gwt-dev:jar:2.8.2:provided > [INFO] | +- com.google.code.gson:gson:jar:2.6.2:provided > [INFO] | +- org.ow2.asm:asm:jar:5.0.3:provided > [INFO] | +- org.ow2.asm:asm-util:jar:5.0.3:provided > [INFO] | | \- org.ow2.asm:asm-tree:jar:5.0.3:provided > [INFO] | +- org.ow2.asm:asm-commons:jar:5.0.3:provided > [INFO] | +- colt:colt:jar:1.2.0:provided > [INFO] | +- ant:ant:jar:1.6.5:provided > [INFO] | +- commons-collections:commons-collections:jar:3.2.2:provided > [INFO] | +- commons-io:commons-io:jar:2.4:provided > [INFO] | +- com.ibm.icu:icu4j:jar:50.1.1:provided > [INFO] | +- tapestry:tapestry:jar:4.0.2:provided > [INFO] | +- net.sourceforge.htmlunit:htmlunit:jar:2.19:provided > [INFO] | | +- xalan:xalan:jar:2.7.2:provided > [INFO] | | | \- xalan:serializer:jar:2.7.2:provided > [INFO] | | +- org.apache.commons:commons-lang3:jar:3.4:provided > [INFO] | | +- org.apache.httpcomponents:httpclient:jar:4.5.1:provided > [INFO] | | | \- org.apache.httpcomponents:httpcore:jar:4.4.3:provided > [INFO] | | +- org.apache.httpcomponents:httpmime:jar:4.5.1:provided > [INFO] | | +- commons-codec:commons-codec:jar:1.10:provided > [INFO] | | +- net.sourceforge.htmlunit:htmlunit-core-js:jar:2.17:provided > [INFO] | | +- xerces:xercesImpl:jar:2.11.0:provided > [INFO] | | | \- xml-apis:xml-apis:jar:1.4.01:provided > [INFO] | | +- net.sourceforge.nekohtml:nekohtml:jar:1.9.22:provided > [INFO] | | +- net.sourceforge.cssparser:cssparser:jar:0.9.18:provided > [INFO] | | +- commons-logging:commons-logging:jar:1.2:provided > [INFO] | | \- > org.eclipse.jetty.websocket:websocket-client:jar:9.2.13.v20150730:provided > [INFO] | | \- > org.eclipse.jetty.websocket:websocket-common:jar:9.2.13.v20150730:provided > [INFO] | |\- > org.eclipse.jetty.websocket:websocket-api:jar:9.2.13.v20150730:provided > [INFO] | +- org.eclipse.jetty:jetty-webapp:jar:9.2.14.v20151106:provided > [INFO] | | +- org.eclipse.jetty:jetty-xml:jar:9.2.14.v20151106:provided > [INFO] | | \- org.eclipse.jetty:jetty-servlet:jar:9.2.14.v20151106:provided > [INFO] | | \- >
[jira] [Commented] (MDEP-713) dependency:tree should not log info the user doesn't ask for
[ https://issues.apache.org/jira/browse/MDEP-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816042#comment-17816042 ] Elliotte Rusty Harold commented on MDEP-713: No, outputFile is not what I'm asking for. I want to see what I asked for, on the console, and nothing else (unless the project can't be built at all). The single command mvn dependency:tree should not do anything but print the dependency tree. Everything else is an implementation detail. > dependency:tree should not log info the user doesn't ask for > > > Key: MDEP-713 > URL: https://issues.apache.org/jira/browse/MDEP-713 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: tree >Reporter: Elliotte Rusty Harold >Priority: Major > Fix For: waiting-for-feedback > > > I'm going to start this report here, though I kind of expect it slips into > core and a lot of other components. Suppose I run mvn dependency:tree on > Guava. As a user here's what I want to see (though probably minus the [INFO] > prefix): > [INFO] com.google.guava:guava-gwt:jar:HEAD-jre-SNAPSHOT > [INFO] +- com.google.guava:failureaccess:jar:1.0.1:compile > [INFO] +- com.google.guava:guava:jar:HEAD-jre-SNAPSHOT:compile > [INFO] | +- > com.google.guava:listenablefuture:jar:.0-empty-to-avoid-conflict-with-guava:compile > [INFO] | +- com.google.code.findbugs:jsr305:jar:3.0.2:compile > [INFO] | +- com.google.errorprone:error_prone_annotations:jar:2.3.4:compile > [INFO] | \- com.google.j2objc:j2objc-annotations:jar:1.3:compile > [INFO] +- com.google.elemental2:elemental2-promise:jar:1.0.0-RC1:compile > [INFO] | +- com.google.jsinterop:jsinterop-annotations:jar:1.0.2:compile > [INFO] | \- com.google.jsinterop:base:jar:1.0.0-RC1:compile > [INFO] +- com.google.guava:guava-testlib:jar:HEAD-jre-SNAPSHOT:test > [INFO] | \- junit:junit:jar:4.13:test > [INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:test > [INFO] +- com.google.guava:guava-testlib:jar:tests:HEAD-jre-SNAPSHOT:test > [INFO] +- com.google.guava:guava-tests:jar:tests:HEAD-jre-SNAPSHOT:test > [INFO] +- com.google.gwt:gwt-dev:jar:2.8.2:provided > [INFO] | +- com.google.code.gson:gson:jar:2.6.2:provided > [INFO] | +- org.ow2.asm:asm:jar:5.0.3:provided > [INFO] | +- org.ow2.asm:asm-util:jar:5.0.3:provided > [INFO] | | \- org.ow2.asm:asm-tree:jar:5.0.3:provided > [INFO] | +- org.ow2.asm:asm-commons:jar:5.0.3:provided > [INFO] | +- colt:colt:jar:1.2.0:provided > [INFO] | +- ant:ant:jar:1.6.5:provided > [INFO] | +- commons-collections:commons-collections:jar:3.2.2:provided > [INFO] | +- commons-io:commons-io:jar:2.4:provided > [INFO] | +- com.ibm.icu:icu4j:jar:50.1.1:provided > [INFO] | +- tapestry:tapestry:jar:4.0.2:provided > [INFO] | +- net.sourceforge.htmlunit:htmlunit:jar:2.19:provided > [INFO] | | +- xalan:xalan:jar:2.7.2:provided > [INFO] | | | \- xalan:serializer:jar:2.7.2:provided > [INFO] | | +- org.apache.commons:commons-lang3:jar:3.4:provided > [INFO] | | +- org.apache.httpcomponents:httpclient:jar:4.5.1:provided > [INFO] | | | \- org.apache.httpcomponents:httpcore:jar:4.4.3:provided > [INFO] | | +- org.apache.httpcomponents:httpmime:jar:4.5.1:provided > [INFO] | | +- commons-codec:commons-codec:jar:1.10:provided > [INFO] | | +- net.sourceforge.htmlunit:htmlunit-core-js:jar:2.17:provided > [INFO] | | +- xerces:xercesImpl:jar:2.11.0:provided > [INFO] | | | \- xml-apis:xml-apis:jar:1.4.01:provided > [INFO] | | +- net.sourceforge.nekohtml:nekohtml:jar:1.9.22:provided > [INFO] | | +- net.sourceforge.cssparser:cssparser:jar:0.9.18:provided > [INFO] | | +- commons-logging:commons-logging:jar:1.2:provided > [INFO] | | \- > org.eclipse.jetty.websocket:websocket-client:jar:9.2.13.v20150730:provided > [INFO] | | \- > org.eclipse.jetty.websocket:websocket-common:jar:9.2.13.v20150730:provided > [INFO] | |\- > org.eclipse.jetty.websocket:websocket-api:jar:9.2.13.v20150730:provided > [INFO] | +- org.eclipse.jetty:jetty-webapp:jar:9.2.14.v20151106:provided > [INFO] | | +- org.eclipse.jetty:jetty-xml:jar:9.2.14.v20151106:provided > [INFO] | | \- org.eclipse.jetty:jetty-servlet:jar:9.2.14.v20151106:provided > [INFO] | | \- > org.eclipse.jetty:jetty-security:jar:9.2.14.v20151106:provided > [INFO] | +- org.eclipse.jetty:jetty-servlets:jar:9.2.14.v20151106:provided > [INFO] | | +- > org.eclipse.jetty:jetty-continuation:jar:9.2.14.v20151106:provided > [INFO] | | +- org.eclipse.jetty:jetty-http:jar:9.2.14.v20151106:provided > [INFO] | | +- org.eclipse.jetty:jetty-util:jar:9.2.14.v20151106:provided > [INFO] | | \- org.eclipse.jetty:jetty-io:jar:9.2.14.v20151106:provided > [INFO] | +- org.eclipse.jetty:jetty-annotations:jar:9.2.14.v20151106:provided > [INFO] | | +-
[jira] [Commented] (MSHARED-1355) Tests seem broken due to javac on JDK 21
[ https://issues.apache.org/jira/browse/MSHARED-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815778#comment-17815778 ] Elliotte Rusty Harold commented on MSHARED-1355: denedabot parent upgrade PR is also failing with different issues: [INFO] Error: Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.4.1:enforce (enforce-maven-version) on project maven-dependency-analyzer: Error: Rule 0: org.apache.maven.enforcer.rules.version.RequireMavenVersion failed with message: Error: Detected Maven Version: 3.2.5 is not in the allowed range [3.6.3,). Error: -> [Help 1] Possibly this one will require a little manual attention. > Tests seem broken due to javac on JDK 21 > > > Key: MSHARED-1355 > URL: https://issues.apache.org/jira/browse/MSHARED-1355 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-analyzer, maven-shared-utils >Reporter: Elliotte Rusty Harold >Priority: Major > > Noticed this in the JDK 21 report on Github. Looks like > ClassFileVisitorUtilsTest might be importing classes that are hidden or gone > in Java 21: > [ERROR] Step 'palantir-java-format' found problem in > 'src/test/java/org/apache/maven/shared/dependency/analyzer/ClassFileVisitorUtilsTest.java': > 'com.sun.tools.javac.tree.JCTree > com.sun.tools.javac.tree.JCTree$JCImport.getQualifiedIdentifier()' > java.lang.NoSuchMethodError: 'com.sun.tools.javac.tree.JCTree > com.sun.tools.javac.tree.JCTree$JCImport.getQualifiedIdentifier()' > at com.palantir.javaformat.java.RemoveUnusedImports.getSimpleName > (RemoveUnusedImports.java:245) > at com.palantir.javaformat.java.RemoveUnusedImports.buildReplacements > (RemoveUnusedImports.java:225) > at com.palantir.javaformat.java.RemoveUnusedImports.removeUnusedImports > (RemoveUnusedImports.java:209) > at com.diffplug.spotless.glue.pjf.PalantirJavaFormatFormatterFunc.apply > (PalantirJavaFormatFormatterFunc.java:42) > at com.diffplug.spotless.FormatterFunc.apply (FormatterFunc.java:32) > at com.diffplug.spotless.FormatterStepImpl$Standard.format > (FormatterStepImpl.java:82) > at com.diffplug.spotless.FormatterStep$Strict.format > (FormatterStep.java:88) > at com.diffplug.spotless.Formatter.compute (Formatter.java:246) > at com.diffplug.spotless.PaddedCell.calculateDirtyState > (PaddedCell.java:203) > at com.diffplug.spotless.PaddedCell.calculateDirtyState > (PaddedCell.java:190) > at com.diffplug.spotless.maven.SpotlessCheckMojo.process > (SpotlessCheckMojo.java:54) > at com.diffplug.spotless.maven.AbstractSpotlessMojo.execute > (AbstractSpotlessMojo.java:229) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo > (DefaultBuildPluginManager.java:137) > 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.DirectMethodHandleAccessor.invoke > (DirectMethodHandleAccessor.java:103) > at java.lang.reflect.Method.invoke (Method.java:580) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced > (Launcher.java:282) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch > (Launcher.java:225) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode > (Launcher.java:406) > at org.codehaus.plexus.classworlds.launcher.Launcher.main > (Launcher.java:347) > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 10.188 s > [INFO] Finished at:
[jira] [Commented] (MSHARED-1355) Tests seem broken due to javac on JDK 21
[ https://issues.apache.org/jira/browse/MSHARED-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815704#comment-17815704 ] Elliotte Rusty Harold commented on MSHARED-1355: https://github.com/diffplug/spotless/pull/1920 > Tests seem broken due to javac on JDK 21 > > > Key: MSHARED-1355 > URL: https://issues.apache.org/jira/browse/MSHARED-1355 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-analyzer, maven-shared-utils >Reporter: Elliotte Rusty Harold >Priority: Major > > Noticed this in the JDK 21 report on Github. Looks like > ClassFileVisitorUtilsTest might be importing classes that are hidden or gone > in Java 21: > [ERROR] Step 'palantir-java-format' found problem in > 'src/test/java/org/apache/maven/shared/dependency/analyzer/ClassFileVisitorUtilsTest.java': > 'com.sun.tools.javac.tree.JCTree > com.sun.tools.javac.tree.JCTree$JCImport.getQualifiedIdentifier()' > java.lang.NoSuchMethodError: 'com.sun.tools.javac.tree.JCTree > com.sun.tools.javac.tree.JCTree$JCImport.getQualifiedIdentifier()' > at com.palantir.javaformat.java.RemoveUnusedImports.getSimpleName > (RemoveUnusedImports.java:245) > at com.palantir.javaformat.java.RemoveUnusedImports.buildReplacements > (RemoveUnusedImports.java:225) > at com.palantir.javaformat.java.RemoveUnusedImports.removeUnusedImports > (RemoveUnusedImports.java:209) > at com.diffplug.spotless.glue.pjf.PalantirJavaFormatFormatterFunc.apply > (PalantirJavaFormatFormatterFunc.java:42) > at com.diffplug.spotless.FormatterFunc.apply (FormatterFunc.java:32) > at com.diffplug.spotless.FormatterStepImpl$Standard.format > (FormatterStepImpl.java:82) > at com.diffplug.spotless.FormatterStep$Strict.format > (FormatterStep.java:88) > at com.diffplug.spotless.Formatter.compute (Formatter.java:246) > at com.diffplug.spotless.PaddedCell.calculateDirtyState > (PaddedCell.java:203) > at com.diffplug.spotless.PaddedCell.calculateDirtyState > (PaddedCell.java:190) > at com.diffplug.spotless.maven.SpotlessCheckMojo.process > (SpotlessCheckMojo.java:54) > at com.diffplug.spotless.maven.AbstractSpotlessMojo.execute > (AbstractSpotlessMojo.java:229) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo > (DefaultBuildPluginManager.java:137) > 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.DirectMethodHandleAccessor.invoke > (DirectMethodHandleAccessor.java:103) > at java.lang.reflect.Method.invoke (Method.java:580) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced > (Launcher.java:282) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch > (Launcher.java:225) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode > (Launcher.java:406) > at org.codehaus.plexus.classworlds.launcher.Launcher.main > (Launcher.java:347) > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 10.188 s > [INFO] Finished at: 2024-02-05T04:40:59Z -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1355) Tests seem broken due to javac on JDK 21
[ https://issues.apache.org/jira/browse/MSHARED-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815701#comment-17815701 ] Elliotte Rusty Harold commented on MSHARED-1355: Or possibly it's a Palantir issue? In either case it breaks the CI so we need to fix it. > Tests seem broken due to javac on JDK 21 > > > Key: MSHARED-1355 > URL: https://issues.apache.org/jira/browse/MSHARED-1355 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-analyzer, maven-shared-utils >Reporter: Elliotte Rusty Harold >Priority: Major > > Noticed this in the JDK 21 report on Github. Looks like > ClassFileVisitorUtilsTest might be importing classes that are hidden or gone > in Java 21: > [ERROR] Step 'palantir-java-format' found problem in > 'src/test/java/org/apache/maven/shared/dependency/analyzer/ClassFileVisitorUtilsTest.java': > 'com.sun.tools.javac.tree.JCTree > com.sun.tools.javac.tree.JCTree$JCImport.getQualifiedIdentifier()' > java.lang.NoSuchMethodError: 'com.sun.tools.javac.tree.JCTree > com.sun.tools.javac.tree.JCTree$JCImport.getQualifiedIdentifier()' > at com.palantir.javaformat.java.RemoveUnusedImports.getSimpleName > (RemoveUnusedImports.java:245) > at com.palantir.javaformat.java.RemoveUnusedImports.buildReplacements > (RemoveUnusedImports.java:225) > at com.palantir.javaformat.java.RemoveUnusedImports.removeUnusedImports > (RemoveUnusedImports.java:209) > at com.diffplug.spotless.glue.pjf.PalantirJavaFormatFormatterFunc.apply > (PalantirJavaFormatFormatterFunc.java:42) > at com.diffplug.spotless.FormatterFunc.apply (FormatterFunc.java:32) > at com.diffplug.spotless.FormatterStepImpl$Standard.format > (FormatterStepImpl.java:82) > at com.diffplug.spotless.FormatterStep$Strict.format > (FormatterStep.java:88) > at com.diffplug.spotless.Formatter.compute (Formatter.java:246) > at com.diffplug.spotless.PaddedCell.calculateDirtyState > (PaddedCell.java:203) > at com.diffplug.spotless.PaddedCell.calculateDirtyState > (PaddedCell.java:190) > at com.diffplug.spotless.maven.SpotlessCheckMojo.process > (SpotlessCheckMojo.java:54) > at com.diffplug.spotless.maven.AbstractSpotlessMojo.execute > (AbstractSpotlessMojo.java:229) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo > (DefaultBuildPluginManager.java:137) > 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.DirectMethodHandleAccessor.invoke > (DirectMethodHandleAccessor.java:103) > at java.lang.reflect.Method.invoke (Method.java:580) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced > (Launcher.java:282) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch > (Launcher.java:225) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode > (Launcher.java:406) > at org.codehaus.plexus.classworlds.launcher.Launcher.main > (Launcher.java:347) > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 10.188 s > [INFO] Finished at: 2024-02-05T04:40:59Z -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHARED-1355) Tests seem broken due to javac on JDK 21
[ https://issues.apache.org/jira/browse/MSHARED-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MSHARED-1355: --- Component/s: maven-dependency-analyzer > Tests seem broken due to javac on JDK 21 > > > Key: MSHARED-1355 > URL: https://issues.apache.org/jira/browse/MSHARED-1355 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-analyzer, maven-shared-utils >Reporter: Elliotte Rusty Harold >Priority: Major > > Noticed this in the JDK 21 report on Github. Looks like > ClassFileVisitorUtilsTest might be importing classes that are hidden or gone > in Java 21: > [ERROR] Step 'palantir-java-format' found problem in > 'src/test/java/org/apache/maven/shared/dependency/analyzer/ClassFileVisitorUtilsTest.java': > 'com.sun.tools.javac.tree.JCTree > com.sun.tools.javac.tree.JCTree$JCImport.getQualifiedIdentifier()' > java.lang.NoSuchMethodError: 'com.sun.tools.javac.tree.JCTree > com.sun.tools.javac.tree.JCTree$JCImport.getQualifiedIdentifier()' > at com.palantir.javaformat.java.RemoveUnusedImports.getSimpleName > (RemoveUnusedImports.java:245) > at com.palantir.javaformat.java.RemoveUnusedImports.buildReplacements > (RemoveUnusedImports.java:225) > at com.palantir.javaformat.java.RemoveUnusedImports.removeUnusedImports > (RemoveUnusedImports.java:209) > at com.diffplug.spotless.glue.pjf.PalantirJavaFormatFormatterFunc.apply > (PalantirJavaFormatFormatterFunc.java:42) > at com.diffplug.spotless.FormatterFunc.apply (FormatterFunc.java:32) > at com.diffplug.spotless.FormatterStepImpl$Standard.format > (FormatterStepImpl.java:82) > at com.diffplug.spotless.FormatterStep$Strict.format > (FormatterStep.java:88) > at com.diffplug.spotless.Formatter.compute (Formatter.java:246) > at com.diffplug.spotless.PaddedCell.calculateDirtyState > (PaddedCell.java:203) > at com.diffplug.spotless.PaddedCell.calculateDirtyState > (PaddedCell.java:190) > at com.diffplug.spotless.maven.SpotlessCheckMojo.process > (SpotlessCheckMojo.java:54) > at com.diffplug.spotless.maven.AbstractSpotlessMojo.execute > (AbstractSpotlessMojo.java:229) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo > (DefaultBuildPluginManager.java:137) > 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.DirectMethodHandleAccessor.invoke > (DirectMethodHandleAccessor.java:103) > at java.lang.reflect.Method.invoke (Method.java:580) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced > (Launcher.java:282) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch > (Launcher.java:225) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode > (Launcher.java:406) > at org.codehaus.plexus.classworlds.launcher.Launcher.main > (Launcher.java:347) > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 10.188 s > [INFO] Finished at: 2024-02-05T04:40:59Z -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1355) Tests seem broken due to javac on JDK 21
Elliotte Rusty Harold created MSHARED-1355: -- Summary: Tests seem broken due to javac on JDK 21 Key: MSHARED-1355 URL: https://issues.apache.org/jira/browse/MSHARED-1355 Project: Maven Shared Components Issue Type: Bug Components: maven-shared-utils Reporter: Elliotte Rusty Harold Noticed this in the JDK 21 report on Github. Looks like ClassFileVisitorUtilsTest might be importing classes that are hidden or gone in Java 21: [ERROR] Step 'palantir-java-format' found problem in 'src/test/java/org/apache/maven/shared/dependency/analyzer/ClassFileVisitorUtilsTest.java': 'com.sun.tools.javac.tree.JCTree com.sun.tools.javac.tree.JCTree$JCImport.getQualifiedIdentifier()' java.lang.NoSuchMethodError: 'com.sun.tools.javac.tree.JCTree com.sun.tools.javac.tree.JCTree$JCImport.getQualifiedIdentifier()' at com.palantir.javaformat.java.RemoveUnusedImports.getSimpleName (RemoveUnusedImports.java:245) at com.palantir.javaformat.java.RemoveUnusedImports.buildReplacements (RemoveUnusedImports.java:225) at com.palantir.javaformat.java.RemoveUnusedImports.removeUnusedImports (RemoveUnusedImports.java:209) at com.diffplug.spotless.glue.pjf.PalantirJavaFormatFormatterFunc.apply (PalantirJavaFormatFormatterFunc.java:42) at com.diffplug.spotless.FormatterFunc.apply (FormatterFunc.java:32) at com.diffplug.spotless.FormatterStepImpl$Standard.format (FormatterStepImpl.java:82) at com.diffplug.spotless.FormatterStep$Strict.format (FormatterStep.java:88) at com.diffplug.spotless.Formatter.compute (Formatter.java:246) at com.diffplug.spotless.PaddedCell.calculateDirtyState (PaddedCell.java:203) at com.diffplug.spotless.PaddedCell.calculateDirtyState (PaddedCell.java:190) at com.diffplug.spotless.maven.SpotlessCheckMojo.process (SpotlessCheckMojo.java:54) at com.diffplug.spotless.maven.AbstractSpotlessMojo.execute (AbstractSpotlessMojo.java:229) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137) 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.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:103) at java.lang.reflect.Method.invoke (Method.java:580) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282) at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406) at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347) [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 10.188 s [INFO] Finished at: 2024-02-05T04:40:59Z -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MPMD-391) Log what developers care about and not what they don't
[ https://issues.apache.org/jira/browse/MPMD-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806570#comment-17806570 ] Elliotte Rusty Harold edited comment on MPMD-391 at 1/26/24 8:40 PM: - Yes, this crosses a lot of projects. It does surface here. Also printing the actual issue PMD flagged should also be in our control. Even if PMD only writes that into a file, we should parse the data out of that file and print the problem here. was (Author: elharo): Yes, this crosses a lot of projects. It does surface here. Also printing the actual issue PMD flagged should also be in out control. Even if PMD only writes that into a file, we should parse the data out of that file and print the problem here. > Log what developers care about and not what they don't > -- > > Key: MPMD-391 > URL: https://issues.apache.org/jira/browse/MPMD-391 > Project: Maven PMD Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Major > > Here's output from a recent PMD plugin run that failed: > [INFO] >>> maven-pmd-plugin:3.21.2:check (default-cli) > :pmd @ commons-io >>> > [INFO] > [INFO] --- maven-pmd-plugin:3.21.2:pmd (pmd) @ commons-io --- > [INFO] PMD version: 6.55.0 > [INFO] Rendering content with > org.apache.maven.skins:maven-default-skin:jar:1.3 skin. > [INFO] > [INFO] <<< maven-pmd-plugin:3.21.2:check (default-cli) < :pmd @ commons-io <<< > [INFO] > [INFO] > [INFO] --- maven-pmd-plugin:3.21.2:check (default-cli) @ commons-io --- > [INFO] PMD version: 6.55.0 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 05:22 min > [INFO] Finished at: 2024-01-14T14:11:30Z > [INFO] > > Error: Failed to execute goal > org.apache.maven.plugins:maven-pmd-plugin:3.21.2:check (default-cli) on > project commons-io: You have 1 PMD violation. For more details see: > /home/runner/work/commons-io/commons-io/target/pmd.xml -> [Help 1] > Error: > Error: To see the full stack trace of the errors, re-run Maven with the -e > switch. > Error: Re-run Maven using the -X switch to enable full debug logging. > Error: > Error: For more information about the errors and possible solutions, please > read the following articles: > Error: [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > Error: Process completed with exit code 1. > Things I don't care about that are printed: > * PMD version > * Doxia skin > * Blank lines > * Total time > * Timestamp when it finished > * Generic information about Mojo failures > * Exit code from Mojo > The one thing I care about: > * The actual error that caused the failure > Everything in the first list can be hidden in some random log file no one > will ever look at. Everything in the second list should be front and center. > Instead Maven gets this exactly backwards, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPMD-391) Log what developers care about and not what they don't
[ https://issues.apache.org/jira/browse/MPMD-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806834#comment-17806834 ] Elliotte Rusty Harold commented on MPMD-391: I want less logs, not more. "Running PMD version 6.55.0 to target/pmd.xml" is not info the developer needs or cares about. It is not actionable. Neither is the skin. Neither is the version of the plugin. These are at most, debugging info for plugin developers. They should not be shown to normal end users who just want to build their project. > Log what developers care about and not what they don't > -- > > Key: MPMD-391 > URL: https://issues.apache.org/jira/browse/MPMD-391 > Project: Maven PMD Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Major > > Here's output from a recent PMD plugin run that failed: > [INFO] >>> maven-pmd-plugin:3.21.2:check (default-cli) > :pmd @ commons-io >>> > [INFO] > [INFO] --- maven-pmd-plugin:3.21.2:pmd (pmd) @ commons-io --- > [INFO] PMD version: 6.55.0 > [INFO] Rendering content with > org.apache.maven.skins:maven-default-skin:jar:1.3 skin. > [INFO] > [INFO] <<< maven-pmd-plugin:3.21.2:check (default-cli) < :pmd @ commons-io <<< > [INFO] > [INFO] > [INFO] --- maven-pmd-plugin:3.21.2:check (default-cli) @ commons-io --- > [INFO] PMD version: 6.55.0 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 05:22 min > [INFO] Finished at: 2024-01-14T14:11:30Z > [INFO] > > Error: Failed to execute goal > org.apache.maven.plugins:maven-pmd-plugin:3.21.2:check (default-cli) on > project commons-io: You have 1 PMD violation. For more details see: > /home/runner/work/commons-io/commons-io/target/pmd.xml -> [Help 1] > Error: > Error: To see the full stack trace of the errors, re-run Maven with the -e > switch. > Error: Re-run Maven using the -X switch to enable full debug logging. > Error: > Error: For more information about the errors and possible solutions, please > read the following articles: > Error: [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > Error: Process completed with exit code 1. > Things I don't care about that are printed: > * PMD version > * Doxia skin > * Blank lines > * Total time > * Timestamp when it finished > * Generic information about Mojo failures > * Exit code from Mojo > The one thing I care about: > * The actual error that caused the failure > Everything in the first list can be hidden in some random log file no one > will ever look at. Everything in the second list should be front and center. > Instead Maven gets this exactly backwards, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPMD-391) Log what developers care about and not what they don't
[ https://issues.apache.org/jira/browse/MPMD-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806570#comment-17806570 ] Elliotte Rusty Harold commented on MPMD-391: Yes, this crosses a lot of projects. It does surface here. Also printing the actual issue PMD flagged should also be in out control. Even if PMD only writes that into a file, we should parse the data out of that file and print the problem here. > Log what developers care about and not what they don't > -- > > Key: MPMD-391 > URL: https://issues.apache.org/jira/browse/MPMD-391 > Project: Maven PMD Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Major > > Here's output from a recent PMD plugin run that failed: > [INFO] >>> maven-pmd-plugin:3.21.2:check (default-cli) > :pmd @ commons-io >>> > [INFO] > [INFO] --- maven-pmd-plugin:3.21.2:pmd (pmd) @ commons-io --- > [INFO] PMD version: 6.55.0 > [INFO] Rendering content with > org.apache.maven.skins:maven-default-skin:jar:1.3 skin. > [INFO] > [INFO] <<< maven-pmd-plugin:3.21.2:check (default-cli) < :pmd @ commons-io <<< > [INFO] > [INFO] > [INFO] --- maven-pmd-plugin:3.21.2:check (default-cli) @ commons-io --- > [INFO] PMD version: 6.55.0 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 05:22 min > [INFO] Finished at: 2024-01-14T14:11:30Z > [INFO] > > Error: Failed to execute goal > org.apache.maven.plugins:maven-pmd-plugin:3.21.2:check (default-cli) on > project commons-io: You have 1 PMD violation. For more details see: > /home/runner/work/commons-io/commons-io/target/pmd.xml -> [Help 1] > Error: > Error: To see the full stack trace of the errors, re-run Maven with the -e > switch. > Error: Re-run Maven using the -X switch to enable full debug logging. > Error: > Error: For more information about the errors and possible solutions, please > read the following articles: > Error: [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > Error: Process completed with exit code 1. > Things I don't care about that are printed: > * PMD version > * Doxia skin > * Blank lines > * Total time > * Timestamp when it finished > * Generic information about Mojo failures > * Exit code from Mojo > The one thing I care about: > * The actual error that caused the failure > Everything in the first list can be hidden in some random log file no one > will ever look at. Everything in the second list should be front and center. > Instead Maven gets this exactly backwards, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPMD-391) Log what developers care about and not what they don't
Elliotte Rusty Harold created MPMD-391: -- Summary: Log what developers care about and not what they don't Key: MPMD-391 URL: https://issues.apache.org/jira/browse/MPMD-391 Project: Maven PMD Plugin Issue Type: Improvement Reporter: Elliotte Rusty Harold Here's output from a recent PMD plugin run that failed: [INFO] >>> maven-pmd-plugin:3.21.2:check (default-cli) > :pmd @ commons-io >>> [INFO] [INFO] --- maven-pmd-plugin:3.21.2:pmd (pmd) @ commons-io --- [INFO] PMD version: 6.55.0 [INFO] Rendering content with org.apache.maven.skins:maven-default-skin:jar:1.3 skin. [INFO] [INFO] <<< maven-pmd-plugin:3.21.2:check (default-cli) < :pmd @ commons-io <<< [INFO] [INFO] [INFO] --- maven-pmd-plugin:3.21.2:check (default-cli) @ commons-io --- [INFO] PMD version: 6.55.0 [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 05:22 min [INFO] Finished at: 2024-01-14T14:11:30Z [INFO] Error: Failed to execute goal org.apache.maven.plugins:maven-pmd-plugin:3.21.2:check (default-cli) on project commons-io: You have 1 PMD violation. For more details see: /home/runner/work/commons-io/commons-io/target/pmd.xml -> [Help 1] Error: Error: To see the full stack trace of the errors, re-run Maven with the -e switch. Error: Re-run Maven using the -X switch to enable full debug logging. Error: Error: For more information about the errors and possible solutions, please read the following articles: Error: [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException Error: Process completed with exit code 1. Things I don't care about that are printed: * PMD version * Doxia skin * Blank lines * Total time * Timestamp when it finished * Generic information about Mojo failures * Exit code from Mojo The one thing I care about: * The actual error that caused the failure Everything in the first list can be hidden in some random log file no one will ever look at. Everything in the second list should be front and center. Instead Maven gets this exactly backwards, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6399) Lift JDK minimum to JDK 8
[ https://issues.apache.org/jira/browse/MNG-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805747#comment-17805747 ] Elliotte Rusty Harold commented on MNG-6399: Looks like someone neglected to update some line in some file somewhere. Not really surprising. It happens all the time. Feel free to send a PR and assign it to me if you figutre out where. perhaps from apache-maven/README.txt though that was updated on github 3 years ago. > Lift JDK minimum to JDK 8 > - > > Key: MNG-6399 > URL: https://issues.apache.org/jira/browse/MNG-6399 > Project: Maven > Issue Type: Task >Affects Versions: 3.6.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.9.0, 4.0.0-alpha-2, 4.0.0 > > Attachments: maven-3.9.6-zip-content.png > > > I would like to lift the minimum of Maven Core to JDK 8 (I think it's time).. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPH-207) Exercise output of an expression returning a null object.
[
https://issues.apache.org/jira/browse/MPH-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MPH-207:
--
Fix Version/s: next-release
> Exercise output of an expression returning a null object.
> -
>
> Key: MPH-207
> URL: https://issues.apache.org/jira/browse/MPH-207
> Project: Maven Help Plugin
> Issue Type: Test
> Components: evaluate
>Reporter: Vincent Latombe
>Priority: Minor
> Fix For: next-release
>
>
> There is no direct way to check for existence of an expression, so I'm
> comparing the output of an expression I expect to find (or not) with the
> output of an expression I know doesn't exist.
> The output of {{help:evaluate}} in case of a missing property is {{null
> object or invalid expression}} but it is not exercised via tests so it could
> potentially regress if someone decides to change the output one day.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MPH-207) Exercise output of an expression returning a null object.
[
https://issues.apache.org/jira/browse/MPH-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MPH-207.
-
> Exercise output of an expression returning a null object.
> -
>
> Key: MPH-207
> URL: https://issues.apache.org/jira/browse/MPH-207
> Project: Maven Help Plugin
> Issue Type: Test
> Components: evaluate
>Reporter: Vincent Latombe
>Priority: Minor
> Fix For: next-release
>
>
> There is no direct way to check for existence of an expression, so I'm
> comparing the output of an expression I expect to find (or not) with the
> output of an expression I know doesn't exist.
> The output of {{help:evaluate}} in case of a missing property is {{null
> object or invalid expression}} but it is not exercised via tests so it could
> potentially regress if someone decides to change the output one day.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MPH-207) Exercise output of an expression returning a null object.
[
https://issues.apache.org/jira/browse/MPH-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MPH-207.
---
Resolution: Fixed
> Exercise output of an expression returning a null object.
> -
>
> Key: MPH-207
> URL: https://issues.apache.org/jira/browse/MPH-207
> Project: Maven Help Plugin
> Issue Type: Test
> Components: evaluate
>Reporter: Vincent Latombe
>Priority: Minor
>
> There is no direct way to check for existence of an expression, so I'm
> comparing the output of an expression I expect to find (or not) with the
> output of an expression I know doesn't exist.
> The output of {{help:evaluate}} in case of a missing property is {{null
> object or invalid expression}} but it is not exercised via tests so it could
> potentially regress if someone decides to change the output one day.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSHARED-995) Documents of patterns used for filtering
[
https://issues.apache.org/jira/browse/MSHARED-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MSHARED-995:
--
Summary: Documents of patterns used for filtering (was: documentation)
> Documents of patterns used for filtering
>
>
> Key: MSHARED-995
> URL: https://issues.apache.org/jira/browse/MSHARED-995
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-filtering
>Reporter: Delany
>Priority: Major
>
> There's basically no documentation on the pattern matching used to filter
> resources. The filter component documentation reads like dev documentation,
> and I'm left to trail-and-error to figure it out. Adding to the confusion is
> that Maven plugins can implement their own pattern matching/strain of regex.
> I think the assembly plugin does its own thing. Its frustrating enough when
> regex doesn't match so can I at least be clear on the algorithm.
> For example, I want to set a more specific filter to copy resources. The
> filename may have anywhere between 1 and 5 characters followed by an
> extension.
> I tried five question marks, but that only matches 5 characters not 4.
>
> {code:java}
> ?.changelog
> {code}
> There's no support for something like
>
> {code:java}
> ?{1,5}.changelog
> {code}
>
> I see double asterisk in some patterns, suggesting globbing. Can this be
> stated? Perhaps at one point it was obvious - it may seem too simple to
> bother with. But the Internet is full of alternatives today and a simple
> write-up will save a lot of guess-work for newbies and those of us with bad
> memory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MSHARED-1022) Documents of patterns used for filtering
[
https://issues.apache.org/jira/browse/MSHARED-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MSHARED-1022.
--
> Documents of patterns used for filtering
>
>
> Key: MSHARED-1022
> URL: https://issues.apache.org/jira/browse/MSHARED-1022
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-common-artifact-filters
>Reporter: Slawomir Jaranowski
>Priority: Major
> Labels: up-for-grabs
>
> For class:
> - {{org.apache.maven.shared.artifact.filter.PatternIncludesArtifactFilter}}
> - {{org.apache.maven.shared.artifact.filter.PatternExcludesArtifactFilter}}
>
> we can use patterns for filtering artifact, but pattern string is not
> documented.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MSHARED-1022) Documents of patterns used for filtering
[
https://issues.apache.org/jira/browse/MSHARED-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MSHARED-1022.
Resolution: Duplicate
valid issue that will be tracked in an earlier bug
> Documents of patterns used for filtering
>
>
> Key: MSHARED-1022
> URL: https://issues.apache.org/jira/browse/MSHARED-1022
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-common-artifact-filters
>Reporter: Slawomir Jaranowski
>Priority: Major
> Labels: up-for-grabs
>
> For class:
> - {{org.apache.maven.shared.artifact.filter.PatternIncludesArtifactFilter}}
> - {{org.apache.maven.shared.artifact.filter.PatternExcludesArtifactFilter}}
>
> we can use patterns for filtering artifact, but pattern string is not
> documented.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MSHARED-1176) FileUtils.copyFile should support copying symlinks with non-existing targets
[
https://issues.apache.org/jira/browse/MSHARED-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold reassigned MSHARED-1176:
--
Assignee: Elliotte Rusty Harold
> FileUtils.copyFile should support copying symlinks with non-existing targets
>
>
> Key: MSHARED-1176
> URL: https://issues.apache.org/jira/browse/MSHARED-1176
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-shared-utils
>Affects Versions: maven-shared-utils-3.3.4
>Reporter: Konrad Windszus
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> Currently {{FileUtils.copyFile}} fails with an exception when it tries to
> copy a symbolic link which has a non-existing target.
> A similar issue was reported in MSHARED-1112 for maven-filtering.
> https://github.com/apache/maven-shared-utils/pull/110 has some currently
> failing test cases for that scenario.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MSHARED-1274) Deprecate the xml bits from maven-shared-utils
[ https://issues.apache.org/jira/browse/MSHARED-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MSHARED-1274. -- Assignee: Elliotte Rusty Harold > Deprecate the xml bits from maven-shared-utils > -- > > Key: MSHARED-1274 > URL: https://issues.apache.org/jira/browse/MSHARED-1274 > Project: Maven Shared Components > Issue Type: Task > Components: maven-shared-utils >Reporter: Guillaume Nodet >Assignee: Elliotte Rusty Harold >Priority: Major > Fix For: maven-shared-utils-next-release > > > The xml bits from plexus-utils are a de-facto part of the maven 3.x api and > we should not have two conflicting versions of it. Now that it has been > extract in a separate project in plexus-xml, I think it is time to deprecate > those classes in maven-shared-utils. Fwiw, the core implementation classes > are mainly implemented with Maven 4.x maven-xml-impl module, and the Xpp3Dom > class from plexus-xml is mainly a wrapper around the new XmlNode/XmlNodeImpl > class from maven, however the parser is still present in plexus-xml. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MSHARED-1274) Deprecate the xml bits from maven-shared-utils
[ https://issues.apache.org/jira/browse/MSHARED-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MSHARED-1274. Fix Version/s: maven-shared-utils-next-release Resolution: Fixed > Deprecate the xml bits from maven-shared-utils > -- > > Key: MSHARED-1274 > URL: https://issues.apache.org/jira/browse/MSHARED-1274 > Project: Maven Shared Components > Issue Type: Task > Components: maven-shared-utils >Reporter: Guillaume Nodet >Priority: Major > Fix For: maven-shared-utils-next-release > > > The xml bits from plexus-utils are a de-facto part of the maven 3.x api and > we should not have two conflicting versions of it. Now that it has been > extract in a separate project in plexus-xml, I think it is time to deprecate > those classes in maven-shared-utils. Fwiw, the core implementation classes > are mainly implemented with Maven 4.x maven-xml-impl module, and the Xpp3Dom > class from plexus-xml is mainly a wrapper around the new XmlNode/XmlNodeImpl > class from maven, however the parser is still present in plexus-xml. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MARCHETYPES-78) Update default Java version in archetype projects to 1.8
[
https://issues.apache.org/jira/browse/MARCHETYPES-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MARCHETYPES-78.
> Update default Java version in archetype projects to 1.8
>
>
> Key: MARCHETYPES-78
> URL: https://issues.apache.org/jira/browse/MARCHETYPES-78
> Project: Maven Archetype Bundles
> Issue Type: Improvement
>Reporter: jiri vanek
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> namely at least
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml
> still use 1.7 as default version.
> I'm happy to fix them all (see
> https://github.com/apache/maven-archetypes/pull/18 and
> https://issues.apache.org/jira/projects/MARCHETYPES/issues/MARCHETYPES-76),
> but first I need some ack from somebody with commit permissions to
> MARCHETYPES/https://github.com/apache/maven-archetypes
> {code:java}
> grep -ir -e maven.compiler.source -e maven.compiler.target| grep -v test
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.8
> maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.8
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
> ${jcv}
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
> ${jcv}
> {code}
> with tests:
> {code:java}
> grep -ir -e maven.compiler.source -e maven.compiler.target
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.8
> maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.8
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
> ${jcv}
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
> ${jcv}
>
[jira] [Resolved] (MARCHETYPES-78) Update default Java version in archetype projects to 1.8
[
https://issues.apache.org/jira/browse/MARCHETYPES-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MARCHETYPES-78.
--
Resolution: Fixed
> Update default Java version in archetype projects to 1.8
>
>
> Key: MARCHETYPES-78
> URL: https://issues.apache.org/jira/browse/MARCHETYPES-78
> Project: Maven Archetype Bundles
> Issue Type: Improvement
>Reporter: jiri vanek
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> namely at least
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml
> still use 1.7 as default version.
> I'm happy to fix them all (see
> https://github.com/apache/maven-archetypes/pull/18 and
> https://issues.apache.org/jira/projects/MARCHETYPES/issues/MARCHETYPES-76),
> but first I need some ack from somebody with commit permissions to
> MARCHETYPES/https://github.com/apache/maven-archetypes
> {code:java}
> grep -ir -e maven.compiler.source -e maven.compiler.target| grep -v test
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.8
> maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.8
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
> ${jcv}
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
> ${jcv}
> {code}
> with tests:
> {code:java}
> grep -ir -e maven.compiler.source -e maven.compiler.target
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.8
> maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.8
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
> ${jcv}
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
>
[jira] [Assigned] (MARCHETYPES-78) Update default Java version in archetype projects to 1.8
[
https://issues.apache.org/jira/browse/MARCHETYPES-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold reassigned MARCHETYPES-78:
Assignee: Elliotte Rusty Harold
> Update default Java version in archetype projects to 1.8
>
>
> Key: MARCHETYPES-78
> URL: https://issues.apache.org/jira/browse/MARCHETYPES-78
> Project: Maven Archetype Bundles
> Issue Type: Improvement
>Reporter: jiri vanek
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> namely at least
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml
> still use 1.7 as default version.
> I'm happy to fix them all (see
> https://github.com/apache/maven-archetypes/pull/18 and
> https://issues.apache.org/jira/projects/MARCHETYPES/issues/MARCHETYPES-76),
> but first I need some ack from somebody with commit permissions to
> MARCHETYPES/https://github.com/apache/maven-archetypes
> {code:java}
> grep -ir -e maven.compiler.source -e maven.compiler.target| grep -v test
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.8
> maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.8
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
> ${jcv}
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
> ${jcv}
> {code}
> with tests:
> {code:java}
> grep -ir -e maven.compiler.source -e maven.compiler.target
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.8
> maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.8
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
> ${jcv}
>
[jira] [Updated] (MARCHETYPES-78) Update default Java version in archetype projects to 1.8
[
https://issues.apache.org/jira/browse/MARCHETYPES-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MARCHETYPES-78:
-
Description:
namely at least
maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml
maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml
maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml
maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml
maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml
maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml
maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml
still use 1.7 as default version.
I'm happy to fix them all (see
https://github.com/apache/maven-archetypes/pull/18 and
https://issues.apache.org/jira/projects/MARCHETYPES/issues/MARCHETYPES-76), but
first I need some ack from somebody with commit permissions to
MARCHETYPES/https://github.com/apache/maven-archetypes
{code:java}
grep -ir -e maven.compiler.source -e maven.compiler.target| grep -v test
maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
1.7
maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
1.7
maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
1.7
maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
1.7
maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
1.7
maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
1.7
maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
1.7
maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
1.7
maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
1.8
maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
1.8
maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
1.7
maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
1.7
maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
1.7
maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
1.7
maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
${jcv}
maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
${jcv}
{code}
with tests:
{code:java}
grep -ir -e maven.compiler.source -e maven.compiler.target
maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
1.7
maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
1.7
maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
1.7
maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
1.7
maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
1.7
maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
1.7
maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
1.7
maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
1.7
maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
1.8
maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
1.8
maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
1.7
maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
1.7
maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
1.7
maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
1.7
maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
${jcv}
maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
${jcv}
maven-archetype-quickstart/src/test/resources/projects/it-java-7/reference/pom.xml:
1.7
maven-archetype-quickstart/src/test/resources/projects/it-java-7/reference/pom.xml:
1.7
maven-archetype-quickstart/src/test/resources/projects/it-java-7-junit-4.12/reference/pom.xml:
1.7
maven-archetype-quickstart/src/test/resources/projects/it-java-7-junit-4.12/reference/pom.xml:
1.7
{code}
was:
namely at least
maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml
[jira] [Updated] (SUREFIRE-2141) Surefire 3.0.0-M8 tests don't pass on Mac M1 (Surefire1295AttributeJvmCrashesToTestsIT)
[
https://issues.apache.org/jira/browse/SUREFIRE-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated SUREFIRE-2141:
Issue Type: Test (was: New Feature)
> Surefire 3.0.0-M8 tests don't pass on Mac M1
> (Surefire1295AttributeJvmCrashesToTestsIT)
> ---
>
> Key: SUREFIRE-2141
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2141
> Project: Maven Surefire
> Issue Type: Test
>Affects Versions: 3.0.0-M8
>Reporter: Enrico Olivelli
>Priority: Critical
>
>
> This test never passes on M1 Macs: Surefire1295AttributeJvmCrashesToTestsIT
> This is the error I can find in
> surefire-its/target/Surefire1295AttributeJvmCrashesToTestsIT_test_segfault_2/target/surefire-reports/junit44.environment.Test1CrashedTest.txt
> The problem is in the crashjvm library
> https://mvnrepository.com/artifact/uk.me.mjt/crashjvm/1.0
> The library seems dead
> {code:java}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.546 s <<<
> FAILURE! - in junit44.environment.Test1CrashedTest
> junit44.environment.Test1CrashedTest.testCrashJvm Time elapsed: 1.53 s <<<
> ERROR!
> java.lang.ExceptionInInitializerError
> at
> junit44.environment.Test1CrashedTest.testCrashJvm(Test1CrashedTest.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
> at
> org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
> at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
> at
> org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
> at
> org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
> at
> org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
> at
> org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
> at
> org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
> at
> org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
> at
> org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
> at
> org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:377)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:284)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:248)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:167)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:456)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:169)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:595)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581)
> Caused by: java.lang.RuntimeException: Unrecognised arch, aarch64
> at uk.me.mjt.FindLibrary.getArch(FindLibrary.java:142)
> at
> uk.me.mjt.FindLibrary.extractNativeLibAsTempFile(FindLibrary.java:108)
> at uk.me.mjt.FindLibrary.loadLibraryFromJarFile(FindLibrary.java:44)
> at
> uk.me.mjt.FindLibrary.loadLibraryExtractingFromJarIfNeeded(FindLibrary.java:25)
> at uk.me.mjt.CrashJvm.(CrashJvm.java:5)
> ... 25 more
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2141) Surefire 3.0.0-M8 tests don't pass on Mac M1 (Surefire1295AttributeJvmCrashesToTestsIT)
[
https://issues.apache.org/jira/browse/SUREFIRE-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated SUREFIRE-2141:
Priority: Minor (was: Critical)
> Surefire 3.0.0-M8 tests don't pass on Mac M1
> (Surefire1295AttributeJvmCrashesToTestsIT)
> ---
>
> Key: SUREFIRE-2141
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2141
> Project: Maven Surefire
> Issue Type: Test
>Affects Versions: 3.0.0-M8
>Reporter: Enrico Olivelli
>Priority: Minor
>
>
> This test never passes on M1 Macs: Surefire1295AttributeJvmCrashesToTestsIT
> This is the error I can find in
> surefire-its/target/Surefire1295AttributeJvmCrashesToTestsIT_test_segfault_2/target/surefire-reports/junit44.environment.Test1CrashedTest.txt
> The problem is in the crashjvm library
> https://mvnrepository.com/artifact/uk.me.mjt/crashjvm/1.0
> The library seems dead
> {code:java}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.546 s <<<
> FAILURE! - in junit44.environment.Test1CrashedTest
> junit44.environment.Test1CrashedTest.testCrashJvm Time elapsed: 1.53 s <<<
> ERROR!
> java.lang.ExceptionInInitializerError
> at
> junit44.environment.Test1CrashedTest.testCrashJvm(Test1CrashedTest.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
> at
> org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
> at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
> at
> org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
> at
> org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
> at
> org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
> at
> org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
> at
> org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
> at
> org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
> at
> org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
> at
> org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:377)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:284)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:248)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:167)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:456)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:169)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:595)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581)
> Caused by: java.lang.RuntimeException: Unrecognised arch, aarch64
> at uk.me.mjt.FindLibrary.getArch(FindLibrary.java:142)
> at
> uk.me.mjt.FindLibrary.extractNativeLibAsTempFile(FindLibrary.java:108)
> at uk.me.mjt.FindLibrary.loadLibraryFromJarFile(FindLibrary.java:44)
> at
> uk.me.mjt.FindLibrary.loadLibraryExtractingFromJarIfNeeded(FindLibrary.java:25)
> at uk.me.mjt.CrashJvm.(CrashJvm.java:5)
> ... 25 more
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SUREFIRE-2103) and causing Java heap space issue.
[ https://issues.apache.org/jira/browse/SUREFIRE-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed SUREFIRE-2103. --- > and causing Java heap space issue. > - > > Key: SUREFIRE-2103 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2103 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M5, 3.0.0-M6 >Reporter: parita jivani >Priority: Critical > Fix For: waiting-for-feedback > > > We have Java test projects, which has different integration and UI tests. We > are upgrading failsafe and surefire version from 2.17 to 3.0.0-M5. After > upgrade few projects were failing with Java heap space. After analysing the > issue, we got to know that failsafe reports creation is causing the memory > issue. Failsafe plugin is writing and elements > with log details. In our case, build logs contains huge data of script > execution logs(around >= 1GB). While creating failsafe report, failsafe > plugin is writing entire logs to *.xml report and causing failure due to java > heap space. > > For issue resolution my suggestion is to get some configuration to > unable/disable option for tags would really help. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SUREFIRE-2103) and causing Java heap space issue.
[ https://issues.apache.org/jira/browse/SUREFIRE-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved SUREFIRE-2103. - Resolution: Fixed sounds like it's fixed, comment and I'll reopen if it can still be reproduced > and causing Java heap space issue. > - > > Key: SUREFIRE-2103 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2103 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M5, 3.0.0-M6 >Reporter: parita jivani >Priority: Critical > Fix For: waiting-for-feedback > > > We have Java test projects, which has different integration and UI tests. We > are upgrading failsafe and surefire version from 2.17 to 3.0.0-M5. After > upgrade few projects were failing with Java heap space. After analysing the > issue, we got to know that failsafe reports creation is causing the memory > issue. Failsafe plugin is writing and elements > with log details. In our case, build logs contains huge data of script > execution logs(around >= 1GB). While creating failsafe report, failsafe > plugin is writing entire logs to *.xml report and causing failure due to java > heap space. > > For issue resolution my suggestion is to get some configuration to > unable/disable option for tags would really help. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIA-540) Update/remove ancient information on Doxia site
[ https://issues.apache.org/jira/browse/DOXIA-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801353#comment-17801353 ] Elliotte Rusty Harold commented on DOXIA-540: - Pending open PRs I think this is all done except possibly "Check Issues for validity" if anyone feels competent to judge that > Update/remove ancient information on Doxia site > --- > > Key: DOXIA-540 > URL: https://issues.apache.org/jira/browse/DOXIA-540 > Project: Maven Doxia > Issue Type: Task > Components: Documentation >Reporter: Michael Osipov >Priority: Major > Labels: up-for-grabs > Time Spent: 10m > Remaining Estimate: 0h > > Tasks to perform: > * Remove [Developer Docs|http://maven.apache.org/doxia/] for ancient versions. > * Remove Doxia IDE intergration is there is none working > * Remove [Upgrading|http://maven.apache.org/doxia/upgrading.html], it is > overhauled. > * Check [FAQ|http://maven.apache.org/doxia/faq.html] for validity. > * Merge [Apt > Enhancements|http://maven.apache.org/doxia/references/doxia-apt.html] into > [main site|http://maven.apache.org/doxia/references/apt-format.html]. > * Check [Issues|http://maven.apache.org/doxia/issues/index.html] for > validity. > * Update [External Resources|http://maven.apache.org/doxia/resources.html]. > * Remove ancient information from [Sink > API|http://maven.apache.org/doxia/doxia/doxia-sink-api/index.html]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIA-540) Update/remove ancient information on Doxia site
[ https://issues.apache.org/jira/browse/DOXIA-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801350#comment-17801350 ] Elliotte Rusty Harold commented on DOXIA-540: - and while we're at it, markmail is dead > Update/remove ancient information on Doxia site > --- > > Key: DOXIA-540 > URL: https://issues.apache.org/jira/browse/DOXIA-540 > Project: Maven Doxia > Issue Type: Task > Components: Documentation >Reporter: Michael Osipov >Priority: Major > Labels: up-for-grabs > Time Spent: 10m > Remaining Estimate: 0h > > Tasks to perform: > * Remove [Developer Docs|http://maven.apache.org/doxia/] for ancient versions. > * Remove Doxia IDE intergration is there is none working > * Remove [Upgrading|http://maven.apache.org/doxia/upgrading.html], it is > overhauled. > * Check [FAQ|http://maven.apache.org/doxia/faq.html] for validity. > * Merge [Apt > Enhancements|http://maven.apache.org/doxia/references/doxia-apt.html] into > [main site|http://maven.apache.org/doxia/references/apt-format.html]. > * Check [Issues|http://maven.apache.org/doxia/issues/index.html] for > validity. > * Update [External Resources|http://maven.apache.org/doxia/resources.html]. > * Remove ancient information from [Sink > API|http://maven.apache.org/doxia/doxia/doxia-sink-api/index.html]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPIR-451) Rename "Dependency Information" to "Maven Coordinates".
[ https://issues.apache.org/jira/browse/MPIR-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800483#comment-17800483 ] Elliotte Rusty Harold commented on MPIR-451: When I read "Maven Dependency Coordinates" I think coordinates of the dependencies of this project. "Maven Coordinates" suggests to me the coordinates of this project, which is what I want. I have occasionally used Maven coordinates to locate an artifact in a context where it is not a dependency. > Rename "Dependency Information" to "Maven Coordinates". > > > Key: MPIR-451 > URL: https://issues.apache.org/jira/browse/MPIR-451 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Major > > From a thread on commons-math where I noticed I was unable to find the Maven > coordinates for the project on the project's website: > The only way to get to that page is scroll about two thirds of the way down a > sidebar and click one of the four links that mention "dependencies" that > seems as likely to bring you to a list of commons-math's own dependencies > rather than how to add this project as a dependency. I'm a Maven comitter > who's spent way more time in the depths of Maven Project website generation > than 99.9% of Java programmers and I still couldn't find this the first time > I looked for it. That's de facto evidence that this information is not easy > to find. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MARCHETYPES-78) Update default Java version in archetype projects to 1.8
[
https://issues.apache.org/jira/browse/MARCHETYPES-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MARCHETYPES-78:
-
Issue Type: Improvement (was: Bug)
> Update default Java version in archetype projects to 1.8
>
>
> Key: MARCHETYPES-78
> URL: https://issues.apache.org/jira/browse/MARCHETYPES-78
> Project: Maven Archetype Bundles
> Issue Type: Improvement
>Reporter: jiri vanek
>Priority: Major
>
> namely at least
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml
> still uses 1.7 as default version.
> I'm happy to fix them all (see
> https://github.com/apache/maven-archetypes/pull/18 and
> https://issues.apache.org/jira/projects/MARCHETYPES/issues/MARCHETYPES-76),
> but first I need some ack from somebody with commit permissions to
> MARCHETYPES/https://github.com/apache/maven-archetypes
> {code:java}
> grep -ir -e maven.compiler.source -e maven.compiler.target| grep -v test
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.8
> maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.8
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
> ${jcv}
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
> ${jcv}
> {code}
> with tests:
> {code:java}
> grep -ir -e maven.compiler.source -e maven.compiler.target
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.8
> maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.8
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
> ${jcv}
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
> ${jcv}
>
[jira] [Updated] (MARCHETYPES-78) Update default Java version in archetype projects to 1.8
[
https://issues.apache.org/jira/browse/MARCHETYPES-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MARCHETYPES-78:
-
Summary: Update default Java version in archetype projects to 1.8 (was:
archetypes generates EOLed maven.compiler versions)
> Update default Java version in archetype projects to 1.8
>
>
> Key: MARCHETYPES-78
> URL: https://issues.apache.org/jira/browse/MARCHETYPES-78
> Project: Maven Archetype Bundles
> Issue Type: Bug
>Reporter: jiri vanek
>Priority: Major
>
> namely at least
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml
> still uses 1.7 as default version.
> I'm happy to fix them all (see
> https://github.com/apache/maven-archetypes/pull/18 and
> https://issues.apache.org/jira/projects/MARCHETYPES/issues/MARCHETYPES-76),
> but first I need some ack from somebody with commit permissions to
> MARCHETYPES/https://github.com/apache/maven-archetypes
> {code:java}
> grep -ir -e maven.compiler.source -e maven.compiler.target| grep -v test
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.8
> maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.8
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
> ${jcv}
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
> ${jcv}
> {code}
> with tests:
> {code:java}
> grep -ir -e maven.compiler.source -e maven.compiler.target
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-plugin/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/src/main/resources/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-archetype/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-profiles/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.8
> maven-archetype-webapp/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.8
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-simple/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-portlet/src/main/resources-filtered/archetype-resources/pom.xml:
> 1.7
> maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
> ${jcv}
>
[jira] [Updated] (MJARSIGNER-69) Verify failFast
[ https://issues.apache.org/jira/browse/MJARSIGNER-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MJARSIGNER-69: Issue Type: New Feature (was: Improvement) > Verify failFast > --- > > Key: MJARSIGNER-69 > URL: https://issues.apache.org/jira/browse/MJARSIGNER-69 > Project: Maven Jar Signer Plugin > Issue Type: New Feature >Reporter: Delany >Priority: Major > > When I verify a directory of jars and errorWhenNotSigned=true I'd like the > option of failing after verifying all jars. > Same as > [https://maven.apache.org/enforcer/maven-enforcer-plugin/enforce-mojo.html#failFast] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MJARSIGNER-48) Make Jar Signer plugin :sign goal threadsafe
[
https://issues.apache.org/jira/browse/MJARSIGNER-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MJARSIGNER-48.
-
Resolution: Fixed
> Make Jar Signer plugin :sign goal threadsafe
>
>
> Key: MJARSIGNER-48
> URL: https://issues.apache.org/jira/browse/MJARSIGNER-48
> Project: Maven Jar Signer Plugin
> Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Kaloyan Raev
>Priority: Major
> Labels: build
> Fix For: 3.1.0
>
>
> Right now when you execute mvn *-T 4* maven-jarsigner-plugin:1.4:sign you get
> a warning:
> {code}
> [WARNING] *
> [WARNING] * Your build is requesting parallel execution, but project *
> [WARNING] * contains the following plugin(s) that are not marked as *
> [WARNING] * @threadSafe to support parallel building. *
> [WARNING] * While this /may/ work fine, please look for plugin updates*
> [WARNING] * and/or request plugins be made thread-safe. *
> [WARNING] * If reporting an issue, report it against the plugin in*
> [WARNING] * question, not against maven-core *
> [WARNING] *
> [WARNING] The following plugins are not marked @threadSafe in uDecideSM:
> [WARNING] org.apache.maven.plugins:maven-jarsigner-plugin:1.4
> [WARNING] *
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MJARSIGNER-48) Make Jar Signer plugin :sign goal threadsafe
[
https://issues.apache.org/jira/browse/MJARSIGNER-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MJARSIGNER-48.
---
> Make Jar Signer plugin :sign goal threadsafe
>
>
> Key: MJARSIGNER-48
> URL: https://issues.apache.org/jira/browse/MJARSIGNER-48
> Project: Maven Jar Signer Plugin
> Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Kaloyan Raev
>Priority: Major
> Labels: build
> Fix For: 3.1.0
>
>
> Right now when you execute mvn *-T 4* maven-jarsigner-plugin:1.4:sign you get
> a warning:
> {code}
> [WARNING] *
> [WARNING] * Your build is requesting parallel execution, but project *
> [WARNING] * contains the following plugin(s) that are not marked as *
> [WARNING] * @threadSafe to support parallel building. *
> [WARNING] * While this /may/ work fine, please look for plugin updates*
> [WARNING] * and/or request plugins be made thread-safe. *
> [WARNING] * If reporting an issue, report it against the plugin in*
> [WARNING] * question, not against maven-core *
> [WARNING] *
> [WARNING] The following plugins are not marked @threadSafe in uDecideSM:
> [WARNING] org.apache.maven.plugins:maven-jarsigner-plugin:1.4
> [WARNING] *
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (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:all-tabpanel
]
Elliotte Rusty Harold updated MSHARED-1285:
---
Fix Version/s: maven-filtering-3.3.2
> 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
> Components: maven-filtering
>Reporter: Christoph Läubrich
>Priority: Major
> Fix For: maven-filtering-3.3.2
>
>
> 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)
[jira] [Closed] (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:all-tabpanel
]
Elliotte Rusty Harold closed MSHARED-1285.
--
> 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
> Components: maven-filtering
>Reporter: Christoph Läubrich
>Priority: Major
> Fix For: maven-filtering-3.3.2
>
>
> 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)
[jira] [Resolved] (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:all-tabpanel
]
Elliotte Rusty Harold resolved MSHARED-1285.
Resolution: Fixed
> 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
> Components: maven-filtering
>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)
[jira] [Resolved] (MJARSIGNER-72) Parallel signing for increased speed
[
https://issues.apache.org/jira/browse/MJARSIGNER-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MJARSIGNER-72.
-
Resolution: Fixed
> Parallel signing for increased speed
>
>
> Key: MJARSIGNER-72
> URL: https://issues.apache.org/jira/browse/MJARSIGNER-72
> Project: Maven Jar Signer Plugin
> Issue Type: New Feature
>Affects Versions: 3.0.0
>Reporter: Lennart Schedin
>Priority: Minor
> Labels: performance
>
> *Background:*
> As of June 1 2023, a new industry standard mandates the storage of private
> keys used for code signing on external hardware devices. Refer to
> [https://knowledge.digicert.com/general-information/new-private-key-storage-requirement-for-standard-code-signing-certificates-november-2022]
> for details. Various devices, from the Thales SafeNet USB eToken (about
> $30), Yubico YubiHSM 2 FIPS (about €1000) up to Thales Luna S700 Series
> (about €3) can store these keys. Cloud-based HSM solutions (like DigiCert
> KeyLocker ($90/year)) also exist.
>
> This ticket primarily targets HSM as a service but could benefit network
> attached HSM solutions as well.
>
> *Problem:*
> Using the {{jarsigner:sign}} goal it is possible to specify
> {{{}archiveDirectory{}}}, that points to a directory with many jar files.
> This is useful for signing every dependency the project has.
>
> Using the DigiCert Keylocker HSM as a service I measured that it took 240
> seconds to sign 128 jar files. I was in Sweden and the DigiCert Keylocker
> service is in USA. The response time of server is about 500 to 700 ms
> (without any login and without any signing).
>
> I created a quick parallel hack (using the Linux command parallel) that used
> 8 threads and it took only 31 seconds. That is: for this specific HSM service
> it scales linearly with the number of threads used.
>
> *To implement:*
> I propose to implement a parallelization for maven-jarsigner-plugin that can
> be used when signing many jar files at once.
>
> The configuration for this could be a new parameter named {{threadCount}}
> (with user property {{{}jarsigner.threadCount{}}}) with default to 1 (no
> parallelization).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MJARSIGNER-72) Parallel signing for increased speed
[
https://issues.apache.org/jira/browse/MJARSIGNER-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MJARSIGNER-72.
---
> Parallel signing for increased speed
>
>
> Key: MJARSIGNER-72
> URL: https://issues.apache.org/jira/browse/MJARSIGNER-72
> Project: Maven Jar Signer Plugin
> Issue Type: New Feature
>Affects Versions: 3.0.0
>Reporter: Lennart Schedin
>Priority: Minor
> Labels: performance
>
> *Background:*
> As of June 1 2023, a new industry standard mandates the storage of private
> keys used for code signing on external hardware devices. Refer to
> [https://knowledge.digicert.com/general-information/new-private-key-storage-requirement-for-standard-code-signing-certificates-november-2022]
> for details. Various devices, from the Thales SafeNet USB eToken (about
> $30), Yubico YubiHSM 2 FIPS (about €1000) up to Thales Luna S700 Series
> (about €3) can store these keys. Cloud-based HSM solutions (like DigiCert
> KeyLocker ($90/year)) also exist.
>
> This ticket primarily targets HSM as a service but could benefit network
> attached HSM solutions as well.
>
> *Problem:*
> Using the {{jarsigner:sign}} goal it is possible to specify
> {{{}archiveDirectory{}}}, that points to a directory with many jar files.
> This is useful for signing every dependency the project has.
>
> Using the DigiCert Keylocker HSM as a service I measured that it took 240
> seconds to sign 128 jar files. I was in Sweden and the DigiCert Keylocker
> service is in USA. The response time of server is about 500 to 700 ms
> (without any login and without any signing).
>
> I created a quick parallel hack (using the Linux command parallel) that used
> 8 threads and it took only 31 seconds. That is: for this specific HSM service
> it scales linearly with the number of threads used.
>
> *To implement:*
> I propose to implement a parallelization for maven-jarsigner-plugin that can
> be used when signing many jar files at once.
>
> The configuration for this could be a new parameter named {{threadCount}}
> (with user property {{{}jarsigner.threadCount{}}}) with default to 1 (no
> parallelization).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJARSIGNER-72) Parallel signing for increased speed
[
https://issues.apache.org/jira/browse/MJARSIGNER-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MJARSIGNER-72:
Fix Version/s: 3.1.0
> Parallel signing for increased speed
>
>
> Key: MJARSIGNER-72
> URL: https://issues.apache.org/jira/browse/MJARSIGNER-72
> Project: Maven Jar Signer Plugin
> Issue Type: New Feature
>Affects Versions: 3.0.0
>Reporter: Lennart Schedin
>Priority: Minor
> Labels: performance
> Fix For: 3.1.0
>
>
> *Background:*
> As of June 1 2023, a new industry standard mandates the storage of private
> keys used for code signing on external hardware devices. Refer to
> [https://knowledge.digicert.com/general-information/new-private-key-storage-requirement-for-standard-code-signing-certificates-november-2022]
> for details. Various devices, from the Thales SafeNet USB eToken (about
> $30), Yubico YubiHSM 2 FIPS (about €1000) up to Thales Luna S700 Series
> (about €3) can store these keys. Cloud-based HSM solutions (like DigiCert
> KeyLocker ($90/year)) also exist.
>
> This ticket primarily targets HSM as a service but could benefit network
> attached HSM solutions as well.
>
> *Problem:*
> Using the {{jarsigner:sign}} goal it is possible to specify
> {{{}archiveDirectory{}}}, that points to a directory with many jar files.
> This is useful for signing every dependency the project has.
>
> Using the DigiCert Keylocker HSM as a service I measured that it took 240
> seconds to sign 128 jar files. I was in Sweden and the DigiCert Keylocker
> service is in USA. The response time of server is about 500 to 700 ms
> (without any login and without any signing).
>
> I created a quick parallel hack (using the Linux command parallel) that used
> 8 threads and it took only 31 seconds. That is: for this specific HSM service
> it scales linearly with the number of threads used.
>
> *To implement:*
> I propose to implement a parallelization for maven-jarsigner-plugin that can
> be used when signing many jar files at once.
>
> The configuration for this could be a new parameter named {{threadCount}}
> (with user property {{{}jarsigner.threadCount{}}}) with default to 1 (no
> parallelization).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-194) Strange effects with springs @Configurable (AspectJ) and new compiler plugin version 3.0
[ https://issues.apache.org/jira/browse/MCOMPILER-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17797311#comment-17797311 ] Elliotte Rusty Harold commented on MCOMPILER-194: - Any chance this and MCOMPILER-424 are related? > Strange effects with springs @Configurable (AspectJ) and new compiler plugin > version 3.0 > > > Key: MCOMPILER-194 > URL: https://issues.apache.org/jira/browse/MCOMPILER-194 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0 > Environment: jdk 1.6.0_38, jdk 1.6.0_37 >Reporter: Andreas Höhmann >Priority: Critical > Attachments: MCOMPILER-194.zip, SO_AJ_MavenSoftExceptions.zip > > > I have no details I can only report the "effects" .. > I have a maven project with compiler-plugin 2.5.1, > aspectj-plugin 1.4, java 1.6 and a lot of @Configurable > annotations in my code. Aspectj will decorate these classes > so @Autowired dependencies injected during runtime. > All is working fine. > Now I switch to compiler-plugin 3.0 ... nothing else changed! > Then "sometimes" I got NPE's because the injected service etc. are > not available. I guess aspectj was not successfull. I have no > errors etc. anywhere during build. > Strang :) -- 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=17795717#comment-17795717
]
Elliotte Rusty Harold commented on MJAVADOC-775:
Bug triage and maintenance is important. We have plenty of evidence now that
taglet path simply doesn't work. Thanks. Now someone needs to produce a test
and a fix. If it turns out this problem still isn't fixed after that, we can
reopen, but for now let's not keep two issues open for what really smells like
two manifestations of the same issue.
> 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)
[jira] [Updated] (MJARSIGNER-75) maven-shared-utils to 3.4.2
[ https://issues.apache.org/jira/browse/MJARSIGNER-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MJARSIGNER-75: Fix Version/s: 3.1.0 > maven-shared-utils to 3.4.2 > --- > > Key: MJARSIGNER-75 > URL: https://issues.apache.org/jira/browse/MJARSIGNER-75 > Project: Maven Jar Signer Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Minor > Fix For: 3.1.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MJARSIGNER-75) maven-shared-utils to 3.4.2
Elliotte Rusty Harold created MJARSIGNER-75: --- Summary: maven-shared-utils to 3.4.2 Key: MJARSIGNER-75 URL: https://issues.apache.org/jira/browse/MJARSIGNER-75 Project: Maven Jar Signer Plugin Issue Type: Dependency upgrade Reporter: Elliotte Rusty Harold -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MJARSIGNER-59) increase reliability when contacting timestamp service over unreliable network
[
https://issues.apache.org/jira/browse/MJARSIGNER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MJARSIGNER-59.
-
Resolution: Duplicate
> increase reliability when contacting timestamp service over unreliable network
> --
>
> Key: MJARSIGNER-59
> URL: https://issues.apache.org/jira/browse/MJARSIGNER-59
> Project: Maven Jar Signer Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Andrew Peter Marlow
>Priority: Major
> Attachments:
> 0001-Added-retries-upon-failure-and-support-multiple-TSA-.patch
>
>
> {color:#00}The signing plugin fails in the presence of an unreliable
> network. Could retries be added please? I am thinking of something like up to
> 3 retries,{color} sleeping for one second between.{color:#00}
>
>
>
> I have just started to use this plugin and this is a major issue. It makes
> my overnight builds fail more often than not. Prior to me making this change
> the project produced unsigned jars during the java build and later on via a
> python script added the signing. Once the {color}
> {color:#00}unreliable network issue was identified the python script was
> changed, adding retries (the network issue will most likely never be fixed).
> These retries in the python script fixed the issue. Now I am using the maven
> plugin the issue is back.{color}
>
> Some people might think that if this is happening in a wired corporate
> network then the network issue ought to be identified and resolved by the
> corporation. Well, maybe. But this issue could easily strike on networks that
> are inherently less reliable such as wifi and mobile. So I really think that
> the retries should be there to cater for that.
>
> {color:#00} {color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MJARSIGNER-59) increase reliability when contacting timestamp service over unreliable network
[
https://issues.apache.org/jira/browse/MJARSIGNER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MJARSIGNER-59.
---
fixed on duplicate issue
> increase reliability when contacting timestamp service over unreliable network
> --
>
> Key: MJARSIGNER-59
> URL: https://issues.apache.org/jira/browse/MJARSIGNER-59
> Project: Maven Jar Signer Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Andrew Peter Marlow
>Priority: Major
> Attachments:
> 0001-Added-retries-upon-failure-and-support-multiple-TSA-.patch
>
>
> {color:#00}The signing plugin fails in the presence of an unreliable
> network. Could retries be added please? I am thinking of something like up to
> 3 retries,{color} sleeping for one second between.{color:#00}
>
>
>
> I have just started to use this plugin and this is a major issue. It makes
> my overnight builds fail more often than not. Prior to me making this change
> the project produced unsigned jars during the java build and later on via a
> python script added the signing. Once the {color}
> {color:#00}unreliable network issue was identified the python script was
> changed, adding retries (the network issue will most likely never be fixed).
> These retries in the python script fixed the issue. Now I am using the maven
> plugin the issue is back.{color}
>
> Some people might think that if this is happening in a wired corporate
> network then the network issue ought to be identified and resolved by the
> corporation. Well, maybe. But this issue could easily strike on networks that
> are inherently less reliable such as wifi and mobile. So I really think that
> the retries should be there to cater for that.
>
> {color:#00} {color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MJAVADOC-775) Option 'tagletpath' not working, completely ignored
[
https://issues.apache.org/jira/browse/MJAVADOC-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MJAVADOC-775.
Resolution: Duplicate
Duping against 783 since that includes a little more info for a potential fix.
> 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)
[jira] [Closed] (MJAVADOC-775) Option 'tagletpath' not working, completely ignored
[
https://issues.apache.org/jira/browse/MJAVADOC-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MJAVADOC-775.
--
> 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)
[jira] (MJAVADOC-775) Option 'tagletpath' not working, completely ignored
[ https://issues.apache.org/jira/browse/MJAVADOC-775 ]
Elliotte Rusty Harold deleted comment on MJAVADOC-775:
was (Author: elharo):
Call me a luddite, but developers work in plain text for good reason, and that
should include email. We'd all be better off if HTML email had never been
invented.
> 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)
[jira] [Commented] (MJAVADOC-783) Invalid path when using TagletArtifact and TagletPath
[
https://issues.apache.org/jira/browse/MJAVADOC-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795347#comment-17795347
]
Elliotte Rusty Harold commented on MJAVADOC-783:
Call me a luddite, but developers work in plain text for good reason, and that
should include email. We'd all be better off if HTML email had never been
invented.
> Invalid path when using TagletArtifact and TagletPath
> -
>
> Key: MJAVADOC-783
> URL: https://issues.apache.org/jira/browse/MJAVADOC-783
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.6.3
>Reporter: Rob Gordon
>Priority: Major
>
> I’m trying to use the Javadoc plugin with both a tagletartifact and a
> tagletpath but I get an InvliadPathException from the Javadoc goal.
> I can see from the generated options file that there is no separator between
> the end of the artifact path and the taglet path.
> I think the problem is that getTagletPath method of AbstractJavadocMojo
> should check for an existing path before adding the tagletpath. Something
> like:
> {code:java}
> if (tagletpath != null && !tagletpath.isEmpty()) {
> if (path.length() > 0)
> { path.append(File.pathSeparator); }
> path.append(JavadocUtil.unifyPathSeparator(tagletpath));
> }
> {code}
> I looked at creating a pull request but I can’t work out how to create a
> suitable test. I found a taglet-test-plugin-config.xml, but not where it’s
> used.
> Could someone familiar with this codebase possibly take a look at this
> problem please?
> My configuration can be seen here:
> [https://github.com/robjg/oj-parent/blob/d3e2328ca285516f1a4f6ee2bce94b44ba89b748/pom.xml#L304]
> I attempted to report this problem via 'us...@maven.apache.org' however my
> mail did not make it.
--
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=17795346#comment-17795346
]
Elliotte Rusty Harold commented on MJAVADOC-775:
Call me a luddite, but developers work in plain text for good reason, and that
should include email. We'd all be better off if HTML email had never been
invented.
> 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)
[jira] [Resolved] (MSHARED-1290) PropertyUtils cycle detection results in false positives
[
https://issues.apache.org/jira/browse/MSHARED-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MSHARED-1290.
Resolution: Fixed
> PropertyUtils cycle detection results in false positives
>
>
> Key: MSHARED-1290
> URL: https://issues.apache.org/jira/browse/MSHARED-1290
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-3.2.0, maven-filtering-3.3.0,
> maven-filtering-3.3.1
>Reporter: Wouter Born
>Priority: Major
>
> I upgraded the maven-assembly-plugin in one of my projects from 2.6 to 3.6.0
> and found that {{PropertyUtils}} was logging many false positives about
> cycles between properties.
> The cycle detection (introduced for MSHARED-417) reports false positives when
> a variable occurs multiple times in a property, example:
> {code:java}
> depends=p1 >= ${version}, p2 >= ${version}, p3 >= ${version}
> version=1.2.3 {code}
> While writing a unit test to fix this, I also found that there are also cycle
> false positives whenever one of the property values is the same as a property
> name, example:
> {code:java}
> test1=${test2}
> test2=${test3}
> test3=test2{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MSHARED-1290) PropertyUtils cycle detection results in false positives
[
https://issues.apache.org/jira/browse/MSHARED-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MSHARED-1290.
--
> PropertyUtils cycle detection results in false positives
>
>
> Key: MSHARED-1290
> URL: https://issues.apache.org/jira/browse/MSHARED-1290
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-3.2.0, maven-filtering-3.3.0,
> maven-filtering-3.3.1
>Reporter: Wouter Born
>Priority: Major
>
> I upgraded the maven-assembly-plugin in one of my projects from 2.6 to 3.6.0
> and found that {{PropertyUtils}} was logging many false positives about
> cycles between properties.
> The cycle detection (introduced for MSHARED-417) reports false positives when
> a variable occurs multiple times in a property, example:
> {code:java}
> depends=p1 >= ${version}, p2 >= ${version}, p3 >= ${version}
> version=1.2.3 {code}
> While writing a unit test to fix this, I also found that there are also cycle
> false positives whenever one of the property values is the same as a property
> name, example:
> {code:java}
> test1=${test2}
> test2=${test3}
> test3=test2{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJARSIGNER-65) Update parent pom to 39
[ https://issues.apache.org/jira/browse/MJARSIGNER-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794691#comment-17794691 ] Elliotte Rusty Harold commented on MJARSIGNER-65: - readonly is not about documentation. See https://maven.apache.org/plugin-tools/maven-plugin-annotations/apidocs/org/apache/maven/plugins/annotations/Parameter.html#readonly() > Update parent pom to 39 > --- > > Key: MJARSIGNER-65 > URL: https://issues.apache.org/jira/browse/MJARSIGNER-65 > Project: Maven Jar Signer Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > Fix For: 3.1.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MJARSIGNER-68) CI is broken
[ https://issues.apache.org/jira/browse/MJARSIGNER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MJARSIGNER-68. - Resolution: Fixed > CI is broken > > > Key: MJARSIGNER-68 > URL: https://issues.apache.org/jira/browse/MJARSIGNER-68 > Project: Maven Jar Signer Plugin > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Blocker > > src/it/verify-fail fails on the CI though it seems to pass locally. As best > I've been able to figure out the failing output is not saved in the CI > environment anywhere for inspection and debugging. Perhaps someone with more > access to the backend can retrieve the log files from this test and figure > out what's going wrong. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MJARSIGNER-68) CI is broken
[ https://issues.apache.org/jira/browse/MJARSIGNER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MJARSIGNER-68. --- > CI is broken > > > Key: MJARSIGNER-68 > URL: https://issues.apache.org/jira/browse/MJARSIGNER-68 > Project: Maven Jar Signer Plugin > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Blocker > > src/it/verify-fail fails on the CI though it seems to pass locally. As best > I've been able to figure out the failing output is not saved in the CI > environment anywhere for inspection and debugging. Perhaps someone with more > access to the backend can retrieve the log files from this test and figure > out what's going wrong. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MJARSIGNER-73) Upgrade Apache Derby to 10.17.1.0
[ https://issues.apache.org/jira/browse/MJARSIGNER-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MJARSIGNER-73. - Resolution: Invalid I don't think that's used in this plugin. If it is, please point to exactly where. Thanks. > Upgrade Apache Derby to 10.17.1.0 > - > > Key: MJARSIGNER-73 > URL: https://issues.apache.org/jira/browse/MJARSIGNER-73 > Project: Maven Jar Signer Plugin > Issue Type: Dependency upgrade >Reporter: Pradeep Agrawal >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MJARSIGNER-73) Upgrade Apache Derby to 10.17.1.0
[ https://issues.apache.org/jira/browse/MJARSIGNER-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MJARSIGNER-73. --- > Upgrade Apache Derby to 10.17.1.0 > - > > Key: MJARSIGNER-73 > URL: https://issues.apache.org/jira/browse/MJARSIGNER-73 > Project: Maven Jar Signer Plugin > Issue Type: Dependency upgrade >Reporter: Pradeep Agrawal >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
