I am using spring-boot and would like to update the application.properties file in the /src/main/resources folder as a task within a manual build plan. As the service can be installed on premise at the customer, I want to build the jar for each customer, where I can provide variables (e.g. spring.data.mongodb.* properties) to be injected/overridden before the maven build.
I found the inject plugin, but this adds a prefix before the variables, which in this case wont work as the DB connection is done automatically with spring.
Is there another plugin I didn't find which could do the trick, or is there an easy way to script something like this (please provide an example as I am not very familiar with shell scripts)?
Related
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/).
This is where I am at:
I am using Drools 6.2 and calling drools engine remotely via KIE Execution Server running on jboss.
I used workbench to create my initial drl file and fact objects and then used Build & Deploy option of workbench to create and deploy the jar file. I then created the container using the jar file and got the end point that I am using to access the rule engine from my client application. At this point every thing is working fine and I am able to fire the rules remotely.
My requirement is to modify the rules file (.drl) outside the workbench, let's say in notepad and update the container with this new drl file. Is there an easy way to create the jar file programmatically that i can deploy to the central maven repository? I can then run the KIE scanner to look for the latest version of my jar file and automatically update my container. Or is there another recommended way to update the running container with an updated .drl file?
My client application is not in Java so I am not looking for an integrated solution where I can write java code to create the knowledge base and use kie builder to build the drl file.
Is there an easy way to create the jar file programmatically that i can deploy to the central maven repository?
2 options that I can think of, one "easy" and one not so much:
Option 1
Use Maven and the maven drools plugin (you don't have to write Java code, just create your maven project and run mvn package to get a jar. See here: https://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html/KIEChapter.html#KIEModuleIntroductionBuildingIntroductionSection
Option 2
A JAR file is simply a zip file with a specified structure. That means that you should be able to update your whatever.drl file, put it in the directory structure that the KIE server expects and deploy it.
For instance, create a directory structure like:
META-INF/kmodule.xml
com/site/project/drools/rules/myrule/SomeRule.drl
Zip those files into somefile.jar and deploy it.
A RESTful web service project that I'm working on needs to be deployed to a very unique environment (that requires a lot of custom configuration) in addition to the typical deployment environment and the integration test environment.
I have created a build profile for the unique environment, but the definition is REALLY long, full of Ant Tasks, etc. and I'd like to put it in its own file and import it into the pom.xml just to keep things clean.
Is that possible?
The only option with the latest version of Maven at the moment (3.0.5) is to put your profile into a parent POM and inherit from the children.
One day when it is finished, POM Mixins would help but this feature is not yet finished.
I created some system properties in TC build configuration.
The value of these properties are passed to a maven configuration this way:
clean test -Dargument1=%system.property1% -Dargument2=%system.property2%
And this works as expected.
What I want to do now is to modify the value of the system properties when the build finish, so the next build will get these values.
Is it possible to do that programmatically, through Java or using Maven?
Is this the correct approach?
You can define build properties for this. Once your build finishes, you can craft a Maven plugin that sends a post request to TeamCity and alters the values for these build properties for the build type.
If I where you, I would craft maven task, which will update your properties via TeamCity restAPI on build completion.
It looks like mostly elegant way to do this task.
Full explanation for restAPI plugin could be found here:
http://confluence.jetbrains.com/display/TW/REST+API+Plugin
What is needed for your use-case is described here:
Build Configuration And Template Settings
Build configuration parameters: GET/DELETE/PUT http://*teamcity_url_goes_here*/httpAuth/app/rest/buildTypes//parameters/ (accepts/produces text/plain)
You could craft a request to update your parameters.
One more interesting thing: If you want to execute requests to REST API inside a TeamCity build running on the same server, you can use %teamcity.serverUrl% predefined parameter to construct URL
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.