Default Environment Variables, and VM options for all new projects in Intellij - spring-boot

I want to apply common env variables and vm options for all my spring boot applications in Intellij.
Whenever i open a new project, the config should copy automatically.
Is there a way to do this?
Also , can i use vmoptions file for supplying my default vm arguments ?

No, you cannot use vmoptions for it, that configures the VM options for IntelliJ itself (as IntelliJ is actually written in Java).
Open the templates section in the run configurations dialog.
Scroll down until you find the run configuration you want to set the defaults for (in this case Sprint Boot).
Click on it, and anything put into the fields will be used for new configurations. Note that it is not possible to retroactively change settings for existing configurations. In this case, what you want is in the Environment dropdown to configure VM options.
Manage the configurations, hit OK, and all your new configurations will have those applied to them by default.

Related

Keeping application.properties up to date

So historically, we launch our Spring application using the maven command and explicitly specifying the active profile of the application. At the root of the project, we have two .properties files:
local-application.properties, in which the settings for the local
environment are located and which are not monitored by git;
application.properties.template, which stores settings for the
dev environment.
When adding a new functionality, you may need new properties that the developer may forget to add to application.properties.template, which is why the dev environment will not start, because the person responsible for this will not know anything about these new properties.
In this regard, the question is:
Is it possible to use maven to automate a reminder to the developer to
add the necessary properties or their values ​​to the application.properties.template file,
if such changes take place?
It may be possible to break all property values ​​across new *.options files and then, when performing any of the maven phases (for example, verify), generate this .template file.
Or maybe there is some kind of plugin that does similar things.
Thanks!

Sonarqube profiles best practices

I would like to use the default rule set provided by sonarqube (5.1.2) which is collected in the default profile "sonar way". Now I need to add/remove some rules. What is the bets practice here? So far I have created a copy of the default profile and applied my changes there. Then after installing a new plugin I noticed that the default profile has been extend by some rules (obviously the useful ones) of that new plugin. So I need to add them manually to my custom profile. I reckon the same happens with updates of the java plugin.
My questions:
Should I work with a copy of the original profile to not pollute it and retain the opportunity to restore it to the factory defaults? (conclusion: manual work every time an update or new plugin comes in)
Should work with the original profile? (will it then still be updated without conflicts on new plugins/updates?)
Is there a way to work with a profile that is linked to the original profile? (like an overlay filesystem over a read only filesystem => OverlayFS)
You might be interested in profile inheritance: http://docs.sonarqube.org/display/SONAR/Non-rule+Profile+Edits+and+Information#Non-ruleProfileEditsandInformation-ProfileInheritance

Intellij Doesn't Honor maven-compiler-plugin

I have 3 JDK's installed on my computer and Intellij knows about all 3 (6, 7, & 8)
Most projects I work on need 6 but a few need 7 or 8 (we are slowly moving everything to 8)
Maven supports this just fine with the maven-compiler-plugin configured just like here:
http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html
This works fine from the command line. However Intellij doesn't listen to that plug in and seems to use what it thinks is right. (by default it always goes with Java 8 because it's the last in the list I think)
Is there a way to force Intellijs compiler to use the plug-in? Or a way for everyone to share that configuration across machines and developers?
A few things might be happening, but IDEA should honor the maven-compiler-plugin settings. Have you re-imported your Maven project?
1.) Check to see if the language level settings are in sync, if you open up the Project Structure window (Ctrl+Alt+Shift+S) do the project AND module's language level mirror the Maven compiler's version?
2.) Now check your Run Configuration, hit Ctrl+Alt+A and type "Edit Configurations".
3.) Add a new Maven Configuration with the desired lifecycle phase, then open up the runner tab and deselect "Use project settings". Select your JDK from the dropdown.
4.) Click OK and hit Shift+F10 to run that new Maven Configuration. Does it work as expected?

How to add some specific file into the build process?

We are using TFS 2010. In our projects we have multiple configuration files. Each configuration file is needed for a specific build.
Example: Project XYZ includes three configuration files, lets say DEV-CONFING, QA-CONFIG and PROD-CONFIG files.
Now we want to find a way that during the build process, the build process includes the right configuration file and excludes the rest.
Example:
Build for Dev should pickup and copy only the DEV-CONFIG file (and excludes all other configuration files)
Build for QA should pickup and copy only the QA-CONFIG file (and excludes all other configuration files)
Build for production should pickup and copy only the PROD-CONFIG file (and excludes all other configuration files)
Is it possible to change the setting of individual build definition and address this issue?
What is best possible solution for this problem in VS 2010 and TFS 2010?
Please list all required steps and be precise as much as possible because I'm a newbie in TFS 2010 and have not much experience with the whole process.
The "Web Config Transformations in VS2010" addresses the problem of modifying the web.config during compile time. Some people might want the web.config to be modified at deployment time instead of compile time (like me) so that we dont have to recompile the code while moving from one environment to another, in that case you can make use of "Web Deployment Parameters"
You can read more about it at:
http://www.asp.net/mvc/tutorials/deployment/visual-studio-web-deployment/web-config-transformations
web config transformation syntax:
http://msdn.microsoft.com/en-us/library/dd465326.aspx
#user2585405 to your comment above "But all the configurations in my case are for the same mode "Release Mode". The decision should relay on the build definition. So when I use a build definition for DEV, the configuration for DEV should be automatically chosen or for QA build definition, the corresponding QA configuration should be automatically chosen."
Doesnt matter whether currently you have only one configuration. You can add how much ever configurations you want, right click the solution and select the configuration manager. Now add a new configuration say "Dev" (it can be in "Release/Debug" and also select the platform "x86, any cpu etc"). Now add another configuration for QA and PROD. Then come back to your web.config and right click and select "Add web config transformation".
Now you should be able to see the web.Dev.Config, web.QA.config etc. The root web.config will have all the common properties and the DEV/QA/Prod specific config will have only the delta changes (you have to define these entries) which are specific to that configuration (lets say connectionstring). When you compile, within the build definition you can select which configuration you want to compile (Dev, QA, prod) you dont have to keep multiple build defintion. Just one is enough! After the compilation is done, the root web.config will be replaced with the values specific to the configuration for the connectionstring part alone.
Hope this helps!
Yes this possible. You can keep configuration files in different mode for eg:
You can have configuration files in Release mode debug mode, release mode and the common configuration file used by all.
So when you build your solution in Debug mode then the debug mode configuration file will be used and when in release mode then release mode configuration file will be used.
For further clarity take example of web config when you will expand the web config tab you will see the two configuration file in different modes.

Using global properties or build steps in TeamCity

I have a lot of projects in my TeamCity server, for building and testing multiple sites. We use Selenium RC to test the sites every night, and I would like to reuse one step or configuration instead of having copies in each project.
I have looked into using Templates, but they only seem to be accessible from the project it is defined in. The same goes for properties, as I tried to put paths and some shared values in system or environment properties and using copied build steps using those shared properties.
But it all fails, as none of these methods seem to be usable across projects. How do you solve this type of issue? It must be possible somehow, right?
As per my comments for your question you can use a single template configuration build across multiple Projects.
See TeamCity documention for information on how to do this.
TeamCity has a new feature (as of 8.0) that supports global configs/parameters/env variables. 8.0 supports the new concept of project organization/nesting, and as part of that feature set all projects now inhert from the "Root" project. And on that root project you can specify a number of things, including parameters, etc. This does not appear to support build steps.
They documented the change in http://youtrack.jetbrains.com/issue/TW-11202.
--
You could achieve a "global property" by creating a dummy build configuration which has your shared properties then for all your builds which need access to the global properties you create a build dependency. When your real build configuration is called it will first call the dependent build configuration (which does nothing meaningful) then it passes the properties from the dependent config (with a dep.bt prefix instead of just the system prefix).
Depending on the logic you need in a shared build step you may be able to actually perform real logic in the dependent build (it won't be able to inherit any properties or VCS details from the "real" build).
Since this is a bit outdated, and the answers above aren't completely clear, thought I would post how I did this with TeamCity 8+.
Basically, a template can be used within the project and its children. If you move a template to the parent, it becomes available to all the siblings of the original project.
Go to the template.
Click the "Move" button (bottom-right pane).
Select a parent (or root).
Note: If the template is attached to a VCS root that is bound to the current project, you'll first have to move the VCS root to the same level to which you're trying to move the template.

Resources