Home > Blogs > VMware {code} > Monthly Archives: April 2017

Monthly Archives: April 2017

VMware {code} Open Office Hours: May 2 All Day, All Time Zones

Organized chaos

Organized Chaos” by schnaars is licensed under CC BY-SA 2.0.

VMware {code} keeps growing at a pretty decent pace. Our Slack just passed the 2,000 member-mark over night. That’s up 800 team members from the beginning of the year!

To celebrate, we’ll be doing open office hours next week. We want to hear your feedback, tell us what could be improved with the program, but also give you a chance to ask questions, connect with your peers and maybe discover a few features or services you weren’t familiar with yet. We also have more things planned for the rest of the year (content, events, swag etc.), so maybe there’s a chance to discuss those projects, too.

The VMware {code} community is international and spans the entire globe. In order to accommodate people in all time zones, we’ll do four 1-hour sessions throughout the day. Please find the schedule below.

Please note that cells marked light yellow indicate that for those sessions it‘ll already be the following day (namely, Wednesday, May 3), in your respective time zone.

City Time zone Session 1 Session 2 Session 3 Session 4
Palo Alto, CA Pacific Daylight Time (PDT) 06:00am 12:00pm 06:00pm 12:00am
New York City, NY Eastern Daylight Time (EDT) 09:00am 03:00pm 09:00pm 03:00am
Sao Paulo (Brazil) Brasília Time (BRT) 10:00am 04:00pm 10:00pm 04:00am
Berlin (Germany) Central European Summer Time (CEST) 03:00pm 09:00pm 03:00am 09:00am
Bangalore (India) India Standard Time (IST) 18:30pm 12:30am 06:30am 12:30pm
Beijing (China) China Standard Time (CST) 09:00pm 03:00am 09:00am 03:00pm
Tokyo (Japan) Japan Standard Time (JST) 10:00pm 04:00am 10:00am 04:00pm
Sydney (Australia) Australian Eastern Standard Time (AEST) 11:00pm 05:00am 11:00am 05:00pm

To join, just head to the #office channel on Slack when the time comes.

If you’re new to VMware {code}, make sure to register via the VMware {code} website first. Upon registration, you’ll automatically receive your personal Slack invite.

See you there!

Feedback Wanted on VMware Documentation

Survey results

Interim survey results

William Lam (@lamw), one of our R&D architects focused primarily on automation, integration and operation of VMware’s Software Defined Datacenter (SDDC), is seeking developer input regarding the state of VMware documentation. From his blog post:

Can you spare a few minutes for some feedback on VMware Documentation?

I am always looking for ways in which we can improve our products and documentation should be no different. In fact, documentation should be treated just as important as the product feature itself. I am very interested in your thoughts and comments and this will also help with a project I am doing internally at an upcoming R&D offsite.

If you haven’t done so already and have a few moments to spare, please consider sharing your thoughts. The survey is only eight questions long and can be found here: https://goo.gl/forms/cLaUhTMRAeZGpLxz1

Thanks!

The results will be shared sometime next month, presumably, and the blog post above already contains a selection of interim results.

HTML Client Plugin Seed: A Fast and Easy Path to Great vSphere Client Plugins!

This post was authored by Laurent Delamare, Staff Engineer at VMware.

This blog gives a brief overview of the HTML Client plugin-seed, a tool available on the vSphere Client Fling page. (Click on the drop down menu and download plugin-seed-<version>.zip, it comes with full documentation.)

In this post we assume that you are familiar with the HTML Client SDK 6.5 and its documentation. If you want to follow the instructions below you must first install the SDK on your Windows or Mac development machine, or install a newer HTML Client SDK Fling (download the file html-client-sdk-6.5.0-<build>.zip) which is a preview of things to come.

Introduction

The HTML Client plugin-seed is the best way to create vSphere Client plugins based on a modern tech stack and robust patterns. It includes a fast development process which will let you expand the initial plugin skeleton into your own version with great productivity.

  • It is based on the HTML Client SDK 6.5, so the generated plugins are compatible with both the HTML Client, version 6.5, and the Web Client, versions 6.0 or 6.5 (Flash-based). Plugin-seed doesn’t add any SDK API, it uses the SDK as-is and offers utilities that are not part of the SDK.
  • The UI layer is based on the Clarity Design System, a VMware open-source project which consists of UX guidelines, HTML/CSS framework, and Angular components. Using Clarity will also ensure consistency of your plugin UI with the rest of the vSphere Client.
  • It uses the latest Angular framework and the Typescript language which have become industry standards for enterprise applications on the web.
  • It generates plugins as Angular-CLI projects. It includes utilities and development tools that will speed up your dev cycles, help you design a good architecture, and set you up for proper testing.

Creating and running your first plugin in minutes

You create a plugin with the following command line, which will prompt you for a plugin name, a plugin directory, and a package name:

./plugin-seed/tools/generate-plugin.[bat, sh]

For instance, if you use the default name myplugin, the script creates two directories, myplugin-ui and myplugin-service, containing the UI component (which runs in the browser) and service component (which runs in the Virgo server).

The UI component, myplugin-ui, is a web app that you can instantaneously run in “dev mode” in your browser:

  1. As a prerequisite, you need to install the following tools:
  2. Go to myplugin-ui root directory:
    cd myplugin-ui
  3. Install the Javascript dependencies (one time operation):
    npm install
  4. Start json-server in a separate terminal (it is used to serve mock data):
    json-server --watch db.json --static ./src/webapp
    (or npm run json-server)
  5. Start the application in standalone dev mode with:
    npm start
  6. Point your browser to http://localhost:4201/ and see the initial plugin UI!

Plugin Dev Mode overview

The plugin application home page is made of an application header, a navigator on the left and a main view in the center. Only the main view contains the plugin content, the header and navigator are extra dev UI components:

Home page of the generated plugin running in Dev Mode.

Home page of the generated plugin running in Dev Mode.

The generated plugin includes the three types of views that can extend the vSphere Client UI:

  1. Global view, one that is not attached to a particular object context in the left navigator.
  2. Object view, included into a specific object workspace (Summary, Monitor, Configure).
  3. Modal view, used in response to actions, such as wizards, one-page dialogs, etc.

It demonstrates how to use mock data for vSphere objects (e.g. Hosts) or custom objects (e.g. Chassis).

Clicking on a Host on the left navigates to the object’s Summary, Monitor, and Configure views:

Host monitor view of the generated plugin running in Dev Mode.

Host monitor view of the generated plugin running in Dev Mode.

You can hide all dev UI by clicking on the top left (X) icon:

Hiding Dev UI

This shows the Monitor view without the “dev UI”, the way it will be displayed inside the vSphere Client:

Host monitor view of the generated plugin without the extra “dev UI”.

Host monitor view of the generated plugin without the extra “dev UI”.

Fast Development Cycle

Thanks to this dev mode approach you end up building your plugin UI as a standalone web application first, without involving the vSphere Client. This has many advantages:

  • You focus on the UI components and treat all views in a single page app without being encumbered with the vSphere Client environment.
  • The dev cycle is really fast: build quickly, prototype quickly, test quickly, and quickly fix any errors along the way!
  • You can use mock data easily to separate UI development and testing from backend services.
  • The “live data” mode allows to test the UI with your production backend.
  • End-to-end testing is simpler.
  • You may convert your plugin into another app later if necessary.

The next step is to modify and expand the plugin to match your actual use cases. For instance you may remove all chassis-related code (which demonstrates custom objects) and may want to create new views to extend the vSphere Client UI for virtual machines instead of hosts.

Because it is an Angular-CLI project, you can take advantage of the CLI commands to generate new components, directives, services, etc. You can also copy and modify the default plugin code which already contains many interesting patterns.

All your UI development can be done in an interactive manner while the app is rebuilding automatically after each change and refreshing in the browser (thanks to npm start), and while unit tests keep running in a separate terminal (using ng test).

Live Data Mode

Mock data is nice to start prototyping fast but at some point you also want to test with real data coming from backend services running in your local Virgo setup. This is possible with the Live data switch in the header! Using a simple setup described in the plugin-seed documentation, you can get the best of both worlds.

Same Host Monitor view displaying live Host and Chassis data from Java services.

Same Host Monitor view displaying live Host and Chassis data from Java services.

Plugin Mode

At any moment you can run the same code in “Plugin Mode”: Plugin Mode means deploying and testing your plugin with the vSphere Client. The same application is running inside each view which makes up your plugin. Instead of being one integrated app, your plugin views are accessible in each “extension” that you have declared in plugin.xml.

For instance:

  1. One global view extension as the main view.
  2. One global view extension as the settings view, in the client’s Administration area.
  3. One object view extension as the Monitor sub-tab for Hosts.
  4. One modal dialog for a menu action extension.

The view routing and how it applies to extensions in plugin.xml is described in more detail in the plugin-seed documentation, but you can see in the screenshots below that the plugin UI is automatically removed from any Dev Mode component. For a more info on SDK extensions in general see this doc.

The other difference with Dev Mode is that data access and service calls made from the UI go directly to back-end services instead of using the mock data server. (This is the same as the Live Mode available in the standalone app).

Plugin’s main view visible in the vSphere Client.

Plugin’s main view visible in the vSphere Client.

Plugin’s Host Monitor view visible in the vSphere Client.

Plugin’s Host Monitor view visible in the vSphere Client.

Fast Development in both Dev Mode and Plugin Mode!

Once you have deployed your plugin with your local vSphere Client server you can take advantage of both environments to keep developing and testing your plugin. All you need to do is keep the standalone app running with <code>npm start</code> on one hand, and to use the <code>gulp watch</code> script to refresh the plugin code on the Virgo server on the other hand: each code change will now be reflected both in dev mode and in the vSphere Client once you refresh the view.

Testing and packaging your plugin for production

Plugin-seed comes with many Jasmine unit tests that you can expand as you add code. Angular / Typescript tests are easy to write once you have a model to get started. End-to-end testing is done using Protractor.

Running the command ng test --code-coverage automatically generates test coverage information, which provides a nice HTML interface where you can drill down into directories and files to see details down to the source lines.

Code coverage map generated when running unit tests.

Code coverage map generated when running unit tests.

A plugin built with plugin-seed is packaged the same way other plugins are, please see Creating and Deploying Plug-In Packages in the HTML Client SDK 6.5 documentation.

There are several ways to optimize your Angular application for production:

  • Use ng build --prod --aot to build production code and use Angular’s AOT compiler for smaller bundle size and faster runtime.
  • Consider lazy loading components if you feel the loading performance should still be improved after using --aot. Plugin-seed includes such an example with the Settings view. The idea is to give the router a simple path to your lazy loaded modules, instead of a direct reference that would bring in all the code during the build. This way the module code is only loaded when you navigate to that particular view.

Other features of plugin-seed

Plugin-seed contains many other features or patterns that we don’t have time to cover here:

  • The app-alert.component for standard use notifications.
  • The common AppErrorHandler.
  • The RefreshService using Rxjs Observables to propagate a global refresh.
  • The i18nService to localize your UI in various languages
  • The NavService which encapsulates navigation actions between views.
  • The initialization of a global webPlatform object (no need to use web-platform.js anymore).
  • The WebPlatform interface containing the SDK apis in a typescript format.
  • The injection of modal components in a reusable DialogBoxComponent.

Conclusion

Although it is entirely possible to develop vSphere Client plugins with other UI stacks, and without the hybrid mode approach, we hope that after trying out plugin-seed for a short time you will appreciate what this stack and this development mode can bring you. Happy plugin writing!

SF Bay Area OpenStack Meetup: 04/12 Event Follow-Up

Q&A session at Prom C Cafeteria

Q&A session at Prom C Cafeteria

We had a great time last night at Prom C Cafeteria hosting the SF Bay Area OpenStack Meetup group yet once again. Well over a hundred people showed up! Thanks to everyone involved, particularly our excellent presenter, Nathan Ness (@nvpnathan).

For developers interested in peer-to-peer learning around a broad range of (more or less) VMware-related topics, please consider joining the VMware {code} program. Our 3,000 members, a growing list of 50+ Slack channels, in-person and online events as well as a tools like our API Explorer and Sample Exchange provide great opportunities to learn, code and connect. Sign up for free, and we’ll send you your personal Slack invite right away.

As always, we welcome your feedback. Leave a comment below or over on the Meetup event page, or find us on Twitter or Slack. Thanks!

Slide and video recording below:

PS: Thanks to the healthy appetite of our guests there wasn’t all that much food left. We were able to donate the leftovers to Julian Street Inn in San José, CA.

Getting Started with the vSphere Automation SDK for Python

We’ve been looking at how to get started using the new vSphere Automation SDKs. In the last couple parts of the series we looked at the SDK for REST, which included Postman REST client samples, as well as some JavaScript samples. This time, we’ll be looking at the vSphere Automation SDK for Python!

Prerequisites

There are a handful of ways to install and setup Python on your workstation, I will be walking through a high level configuration for my Mac.

First things first, clone the vSphere Automation SDK for Python from the VMware GitHub repository located here.

Cloning the Python SDK repo

After that’s complete, we’ll need to install the Python prerequisites. These include the GNU Complier Collection (GCC), a C compiler, and HomeBrew, a package management system.

GCC can be installed in multiple ways, but I’ve found it’s easiest to obtain it by installing the Xcode Command Line Tools. This can be done with the following command, then following the prompts:
xcode-select --install

XCode Installation

Next, we’ll need to install the package manager, Homebrew. It can be easily downloaded and installed with the following command: /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Homebrew Installation

Finally, we’ll install Python in the recommended version of 3.6. It’s worth noting here that Mac OS X comes with a version of Python already installed. However, it is generally an older version (normally, Python 2.7) and is used for some system related tasks. Due to that, it is best not to modify that version or the defaults.

Utilizing our package manager, we’ll install Python 3.6 with the following command:
brew install python3

Python 3.6 Installation

It’s also recommended to isolate your development environments from each other so, we’ll setup a virtual environment and jump into it. We can do that with the following commands:
python3 -m venv SDKDemo
source SDKDemo/bin/activate

Creating a virtual development environment

Lastly, we’ll install the SDK requirements. They’re listed within the root of the SDK folder in the file labeled: requirements.txt. After checking out which requirements are necessary, we’ll install those requirements by way of the following command:
pip3 install -r requirements.txt

Requirement Installation

One other item worth mentioning is an IDE. This will make editing, running and debugging the code a lot easier to deal with. I’ll be using PyCharm, which is available here.

Running Sample Setup Script

To really show off the capabilities of the SDK, there’s a sample script which takes an un-configured vSphere environment and performs all of those normal configuration steps. The environment requirements to run the script are as follows:

  • 1 vCenter Server
  • 2 ESXi Hosts
  • 1 NFS Datastore (minimum of 3GB free)

We’ll first need to open up the testbed.py file and populate lines 17 through 29 as follows:

Modification of the Testbed File

We’re now ready to set the environment up with the sample script! However, before running the script we should take a look at what it’s doing. The script is available in the SDK directory at: /bin/run_sample.sh The goal of the script is to do the following actions:

  • Create 2 Datacenters
  • Create a Cluster
  • Create Test Folders for VM Storage
  • Attach the Hosts
  • Create a Distributed Switch
  • Create a Distributed PortGroup
  • Attach the NFS Datastore (if Selected) to the hosts
  • Copy the Photon OS ISO image downloaded from VMware’s bintray server to the Datastore
  • Create directories to add sample ports

One note before running the script, the ISO image being downloaded is roughly 200MB and could take a while depending on your bandwidth. My tests ranged anywhere between 30 seconds and 5 minutes.

The sample script can be run with the following command:
./run_sample.sh ../samples/vsphere/vcenter/setup/main.py –sv

Configuring an environment with the main.py file

Create a VM with Defaults

Now that our environment is setup, let’s take a look at adding a VM to this environment. The easiest way is to create a default VM. This action means the API takes care of all the configuration settings based on the Guest OS version. There are some prerequisites that are required for placement such as desired datacenter, VM folder, and datastore. These are all referenced from the testbed.py configuration file we referenced in the first example.

Updating the Testbed File for VM Tasks

The VM can then be created with the following command:
./run_sample.sh ../samples/vsphere/vcenter/vm/create/create_default_vm.py –v

Default VM Creation Sample

Notice in the above example how even though we didn’t populate all of the settings, the VM received required items like a CPU, a disk, and so forth.

To verify the VM does indeed exist, we can obtain a list of VMs with the following command:
./run_sample.sh ../samples/vsphere/vcenter/vm/list_vms.py –v

List VMs Sample

VM Power Actions

The next logical step after creating a VM is to power it on. There’s a sample within the vm folder named power.py, which shows off all of the power actions. This file references the ‘VM_NAME_DEFAULT’ input from the testbed.py file.

When running the command as is, the VM will be put through the following power states:

  • Obtain current power state
  • Power Off (NOTE: Only if the VM is currently powered on)
  • Power On
  • Suspend the VM
  • Resume the VM
  • Reset the VM

The command can be run with the following:
./run_sample.sh ../samples/vsphere/vcenter/vm/power.py –v

VM Power State Sample

Summary

This post shows you how to easily get started with the vSphere Automation SDK for Python. It takes you through the setup of an entire environment, as well as using the individual samples. You can then take whichever is most relevant to you and apply to your environment or, pull parts of this code out and use it to automate or integrate as needed.

With our SDK now being open sourced, we are intent on making sure these samples are of a high quality. If you notice areas of improvement, or come up with some new samples, please feel free to raise issues or pull requests on our GitHub repository.

DRC2017 Follow-Up: Developer Relations at VMware

At last week’s 13th Annual Evans Data Developer Relations Conference in Palo Alto, CA, our very own Larry McDonough (Director, Product Management, Ecosystem Tools) got to talk about VMware’s ongoing efforts to build a developer relations program that can meet its various stakeholders’ needs:

Larry McDonough, VMware – Director Product Management, Ecosystem Services
DevRel Judo: Leveraging your company’s organizational structure to build a stronger Developer Relations team
Developer Relations is traditionally a centralized function, but what if you don’t have a dedicated DevRel team? Can a decentralized DevRel team succeed? This presentation will highlight the dynamic and sometimes rocky journey that VMware has travelled regarding Developer Relations and the pros and cons of a decentralized structure. I’ll talk about identifying and understanding developer personas, sharing standard developer relations functions across business units, managing resources and clarifying responsibilities, the importance of relationships with the product teams, and of course, constructing analytics to measure shared progress and success. The purpose is to help you strengthen your devrel teams by exploring your own company’s structure, it’s impact on your success and how you can leverage it’s strengths to improve developer outreach.

Check out Larry’s slides below:

If you have feedback or ideas how we can grow the VMware {code} program and further improve our developer relations efforts, you know what to do: leave a comment below, tweet us, or ping us on Slack.

As always, we value your feedback. If you’ve seen great things other communities are doing that we’re still missing, let us know: leave a comment below or ping us on Twitter or Slack.

Not a member of VMware {code} yet? Register for free: code.vmware.com/join

Common Packaging Pitfalls When Developing vSphere Client HTML Plug-ins

This post was authored by Ina Uzunova, Product Owner of vSphere Client SDK, and Vladimir Velikov, vSphere Client SDK Engineer.

The official vSphere Web Client SDK Documentation of vSphere 6.5 contains important best practices for developing your HTML based vSphere Client Plug-in which are explained in chapter “Best Practices for Developing Extensions”.

A common source of mistakes when building a vSphere Client plug-in is packaging: the way the final vSphere Client plug-in deliverable is built, released to end users and deployed in production environments.

There has been a number of error-prone techniques that were encountered with previous releases. The goal of this post is to address the most common pitfalls when packaging your plug-in and the negative impact those have on your plug-in’s design and operation.

vSphere Client plug-in structure

Each vSphere Client plug-in consists of the following elements:

  • Plug-in manifest: the plugin-package.xml file where the plug-in defines its ID, version, general information and compatibility constraints.
  • Set of plug-in bundles: the plugins/ folder with the plug-in UI bundle (.war), the plug-in Java service bundles (.jar) and all external library bundles (.jar) the plug-in depends on.
    These .war and .jar files need to be correctly defined OSGi bundles with a valid MANIFEST.MF.

Common plug-in packaging mistakes

Here are a few common plug-in packaging mistakes with their impact and improvement recommendation:

A) Errors in the plug-in manifest metadata (plugin-package.xml)

  1. Using wrong company name – “id” and “vendor” attributes do not refer to the correct company name
    1. Error example: <pluginPackage id="com.mycompany1.myplugin" version="1.0" vendor="MyCompany2">
    2. Impact: The plug-in is displayed with wrong information on the UI and might clash with the “id” of another plug-in.
    3. Recommendation: use your company name for all “id”-s in the plug-in.
  2. Dependency on another plug-in – “pluginPackage” dependency tag refers to a plug-in which is not part of vSphere Client
    1. Error example: <dependencies><pluginPackage id="com.mycompany2.plugin2" version="1.0"></dependencies>
    2. Impact: The plug-in lacks integrity and autonomy. The target plug-in might not exist in the system but even if it does it now lives in its own dependency scope (in isolation) which makes it inaccessible by your plug-in. As a result your plug-in might fail during deployment or at runtime.
    3. Recommendation: Depend only on vSphere Client plug-ins (e.g. “com.vmware.vsphere.client”)
  3. Dependency on plug-in bundles – “pluginPackage” dependency tag refers to a plug-in library or OSGi bundle
    1. Error example: <dependencies><pluginPackage id="com.vmware.vim25" version="1.0"></dependencies>
    2. Impact: The plug-in will not be deployed by vSphere Client. The plugin-package.xml expects plug-in dependencies, not library/bundle dependencies.
    3. Recommendation: Remove any library/bundle dependencies.
  4. Plugin version is incorrectly specified as a tag
    1. Error example: <version>1.0</version>
    2. Impact: The plug-in manifest will be unreadable by vSphere Client and your plug-in will not be deployed.
    3. Recommendation: Specify the plug-in version as attribute (e.g. <pluginPackage version="1.0" ...>)

B) Problems in the plug-in bundles (.jar and .war files in the plugins/ folder)

  1. Split packages – two or more plug-in bundles export the same package id
    1. Error example: Two .jar bundles contain com.mycompany1.package1 in the Export-Package section of their MANIFEST.MF.
    2. Impact: The plug-in will not be deployed by vSphere Client in isolation (default).
    3. Recommendation: If the two packages are part of the same feature move all respective classes to the same bundle to make it explicit. If the two packages represent different features rename one of the packages to indicate this conceptual difference.
  2. Packaging the vSphere Client SDK deliverable
    1. Error example: The plug-in contains vsphere-client-lib.jar.
    2. Impact: Increased size of your plug-in. This jar is not an OSGi bundle and will be ignored during deployment. It is not intended for being packaged with the plug-in but for building the plug-in against the public set of Java APIs which are anyway available at vSphere Client’s runtime.
    3. Recommendation: Remove vsphere-client-lib.jar from the plug-in.
  3. Packaging libraries without OSGi manifest
    1. Error example: The plug-in contains a .jar/.war with no MANIFEST.MF.
    2. Impact: Increased size of your plug-in. The specified .jar/.war is not an OSGi bundle will be ignored during deployment.
    3. Recommendation: If the library is not used remove it from the plug-in. Otherwise, convert the library into an OSGi bundle by adding a MANIFEST.MF.
  4. Importing packages from nested libraries – a plug-in bundle both embeds a library and imports a package from it
    1. Error example: A plug-in .jar/.war bundle’s MANIFEST.MF contains Import-Package section with com.mycompany1.package1 and Bundle-Classpath section with my-internal-lib.jar.
    2. Impact: The plug-in will not be deployed. The internal library is not an OSGi bundle so it does not export any packages that your bundle can import.
    3. iii. Recommendation: Remove the package import. The library is already available for direct use by the bundle because it is part of its classpath.

C) Plug-in interoperability issues with vSphere Client

  1. Delivering one or more plug-in bundles built with a higher Java version than vSphere Client supports.
    1. Error example: A plug-in .jar/.war bundle is built with target Java version 8 while target vSphere Client version contains bundles built with Java 7.
    2. Impact: The plug-in will not be deployed.
    3. Recommendation: Follow the environment requirements from the official documentation. Pay attention to what target Java compiler compliance level should be specified for your plug-in bundles.
  2. Packaging 3rd party libraries which are already delivered by vSphere Client
    1. Error example: The plug-in contains a javax.servlet-api.jar bundle.
    2. Impact: Increased size of your plug-in and possible plug-in problems if any operations refer to APIs not present in the vSphere Client’s version of the library. At runtime vSphere Client will always deploy its required 3rd party dependencies first and plug-ins will always consume them even if they bring their own version of the library.
    3. Recommendation: Remove any 3rd party libraries from your plug-in which have counterparts in the server/repository/usr folder of vSphere Client’s server. Note that you need to check the Bundle-SymbolicName in the MANIFEST.MF of the .jar bundle as the .jar file name is not always sufficient to be sure if the bundle maps to one of your plug-in bundles.
      Common libraries delivered by vSphere Client to watch out for are:

      • Spring libraries
      • Jackson libraries
      • servlet, javax.servlet-api, javax.transaction
      • apache.commons.logging
      • joda-time
  3. The plugin is using the global context class loader.
    1. Error example: The plug-in tries to load resources it delivers using the global context ClassLoader.
    2. Impact: The plug-in will fail during deployment or at runtime because it is unable to load the required resource. The reason is that plug-ins are now deployed in isolation by default which makes plug-in resources not directly visible to the global context ClassLoader.
    3. Recommendation: Use current bundle class loader for loading resources (e.g. temporarily change the context ClassLoader with Thread.currentThread().setContextClassLoader(getClass().getClassLoader())).

Cleaning up the aforementioned drawbacks that might be present in your plug-in would facilitate its smooth deployment, operation and interoperability with vSphere Client. In addition, plug-ins would benefit from better design, smaller zip deliverables and faster deployment times.

For more hints check the Best Practices listed in the official vSphere Web Client SDK Documentation or refer to the other blog posts on Building vSphere Client plug-ins and OSGi-Specific Best Practices