[jira] [Comment Edited] (MNG-6763) Restrict repositories to specific groupIds
[ https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761811#comment-17761811 ] dennis lucero edited comment on MNG-6763 at 9/4/23 12:45 PM: - The "Remote Repository Filtering" feature using [prefixes|https://maven.apache.org/resolver/remote-repository-filtering.html#The_Prefixes_Filter] (introduced with Maven Resolver 1.9.0/Maven 3.9.0) works well and avoids the unnecessary requests I complained about. Big thanks to everyone involved in the implementation. However, there would still be value in the ability to specify such prefix filters directly in the settings.xml as it is a bit cumbersome to configure and enable such prefixes using the resolver. Maven needs to be called with the correct parameters (\-Daether.remoteRepositoryFilter.prefixes=true) and additional files (prefixes-*.txt) and their parent directories have to be created at specific paths. The installation on a workstation only needs this once, but when writing (Docker) containers it's easy to forget something or make a mistake (e. g. writing the prefix filters to a wrong directory). It would be much easier to configure and to review these filters if they were specified at the same location where the repositories are configured, that is the settings.xml. was (Author: striderapache): The "Remote Repository Filtering" feature using [prefixes|https://maven.apache.org/resolver/remote-repository-filtering.html#The_Prefixes_Filter] (introduced with Maven Resolver 1.9.0/Maven 3.9.0) works well and avoids the unnecessary requests I complained about. Big thanks to everyone involved in the implementation. However, there would still be value in the ability to specify such prefix filters directly in the settings.xml as it is a bit cumbersome to configure and enable such prefixes using the resolver. Maven needs to be called with the correct parameters (- Daether.remoteRepositoryFilter.prefixes=true) and additional files (prefixes-*.txt) and their parent directories have to be created at specific paths. The installation on a workstation only needs this once, but when writing (Docker) containers it's easy to forget something or make a mistake (e. g. writing the prefix filters to a wrong directory). It would be much easier to configure and to review these filters if they were specified at the same location where the repositories are configured, that is the settings.xml. > 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 > Labels: intern > > 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 always 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.20.10#820010)
[jira] [Comment Edited] (MNG-6763) Restrict repositories to specific groupIds
[ https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761811#comment-17761811 ] dennis lucero edited comment on MNG-6763 at 9/4/23 12:40 PM: - The "Remote Repository Filtering" feature using [prefixes|https://maven.apache.org/resolver/remote-repository-filtering.html#The_Prefixes_Filter] (introduced with Maven Resolver 1.9.0/Maven 3.9.0) works well and avoids the unnecessary requests I complained about. Big thanks to everyone involved in the implementation. However, there would still be value in the ability to specify such prefix filters directly in the settings.xml as it is a bit cumbersome to configure and enable such prefixes using the resolver. Maven needs to be called with the correct parameters (- Daether.remoteRepositoryFilter.prefixes=true) and additional files (prefixes-*.txt) and their parent directories have to be created at specific paths. The installation on a workstation only needs this once, but when writing (Docker) containers it's easy to forget something or make a mistake (e. g. writing the prefix filters to a wrong directory). It would be much easier to configure and to review these filters if they were specified at the same location where the repositories are configured, that is the settings.xml. was (Author: striderapache): The "Remote Repository Filtering" feature using [prefixes|https://maven.apache.org/resolver/remote-repository-filtering.html#The_Prefixes_Filter] (introduced with Maven Resolver 1.9.0/Maven 3.9.0) works well and avoids the unnecessary requests I complained about. Big thanks to everyone involved in the implementation. However, there would still be value in the ability to specify such prefix filters directly in the settings.xml as it is a bit cumbersome to configure and enable such prefixes using the resolver. Maven needs to be called with the correct parameters (-Daether.remoteRepositoryFilter.prefixes=true) and additional files (prefixes-*.txt) and their parent directories have to be created at specific paths. The installation on a workstation only needs this once, but when writing (Docker) containers it's easy to forget something or make a mistake (e. g. writing the prefix filters to a wrong directory). It would be much easier to configure and to review these filters if they were specified at the same location where the repositories are configured, that is the settings.xml. > 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 > Labels: intern > > 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 always 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.20.10#820010)
[jira] [Comment Edited] (MNG-6763) Restrict repositories to specific groupIds
[ https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761811#comment-17761811 ] dennis lucero edited comment on MNG-6763 at 9/4/23 12:40 PM: - The "Remote Repository Filtering" feature using [prefixes|https://maven.apache.org/resolver/remote-repository-filtering.html#The_Prefixes_Filter] (introduced with Maven Resolver 1.9.0/Maven 3.9.0) works well and avoids the unnecessary requests I complained about. Big thanks to everyone involved in the implementation. However, there would still be value in the ability to specify such prefix filters directly in the settings.xml as it is a bit cumbersome to configure and enable such prefixes using the resolver. Maven needs to be called with the correct parameters (-Daether.remoteRepositoryFilter.prefixes=true) and additional files (prefixes-*.txt) and their parent directories have to be created at specific paths. The installation on a workstation only needs this once, but when writing (Docker) containers it's easy to forget something or make a mistake (e. g. writing the prefix filters to a wrong directory). It would be much easier to configure and to review these filters if they were specified at the same location where the repositories are configured, that is the settings.xml. was (Author: striderapache): The "Remote Repository Filtering" feature using [prefixes|https://maven.apache.org/resolver/remote-repository-filtering.html#The_Prefixes_Filter] (introduced with Maven Resolver 1.9.0/Maven 3.9.0) works well and avoids the unnecessary requests I complained about. Big thanks to everyone involved in the implementation. However, there would still be value in the ability to specify such prefix filters directly in the settings.xml as it is a bit cumbersome to configure and enable such prefixes using the resolver. Maven needs to be called with the correct parameters (-Daether.remoteRepositoryFilter.prefixes=true) and additional files (prefixes-*.txt) and their parent directories have to be created at specific paths. The installation on a workstation only needs this once, but when writing (Docker) containers it's easy to forget something or make a mistake (e. g. writing the prefix filters to a wrong directory). It would be much easier to configure and to review these filters if they were specified at the same location where the repositories are configured, that is the settings.xml. > 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 > Labels: intern > > 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 always 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.20.10#820010)
[jira] [Comment Edited] (MNG-6763) Restrict repositories to specific groupIds
[ https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284142#comment-17284142 ] Herve Boutemy edited comment on MNG-6763 at 2/13/21, 8:28 AM: -- this will require an update to settings and POM schemas: can anybody provide an explicit example of how a groupId restriction configuration would look like? notice for later implementation: updating settings schema is probably quite easy, POM is harder, but we'll see that next, once we have a more precise view was (Author: hboutemy): this will require an update to settings and POM schemas: any explicit example of how a groupId restriction configuration would look like? notice for later implementation: updating settings schema is probably quite easy, POM is harder, but we'll see that next once we have a more precise view > 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 > Labels: intern > > 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 always 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)
[jira] [Comment Edited] (MNG-6763) Restrict repositories to specific groupIds
[
https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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],
>
[jira] [Comment Edited] (MNG-6763) Restrict repositories to specific groupIds
[
https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988861#comment-16988861
]
dennis lucero edited comment on MNG-6763 at 12/5/19 6:09 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 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
for {{com.fasterxml.jackson.core}} etc.
> 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
[jira] [Comment Edited] (MNG-6763) Restrict repositories to specific groupIds
[
https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988861#comment-16988861
]
dennis lucero edited comment on MNG-6763 at 12/5/19 6:08 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 requests
for {{com.fasterxml.jackson.core}} etc.
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.
> 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 always because
> sometimes a project is built while a dependency is not yet in our Nexus repo
> – without updatePolicy, it would take 24
[jira] [Comment Edited] (MNG-6763) Restrict repositories to specific groupIds
[
https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988861#comment-16988861
]
dennis lucero edited comment on MNG-6763 at 12/5/19 6:07 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 (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.
> 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 always 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
[jira] [Comment Edited] (MNG-6763) Restrict repositories to specific groupIds
[
https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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, 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.
{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 always 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
[jira] [Comment Edited] (MNG-6763) Restrict repositories to specific groupIds
[
https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 always 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.
>
[jira] [Comment Edited] (MNG-6763) Restrict repositories to specific groupIds
[
https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988861#comment-16988861
]
dennis lucero edited comment on MNG-6763 at 12/5/19 6:03 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.
{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 is not yet done 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.
{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 always 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
[jira] [Comment Edited] (MNG-6763) Restrict repositories to specific groupIds
[
https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16987844#comment-16987844
]
dennis lucero edited comment on MNG-6763 at 12/4/19 6:08 PM:
-
Sorry, by missing dependencies I mean dependencies which are built by our
Jenkins and cannot be pulled from central. Jenkins puts those in our releases
repo.
Sometimes I try to build a project depending on a library (version) which is
not in our releases repo yet. Without updatePolicy, Maven on my workstation
remembers that the dependency is not available in our releases repo. However, I
just have to wait a few minutes for our Jenkins to finish building the
dependency. After that, it is available in our releases repo. But without
updatePolicy Maven waits 24 hours before trying to get it from there again.
My primary concern is to speed up the build process by telling maven which
repo/mirror are able to provide a dependency, removing hundreds of unneccessary
requests. Everything works, but (as long as we don’t push to central) our
releases repository will never provide the dependencies found in central.
Therefore requests to our releases repo should be skipped for dependencies like
Jackson, but currently there’s no way configure Maven this way.
For a better understanding, this is what my ~/.m2/settings.xml looks like:
{code:xml}
default
default
acme-releases
https://maven.example.org/repository/maven-releases/
true
always
false
acme-snapshots
https://maven.example.org/repository/maven-snapshots/
false
true
always
acme-central-mirror
Acme Central Mirror
https://maven.example.org/repository/maven-central/
central
{code}
And a project’s POM contains
{code:xml}
org.codehaus.mojo
versions-maven-plugin
2.7
verify
display-parent-updates
display-plugin-updates
display-property-updates
display-dependency-updates
{code}
And when building the project, this appears:
{quote}— versions-maven-plugin:2.7:display-dependency-updates (default) @
demo-project —
artifact com.fasterxml.jackson.core:jackson-annotations: checking for updates
from acme-releases
artifact com.fasterxml.jackson.core:jackson-core: checking for updates from
acme-releases
artifact com.fasterxml.jackson.core:jackson-databind: checking for updates
from acme-releases
{quote}
(hundreds of other requests omitted)
This is not an issue of the versions plugin, that plugin only makes it worse.
was (Author: striderapache):
Sorry, by missing dependencies I mean dependencies which are built by our
Jenkins and cannot be pulled from central. Jenkins puts those in our releases
repo.
Sometimes I try to build a project depending on a library (version) which is
not in our releases repo yet. Without updatePolicy, Maven on my workstation
remembers that the dependency is not available in our releases repo. However, I
just have to wait a few minutes for our Jenkins to finish building the
dependency. After that, it is available in our releases repo. But without
updatePolicy Maven waits 24 hours before trying again.
My primary concern is to speed up the build process by telling maven which
repo/mirror are able to provide a dependency, removing hundreds of unneccessary
requests. Everything works, but (as long as we don’t push to central) our
releases repository will never provide the dependencies found in central.
Therefore requests to our releases repo should be skipped for dependencies like
Jackson, but currently there’s no way configure Maven this way.
For a better understanding, this is what my ~/.m2/settings.xml looks like:
{code:xml}
default
default
acme-releases
https://maven.example.org/repository/maven-releases/
true
always
false
acme-snapshots
https://maven.example.org/repository/maven-snapshots/
false
[jira] [Comment Edited] (MNG-6763) Restrict repositories to specific groupIds
[
https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16987844#comment-16987844
]
dennis lucero edited comment on MNG-6763 at 12/4/19 6:06 PM:
-
Sorry, by missing dependencies I mean dependencies which are built by our
Jenkins and cannot be pulled from central. Jenkins puts those in our releases
repo.
Sometimes I try to build a project depending on a library (version) which is
not in our releases repo yet. Without updatePolicy, Maven on my workstation
remembers that the dependency is not available in our releases repo. However, I
just have to wait a few minutes for our Jenkins to finish building the
dependency. After that, it is available in our releases repo.
My primary concern is to speed up the build process by telling maven which
repo/mirror are able to provide a dependency, removing hundreds of unneccessary
requests. Everything works, but (as long as we don’t push to central) our
releases repository will never provide the dependencies found in central.
Therefore requests to our releases repo should be skipped for dependencies like
Jackson, but currently there’s no way configure Maven this way.
For a better understanding, this is what my ~/.m2/settings.xml looks like:
{code:xml}
default
default
acme-releases
https://maven.example.org/repository/maven-releases/
true
always
false
acme-snapshots
https://maven.example.org/repository/maven-snapshots/
false
true
always
acme-central-mirror
Acme Central Mirror
https://maven.example.org/repository/maven-central/
central
{code}
And a project’s POM contains
{code:xml}
org.codehaus.mojo
versions-maven-plugin
2.7
verify
display-parent-updates
display-plugin-updates
display-property-updates
display-dependency-updates
{code}
And when building the project, this appears:
{quote}— versions-maven-plugin:2.7:display-dependency-updates (default) @
demo-project —
artifact com.fasterxml.jackson.core:jackson-annotations: checking for updates
from acme-releases
artifact com.fasterxml.jackson.core:jackson-core: checking for updates from
acme-releases
artifact com.fasterxml.jackson.core:jackson-databind: checking for updates
from acme-releases
{quote}
(hundreds of other requests omitted)
This is not an issue of the versions plugin, that plugin only makes it worse.
was (Author: striderapache):
Sorry, by missing dependencies I mean dependencies which are built by our
Jenkins and cannot be pulled from central. Jenkins puts those in our releases
repo.
Sometimes I try to build a project depending on a library (version) which is
not in our releases repo yet. Without updatePolicy, Maven on my workstation
remembers that the dependency is not available in our releases repo.
My primary concern is to speed up the build process by telling maven which
repo/mirror are able to provide a dependency, removing hundreds of unneccessary
requests. Everything works, but (as long as we don’t push to central) our
releases repository will never provide the dependencies found in central.
Therefore requests to our releases repo should be skipped for dependencies like
Jackson, but currently there’s no way configure Maven this way.
For a better understanding, this is what my ~/.m2/settings.xml looks like:
{code:xml}
default
default
acme-releases
https://maven.example.org/repository/maven-releases/
true
always
false
acme-snapshots
https://maven.example.org/repository/maven-snapshots/
false
true
always
acme-central-mirror
Acme Central Mirror
https://maven.example.org/repository/maven-central/
[jira] [Comment Edited] (MNG-6763) Restrict repositories to specific groupIds
[
https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16987844#comment-16987844
]
dennis lucero edited comment on MNG-6763 at 12/4/19 6:06 PM:
-
Sorry, by missing dependencies I mean dependencies which are built by our
Jenkins and cannot be pulled from central. Jenkins puts those in our releases
repo.
Sometimes I try to build a project depending on a library (version) which is
not in our releases repo yet. Without updatePolicy, Maven on my workstation
remembers that the dependency is not available in our releases repo. However, I
just have to wait a few minutes for our Jenkins to finish building the
dependency. After that, it is available in our releases repo. But without
updatePolicy Maven waits 24 hours before trying again.
My primary concern is to speed up the build process by telling maven which
repo/mirror are able to provide a dependency, removing hundreds of unneccessary
requests. Everything works, but (as long as we don’t push to central) our
releases repository will never provide the dependencies found in central.
Therefore requests to our releases repo should be skipped for dependencies like
Jackson, but currently there’s no way configure Maven this way.
For a better understanding, this is what my ~/.m2/settings.xml looks like:
{code:xml}
default
default
acme-releases
https://maven.example.org/repository/maven-releases/
true
always
false
acme-snapshots
https://maven.example.org/repository/maven-snapshots/
false
true
always
acme-central-mirror
Acme Central Mirror
https://maven.example.org/repository/maven-central/
central
{code}
And a project’s POM contains
{code:xml}
org.codehaus.mojo
versions-maven-plugin
2.7
verify
display-parent-updates
display-plugin-updates
display-property-updates
display-dependency-updates
{code}
And when building the project, this appears:
{quote}— versions-maven-plugin:2.7:display-dependency-updates (default) @
demo-project —
artifact com.fasterxml.jackson.core:jackson-annotations: checking for updates
from acme-releases
artifact com.fasterxml.jackson.core:jackson-core: checking for updates from
acme-releases
artifact com.fasterxml.jackson.core:jackson-databind: checking for updates
from acme-releases
{quote}
(hundreds of other requests omitted)
This is not an issue of the versions plugin, that plugin only makes it worse.
was (Author: striderapache):
Sorry, by missing dependencies I mean dependencies which are built by our
Jenkins and cannot be pulled from central. Jenkins puts those in our releases
repo.
Sometimes I try to build a project depending on a library (version) which is
not in our releases repo yet. Without updatePolicy, Maven on my workstation
remembers that the dependency is not available in our releases repo. However, I
just have to wait a few minutes for our Jenkins to finish building the
dependency. After that, it is available in our releases repo.
My primary concern is to speed up the build process by telling maven which
repo/mirror are able to provide a dependency, removing hundreds of unneccessary
requests. Everything works, but (as long as we don’t push to central) our
releases repository will never provide the dependencies found in central.
Therefore requests to our releases repo should be skipped for dependencies like
Jackson, but currently there’s no way configure Maven this way.
For a better understanding, this is what my ~/.m2/settings.xml looks like:
{code:xml}
default
default
acme-releases
https://maven.example.org/repository/maven-releases/
true
always
false
acme-snapshots
https://maven.example.org/repository/maven-snapshots/
false
true
always
