Labels are one of the more powerful features, though they operate similar to other label or tagging systems you have likely used. Basically you create a number of labels or tags as a set of available values and then assign them.
For example in a photo collection you could have labels for the content like sunset', mountain, ocean, waterfall and so on. An individual photo could then have multiple of these labels assigned. In a similar way you can use labels to identify a particular type of component.
A common approach is to use labels to identify an approved component or a component that needs research. Labels can be anything you desire and can have a number of contexts as well. Some labels might be architecture related, while others are related to legal and security properties and yet others are simply signaling ownership by a specific team. The flexibility of the label system allows you to design your own use cases and implement them.
Label creation and management is performed in the Nexus IQ Server organization and application configuration. Assigning those labels to a particular component is a function of the Application Composition Report.
Initially, label assignment might seem like a task that deserves less process. It’s actually the opposite.
The label process actually starts at the Nexus IQ Server, where each organization, in many cases application, has a specific set of labels.
Creating labels at this level means that they are available to users of the Application Composition Report. So, before you label something, a number of things need to be considered, which might mean you need to go back to label and policy management. Let’s take a look at some questions that we can use to form a baseline to what labels we need and/or should have.
Do we have a process defining labels, as well as how and when they should be used? Every label should have a reason for using it. If it doesn’t you don’t need it. That’s because people will naturally infer meaning to the label. For example, if you have a needs review label, you should have a process for reviewing components with that label. It shouldn’t merely be a tag. You should also consider adding labels such as reviewed, so someone can tell if something was reviewed. The possibilities are endless, but this may mean you need to rethink the labels you have, or should create.
Should this label apply to only my applications, or all applications for this organization? We like to refer to this as the scope of a label. A good way to look at scope is the concept of macro and micro. At the macro level we have an organization that may have thousands of applications. If I apply this label to the component at the macro level (organization) it means the label will be seen by all applications under that organization. That’s a pretty sweeping change, and it could be the right thing to do. However, you might actually be better served by considering the impact at the micro level. In this case, maybe this is a label that should only be applied to a particular application.
Only labels that have been created at the organization level, can be assigned to the scope of organization. |
If I apply this label, is it part of a policy, and does it escape certain violations? Conditions in a policy can include values for labels. In many cases, this is best used as a way to prevent a certain component from violating the condition. For example, I could have a policy that requires a component to be no older than three years. However, a safe, and commonly used component is four years old. If I have a process built around reviewing a case like this, where an exception would be valid, I could first place labels to identify the component to be reviewed for an exception, and then another label once that exception is approved (or disapproved). In this scenario, if I have built policies correctly, including allowing them to flow through certain stages, even with a violation, development can continue. This of course should occur simultaneously to a review/exception process. It’s important to consider scenarios like this when creating labels, as well as policy.
There are more questions regarding labels that should be asked as well, but many of these you will discover as you develop your own processes. The key is that labels can be deceivingly simple, given their implementation in other systems. Now that you have the word of warning, let’s take a look at how to assign a label.
When assigning a label, you will only have access to those labels created specifically for the application, or for that application’s organization. Given this, if you don’t see a label you need, speak with whomever is responsible for managing the labels for your application and the organization the application is associated to.
Click the Label option from the CIP menu. Two boxes will be displayed:
If the label was created at the organization level, you will be presented with two options:
Terms of Service Privacy Policy
Copyright ©
2008-present, Sonatype Inc. All rights reserved. Includes the
third-party code listed here. Sonatype and Sonatype Nexus are trademarks
of Sonatype, Inc. Apache Maven and Maven are trademarks of the Apache
Software Foundation. M2Eclipse is a trademark of the Eclipse Foundation.
All other trademarks are the property of their respective owners.
Sonatype Headquarters - 8161
Maple Lawn Blvd #250, Fulton, MD 20759
Tysons Office - 8251 Greensboro Drive #610, McLean, VA
22102
Australia Office - 5 Martin Place, Level 14, Sydney 2000, NSW, Australia