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.
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?
1 person found this helpful
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.
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?