I want to proxy the Eclipse ELK updatesites in my Nexus 2.14.4-03. I created four different proxy repositories for versions 0.1.0, 0.1.1, 0.2.0 and 0.2.1.
Then I created a Repository Group called Eclipse_ELK
Knowing that the order of the repositories matter, I placed 0.1.0 at the top. But when I use Eclipse->Help->Install New Software and mention the URL of the group repository, I am getting 0.2.0 to install. Why is this so?
Related
In JCenter net.sourceforge.plantuml:plantuml module doesn't have version 1.2020.15 in maven-metadata.xml.
But, in Maven Central this module has this version listed in maven-metadata.xml.
However, I managed to successfully download net.sourceforge.plantuml:plantuml:1.2020.15 JAR from JCenter. Look like, in this case JCenter redirects me to repo.jfrog.org/artifactory/libs-release-bintray repository, which contains this version. And this artifactory repository also has this version listed in maven-metadata.xml.
JCenter documentations says that it's a mirror of Maven Central. The question is: shouldn't maven-metadata.xml be fully synchronized? It's critical for me, as I use a tool to update my dependencies to latest versions and this tool doesn't update plantuml to the latest version, because this versions isn't listed in maven-metadata.xml in JCenter.
The Synchronisation of packages in Bintray will happen from JCenter to Maven Central. So packages in Maven Central will not always be in JCenter when users request a package that does not exist on JCenter (hence, on-demand), Bintray will try to retrieve it from remote repositories and store it in JCenter.
Therefore, JCenter does not duplicate everything under Maven Central (to be reflected in JCenter). If the package is already linked to JCenter and once the latest version is uploaded to your Bintray account it will be mirrored in JCenter and then you can sync the latest version with Maven Central from your Bintray account.
Please refer the below link for more information on how Maven Central sync works with Bintray:
https://www.jfrog.com/confluence/display/BT/Syncing+with+Third-Party+Platforms
What is the right procedure to deploy a debian package built for different distros into the same Jfrog debian artifactory repo?
Just uploading to the same path, but with different deb.distribution properties does not work, they all get uploaded to the same place and clobber the previous upload.
Including the distribution name into the package name is ugly, but would of course work. Is there a better way?
You simply post the different debian to different locations within the Jfrog artifactory repository. The trick is that the repository layout has nothing to do with the aptitude API, which retrieves debians regardless of their location according to the requested metadata (deb.distribution, deb.version etc).
Nexus Repository Manager OSS 3.9.0-01.
I wish to create a 'proxy' Nexus repository that will a replica of the public pypi repository. The other machines can then be configured to point to this Nexus repo. so that a 'pip install' on these machines works even if there is no Internet connection. Accordingly, I created a proxy repository of type 'pypi(proxy)'.
When I browse this repo, there aren't any components/assets but whenever someone does a 'pip install' by pointing to this repo, the package shows up in the interface e.g: pip install --user pyspark --verbose
What I am looking for is to clone/copy all the packages in the PyPI repository at once so that the future 'pip install' refers to this local copy and doesn't go to the Internet every time. Once a day, the local copy should be updated.
Is it possible to do so in Nexus OSS?
What you are trying to achieve is a PyPI mirror repository, not a proxy.
The PyPI proxy repository behaviour you described is correct, because it is a proxy, not a mirror. Nexus Repository Manager does not provide functionality to to create a mirror of another repository.
However, you could try to use a PyPI mirror client (e.g. bandersnatch) to obtain a copy of all packages, then move those files over to your PyPI hosted repository and ask Nexus to reindex the files. Later you would have to periodically repeat the process to keep your mirror up to date.
The latest version of Nexus Repository Manager OSS supports a new artefact types: Docker, npm, RubyGems. But it appears to drop support for artefact formats supported in the previous version: Maven, P2, OBR, Yum. Why is that?
Maven should be there, in fact we setup default repos for it when it starts. P2, OBR, Yum have not been rebuilt for Nexus Repository Manager 3 as of yet. Yum will likely be the next up, P2 and then maybe OBR (jury is still out on if we have enough people using it to include it in the core product).
If you'd like to kickstart any of these, we would love that. A community member recently created an APT format for himself:
https://github.com/mpoindexter/nexus-repository-apt
You might be able to follow his example and create one for OBR for example.
I setup a test artifactory server and downloaded some test rpms from a public mirror and then deployed these rpms through artifactory to a local artifactory yum repo (the whole point of this is to test artifactory w/ yum integration). So then I set everything else up and did a bunch of testing so generally speaking the environment has been shown to work (meaning artifactory.repo is config'd correctly and whatever else needed to be done). However. If I "yum install some.rpm" an rpm that is BOTH STORED LOCALLY IN MY ARTIFACTORY YUM REPO and ALSO AVAILABLE IN THE PUBLIC MIRRORS, yum will pull from the public mirror.
How do I deal with this?
Should I deal with this?
Or should I just let yum pull from the public mirror all the time and only use artifactory with yum for my company's rpms?
I mean, what if I want to just build my own repo and not deal with the public mirrors in some cases...?
Is there anything that can "preference" this stuff as opposed to just blowing away the public mirror repo config files in /etc/yum.repos.d/?
Well, it depends on your usecase.
By default Artifactory remote repositories also come with a local cache where they store all downloaded artifacts - so using a local repository to store the same artifacts is redundant.
You can config your yum client to pull from either the remote, local or both if you'd like - it has it's own internal ordering for which one it will access first.
You would mainly use a local repository for cases where you want to be 100% certain only specific versions are used in your build and don't want to rely on what the yum client will choose as an appropriate version, or for cases where you build your own packages for internal use and don't want anyone from 'outside' (outside the team/company whatever) having access to them.