VMware Cloud Community
yatigammanabnd
Enthusiast
Enthusiast
Jump to solution

is it possible to build a plugin without the vRO url specified?

Ok, so the reason I ask this is because today my build hung (mvn clean install ...) because it was trying to download things from our vRO instance. Unfortunately, vRO was not behaving properly for reasons, so what the build was doing was... happily waiting for a response, for 4 hours!

Now ideally, it would have been nice if maven had given up. But it got me thinking, why does the plugin require a running vRO instance to act as a repository to download resources from to maven build a plugin?

So that is my question;

Can I change the pom.xml such that maven does not require my own running vRO instance, but instead can download the resources elsewhere from the internet?

Any thoughts would be helpful

Thanks

Tags (1)
Reply
0 Kudos
1 Solution

Accepted Solutions
iiliev
VMware Employee
VMware Employee
Jump to solution

You have several options:

1) If you already did a successful plug-in build before (when vRO instance has been working normally), the vRO-specific Maven artifacts are already downloaded and available in your local Maven repository, so assuming you haven't changed the POM file of the plug-in to reuire some new dependencies, you should be able to build the plug-in in so-called offline Maven mode. The command line option for doing so is --offline (or -o for short).

2) Alternatively, you can manually download the vRO specific Maven artifacts from the Mave repository hosted inside vRO appliance (under /var/lib/vco/downloads/vco-repo/ folder on the appliance's file system), and the install them manually in your local Maven repository. A bit more work, but doable.

View solution in original post

Reply
0 Kudos
4 Replies
iiliev
VMware Employee
VMware Employee
Jump to solution

You have several options:

1) If you already did a successful plug-in build before (when vRO instance has been working normally), the vRO-specific Maven artifacts are already downloaded and available in your local Maven repository, so assuming you haven't changed the POM file of the plug-in to reuire some new dependencies, you should be able to build the plug-in in so-called offline Maven mode. The command line option for doing so is --offline (or -o for short).

2) Alternatively, you can manually download the vRO specific Maven artifacts from the Mave repository hosted inside vRO appliance (under /var/lib/vco/downloads/vco-repo/ folder on the appliance's file system), and the install them manually in your local Maven repository. A bit more work, but doable.

Reply
0 Kudos
yatigammanabnd
Enthusiast
Enthusiast
Jump to solution

Thanks!

I think this will cover me nicely (as I do have the dependencies).

I also take it that there isn't a publicly available version of any of the dependencies, and so to build a vRO plugin requires a vRO instance running to get the libraries in the first place?

With that in mind, do you know if different vRO versions differ by much in terms of the libraries they provide? I imagine minor version changes won't be different, but will major versions be different such that I should build my plugin for each vRO major version?

Reply
0 Kudos
iiliev
VMware Employee
VMware Employee
Jump to solution

For now, the only 'official' way to get these libraries is via the Maven repository hosted on standalone vRO appliance.

We try to preserve backward compatibility on plug-in API level, so if your plug-in consumes only plug-in related libraries (like o11n-sdkapi, etc.) there is a very high probability that plug-in built against vRO 7.3 will deploy and run without problems in later vRO 7.x. The usual source of incompatibilities are:

  • The plug-in uses its own way of doing things instead of utilizing the services provided by vRO platform. A typical example would be a plug-in that stores its configuration directly as a file on the local file system instead of using the standard vRO configuration API.
  • The plug-in uses not only plug-in related libraries from vRO platform, but also other vRO libraries like o11n-utils. These libraries are not meant to be used by plug-ins directly, and most of the changes in them are not backward compatible.
  • The plug-in uses 3rd party libraries that are also part of vRO server, like Spring, Hibernate, etc. We constantly update these libraries in every new vRO version, so it is possible that a plug-in compiled against a particular version of such library to find a newer version of the same library at runtime. Depending on the library, this might, or might not be, a problem. This risk could be mitigated to some extent by bundling the 3rd party libraries the plug-in uses inside the plug-in library, and configuring plug-in class loader to use only these internal libraries instead of vRO platform libraries. In general, though, this shouldn't be the default option as it will significantly increase the size of the plug-in and its memory consumption.
yatigammanabnd
Enthusiast
Enthusiast
Jump to solution

Just so I am super clear on this, 3 cases:

* a plugin built against any vRO 7.x will have a very high probability of working with any vRO 7.x version (up or down the minor version numbers) - with the caveats you have outlined.

* but a plugin built against 7.x will not work with a future 8.x version?

* and a plugin build against 8.x should work with the previous 7.x version (given the attempt at preserving backwards compatibility)

Is the above correct-ish, or have I generalised too far?

Reply
0 Kudos