[jira] [Created] (MPLUGIN-362) maven-jar-plugin Network Defect
Thomas Campbell created MPLUGIN-362: --- Summary: maven-jar-plugin Network Defect Key: MPLUGIN-362 URL: https://issues.apache.org/jira/browse/MPLUGIN-362 Project: Maven Plugin Tools Issue Type: Bug Components: Plugin Plugin Affects Versions: 3.2 Environment: Windows 10 mounting a WSL 2 Unbuntu File Share Reporter: Thomas Campbell Executing of Maven Goal such as "mvn install" gives the following error when Error assembling JAR: Failed to determine inclusion status for: : When : is a network mounted drive. This specifically happens when the "mounted" drive is a WSL 2 mounted drive. Windows mounts the drive and when the command is executed the error occurs. This does NOT happen for Version 2.5 of maven-jar-plugin. This is apparently known in the deep recesses of the internet. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1809) Differences between Oracle JDK and AdoptOpenJDK caused by JPMS
[
https://issues.apache.org/jira/browse/SUREFIRE-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148245#comment-17148245
]
Tibor Digana commented on SUREFIRE-1809:
I've got this error but i guess you expect another one.
{noformat}
[ERROR] Failures:
[ERROR] PathFilterTest.pathFilter:76 expected: but was:
[ERROR] PathFilterTest.scanClassNames:123 array lengths differ, expected: <3>
but was: <0>
[INFO]
[ERROR] Tests run: 13, Failures: 2, Errors: 0, Skipped: 0
{noformat}
> Differences between Oracle JDK and AdoptOpenJDK caused by JPMS
> --
>
> Key: SUREFIRE-1809
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1809
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Jiri Ondrusek
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> I was upgrading maven-surefire-plugin to 3.0.0-M5 in
> [camel-quarkus|[https://github.com/apache/camel-quarkus]] project.
> Unfortunately there was a test which was failing on CI (using AdoptOpenJDK
> build 11.0.7+10) and there was no failure on my local machine (using Oracle
> "11.0.7" 2020-04-14 LTS).
> Problem was caused by JPMS. On Orace JDK this was turned off by default. On
> AdoptOpenJDK it was turned on by default. Solution was to turn this feature
> off by configuration (https://github.com/apache/camel-quarkus/pull/1383).
> It would be nice if default behavior was the same for different Java vendors.
> Difference seems to be coming from this line -
> https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1423
> On AdoptOpenJDK both 3 clausules are true. On Oracle JDK the last one is
> false.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-dependency-analyzer] johnlinp commented on pull request #7: [MDEP-679] mvn dependency:analyze detected wrong transitive dependency
johnlinp commented on pull request #7: URL: https://github.com/apache/maven-dependency-analyzer/pull/7#issuecomment-651443282 Hi @khmarbaise & @rfscholte, Would you please review my PR? Thank you. 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] (MDEP-645) List classes in a given artifact
[
https://issues.apache.org/jira/browse/MDEP-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148224#comment-17148224
]
John Lin commented on MDEP-645:
---
It looks very promising and satisfying. Thank you all for the effort!
> List classes in a given artifact
>
>
> Key: MDEP-645
> URL: https://issues.apache.org/jira/browse/MDEP-645
> Project: Maven Dependency Plugin
> Issue Type: New Feature
>Reporter: John Lin
>Assignee: Elliotte Rusty Harold
>Priority: Minor
> Labels: intern
>
> When I want to list all the classes in a given artifact, I have to use
> {{jar}} command to show files in the corresponding .jar file.
> For example, I want to list all the classes in the artifact
> {code}
> org.apache.commons:commons-lang3:3.6
> {code}
> I have to run
> {code}
> jar tf
> ~/.m2/repository/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar
> {code}
> This method has some disadvantages:
> # The jar file may not be downloaded, so it may not be in
> {{~/.m2/repository}}.
> # It's kind of tedious to type such a long filename.
> # The output is shown in raw filenames, e.g.,
> {{org/apache/commons/lang3/SystemUtils.class}}, but I generally want a
> package + class name {{org.apache.commons.lang3.SystemUtils}}.
> So I would expect a goal called {{show}} with an argument {{artifact}}, so I
> can type
> {code}
> mvn dependency:show -Dartifact=org.apache.commons:commons-lang3:3.6
> {code}
> to show
> {code}
> org.apache.commons.lang3.CharUtils
> org.apache.commons.lang3.RandomStringUtils
> ...
> {code}
> What do you guys think? Thanks.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-321) Always respect 'createDependencyReducedPom' flag
[
https://issues.apache.org/jira/browse/MSHADE-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148159#comment-17148159
]
Hudson commented on MSHADE-321:
---
Build succeeded in Jenkins: Maven TLP » maven-shade-plugin » master #104
See
https://builds.apache.org/job/maven-box/job/maven-shade-plugin/job/master/104/
> Always respect 'createDependencyReducedPom' flag
>
>
> Key: MSHADE-321
> URL: https://issues.apache.org/jira/browse/MSHADE-321
> Project: Maven Shade Plugin
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Ilya Cherkasov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.3.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3.
> Dependency reduced pom (DRP) is generated only if resulting shaded artifact
> was 'renamed'
> https://github.com/apache/maven-shade-plugin/blob/dbd2a5c04619da76559c61c58755e7062fb8fab9/src/main/java/org/apache/maven/plugins/shade/mojo/ShadeMojo.java#L536
> However, the documentation regarding DRP states:
> {code:java}
> Flag whether to generate a simplified POM for the shaded artifact. If set to
> true, dependencies that have been included into the uber JAR will be removed
> from the section of the generated POM. The reduced POM will be
> named dependency-reduced-pom.xml and is stored into the same directory as the
> shaded artifact. Unless you also specify dependencyReducedPomLocation, the
> plugin will create a temporary file named dependency-reduced-pom.xml in the
> project basedir.
> Default value is: true.{code}
> It's not stating any changes in this flag behavior, by this hiding the
> conditions upon which DRP would be generated.
> This should be fixed, and DRP should be generated whenever the flag is being
> set to 'true'
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MSHADE-321) Always respect 'createDependencyReducedPom' flag
[
https://issues.apache.org/jira/browse/MSHADE-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MSHADE-321.
-
Resolution: Fixed
Fixed with
[6ea8543b8b380bd4ebc0e876970957426bb46808|https://gitbox.apache.org/repos/asf?p=maven-shade-plugin.git;a=commit;h=6ea8543b8b380bd4ebc0e876970957426bb46808].
> Always respect 'createDependencyReducedPom' flag
>
>
> Key: MSHADE-321
> URL: https://issues.apache.org/jira/browse/MSHADE-321
> Project: Maven Shade Plugin
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Ilya Cherkasov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.3.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3.
> Dependency reduced pom (DRP) is generated only if resulting shaded artifact
> was 'renamed'
> https://github.com/apache/maven-shade-plugin/blob/dbd2a5c04619da76559c61c58755e7062fb8fab9/src/main/java/org/apache/maven/plugins/shade/mojo/ShadeMojo.java#L536
> However, the documentation regarding DRP states:
> {code:java}
> Flag whether to generate a simplified POM for the shaded artifact. If set to
> true, dependencies that have been included into the uber JAR will be removed
> from the section of the generated POM. The reduced POM will be
> named dependency-reduced-pom.xml and is stored into the same directory as the
> shaded artifact. Unless you also specify dependencyReducedPomLocation, the
> plugin will create a temporary file named dependency-reduced-pom.xml in the
> project basedir.
> Default value is: true.{code}
> It's not stating any changes in this flag behavior, by this hiding the
> conditions upon which DRP would be generated.
> This should be fixed, and DRP should be generated whenever the flag is being
> set to 'true'
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-shade-plugin] asfgit closed pull request #22: [MSHADE-321] - Always respect 'createDependencyReducedPom' flag
asfgit closed pull request #22: URL: https://github.com/apache/maven-shade-plugin/pull/22 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-6948) Repository files should not pass build-filters
[
https://issues.apache.org/jira/browse/MNG-6948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148140#comment-17148140
]
Robert Scholte commented on MNG-6948:
-
The issue is on something that hasn't even been released, so that looks weird
to me. It doesn't add anything to the release notes.
Buyt I agree that having no version at all looks weird too.
> Repository files should not pass build-filters
> --
>
> Key: MNG-6948
> URL: https://issues.apache.org/jira/browse/MNG-6948
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.7.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
>
> When building Models, only reactor poms should go through the build xml
> filters.
> If all poms go through it, there will be an unnecesary resource lost, and it
> might introduce security issues, because not all pomsin the local repository
> seem to be valid.
> One symptom is that once the poms are collected, you might see the following
> line:
> {noformat}ERROR: 'The entity "oslash" was referenced, but not
> declared.'{noformat}
> One of the poms with this issue is the {{org.codehaus.plexus:1.0.5:pom}},
> which contains:
> {code:xml}
>
> Trygve Laugstl
> trygvis
> tryg...@codehaus.org
>
> Developer
>
>
> {code}
> However, the is not registered in the file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-dependency-plugin] pmoerenhout commented on a change in pull request #51: [MDEP-425] List plugin repositories via maven-artifact-transfer.
pmoerenhout commented on a change in pull request #51: URL: https://github.com/apache/maven-dependency-plugin/pull/51#discussion_r447251306 ## File path: src/site/apt/usage.apt.vm ## @@ -688,6 +688,24 @@ mvn dependency:build-classpath -Dmdep.outputFile=cp.txt poms and declared in transitive dependency poms. +* <<>> + + This goal is used to list all the plugin repositories that this build depends upon. It will show plugin repositories defined in your settings, + poms and declared in transitive dependency poms. + + This goal can be executed from the command line: + ++-+ +mvn dependency:list-plugin-repositories ++-+ + + Optionally, in verbose or debug mode it will display the location of the listed plugin repository: Review comment: Changed. 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-6948) Repository files should not pass build-filters
[
https://issues.apache.org/jira/browse/MNG-6948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148136#comment-17148136
]
Hudson commented on MNG-6948:
-
Build succeeded in Jenkins: Maven TLP » maven » master #441
See https://builds.apache.org/job/maven-box/job/maven/job/master/441/
> Repository files should not pass build-filters
> --
>
> Key: MNG-6948
> URL: https://issues.apache.org/jira/browse/MNG-6948
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.7.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
>
> When building Models, only reactor poms should go through the build xml
> filters.
> If all poms go through it, there will be an unnecesary resource lost, and it
> might introduce security issues, because not all pomsin the local repository
> seem to be valid.
> One symptom is that once the poms are collected, you might see the following
> line:
> {noformat}ERROR: 'The entity "oslash" was referenced, but not
> declared.'{noformat}
> One of the poms with this issue is the {{org.codehaus.plexus:1.0.5:pom}},
> which contains:
> {code:xml}
>
> Trygve Laugstl
> trygvis
> tryg...@codehaus.org
>
> Developer
>
>
> {code}
> However, the is not registered in the file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-dependency-plugin] pmoerenhout commented on a change in pull request #51: [MDEP-425] List plugin repositories via maven-artifact-transfer.
pmoerenhout commented on a change in pull request #51:
URL:
https://github.com/apache/maven-dependency-plugin/pull/51#discussion_r447250946
##
File path:
src/main/java/org/apache/maven/plugins/dependency/ListClassesMojo.java
##
@@ -0,0 +1,326 @@
+package org.apache.maven.plugins.dependency;
+
+/*
+ * 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.
+ */
+
+import java.io.IOException;
+import java.util.ArrayList;
+import java.util.Enumeration;
+import java.util.List;
+import java.util.Map;
+import java.util.jar.JarEntry;
+import java.util.jar.JarFile;
+import java.util.regex.Matcher;
+import java.util.regex.Pattern;
+
+import org.apache.maven.artifact.handler.ArtifactHandler;
+import org.apache.maven.artifact.handler.manager.ArtifactHandlerManager;
+import org.apache.maven.artifact.repository.ArtifactRepository;
+import org.apache.maven.artifact.repository.ArtifactRepositoryPolicy;
+import org.apache.maven.artifact.repository.MavenArtifactRepository;
+import org.apache.maven.artifact.repository.layout.ArtifactRepositoryLayout;
+import org.apache.maven.execution.MavenSession;
+import org.apache.maven.plugin.AbstractMojo;
+import org.apache.maven.plugin.MojoExecutionException;
+import org.apache.maven.plugin.MojoFailureException;
+import org.apache.maven.plugins.annotations.Component;
+import org.apache.maven.plugins.annotations.Mojo;
+import org.apache.maven.plugins.annotations.Parameter;
+import org.apache.maven.project.DefaultProjectBuildingRequest;
+import org.apache.maven.project.ProjectBuildingRequest;
+import org.apache.maven.repository.RepositorySystem;
+import org.apache.maven.settings.Settings;
+import org.apache.maven.shared.transfer.artifact.ArtifactCoordinate;
+import org.apache.maven.shared.transfer.artifact.DefaultArtifactCoordinate;
+import org.apache.maven.shared.transfer.artifact.resolve.ArtifactResolver;
+import
org.apache.maven.shared.transfer.artifact.resolve.ArtifactResolverException;
+import org.apache.maven.shared.transfer.artifact.resolve.ArtifactResult;
+import
org.apache.maven.shared.transfer.dependencies.DefaultDependableCoordinate;
+import org.apache.maven.shared.transfer.dependencies.DependableCoordinate;
+import
org.apache.maven.shared.transfer.dependencies.resolve.DependencyResolver;
+import
org.apache.maven.shared.transfer.dependencies.resolve.DependencyResolverException;
+
+
+/**
+ * Retrieves and lists all classes contained in the specified artifact from
the specified remote repositories.
+ */
+@Mojo( name = "list-classes", requiresProject = false, threadSafe = true )
+public class ListClassesMojo
+extends AbstractMojo
+{
+private static final Pattern ALT_REPO_SYNTAX_PATTERN = Pattern.compile(
"(.+)::(.*)::(.+)" );
+
+@Parameter( defaultValue = "${session}", required = true, readonly = true )
+private MavenSession session;
+
+@Component
+private ArtifactResolver artifactResolver;
+
+@Component
+private DependencyResolver dependencyResolver;
+
+@Component
+private ArtifactHandlerManager artifactHandlerManager;
+
+/**
+ * Map that contains the layouts.
+ */
+@Component( role = ArtifactRepositoryLayout.class )
+private Map repositoryLayouts;
+
+/**
+ * The repository system.
+ */
+@Component
+private RepositorySystem repositorySystem;
+
+private DefaultDependableCoordinate coordinate = new
DefaultDependableCoordinate();
+
+/**
+ * The group ID of the artifact to download. Ignored if {@link #artifact}
is used.
+ */
+@Parameter( property = "groupId" )
+private String groupId;
+
+/**
+ * The artifact ID of the artifact to download. Ignored if {@link
#artifact} is used.
+ */
+@Parameter( property = "artifactId" )
+private String artifactId;
+
+/**
+ * The version of the artifact to download. Ignored if {@link #artifact}
is used.
+ */
+@Parameter( property = "version" )
+private String version;
+
+/**
+ * The classifier of the artifact to download. Ignored if {@link
#artifact} is used.
+ *
+ * @since 2.3
+ */
+@Parameter( property = "classifier" )
+private String classifier;
+
+/**
+ * The packaging of the artifact to
[GitHub] [maven-dependency-plugin] pmoerenhout commented on a change in pull request #51: [MDEP-425] List plugin repositories via maven-artifact-transfer.
pmoerenhout commented on a change in pull request #51: URL: https://github.com/apache/maven-dependency-plugin/pull/51#discussion_r447249737 ## File path: src/site/apt/usage.apt.vm ## @@ -688,6 +688,24 @@ mvn dependency:build-classpath -Dmdep.outputFile=cp.txt poms and declared in transitive dependency poms. +* <<>> + + This goal is used to list all the plugin repositories that this build depends upon. It will show plugin repositories defined in your settings, Review comment: Implemented correct English... 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-dependency-plugin] pmoerenhout commented on a change in pull request #51: [MDEP-425] List plugin repositories via maven-artifact-transfer.
pmoerenhout commented on a change in pull request #51:
URL:
https://github.com/apache/maven-dependency-plugin/pull/51#discussion_r447249945
##
File path:
src/main/java/org/apache/maven/plugins/dependency/resolvers/ListPluginRepositoriesMojo.java
##
@@ -0,0 +1,323 @@
+package org.apache.maven.plugins.dependency.resolvers;
+
+/*
+ * 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.
+ */
+
+import java.util.HashSet;
+import java.util.List;
+import java.util.Set;
+
+import org.apache.maven.artifact.Artifact;
+import org.apache.maven.artifact.ArtifactUtils;
+import org.apache.maven.artifact.repository.ArtifactRepository;
+import org.apache.maven.model.Model;
+import org.apache.maven.model.Repository;
+import org.apache.maven.model.building.ModelBuildingRequest;
+import org.apache.maven.plugin.MojoExecutionException;
+import org.apache.maven.plugins.annotations.Component;
+import org.apache.maven.plugins.annotations.Mojo;
+import org.apache.maven.plugins.annotations.Parameter;
+import org.apache.maven.plugins.annotations.ResolutionScope;
+import org.apache.maven.plugins.dependency.AbstractDependencyMojo;
+import org.apache.maven.project.DefaultProjectBuildingRequest;
+import org.apache.maven.project.MavenProject;
+import org.apache.maven.project.ProjectBuilder;
+import org.apache.maven.project.ProjectBuildingRequest;
+import org.apache.maven.settings.Mirror;
+import org.apache.maven.settings.Settings;
+import org.apache.maven.shared.transfer.artifact.ArtifactCoordinate;
+import org.apache.maven.shared.transfer.artifact.DefaultArtifactCoordinate;
+import org.apache.maven.shared.transfer.artifact.resolve.ArtifactResolver;
+
+/**
+ * Goal that resolves all project plugin dependencies and then lists the
repositories used by the build
+ *
+ * @author mailto:pim.moerenh...@gmail.com;>Pim Moerenhout
+ * @since 3.1.2
+ */
+@Mojo( name = "list-plugin-repositories", requiresDependencyResolution =
ResolutionScope.TEST, threadSafe = true )
+public class ListPluginRepositoriesMojo
+extends AbstractDependencyMojo
+{
+/**
+ * Maven Project Builder component.
+*/
+@Component
+private ProjectBuilder projectBuilder;
+
+/**
+ * Component used to resolve artifacts and download their files from
remote repositories.
+ */
+@Component
+private ArtifactResolver artifactResolver;
+
+/**
+ * The system settings for Maven. This is the instance resulting from
+ * merging global and user-level settings files.
+ */
+@Parameter( defaultValue = "${settings}", readonly = true, required = true
)
+private Settings settings;
+
+/**
+ * Plugin repositories used for the project.
+ */
+@Parameter( defaultValue = "${project.pluginArtifactRepositories}",
readonly = true, required = true )
+private List pluginRepositories;
+
+/**
+ * Sets whether the plugin runs in verbose mode. As of plugin version 2.3,
the default value is derived from Maven's
+ * global debug flag (compare command line switch -X).
+ *
+ * @since 3.1.2
+ */
+@Parameter( property = "verbose" )
+private boolean verbose;
+
+/**
+ * Displays a list of the plugin repositories used by this build.
+ *
+ * @throws MojoExecutionException with a message if an error occurs.
+ */
+@Override
+protected void doExecute()
+throws MojoExecutionException
+{
+final List repositories = pluginRepositories;
+final Set artifacts = getProject().getPluginArtifacts();
+
+this.getLog().info( "Plugin repositories used by this build:" );
+for ( ArtifactRepository repo : repositories )
+{
+if ( isVerbose() )
+{
+Set locations = new HashSet();
+for ( Mirror mirror : settings.getMirrors() )
+{
+if ( mirror.getId().equals( repo.getId() )
+&& ( mirror.getUrl().equals( repo.getUrl() ) ) )
+{
+locations.add( "Maven settings (user/global)" );
+}
+}
+
+Artifact projectArtifact = getProject().getArtifact();
+MavenProject project
[GitHub] [maven-dependency-plugin] pmoerenhout commented on a change in pull request #51: [MDEP-425] List plugin repositories via maven-artifact-transfer.
pmoerenhout commented on a change in pull request #51:
URL:
https://github.com/apache/maven-dependency-plugin/pull/51#discussion_r447249359
##
File path:
src/main/java/org/apache/maven/plugins/dependency/AbstractDependencyMojo.java
##
@@ -345,11 +351,25 @@ private void silenceUnarchiver( UnArchiver unArchiver )
* repositories, used to resolve artifacts.
*/
public ProjectBuildingRequest newResolveArtifactProjectBuildingRequest()
+{
+return newProjectBuildingRequest( remoteRepositories );
+}
+
+/**
+ * @return Returns a new ProjectBuildingRequest populated from the current
session and the current project remote
Review comment:
Implemented correct JavaDoc
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] [Assigned] (MSHADE-321) Always respect 'createDependencyReducedPom' flag
[
https://issues.apache.org/jira/browse/MSHADE-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MSHADE-321:
-
Assignee: Michael Osipov
> Always respect 'createDependencyReducedPom' flag
>
>
> Key: MSHADE-321
> URL: https://issues.apache.org/jira/browse/MSHADE-321
> Project: Maven Shade Plugin
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Ilya Cherkasov
>Assignee: Michael Osipov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3.
> Dependency reduced pom (DRP) is generated only if resulting shaded artifact
> was 'renamed'
> https://github.com/apache/maven-shade-plugin/blob/dbd2a5c04619da76559c61c58755e7062fb8fab9/src/main/java/org/apache/maven/plugins/shade/mojo/ShadeMojo.java#L536
> However, the documentation regarding DRP states:
> {code:java}
> Flag whether to generate a simplified POM for the shaded artifact. If set to
> true, dependencies that have been included into the uber JAR will be removed
> from the section of the generated POM. The reduced POM will be
> named dependency-reduced-pom.xml and is stored into the same directory as the
> shaded artifact. Unless you also specify dependencyReducedPomLocation, the
> plugin will create a temporary file named dependency-reduced-pom.xml in the
> project basedir.
> Default value is: true.{code}
> It's not stating any changes in this flag behavior, by this hiding the
> conditions upon which DRP would be generated.
> This should be fixed, and DRP should be generated whenever the flag is being
> set to 'true'
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHADE-321) Always respect 'createDependencyReducedPom' flag
[
https://issues.apache.org/jira/browse/MSHADE-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSHADE-321:
--
Fix Version/s: 3.3.0
> Always respect 'createDependencyReducedPom' flag
>
>
> Key: MSHADE-321
> URL: https://issues.apache.org/jira/browse/MSHADE-321
> Project: Maven Shade Plugin
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Ilya Cherkasov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.3.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3.
> Dependency reduced pom (DRP) is generated only if resulting shaded artifact
> was 'renamed'
> https://github.com/apache/maven-shade-plugin/blob/dbd2a5c04619da76559c61c58755e7062fb8fab9/src/main/java/org/apache/maven/plugins/shade/mojo/ShadeMojo.java#L536
> However, the documentation regarding DRP states:
> {code:java}
> Flag whether to generate a simplified POM for the shaded artifact. If set to
> true, dependencies that have been included into the uber JAR will be removed
> from the section of the generated POM. The reduced POM will be
> named dependency-reduced-pom.xml and is stored into the same directory as the
> shaded artifact. Unless you also specify dependencyReducedPomLocation, the
> plugin will create a temporary file named dependency-reduced-pom.xml in the
> project basedir.
> Default value is: true.{code}
> It's not stating any changes in this flag behavior, by this hiding the
> conditions upon which DRP would be generated.
> This should be fixed, and DRP should be generated whenever the flag is being
> set to 'true'
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MRESOLVER-123) Concurrency issues
[
https://issues.apache.org/jira/browse/MRESOLVER-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148100#comment-17148100
]
Michael Osipov edited comment on MRESOLVER-123 at 6/29/20, 8:30 PM:
Branch MRESOLVER-123 provide a naive solutin to this problem by utilizing a
{{ReentrantReadWriteLock}} which will bascially avoid concurrent writes to the
same local repository. This solution is *not* suited for concurrent access from
multiple Maven instances. It is still open, if this works, to be the default
solution or an extension to be installed separately. Far from ideal, but better
than failing builds.
was (Author: michael-o):
Branch MRESOLVER-123 provide a naive solutin to this problem by utilizing a
{{ReentrantReadWriteLock}} which will bascially avoid concurrent writes to the
same local repository. This solution is *not* suited for concurrent access from
multiple Maven instances. It is still open, if this works, to be the default
solution or an extension to be installed separately.
> Concurrency issues
> --
>
> Key: MRESOLVER-123
> URL: https://issues.apache.org/jira/browse/MRESOLVER-123
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.2
>Reporter: Michael Osipov
>Priority: Critical
>
> This is an umbrella ticket for a long standing issue with Maven Resolver: Our
> concurrency support is mediocre in a way that if two or more threads try to
> download the same file and fail to queue those write actions nicely. The
> problem is that The {{SyncContext}} and the its factory provided by Maven
> Resolver does not employ any locking at all. As layed out in detail in
> MRESOLVER-114 we need striped read write locks on artifacts and its metadata.
> This issue shall track progress on it. Even Takari Concurrent Repository
> extension does not help because it is only intended to synchronize concurrent
> access by multple JVMs and not threads.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6948) Repository files should not pass build-filters
[
https://issues.apache.org/jira/browse/MNG-6948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148119#comment-17148119
]
Michael Osipov commented on MNG-6948:
-
Why is there no fix version on this issue?
> Repository files should not pass build-filters
> --
>
> Key: MNG-6948
> URL: https://issues.apache.org/jira/browse/MNG-6948
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.7.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
>
> When building Models, only reactor poms should go through the build xml
> filters.
> If all poms go through it, there will be an unnecesary resource lost, and it
> might introduce security issues, because not all pomsin the local repository
> seem to be valid.
> One symptom is that once the poms are collected, you might see the following
> line:
> {noformat}ERROR: 'The entity "oslash" was referenced, but not
> declared.'{noformat}
> One of the poms with this issue is the {{org.codehaus.plexus:1.0.5:pom}},
> which contains:
> {code:xml}
>
> Trygve Laugstl
> trygvis
> tryg...@codehaus.org
>
> Developer
>
>
> {code}
> However, the is not registered in the file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-6948) Repository files should not pass build-filters
[
https://issues.apache.org/jira/browse/MNG-6948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-6948.
---
Resolution: Fixed
Fixed in
[65ec04c2363b16d08b760fe7e494b56b347bffee|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=65ec04c2363b16d08b760fe7e494b56b347bffee]
> Repository files should not pass build-filters
> --
>
> Key: MNG-6948
> URL: https://issues.apache.org/jira/browse/MNG-6948
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.7.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
>
> When building Models, only reactor poms should go through the build xml
> filters.
> If all poms go through it, there will be an unnecesary resource lost, and it
> might introduce security issues, because not all pomsin the local repository
> seem to be valid.
> One symptom is that once the poms are collected, you might see the following
> line:
> {noformat}ERROR: 'The entity "oslash" was referenced, but not
> declared.'{noformat}
> One of the poms with this issue is the {{org.codehaus.plexus:1.0.5:pom}},
> which contains:
> {code:xml}
>
> Trygve Laugstl
> trygvis
> tryg...@codehaus.org
>
> Developer
>
>
> {code}
> However, the is not registered in the file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOLVER-123) Concurrency issues
[
https://issues.apache.org/jira/browse/MRESOLVER-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148100#comment-17148100
]
Michael Osipov commented on MRESOLVER-123:
--
Branch MRESOLVER-123 provide a naive solutin to this problem by utilizing a
{{ReentrantReadWriteLock}} which will bascially avoid concurrent writes to the
same local repository. This solution is *not* suited for concurrent access from
multiple Maven instances. It is still open, if this works, to be the default
solution or an extension to be installed separately.
> Concurrency issues
> --
>
> Key: MRESOLVER-123
> URL: https://issues.apache.org/jira/browse/MRESOLVER-123
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.2
>Reporter: Michael Osipov
>Priority: Critical
>
> This is an umbrella ticket for a long standing issue with Maven Resolver: Our
> concurrency support is mediocre in a way that if two or more threads try to
> download the same file and fail to queue those write actions nicely. The
> problem is that The {{SyncContext}} and the its factory provided by Maven
> Resolver does not employ any locking at all. As layed out in detail in
> MRESOLVER-114 we need striped read write locks on artifacts and its metadata.
> This issue shall track progress on it. Even Takari Concurrent Repository
> extension does not help because it is only intended to synchronize concurrent
> access by multple JVMs and not threads.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5315) Artifact resolution sporadically fails in parallel builds
[
https://issues.apache.org/jira/browse/MNG-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148096#comment-17148096
]
Michael Osipov commented on MNG-5315:
-
Please test a new, global locking approach with MRESOLVER-123. It is suited for
concurrent access in *one* VM.
> Artifact resolution sporadically fails in parallel builds
> -
>
> Key: MNG-5315
> URL: https://issues.apache.org/jira/browse/MNG-5315
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.4
>Reporter: Ivan Dubrov
>Priority: Minor
> Attachments: MNG-5315-3.0.x.patch, MNG-5315-3.1.2-SNAPSHOT.patch
>
>
> Artifact resolution can fail during the parallel build if it was downloaded
> during the same session.
> Scenario:
> 1) Delete the whole Maven local repository.
> 2) Run build "mvn compile -T1.5C"
> 3) Build fails (see log extracts below)
> 4) If I run build again, it succeeds.
> It seems like the problem is due to two thread trying to resolve same
> artifact concurrently. This problem never happens once I have all
> dependencies cached in the local repository.
> Extracts from the log output:
> {noformat}Downloading:
> http://nexus/content/repositories/thirdparty/com/googlecode/guava-osgi/guava-osgi/11.0.0/guava-osgi-11.0.0.jar
> 12444/13937 KB ...
> ...
> [DEBUG] Skipped remote update check for commons-cli:commons-cli:jar:1.2,
> already updated during this session.
> [DEBUG] Skipped remote update check for
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0, already updated during this
> session.
> [DEBUG] Skipped remote update check for org.slf4j:slf4j-api:jar:1.6.4,
> already updated during this session.
> [DEBUG] Skipped remote update check for org.slf4j:slf4j-jdk14:jar:1.6.4,
> already updated during this session.
> ...
> [ERROR] Failed to execute goal on project util: Could not resolve
> dependencies for project com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The
> following artifacts could not be resolved: commons-cli:commons-cli:jar:1.2,
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
> org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
> find commons-cli:commons-cli:jar:1.2 in
> http://nexus/content/repositories/thirdparty was cached in the local
> repository, resolution will not be reattempted until the update interval of
> gw.thirdparty has elapsed or updates are forced -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project util: Could not resolve dependencies for project
> com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The following artifacts could not
> be resolved: commons-cli:commons-cli:jar:1.2,
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
> org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
> find commons-cli:commons-cli:jar:1.2 in
> http://nexus/content/repositories/thirdparty was cached in the local
> repository, resolution will not be reattempted until the update interval of
> gw.thirdparty has elapsed or updates are forced
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
> at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by:
[jira] [Commented] (MNG-6604) Intermittent failures while downloading GAVs from Nexus
[
https://issues.apache.org/jira/browse/MNG-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148097#comment-17148097
]
Michael Osipov commented on MNG-6604:
-
Please test a new, global locking approach with MRESOLVER-123. It is suited for
concurrent access in *one* VM.
> Intermittent failures while downloading GAVs from Nexus
> ---
>
> Key: MNG-6604
> URL: https://issues.apache.org/jira/browse/MNG-6604
> Project: Maven
> Issue Type: Bug
> Components: Command Line, Toolchains
>Affects Versions: 3.6.0
> Environment: Nexus OSS 3.15.2-01
> Docker 18.09.2 on Ubuntu 18.04.2 LTS
> Gitlab runner 11.8.0
>Reporter: Ivan Rizzante
>Priority: Major
> Attachments: docker-env.txt, log.txt
>
>
> Hello
> we're running maven 3.6.0 builds in a docker container and we use Nexus OSS
> configured as proxy for Maven Central.
> While running our builds using Gitlab CI, we're experiencing intermittent
> build failures because Maven cannot find artifacts in Nexus which we verified
> they are actually available.
> Error example below:
> {noformat}
> 20744 [main] [ERROR] Failed to execute goal on project EcotransitWSClient:
> Could not resolve dependencies for project
> it.sdb.ecotransit:EcotransitWSClient:jar:7.0.1-SNAPSHOT: Could not transfer
> artifact commons-beanutils:commons-beanutils:jar:1.9.3 from/to nexus
> (http://maven-repo.sdb.it:8081/repository/maven-public/):
> /builds/sdb/webportal/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar.part
> (No such file or directory) -> [Help 1]
> {noformat}
> I attached the full maven build log and our Docker env settings.
> We tried disabling the keep alive and also disabling the connection pooling
> but nothing seems to fix the issue.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOLVER-25) Resume support is broken under high concurrency
[
https://issues.apache.org/jira/browse/MRESOLVER-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148094#comment-17148094
]
Michael Osipov commented on MRESOLVER-25:
-
Please test a new, global locking approach with MRESOLVER-123. It is suited for
concurrent access in *one* VM.
> Resume support is broken under high concurrency
> ---
>
> Key: MRESOLVER-25
> URL: https://issues.apache.org/jira/browse/MRESOLVER-25
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: Maven Artifact Resolver 1.0.3
>Reporter: Roland Illig
>Priority: Major
> Attachments: dependency-list-x.zip, dependency-list.txt,
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local
> Maven repository without taking into account that other threads or processes
> might do the same at the same time.
> To reproduce:
> 1. unpack the attached project
> 2. {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be
> found". This is wrong, since the dependency _can_ be found, it's just not
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOLVER-114) ArtifactNotFoundExceptions when building in parallel
[
https://issues.apache.org/jira/browse/MRESOLVER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148095#comment-17148095
]
Michael Osipov commented on MRESOLVER-114:
--
Please test a new, global locking approach with MRESOLVER-123. It is suited for
concurrent access in *one* VM.
> ArtifactNotFoundExceptions when building in parallel
>
>
> Key: MRESOLVER-114
> URL: https://issues.apache.org/jira/browse/MRESOLVER-114
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.2
>Reporter: Rainer Reich
>Priority: Major
> Attachments: BasicRepositoryConnector.java,
> DefaultArtifactResolver.java, maven-debug-log.txt, mvn-build-120-sorted.txt,
> mvn-build-120.log, mvn-build-134-sorted.txt, mvn-build-134.log,
> mvn-build-144-sorted.txt, mvn-build-144.log
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have a multi-module project with quite many modules and many dependencies
> and observe pretty random {{ArtifactNotFoundExceptions}} when building in
> parallel with an empty local repository.
> The "funny" thing is that Maven did in fact download the jar that it
> complained about not finding.
> In this example Maven said it could not find
> {{edu.tum.cs:cup-runtime:jar:11a}} (see stacktrace below)
> But it also said: {{Downloaded from central-mirror:
> [https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar]}}.
> When looking into the local repository after the failed build we found the
> cup-runtime.jar in the correct place with the correct checksum.
> We tried the following to "fix" the problem:
> * build with and without the takari extensions ({{takari-local-repository}}
> & {{takari-smart-builder}}) using {{--builder smart}}
> * also build with {{io.takari.aether:aether-connector-okhttp}} extension
> * only execute goal package instead of install
> * build with these properties: {{-Daether.connector.basic.threads=1
> -Daether.connector.resumeDownloads=false}}
> But nothing helped.
> Unfortunately it seems to be a race condition and we cannot reproduce it
> consistently but it happens in about 1 out of 5 builds.
> {code:java}
> ...
> [2019-11-18T16:46:29.370Z] [INFO] Downloaded from central-mirror:
> https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar
> (13 kB at 738 kB/s)
> ...
> [2019-11-18T16:46:30.894Z] [ERROR] Failed to execute goal on project xy:
> Could not resolve dependencies for project xy: The following artifacts could
> not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> -> [Help 1]
> [2019-11-18T16:46:30.894Z]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project xy: Could not resolve dependencies for project xy: The
> following artifacts could not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject
> (SmartBuilderImpl.java:205)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run
> (SmartBuilderImpl.java:77)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
> [2019-11-18T16:46:30.894Z] at java.util.concurrent.FutureTask.run
> (FutureTask.java:264)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1128)
>
[GitHub] [maven] mthmulders commented on a change in pull request #365: [MNG-6949] Add a GitHub Actions Workflow for building and integration…
mthmulders commented on a change in pull request #365:
URL: https://github.com/apache/maven/pull/365#discussion_r447179848
##
File path: .github/workflows/maven.yml
##
@@ -0,0 +1,116 @@
+# 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.
+
+name: Java CI
+
+on: [push, pull_request]
+
+jobs:
+ build:
+strategy:
+ matrix:
+os: [ubuntu-latest, windows-latest, macOS-latest]
+java: [8, 11, 14]
+ fail-fast: false
+
+runs-on: ${{ matrix.os }}
+
+steps:
+ - name: Checkout
+uses: actions/checkout@v2
+
+ - name: Set up cache for ~./m2/repository
+uses: actions/cache@v1
+with:
+ path: ~/.m2/repository
+ key: maven-${{ matrix.os }}-java${{ matrix.java }}-${{
hashFiles('**/pom.xml') }}
+ restore-keys: |
+maven-${{ matrix.os }}-java${{ matrix.java }}-
Review comment:
Hmm, I see, apparently the caching mechanism works differently than it
does in CircleCI (where I have often seen the practice of prefixing a cache
with a version identifier. Let's keep it as it is.
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] mthmulders commented on a change in pull request #365: [MNG-6949] Add a GitHub Actions Workflow for building and integration…
mthmulders commented on a change in pull request #365: URL: https://github.com/apache/maven/pull/365#discussion_r447177146 ## File path: .github/workflows/maven.yml ## @@ -0,0 +1,116 @@ +# 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. + +name: Java CI + +on: [push, pull_request] + +jobs: + build: +strategy: + matrix: +os: [ubuntu-latest, windows-latest, macOS-latest] +java: [8, 11, 14] Review comment: We don't make that much cost by adding the latest non-LTS here :-). I'd argue to keep 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
[jira] [Commented] (MJDEPS-20) jdeps for modularized code should use --module-path
[
https://issues.apache.org/jira/browse/MJDEPS-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147908#comment-17147908
]
b. ohnsorg commented on MJDEPS-20:
--
>From time to time I run into this issue and it is annoying enough so I had a
>look at the code. Basically I know what to do to push the classpath-resources
>into a new command option. I'm only uncertain how to derive it from runtime
>environment.
I can think of at least two options: double -cp and put all the elements from
classpath into module-path, too. Another option would be a
-structure, explictely configuring which modules to take into
consideration. This could also be some sort of include-/ exclude-thing to
filter classpath-elements. Then the filtered list is put into
module-path-option.
I often stumble across this with modularized projects, looking like this:
{code:java}
/-pom.xml: root with all modules/ packaging=pom
|- assets: not containing anything relevant for the Maven-portion of this
project
|- -app/pom.xml: binding all the tiny bits into a deliverable
|- -config/pom.xml: configuration module, constants, loading
preferences
|- -api/pom.xml: pure contracting, only interfaces
|- -model/pom.xml: model elements/ transfer objects
|- -ui/pom.xml: ui-components
{code}
Such projects often build the dependency chain like:
{code:java}
api <- model
config <- ui
model <- ui
ui <- app{code}
Thus I'd be comfortable with for example ui's pom.xml to have a jdeps-config
like the following (where is replaced with something like foobar, e.g.
foobar-ui, foobar-model etc.):
{code:java}
foobar*
{code}
Which in turn would copy all classpath-elements matching this filter to the
module-path-argument.
(?) Is it necessary to remove those elements from the -cp argument then?
> jdeps for modularized code should use --module-path
> ---
>
> Key: MJDEPS-20
> URL: https://issues.apache.org/jira/browse/MJDEPS-20
> Project: Maven JDeps Plugin
> Issue Type: Bug
>Affects Versions: 3.1.2
>Reporter: Andre Tadeu de Carvalho
>Priority: Major
>
> In the attempt to solve https://issues.apache.org/jira/browse/MJDEPS-16, I
> discover that the plugin is not settings *--module-path* when the code is
> modularized. It also need to set the target to
> _target/classes/module-info.class_ instead _target/classes_.
> As an example in [https://github.com/andretadeu/maven-jdeps-plugin.git,]
> branch MJDEPS-16, running the test *MJDEPS-16_jdkinternals*:
> {code}
> jdeps --module-path repo>/com/google/inject/guice/4.2.0/guice-4.2.0.jar: repo>/javax/inject/javax.inject/1/javax.inject-1.jar: repo>/aopalliance/aopalliance/1.0/aopalliance-1.0.jar: repo>/com/google/guava/guava/25.1-jre/guava-25.1-jre.jar: repo>/com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar: repo>/org/checkerframework/checker-qual/2.0.0/checker-qual-2.0.0.jar: repo>/com/google/errorprone/error_prone_annotations/2.1.3/error_prone_annotations-2.1.3.jar:
> repo>/com/google/j2objc/j2objc-annotations/1.1/j2objc-annotations-1.1.jar:
> repo>/org/codehaus/mojo/animal-sniffer-annotations/1.14/animal-sniffer-annotations-1.14.jar
> -jdkinternals root>/target/it/MJDEPS-16_jdkinternals/target/classes/module-info.class
> {code}
> should return:
> {code:java}
> com.google.common automatic
> [file:///home/andre/workspaces/oss/maven-jdeps-plugin/target/local-repo/com/google/guava/guava/25.1-jre/guava-25.1-jre.jar]
> requires mandated java.base
> com.google.common -> jdk.unsupported
> com.google.common.cache.Striped64 -> sun.misc.Unsafe JDK internal API
> (jdk.unsupported)
> com.google.common.cache.Striped64$1 -> sun.misc.Unsafe JDK internal API
> (jdk.unsupported)
> com.google.common.cache.Striped64$Cell -> sun.misc.Unsafe JDK internal API
> (jdk.unsupported)
> com.google.common.hash.LittleEndianByteArray$UnsafeByteArray ->
> sun.misc.Unsafe JDK internal API (jdk.unsupported)
> com.google.common.hash.LittleEndianByteArray$UnsafeByteArray$1 ->
> sun.misc.Unsafe JDK internal API (jdk.unsupported)
> com.google.common.hash.LittleEndianByteArray$UnsafeByteArray$2 ->
> sun.misc.Unsafe JDK internal API (jdk.unsupported)
> com.google.common.hash.LittleEndianByteArray$UnsafeByteArray$3 ->
> sun.misc.Unsafe JDK internal API (jdk.unsupported)
> com.google.common.hash.Striped64 -> sun.misc.Unsafe JDK internal API
> (jdk.unsupported)
> com.google.common.hash.Striped64$1 -> sun.misc.Unsafe JDK internal API
> (jdk.unsupported)
> com.google.common.hash.Striped64$Cell -> sun.misc.Unsafe JDK internal API
> (jdk.unsupported)
> com.google.common.primitives.UnsignedBytes$LexicographicalComparatorHolder$UnsafeComparator
> -> sun.misc.Unsafe JDK internal API (jdk.unsupported)
> com.google.common.primitives.UnsignedBytes$LexicographicalComparatorHolder$UnsafeComparator$1
> ->
[jira] [Comment Edited] (MJDEPS-20) jdeps for modularized code should use --module-path
[
https://issues.apache.org/jira/browse/MJDEPS-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147908#comment-17147908
]
b. ohnsorg edited comment on MJDEPS-20 at 6/29/20, 3:58 PM:
>From time to time I run into this issue and it is annoying enough so I had a
>look at the code. Basically I know what to do to push the classpath-resources
>into a new command option. I'm only uncertain how to derive it from runtime
>environment.
I can think of at least two options: double -cp and put all the elements from
classpath into module-path, too. Another option would be a
-structure, explictely configuring which modules to take into
consideration. This could also be some sort of include/ exclude-thing to filter
classpath-elements. Then the filtered list is put into module-path-option.
I often stumble across this with modularized projects, looking like this:
{code:java}
/-pom.xml: root with all modules/ packaging=pom
|- assets: not containing anything relevant for the Maven-portion of this
project
|- -app/pom.xml: binding all the tiny bits into a deliverable
|- -config/pom.xml: configuration module, constants, loading
preferences
|- -api/pom.xml: pure contracting, only interfaces
|- -model/pom.xml: model elements/ transfer objects
|- -ui/pom.xml: ui-components
{code}
Such projects often build the dependency chain like:
{code:java}
api <- model
config <- ui
model <- ui
ui <- app{code}
Thus I'd be comfortable with for example ui's pom.xml to have a jdeps-config
like the following (where is replaced with something like foobar, e.g.
foobar-ui, foobar-model etc.):
{code:java}
foobar*
{code}
Which in turn would copy all classpath-elements matching this filter to the
module-path-argument.
(?) Is it necessary to remove those elements from the -cp argument then?
was (Author: b.ohnsorg):
>From time to time I run into this issue and it is annoying enough so I had a
>look at the code. Basically I know what to do to push the classpath-resources
>into a new command option. I'm only uncertain how to derive it from runtime
>environment.
I can think of at least two options: double -cp and put all the elements from
classpath into module-path, too. Another option would be a
-structure, explictely configuring which modules to take into
consideration. This could also be some sort of include-/ exclude-thing to
filter classpath-elements. Then the filtered list is put into
module-path-option.
I often stumble across this with modularized projects, looking like this:
{code:java}
/-pom.xml: root with all modules/ packaging=pom
|- assets: not containing anything relevant for the Maven-portion of this
project
|- -app/pom.xml: binding all the tiny bits into a deliverable
|- -config/pom.xml: configuration module, constants, loading
preferences
|- -api/pom.xml: pure contracting, only interfaces
|- -model/pom.xml: model elements/ transfer objects
|- -ui/pom.xml: ui-components
{code}
Such projects often build the dependency chain like:
{code:java}
api <- model
config <- ui
model <- ui
ui <- app{code}
Thus I'd be comfortable with for example ui's pom.xml to have a jdeps-config
like the following (where is replaced with something like foobar, e.g.
foobar-ui, foobar-model etc.):
{code:java}
foobar*
{code}
Which in turn would copy all classpath-elements matching this filter to the
module-path-argument.
(?) Is it necessary to remove those elements from the -cp argument then?
> jdeps for modularized code should use --module-path
> ---
>
> Key: MJDEPS-20
> URL: https://issues.apache.org/jira/browse/MJDEPS-20
> Project: Maven JDeps Plugin
> Issue Type: Bug
>Affects Versions: 3.1.2
>Reporter: Andre Tadeu de Carvalho
>Priority: Major
>
> In the attempt to solve https://issues.apache.org/jira/browse/MJDEPS-16, I
> discover that the plugin is not settings *--module-path* when the code is
> modularized. It also need to set the target to
> _target/classes/module-info.class_ instead _target/classes_.
> As an example in [https://github.com/andretadeu/maven-jdeps-plugin.git,]
> branch MJDEPS-16, running the test *MJDEPS-16_jdkinternals*:
> {code}
> jdeps --module-path repo>/com/google/inject/guice/4.2.0/guice-4.2.0.jar: repo>/javax/inject/javax.inject/1/javax.inject-1.jar: repo>/aopalliance/aopalliance/1.0/aopalliance-1.0.jar: repo>/com/google/guava/guava/25.1-jre/guava-25.1-jre.jar: repo>/com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar: repo>/org/checkerframework/checker-qual/2.0.0/checker-qual-2.0.0.jar: repo>/com/google/errorprone/error_prone_annotations/2.1.3/error_prone_annotations-2.1.3.jar:
> repo>/com/google/j2objc/j2objc-annotations/1.1/j2objc-annotations-1.1.jar:
>
[GitHub] [maven] MartinKanters commented on a change in pull request #365: [MNG-6949] Add a GitHub Actions Workflow for building and integration…
MartinKanters commented on a change in pull request #365:
URL: https://github.com/apache/maven/pull/365#discussion_r447052482
##
File path: .github/workflows/maven.yml
##
@@ -0,0 +1,116 @@
+# 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.
+
+name: Java CI
+
+on: [push, pull_request]
+
+jobs:
+ build:
+strategy:
+ matrix:
+os: [ubuntu-latest, windows-latest, macOS-latest]
+java: [8, 11, 14]
+ fail-fast: false
+
+runs-on: ${{ matrix.os }}
+
+steps:
+ - name: Checkout
+uses: actions/checkout@v2
+
+ - name: Set up cache for ~./m2/repository
+uses: actions/cache@v1
+with:
+ path: ~/.m2/repository
+ key: maven-${{ matrix.os }}-java${{ matrix.java }}-${{
hashFiles('**/pom.xml') }}
+ restore-keys: |
+maven-${{ matrix.os }}-java${{ matrix.java }}-
Review comment:
Hmm, interesting. How it currently works is that it will try to find a
cache exactly matching the key: `maven-${{ matrix.os }}-java${{ matrix.java
}}-${{ hashFiles('**/pom.xml') }}`. If that fails it will try to find any of
the `restore-keys` caches (which are prefixes of caches). So it is designed to
always try to find any maven repository cache.
There is no way to manually clear the cache as far as I know, so if we
really want this to work, we should remove the `restore-keys` list and always
hit on exactly the cache key. If we would need to clear the cache, we can make
a simple change in a pom file which changes the hash in the caching key. It's a
bit cumbersome in my opinion.
Alternatively we could also keep it like this and make a change once needed.
We can always remove the caching job in this file, when needed. Also I think
that the GitHub Actions are only advisory (they won't block PRs), so we could
always fallback to local runs.
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 #365: [MNG-6949] Add a GitHub Actions Workflow for building and integration…
MartinKanters commented on a change in pull request #365:
URL: https://github.com/apache/maven/pull/365#discussion_r447039806
##
File path: .github/workflows/maven.yml
##
@@ -0,0 +1,116 @@
+# 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.
+
+name: Java CI
+
+on: [push, pull_request]
+
+jobs:
+ build:
+strategy:
+ matrix:
+os: [ubuntu-latest, windows-latest, macOS-latest]
+java: [8, 11, 14]
+ fail-fast: false
+
+runs-on: ${{ matrix.os }}
+
+steps:
+ - name: Checkout
+uses: actions/checkout@v2
+
+ - name: Set up cache for ~./m2/repository
+uses: actions/cache@v1
+with:
+ path: ~/.m2/repository
+ key: maven-${{ matrix.os }}-java${{ matrix.java }}-${{
hashFiles('**/pom.xml') }}
+ restore-keys: |
+maven-${{ matrix.os }}-java${{ matrix.java }}-
+maven-${{ matrix.os }}-
+
+ - name: Set up JDK
+uses: actions/setup-java@v1
+with:
+ java-version: ${{ matrix.java }}
+
+ - name: Build with Maven
+run: mvn verify -e -B -V -DdistributionFileName=apache-maven
+
+ - name: Upload built Maven
+uses: actions/upload-artifact@v2
+if: ${{ matrix.os == 'ubuntu-latest' && matrix.java == '11' }}
+with:
+ name: built-maven
+ path: apache-maven/target/
+
+ - name: Upload built Maven Wrapper
+uses: actions/upload-artifact@v2
+if: ${{ matrix.os == 'ubuntu-latest' && matrix.java == '11' }}
+with:
+ name: built-maven-wrapper
+ path: maven-wrapper/target/maven-wrapper.jar
+
+ integration-test:
+needs: build
+runs-on: ubuntu-latest
Review comment:
I think we could definitely try and enable this on the other platforms.
We'll need to make a pre-integration-test job then which at least determines
the integration-test repo (either the forked repo or from apache), but perhaps
we can do more.
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 #365: [MNG-6949] Add a GitHub Actions Workflow for building and integration…
MartinKanters commented on a change in pull request #365: URL: https://github.com/apache/maven/pull/365#discussion_r447033375 ## File path: .github/workflows/maven.yml ## @@ -0,0 +1,116 @@ +# 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. + +name: Java CI + +on: [push, pull_request] + +jobs: + build: +strategy: + matrix: +os: [ubuntu-latest, windows-latest, macOS-latest] +java: [8, 11, 14] Review comment: Thanks for the feedback! On the one hand I'm fine with removing 14 and only keeping the LTSes. On the other hand by keeping the latest non-LTS version we would reduce the risk of it failing on Jenkins eventually. The only downside I see is that we would have to upgrade this version number every half year. Am I missing other disadvantages? 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] (MCOMPILER-423) Unable to define qualified exports to unknown modules without triggering compiler warning
[
https://issues.apache.org/jira/browse/MCOMPILER-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147841#comment-17147841
]
Gili edited comment on MCOMPILER-423 at 6/29/20, 2:44 PM:
--
Passing the following options to the compiler plugin fixes the problem, but I
am looking for a way to configure Maven to do this automatically on my behalf:
{code:java}
org.apache.maven.plugins
maven-compiler-plugin
3.8.1
-Werror
--module-source-path
${project.basedir}/../*/src/main/java
--module
${module.name}
org.apache.maven.plugins
maven-jar-plugin
3.1.0
default-jar
jar
${project.build.outputDirectory}/${module.name}
{code}
was (Author: cowwoc):
Passing the following options to the compiler plugin fixes the problem, but I
am looking for a way to configure Maven to do this automatically on my behalf:
{code:java}
org.apache.maven.plugins
maven-compiler-plugin
3.8.1
-Werror
--module-source-path
${project.basedir}/../*/src/main/java
--module
${module.name}
{code}
> Unable to define qualified exports to unknown modules without triggering
> compiler warning
> -
>
> Key: MCOMPILER-423
> URL: https://issues.apache.org/jira/browse/MCOMPILER-423
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Gili
>Priority: Major
> Attachments: qualified-exports-module-source-path.zip
>
>
> Following up on a discussion with [~khmarbaise] at
> [https://stackoverflow.com/q/53670052/14731]
> It doesn't seem to be possible to compile the attached testcase without
> triggering a compiler warning.
> Expected behavior: Maven compiler plugin should pass --module-source-path to
> avoid the compiler warning.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCOMPILER-423) Unable to define qualified exports to unknown modules without triggering compiler warning
[
https://issues.apache.org/jira/browse/MCOMPILER-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147841#comment-17147841
]
Gili commented on MCOMPILER-423:
Passing the following options to the compiler plugin fixes the problem, but I
am looking for a way to configure Maven to do this automatically on my behalf:
{code:java}
org.apache.maven.plugins
maven-compiler-plugin
3.8.1
-Werror
--module-source-path
${project.basedir}/../*/src/main/java
--module
${module.name}
{code}
> Unable to define qualified exports to unknown modules without triggering
> compiler warning
> -
>
> Key: MCOMPILER-423
> URL: https://issues.apache.org/jira/browse/MCOMPILER-423
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Gili
>Priority: Major
> Attachments: qualified-exports-module-source-path.zip
>
>
> Following up on a discussion with [~khmarbaise] at
> [https://stackoverflow.com/q/53670052/14731]
> It doesn't seem to be possible to compile the attached testcase without
> triggering a compiler warning.
> Expected behavior: Maven compiler plugin should pass --module-source-path to
> avoid the compiler warning.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MCOMPILER-423) Unable to define qualified exports to unknown modules without triggering compiler warning
[ https://issues.apache.org/jira/browse/MCOMPILER-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gili updated MCOMPILER-423: --- Affects Version/s: 3.8.1 > Unable to define qualified exports to unknown modules without triggering > compiler warning > - > > Key: MCOMPILER-423 > URL: https://issues.apache.org/jira/browse/MCOMPILER-423 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > Attachments: qualified-exports-module-source-path.zip > > > Following up on a discussion with [~khmarbaise] at > [https://stackoverflow.com/q/53670052/14731] > It doesn't seem to be possible to compile the attached testcase without > triggering a compiler warning. > Expected behavior: Maven compiler plugin should pass --module-source-path to > avoid the compiler warning. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MCOMPILER-423) Unable to define qualified exports to unknown modules without triggering compiler warning
[ https://issues.apache.org/jira/browse/MCOMPILER-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gili updated MCOMPILER-423: --- Attachment: qualified-exports-module-source-path.zip > Unable to define qualified exports to unknown modules without triggering > compiler warning > - > > Key: MCOMPILER-423 > URL: https://issues.apache.org/jira/browse/MCOMPILER-423 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: Gili >Priority: Major > Attachments: qualified-exports-module-source-path.zip > > > Following up on a discussion with [~khmarbaise] at > [https://stackoverflow.com/q/53670052/14731] > It doesn't seem to be possible to compile the attached testcase without > triggering a compiler warning. > Expected behavior: Maven compiler plugin should pass --module-source-path to > avoid the compiler warning. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MCOMPILER-423) Unable to define qualified exports to unknown modules without triggering compiler warning
Gili created MCOMPILER-423: -- Summary: Unable to define qualified exports to unknown modules without triggering compiler warning Key: MCOMPILER-423 URL: https://issues.apache.org/jira/browse/MCOMPILER-423 Project: Maven Compiler Plugin Issue Type: Improvement Reporter: Gili Attachments: qualified-exports-module-source-path.zip Following up on a discussion with [~khmarbaise] at [https://stackoverflow.com/q/53670052/14731] It doesn't seem to be possible to compile the attached testcase without triggering a compiler warning. Expected behavior: Maven compiler plugin should pass --module-source-path to avoid the compiler warning. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-resolver-ant-tasks] michael-o commented on pull request #3: [MRESOLVER-66] settings task does not load repositories defined into settings.xml
michael-o commented on pull request #3: URL: https://github.com/apache/maven-resolver-ant-tasks/pull/3#issuecomment-651056457 Will look Info 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] mthmulders commented on a change in pull request #365: [MNG-6949] Add a GitHub Actions Workflow for building and integration…
mthmulders commented on a change in pull request #365:
URL: https://github.com/apache/maven/pull/365#discussion_r446813483
##
File path: .github/workflows/maven.yml
##
@@ -0,0 +1,116 @@
+# 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.
+
+name: Java CI
+
+on: [push, pull_request]
+
+jobs:
+ build:
+strategy:
+ matrix:
+os: [ubuntu-latest, windows-latest, macOS-latest]
+java: [8, 11, 14]
+ fail-fast: false
+
+runs-on: ${{ matrix.os }}
+
+steps:
+ - name: Checkout
+uses: actions/checkout@v2
+
+ - name: Set up cache for ~./m2/repository
+uses: actions/cache@v1
+with:
+ path: ~/.m2/repository
+ key: maven-${{ matrix.os }}-java${{ matrix.java }}-${{
hashFiles('**/pom.xml') }}
+ restore-keys: |
+maven-${{ matrix.os }}-java${{ matrix.java }}-
Review comment:
You might want to consider using a version number in the cache key. If -
for any reason - the current caches become unsuitable, you can bump the version
number and thus manually invalidate 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] mthmulders commented on a change in pull request #365: [MNG-6949] Add a GitHub Actions Workflow for building and integration…
mthmulders commented on a change in pull request #365:
URL: https://github.com/apache/maven/pull/365#discussion_r446798628
##
File path: .github/workflows/maven.yml
##
@@ -0,0 +1,116 @@
+# 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.
+
+name: Java CI
+
+on: [push, pull_request]
+
+jobs:
+ build:
+strategy:
+ matrix:
+os: [ubuntu-latest, windows-latest, macOS-latest]
+java: [8, 11, 14]
+ fail-fast: false
+
+runs-on: ${{ matrix.os }}
+
+steps:
+ - name: Checkout
+uses: actions/checkout@v2
+
+ - name: Set up cache for ~./m2/repository
+uses: actions/cache@v1
+with:
+ path: ~/.m2/repository
+ key: maven-${{ matrix.os }}-java${{ matrix.java }}-${{
hashFiles('**/pom.xml') }}
+ restore-keys: |
+maven-${{ matrix.os }}-java${{ matrix.java }}-
+maven-${{ matrix.os }}-
+
+ - name: Set up JDK
+uses: actions/setup-java@v1
+with:
+ java-version: ${{ matrix.java }}
+
+ - name: Build with Maven
+run: mvn verify -e -B -V -DdistributionFileName=apache-maven
+
+ - name: Upload built Maven
+uses: actions/upload-artifact@v2
+if: ${{ matrix.os == 'ubuntu-latest' && matrix.java == '11' }}
+with:
+ name: built-maven
+ path: apache-maven/target/
+
+ - name: Upload built Maven Wrapper
+uses: actions/upload-artifact@v2
+if: ${{ matrix.os == 'ubuntu-latest' && matrix.java == '11' }}
+with:
+ name: built-maven-wrapper
+ path: maven-wrapper/target/maven-wrapper.jar
+
+ integration-test:
+needs: build
+runs-on: ubuntu-latest
Review comment:
Would it be possible (and useful) to run the integration tests on other
platforms as well? Say Windows or macOS? I can foresee it will increase the
build duration so maybe it doesn't fit in the idea of a "sanity check". But if
so, then why do we _build_ it on those platforms?
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
