[jira] [Commented] (MNG-7843) Allow glob patterns in dependency exclusions
[
https://issues.apache.org/jira/browse/MNG-7843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743312#comment-17743312
]
ASF GitHub Bot commented on MNG-7843:
-
gnodet commented on code in PR #1200:
URL: https://github.com/apache/maven/pull/1200#discussion_r1264213883
##
maven-core/src/main/java/org/apache/maven/artifact/resolver/filter/ExclusionArtifactFilter.java:
##
@@ -28,37 +30,120 @@
* Filter to exclude from a list of artifact patterns.
*/
public class ExclusionArtifactFilter implements ArtifactFilter {
-private static final String WILDCARD = "*";
private final List exclusions;
+private final List> predicates;
public ExclusionArtifactFilter(List exclusions) {
this.exclusions = exclusions;
+this.predicates =
+
exclusions.stream().map(ExclusionArtifactFilter::toPredicate).collect(Collectors.toList());
}
-private Predicate sameArtifactId(Artifact artifact) {
-return exclusion ->
exclusion.getArtifactId().equals(artifact.getArtifactId());
+@Override
+public boolean include(Artifact artifact) {
+return predicates.stream().noneMatch(p -> p.test(artifact));
}
-private Predicate sameGroupId(Artifact artifact) {
-return exclusion ->
exclusion.getGroupId().equals(artifact.getGroupId());
+private static Predicate toPredicate(Exclusion exclusion) {
+Pattern groupId =
Pattern.compile(convertGlobToRegex(exclusion.getGroupId()));
+Pattern artifactId =
Pattern.compile(convertGlobToRegex(exclusion.getArtifactId()));
+Predicate predGroupId = a ->
groupId.matcher(a.getGroupId()).matches();
+Predicate predArtifactId =
+a -> artifactId.matcher(a.getArtifactId()).matches();
+return predGroupId.and(predArtifactId);
}
-private Predicate groupIdIsWildcard = exclusion ->
WILDCARD.equals(exclusion.getGroupId());
-
-private Predicate artifactIdIsWildcard = exclusion ->
WILDCARD.equals(exclusion.getArtifactId());
-
-private Predicate groupIdAndArtifactIdIsWildcard =
groupIdIsWildcard.and(artifactIdIsWildcard);
-
-private Predicate exclude(Artifact artifact) {
-return groupIdAndArtifactIdIsWildcard
-.or(groupIdIsWildcard.and(sameArtifactId(artifact)))
-.or(artifactIdIsWildcard.and(sameGroupId(artifact)))
-.or(sameGroupId(artifact).and(sameArtifactId(artifact)));
-}
-
-@Override
-public boolean include(Artifact artifact) {
-return !exclusions.stream().anyMatch(exclude(artifact));
+/**
+ * Converts a standard POSIX Shell globbing pattern into a regular
expression
Review Comment:
`PathMatcher` is not really usable in this context, unless we want to
implement a `Path` class just for that, but it looks worse to me. And I thought
we wanted to avoid `maven-shared-utils` which is not a dependency in maven
atm...
> Allow glob patterns in dependency exclusions
>
>
> Key: MNG-7843
> URL: https://issues.apache.org/jira/browse/MNG-7843
> Project: Maven
> Issue Type: New Feature
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] gnodet commented on a diff in pull request #1200: [MNG-7843] Allow glob patterns in dependency exclusions
gnodet commented on code in PR #1200:
URL: https://github.com/apache/maven/pull/1200#discussion_r1264213883
##
maven-core/src/main/java/org/apache/maven/artifact/resolver/filter/ExclusionArtifactFilter.java:
##
@@ -28,37 +30,120 @@
* Filter to exclude from a list of artifact patterns.
*/
public class ExclusionArtifactFilter implements ArtifactFilter {
-private static final String WILDCARD = "*";
private final List exclusions;
+private final List> predicates;
public ExclusionArtifactFilter(List exclusions) {
this.exclusions = exclusions;
+this.predicates =
+
exclusions.stream().map(ExclusionArtifactFilter::toPredicate).collect(Collectors.toList());
}
-private Predicate sameArtifactId(Artifact artifact) {
-return exclusion ->
exclusion.getArtifactId().equals(artifact.getArtifactId());
+@Override
+public boolean include(Artifact artifact) {
+return predicates.stream().noneMatch(p -> p.test(artifact));
}
-private Predicate sameGroupId(Artifact artifact) {
-return exclusion ->
exclusion.getGroupId().equals(artifact.getGroupId());
+private static Predicate toPredicate(Exclusion exclusion) {
+Pattern groupId =
Pattern.compile(convertGlobToRegex(exclusion.getGroupId()));
+Pattern artifactId =
Pattern.compile(convertGlobToRegex(exclusion.getArtifactId()));
+Predicate predGroupId = a ->
groupId.matcher(a.getGroupId()).matches();
+Predicate predArtifactId =
+a -> artifactId.matcher(a.getArtifactId()).matches();
+return predGroupId.and(predArtifactId);
}
-private Predicate groupIdIsWildcard = exclusion ->
WILDCARD.equals(exclusion.getGroupId());
-
-private Predicate artifactIdIsWildcard = exclusion ->
WILDCARD.equals(exclusion.getArtifactId());
-
-private Predicate groupIdAndArtifactIdIsWildcard =
groupIdIsWildcard.and(artifactIdIsWildcard);
-
-private Predicate exclude(Artifact artifact) {
-return groupIdAndArtifactIdIsWildcard
-.or(groupIdIsWildcard.and(sameArtifactId(artifact)))
-.or(artifactIdIsWildcard.and(sameGroupId(artifact)))
-.or(sameGroupId(artifact).and(sameArtifactId(artifact)));
-}
-
-@Override
-public boolean include(Artifact artifact) {
-return !exclusions.stream().anyMatch(exclude(artifact));
+/**
+ * Converts a standard POSIX Shell globbing pattern into a regular
expression
Review Comment:
`PathMatcher` is not really usable in this context, unless we want to
implement a `Path` class just for that, but it looks worse to me. And I thought
we wanted to avoid `maven-shared-utils` which is not a dependency in maven
atm...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MSITE-971) Site generation not resolving git.commit.time
[
https://issues.apache.org/jira/browse/MSITE-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743284#comment-17743284
]
Michael Osipov commented on MSITE-971:
--
[~larrick], interesting, this could be a global issue where {{MavenProject}}
contains global/static values. Can you create a sample project?
Please note that a potential fix needs to be applied to {{AbstractMavenReport}}
as well. Yet another problem is that the Velocity context is populated with
this uninerpolated value. So even if this is fixed, the populated value would
be wrong. I won't want a half-baked solution. Is there a reason why you don't
supply a static value once and have the Maven Release Plugin update the value
for you?
[~gnodet], what is your opinion, this should be this way or should they be
fully interpolated?
> Site generation not resolving git.commit.time
> -
>
> Key: MSITE-971
> URL: https://issues.apache.org/jira/browse/MSITE-971
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: property interpolation
>Affects Versions: 4.0.0-M9
> Environment: Windows 10 and FreeBSD
>Reporter: Brad Larrick
>Priority: Major
>
> I'm using git-commit-id-maven-plugin to set project.build.outputTimestamp as
> suggested in the Maven Guide Configuring for Reproducible Builds. I've
> included the plugin in my pom and including the following property definition:
>
> {code:java}
> ${git.commit.time}{code}
>
> When I generate the site, the plugin fails with the message:
> {{site failed: Invalid project.build.outputTimestamp value
> '${git.commit.time}}}
> This configuration works properly in the maven-jar-plugin, so I did some
> investigation. The jar plugin is getting the outputTimestamp as a mojo
> parameter:
>
> {code:java}
> @Parameter( defaultValue = "${project.build.outputTimestamp}" )
> private String outputTimestamp;
> {code}
> This works properly, with outputTimestamp set to the last commit time.
> In the site-plugin code, the outputTimestamp is being pulled from the project
> properties:
> {code:java}
> String outputTimestamp =
> p.getProperties().getProperty("project.build.outputTimestamp");{code}
> In the case the property hasn't been resolved and the returned string is
> ${git.commit.time}.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-383) java.net.SocketException: Connection reset
[
https://issues.apache.org/jira/browse/MRESOLVER-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743276#comment-17743276
]
Ryan Rupp commented on MRESOLVER-383:
-
Not sure if Apache has visibility on this or more of a Sonatype question but
any idea if there have been infrastructure changes with Maven Central that
would result in an increased amount of `Connection Reset` occurring? We've been
seeing a significant increase on our CI builds since ~July 5th without any
infrastructure changes or maven version changes etc. on our end. I was also
wondering if it had to do with keep alive i.e. something with a more aggressive
max-idle time somewhere along the network stack with Maven Central although we
have some builds where this occurs within 45 seconds of the build starting (so
the maven process would be at most 45 seconds old at that point and I assume
the connection pooling isn't scoped beyond the lifetime of the maven process?).
I wrote a little test client that just downloads from maven central with
keep-alive enabled and then tries again X seconds later and it worked fine i.e.
I tried 60 seconds later and the connection hadn't been severed at least
(wasn't truly apples to apples because I did my machine -->
`https://repo.maven.apache.org` rather than going through our build
infrastructure). I will say I have experienced issues with this in general
(outside of maven/CI) i.e. AWS NAT as mentioned is 350s and Azure load
balancers default to 4 minutes and Azure at least doesn't notify the client
that it closed until you try to write to the connection at some later point in
time which is how you get the `Connection Reset` on an attempt to write. Azure
load balancers for instance the ability to notify the client immediately of the
close (send a TCP RST) is configurable but by default is *not* enabled so we've
seen that be a problem there if you don't have TCP keep-alive enabled with the
interval tweaked down OR scale in the connection pooling max-idle.
Anyway, I've been hunting for if other people are suddenly experiencing this
and I found this issue and INFRA-24767 for instance that align with this
timeline.
> java.net.SocketException: Connection reset
> --
>
> Key: MRESOLVER-383
> URL: https://issues.apache.org/jira/browse/MRESOLVER-383
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Konrad Windszus
>Priority: Major
>
> Although in MRESOLVER-361 the retry handler by default is now using
> https://www.javadoc.io/doc/org.apache.httpcomponents/httpclient/latest/org/apache/http/impl/client/StandardHttpRequestRetryHandler.html
> that one still does not sufficiently deal with Connection resets.
> A regular connection reset leads to an exception like the following (without
> any noticable retry attempts)
> {code}
> [ERROR] Failed to execute goal on project vault-davex: Could not resolve
> dependencies for project
> org.apache.jackrabbit.vault:vault-davex:jar:3.6.9-SNAPSHOT: Failed to collect
> dependencies at org.apache.jackrabbit:jackrabbit-jcr-client:jar:2.20.10:
> Failed to read artifact descriptor for
> org.apache.jackrabbit:jackrabbit-jcr-client:jar:2.20.10: The following
> artifacts could not be resolved:
> org.apache.jackrabbit:jackrabbit-jcr-client:pom:2.20.10 (absent): Could not
> transfer artifact org.apache.jackrabbit:jackrabbit-jcr-client:pom:2.20.10
> from/to central (https://repo.maven.apache.org/maven2): Connection reset ->
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project vault-davex: Could not resolve dependencies for project
> org.apache.jackrabbit.vault:vault-davex:jar:3.6.9-SNAPSHOT: Failed to collect
> dependencies at org.apache.jackrabbit:jackrabbit-jcr-client:jar:2.20.10
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:243)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:136)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:355)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:313)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:174)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:75)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:162)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
>
[jira] [Created] (MSITE-971) Site generation not resolving git.commit.time
Brad Larrick created MSITE-971:
--
Summary: Site generation not resolving git.commit.time
Key: MSITE-971
URL: https://issues.apache.org/jira/browse/MSITE-971
Project: Maven Site Plugin
Issue Type: Bug
Components: property interpolation
Affects Versions: 4.0.0-M9
Environment: Windows 10 and FreeBSD
Reporter: Brad Larrick
I'm using git-commit-id-maven-plugin to set project.build.outputTimestamp as
suggested in the Maven Guide Configuring for Reproducible Builds. I've included
the plugin in my pom and including the following property definition:
{code:java}
${git.commit.time}{code}
When I generate the site, the plugin fails with the message:
{{site failed: Invalid project.build.outputTimestamp value '${git.commit.time}}}
This configuration works properly in the maven-jar-plugin, so I did some
investigation. The jar plugin is getting the outputTimestamp as a mojo
parameter:
{code:java}
@Parameter( defaultValue = "${project.build.outputTimestamp}" )
private String outputTimestamp;
{code}
This works properly, with outputTimestamp set to the last commit time.
In the site-plugin code, the outputTimestamp is being pulled from the project
properties:
{code:java}
String outputTimestamp =
p.getProperties().getProperty("project.build.outputTimestamp");{code}
In the case the property hasn't been resolved and the returned string is
${git.commit.time}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-archetype] slawekjaranowski merged pull request #150: Fix dead link to velocity docs
slawekjaranowski merged PR #150: URL: https://github.com/apache/maven-archetype/pull/150 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-site] slawekjaranowski merged pull request #438: Fix dead link to velocity docs
slawekjaranowski merged PR #438: URL: https://github.com/apache/maven-site/pull/438 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (SUREFIRE-2188) Upgrade Parent to 40
Slawomir Jaranowski created SUREFIRE-2188: - Summary: Upgrade Parent to 40 Key: SUREFIRE-2188 URL: https://issues.apache.org/jira/browse/SUREFIRE-2188 Project: Maven Surefire Issue Type: Dependency upgrade Reporter: Slawomir Jaranowski Fix For: 3.2.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2177) Use junit-bom instead of single JUnit 5 versions
[ https://issues.apache.org/jira/browse/SUREFIRE-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated SUREFIRE-2177: -- Fix Version/s: (was: 3.x-candidate) > Use junit-bom instead of single JUnit 5 versions > > > Key: SUREFIRE-2177 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2177 > Project: Maven Surefire > Issue Type: Dependency upgrade > Components: JUnit 5.x support >Affects Versions: 3.1.2 >Reporter: Stefano Cordio >Priority: Minor > Labels: pull-request-available > > I have noticed from > [95e8e95e|https://github.com/apache/maven-surefire/commit/95e8e95ee02ee0e12af70850440bd3d4c053d5db] > that the Surefire project declares JUnit dependency versions separately. > That commit upgraded the junit-jupiter dependencies to 5.9.3 and the > junit-platform dependency to 1.9.2. However, I assume the latter should have > been > [1.9.3|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-platform] > to stay in line with the [junit-jupiter > version|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-jupiter]. > If keeping the junit-platform version behind is not on purpose, I propose to > use instead the > [junit-bom|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-bom] > which would coordinate versioning of all the related JUnit modules. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2177) Use junit-bom instead of single JUnit 5 versions
[ https://issues.apache.org/jira/browse/SUREFIRE-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated SUREFIRE-2177: -- Issue Type: Improvement (was: Dependency upgrade) > Use junit-bom instead of single JUnit 5 versions > > > Key: SUREFIRE-2177 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2177 > Project: Maven Surefire > Issue Type: Improvement > Components: JUnit 5.x support >Affects Versions: 3.1.2 >Reporter: Stefano Cordio >Priority: Minor > Labels: pull-request-available > Fix For: 3.2.0 > > > I have noticed from > [95e8e95e|https://github.com/apache/maven-surefire/commit/95e8e95ee02ee0e12af70850440bd3d4c053d5db] > that the Surefire project declares JUnit dependency versions separately. > That commit upgraded the junit-jupiter dependencies to 5.9.3 and the > junit-platform dependency to 1.9.2. However, I assume the latter should have > been > [1.9.3|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-platform] > to stay in line with the [junit-jupiter > version|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-jupiter]. > If keeping the junit-platform version behind is not on purpose, I propose to > use instead the > [junit-bom|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-bom] > which would coordinate versioning of all the related JUnit modules. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SUREFIRE-2177) Use junit-bom instead of single JUnit 5 versions
[ https://issues.apache.org/jira/browse/SUREFIRE-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski reassigned SUREFIRE-2177: - Assignee: Slawomir Jaranowski > Use junit-bom instead of single JUnit 5 versions > > > Key: SUREFIRE-2177 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2177 > Project: Maven Surefire > Issue Type: Improvement > Components: JUnit 5.x support >Affects Versions: 3.1.2 >Reporter: Stefano Cordio >Assignee: Slawomir Jaranowski >Priority: Minor > Labels: pull-request-available > Fix For: 3.2.0 > > > I have noticed from > [95e8e95e|https://github.com/apache/maven-surefire/commit/95e8e95ee02ee0e12af70850440bd3d4c053d5db] > that the Surefire project declares JUnit dependency versions separately. > That commit upgraded the junit-jupiter dependencies to 5.9.3 and the > junit-platform dependency to 1.9.2. However, I assume the latter should have > been > [1.9.3|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-platform] > to stay in line with the [junit-jupiter > version|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-jupiter]. > If keeping the junit-platform version behind is not on purpose, I propose to > use instead the > [junit-bom|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-bom] > which would coordinate versioning of all the related JUnit modules. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SUREFIRE-2177) Use junit-bom instead of single JUnit 5 versions
[ https://issues.apache.org/jira/browse/SUREFIRE-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed SUREFIRE-2177. - Fix Version/s: 3.2.0 Resolution: Fixed > Use junit-bom instead of single JUnit 5 versions > > > Key: SUREFIRE-2177 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2177 > Project: Maven Surefire > Issue Type: Dependency upgrade > Components: JUnit 5.x support >Affects Versions: 3.1.2 >Reporter: Stefano Cordio >Priority: Minor > Labels: pull-request-available > Fix For: 3.2.0 > > > I have noticed from > [95e8e95e|https://github.com/apache/maven-surefire/commit/95e8e95ee02ee0e12af70850440bd3d4c053d5db] > that the Surefire project declares JUnit dependency versions separately. > That commit upgraded the junit-jupiter dependencies to 5.9.3 and the > junit-platform dependency to 1.9.2. However, I assume the latter should have > been > [1.9.3|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-platform] > to stay in line with the [junit-jupiter > version|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-jupiter]. > If keeping the junit-platform version behind is not on purpose, I propose to > use instead the > [junit-bom|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-bom] > which would coordinate versioning of all the related JUnit modules. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2177) Use junit-bom instead of single JUnit 5 versions
[ https://issues.apache.org/jira/browse/SUREFIRE-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743191#comment-17743191 ] ASF GitHub Bot commented on SUREFIRE-2177: -- slawekjaranowski merged PR #663: URL: https://github.com/apache/maven-surefire/pull/663 > Use junit-bom instead of single JUnit 5 versions > > > Key: SUREFIRE-2177 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2177 > Project: Maven Surefire > Issue Type: Dependency upgrade > Components: JUnit 5.x support >Affects Versions: 3.1.2 >Reporter: Stefano Cordio >Priority: Minor > Labels: pull-request-available > Fix For: 3.x-candidate > > > I have noticed from > [95e8e95e|https://github.com/apache/maven-surefire/commit/95e8e95ee02ee0e12af70850440bd3d4c053d5db] > that the Surefire project declares JUnit dependency versions separately. > That commit upgraded the junit-jupiter dependencies to 5.9.3 and the > junit-platform dependency to 1.9.2. However, I assume the latter should have > been > [1.9.3|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-platform] > to stay in line with the [junit-jupiter > version|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-jupiter]. > If keeping the junit-platform version behind is not on purpose, I propose to > use instead the > [junit-bom|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-bom] > which would coordinate versioning of all the related JUnit modules. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MASFRES-67) Exclude ".flattened-pom.xml" generated by flatten-maven-plugin
[
https://issues.apache.org/jira/browse/MASFRES-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved MASFRES-67.
Fix Version/s: apache-resources 1.6
Resolution: Fixed
Fixed in
https://github.com/apache/maven-apache-resources/commit/57717810cdb00a2e3eade26346802bafe4764339.
> Exclude ".flattened-pom.xml" generated by flatten-maven-plugin
> --
>
> Key: MASFRES-67
> URL: https://issues.apache.org/jira/browse/MASFRES-67
> Project: Apache Maven Resource Bundles
> Issue Type: Improvement
> Components: apache-source-release-assembly-descriptor
>Affects Versions: apache-resources 1.5
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: apache-resources 1.6
>
>
> As leveraging [CI Friendly
> Versions|https://maven.apache.org/maven-ci-friendly.html] requires the use of
> the {{flatten-maven-plugin}} which creates {{.flattened-pom.xml}} files,
> those files should be exluded by default as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-apache-resources] kwin merged pull request #9: [MASFRES-67] Exclude ".flattened-pom.xml" generated by flatten-maven-…
kwin merged PR #9: URL: https://github.com/apache/maven-apache-resources/pull/9 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7843) Allow glob patterns in dependency exclusions
[
https://issues.apache.org/jira/browse/MNG-7843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743127#comment-17743127
]
ASF GitHub Bot commented on MNG-7843:
-
elharo commented on code in PR #1200:
URL: https://github.com/apache/maven/pull/1200#discussion_r1263664946
##
maven-core/src/main/java/org/apache/maven/artifact/resolver/filter/ExclusionArtifactFilter.java:
##
@@ -28,37 +30,120 @@
* Filter to exclude from a list of artifact patterns.
*/
public class ExclusionArtifactFilter implements ArtifactFilter {
-private static final String WILDCARD = "*";
private final List exclusions;
+private final List> predicates;
public ExclusionArtifactFilter(List exclusions) {
this.exclusions = exclusions;
+this.predicates =
+
exclusions.stream().map(ExclusionArtifactFilter::toPredicate).collect(Collectors.toList());
}
-private Predicate sameArtifactId(Artifact artifact) {
-return exclusion ->
exclusion.getArtifactId().equals(artifact.getArtifactId());
+@Override
+public boolean include(Artifact artifact) {
+return predicates.stream().noneMatch(p -> p.test(artifact));
}
-private Predicate sameGroupId(Artifact artifact) {
-return exclusion ->
exclusion.getGroupId().equals(artifact.getGroupId());
+private static Predicate toPredicate(Exclusion exclusion) {
+Pattern groupId =
Pattern.compile(convertGlobToRegex(exclusion.getGroupId()));
+Pattern artifactId =
Pattern.compile(convertGlobToRegex(exclusion.getArtifactId()));
+Predicate predGroupId = a ->
groupId.matcher(a.getGroupId()).matches();
+Predicate predArtifactId =
+a -> artifactId.matcher(a.getArtifactId()).matches();
+return predGroupId.and(predArtifactId);
}
-private Predicate groupIdIsWildcard = exclusion ->
WILDCARD.equals(exclusion.getGroupId());
-
-private Predicate artifactIdIsWildcard = exclusion ->
WILDCARD.equals(exclusion.getArtifactId());
-
-private Predicate groupIdAndArtifactIdIsWildcard =
groupIdIsWildcard.and(artifactIdIsWildcard);
-
-private Predicate exclude(Artifact artifact) {
-return groupIdAndArtifactIdIsWildcard
-.or(groupIdIsWildcard.and(sameArtifactId(artifact)))
-.or(artifactIdIsWildcard.and(sameGroupId(artifact)))
-.or(sameGroupId(artifact).and(sameArtifactId(artifact)));
-}
-
-@Override
-public boolean include(Artifact artifact) {
-return !exclusions.stream().anyMatch(exclude(artifact));
+/**
+ * Converts a standard POSIX Shell globbing pattern into a regular
expression
Review Comment:
This is unnecessary. There are already globstar patterns in the JDK. See
PathMatcher.getMatcher("glob")
And there's glob support in maven-shared-utils that predates this being
added to the JDK.
> Allow glob patterns in dependency exclusions
>
>
> Key: MNG-7843
> URL: https://issues.apache.org/jira/browse/MNG-7843
> Project: Maven
> Issue Type: New Feature
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-763) JavadocReportTest.testExceptions is broken
[
https://issues.apache.org/jira/browse/MJAVADOC-763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743109#comment-17743109
]
ASF GitHub Bot commented on MJAVADOC-763:
-
elharo commented on code in PR #219:
URL:
https://github.com/apache/maven-javadoc-plugin/pull/219#discussion_r1263627189
##
src/test/java/org/apache/maven/plugins/javadoc/JavadocReportTest.java:
##
@@ -594,27 +595,6 @@ public void testOptionsUmlautEncoding() throws Exception {
}
}
-/**
- * @throws Exception if any
- */
-public void testExceptions() throws Exception {
-try {
-Path testPom =
unit.resolve("default-configuration/exception-test-plugin-config.xml");
-JavadocReport mojo = lookupMojo(testPom);
Review Comment:
This lookup fails and throws an exception, causing the test to pass. It
never executes the mojo which is what it's supposed to test.
> JavadocReportTest.testExceptions is broken
> --
>
> Key: MJAVADOC-763
> URL: https://issues.apache.org/jira/browse/MJAVADOC-763
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Major
>
> The Mojo lookup fails. This is hidden by bad exception handling in the test
> that catches too broad an exception type.
> [ERROR] Errors:
> [ERROR]
> JavadocReportTest.testExceptions:603->lookupMojo:103->AbstractMojoTestCase.lookupMojo:355->AbstractMojoTestCase.lookupMojo:426
> » ComponentConfiguration Cannot load implementation hint
> 'org.apache.maven.plugins.javadoc.stubs.ExceptionTestMavenProjectStub'
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-javadoc-plugin] elharo commented on a diff in pull request #219: [MJAVADOC-763] remove test that doesn't test what it claims
elharo commented on code in PR #219:
URL:
https://github.com/apache/maven-javadoc-plugin/pull/219#discussion_r1263627189
##
src/test/java/org/apache/maven/plugins/javadoc/JavadocReportTest.java:
##
@@ -594,27 +595,6 @@ public void testOptionsUmlautEncoding() throws Exception {
}
}
-/**
- * @throws Exception if any
- */
-public void testExceptions() throws Exception {
-try {
-Path testPom =
unit.resolve("default-configuration/exception-test-plugin-config.xml");
-JavadocReport mojo = lookupMojo(testPom);
Review Comment:
This lookup fails and throws an exception, causing the test to pass. It
never executes the mojo which is what it's supposed to test.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MJAVADOC-763) JavadocReportTest.testExceptions is broken
[ https://issues.apache.org/jira/browse/MJAVADOC-763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743099#comment-17743099 ] ASF GitHub Bot commented on MJAVADOC-763: - michael-o commented on PR #219: URL: https://github.com/apache/maven-javadoc-plugin/pull/219#issuecomment-1635681681 I don't have an opinion here > JavadocReportTest.testExceptions is broken > -- > > Key: MJAVADOC-763 > URL: https://issues.apache.org/jira/browse/MJAVADOC-763 > Project: Maven Javadoc Plugin > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > > The Mojo lookup fails. This is hidden by bad exception handling in the test > that catches too broad an exception type. > [ERROR] Errors: > [ERROR] > JavadocReportTest.testExceptions:603->lookupMojo:103->AbstractMojoTestCase.lookupMojo:355->AbstractMojoTestCase.lookupMojo:426 > » ComponentConfiguration Cannot load implementation hint > 'org.apache.maven.plugins.javadoc.stubs.ExceptionTestMavenProjectStub' -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-apache-resources] kwin opened a new pull request, #9: [MASFRES-67] Exclude ".flattened-pom.xml" generated by flatten-maven-…
kwin opened a new pull request, #9: URL: https://github.com/apache/maven-apache-resources/pull/9 …plugin -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (MASFRES-67) Exclude ".flattened-pom.xml" generated by flatten-maven-plugin
[
https://issues.apache.org/jira/browse/MASFRES-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned MASFRES-67:
--
Assignee: Konrad Windszus
> Exclude ".flattened-pom.xml" generated by flatten-maven-plugin
> --
>
> Key: MASFRES-67
> URL: https://issues.apache.org/jira/browse/MASFRES-67
> Project: Apache Maven Resource Bundles
> Issue Type: Improvement
> Components: apache-source-release-assembly-descriptor
>Affects Versions: apache-resources 1.5
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> As leveraging [CI Friendly
> Versions|https://maven.apache.org/maven-ci-friendly.html] requires the use of
> the {{flatten-maven-plugin}} which creates {{.flattened-pom.xml}} files,
> those files should be exluded by default as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MASFRES-67) Exclude ".flattened-pom.xml" generated by flatten-maven-plugin
Konrad Windszus created MASFRES-67:
--
Summary: Exclude ".flattened-pom.xml" generated by
flatten-maven-plugin
Key: MASFRES-67
URL: https://issues.apache.org/jira/browse/MASFRES-67
Project: Apache Maven Resource Bundles
Issue Type: Improvement
Components: apache-source-release-assembly-descriptor
Affects Versions: apache-resources 1.5
Reporter: Konrad Windszus
As leveraging [CI Friendly
Versions|https://maven.apache.org/maven-ci-friendly.html] requires the use of
the {{flatten-maven-plugin}} which creates {{.flattened-pom.xml}} files, those
files should be exluded by default as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-382) Define local outgoing (bind) address
[
https://issues.apache.org/jira/browse/MRESOLVER-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell reassigned MRESOLVER-382:
--
Assignee: Tamas Cservenak (was: Benjamin Marwell)
Please review (target version, etc.).
> Define local outgoing (bind) address
>
>
> Key: MRESOLVER-382
> URL: https://issues.apache.org/jira/browse/MRESOLVER-382
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Benjamin Marwell
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 1.10.0
>
>
> Currently, outgoing PUT connections (or download from central for that
> matter) will be resolved over the default route.
> However, this is not always feasible.
> h2. Expected behaviour
> A new property {{aether.connector.http.bind.address}} is defined for outgoing
> requests, so that other routes (other interfaces) can be used.
> h2. Actual behaviour
> Certain systems cannot be reached when a firewall is only opened on a
> non-default interface.
> h2. User Story
> Builds on servers with multiple interfaces:
> * The default route is defined poorly
> * Other interfaces are available and have the requested firewall rules
> * User defines -Daether.connector.http.bind.address=${myotherip} (or local
> address) to make outgoing connections to bind to another interface than the
> default one.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-382) Define local outgoing (bind) address
[
https://issues.apache.org/jira/browse/MRESOLVER-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell updated MRESOLVER-382:
---
Fix Version/s: 1.10.0
> Define local outgoing (bind) address
>
>
> Key: MRESOLVER-382
> URL: https://issues.apache.org/jira/browse/MRESOLVER-382
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
> Fix For: 1.10.0
>
>
> Currently, outgoing PUT connections (or download from central for that
> matter) will be resolved over the default route.
> However, this is not always feasible.
> h2. Expected behaviour
> A new property {{aether.connector.http.bind.address}} is defined for outgoing
> requests, so that other routes (other interfaces) can be used.
> h2. Actual behaviour
> Certain systems cannot be reached when a firewall is only opened on a
> non-default interface.
> h2. User Story
> Builds on servers with multiple interfaces:
> * The default route is defined poorly
> * Other interfaces are available and have the requested firewall rules
> * User defines -Daether.connector.http.bind.address=${myotherip} (or local
> address) to make outgoing connections to bind to another interface than the
> default one.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
