Component 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 component labels to identify a particular type of component.
A common approach is to use component labels to identify an approved component or a component that needs research. Component labels can be anything you desire and can have a number of contexts as well. Some component 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 component label system allows you to design your own use cases and implement them.
Component label creation and management is performed in the IQ Server Organization & Policies Management area. Assigning those labels to a particular component is a function of the Application Composition Report.
Initially, component label assignment might seem like a task that deserves less process. It’s actually the opposite.
The component label process actually starts at the IQ Server, where each organization, in many cases application, has a specific set of component labels.
Creating component 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 component label and policy management. Let’s take a look at some questions that we can use to form a baseline for what component labels we need and/or should have.
Do we have a process defining component labels, as well as how and when they should be used? Every component 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 from the label. For example, if you have a needs review component label, you should have a process for reviewing components with that label. It shouldn’t merely be a tag. You should also consider adding component 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 component labels you have, or should create.
Should this component label apply to only my applications, or all applications for this organization? We like to refer to this as the scope of a component 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 assign this label to the component at the macro level (organization) it means the label will be seen by all applications under that organization. A component label at the root organization will have an even larger scope. 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 component label that should only be applied to a particular application.
Only component labels that have been created at the root organization, can be assigned to the scope of root organization or organization level. Only components created at the organization can be assigned to the scope of organization. |
If I assign this component label, is it part of a policy, and does it escape certain violations? Conditions in a policy can include values for component 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 component labels to identify the component to be reviewed for an exception, and then another component 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 component labels, as well as policy.
There are more questions regarding component labels that should be asked as well, but many of these you will discover as you develop your own processes. The key is that component 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 component labels created specifically for the application, or for that application’s organization, or the root organization. Given this, if you don’t see a label you need, speak with whomever is responsible for managing the component labels for your application and parent organizations.
Click the Labels 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:
If the label was created at the root organization level, you will be presented with three 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