I have a group on GitLab with two projects, and I wish to use the group level maven endpoint so that each project can reference one repository URL for the group instead of each project needing to know the specific project repositories.
However, I cannot seem to get it to work. I can build a library and push its artifact to the repository, and another project can find it with the project level maven endpoint. However, when I use the group level repository URL as described in the document, replacing my-group with my group, the build fails because it "Could not find artifact". Has anybody got this to work?
<repositories>
<repository>
<id>gitlab-maven</id>
<url>https://gitlab.com/api/v4/groups/my-group/-/packages/maven</url>
</repository>
</repositories>
For anybody with the same problem, I was able to make it work with the group ID.
Related
In the team I work for, I need to deploy site artifacts to a maven repo in the following format:
http://therepo/site/${project.groupId}/${project.artifactId}/${project.version}
Because I'm a big fan of doing things in a DRY manner, I have put this in my parent pom within a distributionManagement tag. Like so:
<distributionManagement>
<site>
<id>team-site</id>
<name>Team Snapshot Site Repository</name>
<url>dav:http://therepo/snapshot/site/${project.groupId}/${project.artifactId}/${project.version}</url>
</site>
</distributionManagement>
This seems reasonable except that the maven site plugin will automatically add the project artifact id to the end of the URL if the URL is provided by a parent pom. This behavior is documented here: https://maven.apache.org/plugins/maven-site-plugin/usage.html#Deploying_a_Site
Obviously this isn't what I want to happen. As a result of this behavior, my site URL effectively becomes:
http://therepo/site/${project.groupId}/${project.artifactId}/${project.version}/${project.artifactId}
Is there a way to suppress this behavior? Or do I have to put a distributionManagement tag in every single project?
Thanks!
When specifying the repository element why we need snapshots and releases as well?
Example:
<repository>
<id>my-repo</id>
<url>https://some.url.com/my-repo</url>
<snapshots>
<enabled>false/true</enabled>
</snapshots>
<releases>
<enabled>false/true</enabled>
</releases>
</repository>
How it affects a specific version of the dependency? (1.2.3-SNAPSHOT, 1.2.3, 1.2.3-RELEASE)
When there are multiple repositories, which repository will be searched for the artifact? How the artifacts being resolved?
When specifying the repository element why we need false/true and as well?
We need to do so if we would like to have a repository only for released versions, for instance, and another one only for SNAPSHOT versions.
This is a common use case for enterprise Maven repositories (i.e. Nexus, Artifactory, Archivia), when certain versions (like SNAPSHOT) are only available in a repository (deployed but a CI job, as an example) while released versions would only be available in another repository. A CI job releasing something for PROD should only use the latter repository, not using/allowing any SNAPSHOT version and breaking the build otherwise (enforcing build reproducibility and good practices).
From official Maven Settings documentation
releases, snapshots: These are the policies for each type of artifact, Release or snapshot. With these two sets, a POM has the power to alter the policies for each type independent of the other within a single repository. For example, one may decide to enable only snapshot downloads, possibly for development purposes.
enabled: true or false for whether this repository is enabled for the respective type (releases or snapshots).
When there are multiple repositories , which repository will be searched for the artifact? How the artifacts being resolved?
The order of declaration will affect the look up order used by Maven. Check this official Maven ticket providing the fix for the proper behavior from version 3.0 on.
MNG-4400: Repository order from settings.xml is not respected during artifact resolution
How it affects a specific version of the dependency? (1.2.3-SNAPSHOT, 1.2.3, 1.2.3-RELEASE)
Merging the two answers above, depending on the order of declaration and which repository allow which type of artifact (snapshot or not).
Further references:
Maven: working with multiple repositories
Maven Settings
Maven: introduction to repositories
I am using artifactory for artifacts management .To upload my artifacts to the server i have below lines added to my pom.xml
<distributionManagement>
<repository>
<id>e512209f3d01</id>
<name>e512209f3d01-releases</name>
<url>http://server-cicd-01-ubt:8081/artifactory/ext-release-local</url>
</repository>
<snapshotRepository>
<id>e512209f3d01</id>
<name>e512209f3d01-snapshots</name>
<url>http://server-cicd-01-ubt:8081/artifactory/ext-snapshot-local</url>
</snapshotRepository>
</distributionManagement>
but i do not want these settings to be in pom.xml.Is there any way i can define in global setting.xml. What will be the syntax for that.
In a similar need, we implemented a super pom, which is a single file component (pom.xml only) that declares all common properties and settings to be used by all components developed in our R&D group.
We mostly define common properties like dependencies versions strings and also the section is there.
Every component needing this needs to declare the super pom as its parent:
<parent>
<groupId>com.mycompany</groupId>
<artifactId>super-pom</artifactId>
<version>1.0.1</version>
</parent>
This works very well for us for managing 100s of components in the system, which all share common properties.
You can add may common elements like plugins, dependency management etc.
I hope this helps.
The artifactory website lists 6 types of repo and claims this naming schema is best practice:
I have 2 questions,
What should be stored in plugins-* repos. Please give a concrete example. I don't understand why plugins should have a separate repo.
Where is this best practice documented?
https://www.jfrog.com/confluence/display/RTF/Local+Repositories
libs-release-local = Your code releases
libs-snapshot-local= Your code snapshots
ext-release-local = Manually deployed 3rd party libs (releases)
ext-snapshot-local = Manually deployed 3rd party libs (shapshots)
plugins-release-local = Your and 3rd party plugins (releases)
plugins-snapshot-local = Your and 3rd party plugins (snapshots)
Artifactory makes this distinction only because Maven makes it. This is to be consistent with Maven.
In Maven, repositories for dependencies and repositories for plugins are declared in 2 differents tags: namely <repositories> for dependencies and <pluginRepositories> for plugins.
Plugin repositories are used to declare dependencies toward plugins. For example, the maven-compiler-plugin is correctly resolved by Maven because a <pluginRepository> is defined in the Super POM (that actually points to Maven Central). If you were to develop a Maven plugin, internal to your company, it would be best to store it inside the plugins-* repo.
There isn't any official page (that I could find at least) regarding this "best practice", but do note that quoting the Maven docs (emphasis mine):
Repositories are home to two major types of artifacts. The first are artifacts that are used as dependencies of other artifacts. These are the majority of plugins that reside within central. The other type of artifact is plugins. Maven plugins are themselves a special type of artifact. Because of this, plugin repositories may be separated from other repositories (although, I have yet to hear a convincing argument for doing so). In any case, the structure of the pluginRepositories element block is similar to the repositories element. The pluginRepository elements each specify a remote location of where Maven can find new plugins.
I see several options:
directly in pom.xml
in company super-pom
in settings.xml (global or user)
in a profile or directly (in settings.xml or pom.xml)
We want our Jenkins to push artifacts to internal repository, and developers to pull missing artifacts from there.
If I put the repository URL in pom.xml, and later the internal repository is moved to a different address, the released versions will all have a broken link.
Super-pom saves some repetition, but in a clean setup you need to somehow know where the repository is to find the parent POM — to tell you where the repository is.
Having the URL in settings allows one to change it without modifying the artifacts, but there are two problems:
build will fail due to unresolved dependencies, if maven settings have no reference to the internal repo
developers have to update their settings.xml files manually
I'm also unsure about the merits of putting repository configuration in profiles. I know it let's you easily switch the repositories on and off, but shouldn't the -o option and snapshot resolution settings be enough for most uses?
What about using a different repository (e.g. with instrumented classes) for integration tests?
Configure a single repository in the users ${HOME}/.m2/settings.xml and configure other needed repositories in your appropriate repository manager either Nexus, Artifactory or Archiva. In Jenkins there is the Config File Provider plugin which exactly handles such situations in a very convinient way.
If you want to have repeatable builds and good control over your organization internally, use a repository manager and use a mirrorOf entry in everyone’s settings.xml to point at that url.
If you are exposing your source and want to make it easy for others to
build, then consider adding a repository entry to your POM, but don’t
pick a URL lightly, think long-term, and use a URL that will always be
under your control.
http://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/