I've noticed a different repository structure for a conan repository in Artifactory.
1. Artifactory Enterprise 6.3.2
Repository Layout: conan-default
Repository strucutre: repository_name/conan_username/conan_package_name/version/channel
2. Artifactory Enterprise 5.4.6
Repository Layout: conan-default
Repository strucutre: repository_name/conan_package_name/version/conan_username/channel
Do you know why? Is it because the Artifactory version? I haven't found anything in Artifactory release notes related to the conan repository structure.
The default layout for conan packages was migrated in Artifactory 6, to match other package managers default layouts that put the user (organization) name first, as the most important classification of packages.
The migration should be automatic, and affect only the visual appearance in Artifactory web UI. If there is some other changes, or the conan client breaks (and this is the reason you are asking), then, it is a failing migration in Artifactory upgrade. It should be reported to JFrog and ask support to help recover it.
Related
Can JFrog Xray be used to scan Maven artifact directly? All examples and resources I can find shows only Xray scanning Docker Images where it also scans layer with java application and its dependencies.
But can one scan Maven artifact directly even if its not part of any Docker images?
As you can se in the official JFrog Xray documentation, it supports many more technologies. NPM, NuGet, Docker and RPM just to name a few.
The artifacts are scanned regardless of what contains them, as long as they are hosted in a JFrog Artifactory repository that is configured to be scanned by Xray.
BTW, scanning is recursive, so if you have an NPM module in an RPM, it would also be scanned and reported.
We use our own Azure Artifacts instance to provide a private Nuget feed. It has a default setup, with the #Local view as the default view.
After updating a project on one of the developer machines from dotnet core 3.x to 5.0 all went fine on the dev machine. But then other developers started getting problems with restoring packages.
These developers tried dotnet nuget locals all -c then dotnet clean && dotnet restore after making sure they have the correct SDK installed (5.0). But the Azure Artifacts server cannot provide the correct package version, specifically;
error NU1102: Unable to find package Microsoft.AspNetCore.App.Ref with version (= 5.0.0)
I am aware that this package is an "internal package" in dotnet, and I have confirmed that it is not explicitly defined as a dependency in the projects that reports errors. It is some sort of implicit dependency.
I am also aware of that Microsoft says that one must add packages to a private feed that one wants the consumers of the feed to have available.
How can I possibly add such an "internal package" to the Nuget feed, when it is not meant to be consumed explicitly?
Why cannot Microsoft query a upstream package source when the requested package is not found in the private feed? (the 5.0.0 package version actually exists on nuget!)
How come that I do not have to download such a package myself when running dotnet restore, but my peers have to? (and fails at it, even though their dev environment is similar to mine)
I am trying to move all repositories I am using to Nexus 3. I use Apache Archiva as a Maven repository. I read that it's possible to copy repos between Archiva and Nexus 2. Is there any way to do the same with Nexus 3 ?
I have tried to do a workaround and succeeded. I created an instance of Nexus2 and migrated Archiva there. After that I have used the upgrade agent from Capabilities to migrate from Nexus2 to 3. Not a complicated way and is fast as well.
We have our source code (ASP.NET Core) within a SVN repository. Now for Continuous Integration, we want to use TFS to build and deploy to Azure WebApp. We can't migrate our code to TFS.
Is this possible?
Subversion is a natively supported repository type when defining builds since TFS 2015 Update 1. You should be able to choose it on the "Repository" tab.
There is a walkthrough available on VisualStudio.com.
You can build code you manage in Subversion in TFS 2017. You must install the Subversion client on your build agents. Check: https://www.visualstudio.com/en-us/docs/build/define/repository#subversion
In the Repository of Build Definition, choose Subversion type:
I have a maven project called myproject.app. I also have another project using vaadin and gwt called myproject.ui and another project, which is an Xcore-Project converted to Maven called myproject.model.
I want to aggregate them all in a war. For this I have a myproject.war with a pom declaring the dependencies.
For Vaadin and GWT everthing is working fine as these projects are pure maven projects. The Xcore project gives me headaches because I can't manage to provide the Plugin Dependencies declared in this project in the war.
I have tried to add the needed libraries in the pom but I can only get old versions (2.2.3) from Central - the XCore project uses 2.8./3.8..
How can I solve this?
The answer is to convert the eclipse dependencies (EMF, XCore ...) to maven artifacts using the Maven Tools 4 Eclipse.
http://wiki.eclipse.org/MT4E_FAQ
For professional usage it is necessary to setup a maven repository, I used Nexus with success (if you are developing locally and alone it would be enough to install the artifacts in you local repository).
http://www.sonatype.org/nexus/
You can get it working by setting up a hosted repository with the converted Eclipse artifacts (documented in the mt4e reference) and creating a repository group aggregating the preconfigured maven central proxy and the hosted repository with the eclipse artifacts.
You need to setup your local settings.xml to use the nexus and you're good to go. Eclipse's artifacts are usable via maven coordinates.
Keep the orbit artifacts in mind and design your patch files carefully.