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
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.
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.
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?
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:
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?