ods-quickstarters
ods-quickstarters copied to clipboard
Add configurations to use internal Nexus repository
Is your feature request related to a problem? Please describe. Building of new projects fail due to missing repository configuration.
Describe the solution you'd like Adding the required configurations to the project would provide a solid foundation and consistency across projects. e.g. A Java project using gradle requires the correct Nexus URL for code dependencies ( in build.gradle) and managing plugins (in settings.gradle)
Describe alternatives you've considered An alternative is to allow the firewall to connect to all public repositories
Additional context none
Example settings.gradle
settings:
pluginManagement {
repositories {
maven {
url "https://nexus-repository-url.some.where/repository/maven-central/"
}
maven {
url "https://nexus-repository-url.some.where/repository/atlassian_public/"
}
maven {
url "https://nexus-repository-url.some.where/repository/maven-public/"
}
}
}
rootProject.name = 'my-amazing-project'
Thank you @mh11. @braisvq1996 we will need to use the repositories only if USE_NEXUS
is enabled, I assume. @jafarre-viewnext can you advise?
We already have something similar for build.gradle
here and check if we have nexus here, we could follow a similar approach
If I read this correctly, that works for a controlled environment (e.g. Jenkins). I think, that you can't assume, that the user has all the variables set correctly in their environment. It would be good that the configuration file is generated with the URLs set, when the project is provisioned (or read from a properties file) - all contained within the project.
@mh11 environment variables are a widely-used way of configuring an application, and proposed as part of the 12-factor apps approach. When using the EDP, this environment variable is automatically set. When using the component on a local machine, you need to set this by hand or as part of your .bashrc file (or similar).
I know that the "hard-coded" URLs would interfere with EDP and would violate the 12-factor apps approach. But the ultimate question is, how to enable / support the user to get started with an enviroment, which could range from "nothing" to "multiple" configurations. In addition - what are the default resources a user should use (public vs internal). One way to leaverage environment variables are to overwrite a default behaviour by providing alternative settings. In this case, you might want to (i) set the Nexus URLs hardcoded (not nice, I know) as default pointing at the internally Nexus and (ii) "disabled" or overwrite them, when a variable e.g. EDP_CONTROLED or NO_NEXUS exists.
For gradle, you can add a gradle.properties
with the nexus settings of your ocp cluster to your local .gradle
folder and it will be picked up by gradle for any gradle execution of any project you might provision afterwards.