[GitHub] [maven] pzygielo commented on a change in pull request #391: Mng 6957: Support Build Consumer while defining modules in reverse order

[GitBox]

pzygielo commented on a change in pull request #391:
URL: https://github.com/apache/maven/pull/391#discussion_r542168538



##
File path: 
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
##
@@ -1707,4 +1786,132 @@ protected void mergePluginContainer_Plugins( 
PluginContainer target, PluginConta
 // don't merge
 }
 }
+
+/**
+ * Builds up the transformer context.
+ * After the buildplan is ready, the build()-method returns the immutable 
context useful during distribution.
+ * This is an inner class, as it must be able to call readRawModel() 
+ * 
+ * @author Robert Scholte
+ * @since 4.0.0
+ */
+private class DefaultTransformerContextBuilder implements 
TransformerContextBuilder
+{
+private final DefaultTransformerContext context = new 
DefaultTransformerContext();
+
+private final Map> 
mappedSources
+= new ConcurrentHashMap<>( 64 );
+
+/**
+ * If an interface could be extracted, DefaultModelProblemCollector 
should be ModelProblemCollectorExt
+ * 
+ * @param request
+ * @param collector
+ * @return
+ */
+@Override
+public TransformerContext initialize( ModelBuildingRequest request, 
ModelProblemCollector collector )
+{
+// We must assume the TransformerContext was created using 
this.newTransformerContextBuilder()
+DefaultModelProblemCollector problems = 
(DefaultModelProblemCollector) collector;
+return new TransformerContext()
+{
+@Override
+public String getUserProperty( String key )
+{
+return context.userProperties.computeIfAbsent( key,
+   k -> 
request.getUserProperties().getProperty( key ) );
+}
+
+@Override
+public Model getRawModel( String gId, String aId )
+{
+return context.modelByGA.computeIfAbsent( new 
DefaultTransformerContext.GAKey( gId, aId ),
+  k -> 
findRawModel( gId, aId ) );
+}
+
+@Override
+public Model getRawModel( Path path )
+{
+return context.modelByPath.computeIfAbsent( path, k -> 
findRawModel( path ) );
+}
+
+private Model findRawModel( String groupId, String artifactId )
+{
+Source source = getSource( groupId, artifactId );
+if ( source != null )
+{
+try
+{
+ModelBuildingRequest gaBuildingRequest = new 
FilterModelBuildingRequest( request ) 
+{
+@Override
+public ModelSource getModelSource()
+{
+return (ModelSource) source;
+}
+
+};
+return readRawModel( gaBuildingRequest, problems );
+}
+catch ( ModelBuildingException e )
+{
+// gathered with problem collector
+}
+}
+return null;
+}
+
+private Model findRawModel( Path p )
+{
+if ( !Files.isRegularFile( p ) )
+{
+throw new IllegalArgumentException( "Not a regular 
file: " + p );
+}
+
+DefaultModelBuildingRequest req = new 
DefaultModelBuildingRequest( request )
+.setPomFile( p.toFile() )
+.setModelSource( new FileModelSource( 
p.toFile() ) );
+
+try
+{
+return readRawModel( req, problems );
+}
+catch ( ModelBuildingException e )
+{
+// gathered with problem collector
+}
+return null;
+}
+};
+}
+
+@Override
+public TransformerContext build()
+{
+return context;
+}
+
+public Source getSource( String groupId, String artifactId )
+{
+Set sources = mappedSources.get( new 
DefaultTransformerContext.GAKey( groupId, artifactId ) );
+if ( sources == null )
+{
+

Following Java Modularity documentation creates errors

[leerho]

Hello,
I have been trying for a few days to get Maven + Eclipse + TestNG to work
with JPMS.

The problem I am running into now is that following the Using Java
Modularity

documentation exactly causes the following error:

> The project was not built due to "Build path contains duplicate entry:
> 'module-info.java' for project 'datasketches-panama'". Fix the problem,
> then try refreshing this project and building it since it may be
> inconsistent.
>

The documentation specifically insists that there be a module descriptor
located in both src/main/java and in src/test/java.
The main and test trees are parallel with the same underlying tree
structure, so as far as Java is concerned they are essentially the same
packages.

I can supply a lot more information if needed.

Please advise.

Thanks,

Lee Rhodes,
Committer, DataSketches.apache.org

[jira] [Commented] (MINVOKER-272) use Files.createTempDirectory(...) instead of custom code around File.createTempFile(...)

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MINVOKER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248695#comment-17248695
 ] 

Hudson commented on MINVOKER-272:
-

Build failed in Jenkins: Maven » Maven TLP » maven-invoker-plugin » master #26

See 
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-invoker-plugin/job/master/26/

> use Files.createTempDirectory(...) instead of custom code around 
> File.createTempFile(...)
> -
>
> Key: MINVOKER-272
> URL: https://issues.apache.org/jira/browse/MINVOKER-272
> Project: Maven Invoker Plugin
>  Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.2.2
>
>
> since Java 7, a perfect API for temp directory creation was introduced: let's 
> use it
>  
> we need it when users configured IT cloning target directory to a directory 
> inside the ITs source tree



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSCMPUB-47) use Files.createTempDirectory(...) instead of custom code around File.createTempFile(...)

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MSCMPUB-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248688#comment-17248688
 ] 

Hudson commented on MSCMPUB-47:
---

Build succeeded in Jenkins: Maven » Maven TLP » maven-scm-publish-plugin » 
master #17

See 
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-scm-publish-plugin/job/master/17/

> use Files.createTempDirectory(...) instead of custom code around 
> File.createTempFile(...)
> -
>
> Key: MSCMPUB-47
> URL: https://issues.apache.org/jira/browse/MSCMPUB-47
> Project: Maven SCM Publish Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.1.0
>
>
> since Java 7, a perfect API for temp directory creation was introduced: let's 
> use it
>  
> we need it when auto-creating remote empty directory in Subversion 
> ([https://maven.apache.org/plugins/maven-scm-publish-plugin/publish-scm-mojo.html#automaticRemotePathCreation]
>  )



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MCOMPILER-445) Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing

[Benjamin Marwell (Jira)]

[ 
https://issues.apache.org/jira/browse/MCOMPILER-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248680#comment-17248680
 ] 

Benjamin Marwell edited comment on MCOMPILER-445 at 12/13/20, 10:30 PM:


[~michael-o] I think I just found the cause.

The usual {{mvn}} script will just load a "restricted" java, as they said 
upstream. In contrast to this, {{javac}}  invocation would load some extra 
modules.

I placed a file `.mvn/jvm.config` in the IT directory I created and added the 
following lines:
{quote}{{--add-modules}}
 {{jdk.javadoc}}
 {{--add-opens}}
 {{jdk.javadoc/jdk.javadoc.doclet=ALL-UNNAMED}}
{quote}
Guess what, it works. So we could "fix" this in maven-core by adding some logic 
like this:
{quote}
{code:java}
$JAVA_HOME/bin/java -version 2>&1 \
| head -1 \
| grep -qs "\"16" \
&& export MAVEN_OPTS="--add-modules jdk.javadoc --add-opens 
jdk.javadoc/jdk.javadoc.doclet=ALL-UNNAMED"
{code}
{quote}
 


was (Author: mampf86):
[~michael-o] I think I just found the cause.

The usual {{mvn}} script will just load a "restricted" java, as they said 
upstream. In contrast to this, {{javac}}  invocation would load some extra 
modules.

I placed a file `.mvn/jvm.config` in the IT directory I created and added the 
following lines:
{quote}{{--add-modules}}
{{jdk.javadoc}}
{{--add-opens}}
{{jdk.javadoc/jdk.javadoc.doclet=ALL-UNNAMED}}
{quote}
Guess what, it works. So we could "fix" this in maven-core by adding some logic 
like this:

{{$JAVA_HOME/bin/java -version 2>&1 | head -1 | grep -qs "\"16" && export 
MAVEN_OPTS="--add-modules jdk.javadoc --add-opens 
jdk.javadoc/jdk.javadoc.doclet=ALL-UNNAMED"}}

 

> Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing
> ---
>
> Key: MCOMPILER-445
> URL: https://issues.apache.org/jira/browse/MCOMPILER-445
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.8.0, 3.8.1
> Environment: Maven 3.6.3
> Compiler-Plugin 3.8.1
> JDK16 since JDK 16 ea b 18
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
>  Labels: jdk, jdk-javac, jdk16
>
> h2. Issue description
> When compiling with options {{noFork}} and {{-Xdoclint}}, the compiler plugin 
> will fail:
>  
> {quote}{{[INFO] 
> }}
> {{[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile 
> (pre-compile-jute) on project zookeeper-jute: Fatal error compiling: error: 
> invalid flag: -Xdoclint:-missing -> [Help 1]}}
> {{This is Maven debug:}}
> {{[DEBUG] Classpath:}}
> {{[DEBUG] /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes}}
> {{[DEBUG] 
> /home/eolivelli/.m2/repository/org/apache/yetus/audience-annotations/0.5.0/audience-annotations-0.5.0.jar}}
> {{[DEBUG] Source roots:}}
> {{[DEBUG] /home/eolivelli/dev/zookeeper/zookeeper-jute/src/main/java}}
> {{[DEBUG] 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/java}}
> {{[DEBUG] 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations}}
> {{[DEBUG] Command line options:}}
> {{[DEBUG] -d /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes 
> -classpath 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes:/home/eolivelli/.m2/repository/org/apache/yetus/audience-annotations/0.5.0/audience-annotations-0.5.0.jar:
>  -sourcepath 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/src/main/java:/home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/java:/home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations:
>  -s 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations
>  -g --release 8 -encoding UTF-8 -Werror -Xlint:deprecation -Xlint:unchecked 
> -Xlint:-options -Xdoclint:-missing -Xpkginfo:always}}
> {{[DEBUG] incrementalBuildHelper#beforeRebuildExecution}}
> {{[INFO] Compiling 36 source files to 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes}}{quote}
> But -Xdoclint is a valid option.
> h2. Cause
> Without forking, maven runs {{javac}} using 
> {{com.sun.tools.javac.api.JavacTool}}. The module is not loaded.
> h2. Proposed solution
> From the mailing list:
> When running the compiler in noFork mode, use the ToolProvider to run Javac 
> in the same VM on Java9+. This can be implemented using multi-release-jars. 
> See the {{maven-jlink-plugin}} as a reference.
> h2. Related
> [Move Doclint to jdk.javadoc 
> module|https://bugs.openjdk.java.net/browse/JDK-8252712]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MCOMPILER-445) Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing

[Benjamin Marwell (Jira)]

[ 
https://issues.apache.org/jira/browse/MCOMPILER-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248684#comment-17248684
 ] 

Benjamin Marwell commented on MCOMPILER-445:


Agreed, but as a module must be loaded, it must be before the JVM starts. AFAIK 
you cannot load a module dynamically (which is the whole point of JPMS). You 
could until JDK14 I think, but illegal-access is now always deny if I am not 
mistaken.
Anyway, upstream had an incompatible change here.

Other ways: From JDK16 on, disallow "no-fork".

> Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing
> ---
>
> Key: MCOMPILER-445
> URL: https://issues.apache.org/jira/browse/MCOMPILER-445
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.8.0, 3.8.1
> Environment: Maven 3.6.3
> Compiler-Plugin 3.8.1
> JDK16 since JDK 16 ea b 18
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
>  Labels: jdk, jdk-javac, jdk16
>
> h2. Issue description
> When compiling with options {{noFork}} and {{-Xdoclint}}, the compiler plugin 
> will fail:
>  
> {quote}{{[INFO] 
> }}
> {{[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile 
> (pre-compile-jute) on project zookeeper-jute: Fatal error compiling: error: 
> invalid flag: -Xdoclint:-missing -> [Help 1]}}
> {{This is Maven debug:}}
> {{[DEBUG] Classpath:}}
> {{[DEBUG] /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes}}
> {{[DEBUG] 
> /home/eolivelli/.m2/repository/org/apache/yetus/audience-annotations/0.5.0/audience-annotations-0.5.0.jar}}
> {{[DEBUG] Source roots:}}
> {{[DEBUG] /home/eolivelli/dev/zookeeper/zookeeper-jute/src/main/java}}
> {{[DEBUG] 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/java}}
> {{[DEBUG] 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations}}
> {{[DEBUG] Command line options:}}
> {{[DEBUG] -d /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes 
> -classpath 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes:/home/eolivelli/.m2/repository/org/apache/yetus/audience-annotations/0.5.0/audience-annotations-0.5.0.jar:
>  -sourcepath 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/src/main/java:/home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/java:/home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations:
>  -s 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations
>  -g --release 8 -encoding UTF-8 -Werror -Xlint:deprecation -Xlint:unchecked 
> -Xlint:-options -Xdoclint:-missing -Xpkginfo:always}}
> {{[DEBUG] incrementalBuildHelper#beforeRebuildExecution}}
> {{[INFO] Compiling 36 source files to 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes}}{quote}
> But -Xdoclint is a valid option.
> h2. Cause
> Without forking, maven runs {{javac}} using 
> {{com.sun.tools.javac.api.JavacTool}}. The module is not loaded.
> h2. Proposed solution
> From the mailing list:
> When running the compiler in noFork mode, use the ToolProvider to run Javac 
> in the same VM on Java9+. This can be implemented using multi-release-jars. 
> See the {{maven-jlink-plugin}} as a reference.
> h2. Related
> [Move Doclint to jdk.javadoc 
> module|https://bugs.openjdk.java.net/browse/JDK-8252712]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven] michael-o commented on a change in pull request #391: Mng 6957: Support Build Consumer while defining modules in reverse order

[GitBox]

michael-o commented on a change in pull request #391:
URL: https://github.com/apache/maven/pull/391#discussion_r542017373



##
File path: 
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
##
@@ -1901,8 +1901,9 @@ public Source getSource( String groupId, String 
artifactId )
 }
 return sources.stream().reduce( ( a, b ) ->
 {
-throw new IllegalStateException( "No unique Source for " + 
groupId + ':' + artifactId
-+ ": " + a.getLocation() + " and " + b.getLocation() );
+throw new IllegalStateException( String.format( "No unique 
Source for %s:%s: %s and %s ", 

Review comment:
   There is a trailing WS in the string





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] (MCOMPILER-445) Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MCOMPILER-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248683#comment-17248683
 ] 

Michael Osipov commented on MCOMPILER-445:
--

This is so ugly. There must be a better way.

> Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing
> ---
>
> Key: MCOMPILER-445
> URL: https://issues.apache.org/jira/browse/MCOMPILER-445
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.8.0, 3.8.1
> Environment: Maven 3.6.3
> Compiler-Plugin 3.8.1
> JDK16 since JDK 16 ea b 18
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
>  Labels: jdk, jdk-javac, jdk16
>
> h2. Issue description
> When compiling with options {{noFork}} and {{-Xdoclint}}, the compiler plugin 
> will fail:
>  
> {quote}{{[INFO] 
> }}
> {{[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile 
> (pre-compile-jute) on project zookeeper-jute: Fatal error compiling: error: 
> invalid flag: -Xdoclint:-missing -> [Help 1]}}
> {{This is Maven debug:}}
> {{[DEBUG] Classpath:}}
> {{[DEBUG] /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes}}
> {{[DEBUG] 
> /home/eolivelli/.m2/repository/org/apache/yetus/audience-annotations/0.5.0/audience-annotations-0.5.0.jar}}
> {{[DEBUG] Source roots:}}
> {{[DEBUG] /home/eolivelli/dev/zookeeper/zookeeper-jute/src/main/java}}
> {{[DEBUG] 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/java}}
> {{[DEBUG] 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations}}
> {{[DEBUG] Command line options:}}
> {{[DEBUG] -d /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes 
> -classpath 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes:/home/eolivelli/.m2/repository/org/apache/yetus/audience-annotations/0.5.0/audience-annotations-0.5.0.jar:
>  -sourcepath 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/src/main/java:/home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/java:/home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations:
>  -s 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations
>  -g --release 8 -encoding UTF-8 -Werror -Xlint:deprecation -Xlint:unchecked 
> -Xlint:-options -Xdoclint:-missing -Xpkginfo:always}}
> {{[DEBUG] incrementalBuildHelper#beforeRebuildExecution}}
> {{[INFO] Compiling 36 source files to 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes}}{quote}
> But -Xdoclint is a valid option.
> h2. Cause
> Without forking, maven runs {{javac}} using 
> {{com.sun.tools.javac.api.JavacTool}}. The module is not loaded.
> h2. Proposed solution
> From the mailing list:
> When running the compiler in noFork mode, use the ToolProvider to run Javac 
> in the same VM on Java9+. This can be implemented using multi-release-jars. 
> See the {{maven-jlink-plugin}} as a reference.
> h2. Related
> [Move Doclint to jdk.javadoc 
> module|https://bugs.openjdk.java.net/browse/JDK-8252712]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MCOMPILER-445) Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing

[Benjamin Marwell (Jira)]

[ 
https://issues.apache.org/jira/browse/MCOMPILER-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248680#comment-17248680
 ] 

Benjamin Marwell commented on MCOMPILER-445:


[~michael-o] I think I just found the cause.

The usual {{mvn}} script will just load a "restricted" java, as they said 
upstream. In contrast to this, {{javac}}  invocation would load some extra 
modules.

I placed a file `.mvn/jvm.config` in the IT directory I created and added the 
following lines:
{quote}{{--add-modules}}
{{jdk.javadoc}}
{{--add-opens}}
{{jdk.javadoc/jdk.javadoc.doclet=ALL-UNNAMED}}
{quote}
Guess what, it works. So we could "fix" this in maven-core by adding some logic 
like this:

{{$JAVA_HOME/bin/java -version 2>&1 | head -1 | grep -qs "\"16" && export 
MAVEN_OPTS="--add-modules jdk.javadoc --add-opens 
jdk.javadoc/jdk.javadoc.doclet=ALL-UNNAMED"}}

 

> Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing
> ---
>
> Key: MCOMPILER-445
> URL: https://issues.apache.org/jira/browse/MCOMPILER-445
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.8.0, 3.8.1
> Environment: Maven 3.6.3
> Compiler-Plugin 3.8.1
> JDK16 since JDK 16 ea b 18
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
>  Labels: jdk, jdk-javac, jdk16
>
> h2. Issue description
> When compiling with options {{noFork}} and {{-Xdoclint}}, the compiler plugin 
> will fail:
>  
> {quote}{{[INFO] 
> }}
> {{[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile 
> (pre-compile-jute) on project zookeeper-jute: Fatal error compiling: error: 
> invalid flag: -Xdoclint:-missing -> [Help 1]}}
> {{This is Maven debug:}}
> {{[DEBUG] Classpath:}}
> {{[DEBUG] /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes}}
> {{[DEBUG] 
> /home/eolivelli/.m2/repository/org/apache/yetus/audience-annotations/0.5.0/audience-annotations-0.5.0.jar}}
> {{[DEBUG] Source roots:}}
> {{[DEBUG] /home/eolivelli/dev/zookeeper/zookeeper-jute/src/main/java}}
> {{[DEBUG] 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/java}}
> {{[DEBUG] 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations}}
> {{[DEBUG] Command line options:}}
> {{[DEBUG] -d /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes 
> -classpath 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes:/home/eolivelli/.m2/repository/org/apache/yetus/audience-annotations/0.5.0/audience-annotations-0.5.0.jar:
>  -sourcepath 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/src/main/java:/home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/java:/home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations:
>  -s 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations
>  -g --release 8 -encoding UTF-8 -Werror -Xlint:deprecation -Xlint:unchecked 
> -Xlint:-options -Xdoclint:-missing -Xpkginfo:always}}
> {{[DEBUG] incrementalBuildHelper#beforeRebuildExecution}}
> {{[INFO] Compiling 36 source files to 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes}}{quote}
> But -Xdoclint is a valid option.
> h2. Cause
> Without forking, maven runs {{javac}} using 
> {{com.sun.tools.javac.api.JavacTool}}. The module is not loaded.
> h2. Proposed solution
> From the mailing list:
> When running the compiler in noFork mode, use the ToolProvider to run Javac 
> in the same VM on Java9+. This can be implemented using multi-release-jars. 
> See the {{maven-jlink-plugin}} as a reference.
> h2. Related
> [Move Doclint to jdk.javadoc 
> module|https://bugs.openjdk.java.net/browse/JDK-8252712]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MCOMPILER-445) Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MCOMPILER-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248674#comment-17248674
 ] 

Michael Osipov commented on MCOMPILER-445:
--

That's the stupidest thing I have ever heard. I would expect a compiler to skip 
comments at all. This needs to be discussed with Rory O'Donnell.

> Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing
> ---
>
> Key: MCOMPILER-445
> URL: https://issues.apache.org/jira/browse/MCOMPILER-445
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.8.0, 3.8.1
> Environment: Maven 3.6.3
> Compiler-Plugin 3.8.1
> JDK16 since JDK 16 ea b 18
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
>  Labels: jdk, jdk-javac, jdk16
>
> h2. Issue description
> When compiling with options {{noFork}} and {{-Xdoclint}}, the compiler plugin 
> will fail:
>  
> {quote}{{[INFO] 
> }}
> {{[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile 
> (pre-compile-jute) on project zookeeper-jute: Fatal error compiling: error: 
> invalid flag: -Xdoclint:-missing -> [Help 1]}}
> {{This is Maven debug:}}
> {{[DEBUG] Classpath:}}
> {{[DEBUG] /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes}}
> {{[DEBUG] 
> /home/eolivelli/.m2/repository/org/apache/yetus/audience-annotations/0.5.0/audience-annotations-0.5.0.jar}}
> {{[DEBUG] Source roots:}}
> {{[DEBUG] /home/eolivelli/dev/zookeeper/zookeeper-jute/src/main/java}}
> {{[DEBUG] 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/java}}
> {{[DEBUG] 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations}}
> {{[DEBUG] Command line options:}}
> {{[DEBUG] -d /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes 
> -classpath 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes:/home/eolivelli/.m2/repository/org/apache/yetus/audience-annotations/0.5.0/audience-annotations-0.5.0.jar:
>  -sourcepath 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/src/main/java:/home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/java:/home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations:
>  -s 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations
>  -g --release 8 -encoding UTF-8 -Werror -Xlint:deprecation -Xlint:unchecked 
> -Xlint:-options -Xdoclint:-missing -Xpkginfo:always}}
> {{[DEBUG] incrementalBuildHelper#beforeRebuildExecution}}
> {{[INFO] Compiling 36 source files to 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes}}{quote}
> But -Xdoclint is a valid option.
> h2. Cause
> Without forking, maven runs {{javac}} using 
> {{com.sun.tools.javac.api.JavacTool}}. The module is not loaded.
> h2. Proposed solution
> From the mailing list:
> When running the compiler in noFork mode, use the ToolProvider to run Javac 
> in the same VM on Java9+. This can be implemented using multi-release-jars. 
> See the {{maven-jlink-plugin}} as a reference.
> h2. Related
> [Move Doclint to jdk.javadoc 
> module|https://bugs.openjdk.java.net/browse/JDK-8252712]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-deploy-plugin] michael-o commented on a change in pull request #12: [MDEPLOY-279] Better validation for alt deploy repository mojo parameter

[GitBox]

michael-o commented on a change in pull request #12:
URL: https://github.com/apache/maven-deploy-plugin/pull/12#discussion_r542003179



##
File path: src/main/java/org/apache/maven/plugins/deploy/DeployMojo.java
##
@@ -51,6 +51,9 @@
 public class DeployMojo
 extends AbstractDeployMojo
 {
+private static final Pattern ALT_INVALID_REPO_SYNTAX_PATTERN = 
Pattern.compile( "(.+)::(.+)::(.+)::(.+)" );

Review comment:
   I do not fully understand the purpose of this. You can extend this ad 
absurdum with zillions of double-colons. We cannot avoid this, but is not wrong:
   `funny-id::https:///server/some/url/sub::/...`. I would rather drop this and 
make both other formats non-greedy all `n-1` matching groups.





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] rfscholte commented on a change in pull request #391: Mng 6957: Support Build Consumer while defining modules in reverse order

[GitBox]

rfscholte commented on a change in pull request #391:
URL: https://github.com/apache/maven/pull/391#discussion_r542001814



##
File path: 
maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuilder.java
##
@@ -703,15 +671,14 @@ private boolean build( List 
results, List p
 }
 
 @SuppressWarnings( "checkstyle:methodlength" )
-private void initProject( MavenProject project, Map 
projects,
+private void initProject( MavenProject project, Map 
projects,
   boolean buildParentIfNotExisting, 
ModelBuildingResult result,
   Map profilesXmls, 
ProjectBuildingRequest projectBuildingRequest )
 {
 Model model = result.getEffectiveModel();
 
 project.setModel( model );
-project.setOriginalModel( result.getRawModel() );
-project.setFile( model.getPomFile() );

Review comment:
   File was already set on the project when creating it (line 167)
   Also, the Model was being abused to hold the file. A model is created with 
an InputStream, so the file information was added via post-processing. Only the 
MavenProject is interested in the file, not the Model.





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] rfscholte commented on a change in pull request #391: Mng 6957: Support Build Consumer while defining modules in reverse order

[GitBox]

rfscholte commented on a change in pull request #391:
URL: https://github.com/apache/maven/pull/391#discussion_r541999673



##
File path: 
maven-model-builder/src/main/java/org/apache/maven/model/building/TransformerContextBuilder.java
##
@@ -0,0 +1,46 @@
+package org.apache.maven.model.building;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+/**
+ * The transformerContextBuilder is responsible for initializing the 
TransformerContext.
+ * In case rawModels are missing, it could do new buildingRequests on the 
ModelBuilder.
+ * 
+ * @author Robert Scholte
+ * @since 3.7.0

Review comment:
   fixed

##
File path: 
maven-xml/src/test/java/org/apache/maven/xml/sax/filter/ParentXMLFilterTest.java
##
@@ -89,6 +89,31 @@ public void testDefaultRelativePath() throws Exception
 assertEquals( expected, actual );
 }
 
+/**
+ * An empty relative path means it must downloaded from a repository.
+ * That implies that the version cannot be solved (if missing, Maven 
should complain)
+ * 
+ * @throws Exception
+ */
+@Test
+public void testEmptyRelativePathNoVersion() throws Exception
+{
+String input = ""
++ "GROUPID"
++ "ARTIFACTID"
++ ""
++ "";
+String expected = ""
++ "GROUPID"
++ "ARTIFACTID"
++ "" // SAX optimization, however "" != 
null ...
++ "";;

Review comment:
   fixed





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] rfscholte commented on a change in pull request #391: Mng 6957: Support Build Consumer while defining modules in reverse order

[GitBox]

rfscholte commented on a change in pull request #391:
URL: https://github.com/apache/maven/pull/391#discussion_r541999304



##
File path: 
maven-model-builder/src/main/java/org/apache/maven/model/building/ModelCacheTag.java
##
@@ -129,12 +129,16 @@ public DependencyManagement fromCache( 
DependencyManagement data )
 
 };
 
-ModelCacheTag FILEMODEL = new ModelCacheTag() 
+/**
+ * The tag used for the file model without profile activation
+ * @since 3.7.0

Review comment:
   fixed





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] rfscholte commented on a change in pull request #391: Mng 6957: Support Build Consumer while defining modules in reverse order

[GitBox]

rfscholte commented on a change in pull request #391:
URL: https://github.com/apache/maven/pull/391#discussion_r541999208



##
File path: 
maven-model-builder/src/main/java/org/apache/maven/model/building/ModelBuildingResult.java
##
@@ -41,6 +41,13 @@
  * @return The model identifiers from the lineage of models, never {@code 
null}.
  */
 List getModelIds();
+
+/**
+ * 
+ * @return the file model
+ * @since 3.7.0

Review comment:
   fixed





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] rfscholte commented on a change in pull request #391: Mng 6957: Support Build Consumer while defining modules in reverse order

[GitBox]

rfscholte commented on a change in pull request #391:
URL: https://github.com/apache/maven/pull/391#discussion_r541998896



##
File path: 
maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuilder.java
##
@@ -386,44 +381,22 @@ private ModelSource createStubModelSource( Artifact 
artifact )
 ReactorModelPool.Builder poolBuilder = new ReactorModelPool.Builder();
 final ReactorModelPool modelPool = poolBuilder.build();
 
-if ( Features.buildConsumer().isActive() )
-{
-final TransformerContext context = new TransformerContext()
-{
-@Override
-public String getUserProperty( String key )
-{
-return request.getUserProperties().getProperty( key );
-}
-
-@Override
-public Model getRawModel( Path p )
-{
-return modelPool.get( p );
-}
-
-@Override
-public Model getRawModel( String groupId, String artifactId )
-{
-return modelPool.get( groupId, artifactId, null );
-}
-};
-request.getRepositorySession().getData().set( 
TransformerContext.KEY, context );
-}
-
-InternalConfig config = new InternalConfig( request, modelPool,
-useGlobalModelCache() ? getModelCache() : new 
ReactorModelCache() );
+InternalConfig config =
+new InternalConfig( request, modelPool, useGlobalModelCache() ? 
getModelCache() : new ReactorModelCache(),
+modelBuilder.newTransformerContextBuilder() );
 
-Map projectIndex = new HashMap<>( 256 );
+Map projectIndex = new HashMap<>( 256 );
 
+// phase 1: get file Models from the reactor.
 boolean noErrors =
 build( results, interimResults, projectIndex, pomFiles, new 
LinkedHashSet<>(), true, recursive,
config, poolBuilder );
-
+
 ClassLoader oldContextClassLoader = 
Thread.currentThread().getContextClassLoader();
 
 try
 {
+// Phase 2: get effective from the reactor

Review comment:
   models, fixed 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] rfscholte commented on a change in pull request #391: Mng 6957: Support Build Consumer while defining modules in reverse order

[GitBox]

rfscholte commented on a change in pull request #391:
URL: https://github.com/apache/maven/pull/391#discussion_r541998917



##
File path: 
maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuilder.java
##
@@ -505,32 +483,17 @@ private boolean build( List 
results, List
 noErrors = false;
 }
 
-Model model = result.getEffectiveModel();
+Model model = result.getFileModel().clone();
 
-poolBuilder.put( model.getPomFile().toPath(),  result.getRawModel() );
+poolBuilder.put( model.getPomFile().toPath(),  model );
 
-try
-{
-// first pass: build without building parent.
-initProject( project, projectIndex, false, result, new HashMap<>( 
0 ), config.request );
-}
-catch ( InvalidArtifactRTException iarte )
-{
-result.getProblems().add( new DefaultModelProblem( null, 
ModelProblem.Severity.ERROR, null, model, -1, -1,
-  iarte ) );
-}
-
-projectIndex.put( result.getModelIds().get( 0 ), project );
-
 InterimResult interimResult = new InterimResult( pomFile, request, 
result, listener, isRoot );
 interimResults.add( interimResult );
-
-if ( recursive && !model.getModules().isEmpty() )
+

Review comment:
   fixed





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] rfscholte commented on a change in pull request #391: Mng 6957: Support Build Consumer while defining modules in reverse order

[GitBox]

rfscholte commented on a change in pull request #391:
URL: https://github.com/apache/maven/pull/391#discussion_r541998876



##
File path: 
maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuilder.java
##
@@ -386,44 +381,22 @@ private ModelSource createStubModelSource( Artifact 
artifact )
 ReactorModelPool.Builder poolBuilder = new ReactorModelPool.Builder();
 final ReactorModelPool modelPool = poolBuilder.build();
 
-if ( Features.buildConsumer().isActive() )
-{
-final TransformerContext context = new TransformerContext()
-{
-@Override
-public String getUserProperty( String key )
-{
-return request.getUserProperties().getProperty( key );
-}
-
-@Override
-public Model getRawModel( Path p )
-{
-return modelPool.get( p );
-}
-
-@Override
-public Model getRawModel( String groupId, String artifactId )
-{
-return modelPool.get( groupId, artifactId, null );
-}
-};
-request.getRepositorySession().getData().set( 
TransformerContext.KEY, context );
-}
-
-InternalConfig config = new InternalConfig( request, modelPool,
-useGlobalModelCache() ? getModelCache() : new 
ReactorModelCache() );
+InternalConfig config =
+new InternalConfig( request, modelPool, useGlobalModelCache() ? 
getModelCache() : new ReactorModelCache(),
+modelBuilder.newTransformerContextBuilder() );
 
-Map projectIndex = new HashMap<>( 256 );
+Map projectIndex = new HashMap<>( 256 );
 
+// phase 1: get file Models from the reactor.
 boolean noErrors =
 build( results, interimResults, projectIndex, pomFiles, new 
LinkedHashSet<>(), true, recursive,
config, poolBuilder );
-
+

Review comment:
   Fixed





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] rfscholte commented on a change in pull request #391: Mng 6957: Support Build Consumer while defining modules in reverse order

[GitBox]

rfscholte commented on a change in pull request #391:
URL: https://github.com/apache/maven/pull/391#discussion_r541998823



##
File path: 
maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuilder.java
##
@@ -263,21 +264,14 @@ private DependencyResolutionResult resolveDependencies( 
MavenProject project, Re
 
 private List getProfileIds( List profiles )
 {
-List ids = new ArrayList<>( profiles.size() );
-
-for ( Profile profile : profiles )
-{
-ids.add( profile.getId() );
-}
-
-return ids;
+return profiles.stream().map( Profile::getId ).collect( 
Collectors.toList() );
 }
 
 private ModelBuildingRequest getModelBuildingRequest( InternalConfig 
config )
 {
 ProjectBuildingRequest configuration = config.request;
 
-ModelBuildingRequest request = new DefaultModelBuildingRequest();
+DefaultModelBuildingRequest request = new 
DefaultModelBuildingRequest();

Review comment:
   Not anymore, during refactoring there was a period where I needed it. 
Changed it back.





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] (MCOMPILER-445) Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing

[Benjamin Marwell (Jira)]

[ 
https://issues.apache.org/jira/browse/MCOMPILER-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248616#comment-17248616
 ] 

Benjamin Marwell commented on MCOMPILER-445:


It is not just you… 

The compiler (javac) will check javadoc. BUT they moved the logic for this into 
a(nother) module, which is not loaded due to not using forks for compilation.

See list thread here: 
[https://lists.apache.org/thread.html/r026b0d9dc8a678b530e36217993920febd72eb4593d312fa2e7465ec%40%3Cdev.maven.apache.org%3E]

See the actual failing IT here: 
[https://github.com/bmarwell/maven-compiler-plugin/actions/runs/419095393]

> Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing
> ---
>
> Key: MCOMPILER-445
> URL: https://issues.apache.org/jira/browse/MCOMPILER-445
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.8.0, 3.8.1
> Environment: Maven 3.6.3
> Compiler-Plugin 3.8.1
> JDK16 since JDK 16 ea b 18
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
>  Labels: jdk, jdk-javac, jdk16
>
> h2. Issue description
> When compiling with options {{noFork}} and {{-Xdoclint}}, the compiler plugin 
> will fail:
>  
> {quote}{{[INFO] 
> }}
> {{[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile 
> (pre-compile-jute) on project zookeeper-jute: Fatal error compiling: error: 
> invalid flag: -Xdoclint:-missing -> [Help 1]}}
> {{This is Maven debug:}}
> {{[DEBUG] Classpath:}}
> {{[DEBUG] /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes}}
> {{[DEBUG] 
> /home/eolivelli/.m2/repository/org/apache/yetus/audience-annotations/0.5.0/audience-annotations-0.5.0.jar}}
> {{[DEBUG] Source roots:}}
> {{[DEBUG] /home/eolivelli/dev/zookeeper/zookeeper-jute/src/main/java}}
> {{[DEBUG] 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/java}}
> {{[DEBUG] 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations}}
> {{[DEBUG] Command line options:}}
> {{[DEBUG] -d /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes 
> -classpath 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes:/home/eolivelli/.m2/repository/org/apache/yetus/audience-annotations/0.5.0/audience-annotations-0.5.0.jar:
>  -sourcepath 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/src/main/java:/home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/java:/home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations:
>  -s 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations
>  -g --release 8 -encoding UTF-8 -Werror -Xlint:deprecation -Xlint:unchecked 
> -Xlint:-options -Xdoclint:-missing -Xpkginfo:always}}
> {{[DEBUG] incrementalBuildHelper#beforeRebuildExecution}}
> {{[INFO] Compiling 36 source files to 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes}}{quote}
> But -Xdoclint is a valid option.
> h2. Cause
> Without forking, maven runs {{javac}} using 
> {{com.sun.tools.javac.api.JavacTool}}. The module is not loaded.
> h2. Proposed solution
> From the mailing list:
> When running the compiler in noFork mode, use the ToolProvider to run Javac 
> in the same VM on Java9+. This can be implemented using multi-release-jars. 
> See the {{maven-jlink-plugin}} as a reference.
> h2. Related
> [Move Doclint to jdk.javadoc 
> module|https://bugs.openjdk.java.net/browse/JDK-8252712]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MCOMPILER-445) Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MCOMPILER-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248613#comment-17248613
 ] 

Michael Osipov commented on MCOMPILER-445:
--

I am confused how a Javadoc option affects compilation...

> Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing
> ---
>
> Key: MCOMPILER-445
> URL: https://issues.apache.org/jira/browse/MCOMPILER-445
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.8.0, 3.8.1
> Environment: Maven 3.6.3
> Compiler-Plugin 3.8.1
> JDK16 since JDK 16 ea b 18
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
>  Labels: jdk, jdk-javac, jdk16
>
> h2. Issue description
> When compiling with options {{noFork}} and {{-Xdoclint}}, the compiler plugin 
> will fail:
>  
> {quote}{{[INFO] 
> }}
> {{[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile 
> (pre-compile-jute) on project zookeeper-jute: Fatal error compiling: error: 
> invalid flag: -Xdoclint:-missing -> [Help 1]}}
> {{This is Maven debug:}}
> {{[DEBUG] Classpath:}}
> {{[DEBUG] /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes}}
> {{[DEBUG] 
> /home/eolivelli/.m2/repository/org/apache/yetus/audience-annotations/0.5.0/audience-annotations-0.5.0.jar}}
> {{[DEBUG] Source roots:}}
> {{[DEBUG] /home/eolivelli/dev/zookeeper/zookeeper-jute/src/main/java}}
> {{[DEBUG] 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/java}}
> {{[DEBUG] 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations}}
> {{[DEBUG] Command line options:}}
> {{[DEBUG] -d /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes 
> -classpath 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes:/home/eolivelli/.m2/repository/org/apache/yetus/audience-annotations/0.5.0/audience-annotations-0.5.0.jar:
>  -sourcepath 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/src/main/java:/home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/java:/home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations:
>  -s 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations
>  -g --release 8 -encoding UTF-8 -Werror -Xlint:deprecation -Xlint:unchecked 
> -Xlint:-options -Xdoclint:-missing -Xpkginfo:always}}
> {{[DEBUG] incrementalBuildHelper#beforeRebuildExecution}}
> {{[INFO] Compiling 36 source files to 
> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes}}{quote}
> But -Xdoclint is a valid option.
> h2. Cause
> Without forking, maven runs {{javac}} using 
> {{com.sun.tools.javac.api.JavacTool}}. The module is not loaded.
> h2. Proposed solution
> From the mailing list:
> When running the compiler in noFork mode, use the ToolProvider to run Javac 
> in the same VM on Java9+. This can be implemented using multi-release-jars. 
> See the {{maven-jlink-plugin}} as a reference.
> h2. Related
> [Move Doclint to jdk.javadoc 
> module|https://bugs.openjdk.java.net/browse/JDK-8252712]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MCOMPILER-445) Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing

[Benjamin Marwell (Jira)]

Benjamin Marwell created MCOMPILER-445:
--

 Summary: Javac error on jdk16 build 18: invalid flag: 
-Xdoclint:-missing
 Key: MCOMPILER-445
 URL: https://issues.apache.org/jira/browse/MCOMPILER-445
 Project: Maven Compiler Plugin
  Issue Type: Bug
Affects Versions: 3.8.1, 3.8.0
 Environment: Maven 3.6.3
Compiler-Plugin 3.8.1
JDK16 since JDK 16 ea b 18
Reporter: Benjamin Marwell
Assignee: Benjamin Marwell


h2. Issue description

When compiling with options {{noFork}} and {{-Xdoclint}}, the compiler plugin 
will fail:

 
{quote}{{[INFO] 
}}
{{[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (pre-compile-jute) 
on project zookeeper-jute: Fatal error compiling: error: invalid flag: 
-Xdoclint:-missing -> [Help 1]}}

{{This is Maven debug:}}
{{[DEBUG] Classpath:}}
{{[DEBUG] /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes}}
{{[DEBUG] 
/home/eolivelli/.m2/repository/org/apache/yetus/audience-annotations/0.5.0/audience-annotations-0.5.0.jar}}
{{[DEBUG] Source roots:}}
{{[DEBUG] /home/eolivelli/dev/zookeeper/zookeeper-jute/src/main/java}}
{{[DEBUG] 
/home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/java}}
{{[DEBUG] 
/home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations}}
{{[DEBUG] Command line options:}}
{{[DEBUG] -d /home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes 
-classpath 
/home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes:/home/eolivelli/.m2/repository/org/apache/yetus/audience-annotations/0.5.0/audience-annotations-0.5.0.jar:
 -sourcepath 
/home/eolivelli/dev/zookeeper/zookeeper-jute/src/main/java:/home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/java:/home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations:
 -s 
/home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/annotations
 -g --release 8 -encoding UTF-8 -Werror -Xlint:deprecation -Xlint:unchecked 
-Xlint:-options -Xdoclint:-missing -Xpkginfo:always}}
{{[DEBUG] incrementalBuildHelper#beforeRebuildExecution}}
{{[INFO] Compiling 36 source files to 
/home/eolivelli/dev/zookeeper/zookeeper-jute/target/classes}}{quote}
But -Xdoclint is a valid option.
h2. Cause

Without forking, maven runs {{javac}} using 
{{com.sun.tools.javac.api.JavacTool}}. The module is not loaded.
h2. Proposed solution

>From the mailing list:

When running the compiler in noFork mode, use the ToolProvider to run Javac in 
the same VM on Java9+. This can be implemented using multi-release-jars. See 
the {{maven-jlink-plugin}} as a reference.
h2. Related

[Move Doclint to jdk.javadoc 
module|https://bugs.openjdk.java.net/browse/JDK-8252712]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-7034) StackOverflowError thrown if a cycle exists in BOM imports

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248595#comment-17248595
 ] 

Hudson commented on MNG-7034:
-

Build succeeded in Jenkins: Maven » Maven TLP » maven » master #68

See 
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/68/

> StackOverflowError thrown if a cycle exists in BOM imports
> --
>
> Key: MNG-7034
> URL: https://issues.apache.org/jira/browse/MNG-7034
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.1.0
>Reporter: Guillaume Nodet
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven] michael-o commented on a change in pull request #391: Mng 6957: Support Build Consumer while defining modules in reverse order

[GitBox]

michael-o commented on a change in pull request #391:
URL: https://github.com/apache/maven/pull/391#discussion_r541933983



##
File path: 
maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuilder.java
##
@@ -263,21 +264,14 @@ private DependencyResolutionResult resolveDependencies( 
MavenProject project, Re
 
 private List getProfileIds( List profiles )
 {
-List ids = new ArrayList<>( profiles.size() );
-
-for ( Profile profile : profiles )
-{
-ids.add( profile.getId() );
-}
-
-return ids;
+return profiles.stream().map( Profile::getId ).collect( 
Collectors.toList() );
 }
 
 private ModelBuildingRequest getModelBuildingRequest( InternalConfig 
config )
 {
 ProjectBuildingRequest configuration = config.request;
 
-ModelBuildingRequest request = new DefaultModelBuildingRequest();
+DefaultModelBuildingRequest request = new 
DefaultModelBuildingRequest();

Review comment:
   This change is necessary to pass the builder?

##
File path: 
maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuilder.java
##
@@ -386,44 +381,22 @@ private ModelSource createStubModelSource( Artifact 
artifact )
 ReactorModelPool.Builder poolBuilder = new ReactorModelPool.Builder();
 final ReactorModelPool modelPool = poolBuilder.build();
 
-if ( Features.buildConsumer().isActive() )
-{
-final TransformerContext context = new TransformerContext()
-{
-@Override
-public String getUserProperty( String key )
-{
-return request.getUserProperties().getProperty( key );
-}
-
-@Override
-public Model getRawModel( Path p )
-{
-return modelPool.get( p );
-}
-
-@Override
-public Model getRawModel( String groupId, String artifactId )
-{
-return modelPool.get( groupId, artifactId, null );
-}
-};
-request.getRepositorySession().getData().set( 
TransformerContext.KEY, context );
-}
-
-InternalConfig config = new InternalConfig( request, modelPool,
-useGlobalModelCache() ? getModelCache() : new 
ReactorModelCache() );
+InternalConfig config =
+new InternalConfig( request, modelPool, useGlobalModelCache() ? 
getModelCache() : new ReactorModelCache(),
+modelBuilder.newTransformerContextBuilder() );
 
-Map projectIndex = new HashMap<>( 256 );
+Map projectIndex = new HashMap<>( 256 );
 
+// phase 1: get file Models from the reactor.
 boolean noErrors =
 build( results, interimResults, projectIndex, pomFiles, new 
LinkedHashSet<>(), true, recursive,
config, poolBuilder );
-
+
 ClassLoader oldContextClassLoader = 
Thread.currentThread().getContextClassLoader();
 
 try
 {
+// Phase 2: get effective from the reactor

Review comment:
   get effective what?

##
File path: 
maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuilder.java
##
@@ -640,12 +605,12 @@ private boolean build( List 
results, List
 }
 
 private boolean build( List results, 
List projects,
-   Map projectIndex, 
List interimResults,
+   Map projectIndex, 
List interimResults,
ProjectBuildingRequest request, Map 
profilesXmls,
RepositorySystemSession session )
 {
 boolean noErrors = true;
-
+

Review comment:
   Trailing WS

##
File path: 
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
##
@@ -1707,4 +1786,131 @@ protected void mergePluginContainer_Plugins( 
PluginContainer target, PluginConta
 // don't merge
 }
 }
+
+/**
+ * Builds up the transformer context.
+ * After the buildplan is ready, the build()-method returns the immutable 
context useful during distribution.
+ * This is an inner class, as it must be able to call readRawModel() 
+ * 
+ * @author Robert Scholte
+ * @since 3.7.0
+ */
+private class DefaultTransformerContextBuilder implements 
TransformerContextBuilder
+{
+private final DefaultTransformerContext context = new 
DefaultTransformerContext();
+
+private final Map> 
mappedSources
+= new ConcurrentHashMap<>( 64 );
+
+/**
+ * If an interface could be extracted, DefaultModelProblemCollector 
should be ModelProblemCollectorExt
+ * 
+ * @param request
+ * @param collector
+ * @return
+ */
+@Override
+ 

[jira] [Closed] (MNG-7034) StackOverflowError thrown if a cycle exists in BOM imports

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-7034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MNG-7034.
---
Fix Version/s: (was: 4.0.x-candidate)
   4.0.0-alpha-1
   4.0.0
   Resolution: Fixed

Fixed with 
[be8ced6be3e9758a2373a8b62647329a2110151f|https://gitbox.apache.org/repos/asf?p=maven.git=commit=be8ced6be3e9758a2373a8b62647329a2110151f].

> StackOverflowError thrown if a cycle exists in BOM imports
> --
>
> Key: MNG-7034
> URL: https://issues.apache.org/jira/browse/MNG-7034
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.1.0
>Reporter: Guillaume Nodet
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven] asfgit closed pull request #399: [MNG-7034] StackOverflowError thrown if a cycle exists in BOM imports

[GitBox]

asfgit closed pull request #399:
URL: https://github.com/apache/maven/pull/399


   



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] michael-o removed a comment on pull request #399: [MNG-7034] StackOverflowError thrown if a cycle exists in BOM imports

[GitBox]

michael-o removed a comment on pull request #399:
URL: https://github.com/apache/maven/pull/399#issuecomment-744010593


   This changes causes:
   ```
   [ERROR] Failures:
   [ERROR]   
MavenITmng3819PluginDepPlexusUtilsTest>AbstractMavenIntegrationTestCase.runTest:255->testitMNG3819:62
   [ERROR]   
MavenITmng3843PomInheritanceTest>AbstractMavenIntegrationTestCase.runTest:255->testitMNG3843:105
 expected:<[1]> but was:<[2]>
   [ERROR]   
MavenITmng4262MakeLikeReactorDottedPathTest>AbstractMavenIntegrationTestCase.runTest:255->testitMakeRoot:67
 Unwanted file was found: 
/var/osipovmi/Projekte/mit/core-it-suite/target/test-classes/mng-4262/parent/../sub-a/target/touch.txt
   [ERROR]   
MavenITmng5783PluginDependencyFiltering>AbstractMavenIntegrationTestCase.runTest:255->testSLF4j:36
 expected:<3> but was:<2>
   ```
   
   I haven't looked into yet, but that doesn't look good. Could also be fallout 
from crappy ITs.



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] michael-o commented on pull request #399: [MNG-7034] StackOverflowError thrown if a cycle exists in BOM imports

[GitBox]

michael-o commented on pull request #399:
URL: https://github.com/apache/maven/pull/399#issuecomment-744010593


   This changes causes:
   ```
   [ERROR] Failures:
   [ERROR]   
MavenITmng3819PluginDepPlexusUtilsTest>AbstractMavenIntegrationTestCase.runTest:255->testitMNG3819:62
   [ERROR]   
MavenITmng3843PomInheritanceTest>AbstractMavenIntegrationTestCase.runTest:255->testitMNG3843:105
 expected:<[1]> but was:<[2]>
   [ERROR]   
MavenITmng4262MakeLikeReactorDottedPathTest>AbstractMavenIntegrationTestCase.runTest:255->testitMakeRoot:67
 Unwanted file was found: 
/var/osipovmi/Projekte/mit/core-it-suite/target/test-classes/mng-4262/parent/../sub-a/target/touch.txt
   [ERROR]   
MavenITmng5783PluginDependencyFiltering>AbstractMavenIntegrationTestCase.runTest:255->testSLF4j:36
 expected:<3> but was:<2>
   ```
   
   I haven't looked into yet, but that doesn't look good. Could also be fallout 
from crappy ITs.



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] (MNG-6928) CREATE: Call to Action design card

[Robert Scholte (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248579#comment-17248579
 ] 

Robert Scholte commented on MNG-6928:
-

Based on the release of the first set, there are requests via Twitter for:
- I'm a happy Maven user
- I maintain Maven plugins
- I'm a Maven committer
- ...

> CREATE: Call to Action design card
> --
>
> Key: MNG-6928
> URL: https://issues.apache.org/jira/browse/MNG-6928
> Project: Maven
>  Issue Type: New Feature
>Reporter: Amelia Eiras
>Priority: Major
> Attachments: Maven-SM-Content-aug14.png, Maven-SM-Content-aug14.png, 
> Maven-SM-Content.png, Maven-SM-ContentContributor.png, 
> Maven-SM-ContentContributor.png, Maven-SM-ContentContributor.png, 
> Maven-SM-Contributor-aug14.png, Maven-SM-Contributor-aug14.png, 
> Maven-SM-Contributor-aug14.png, Maven-SM-Contributor.png, 
> Maven-SM-Contributor.png, Maven-SM-User.png, Maven-SM-User.png, 
> Maven-SM-User.png, Maven-SM-User.png, Maven-SM-User.png, Maven-SM-User.png, 
> Maven-SM-User.png, actioncards.PNG, image-2020-08-11-19-04-07-654.png, 
> image-2020-08-11-19-04-07-776.png, image-2020-08-11-19-04-08-038.png, 
> image-2020-08-11-19-06-16-333.png, image-2020-08-11-19-06-16-469.png, 
> image-2020-08-11-19-06-16-615.png, image-2020-08-11-19-06-44-982.png, 
> image-2020-08-19-20-31-22-486.png, image-2020-08-19-20-31-22-642.png, 
> image-2020-08-19-20-31-22-931.png, image-2020-08-19-20-31-23-087.png
>
>
> general call out as Maven benefits for diverse contributions that are not 
> solely focused on code. 
> [Maven 
> Logos|https://drive.google.com/drive/folders/1oKAnZAlvUlck9XgNGUkr6UGgzEguY8n3?usp=sharing]
> Tomitribe will create the drafts. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (MNG-7044) Allow use of attributes in Maven pom.xml

[Robert Scholte (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte closed MNG-7044.
---
  Assignee: Robert Scholte
Resolution: Won't Fix

> Allow use of attributes in Maven pom.xml
> 
>
> Key: MNG-7044
> URL: https://issues.apache.org/jira/browse/MNG-7044
> Project: Maven
>  Issue Type: New Feature
>  Components: core, POM
>Reporter: Will Iverson
>Assignee: Robert Scholte
>Priority: Minor
>  Labels: features
>
> Proposal: The current pom.xml file is very verbose due to the exclusive use 
> of XML elements. This makes even simple declarations such as dependencies 
> unnecessarily verbose.
> I would propose that a future version of Maven allow for the use of 
> attributes as an alternative declaration for pom.xml configuration. This 
> would only affect how Maven ingests project files - for consistency and 
> backward compatibility all generated pom.xml files would continue to be 
> element based.
> Projects that declared a conflicting/duplicate attribute/element pairing 
> would be considered to be malformed, and would result in a built break.
> By way of example of the benefit of this proposal, this declaration would be 
> reduced from:
> 
>      commons-cli
>      commons-cli
>      1.4
> 
> ...to...
> 
> This would allow many Maven projects to *dramatically* decrease the total 
> line count, which is one of the frequent criticisms of Maven compared with 
> other build tools.
> If there is interest, I would be happy to help support this. My 
> hope/expectation is that the changes required to support this in Maven itself 
> would be quite minor - simply adding a bit of additional logic to look for 
> attributes in the XML parse and error reporting in the event of a duplication 
> (as well as supporting test cases). That said, I don't want to send in 
> patches for a change like this that would be dead on arrival.
> This would, of course, represent a potentially large impact on the user and 
> tooling space (in particular, IDEs that integrate Maven support). As the 
> emitted files for resolved pom.xml files (those that are published in repos) 
> would remain the same, hopefully the overall impacts would be manageable.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-7052) Do not allow symbols as first character of identifiers in the POM

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248560#comment-17248560
 ] 

Michael Osipov commented on MNG-7052:
-

I think this should also apply to elements in the settings, but should require 
a separate ticket.

> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Reporter: Martin Kanters
>Priority: Major
>  Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against 
> {{a-zA-Z0-9-_.}} 
> Since Maven also allows operators to be used against an identifier, this can 
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example 
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn  -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character 
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of 
> those symbols.
> This should apply to all identifiers that we support. The methods that need 
> attention are:
> {{DefaultModelValidator#validateId}} and 
> {{DefaultModelValidator#validateIdWithWildcards}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-7052) Do not allow symbols as first character of identifiers in the POM

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248559#comment-17248559
 ] 

Michael Osipov commented on MNG-7052:
-

I think this should also apply to elements in the settings, but should require 
a separate ticket.

> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Reporter: Martin Kanters
>Priority: Major
>  Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against 
> {{a-zA-Z0-9-_.}} 
> Since Maven also allows operators to be used against an identifier, this can 
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example 
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn  -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character 
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of 
> those symbols.
> This should apply to all identifiers that we support. The methods that need 
> attention are:
> {{DefaultModelValidator#validateId}} and 
> {{DefaultModelValidator#validateIdWithWildcards}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MJAR-275) outputTimestamp not applied to module-info; breaks reproducible builds

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MJAR-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248555#comment-17248555
 ] 

Michael Osipov commented on MJAR-275:
-

I have talked to Rory O'Donell, there are two issues:
* Modification of timestamps
* Incorporation of patch JDK version information

> outputTimestamp not applied to module-info; breaks reproducible builds
> --
>
> Key: MJAR-275
> URL: https://issues.apache.org/jira/browse/MJAR-275
> Project: Maven JAR Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.0
> Environment: Mac OS X 10.14.6
> JDK 15 (build 15+36)
> JDK 11 (build 11.0.8+10)
>Reporter: Anand Beh
>Priority: Minor
> Attachments: MCOMPILER-439.zip, Screenshot 2020-10-25 at 2.35.59 
> PM.png
>
>
> Setting {{project.build.outputTimestamp}} to a fixed value allows creating 
> reproducible builds per this guide: 
> [https://maven.apache.org/guides/mini/guide-reproducible-builds.html 
> |https://maven.apache.org/guides/mini/guide-reproducible-builds.html]However, 
> if one adds a module-info file to the project, reproducible builds break.
> This is caused by module-info.class using the latest timestamp and not 
> {{project.build.outputTimestamp}}. I was able to identify the problem using 
> diffoscope: [https://diffoscope.org/.|https://diffoscope.org/] With it I 
> determined the timestamp across 2 builds was constant for all but the 
> module-info.class:
>  
> {code:java}
>   -rw 2.0 fat  862 bl defN 20-Oct-17 00:40 
> space/arim/libertybans/api/select/SelectionOrder.class
> │  -rw 2.0 fat 1113 bl defN 20-Oct-17 00:40 
> space/arim/libertybans/api/select/SelectionOrderBuilder.class
> │  -rw 2.0 fat 2285 bl defN 20-Oct-17 00:40 
> META-INF/maven/space.arim.libertybans/bans-api/pom.xml
> │  -rw 2.0 fat   74 bl defN 20-Oct-17 00:40 
> META-INF/maven/space.arim.libertybans/bans-api/pom.properties
> │ --rw 2.0 fat  557 bl defN 20-Oct-25 12:39 module-info.class
> │ +-rw 2.0 fat  557 bl defN 20-Oct-25 12:41 module-info.class
> {code}
>  
> Note the + and - which are diffoscope's way of indicating the difference 
> between the .jar files. Here the {{project.build.outputTimestamp}} is on 17 
> October. As shown, module-info has a "rebellious" timestamp.
>  
> *EDIT:*
> Example project to reproduce the bug:
> [https://github.com/A248/MJAR-275|https://github.com/A248/MCOMPILER-439] 
> (Renamed from [https://github.com/A248/MCOMPILER-439])
> Source code is also provided as an attachment below



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MDEPLOY-280) Ability so skip certain classifiers from deploy

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MDEPLOY-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248544#comment-17248544
 ] 

Michael Osipov commented on MDEPLOY-280:


This also seems to me like a symptom solution instead of a problem solution...

> Ability so skip certain classifiers from deploy
> ---
>
> Key: MDEPLOY-280
> URL: https://issues.apache.org/jira/browse/MDEPLOY-280
> Project: Maven Deploy Plugin
>  Issue Type: Improvement
>  Components: deploy:deploy
>Reporter: Tamás Cservenák
>Priority: Minor
>
> There are cases when producing and attaching "derivative" artifacts (docker 
> image of main artifact, rpm of same, etc) is needed, but their deploy is not 
> wanted, as they are either used only during ITs, and are "just derivative", 
> or, they are to be deployed in their format specific registries/repositories 
> instead.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-7037) Add JPMS support -> solve split packages problem

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248542#comment-17248542
 ] 

Michael Osipov commented on MNG-7037:
-

Why it is wrong? You use our work and it is perfectly natural to try to give 
back if you can.

> Add JPMS support -> solve split packages problem
> 
>
> Key: MNG-7037
> URL: https://issues.apache.org/jira/browse/MNG-7037
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.6.3
>Reporter: Pavel_K
>Priority: Major
>
> I use apache maven with apache maven resolver in JPMS environment as 
> automatic modules. At least I wanted to use them this way. When I started my 
> application I got
> java.lang.module.ResolutionException: Modules maven.model.builder and 
> maven.model export package org.apache.maven.model.merge to module 
> mymodule.core.
> Please, add JPMS support. 2020 is ending and there are still split packages.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MRESOLVER-151) Switch the default checksum policy from "warn" to "fail"

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248541#comment-17248541
 ] 

Michael Osipov commented on MRESOLVER-151:
--

Yes, that is correct. I haven't thought about this at all. I will modify the 
issue or spawn a new one accordingly.

> Switch the default checksum policy from "warn" to "fail"
> 
>
> Key: MRESOLVER-151
> URL: https://issues.apache.org/jira/browse/MRESOLVER-151
> Project: Maven Resolver
>  Issue Type: Task
>  Components: Resolver
>Affects Versions: 1.6.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.7.0
>
>
> This mirrors MNG-5728. The change has to happen in 
> {{DefaultChecksumPolicyProvider}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml

[Alexander Kriegisch (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248527#comment-17248527
 ] 

Alexander Kriegisch edited comment on MRELEASE-899 at 12/13/20, 8:14 AM:
-

As for explanting the code from IDEA, that would be a bit difficult because the 
class has many dependencies and this statement applies recursively. What the 
code basically does, though, is to count all the different types of line breaks 
CR, LF and CRLF and return the one with the highest count in the file. Doing 
all this, it also takes care of encoding issues, BOM headers in XML files etc., 
so it is quite sophisticated. But a simple version might be easy to reimplement.

Anyway, I do not like the approach much and had the idea to modify Maven 
Release in such a way that, if a certain new option 
{{preserveOriginalLineBreaks}} is specified, instead of normalising line 
endings while reading the XML file and writing back with a uniform line ending, 
it could encode all line endings as XML entities {{}}{{;}} and 
{{}}{{;}} and just write them back out in a decoded way after POM 
modification. What do you think about that? It would even preserve a file with 
mixed line endings and would eliminate the need to detect the most common line 
ending type via statistics.


was (Author: kriegaex):
As for explanting the code from IDEA, that would be a bit difficult because the 
class has many dependencies and this statement applies recursively. What the 
code basically does, though, is to count all the different types of line breaks 
CR, LF and CRLF and return the one with the highest count in the file. Doing 
all this, it also takes care of encoding issues, BOM headers in XML files etc., 
so it is quite sophisticated. But a simple version might be easy to reimplement.

Anyway, I do not like the approach much and had the idea to modify Maven 
Release in such a way that, if a certain new option 
{{preserveOriginalLineBreaks}} is specified, instead of normalising line 
endings while reading the XML file and writing back with a uniform line ending, 
it could encode all line endings as XML entities {{ ;}} and {{ ;}} and 
just write them back out in a decoded way after POM modification. What do you 
think about that? It would even preserve a file with mixed line endings and 
would eliminate the need to detect the most common line ending type via 
statistics.

> release:prepare should not change the line separator but detect effective 
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
>  Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it 
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is 
> released sometimes under Windows and sometimes under Linux (because of its 
> different line separators). 
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the 
> systems line separator but the line separator that is already used in the 
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm 
> someone else.
> Therefore it would be an great feature when there would be an property that 
> define the expected behaviour, maybe in the same way it is done by the 
> maven-assembly-plugin's property fileSet.lineEnding 
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml

[Alexander Kriegisch (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248527#comment-17248527
 ] 

Alexander Kriegisch edited comment on MRELEASE-899 at 12/13/20, 8:13 AM:
-

As for explanting the code from IDEA, that would be a bit difficult because the 
class has many dependencies and this statement applies recursively. What the 
code basically does, though, is to count all the different types of line breaks 
CR, LF and CRLF and return the one with the highest count in the file. Doing 
all this, it also takes care of encoding issues, BOM headers in XML files etc., 
so it is quite sophisticated. But a simple version might be easy to reimplement.

Anyway, I do not like the approach much and had the idea to modify Maven 
Release in such a way that, if a certain new option 
{{preserveOriginalLineBreaks}} is specified, instead of normalising line 
endings while reading the XML file and writing back with a uniform line ending, 
it could encode all line endings as XML entities {{ ;}} and {{ ;}} and 
just write them back out in a decoded way after POM modification. What do you 
think about that? It would even preserve a file with mixed line endings and 
would eliminate the need to detect the most common line ending type via 
statistics.


was (Author: kriegaex):
As for explanting the code from IDEA, that would be a bit difficult because the 
class has many dependencies and this statement applies recursively. What the 
code basically does, though, is to count all the different types of line breaks 
CR, LF and CRLF and return the one with the highest count in the file. Doing 
all this, it also takes care of encoding issues, BOM headers in XML files etc., 
so it is quite sophisticated. But a simple version might be easy to reimplement.

Anyway, I do not like the approach much and had the idea to modify Maven 
Release in such a way that, if a certain new option 
{{preserveOriginalLineBreaks}} is specified, instead of normalising line 
endings while reading the XML file and writing back with a uniform line ending, 
it could encode all line endings as XML entities {{}} and {{}} and 
just write them back out in a decoded way after POM modification. What do you 
think about that? It would even preserve a file with mixed line endings and 
would eliminate the need to detect the most common line ending type via 
statistics.

> release:prepare should not change the line separator but detect effective 
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
>  Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it 
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is 
> released sometimes under Windows and sometimes under Linux (because of its 
> different line separators). 
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the 
> systems line separator but the line separator that is already used in the 
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm 
> someone else.
> Therefore it would be an great feature when there would be an property that 
> define the expected behaviour, maybe in the same way it is done by the 
> maven-assembly-plugin's property fileSet.lineEnding 
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml

[Alexander Kriegisch (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248528#comment-17248528
 ] 

Alexander Kriegisch edited comment on MRELEASE-899 at 12/13/20, 8:09 AM:
-

Another finding alleviating the pain of this problem is that when using the 
more recent combination of
 * Maven Release Plugin from 2.5.2 to 3.0.0-M1,
 * Maven SCM Provider JGit from 1.9.4 to 1.11.2,
 * JGit from 3.7.1.201504261725-r to 5.10.0.202012080955-r,

the problem I personally had with Git for Windows and my setting "check out as 
is, commit Unix line endings" disappears because newer JGit versions can read 
global system settings of Git for Windows correctly, which previously it failed 
to do, hence not honouring them and committing the wrong way, causing full file 
diffs. See also [this comment for Git for Windows issue 
#337|https://github.com/git-for-windows/git/issues/337#issuecomment-743970276].

In other constellations, e.g. "check in + out as is", this would still not work 
and the solution I just mentioned above about conserving existing line endings 
would help.


was (Author: kriegaex):
Another finding alleviating the pain of this problem is that when using the 
more recent combination of
 * Maven Release Plugin from 2.5.2 to 3.0.0-M1,
 * Maven SCM Provider JGit from 1.9.4 to 1.11.2,
 * JGit from 3.7.1.201504261725-r to 5.10.0.202012080955-r,

the problem I personally had with Git for Windows and my setting "check out as 
is, commit Unix line endings" disappears because newer JGit versions can read 
global system settings of Git for Windows correctly, which previously it failed 
to do, hence not honouring them and committing the wrong way, causing full file 
diffs.

In other constellations, e.g. "check in + out as is", this would still not work 
and the solution I just mentioned above about conserving existing line endings 
would help.

> release:prepare should not change the line separator but detect effective 
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
>  Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it 
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is 
> released sometimes under Windows and sometimes under Linux (because of its 
> different line separators). 
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the 
> systems line separator but the line separator that is already used in the 
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm 
> someone else.
> Therefore it would be an great feature when there would be an property that 
> define the expected behaviour, maybe in the same way it is done by the 
> maven-assembly-plugin's property fileSet.lineEnding 
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml

[Alexander Kriegisch (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248528#comment-17248528
 ] 

Alexander Kriegisch commented on MRELEASE-899:
--

Another finding alleviating the pain of this problem is that when using the 
more recent combination of
 * Maven Release Plugin from 2.5.2 to 3.0.0-M1,
 * Maven SCM Provider JGit from 1.9.4 to 1.11.2,
 * JGit from 3.7.1.201504261725-r to 5.10.0.202012080955-r,

the problem I personally had with Git for Windows and my setting "check out as 
is, commit Unix line endings" disappears because newer JGit versions can read 
global system settings of Git for Windows correctly, which previously it failed 
to do, hence not honouring them and committing the wrong way, causing full file 
diffs.

In other constellations, e.g. "check in + out as is", this would still not work 
and the solution I just mentioned above about conserving existing line endings 
would help.

> release:prepare should not change the line separator but detect effective 
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
>  Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it 
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is 
> released sometimes under Windows and sometimes under Linux (because of its 
> different line separators). 
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the 
> systems line separator but the line separator that is already used in the 
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm 
> someone else.
> Therefore it would be an great feature when there would be an property that 
> define the expected behaviour, maybe in the same way it is done by the 
> maven-assembly-plugin's property fileSet.lineEnding 
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml

[Alexander Kriegisch (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248527#comment-17248527
 ] 

Alexander Kriegisch edited comment on MRELEASE-899 at 12/13/20, 8:04 AM:
-

As for explanting the code from IDEA, that would be a bit difficult because the 
class has many dependencies and this statement applies recursively. What the 
code basically does, though, is to count all the different types of line breaks 
CR, LF and CRLF and return the one with the highest count in the file. Doing 
all this, it also takes care of encoding issues, BOM headers in XML files etc., 
so it is quite sophisticated. But a simple version might be easy to reimplement.

Anyway, I do not like the approach much and had the idea to modify Maven 
Release in such a way that, if a certain new option 
{{preserveOriginalLineBreaks}} is specified, instead of normalising line 
endings while reading the XML file and writing back with a uniform line ending, 
it could encode all line endings as XML entities {{}} and {{}} and 
just write them back out in a decoded way after POM modification. What do you 
think about that? It would even preserve a file with mixed line endings and 
would eliminate the need to detect the most common line ending type via 
statistics.


was (Author: kriegaex):
As for explanting the code from IDEA, that would be a bit difficult because the 
class has many dependencies and this statement applies recursively. What the 
code basically does, though, is to count all the different types of line breaks 
CR, LF and CRLF and return the one with the highest count in the file. Doing 
all this, it also takes care of encoding issues, BOM headers in XML files etc., 
so it is quite sophisticated. But a simple version might be easy to reimplement.

Anyway, I do not like the approach much and had the idea to modify Maven 
Release in such a way that, if a certain new option 
`preserveOriginalLineBreaks` is specified, instead of normalising line endings 
while reading the XML file and writing back with a uniform line ending, it 
could encode all line endings as XML entities `` and `""` and just 
write them back out in a decoded way after POM modification. What do you think 
about that? It would even preserve a file with mixed line endings and would 
eliminate the need to detect the most common line ending type via statistics.

> release:prepare should not change the line separator but detect effective 
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
>  Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it 
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is 
> released sometimes under Windows and sometimes under Linux (because of its 
> different line separators). 
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the 
> systems line separator but the line separator that is already used in the 
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm 
> someone else.
> Therefore it would be an great feature when there would be an property that 
> define the expected behaviour, maybe in the same way it is done by the 
> maven-assembly-plugin's property fileSet.lineEnding 
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml

[Alexander Kriegisch (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248527#comment-17248527
 ] 

Alexander Kriegisch commented on MRELEASE-899:
--

As for explanting the code from IDEA, that would be a bit difficult because the 
class has many dependencies and this statement applies recursively. What the 
code basically does, though, is to count all the different types of line breaks 
CR, LF and CRLF and return the one with the highest count in the file. Doing 
all this, it also takes care of encoding issues, BOM headers in XML files etc., 
so it is quite sophisticated. But a simple version might be easy to reimplement.

Anyway, I do not like the approach much and had the idea to modify Maven 
Release in such a way that, if a certain new option 
`preserveOriginalLineBreaks` is specified, instead of normalising line endings 
while reading the XML file and writing back with a uniform line ending, it 
could encode all line endings as XML entities `` and `""` and just 
write them back out in a decoded way after POM modification. What do you think 
about that? It would even preserve a file with mixed line endings and would 
eliminate the need to detect the most common line ending type via statistics.

> release:prepare should not change the line separator but detect effective 
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
>  Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it 
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is 
> released sometimes under Windows and sometimes under Linux (because of its 
> different line separators). 
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the 
> systems line separator but the line separator that is already used in the 
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm 
> someone else.
> Therefore it would be an great feature when there would be an property that 
> define the expected behaviour, maybe in the same way it is done by the 
> maven-assembly-plugin's property fileSet.lineEnding 
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)