We have been getting lots of questions around how developers and architects can reference open source components, WSDLs or other binaries that are under governance in their workspace?    Dr Gili Mendel recently wrote an explanation on this that I wanted to share with you below.   By referencing the artifacts in the DSL you prevent teams from having to repeatedly copy asset artifacts around or version the same component multiple times in different SCM systems.   This has the added benefit of allowing you to control access to these components and shut them off when licenses expire or the asset artifacts are no longer supported.

“How does the workspace know how to consume one of these linked artifacts, such as an open source component”

Workspace Link to a RAM artifact

When you “drag” an artifact from a RAM repository into your workspace, the RAM plugin brings down the  file to your workspace (so that you can use it disconnected as well), but it marks it as a derived resource.  A derived resource will not be checked in/out a SCM by Eclipse…. similar to a compiled .class file.


The RAM plugin will also create a link (an entry for that artifact in a control file see image below).   This control file (or changes to this control file) will be checked into the SCM.   When another user checks out this file (or changes to this file), the RAM plugin will parse it, and will bring down the artifacts to that users as well.


The build process can use RAM provided Ant scripts, Ant lib. calls, or Java Calls to bring down “linked” artifacts.   These calls look for the rambuildercontrol.xml file and act on it in a headless environment

Traceability when publishing an artifact into RAM

The Eclipse client provides an asset packaging editor that allow you to provide information about the asset (name, description, version….) as well as a collection of resources from your workspace.   When press the submit/update button, the editor will baseline the projects involved (if it is a TEAM based project, like CVS, Rational Team Concert, Subversion, ClearCase….) and publish the asset annotating (the server, baseline id and such) the artifact with the origin’s information.   The build process, as I noted in the demo,  annotated the .ear with a the build id, and a link back to the BuildForge job or other build automation software.

When a user consumes an asset in Eclipse, the Rational Asset Manager plugin will look for these traceability annotation on the artifacts.   If they exist, the plugin will give you the option to attach to the baseline, or the latest stream level.

This week we had the Rational Voice event, where we meet with a select group of customers to discuss our product road maps and do a deep dive on product capabilities.   I wanted to share the slides we presented at the deep dive session on how to define an asset governance model in Rational Asset Manager v7.2 .  In the session we covered what the governance constructs were in Rational Asset Manager and what the best practices are for establishing a definitive software library.   Here are the slides. If you are interested in participating in future Rational Voice events send me an email and I can get you added to our select group of customers that are invited to the event.  carlos.ferreira at us.ibm.com