[jira] [Commented] (ARCHETYPE-613) Different gererating result with user defined parameters
[
https://issues.apache.org/jira/browse/ARCHETYPE-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223420#comment-17223420
]
Liu Shilong commented on ARCHETYPE-613:
---
I solve the problem, In fact ,it occurs not because of the maven version but
the jdk version, it needs jdk14 rather than jdk8
> Different gererating result with user defined parameters
>
>
> Key: ARCHETYPE-613
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-613
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.2.0
> Environment: maven 3.6.3(right), maven3.6.1(wrong), IDEA2020.1(wrong)
>Reporter: Liu Shilong
>Priority: Major
>
> Happend in two different maven version 3.6.1 and 3.6.3,
> I defined my archetype-metadata.xml as following:
> {code:java}
> //代码占位符
>
>
>
>
> 1.0.0-SNAPSHOT
>
>
>
> //user defined parameter
> // user defined parameter
>
> ${package.getClass().forName("org.apache.velocity.util.StringUtils").nullTrim("")}
> //default is null;
>
> {code}
> and following are some others parameter tansformed by abover parameters
> {code:java}
> //代码占位符
>
> ${1.toUpperCase()}
>
>
>
> ${1.toLowerCase().substring(0,1).toUpperCase()}${1.toLowerCase().substring(1)}
>
>
>
> ${package.getClass().forName("org.apache.velocity.util.StringUtils").nullTrim("$2").toUpperCase()}
>
>
>
> ${package.getClass().forName("org.apache.velocity.util.StringUtils").firstLetterCaps("${2}_").replaceAll("_","")}
>
>
> ${4}${6}
>
>
> {code}
> when I use command "mvn archetype : generate " in maven 3.6.3, i got the
> right generated project ,and all the parameters are as my expected including
> parameters which need to be evaluated. But in maven 3.6.1(In fact , I'm not
> sure whether the version cause the difference"), it's different, some
> parameters are not evaluatedd correctly like following:
> {code:java}
> //代码占位符
> ...
> Parameter: 3, Value: ${1.toUpperCase()}
> [INFO] Parameter: x6, Value: _${}_
> [INFO] Parameter: x, Value: __
> ...{code}
> as you see, some parameters are evaluated, but some are not. In fact , I
> found this happened also in 'mvn command' and 'maven archetype generating
> process in IDEA'. And I found following source code in maven-archetype plugin:
> {code:java}
> //代码占位符
> private Context prepareVelocityContext(ArchetypeGenerationRequest request) {
> Context context = new VelocityContext();
> context.put(Constants.GROUP_ID, request.getGroupId());
> context.put(Constants.ARTIFACT_ID, request.getArtifactId());
> context.put(Constants.VERSION, request.getVersion());
> context.put(Constants.PACKAGE, request.getPackage());
> final String packageInPathFormat =
> getPackageInPathFormat(request.getPackage());
> context.put(Constants.PACKAGE_IN_PATH_FORMAT, packageInPathFormat);
> if (getLogger().isInfoEnabled()) {
>
> getLogger().info("");
> getLogger().info(
> "Using following parameters for creating project from
> Archetype: " + request
> .getArchetypeArtifactId()
> + ":" + request.getArchetypeVersion());
>
> getLogger().info("");
> getLogger().info("Parameter: " + Constants.GROUP_ID + ", Value: " +
> request.getGroupId());
> getLogger().info("Parameter: " + Constants.ARTIFACT_ID + ", Value: "
> + request.getArtifactId());
> getLogger().info("Parameter: " + Constants.VERSION + ", Value: " +
> request.getVersion());
> getLogger().info("Parameter: " + Constants.PACKAGE + ", Value: " +
> request.getPackage());
> getLogger().info("Parameter: " + Constants.PACKAGE_IN_PATH_FORMAT +
> ", Value: " + packageInPathFormat);
> }
> for (Iterator iterator = request.getProperties().keySet().iterator();
> iterator.hasNext(); ) { // here,the result of request.getProperties() is a
> hashtable
> String key = (String) iterator.next();
> String value = request.getProperties().getProperty(key);
> if (maybeVelocityExpression(value)) {
> value = evaluateExpression(context, key, value);
> }
> context.put(key, value);
> if (getLogger().isInfoEnabled()) {
> getLogger().info("Parameter: " + key + ", Value: " + value);
> }
> }
> return context;
> }
> {code}
> As above comment, the result of request.getProperties() is a HashTable, the
> fact is that the parameter order is not what we input but hash value, so it
> cause that some
[jira] [Updated] (ARCHETYPE-613) Different gererating result with user defined parameters
[
https://issues.apache.org/jira/browse/ARCHETYPE-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Liu Shilong updated ARCHETYPE-613:
--
Description:
Happend in two different maven version 3.6.1 and 3.6.3,
I defined my archetype-metadata.xml as following:
{code:java}
//代码占位符
1.0.0-SNAPSHOT
//user defined parameter
// user defined parameter
${package.getClass().forName("org.apache.velocity.util.StringUtils").nullTrim("")}
//default is null;
{code}
and following are some others parameter tansformed by abover parameters
{code:java}
//代码占位符
${1.toUpperCase()}
${1.toLowerCase().substring(0,1).toUpperCase()}${1.toLowerCase().substring(1)}
${package.getClass().forName("org.apache.velocity.util.StringUtils").nullTrim("$2").toUpperCase()}
${package.getClass().forName("org.apache.velocity.util.StringUtils").firstLetterCaps("${2}_").replaceAll("_","")}
${4}${6}
{code}
when I use command "mvn archetype : generate " in maven 3.6.3, i got the
right generated project ,and all the parameters are as my expected including
parameters which need to be evaluated. But in maven 3.6.1(In fact , I'm not
sure whether the version cause the difference"), it's different, some
parameters are not evaluatedd correctly like following:
{code:java}
//代码占位符
...
Parameter: 3, Value: ${1.toUpperCase()}
[INFO] Parameter: x6, Value: _${}_
[INFO] Parameter: x, Value: __
...{code}
as you see, some parameters are evaluated, but some are not. In fact , I found
this happened also in 'mvn command' and 'maven archetype generating process in
IDEA'. And I found following source code in maven-archetype plugin:
{code:java}
//代码占位符
private Context prepareVelocityContext(ArchetypeGenerationRequest request) {
Context context = new VelocityContext();
context.put(Constants.GROUP_ID, request.getGroupId());
context.put(Constants.ARTIFACT_ID, request.getArtifactId());
context.put(Constants.VERSION, request.getVersion());
context.put(Constants.PACKAGE, request.getPackage());
final String packageInPathFormat =
getPackageInPathFormat(request.getPackage());
context.put(Constants.PACKAGE_IN_PATH_FORMAT, packageInPathFormat);
if (getLogger().isInfoEnabled()) {
getLogger().info("");
getLogger().info(
"Using following parameters for creating project from
Archetype: " + request
.getArchetypeArtifactId()
+ ":" + request.getArchetypeVersion());
getLogger().info("");
getLogger().info("Parameter: " + Constants.GROUP_ID + ", Value: " +
request.getGroupId());
getLogger().info("Parameter: " + Constants.ARTIFACT_ID + ", Value: " +
request.getArtifactId());
getLogger().info("Parameter: " + Constants.VERSION + ", Value: " +
request.getVersion());
getLogger().info("Parameter: " + Constants.PACKAGE + ", Value: " +
request.getPackage());
getLogger().info("Parameter: " + Constants.PACKAGE_IN_PATH_FORMAT + ",
Value: " + packageInPathFormat);
}
for (Iterator iterator = request.getProperties().keySet().iterator();
iterator.hasNext(); ) { // here,the result of request.getProperties() is a
hashtable
String key = (String) iterator.next();
String value = request.getProperties().getProperty(key);
if (maybeVelocityExpression(value)) {
value = evaluateExpression(context, key, value);
}
context.put(key, value);
if (getLogger().isInfoEnabled()) {
getLogger().info("Parameter: " + key + ", Value: " + value);
}
}
return context;
}
{code}
As above comment, the result of request.getProperties() is a HashTable, the
fact is that the parameter order is not what we input but hash value, so it
cause that some parameters are not evaluated because some parameters are relied
on others.
But the question is "how difference happens?" . In fact ,once the parameter are
determined, the result will be determined, why it will be different in some
case?
{color:#808080}IDEA use the java command to start the process of generating
like: {color}
{code:java}
//代码占位符
java -Dxxx=xxx org.apache.maven.plugins:maven-archetype-plugin:RELEASE:generate
{code}
{color:#808080}also, some parameters are not evaluated correctly.{color}
was:
Happend in two different maven version 3.6.1 and 3.6.3,
I defined my archetype-metadata.xml as following:
{code:java}
//代码占位符
1.0.0-SNAPSHOT
//user defined parameter
// user defined parameter
${package.getClass().forName("org.apache.velocity.util.StringUtils").nullTrim("")}
[jira] [Created] (ARCHETYPE-613) Different gererating result with user defined parameters
Liu Shilong created ARCHETYPE-613:
-
Summary: Different gererating result with user defined parameters
Key: ARCHETYPE-613
URL: https://issues.apache.org/jira/browse/ARCHETYPE-613
Project: Maven Archetype
Issue Type: Bug
Components: Plugin
Affects Versions: 3.2.0
Reporter: Liu Shilong
Happend in two different maven version 3.6.1 and 3.6.3,
I defined my archetype-metadata.xml as following:
{code:java}
//代码占位符
1.0.0-SNAPSHOT
//user defined parameter
// user defined parameter
${package.getClass().forName("org.apache.velocity.util.StringUtils").nullTrim("")}
//default is null;
{code}
and following are some others parameter tansformed by abover parameters
{code:java}
//代码占位符
${1.toUpperCase()}
${1.toLowerCase().substring(0,1).toUpperCase()}${1.toLowerCase().substring(1)}
${package.getClass().forName("org.apache.velocity.util.StringUtils").nullTrim("$2").toUpperCase()}
${package.getClass().forName("org.apache.velocity.util.StringUtils").firstLetterCaps("${2}_").replaceAll("_","")}
${4}${6}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MWRAPPER-9) Ability to automatically download JRE
[ https://issues.apache.org/jira/browse/MWRAPPER-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223271#comment-17223271 ] Manfred Moser commented on MWRAPPER-9: -- I think thats beyond the scope of the wrapper. there are other tools that can do that. If anything we should make sure that the wrapper fails gracefully with a good error message if not Java is found. From what I recall thats already the case but it might be worth testing again. > Ability to automatically download JRE > - > > Key: MWRAPPER-9 > URL: https://issues.apache.org/jira/browse/MWRAPPER-9 > Project: Maven Wrapper > Issue Type: Bug >Reporter: Yannick Menager >Priority: Normal > > It would be helpful if the wrapper had the ability to download a JRE like > adoptjdk for example > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MWRAPPER-10) Checksums for maven-dists
[ https://issues.apache.org/jira/browse/MWRAPPER-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223255#comment-17223255 ] Michael Osipov commented on MWRAPPER-10: Checksums are *not* intended to verify authenticity. > Checksums for maven-dists > - > > Key: MWRAPPER-10 > URL: https://issues.apache.org/jira/browse/MWRAPPER-10 > Project: Maven Wrapper > Issue Type: Bug >Reporter: Yannick Menager >Priority: Critical > > Automatically downloading and running software is highly dangerous from a > security point of view. > Wrapper should include the ability to include a checksum and verify the > downloaded zip file -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MWRAPPER-9) Ability to automatically download JRE
[ https://issues.apache.org/jira/browse/MWRAPPER-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223257#comment-17223257 ] Michael Osipov commented on MWRAPPER-9: --- + cattle of tea infusion? > Ability to automatically download JRE > - > > Key: MWRAPPER-9 > URL: https://issues.apache.org/jira/browse/MWRAPPER-9 > Project: Maven Wrapper > Issue Type: Bug >Reporter: Yannick Menager >Priority: Normal > > It would be helpful if the wrapper had the ability to download a JRE like > adoptjdk for example > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MJLINK-9) Add support for multi module projects
[
https://issues.apache.org/jira/browse/MJLINK-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223216#comment-17223216
]
Benjamin Marwell commented on MJLINK-9:
---
Hi,
I created an integration test case locally which works fine. Maybe this has
been resolved?
PR following tomorrow.
I found out that I cannot set a classifier, though. For example if you want to
create both a runnable jar and a jlink bundle, you need to set the classifier
of the jar plugin. I will also create an issue for this.
> Add support for multi module projects
> -
>
> Key: MJLINK-9
> URL: https://issues.apache.org/jira/browse/MJLINK-9
> Project: Maven JLink Plugin
> Issue Type: New Feature
>Affects Versions: 3.0.0-alpha-1
>Reporter: Vladimir Tsanev
>Priority: Major
> Labels: intern, multimodule
>
> I would like to have a multi module project something like
> {code:java}
> parent
> lib
> pom.xml
> app
> pom.xml
> dist
> pom.xml{code}
> where app is my application module that depends on a lib module and dist is a
> jlink module that depends on app.
>
> Currently I see a NPE because it cannot find app's jar. Seems like jars from
> reactor are not resolved
>
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink
> (default-jlink) on project dist: Execution default-jlink of goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.:
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink
> (default-jlink) on project dist: Execution default-jlink of goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> 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:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:564)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-jlink of goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:145)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> 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:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at
[GitHub] [maven-archetypes] JurrianFahner edited a comment on pull request #5: Fix merge conflicts of PR #3
JurrianFahner edited a comment on pull request #5: URL: https://github.com/apache/maven-archetypes/pull/5#issuecomment-719002625 @eolivelli Gentle ping... Could you review this PR? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-archetypes] JurrianFahner commented on pull request #5: Fix merge conflicts of PR #3
JurrianFahner commented on pull request #5: URL: https://github.com/apache/maven-archetypes/pull/5#issuecomment-719002625 @eolivelli Could you review this PR? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] MartinKanters commented on a change in pull request #386: [MNG-6999] Chained (consumer) XMLFilters can result in "floating" comments
MartinKanters commented on a change in pull request #386:
URL: https://github.com/apache/maven/pull/386#discussion_r514502330
##
File path:
maven-core/src/test/java/org/apache/maven/project/ProjectBuilderTest.java
##
@@ -236,9 +236,9 @@ public void testReadInvalidPom()
{
projectBuilder.build( pomFile, configuration );
}
-catch ( InvalidArtifactRTException iarte )
+catch ( Exception ex )
{
-assertThat( iarte.getMessage(), containsString( "The groupId
cannot be empty." ) );
+ assertThat( ex.getMessage(), containsString( "expected START_TAG
or END_TAG not TEXT" ) );
Review comment:
The extra space at the start can be removed I think.
##
File path:
maven-core/src/test/java/org/apache/maven/project/ProjectBuilderTest.java
##
@@ -249,9 +249,9 @@ public void testReadInvalidPom()
catch ( ProjectBuildingException ex )
{
assertEquals( 1, ex.getResults().size() );
-MavenProject project = ex.getResults().get( 0 ).getProject();
-assertNotNull( project );
-assertNotSame( 0, ex.getResults().get( 0 ).getProblems().size() );
+assertNotNull( ex.getResults().get( 0 ).getPomFile() );
Review comment:
It's not related to your merge request, but good practice anyway I
think.
To make sure we get in these catch block we should add a `fail("Expected an
exception to be thrown")` in the try-block after. I've had tests pass without
ever reaching the catch block..
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (SUREFIRE-1852) ReporterException: When writing xml report stdout/stderr
[
https://issues.apache.org/jira/browse/SUREFIRE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223167#comment-17223167
]
Tibor Digana commented on SUREFIRE-1852:
[~kgyrtkirk]
As i can see your stacktrace, i have to say that your Jenkins deleted the temp
file.
*Caused by: java.io.FileNotFoundException:
/tmp/stderr6375771388417760677deferred (No such file or directory)*
I have checked the old code for 3.0.0-M4 and I don't see a bug in the plugin.
Another files, e.g. JAR file, which are used to execute the tests themselve are
also located in tem dir but this can be configured.
If you want to alter the remaining paths and make them configureble, it is
technically possible, feel free to contribute to the project at GitHub.
> ReporterException: When writing xml report stdout/stderr
>
>
> Key: SUREFIRE-1852
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1852
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M4
>Reporter: Zoltan Haindrich
>Priority: Major
>
> I'm seeing some junit xml errors lately on ci.hive.apache.org (we are using
> 3.0.0-M4)
> jenkins is unable to parse the junit result xml because its not a valid xml.
> I was able to take a look at one of the problematic xmls and it doesn't "end
> well"
> {code}
>
[jira] [Created] (MWRAPPER-10) Checksums for maven-dists
Yannick Menager created MWRAPPER-10: --- Summary: Checksums for maven-dists Key: MWRAPPER-10 URL: https://issues.apache.org/jira/browse/MWRAPPER-10 Project: Maven Wrapper Issue Type: Bug Reporter: Yannick Menager Automatically downloading and running software is highly dangerous from a security point of view. Wrapper should include the ability to include a checksum and verify the downloaded zip file -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MWRAPPER-9) Ability to automatically download JRE
Yannick Menager created MWRAPPER-9: -- Summary: Ability to automatically download JRE Key: MWRAPPER-9 URL: https://issues.apache.org/jira/browse/MWRAPPER-9 Project: Maven Wrapper Issue Type: Bug Reporter: Yannick Menager It would be helpful if the wrapper had the ability to download a JRE like adoptjdk for example -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] rfscholte commented on pull request #386: [MNG-6999] Chained (consumer) XMLFilters can result in "floating" comments
rfscholte commented on pull request #386: URL: https://github.com/apache/maven/pull/386#issuecomment-718921546 if there are no objections, I'll merge this tomorrow This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-compiler-plugin] elharo commented on a change in pull request #34: [MCOMPILER-428] improve incremental compilation documentation
elharo commented on a change in pull request #34: URL: https://github.com/apache/maven-compiler-plugin/pull/34#discussion_r514368549 ## File path: src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java ## @@ -483,7 +483,19 @@ private List fileExtensions; /** - * to enable/disable incrementation compilation feature + * to enable/disable incrementation compilation feature. + * This leads to two different modes depending on the underlining compiler. Default javac compiler does the + * following: + * + * true (default) in this mode the compiler plugin determines whether any JAR files the + * current module depends on have been changed in the current build run, or any source file was added, removed or + * changed since the last compilation. If this is the case, the compiler plugin recompiles all sources Review comment: period at end ## File path: src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java ## @@ -483,7 +483,19 @@ private List fileExtensions; /** - * to enable/disable incrementation compilation feature + * to enable/disable incrementation compilation feature. + * This leads to two different modes depending on the underlining compiler. Default javac compiler does the + * following: + * + * true (default) in this mode the compiler plugin determines whether any JAR files the + * current module depends on have been changed in the current build run, or any source file was added, removed or + * changed since the last compilation. If this is the case, the compiler plugin recompiles all sources + * false (not recommended) this only compiles source files which are newer than their + * corresponding class files. That is which have been changed since the last compilation. This does not Review comment: That is... is a sentence fragment ## File path: src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java ## @@ -483,7 +483,19 @@ private List fileExtensions; /** - * to enable/disable incrementation compilation feature + * to enable/disable incrementation compilation feature. + * This leads to two different modes depending on the underlining compiler. Default javac compiler does the Review comment: underlining --> underlying The default javac ## File path: src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java ## @@ -483,7 +483,19 @@ private List fileExtensions; /** - * to enable/disable incrementation compilation feature + * to enable/disable incrementation compilation feature. + * This leads to two different modes depending on the underlining compiler. Default javac compiler does the + * following: + * + * true (default) in this mode the compiler plugin determines whether any JAR files the + * current module depends on have been changed in the current build run, or any source file was added, removed or Review comment: have been --> have build run, --> build run; This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-compiler-plugin] sadraskol commented on pull request #34: [MCOMPILER-428] improve incremental compilation documentation
sadraskol commented on pull request #34: URL: https://github.com/apache/maven-compiler-plugin/pull/34#issuecomment-718818351 I've pushed the modification with the usage of present tense and a modulation to specify that the description is javac-specific. Thanks for your feedbacks! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jlink-plugin] sparsick commented on pull request #9: [MJLINK-50] upgrade to Java 8 / Maven 3.1.0
sparsick commented on pull request #9: URL: https://github.com/apache/maven-jlink-plugin/pull/9#issuecomment-718777426 @bmhm :+1: I changed it This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jlink-plugin] bmhm commented on a change in pull request #9: [MJLINK-50] upgrade to Java 8 / Maven 3.1.0
bmhm commented on a change in pull request #9: URL: https://github.com/apache/maven-jlink-plugin/pull/9#discussion_r514263074 ## File path: pom.xml ## @@ -118,42 +117,76 @@ org.mockito mockito-core - 2.19.0 + 3.5.13 test org.assertj assertj-core - 2.9.1 + 3.16.1 + test + + + org.junit.jupiter + junit-jupiter + test + + + org.junit.vintage + junit-vintage-engine test + + + +org.junit +junit-bom +5.7.0 +pom +import + + + + - maven-enforcer-plugin - 3.0.0-M1 - - - enforce-bytecode-version - - - -1.7 - - org.ow2.asm:asm - - - - - - - + org.apache.maven.plugins + maven-compiler-plugin + 3.8.1 + + + org.apache.maven.plugins + maven-plugin-plugin + 3.6.0 + + +maven-enforcer-plugin +3.0.0-M3 + + +enforce-bytecode-version + + + + 8 Review comment: wouldn’t it make sense to use this and line 69 (compiler.release) as property? ## File path: pom.xml ## @@ -65,9 +65,8 @@ -3.0 -1.7 -1.7 +3.1.0 +8 Review comment: defining `maven.compiler.release` will make it incompatible with Java 8. Please use `maven.compiler.source` and `maven.compiler.target` for now. Also see my other comment. `jlink` will be obtained from the `$PATH` or `toolchains.xml`, so this does not prevent this plugin from running with Java 8. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MJLINK-50) upgrade to Java 8 / Maven 3.1.0
[ https://issues.apache.org/jira/browse/MJLINK-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17222809#comment-17222809 ] Sandra Parsick commented on MJLINK-50: -- Update the issue after disussion in the PR #9 > upgrade to Java 8 / Maven 3.1.0 > --- > > Key: MJLINK-50 > URL: https://issues.apache.org/jira/browse/MJLINK-50 > Project: Maven JLink Plugin > Issue Type: Improvement >Affects Versions: 3.0.0-alpha-1 >Reporter: Sandra Parsick >Priority: Major > > Currently, the base jdk and maven is 1.7 and 3.0.0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MJLINK-50) upgrade to Java 8 / Maven 3.1.0
[ https://issues.apache.org/jira/browse/MJLINK-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandra Parsick updated MJLINK-50: - Description: Currently, the base jdk and maven is 1.7 and 3.0.0. (was: To support the module system in a better way, the plugin should have Java 11 as minimum) > upgrade to Java 8 / Maven 3.1.0 > --- > > Key: MJLINK-50 > URL: https://issues.apache.org/jira/browse/MJLINK-50 > Project: Maven JLink Plugin > Issue Type: Improvement >Affects Versions: 3.0.0-alpha-1 >Reporter: Sandra Parsick >Priority: Major > > Currently, the base jdk and maven is 1.7 and 3.0.0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MJLINK-50) upgrade to Java 8 / Maven 3.1.0
[ https://issues.apache.org/jira/browse/MJLINK-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandra Parsick updated MJLINK-50: - Summary: upgrade to Java 8 / Maven 3.1.0 (was: Upgrade to Java 11) > upgrade to Java 8 / Maven 3.1.0 > --- > > Key: MJLINK-50 > URL: https://issues.apache.org/jira/browse/MJLINK-50 > Project: Maven JLink Plugin > Issue Type: Improvement >Affects Versions: 3.0.0-alpha-1 >Reporter: Sandra Parsick >Priority: Major > > To support the module system in a better way, the plugin should have Java 11 > as minimum -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-jlink-plugin] sparsick commented on pull request #9: [MJLINK-50] -Upgrade to Java 11
sparsick commented on pull request #9: URL: https://github.com/apache/maven-jlink-plugin/pull/9#issuecomment-718578254 @bmhm good point. Thank you. I will update the issue This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jlink-plugin] sparsick commented on a change in pull request #9: [MJLINK-50] -Upgrade to Java 11
sparsick commented on a change in pull request #9: URL: https://github.com/apache/maven-jlink-plugin/pull/9#discussion_r514121512 ## File path: pom.xml ## @@ -146,7 +169,7 @@ 3.0.0-M3 - enforce-bytecode-version + enforce-bytecode-version Review comment: Fix see next commit This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jlink-plugin] sparsick commented on a change in pull request #9: [MJLINK-50] -Upgrade to Java 11
sparsick commented on a change in pull request #9: URL: https://github.com/apache/maven-jlink-plugin/pull/9#discussion_r514121647 ## File path: pom.xml ## @@ -67,6 +67,7 @@ 3.1.0 8 +8 Review comment: Fix see next commit This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jlink-plugin] sparsick commented on a change in pull request #9: [MJLINK-50] -Upgrade to Java 11
sparsick commented on a change in pull request #9: URL: https://github.com/apache/maven-jlink-plugin/pull/9#discussion_r514105741 ## File path: pom.xml ## @@ -146,7 +169,7 @@ 3.0.0-M3 - enforce-bytecode-version + enforce-bytecode-version Review comment: It seems that this configuration doesn't overwrite the configuration with the same defined in maven-parent This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jlink-plugin] sparsick commented on a change in pull request #9: [MJLINK-50] -Upgrade to Java 11
sparsick commented on a change in pull request #9: URL: https://github.com/apache/maven-jlink-plugin/pull/9#discussion_r514103082 ## File path: pom.xml ## @@ -67,6 +67,7 @@ 3.1.0 8 +8 Review comment: I had to insert this property because enforcer-maven-plugin configured in maven-parent uses this property. Without this property I got following error: ``` [INFO] --- maven-enforcer-plugin:3.0.0-M3:enforce (enforce-bytecode-version) @ maven-jlink-plugin --- [INFO] Adding ignore: module-info [INFO] Restricted to JDK 1.7 yet org.mockito:mockito-core:jar:3.5.13:test contains org/mockito/AdditionalAnswers.class targeted to JDK 8 [INFO] Restricted to JDK 1.7 yet org.junit.platform:junit-platform-commons:jar:1.7.0:test contains org/junit/platform/commons/JUnitException.class targeted to JDK 8 [INFO] Restricted to JDK 1.7 yet org.objenesis:objenesis:jar:3.1:test contains org/objenesis/ObjenesisHelper.class targeted to JDK 8 [INFO] Restricted to JDK 1.7 yet org.junit.vintage:junit-vintage-engine:jar:5.7.0:test contains org/junit/vintage/engine/JUnit4VersionCheck.class targeted to JDK 8 [INFO] Restricted to JDK 1.7 yet org.assertj:assertj-core:jar:3.16.1:test contains org/assertj/core/condition/Not.class targeted to JDK 8 [INFO] Restricted to JDK 1.7 yet org.junit.jupiter:junit-jupiter-params:jar:5.7.0:test contains org/junit/jupiter/params/ParameterizedTest.class targeted to JDK 8 [INFO] Restricted to JDK 1.7 yet org.junit.jupiter:junit-jupiter-engine:jar:5.7.0:test contains org/junit/jupiter/engine/Constants.class targeted to JDK 8 [INFO] Restricted to JDK 1.7 yet org.junit.jupiter:junit-jupiter-api:jar:5.7.0:test contains org/junit/jupiter/api/AfterAll.class targeted to JDK 8 [INFO] Restricted to JDK 1.7 yet org.junit.platform:junit-platform-engine:jar:1.7.0:test contains org/junit/platform/engine/CompositeFilter$1.class targeted to JDK 8 [WARNING] Rule 0: org.apache.maven.plugins.enforcer.EnforceBytecodeVersion failed with message: Found Banned Dependency: org.mockito:mockito-core:jar:3.5.13 Found Banned Dependency: org.junit.platform:junit-platform-commons:jar:1.7.0 Found Banned Dependency: org.objenesis:objenesis:jar:3.1 Found Banned Dependency: org.junit.vintage:junit-vintage-engine:jar:5.7.0 Found Banned Dependency: org.assertj:assertj-core:jar:3.16.1 Found Banned Dependency: org.junit.jupiter:junit-jupiter-params:jar:5.7.0 Found Banned Dependency: org.junit.jupiter:junit-jupiter-engine:jar:5.7.0 Found Banned Dependency: org.junit.jupiter:junit-jupiter-api:jar:5.7.0 Found Banned Dependency: org.junit.platform:junit-platform-engine:jar:1.7.0 Use 'mvn dependency:tree' to locate the source of the banned dependencies. [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 3.723 s [INFO] Finished at: 2020-10-29T10:05:48+01:00 [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M3:enforce (enforce-bytecode-version) on project maven-jlink-plugin: Some Enforcer rules have failed. Look above for specific messages explaining why the rule failed. -> [Help 1] ``` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jlink-plugin] sparsick commented on pull request #9: [MJLINK-50] -Upgrade to Java 11
sparsick commented on pull request #9: URL: https://github.com/apache/maven-jlink-plugin/pull/9#issuecomment-718475463 @rfscholte @aalmiray Thanks for your review. I change the pom to address your comment. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jlink-plugin] bmhm commented on a change in pull request #9: [MJLINK-50] -Upgrade to Java 11
bmhm commented on a change in pull request #9: URL: https://github.com/apache/maven-jlink-plugin/pull/9#discussion_r513802569 ## File path: pom.xml ## @@ -66,8 +66,7 @@ 3.0 -1.7 -1.7 +11 Review comment: But jlink doesn't come with java 8? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MENFORCER-360) requireUpperBoundDeps should have option to check for same major version
[
https://issues.apache.org/jira/browse/MENFORCER-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17222698#comment-17222698
]
Zhenlei Huang edited comment on MENFORCER-360 at 10/29/20, 7:15 AM:
More precisely, for a project that follows semantic versioning having
dependency on groupId:artifactId, the conflict matrix should be as following,
||R \ T||1.0.0||1.0.1||1.1.0||2.0.0||
|1.0.0|{color:#008000}OK{color}|{color:#008000}OK{color}|{color:#FF}Breaking{color}|{color:#FF}Breaking{color}|
|1.0.1|{color:#008000}OK{color}|{color:#008000}OK{color}|{color:#FF}Breaking{color}|{color:#FF}Breaking{color}|
|1.1.0|{color:#008000}OK{color}|{color:#008000}OK{color}|{color:#008000}OK{color}|{color:#FF}Breaking{color}|
|2.0.0|{color:#FF}Breaking{color}|{color:#FF}Breaking{color}|{color:#FF}Breaking{color}|{color:#008000}OK{color}|
R is short for resolved version, and T for transitive dependency version.
Current implementation
[https://github.com/apache/maven-enforcer/blob/2babf83f8cb03b8565fa48fe429dbdd8f9fccee4/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireUpperBoundDeps.java#L342]
compares version only and does not consider major version incompatible, say
resolved version is 2.0.0 and transitive dependency version is 1.0.0 .
[~guyv] If the above is exactly what you desired, then I would suggest
introducing some boolean flag like *enforceSemVer* :)
was (Author: gmshake):
More precisely, for a project that follows semantic versioning having
dependency on groupId:artifactId, the conflict matrix should be as following,
||R \ T||1.0.0||1.0.1||1.1.0||2.0.0||
|1.0.0|{color:green}OK{color}|{color:green}OK{color}|{color:red}Breaking{color}|{color:red}Breaking{color}|
|1.0.1|{color:green}OK{color}|{color:green}OK{color}|{color:red}Breaking{color}|{color:red}Breaking{color}|
|1.1.0|{color:green}OK{color}|{color:green}OK{color}|{color:green}OK{color}|{color:red}Breaking{color}|
|2.0.0|{color:red}Breaking{color}|{color:red}Breaking{color}|{color:red}Breaking{color}|{color:green}OK{color}|
R is short for resolved version, and T for transitive dependency version.
Current implementation
https://github.com/apache/maven-enforcer/blob/2babf83f8cb03b8565fa48fe429dbdd8f9fccee4/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireUpperBoundDeps.java#L342
compares version only and does not consider major version incompatible, say
resolved version is 1.0.0 and transitive dependency version is 2.0.0 .
[~guyv] If the above is exactly what you desired, then I would suggest
introducing some boolean flag like *enforceSemVer* :)
> requireUpperBoundDeps should have option to check for same major version
>
>
> Key: MENFORCER-360
> URL: https://issues.apache.org/jira/browse/MENFORCER-360
> Project: Maven Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Affects Versions: 3.0.0-M3
>Reporter: Guy Veraghtert
>Priority: Major
>
> In our project we use semantic versioning for our dependencies
> ([https://semver.org/|https://semver.org/).])
> The requireUpperBoundDeps rule already checks for compatible versions, but we
> would like to have the option to specify that no major (i.e. breaking)
> versions are mixed.
> So a (transitive) dependency on groupId:artifactId:1.0.0 and on
> groupId:artifactId:2.0.0 means that we have a conflict.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
