Baruch Sadogursky, recently joined JFrog as the Developers Advocate following years of working alongside JFrog’s founding team. Prior to joining JFrog, Baruch was an innovations expert with BMC Software Incubator team after 6 years with AlphaCSP as a senior Java consultant, architect and training division manager. Baruch is hacking around Java technologies and Continuous-Integration tools since 2001, including module development for open source projects like Gradle & Spring. Baruch is also active in community development around Artifactory, participating in the development of it’s plugin ecosystem and enriching it’s functionality with open-source user plugins. As JFrog’s Developers Advocate, Baruch contributes to the strong collaboration with leading open-source projects such as SpringSource, Grails and Gradle by providing them with the Artifactory Cloud platform, and fuels the Continuous-Integration ecosystem with open-source plugins for leading tools such as Jenkins, TeamCity & Bamboo. Baruch blogs at http://blogs.jfrog.org & blog.sadogursky.com and tweets as @jbaruch. Baruch is a DZone MVB and is not an employee of DZone and has posted 17 posts at DZone. You can read more from them at their website. View Full User Profile

Beat the binary repository developer (a.k.a. User Plugins)

11.18.2012
| 1456 views |
  • submit to reddit

From our experience with thousands of Artifactory users we know one thing for sure: we don't know better. Every organization does its ALM differently: artifact approval flow, snapshot retention policies, build-to-release flow, governance, needed metadata and much, much more - they are all different. We definitely have some ideas on how the build and deploy process should look, but there are so many things that make your process unique. And that's good. After all, you aren't paid for working within the ideal deployment cycle, but for solving a business problem. At least I hope so.

Acknowledging the fact that we don't know better complicates our lives as creators of a binary repository... and not only by hurting our ego. We want to give you the perfect tool for the job, but how can we do it without dictating to you what your job is? The solution is well known - extensions, a.k.a. add-ons, user plugins, you name it.

"OMG!", you might say. "Code! Joy-joy! Finally, an excuse to hack around!" Or "OMG! Code! It's your job to code those things into your product, not mine!" Look, either way, we don't have much choice, do we? When it comes to customizations,you have to tell Artifactory what you want it to do. We can only try to do our best to make it simple for you. So, we developed a simple DSL.

In this post, I'll show you how easy it is to customize Artifactory with user plugins. Here's the story: you want to prevent downloading of deprecated artifacts. The deprecation information is attached as custom metadata to the artifacts by some quality-assurance mechanism.

Let's say, for example, the artifacts to be banned from download are marked with property "deprecated=true". Artifactory allows you react (with code) to various events in the system. You can find the list of available callbacks in the User Plugins documentation. So, we are going to write Download plugin and the callback we are looking for is the altResponse. In this callback, we can provide an alternative response instead of the one Artifactory was asked for. Here's the code:

download {
   altResponse { request, responseRepoPath ->
     def deprecated = repositories.getProperties(responseRepoPath).getFirst('deprecated')
     if (deprecated && deprecated.toBoolean()) {
       status = 403
       message = 'This artifact was deprecated, please use some alternative.'
       log.warn "Request was made for deprecated artifact: $responseRepoPath.";
     }
   }
}

10 lines of code. That’s all. Let's examine them:

  • It's Groovy! If you are into it, good for you, enjoy! If you aren't, don't worry. It's amost like Java, so you'll read it without problems and will be productive from day 0.
  • It's super-simple. 
Here we go, line by line:
  1. Declares that it's a Download plugin.
  2. Defines the callback type we want (altResponse). When we are implementing alternative response Artifactory provides us with 2 objects:
  3. We want to get the first value of 'deprecated' property, if defined on the artifact represented by responseRepoPath.
  4. If the value exists and it is 'true', 1 or 'y' (as declared by toBoolean()) ...
  5. set return code to 403 (Forbidden) and
  6. set the correct error message and
  7. - optionally - issue warning to the Artifactory log.
Well, that's all. Now, when you saw that the dragon of user plugins isn't so scary, just think about the unique ways you cloud automate your delivery cycle, apply regulations and checks, or provide your corporate users with better Artifactory experience.Here are some samples and community contributed plugins to ignite your imagination.Enjoy your build!

This post was originally published at JFrog blog , you can comment here, or there.
Published at DZone with permission of Baruch Sadogursky, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)