Frederic Simon wrote > > Hi, > > Thanks for opening the Jira request. > About maintenance of include/exclude, adding for example it/tiscali/** as > exclude for the remote-repos virtual is one time good filter, no? > > Fred >
The fact is that I should add precise include/exclude patterns on each repository to hope to have some benefit. Just adding an exclusion patterns for artifacts I know that should not be resolved on remote repositories does not solve the problem that resolving dependencies for remote artifacts when a remote repo is down may cause a lot of unsuccessful requests to be generated to it. Consider that we don't use SNAPSHOT dependencies on our own artifacts at all, but we do have some artifacts on a flat directory "repository" bundled together with our projects, for JARs that are not stored in any remote Maven repository. We should invent a groupid for them (if they don't have a candidate one at all) and add an exclusion on Artifactory remote-repos virtual repo for that groupid. It's quite a lot of work for such a workaround, considering we are talking about ~80 jars in ~10 multiprojects. Fortunately, the latest versions of Gradle (since 1.0-milestone-7) are more efficient on caching artifacts, but not all our projects are ready to use those new versions. Mauro. -- View this message in context: http://forums.jfrog.org/Artifactory-slow-when-remote-repository-does-not-respond-tp7290329p7291021.html Sent from the Artifactory - Users mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Artifactory-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/artifactory-users
