Skip to content

Metadata type out of coordinates#1491

Merged
cstamas merged 1 commit intoapache:masterfrom
cstamas:metadata-type-non-addressable
Jun 16, 2025
Merged

Metadata type out of coordinates#1491
cstamas merged 1 commit intoapache:masterfrom
cstamas:metadata-type-non-addressable

Conversation

@cstamas
Copy link
Member

@cstamas cstamas commented Jun 14, 2025

Fix for metadata type that contains / (slash), as right now the layout get messed up in such cases. Originally, the "type" was filename, and GAV are the coordinates, but with this simple change, we can (re)use Resolver to resolve files that are not in "addressable space", but still have all the benefit of caching/auth etc.

Fix for metadata type that contains / (slash)
@cstamas cstamas added the bug Something isn't working label Jun 14, 2025
@cstamas cstamas marked this pull request as ready for review June 15, 2025 12:36
@cstamas cstamas self-assigned this Jun 15, 2025
@cstamas cstamas requested a review from gnodet June 15, 2025 12:58
@cstamas cstamas merged commit a9573dd into apache:master Jun 16, 2025
8 checks passed
@cstamas cstamas deleted the metadata-type-non-addressable branch June 16, 2025 14:55
@github-actions github-actions bot added this to the 2.0.10 milestone Jun 16, 2025
cstamas added a commit to cstamas/maven-resolver that referenced this pull request Jun 24, 2025
Fix for metadata type that contains `/` (slash), as right now the layout get messed up in such cases. Originally, the "type" was filename, and GAV are the coordinates, but with this simple change, we can (re)use Resolver to resolve files that are not in "addressable space", but still have all the benefit of caching/auth etc.
cstamas added a commit that referenced this pull request Jun 24, 2025
Fix for metadata type that contains `/` (slash), as right now the layout get messed up in such cases. Originally, the "type" was filename, and GAV are the coordinates, but with this simple change, we can (re)use Resolver to resolve files that are not in "addressable space", but still have all the benefit of caching/auth etc.Fix for metadata type that contains `/` (slash), as right now the layout get messed up in such cases. Originally, the "type" was filename, and GAV are the coordinates, but with this simple change, we can (re)use Resolver to resolve files that are not in "addressable space", but still have all the benefit of caching/auth etc.

This is a backport for #1491
@cstamas cstamas added enhancement New feature or request and removed bug Something isn't working labels Jun 26, 2025
cstamas added a commit that referenced this pull request Aug 12, 2025
High level new features and changes:
* (change) filtering is **enabled by default**
* (new) filtering can be suppressed on per-repository basis by appending configuration key with `.repoId=false`.
* (change) both filters enhanced to become really usable.

## GroupId filter

Is enabled by default (but remains dormant if user does not provides input). It becomes active only when user provides input for it.

Input vastly improved and now supports modifiers as well (Resolver 1.x modus operandi was `=org.apache` ONLY). Hence, upgrading from Resolver 1.x to Resolver 2.x leads to "broadened" filtering but that is fine is was user usually wants (Resolver 1.x had to enumerate all Gs for nested G, ie `org.apache.maven`, `org.apache.maven.plugins` etc... same effect with Resolver 2.x is one liner: `org.apache.maven` (as it means now "and below"). Added support for negation (`!`) and limiter (`=`). Example groupId filter file:

```
# My file                   (1)
                            (2)
org.apache.maven            (3)
!=org.apache.maven.foo      (4)
!org.apache.maven.indexer   (5)
=org.apache.bar             (6)
```
Lines 1, 2 ignored. Line 3 "allow `org.apache.maven` and below". Line 4 "not allow `org.apache.maven.foo` only". Line 5 "not allow `org.apache.maven.indexer` and below". Line 6 "allow `org.apache.bar` only".

## Prefix filter

Is enabled by default and improved to try to auto-discover prefix file published by remote repository. If prefix file is discovered, common resolver means are used to resolve and cache the prefix file in user local repository. If discovery fails, user provided prefix file is attempted (and used, if found). Finally, if no input, filter will not interfere. Order of precedence:
* user provided prefix file (if found, will be used, no discovery happens)
* auto discovery

Caching is now possible with fix done in #1491
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant