We run a CA Release Automation (Nolio) instance with an embedded Nexus instance. In this embedded Nexus instance there are a number of jar artifacts that are related to Nolio actions which are required dependencies when trying to compile custom developed action packs, e.g. nolio-actions-shared.jar. We're trying to setup a CI build system to aid in the development of these custom developed action packs, however, when we try to use Maven which is configured with the required dependencies the build fails. This is because the jar artifacts that are stored in this embedded Nexus instance aren't stored with Maven metadata and pom files, so can't be found by Maven. Is there any reason that the jar file artifacts aren't stored in this embedded Nexus instance as "correct" Maven artifacts?
I would need to check with engineering on this one, I would imagine the reasoning behind this would be in most scenarios recompiling core components like the shared actions jar mentioned would not be advised/supported.
Does anyone have experience of this or similar and any workarounds that worked for them? I don't particularly want to take these jar artifacts and upload them as proper Maven artifacts into a different Nexus instance and then reference that other Nexus instance in our CI build. Therefore I'm thinking that the best option would be to do something in the embedded Nexus instance to generate the required Maven metadata/pom files, either rebuilding the indexes somehow or uploading the files into this Nexus instance again. Is it safe to do steps like this on this Nexus instance to generate maven metadata/pom without any impact to the running CA Release Automation platform?
I will check with engineering to see if these can be provided, however there are a lot of dependencies for certain jars that I do not imagine we would be able to provide, but I will check. As far as whether or not it is safe to do steps like this while deployments are running, as long as you are not actually replacing the referenced jar(just generating the metadata) I do not see this having any adverse effects, however I cannot guarantee this until I hear back from engineering.
When we upgrade out CA Release Automation platform to a future version I assume that the new version of these jar artifacts get added into the embedded Nexus and the old versions removed as part of the upgrade process, so any action that we took to get this to work would likely need to be repeated after every platform upgrade?
That is correct, during an upgrade most of the jars are replaced as part of the upgrade process, so any custom jars would in fact be replaced. If you are intending to modify/customize any core classes(outside of action packs), you may run into additional issues with signing them properly.
I will update you as soon as I know more, thanks Luke.
Jeremy