[
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:06 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.
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, 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.
> 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)
