maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "dennis lucero (Jira)" <j...@apache.org>
Subject [jira] [Comment Edited] (MNG-6763) Restrict repositories to specific groupIds
Date Thu, 05 Dec 2019 18:11:00 GMT

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

dennis lucero edited comment on MNG-6763 at 12/5/19 6:10 PM:
-------------------------------------------------------------

{quote}You should simply use your repository manager which mean to configure your setting
to mirror everything through your own repository manager.
{quote}
This is already done (acme-central-mirror in the settings.xml above)
{quote}Furthermore you have an update policy given with {{always}} on a release repository
this does not make sense...
{quote}
It does make sense. It is used to disable [negative caching|https://en.wikipedia.org/wiki/Negative_cache].
Is there another option to disable negative caching?

Consider this situation:

Project P depends on Library L. I make a change on L, give it a new (release) version number
and push it to our Git repo. Then Jenkins will get L, compile it and push it to our Maven
Repository Manager (Nexus, acme-releases in the settings.xml above). I then update P to include
the new version of L and try to build it.

If Jenkins has not yet finished compiling L, Maven on my workstation cannot find the new version
in our Nexus and remembers that for 24 hours, so unless I delete the metadata for L (or fiddle
with command line parameters) the build will fail every time in the next 24 hours.

After Jenkins is finished a few minutes later, the new version of L is available in Nexus
and I can build P if and only if Nexus is asked for the new version again – that’s what
{{updatePolicy always}} is for (in this case), to force Maven to query Nexus again.
{quote}the setup in your repository manager can decide which kind of artifacts (dependencies)
can be provided...
{quote}
But there is currently no way to tell Maven _on my workstation_ which artifacts could *possibly*
be available in a repo. That is what this issue is about. If I could tell Maven on my workstation
to query {{acme-releases}} only for dependencies with, for example, groupIds beginning with
{{com.example.acme}}, this would greatly speed up the build process, because it would skip
hundreds of requests to {{acme-releases}} for {{com.fasterxml.jackson.core}} etc. (those
artifacts are available in {{acme-central-mirror}}, which is also queried).


was (Author: striderapache):
{quote}You should simply use your repository manager which mean to configure your setting
to mirror everything through your own repository manager.
{quote}
This is already done (acme-central-mirror in the settings.xml above)
{quote}Furthermore you have an update policy given with {{always}} on a release repository
this does not make sense...
{quote}
It does make sense. It is used to disable [negative caching|https://en.wikipedia.org/wiki/Negative_cache].
Is there another option to disable negative caching?

Consider this situation:

Project P depends on Library L. I make a change on L, give it a new (release) version number
and push it to our Git repo. Then Jenkins will get L, compile it and push it to our Maven
Repository Manager (Nexus, acme-releases in the settings.xml above). I then update P to include
the new version of L and try to build it.

If Jenkins has not yet finished compiling L, Maven on my workstation cannot find the new version
in our Nexus and remembers that for 24 hours, so unless I delete the metadata for L (or fiddle
with command line parameters) the build will fail every time in the next 24 hours.

After Jenkins is finished a few minutes later, the new version of L is available in Nexus
and I can build P if and only if Nexus is asked for the new version again – that’s what
{{updatePolicy always}} is for (in this case), to force Maven to query Nexus again.
{quote}the setup in your repository manager can decide which kind of artifacts (dependencies)
can be provided...
{quote}
But there is currently no way to tell Maven _on my workstation_ which artifacts could *possibly*
be available in a repo. That is what this issue is about. If I could tell Maven on my workstation
to query {{acme-releases}} only for dependencies with, for example, groupIds beginning with
{{com.example.acme}}, this would greatly speed up the build process, because it would skip
requests to {{acme-releases}} for {{com.fasterxml.jackson.core}} etc. (those artifacts are
available in {{acme-central-mirror}}, which is also queried).

> Restrict repositories to specific groupIds
> ------------------------------------------
>
>                 Key: MNG-6763
>                 URL: https://issues.apache.org/jira/browse/MNG-6763
>             Project: Maven
>          Issue Type: New Feature
>            Reporter: dennis lucero
>            Priority: Major
>
> It should be possible to restrict the repositories specified in settings.xml to specific
groupIds. Looking at [https://maven.apache.org/ref/3.6.2/maven-settings/settings.html#class_repository],
it seems this is currently not the case.
> Background: We use Nexus to host our own artifacts. The settings.xml contains our Nexus
repository with <updatePolicy>always</updatePolicy> because sometimes a project
is built while a dependency is not yet in our Nexus repo – without updatePolicy, it would
take 24 hours or manual deletion of metadata to make Maven re-check for the missing dependency.
> Additionally, we use versions-maven-plugin:2.7:display-dependency-updates in our build
process.
> This results in lots of queries (more than 300 in a simple Dropwizard project) to our
repo which will never succeed. If we could specify that our repo only supplies groupIds beginning
with org.example, Maven could skip update checks for groupIds starting with com.fasterxml.jackson
and so on, speeding up the build process.



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

Mime
View raw message