An important aspect of the end-to-end development lifecycle is the creation and storage of software packages that are often binary artifacts. In the Java world, these are usually reusable jars that are used by other projects. Binary artifact repository managers are software systems that manage, version, and store binary artifacts. Examples of such repository managers are JFrog Artifactory, and Sonatype Nexus.

Here is the design overview of integrating TeamForge, a full ALM suite with binary repository managers.

What is a binary artifact repository?

A binary artifact repository stores binary artifacts along with the metadata in a defined directory structure, conceptually similar to a source code repository. The metadata describes the binary software artifact and includes information such as dependencies, versioning, and build promotions. Maven is the widely used tool for dependency management, especially for Java projects. Maven represents dependencies in an XML file called Project Object Model (POM). Other tools can use similar approaches to store documentation archives, source archives, Flash libraries and applications, and Ruby libraries.

How does a binary artifact repository manager help?

Some of the advantages of using a binary artifact repository manager are:

  • Dependency management: Nexus and Artifactory can act as Maven repositories. Maven is a widely used Java dependency management and build tool.
  • Efficient builds: With the help of a binary artifact repository manager, you can save the download time from public repositories as the artifacts once downloaded are cached locally.
  • Predictability and release stability: Once published onto a release repository, the binary artifact and metadata do not change. It ensures predictable and repeatable builds.
  • Control and audit: If you want to standardize libraries that are used in your software, the binary artifact repository helps track the versions of your software components. Also it enables you to audit the licenses of your third-party components used in your software.
  • Promotes collaboration: The binary artifact repository enables you to share components with other teams.

How to integrate Nexus with TeamForge?

TeamForge supports integration with Nexus in both the ALM and SCM modes. Nexus integration has been tested by CollabNet for Nexus and Nexus professional versions 2.9, 2.10, and 2.11.

To integrate Nexus with TeamForge:

  1. Download and install the Nexus OSS if you do not have a Nexus instance running.
  2. Download and install the CollabNet Nexus integration plugin.
  3. Change your build system and use the CollabNet supplied Maven deploy plugin for end-to-end traceability.
  4. Set up the TeamForge EventQ activity source to provide your teams with end-to-end visibility from requirements to source code all the way to deployed binary artifacts.

Install the TeamForge-Nexus Integration Plugin

You need to have the following information handy before you start off with the installation:

  • Installation path of the running Nexus instance.
  • TeamForge host’s URL.
  • TeamForge site administrator credentials.
  • A suitable name for your Nexus instance; the Binaries App in TeamForge refers to this name.

You must have a Nexus instance running for the integration. If you are upgrading from an earlier version of the plugin, ensure that the old plugin is completely removed from the directory and the new plugin is unzipped on the same directory before you restart the Nexus instance.

Accessing Nexus through TeamForge: You have to introduce a TeamForge project context in Nexus and allow authentication to use TeamForge credentials for logging into Nexus directly. Accessing Nexus through the TeamForge project toolbar provides you with Single Sign-on (SSO). It logs you into Nexus automatically with the project context. You can allow RBAC (Role Based Access Control) using TeamForge roles.

How to integrate Artifactory with TeamForge?

TeamForge supports integration with Artifactory in both the ALM and SCM modes. Artifactory integration has been tested by CollabNet for Artifactory Pro 4.7 or later.

To integrate Artifactory with TeamForge:

  1. You must have an Artifactory Pro instance running for the integration. Download and install the Artifactory Pro 4.7 or later if you do not have an Artifactory Pro instance running.
  2. Download and install the CollabNet Artifactory integration plugin.
  3. Change your build system and use the CollabNet supplied Maven deploy plugin for end-to-end traceability.
  4. Set up the TeamForge EventQ activity source to provide your teams with end-to-end visibility from requirements to source code all the way to deployed binary artifacts.

Install the TeamForge-Artifactory Integration Plugin

You need to have the following information handy before you start off with the installation:

Accessing Artifactory through TeamForge: You have to introduce a TeamForge project context in Artifactory and allow authentication to use TeamForge credentials for logging into Artifactory directly. Accessing Artifactory through the TeamForge project toolbar provides you with Single Sign-on (SSO). It logs you into Artifactory automatically with the project context. You can allow RBAC (Role Based Access Control) using TeamForge roles.

Authentication Policies

Nexus

Your site administrator can enable the integration with the following two authentication mechanisms:

  • TeamForge and native Nexus login (default)
  • TeamForge only In both the cases, you can use your TeamForge credentials to log on to Nexus. If your Site Administrator has used the default setup, you can use your pre-existing Nexus credentials.

Roles and Permissions

Following are the two administrative privileges in Nexus:

  • Nexus Admin (Site Admin in TeamForge will be a Nexus Admin)
  • Project admin (permissions to create, update, and delete binary artifact repositories.)

For all the other users, privileges are based on the TeamForge RBAC setup.
Artifactory

Your site administrator can enable the integration with the following two authentication mechanisms:

  • TeamForge and native Artifactory login (default)
  • TeamForge only

In both the cases, you can use your TeamForge credentials to log on to Artifactory. If your Site Administrator has used the default setup, you can use your pre-existing Artifactory credentials.

Roles and Permissions

  • Artifactory Admin (Site Admin in TeamForge will be an Artifactory Admin)
  • A user with any one of the following permissions in TeamForge becomes an Artifactory Admin: VIEW/CREATE REPOSITORIES, VIEW/UPDATE REPOSITORIES and VIEW/DELETE REPOSITORIES.
  • All other permissions in TeamForge are mapped as is in Artifactory.

For all the other users, privileges are based on the TeamForge RBAC setup.

TeamForge-Nexus Integration Plugin Release Notes

Here’s the release notes for TeamForge-Nexus integration plugin.

TeamForge-Nexus Integration Plugin v2.0

Name of the plugin: CTF-Nexus-Integration-Plugin-2.0.

Release Highlights

  • Usability of the Nexus installer (used to integrate Nexus with TeamForge) has been enhanced.
  • Improved peformance while loading Nexus UI.

Bug Fixes

  • When users log on to Nexus using CTF user credentials, the Nexus UI showed poor performance. This is fixed.
  • Fixed the time delay due to the presence of Nexus plugin in Maven builds.

TeamForge-Nexus Integration Plugin v2.0.1

Name of the plugin: CTF-Nexus-Integration-Plugin-2.0.1.

Release Highlights

  • Minor patch release.
  • Enhanced the TeamForge top navigation bar supported by Angular JS.
  • Released with TeamForge 16.7.

TeamForge-Nexus Integration Plugin v2.1.1

Name of the plugin: CTF-Nexus-Integration-Plugin-2.1.1.

Release Highlights

  • User session management between Nexus application and TeamForge integrated with Nexus has been handled in a much better way so that communication between TeamForge and Nexus happens smoothly as expected. This enhancement is done for the Nexus versions 2.9 through 2.14.
  • Improved peformance while loading Nexus UI.
  • Released with TeamForge 17.4.

Bug Fixes

  • Fixed the issue in which the 500: Internal Server Error was shown instead of 401: Unauthorized Error for any user activities in Nexus after a session timeout for the Nexus versions 2.9, 2.10, and 2.11. This fix is applicable for Nexus versions 2.9 through 2.14.
  • A 403: Forbidden error was shown as Nexus authentication failed for users whose session has timed out due to the expiration of OAuth token. This is fixed.

Also see: Known Limitations with TeamForge-Nexus/Artifactory Integrations

Known Limitations with TeamForge-Nexus/Artifactory Integrations

Here is a list of known limitations of TeamForge-Nexus/Artifactory integration.

TeamForge-Nexus Integration

  • While it is possible for users (all TeamForge users but site administrators) with ‘create repository’ permission to create binary repositories via the TeamForge Binaries application, such users cannot create repositories directly on the Nexus server (using the Nexus UI) as there is no TeamForge project mapping available in Nexus.
  • A TeamForge user cannot be configured as an anonymous user in Nexus as TeamForge users are not available in the Nexus database.
  • TeamForge broadcast messages and license notifications are not visible in Sonatype Nexus pages in TeamForge. This is due to a limitation with the TeamForge-Nexus integration plugin.
  • When the TeamForge Project administrator changes the existing binary permissions for a user, the changes will not immediately take place due to the cache implementation in Nexus to improve the performance of session handling. Due to this limitation, when a user tries to create a new Nexus repository, he will get the permission denied error. Hence the user must wait for the changes to take effect. However, the user can view the changes immediately on a standalone Nexus application by restarting his session on it.

TeamForge-Artifactory Integration

Artifactory repository names must be unique. You cannot have two or more repositories with the same name even if the repositories are of different types such as Remote or Hosted repositories. However, if you want to create two (or more) repositories with like-sounding names, you can devise and follow a repo naming convention to uniquely identify repositories of different types. For example, a “central” repo can be named as “central-local” and “central-remote” to uniquely refer to the “Hosted” and “Remote” repository types respectively.

Tags for this page: binaries authentication integration installation release_notes