[GitHub] [maven-archetypes] Sunitha-Kandepu opened a new pull request, #16: Create samp1
Sunitha-Kandepu opened a new pull request, #16: URL: https://github.com/apache/maven-archetypes/pull/16 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MARCHETYPES) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MARCHETYPES-XXX] SUMMARY`, where you replace `MARCHETYPES-XXX` and `SUMMARY` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- 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] (MNGSITE-488) Add Bootstrap Site Skin to documentation
[ https://issues.apache.org/jira/browse/MNGSITE-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606131#comment-17606131 ] ASF GitHub Bot commented on MNGSITE-488: michael-o commented on PR #314: URL: https://github.com/apache/maven-site/pull/314#issuecomment-1250089073 Change looks good. > Add Bootstrap Site Skin to documentation > > > Key: MNGSITE-488 > URL: https://issues.apache.org/jira/browse/MNGSITE-488 > Project: Maven Project Web Site > Issue Type: Task >Reporter: Stephen Crocker >Priority: Minor > > I have developed a new Maven Site skin based on Bootstrap 5 components and > elements which can be toggled on/off allowing a variety of layouts. > The areas of the community I have shared this with have suggested placing it > into the available skin documentation so other projects can find it. > This feature is adding that information to the relevant documentation page. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-site] michael-o commented on pull request #314: MSITE-909 - Added new Site skin information to documentation
michael-o commented on PR #314: URL: https://github.com/apache/maven-site/pull/314#issuecomment-1250089073 Change looks good. -- 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] (MNG-7541) Native support for powershell to start maven
Jurrian Fahner created MNG-7541: --- Summary: Native support for powershell to start maven Key: MNG-7541 URL: https://issues.apache.org/jira/browse/MNG-7541 Project: Maven Issue Type: Improvement Components: Command Line Affects Versions: 3.8.3 Environment: windows 10 / 11 Reporter: Jurrian Fahner Maven has two files in the bin dir: ||command||it's use|| |mvn|bash| |mvn.cmd|cmd.exe| On windows there are two ways to write scripts, by using cmd.exe or using powershell. If you enter mvn in powershell it will look for `mvn.ps1` on the PATH first. If it doesn't find anything it will execute `mvn.cmd` as fall-back. When running maven for starting a server for development purposes and you do ctrl-c to exit the server it will ask the question: Terminate batch job (Y/N)? As far as I know it is default behaviour of cmd.exe. Well if I don't want to terminate, I wouldn't press ctrl-c. ;) It is not the case (as far as I know that Microsoft is going to deprecate cmd.exe in favor of powershell: [https://devblogs.microsoft.com/commandline/rumors-of-cmds-death-have-been-greatly-exaggerated/] Allthough I think it would be a good move for maven to have also a powershell script as well... It is possible to integrate elegant support for native help in powershell, `get-help mvn`. But it also increases the maintenance effort as well. I don't know whether this cost outweigh the benefits, though... By the way I would happy to contribute if it is appreciated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1136) Deprecate verifier.forkMode in favor of maven.verifier.forkMode
[
https://issues.apache.org/jira/browse/MSHARED-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606096#comment-17606096
]
Michael Osipov commented on MSHARED-1136:
-
How do you mean?
> Deprecate verifier.forkMode in favor of maven.verifier.forkMode
> ---
>
> Key: MSHARED-1136
> URL: https://issues.apache.org/jira/browse/MSHARED-1136
> Project: Maven Shared Components
> Issue Type: Task
> Components: maven-verifier
>Reporter: Michael Osipov
>Priority: Major
> Labels: up-for-grabs
> Fix For: maven-verifier-2.0.0
>
>
> We should have all system properties under our namespace, thus all prefixed
> with {{{}maven.{}}}. Query {{maven.verifier.forkMode}} first and then fall
> back to {{{}verifier.forkMode{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1136) Deprecate verifier.forkMode in favor of maven.verifier.forkMode
[
https://issues.apache.org/jira/browse/MSHARED-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606093#comment-17606093
]
Slawomir Jaranowski commented on MSHARED-1136:
--
Maybe we don't need such property at all.
Caller can easy set it during test prepare.
> Deprecate verifier.forkMode in favor of maven.verifier.forkMode
> ---
>
> Key: MSHARED-1136
> URL: https://issues.apache.org/jira/browse/MSHARED-1136
> Project: Maven Shared Components
> Issue Type: Task
> Components: maven-verifier
>Reporter: Michael Osipov
>Priority: Major
> Labels: up-for-grabs
> Fix For: maven-verifier-2.0.0
>
>
> We should have all system properties under our namespace, thus all prefixed
> with {{{}maven.{}}}. Query {{maven.verifier.forkMode}} first and then fall
> back to {{{}verifier.forkMode{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MSHARED-1135) Deprecate Verifier#setMavenDebug(boolean) for removal
[
https://issues.apache.org/jira/browse/MSHARED-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MSHARED-1135.
Resolution: Fixed
> Deprecate Verifier#setMavenDebug(boolean) for removal
> -
>
> Key: MSHARED-1135
> URL: https://issues.apache.org/jira/browse/MSHARED-1135
> Project: Maven Shared Components
> Issue Type: Task
> Components: maven-verifier
>Reporter: Michael Osipov
>Assignee: Slawomir Jaranowski
>Priority: Major
> Labels: up-for-grabs
> Fix For: maven-verifier-2.0.0
>
>
> This method has two issues:
> * The used option has been deprecated in favor of {{-X}}
> * The code overhead for just passing {{-X}} is not justified. This can
> simply be added by client code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1135) Deprecate Verifier#setMavenDebug(boolean) for removal
[
https://issues.apache.org/jira/browse/MSHARED-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606091#comment-17606091
]
Hudson commented on MSHARED-1135:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven-verifier » master #42
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-verifier/job/master/42/
> Deprecate Verifier#setMavenDebug(boolean) for removal
> -
>
> Key: MSHARED-1135
> URL: https://issues.apache.org/jira/browse/MSHARED-1135
> Project: Maven Shared Components
> Issue Type: Task
> Components: maven-verifier
>Reporter: Michael Osipov
>Assignee: Slawomir Jaranowski
>Priority: Major
> Labels: up-for-grabs
> Fix For: maven-verifier-2.0.0
>
>
> This method has two issues:
> * The used option has been deprecated in favor of {{-X}}
> * The code overhead for just passing {{-X}} is not justified. This can
> simply be added by client code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-verifier] slawekjaranowski merged pull request #47: [MSHARED-1135] deprecate mavenDebug option
slawekjaranowski merged PR #47: URL: https://github.com/apache/maven-verifier/pull/47 -- 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] [Comment Edited] (MRESOLVER-224) DefaultVersionResolver is inflicting ArtifactNotFoundException for classifiers with SNAPSHOT version
[
https://issues.apache.org/jira/browse/MRESOLVER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606085#comment-17606085
]
Tamás Cservenák edited comment on MRESOLVER-224 at 9/17/22 9:57 AM:
History:
This class was introduced in this commit:
[https://github.com/apache/maven-invoker-plugin/commit/863270e527db02c06de86ed2e3b01487862bda0f]
In 2009, when still Maven 2.0.6 was the thing. Since then, it lived pretty much
unmodified, merely "facelift" changes like Java 5 features or later
try-with-resource changes added, but not touching core logic (that is still
Maven2 aligned).
was (Author: cstamas):
History:
This class was introduced in this commit:
[https://github.com/apache/maven-invoker-plugin/commit/863270e527db02c06de86ed2e3b01487862bda0f]
In 2009, when still Maven 2.0.6 was the thing. Since then, it lived pretty much
unmodified, merely "facelift" changes like Java 5 features or later
try-with-resource changes added, but not touching core logic.
> DefaultVersionResolver is inflicting ArtifactNotFoundException for
> classifiers with SNAPSHOT version
>
>
> Key: MRESOLVER-224
> URL: https://issues.apache.org/jira/browse/MRESOLVER-224
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Tuomas Kiviaho
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I use classifier artifact along with the artifact itself as a dependency in a
> Maven Invoker Plugin project. The project that calls the invoker has the
> artifact itself as a dependency, but no reference to the classifier.
> This causes resolving of the maven-metadata.xml for the project itself plus
> downloading of the dependency artifact.When invoker is called the artifact is
> already downloaded to the local repo and cached with SNAPSHOT key.
> This causes the DefaultVersionResolver to merge the version information of
> the SNAPSHOT:jar artifact that is now being resolved with the
> already downloaded SNAPSHOT key. Since the local version is newer than the
> repo version the DefaultVersionResolver thinks SNAPSHOT:jar to
> be outdated thus overriding it with local repo.
> Since the SNAPSHOT:jar doesn't exist in the local repo there
> are no remote report left to try the DefaultArtifactResolver fails ultimately
> to ArtifactNotFoundException since there was no download task.
> {code:java}
> [INFO] [DEBUG] Resolving artifact
> .:jar::-SNAPSHOT from
> []{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-224) DefaultVersionResolver is inflicting ArtifactNotFoundException for classifiers with SNAPSHOT version
[
https://issues.apache.org/jira/browse/MRESOLVER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606085#comment-17606085
]
Tamás Cservenák commented on MRESOLVER-224:
---
History:
This class was introduced in this commit:
[https://github.com/apache/maven-invoker-plugin/commit/863270e527db02c06de86ed2e3b01487862bda0f]
In 2009, when still Maven 2.0.6 was the thing. Since then, it lived pretty much
unmodified, merely "facelift" changes like Java 5 features or later
try-with-resource changes added, but not touching core logic.
> DefaultVersionResolver is inflicting ArtifactNotFoundException for
> classifiers with SNAPSHOT version
>
>
> Key: MRESOLVER-224
> URL: https://issues.apache.org/jira/browse/MRESOLVER-224
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Tuomas Kiviaho
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I use classifier artifact along with the artifact itself as a dependency in a
> Maven Invoker Plugin project. The project that calls the invoker has the
> artifact itself as a dependency, but no reference to the classifier.
> This causes resolving of the maven-metadata.xml for the project itself plus
> downloading of the dependency artifact.When invoker is called the artifact is
> already downloaded to the local repo and cached with SNAPSHOT key.
> This causes the DefaultVersionResolver to merge the version information of
> the SNAPSHOT:jar artifact that is now being resolved with the
> already downloaded SNAPSHOT key. Since the local version is newer than the
> repo version the DefaultVersionResolver thinks SNAPSHOT:jar to
> be outdated thus overriding it with local repo.
> Since the SNAPSHOT:jar doesn't exist in the local repo there
> are no remote report left to try the DefaultArtifactResolver fails ultimately
> to ArtifactNotFoundException since there was no download task.
> {code:java}
> [INFO] [DEBUG] Resolving artifact
> .:jar::-SNAPSHOT from
> []{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-224) DefaultVersionResolver is inflicting ArtifactNotFoundException for classifiers with SNAPSHOT version
[
https://issues.apache.org/jira/browse/MRESOLVER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606082#comment-17606082
]
Tamás Cservenák commented on MRESOLVER-224:
---
Proposal: move this issue to MINVOKER, as this is NOT resolver issue: it just
tries it's best on interpreting available WRONG (Maven2, version 1.0.0)
metadata, that is in fact created by maven-invoker-plugin MetadataUtils class.
> DefaultVersionResolver is inflicting ArtifactNotFoundException for
> classifiers with SNAPSHOT version
>
>
> Key: MRESOLVER-224
> URL: https://issues.apache.org/jira/browse/MRESOLVER-224
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Tuomas Kiviaho
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I use classifier artifact along with the artifact itself as a dependency in a
> Maven Invoker Plugin project. The project that calls the invoker has the
> artifact itself as a dependency, but no reference to the classifier.
> This causes resolving of the maven-metadata.xml for the project itself plus
> downloading of the dependency artifact.When invoker is called the artifact is
> already downloaded to the local repo and cached with SNAPSHOT key.
> This causes the DefaultVersionResolver to merge the version information of
> the SNAPSHOT:jar artifact that is now being resolved with the
> already downloaded SNAPSHOT key. Since the local version is newer than the
> repo version the DefaultVersionResolver thinks SNAPSHOT:jar to
> be outdated thus overriding it with local repo.
> Since the SNAPSHOT:jar doesn't exist in the local repo there
> are no remote report left to try the DefaultArtifactResolver fails ultimately
> to ArtifactNotFoundException since there was no download task.
> {code:java}
> [INFO] [DEBUG] Resolving artifact
> .:jar::-SNAPSHOT from
> []{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-224) DefaultVersionResolver is inflicting ArtifactNotFoundException for classifiers with SNAPSHOT version
[
https://issues.apache.org/jira/browse/MRESOLVER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606081#comment-17606081
]
Tamás Cservenák commented on MRESOLVER-224:
---
That above is maven-invoker-plugin 3.2.1 (commit of tag), but looking at
master, same issue applies:
https://github.com/apache/maven-invoker-plugin/blob/master/src/main/java/org/apache/maven/plugins/invoker/MetadataUtils.java
> DefaultVersionResolver is inflicting ArtifactNotFoundException for
> classifiers with SNAPSHOT version
>
>
> Key: MRESOLVER-224
> URL: https://issues.apache.org/jira/browse/MRESOLVER-224
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Tuomas Kiviaho
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I use classifier artifact along with the artifact itself as a dependency in a
> Maven Invoker Plugin project. The project that calls the invoker has the
> artifact itself as a dependency, but no reference to the classifier.
> This causes resolving of the maven-metadata.xml for the project itself plus
> downloading of the dependency artifact.When invoker is called the artifact is
> already downloaded to the local repo and cached with SNAPSHOT key.
> This causes the DefaultVersionResolver to merge the version information of
> the SNAPSHOT:jar artifact that is now being resolved with the
> already downloaded SNAPSHOT key. Since the local version is newer than the
> repo version the DefaultVersionResolver thinks SNAPSHOT:jar to
> be outdated thus overriding it with local repo.
> Since the SNAPSHOT:jar doesn't exist in the local repo there
> are no remote report left to try the DefaultArtifactResolver fails ultimately
> to ArtifactNotFoundException since there was no download task.
> {code:java}
> [INFO] [DEBUG] Resolving artifact
> .:jar::-SNAPSHOT from
> []{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-224) DefaultVersionResolver is inflicting ArtifactNotFoundException for classifiers with SNAPSHOT version
[
https://issues.apache.org/jira/browse/MRESOLVER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606080#comment-17606080
]
Tamás Cservenák commented on MRESOLVER-224:
---
Here it is:
[https://github.com/apache/maven-invoker-plugin/blob/c004d31c7288d1e01c77bac183e1b9037a95f3b5/src/main/java/org/apache/maven/plugins/invoker/MetadataUtils.java#L67]
This class does it utterly wrong... (not only uses DOM to fake metadata,but
alas it creates 1.0.0 metadata)
> DefaultVersionResolver is inflicting ArtifactNotFoundException for
> classifiers with SNAPSHOT version
>
>
> Key: MRESOLVER-224
> URL: https://issues.apache.org/jira/browse/MRESOLVER-224
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Tuomas Kiviaho
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I use classifier artifact along with the artifact itself as a dependency in a
> Maven Invoker Plugin project. The project that calls the invoker has the
> artifact itself as a dependency, but no reference to the classifier.
> This causes resolving of the maven-metadata.xml for the project itself plus
> downloading of the dependency artifact.When invoker is called the artifact is
> already downloaded to the local repo and cached with SNAPSHOT key.
> This causes the DefaultVersionResolver to merge the version information of
> the SNAPSHOT:jar artifact that is now being resolved with the
> already downloaded SNAPSHOT key. Since the local version is newer than the
> repo version the DefaultVersionResolver thinks SNAPSHOT:jar to
> be outdated thus overriding it with local repo.
> Since the SNAPSHOT:jar doesn't exist in the local repo there
> are no remote report left to try the DefaultArtifactResolver fails ultimately
> to ArtifactNotFoundException since there was no download task.
> {code:java}
> [INFO] [DEBUG] Resolving artifact
> .:jar::-SNAPSHOT from
> []{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-224) DefaultVersionResolver is inflicting ArtifactNotFoundException for classifiers with SNAPSHOT version
[
https://issues.apache.org/jira/browse/MRESOLVER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606078#comment-17606078
]
Tamás Cservenák commented on MRESOLVER-224:
---
What version of invoker plugin you used (the invoker:install goal)? As I have a
suspect for this, but current state of affairs (invoker and
maven-invoker-plugin) does not confirm this...
Given this issue is 2021 Nov and when look at this
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-invoker-plugin/,
can I assume 3.2.2 or 3.2.1 was used? (if you cannot exactly tell the
version)
> DefaultVersionResolver is inflicting ArtifactNotFoundException for
> classifiers with SNAPSHOT version
>
>
> Key: MRESOLVER-224
> URL: https://issues.apache.org/jira/browse/MRESOLVER-224
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Tuomas Kiviaho
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I use classifier artifact along with the artifact itself as a dependency in a
> Maven Invoker Plugin project. The project that calls the invoker has the
> artifact itself as a dependency, but no reference to the classifier.
> This causes resolving of the maven-metadata.xml for the project itself plus
> downloading of the dependency artifact.When invoker is called the artifact is
> already downloaded to the local repo and cached with SNAPSHOT key.
> This causes the DefaultVersionResolver to merge the version information of
> the SNAPSHOT:jar artifact that is now being resolved with the
> already downloaded SNAPSHOT key. Since the local version is newer than the
> repo version the DefaultVersionResolver thinks SNAPSHOT:jar to
> be outdated thus overriding it with local repo.
> Since the SNAPSHOT:jar doesn't exist in the local repo there
> are no remote report left to try the DefaultArtifactResolver fails ultimately
> to ArtifactNotFoundException since there was no download task.
> {code:java}
> [INFO] [DEBUG] Resolving artifact
> .:jar::-SNAPSHOT from
> []{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-274) Introduce Remote Repository Filter feature
[
https://issues.apache.org/jira/browse/MRESOLVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MRESOLVER-274:
--
Description:
The feature, as it's name says should be able to "filter" RemoteRepositories by
some criteria ("known bad GAVs", "allowed groupId", etc).
In short, this feature allows following filtering: "should be Artifact
available from RemoteRepository?" and is able to employ several combination
(via consensus, or later possibly other strategies) of several "filter sources"
that are extensible (via adding new components).
Filter is used in two places:
* in connector, preventing remote artifact to be fetched from remote
repository (100% reliable)
* in resolution, preventing locally *cached* artifact to be resolved (reliable
as much as your local repository is "clean", ie. if you used Simple LRM on it,
it does not track remote origins will fail, while EnhancedLRM does track it and
will work as expected).
By default this feature is "dormant" (resolver behaves exactly same as before
without it). This is intended as "low level" feature that later can be built
upon, and implement some more user friendly solutions like MNG-6763. Hence,
this issue and resolver code changes are NOT meant to completely implement
MNG-6763, but more like to provide needed (lower level) functionalities to make
it possible.
Examples:
* provide a list of groupIds (this is done by demo)
* use prefixes file (example central
[https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
[https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
* maybe package up an artifact holding list of "known" bad artifacts and
consume that (and enforce it)
* etc...
was:
The feature, as it's name says should be able to "filter" RemoteRepositories by
some criteria ("known bad GAVs", "allowed groupId", etc).
In short, this feature allows following filtering: "should be Artifact
available from RemoteRepository?" and is able to employ several combination
(via consensus, or later possibly other strategies) of several "filter sources"
that are extensible (via adding new components).
Filter is used in two places:
* in connector, preventing remote artifact to be fetched from remote
repository (100% reliable)
* in resolution, preventing locally present artifact to be resolved (reliable
as much as your local repository is clean, ie. if you used Simple LRM on it, it
does not track remote origins, while EnhancedLRM does track it).
By default this feature is "dormant" (resolver behaves exactly same as before
without it). This is intended as "low level" feature that later can be built
upon, and implement some more user friendly solutions like MNG-6763. Hence,
this issue and resolver code changes are NOT meant to completely implement
MNG-6763, but more like to provide needed (lower level) functionalities to make
it possible.
Examples:
* provide a list of groupIds (this is done by demo)
* use prefixes file (example central
[https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
[https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
* maybe package up an artifact holding list of "known" bad artifacts and
consume that (and enforce it)
* etc...
> Introduce Remote Repository Filter feature
> --
>
> Key: MRESOLVER-274
> URL: https://issues.apache.org/jira/browse/MRESOLVER-274
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: resolver-next
>
>
> The feature, as it's name says should be able to "filter" RemoteRepositories
> by some criteria ("known bad GAVs", "allowed groupId", etc).
> In short, this feature allows following filtering: "should be Artifact
> available from RemoteRepository?" and is able to employ several combination
> (via consensus, or later possibly other strategies) of several "filter
> sources" that are extensible (via adding new components).
> Filter is used in two places:
> * in connector, preventing remote artifact to be fetched from remote
> repository (100% reliable)
> * in resolution, preventing locally *cached* artifact to be resolved
> (reliable as much as your local repository is "clean", ie. if you used Simple
> LRM on it, it does not track remote origins will fail, while EnhancedLRM does
> track it and will work as expected).
> By default this feature is "dormant" (resolver behaves exactly same as before
> without it). This is intended as "low level" feature that later can be built
> upon, and implement some more user friendly solutions like MNG-6763. Hence,
> this issue and resolver code changes are NOT meant to completely implement
[jira] [Updated] (MRESOLVER-274) Introduce Remote Repository Filter feature
[
https://issues.apache.org/jira/browse/MRESOLVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MRESOLVER-274:
--
Description:
The feature, as it's name says should be able to "filter" RemoteRepositories by
some criteria ("known bad GAVs", "allowed groupId", etc).
In short, this feature allows following filtering: "should be Artifact
available from RemoteRepository?" and is able to employ several combination
(via consensus, or later possibly other strategies) of several "filter sources"
that are extensible (via adding new components).
Filter is used in two places:
* in connector, preventing remote artifact to be fetched from remote
repository (100% reliable)
* in resolution, preventing locally *cached* artifact to be resolved (reliable
as much as your local repository is "clean", ie. if you used Simple LRM on it,
it does not track remote origins will fail to filter, while EnhancedLRM does
track it and will work as expected).
By default this feature is "dormant" (resolver behaves exactly same as before
without it). This is intended as "low level" feature that later can be built
upon, and implement some more user friendly solutions like MNG-6763. Hence,
this issue and resolver code changes are NOT meant to completely implement
MNG-6763, but more like to provide needed (lower level) functionalities to make
it possible.
Examples:
* provide a list of groupIds (this is done by demo)
* use prefixes file (example central
[https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
[https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
* maybe package up an artifact holding list of "known" bad artifacts and
consume that (and enforce it)
* etc...
was:
The feature, as it's name says should be able to "filter" RemoteRepositories by
some criteria ("known bad GAVs", "allowed groupId", etc).
In short, this feature allows following filtering: "should be Artifact
available from RemoteRepository?" and is able to employ several combination
(via consensus, or later possibly other strategies) of several "filter sources"
that are extensible (via adding new components).
Filter is used in two places:
* in connector, preventing remote artifact to be fetched from remote
repository (100% reliable)
* in resolution, preventing locally *cached* artifact to be resolved (reliable
as much as your local repository is "clean", ie. if you used Simple LRM on it,
it does not track remote origins will fail, while EnhancedLRM does track it and
will work as expected).
By default this feature is "dormant" (resolver behaves exactly same as before
without it). This is intended as "low level" feature that later can be built
upon, and implement some more user friendly solutions like MNG-6763. Hence,
this issue and resolver code changes are NOT meant to completely implement
MNG-6763, but more like to provide needed (lower level) functionalities to make
it possible.
Examples:
* provide a list of groupIds (this is done by demo)
* use prefixes file (example central
[https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
[https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
* maybe package up an artifact holding list of "known" bad artifacts and
consume that (and enforce it)
* etc...
> Introduce Remote Repository Filter feature
> --
>
> Key: MRESOLVER-274
> URL: https://issues.apache.org/jira/browse/MRESOLVER-274
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: resolver-next
>
>
> The feature, as it's name says should be able to "filter" RemoteRepositories
> by some criteria ("known bad GAVs", "allowed groupId", etc).
> In short, this feature allows following filtering: "should be Artifact
> available from RemoteRepository?" and is able to employ several combination
> (via consensus, or later possibly other strategies) of several "filter
> sources" that are extensible (via adding new components).
> Filter is used in two places:
> * in connector, preventing remote artifact to be fetched from remote
> repository (100% reliable)
> * in resolution, preventing locally *cached* artifact to be resolved
> (reliable as much as your local repository is "clean", ie. if you used Simple
> LRM on it, it does not track remote origins will fail to filter, while
> EnhancedLRM does track it and will work as expected).
> By default this feature is "dormant" (resolver behaves exactly same as before
> without it). This is intended as "low level" feature that later can be built
> upon, and implement some more user friendly solutions like MNG-6763. Hence,
> this issue and
[jira] [Updated] (MRESOLVER-274) Introduce Remote Repository Filter feature
[
https://issues.apache.org/jira/browse/MRESOLVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MRESOLVER-274:
--
Description:
The feature, as it's name says should be able to "filter" RemoteRepositories by
some criteria ("known bad GAVs", "allowed groupId", etc).
In short, this feature allows following filtering: "should be Artifact
available from RemoteRepository?" and is able to employ several combination
(via consensus, or later possibly other strategies) of several "filter sources"
that are extensible (via adding new components).
Filter is used in two places:
* in connector, preventing remote artifact to be fetched from remote
repository (100% reliable)
* in resolution, preventing locally present artifact to be resolved (reliable
as much as your local repository is clean, ie. if you used Simple LRM on it, it
does not track remote origins, while EnhancedLRM does track it).
By default this feature is "dormant" (resolver behaves exactly same as before
without it). This is intended as "low level" feature that later can be built
upon, and implement some more user friendly solutions like MNG-6763. Hence,
this issue and resolver code changes are NOT meant to completely implement
MNG-6763, but more like to provide needed (lower level) functionalities to make
it possible.
Examples:
* provide a list of groupIds (this is done by demo)
* use prefixes file (example central
[https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
[https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
* maybe package up an artifact holding list of "known" bad artifacts and
consume that (and enforce it)
* etc...
was:
The feature, as it's name says should be able to "filter" RemoteRepositories by
some criteria ("known bad GAVs", "allowed groupId", etc).
In short, this feature allows following filtering: "should be Artifact
available from RemoteRepository?" and is able to employ several combination
(via consensus, or later possibly other strategies) of several "filter sources"
that are extensible (via adding new components).
Filter is used in two places:
* in connector, preventing remote artifact to be fetched from (100% reliable)
* in resolution, preventing locally present artifact to be resolved (reliable
as much as your local repository is clean, ie. if you used Simple LRM on it, it
does not track remote origins, while EnhancedLRM does track it).
By default this feature is "dormant" (resolver behaves exactly same as before
without it). This is intended as "low level" feature that later can be built
upon, and implement some more user friendly solutions like MNG-6763. Hence,
this issue and resolver code changes are NOT meant to completely implement
MNG-6763, but more like to provide needed (lower level) functionalities to make
it possible.
Examples:
* provide a list of groupIds (this is done by demo)
* use prefixes file (example central
[https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
[https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
* maybe package up an artifact holding list of "known" bad artifacts and
consume that (and enforce it)
* etc...
> Introduce Remote Repository Filter feature
> --
>
> Key: MRESOLVER-274
> URL: https://issues.apache.org/jira/browse/MRESOLVER-274
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: resolver-next
>
>
> The feature, as it's name says should be able to "filter" RemoteRepositories
> by some criteria ("known bad GAVs", "allowed groupId", etc).
> In short, this feature allows following filtering: "should be Artifact
> available from RemoteRepository?" and is able to employ several combination
> (via consensus, or later possibly other strategies) of several "filter
> sources" that are extensible (via adding new components).
> Filter is used in two places:
> * in connector, preventing remote artifact to be fetched from remote
> repository (100% reliable)
> * in resolution, preventing locally present artifact to be resolved
> (reliable as much as your local repository is clean, ie. if you used Simple
> LRM on it, it does not track remote origins, while EnhancedLRM does track it).
> By default this feature is "dormant" (resolver behaves exactly same as before
> without it). This is intended as "low level" feature that later can be built
> upon, and implement some more user friendly solutions like MNG-6763. Hence,
> this issue and resolver code changes are NOT meant to completely implement
> MNG-6763, but more like to provide needed (lower level) functionalities to
> make it possible.
>
[jira] [Updated] (MRESOLVER-274) Introduce Remote Repository Filter feature
[
https://issues.apache.org/jira/browse/MRESOLVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MRESOLVER-274:
--
Description:
The feature, as it's name says should be able to "filter" RemoteRepositories by
some criteria ("known bad GAVs", "allowed groupId", etc).
In short, this feature allows following filtering: "should be Artifact
available from RemoteRepository?" and is able to employ several combination
(via consensus, or later possibly other strategies) of several "filter sources"
that are extensible (via adding new components).
Filter is used in two places:
* in connector, preventing remote artifact to be fetched from (100% reliable)
* in resolution, preventing locally present artifact to be resolved (reliable
as much as your local repository is clean, ie. if you used Simple LRM on it, it
does not track remote origins, while EnhancedLRM does track it).
By default this feature is "dormant" (resolver behaves exactly same as before
without it). This is intended as "low level" feature that later can be built
upon, and implement some more user friendly solutions like MNG-6763. Hence,
this issue and resolver code changes are NOT meant to completely implement
MNG-6763, but more like to provide needed (lower level) functionalities to make
it possible.
Examples:
* provide a list of groupIds (this is done by demo)
* use prefixes file (example central
[https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
[https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
* maybe package up an artifact holding list of "known" bad artifacts and
consume that (and enforce it)
* etc...
was:
The feature, as it's name says should be able to "filter" RemoteRepositories by
some criteria ("known bad GAVs", "allowed groupId", etc).
In short, this feature allows following filtering: "is Artifact available from
RemoteRepository?" and is able to employ several combination (via consensus, or
later possibly other strategies) of several "filter sources" that are
extensible (via adding new components).
Filter is used in two places:
* in connector, preventing remote artifact to be fetched from (100% reliable)
* in resolution, preventing locally present artifact to be resolved (reliable
as much as your local repository is clean, ie. if you used Simple LRM on it, it
does not track remote origins, while EnhancedLRM does track it).
By default this feature is "dormant" (resolver behaves exactly same as before
without it). This is intended as "low level" feature that later can be built
upon, and implement some more user friendly solutions like MNG-6763. Hence,
this issue and resolver code changes are NOT meant to completely implement
MNG-6763, but more like to provide needed (lower level) functionalities to make
it possible.
Examples:
* provide a list of groupIds (this is done by demo)
* use prefixes file (example central
[https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
[https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
* maybe package up an artifact holding list of "known" bad artifacts and
consume that (and enforce it)
* etc...
> Introduce Remote Repository Filter feature
> --
>
> Key: MRESOLVER-274
> URL: https://issues.apache.org/jira/browse/MRESOLVER-274
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: resolver-next
>
>
> The feature, as it's name says should be able to "filter" RemoteRepositories
> by some criteria ("known bad GAVs", "allowed groupId", etc).
> In short, this feature allows following filtering: "should be Artifact
> available from RemoteRepository?" and is able to employ several combination
> (via consensus, or later possibly other strategies) of several "filter
> sources" that are extensible (via adding new components).
> Filter is used in two places:
> * in connector, preventing remote artifact to be fetched from (100% reliable)
> * in resolution, preventing locally present artifact to be resolved
> (reliable as much as your local repository is clean, ie. if you used Simple
> LRM on it, it does not track remote origins, while EnhancedLRM does track it).
> By default this feature is "dormant" (resolver behaves exactly same as before
> without it). This is intended as "low level" feature that later can be built
> upon, and implement some more user friendly solutions like MNG-6763. Hence,
> this issue and resolver code changes are NOT meant to completely implement
> MNG-6763, but more like to provide needed (lower level) functionalities to
> make it possible.
> Examples:
> * provide a list of groupIds (this
[jira] [Updated] (MRESOLVER-274) Introduce Remote Repository Filter feature
[
https://issues.apache.org/jira/browse/MRESOLVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MRESOLVER-274:
--
Description:
The feature, as it's name says should be able to "filter" RemoteRepositories by
some criteria ("known bad GAVs", "allowed groupId", etc).
In short, this feature allows following filtering: "is Artifact available from
RemoteRepository?" and is able to employ several combination (via consensus, or
later possibly other strategies) of several "filter sources" that are
extensible (via adding new components).
Filter is used in two places:
* in connector, preventing remote artifact to be fetched from (100% reliable)
* in resolution, preventing locally present artifact to be resolved (reliable
as much as your local repository is clean, ie. if you used Simple LRM on it, it
does not track remote origins, while EnhancedLRM does track it).
By default this feature is "dormant" (resolver behaves exactly same as before
without it). This is intended as "low level" feature that later can be built
upon, and implement some more user friendly solutions like MNG-6763. Hence,
this issue and resolver code changes are NOT meant to completely implement
MNG-6763, but more like to provide needed (lower level) functionalities to make
it possible.
Examples:
* provide a list of groupIds (this is done by demo)
* use prefixes file (example central
[https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
[https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
* maybe package up an artifact holding list of "known" bad artifacts and
consume that (and enforce it)
* etc...
was:
The feature, as it's name says should be able to "filter" RemoteRepositories by
some criteria ("known bad GAVs", "allowed groupId", etc).
In short, this feature allows following filtering: "is Artifact available from
RemoteRepository?" and is able to employ several combination (via consensus, or
later possibly other strategies) of several "filter sources" that are
extensible (via adding new components).
Filter is used in two places:
* in connector, preventing remote artifact to be fetched from (100% reliable)
* in resolution, preventing locally present artifact to be resolved (reliable
as much as your local repository is clean, ie. if you used Simple LRM on it, it
does not track remote origins, while EnhancedLRM does track it).
Examples:
* provide a list of groupIds (this is done by demo)
* use prefixes file (example central
[https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
[https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
* maybe package up an artifact holding list of "known" bad artifacts and
consume that (and enforce it)
* etc...
> Introduce Remote Repository Filter feature
> --
>
> Key: MRESOLVER-274
> URL: https://issues.apache.org/jira/browse/MRESOLVER-274
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: resolver-next
>
>
> The feature, as it's name says should be able to "filter" RemoteRepositories
> by some criteria ("known bad GAVs", "allowed groupId", etc).
> In short, this feature allows following filtering: "is Artifact available
> from RemoteRepository?" and is able to employ several combination (via
> consensus, or later possibly other strategies) of several "filter sources"
> that are extensible (via adding new components).
> Filter is used in two places:
> * in connector, preventing remote artifact to be fetched from (100% reliable)
> * in resolution, preventing locally present artifact to be resolved
> (reliable as much as your local repository is clean, ie. if you used Simple
> LRM on it, it does not track remote origins, while EnhancedLRM does track it).
> By default this feature is "dormant" (resolver behaves exactly same as before
> without it). This is intended as "low level" feature that later can be built
> upon, and implement some more user friendly solutions like MNG-6763. Hence,
> this issue and resolver code changes are NOT meant to completely implement
> MNG-6763, but more like to provide needed (lower level) functionalities to
> make it possible.
> Examples:
> * provide a list of groupIds (this is done by demo)
> * use prefixes file (example central
> [https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
> [https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
> * maybe package up an artifact holding list of "known" bad artifacts and
> consume that (and enforce it)
> * etc...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-274) Introduce Remote Repository Filter feature
[
https://issues.apache.org/jira/browse/MRESOLVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MRESOLVER-274:
--
Description:
The feature, as it's name says should be able to "filter" RemoteRepositories by
some criteria ("known bad GAVs", "allowed groupId", etc).
In short, this feature allows following filtering: "is Artifact available from
RemoteRepository?" and is able to employ several combination (via consensus, or
later possibly other strategies) of several "filter sources" that are
extensible (via adding new components).
Filter is used in two places:
* in connector, preventing remote artifact to be fetched from (100% reliable)
* in resolution, preventing locally present artifact to be resolved (reliable
as much as your local repository is clean, ie. if you used Simple LRM on it, it
does not track remote origins, while EnhancedLRM does track it).
Examples:
* provide a list of groupIds (this is done by demo)
* use prefixes file (example central
[https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
[https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
* maybe package up an artifact holding list of "known" bad artifacts and
consume that (and enforce it)
* etc...
was:
The feature, as it's name says should be able to "filter" RemoteRepositories by
some criteria ("known bad GAVs", "allowed groupId", etc).
In short, this feature allows following filtering: "is Artifact available from
RemoteRepository?" and is able to employ several combination (via consensus, or
later possibly other strategies) of several "filter sources" that are
extensible (via adding new components).
Examples:
* provide a list of groupIds (this is done by demo)
* use prefixes file (example central
[https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
[https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
* maybe package up an artifact holding list of "known" bad artifacts and
consume that (and enforce it)
* etc...
> Introduce Remote Repository Filter feature
> --
>
> Key: MRESOLVER-274
> URL: https://issues.apache.org/jira/browse/MRESOLVER-274
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: resolver-next
>
>
> The feature, as it's name says should be able to "filter" RemoteRepositories
> by some criteria ("known bad GAVs", "allowed groupId", etc).
> In short, this feature allows following filtering: "is Artifact available
> from RemoteRepository?" and is able to employ several combination (via
> consensus, or later possibly other strategies) of several "filter sources"
> that are extensible (via adding new components).
> Filter is used in two places:
> * in connector, preventing remote artifact to be fetched from (100% reliable)
> * in resolution, preventing locally present artifact to be resolved
> (reliable as much as your local repository is clean, ie. if you used Simple
> LRM on it, it does not track remote origins, while EnhancedLRM does track it).
> Examples:
> * provide a list of groupIds (this is done by demo)
> * use prefixes file (example central
> [https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
> [https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
> * maybe package up an artifact holding list of "known" bad artifacts and
> consume that (and enforce it)
> * etc...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-274) Introduce Remote Repository Filter feature
[
https://issues.apache.org/jira/browse/MRESOLVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MRESOLVER-274:
--
Description:
The feature, as it's name says should be able to "filter" RemoteRepositories by
some criteria ("known bad GAVs", "allowed groupId", etc).
In short, this feature allows following filtering: "is Artifact available from
RemoteRepository?" and is able to employ several combination (via consensus, or
later possibly other strategies) of several "filter sources" that are
extensible (via adding new components).
Examples:
* provide a list of groupIds (this is done by demo)
* use prefixes file (example central
[https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
[https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
* maybe package up an artifact holding list of "known" bad artifacts and
consume that (and enforce it)
* etc...
was:
The feature, as it's name says should be able to "filter" RemoteRepositories by
some criteria ("known bad GAVs", "allowed groupId", etc).
Examples:
* provide a list of groupIds (this is done by demo)
* use prefixes file (example central
[https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
[https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
* maybe package up an artifact holding list of "known" bad artifacts and
consume that (and enforce it)
* etc...
> Introduce Remote Repository Filter feature
> --
>
> Key: MRESOLVER-274
> URL: https://issues.apache.org/jira/browse/MRESOLVER-274
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: resolver-next
>
>
> The feature, as it's name says should be able to "filter" RemoteRepositories
> by some criteria ("known bad GAVs", "allowed groupId", etc).
> In short, this feature allows following filtering: "is Artifact available
> from RemoteRepository?" and is able to employ several combination (via
> consensus, or later possibly other strategies) of several "filter sources"
> that are extensible (via adding new components).
> Examples:
> * provide a list of groupIds (this is done by demo)
> * use prefixes file (example central
> [https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
> [https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
> * maybe package up an artifact holding list of "known" bad artifacts and
> consume that (and enforce it)
> * etc...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-274) Introduce Remote Repository Filter feature
[
https://issues.apache.org/jira/browse/MRESOLVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MRESOLVER-274:
--
Description:
The feature, as it's name says should be able to "filter" RemoteRepositories by
some criteria ("known bad GAVs", "allowed groupId", etc).
Examples:
* provide a list of groupIds (this is done by demo)
* use prefixes file (example central
[https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
[https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
* maybe package up an artifact holding list of "known" bad artifacts and
consume that (and enforce it)
* etc...
was:The feature, as it's name says should be able to "filter"
RemoteRepositories by some criteria ("known bad GAVs", "allowed groupId", etc).
> Introduce Remote Repository Filter feature
> --
>
> Key: MRESOLVER-274
> URL: https://issues.apache.org/jira/browse/MRESOLVER-274
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: resolver-next
>
>
> The feature, as it's name says should be able to "filter" RemoteRepositories
> by some criteria ("known bad GAVs", "allowed groupId", etc).
> Examples:
> * provide a list of groupIds (this is done by demo)
> * use prefixes file (example central
> [https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
> [https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
> * maybe package up an artifact holding list of "known" bad artifacts and
> consume that (and enforce it)
> * etc...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-dependency-plugin] dependabot[bot] commented on pull request #247: Bump slf4j-simple from 1.7.36 to 2.0.1
dependabot[bot] commented on PR #247: URL: https://github.com/apache/maven-dependency-plugin/pull/247#issuecomment-1250025666 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-plugin] slawekjaranowski closed pull request #247: Bump slf4j-simple from 1.7.36 to 2.0.1
slawekjaranowski closed pull request #247: Bump slf4j-simple from 1.7.36 to 2.0.1 URL: https://github.com/apache/maven-dependency-plugin/pull/247 -- 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] (MASSEMBLY-965) Symbolic links get copied with absolute path
[
https://issues.apache.org/jira/browse/MASSEMBLY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606065#comment-17606065
]
Václav Haisman commented on MASSEMBLY-965:
--
Test case project: https://github.com/wilx/MASSEMBLY-965
> Symbolic links get copied with absolute path
>
>
> Key: MASSEMBLY-965
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-965
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Marc Guillemot
>Assignee: Guillaume Nodet
>Priority: Major
>
> Copied symbolic links in a `` have an absolute path as target and
> not the one of the original resource.
> Example:
> Source: {{foo -> ../my-file1}}
> Assembly: {{foo ->/home/marc/projects/demo/src/somestuff/myfile1}}
> This is a regression compared to 3.3.0. According to git bisect, the problem
> has been introduced with commit
> [https://github.com/apache/maven-assembly-plugin/commit/937750250bfe06333f92351fa1a19a9cd5e59d28]
> Pull Request with failing integration test follows.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-224) DefaultVersionResolver is inflicting ArtifactNotFoundException for classifiers with SNAPSHOT version
[
https://issues.apache.org/jira/browse/MRESOLVER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606050#comment-17606050
]
Tuomas Kiviaho commented on MRESOLVER-224:
--
Thanks for the clarification.
My workaround was to switch from {{invoker:install}} to premature installing at
{{pre-integration-test}} phase. If I recall correctly I stopped poking around
when I saw that invoker did use shared metadata creation but had it's own
rather crude implementation for it. Install plugin on the other hand didn't
"corrupt" the local repo with such partial (this is the model 1.0.0 I presume)
metadata and thus I was able to continue without too much of a fuzz.
I'd close the issue by knowing now that the limitation had left it's
marks/scars to the codebase.
PS. IMO {{invoker:install}} might be worth looking at with pair of eyes that
know more about the subtleties involved with metadata generation and resolving.
> DefaultVersionResolver is inflicting ArtifactNotFoundException for
> classifiers with SNAPSHOT version
>
>
> Key: MRESOLVER-224
> URL: https://issues.apache.org/jira/browse/MRESOLVER-224
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Tuomas Kiviaho
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I use classifier artifact along with the artifact itself as a dependency in a
> Maven Invoker Plugin project. The project that calls the invoker has the
> artifact itself as a dependency, but no reference to the classifier.
> This causes resolving of the maven-metadata.xml for the project itself plus
> downloading of the dependency artifact.When invoker is called the artifact is
> already downloaded to the local repo and cached with SNAPSHOT key.
> This causes the DefaultVersionResolver to merge the version information of
> the SNAPSHOT:jar artifact that is now being resolved with the
> already downloaded SNAPSHOT key. Since the local version is newer than the
> repo version the DefaultVersionResolver thinks SNAPSHOT:jar to
> be outdated thus overriding it with local repo.
> Since the SNAPSHOT:jar doesn't exist in the local repo there
> are no remote report left to try the DefaultArtifactResolver fails ultimately
> to ArtifactNotFoundException since there was no download task.
> {code:java}
> [INFO] [DEBUG] Resolving artifact
> .:jar::-SNAPSHOT from
> []{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
