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?
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?
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?
For explanation the below is the filesystem of the embedded Nexus instance, showing the nolio-actions-6.3.0.jar jar file without the required pom files.
H:\>ls -la H:\CA\nolio_01\LISAReleaseAutomationServer\sonatype-work\nexus\storage\nolio-actions\core_actions_group\nolio-actions\6.3.0total 516drwxr-xr-x 3 randalll Administ 0 Mar 20 2017 .drwxr-xr-x 10 randalll Administ 4096 Mar 15 2017 ..-rw-r--r-- 1 randalll Administ 1051291 Mar 20 2017 nolio-actions-6.3.0.jar
The following shows another jar file, nolio-shared-6.3.0.jar, which we uploaded into the embedded Nexus instance and had the Maven pom files generated
H:\>ls -la H:\CA\nolio_01\LISAReleaseAutomationServer\sonatype-work\nexus\storage\nolio-actions\core_actions_group\nolio-shared\6.3.0total 877drwxr-xr-x 8 randalll Administ 4096 Nov 13 00:25 .drwxr-xr-x 8 randalll Administ 0 Nov 16 14:54 ..-rw-r--r-- 1 randalll Administ 1785688 Nov 13 00:25 nolio-shared-6.3.0.jar-rw-r--r-- 1 randalll Administ 32 Nov 13 00:25 nolio-shared-6.3.0.jar.md5-rw-r--r-- 1 randalll Administ 40 Nov 13 00:25 nolio-shared-6.3.0.jar.sha1-rw-r--r-- 1 randalll Administ 466 Nov 13 00:25 nolio-shared-6.3.0.pom-rw-r--r-- 1 randalll Administ 32 Nov 13 00:25 nolio-shared-6.3.0.pom.md5-rw-r--r-- 1 randalll Administ 40 Nov 13 00:25 nolio-shared-6.3.0.pom.sha1
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.
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.
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.
Did Jeremy's reply answer your question?
Although it may not be perfect, I believe his suggestion could cover almost of your question.
Can we close this thread at this stage?
Thanks in advance.