Why does Artifactory have both Gradle and Maven repositories? - artifactory

After evaluating Artifactory for the first time, I find it confusing that when going through the initial setup, and selecting both Maven and Gradle integration, it creates two sets of repositories for me
platform-gradle-dev-local
platform-gradle-release-local
platform-libs-release-local
platform-libs-snapshot-local
While I have used Maven for many years, I am new to Gradle. The mystery to me is, I cannot see any utility in having separate repos for Gradle and Maven builds, and I cannot fathom from JFrog documentation why they do this.
Is there any reason to use the two gradle repos, or can I just use the standard Maven repos for all builds? Gradle, Maven, SBT, etc.

Artifactory Gradle repositories have a different layout than Maven repositories.
The layout used for Gradle repositories is compatible with the one use by the default Gradle Ivy repository layout.
Unless you need to use this repository layout, you should be perfectly fine working with a Maven repository.

Related

VSTS - Asp.Net Build with Project Dependencies and Git Repositories

Since VSTS has sought to bend to the popular Git source control, I have yet to see a good description of building .Net projects located in Git repositories, having project dependencies on one another.
For instance, in Visual Studio, I build a solution that includes projects with dependencies on each other. Then, in VSTS each of those .Net projects are versioned in separate Git repositories.
How, then, do you get a build on VSTS? How do you get the artifacts (read: DLLs) from one project into the project of the other?
UPDATE: 12/18/17
I took #VonC's suggestion and followed-through on a VSTS (Visual Studio Team Services) hosted Nuget package. I was able to make this work. This process makes .Net solution files and project dependencies OBSOLETE.
If you want to reuse a library, you can save the binaries as a NuGet package.
In the downstream project, you simply assign the VSTS url reference to the Nuget package to get the Nuget Restore to find/place the binaries in your build project.
You will have to download and install a Credentials tool that will allow you to push your binaries to VSTS's package location. Additionally, tell your admin to add the Packages functionality from the VSTS Marketplace.
Thanks, #VonC for the great suggestion!
Here are some helpful links:
Create and Publish the Private Nuget Package here
VSTS Marketplace Package Manager here
The idea is, for binary dependencies (DLLs) to not involve a source control tool (like Git) but a binary referential one (like Nuget)
See for instance:
"Package: NuGet"
"NuGet is now fully integrated into MSBuild"
With Visual Studio 2017 and .NET Core, we have improved the NuGet package management experience by introducing the PackageReference feature in MSBuild.
PackageReference brings new and improved capabilities such as deep MSBuild integration, improved performance for everyday tasks such as install and restore, multi-targeting and more.
First, it’s unnecessary to manage the build artifacts (such as dlls) in source control since they're the output files from the source code.
Then to add dependencies (dlls) from other repos to the parent (main) repo’s project, there usually has below options:
Option 1: manage the build artifacts as packages
As Vonc mentioned, you can manage the dlls as nuget packages, and then add nuget packages to your main repo’s project.
Option 2: git submodules
You can also treat other repos as the submodules for the main repo, and both build the projects from the submodules repos and the main repo in the build, then the main repo project can get the dependencies from the submodule repos’ build artifacts.
Commands to add a submodule for the main repo:
# In local main repo
git submodule add <URL for a submodule repo>
git commit -m 'add a submodule'
git push
Note: in VSTS build definition, you should select checkout submodules in Get Sources step.
Details about git submodules, you can refer Submodules.
Option 3: git subree (alternative way for git submodules)
Treat a branch from another repo as a subtree (a folder) in the main repo. Then build the projects both in the main repo and the subtrees, and get dependencies from subtrees for the main repo’s project.
Commands to add a subtree in the main repo:
git submodule add --prefix=submodule1 <URL for sub repo> master
git push
Then it will add a folder submodule1 with the files in the sub repo master branch, and commit the changes in the main repo.
Details about git subtree, you can refer
Git subtree: the alternative to Git submodule.
At any time, if your branch has working code with any version of dependent assemblies, I can't see any reason you need to do anything.
For example of dependencies here:
You can set dependencies in project like:
Also you can add dependencies in solution like :
You can set build order in solution too if your project has multiple project with dependencies.
As long as your current code in branch from which you are build is working (with any version of different assemblies, e.g. Classlibrary1 has version 1.0.0.0, Classlibrary2 has version 1.2.2.1 & so on but is working fine with each other after referencing) this approach will work.
Project dependencies exist for ages in Visual Studio & .Net. As long those project exist in same TFS branch You can add project dependency right in dependent project. Also you can manage Project build order in Solution.
For more complex scenarios like different repositories or branch dependencies you need to modify build workflow but it is also quite possible.
You can also refer
http://dailydotnettips.com/2015/11/25/how-to-identify-the-project-dependencies-in-visual-studio/
what I saw long time ago when I created same sample for test.

Writing maven plugins (mojos) in Scala with sbt

I have a multi module sbt/Scala project, and I want to write a maven plugin that depends on the scala code.
For the moment, I have the plugin in a separate project, using maven (maven-plugin packaging, and deps on the scala code). I therefore have 2 projects : one sbt and one maven. So I need to build (and publishM2) the sbt one and then build the other with maven.
Can the maven plugin be aggregated into the sbt build, so that I have only one multi-module project ?
Do I need to keep the pom.xml and "invoke" it from sbt ?
Can I build the mvn plugin directly in sbt (what about the packaging "maven-plugin" then) ?

What reposiroty type should I check in Artifactory OSS to proxy MavenCentral and JCenter?

I grabbed Artifactory OSS, change storage location and run application.
Under http://localhost:.../... I was asked for repository type.
My goal is to proxy in-house repositories to make possible offline/out-of-office development and I use in build.gradle:
jcenter()
mavenCentral()
Artifactory OSS provides:
Generic
Gradle
Ivy
Maven
variants. What should I choose?
Indeed, Maven is the right choice.
Also, no need to proxy both jcenter and maven central, see the following:
Why should I use jcenter over maven central
I am with JFrog, the company behind bintray and artifactory
Seems that Maven repository type is appropriate.
Predefined for proxing jcenter repository is Maven type.

How to check whether there are newer versions of library dependencies in an sbt/play/activator project

Is there any command in Activator that can list all the dependencies and libraries that I use with the current version and newer versions that is possible to use to update my project?
This is similar that the apache maven command versions:display-dependency-updates.
Is there any similar command available?
You're looking for sbt-updates, which is a plugin for sbt and activator.
Install the plugin and execute activator dependencyUpdates to see the list of outdated dependencies.

Including a non-Mavenized dependency so it works with maven-shade-plugin

I want to include GData Client, which doesn't use Maven, as a dependency into my Maven project. It ships as a bunch of JAR files.
Additionaly, I use Maven Shade Plugin to build an executable JAR without any external dependencies (with the default configuration, no renaming/including/excluding/transforming of dependencies).
How can I do that?
(Just adding the JARs as resources wouldn't work, since the Shade plugin must extract them).
you want to check the maven docs on installing 3rd party jars
Once installed into your local maven repository, shade should be able to use them like any other dependency.
See this answer if you don't want to install the JARs in your repository for whatever reason: Add a dependency in Maven

Resources