I have a few projects in separate git repositories.
Is there a way to store common gradle configuration that they are using in one place?
The common configuration includes repositories, tasks etc.
Yes, it's possible. You can define a gradle file with all the necessary data and expose it, e.g. www.company.com/master.gradle.
Then apply it in the following way:
apply from: 'www.company.com/master.gradle'
in all gradle scripts that require these global settings. This link may be also useful.
Related
Building a Spring based project deployed in kubernetes using Spring Cloud Kubernetes library with Kubernetes. The build is using maven and GIT CI/CD. Exploring the build process to package environment specific files and the runtime to pick up env specific files during execution. In traditional deployment, used to use maven profiles to build env specific libraries and configurations. Now spring has profile and maven has its profile. Besides, some of the designs includes files/configurations for all env included in the build and only a activated profile will use the correct configuration. Is it advisable to include all configurations in the package?
Is there a best approach on how these two work in handling env specific files or any other optimized approach to handle this?
I'm afraid that:
In traditional deployment, used to use maven profiles to build env specific libraries and configurations
was never a case for maven profiles, if you take a look at official guide you may find following:
Apache Maven goes to great lengths to ensure that builds are portable. Among other things, this means allowing build configuration inside the POM, avoiding all filesystem references (in inheritance, dependencies, and other places), and leaning much more heavily on the local repository to store the metadata needed to make this possible.
However, sometimes portability is not entirely possible. Under certain conditions, plugins may need to be configured with local filesystem paths. Under other circumstances, a slightly different dependency set will be required, and the project's artifact name may need to be adjusted slightly. And at still other times, you may even need to include a whole plugin in the build lifecycle depending on the detected build environment.
To address these circumstances, Maven supports build profiles.
So, maven profiles was designed to support codebase portability across build environments, but not to build artifacts for particular environment.
"Traditional" way to inject environment-specific settings into j2ee-application was to setup those settings via JNDI, i.e. j2ee-container was providing a configuration via JNDI and our application was consuming that configuration via JNDI. In case of spring/k8s/etc the main idea should remain the same: application knows how to retrieve configuration (system properties, environment variables, configuration server, service discovery, etc) and environment provides that configuration.
We have multiple projects/services where we do repeat same configuration over and over again as a part of build.gradle file. Examples could be configuration for spotless plugin, docker, junit/jacoco, versioning, groovy tasks, etc.
I wonder is there a way to externalize it or move to single place so that if needed we can update configuration once instead of doing the same across each and every project.
Very naive idea is to have master-build.gradle file stored in it's own git repo and where needed we can refer it as a git submodule with capabilities to extend/rewrite. Open for any ideas. Thanks!
Gradle scripts can be reused by creating external script files and importing them using apply from: my-script.gradle. apply from also accepts an URL, so you can use something like
apply from: 'https://github.com/user/myproject/raw/master/hello.gradle'
Note tough that using plain references (URLs; or GIT repo URLs) is sub-optimal; a better approach is to identify your build dependencies (and these scripts ARE dependencies!) using group:artifact:version coordinates- that is achieved by writing a plugin and publishing to a repo (eg. to https://plugins.gradle.org/).
In the plugin I would like to be able to choose what other plugins apply (e.g. Nexus plugin or Bintray plugin, but not both) based on a configuration placed by a user in the configuration closure for my plugin.
I normally get the configuration for my plugin after the project has been evaluated. That is too late as I would like to allow users to override default configuration for those other plugins in their own (so they have to be applied earlier).
I could split my plugin into two separate plugins (within the same JAR), and require to apply the first one, provide configuration closure, apply the second one and use the configuration provided for the first plugin to decide what 3rd party plugins to apply.
Is there a better way to get the configuration for my plugin early enough to be able to conditionally apply other plugins (and allow them to use their configuration closures)?
You may use gradle 61.5. Init script plugins. This will allow your plugin runs before project configuration.
Example in the gradle documentation remove repositories from your build script. This means that you can read your configuration in a Init script plugin and decide which plugins to apply. Of course your configuration name should be fixed therefore your Init script plugin should be able to read it.
In a large maven multimodule context,
how can I gather javadoc-comments programmatically for a specific set of classes (e.g. all classes implementing some interface) or modules ?
I have tried a stupid doclet and looked at QDox, but neither seems to do the job well.
Actually I think this should be simple if done correctly.
Specifically, I do not know how to do this in a maven-build: How can I depend on and use the src-jars?
This should be possible with QDox, as long as you have the sources. QDox-2.x can also read source-files from jars, which can be generated by the maven-source-plugin.
We are using Maven(3.0.3) as build tool and we need to have different version for different environments (DEV , TEST, QA ) . If we pass version property value during build time based on environment , the installed POM doesn't have the passed property values instead it still has the ${app-version} string.
I saw already there is a bug for this http://jira.codehaus.org/browse/MNG-2971
Is there any other alternative ,because we cannot different POM file for different environments ,which will be hard to maintain..
Thanks
Vijay
Create different artifacts for the environments and use the parameter as a classifier. The pom is the same for all three artifacts but the classifier separates them.
Apparently Maven does not make any variable/property substitution when installing the POM. It is installed as is, that is the principle. You'd better not read any properties from POM (unless this is e.g. version number), bout you should configure your properties in external file (one per stage, e.g. dev.properties, test.properties, ...) and then configure Maven profiles (again, one per stage) and invoke Maven like mvn -Pdev depending on what you want to build. In profile you can package your final application with whatever properties you like (e.g. with the help of build-helper-maven-plugin:add-resource or maven-antrun-plugin + copy rule).
Alternatively you can filter your resources. For example, you can filter your Spring context XML file, which refers the properties file (so you package all property files, but Spring will refer only some specific). Or you can filter another properties file from which you will learn what is the "main" properties file to use (double indirection).
You should create the archives for your different targets within a single build and use as already mentioned the classifier to separate those artifacts from each others.