I have a simple Java application using Gradle as the build tool. Normally when I run my application using gralde I set a specific environment variable set MYVAR=myval and later my application uses this value. When I set up a configuration to Run/Debug my Gradle based application in IntelliJ all goes well except that I have no way that I can find to specify my environment variable MYVAR and thus it is always unset.
I've been reading up on my options in various documents and articles for over two hours now and have gotten nowhere.
Related
Had a bit of a nightmare getting consistent result from my code when reading "user.dir" property depending on how the code was launched.
I have a gradle project, some code & scripts in src/main/groovy and tests in source/test/groovy, and running code from command line, or in the IDE (run script directly) and running some tests
i'd built myself a new gradle project and was trying to open a file resources in src/main/resources.
when i ran my unit tests, the user.dir = 'project root' (which is what i was expecting). when i built a script and right clicked in the IDE, then the user.dir property returned the current script directory path in source main!
so a lookup in a test returned a different test.
I also tried setting this in build.gradle
//setup proj.dir as project root
System.setProperty( "proj.dir", project.projectDir.toString() )
and build a gradle task to print this - and it shows the project directory as result.
There doesn't appear to a global 'fix or config' in intellij to always get consistent return when reading the property "user.dir" to be project root. unless i missed something?
in the IDE if i look at the run/debug configurations - under defaults the entry for groovy says the working directory is the project root (as id expected). however when i looked under the groovy node and my script there ('testPCE'), then the working directory was set as the scripts current location.
once i found out that i can edit the IDE run/debug configurations i reset the working directory to be the project root, and now get a consistent result. But seem to have to check this on each script if i need to.
so my questions is what can i do/configure/set so that i get an env variable which always returns the project root, whether from command line launch, in gradle, by running by right click of script from IDE, or from tests in the IDE/ or from commnd line
There must, be a 'robust' way to ensure that all lookups on some env variable will return the same answer regardless of how your code is executed.
know i know whats happening, i can adjust my ide to set where i want working directory to be - but have to keep checking. I want something reliable that will always work, whether its IDE, command line, inside tomcat web container etc to get the 'project root' and build paths reliably from this one stable point, that will work consistently
Does anyone know how to do this?
perhaps not ideal bu this is working. I'm trying to load a config file from the resources area that's in the classpath, but my code is a static block in class.
in this case i had to get the classLoader for the Class object and getResource on that (which includes checking across the classpath (i didnt want a spring dependency for this project if i could avoid it).
So the the code that seems to work - without having to resolve "user.dir" property is shown below
//configure standard converters
static {
// class class loader will include resources so file will be found
def configFile = "config/BinderConfig.groovy"
def resource = new File (configFile).canonicalPath
resource = Gbinder.getClassLoader().getResource(configFile)
def binderConfig = new ConfigSlurper().parse (resource)
binderConfig.global.converters.each {
typeConverters << it
}
typeConverters
}
I have a solution that is using an hybrid .csproj and project.json combination (for nuget management purposes). So basically the "project.json" file is working as a "packages.config" file with a floating version capability.
This solution is using a custom RuleSet that is being distributed via Package, and is imported automatically. On the dev machine, works without a problem.
At the build machine (that is, inside the machine itself, working as an user) the solution also compiles without a problem.
However, when a vNext build (is this the name for the new build system?) is queued, it ignores completely the custom ruleset and just uses the StyleCop one (that is also included), which gives a bunch of warnings. Said warnings should not appear as the Custom RuleSet basically suppresses those warnings (ie: Warning SA1404: Code analysis suppression must have justification,
Warning SA1124: Do not use regions, etc)
As far as I have checked, there is no setting to specify the ruleset, and this works with XAML Builds. What is different in this new build system that is causing this? Is there a way to force/specify the Code Analysis Rule Set from the definition?
Thanks in advance for any help or advice on the matter.
Update/Edit
After debugging back and forth with the wonderful help of jessehouwing I must include the following detail on my initial report (that I ignored as I did not know that it was influential):
I am using SonarQube Analysis on my build definition.
I initially did not mention it as I did not know that it replaces the Code Analysis at Build Time (and not only when it "analyzes", as I thought).
If you are using the SonarQube tasks
The SonarQube tasks generate a new Code Analysis Ruleset file on the fly and will overwrite the one configured for the projects. These rulesets will be used regardless of what you've previously specified.
There is a trick to the naming of the rulesets through which you can include your own overrides.
More information on the structure can be found in the blog post from the SonarQube/Visual Studio team. Basically when you Bind your solution to SonarQube it will generate 2 ruleset files. One which will be overwritten during build, the other containing your customizations.
There is a toolkit/SDK to generate a SonarQube plugin for custom analyzers which allow you to import your rules into SonarQube, so it will know what rules to activate for your project(s).
If you're not using SonarQube
Yes you can specify the ruleset you want to use and force Code Analysis to run. It requires a couple of MsBuild arguments:
/p:RunCodeAnalysis=true /p:CodeAnalysisRuleset="PathToRuleset"
Or you can use my MsBuild helper extension to configure these settings with the help of a UI template:
Background:
I've been using Eclipse for a while and am trying out Intellij now.
I checked out my project from Git (via Intellij) and recognized it as a gradle project. Its created the WAR(& the exploded WAR) all of which are fine.
Question:
When I was using Eclipse, I used the command:
gradlew -Penv=Development :my_webapp:assemble
This used to do a few things including creating a environment.properties file that my dev specific env could use (for selecting database instances etc) based off of -Penv=Development...I'd like the Intellij gradle build to do the same... What's a way to configure Intellij's gradle process to do these custom things or provide same features as provided by this specific command line tool (Note - the code for this is already written in build.gradle file)...
I looked at some of Intellij's docs, but could not find an answer to this.
EDIT:
I've found the solution, for anyone interested - read on...
Seeking guidance from #Stanislav, I was able to add the property as follows:
In your server's run configuration (Run/Debug Configuration -->Your server's config(Jetty etc), there is a section called Before launch, which should have Make/Build Gradle already included
Hit the + sign -->Run Gradle Task --> Select your gradle project (i.e. the web app) --> Select the task (most likely loadEnvironmentConfiguration) --> set the script parameters such as -Penv=Development, hit OK
Move this to before the Build Gradle function (by using the up arrow - to the right of + sign you hit in step 2)
It seems, that you need to create your specific run or debug configuration. You can read about it in official IntelliJ Idea help. All you need, is to modify your configuration for the task you need, by providing the argument -Penv=Development, since it is running with gradle.
You may also need to define Gradle instance, which will be used via settings, if the defaul wrapper wont work for you. You can find almost all you need in the the official help.
the easiest way to pass spring profiles to gradle bootRun is (for me) by environment variable (e.g. SPRING_PROFILES_ACTIVE), when run on commandline.
Unlike the Application configurations, the config for gradle tasks does not provide an input for environment variables. And as VM options don't get picked up either as it seems, I can not run those tasks from the IDE.
I am aware, that I could start IntelliJ with the envvar set, but this seems rather cumbersome.
So what I need is the IntelliJ pendant for SPRING_PROFILES_ACTIVE=dev,testdb gradle bootRun, unless there is a good reason, they have left this out.
System is linux, intellij 14. The project in question is using springboot and I want to move over from running main in IntelliJ to running with springloaded+bootRun and separate compileGroovy calls as IntelliJ is not "understanding" the gradle file completely and therefor hides errors.
Make the System.properties available in the bootRun (or other) tasks.
bootRun.systemProperties = System.properties
This way we can set in IntelliJ VM Options like -Dspring.profiles.active=dev.
Here is my solution for setting up Spring environment variables / settings with Gradle / IntelliJ
Firstly, define a basic properties file, and then one based on your environment, such as:
#Configuration
#PropertySources(value = {#PropertySource("classpath:default.properties"),#PropertySource("classpath:${env}.properties")})
Int the above example, pay careful attention to the #PropertySource("classpath:${env}.properties"). This is an environment variable being pulled through.
Next, add a VM argument to IntelliJ (via the Gradle Tasks Run Configurations) - or as an argument via the gradle command line.
Lastly, copy the properties across in the gradle task as #cfrick mentioned and #mdjnewman have correctly shown:
tasks.withType(org.springframework.boot.gradle.run.BootRunTask) {
bootRun.systemProperties = System.properties
}
I've had success adding the following to my build.gradle file:
tasks.withType(org.springframework.boot.gradle.run.BootRunTask) {
systemProperty('spring.profiles.active', 'local')
}
This allows gradlew bootRun to be run from IntelliJ without requiring any changes to the IntelliJ Run/Debug Configurations (and also from the command line without having to manually specify a profile).
In order to load .DLLs (under Windows) or .SOs (under Linux) we must use the environment variables PATH (Windows) or LD_LIBRARY_PATH (Linux).
The only way we could find to properly use DLLs and SOs was to define the environment variables before starting Netbeans.
Is there a way to specify those environment variables inside
Netbeans?
Is it possible to specify it inside the project
properties? That way each project could have its own definitions.
is there a way to just append to those environment variables instead of just overriding them?
Background: we are developing a Java program that uses JNI to access native libraries. Those native libraries, in turn, access other dependent native libraries. Because of that, just setting the property "java.library.path" doesn't work, as we need to set the full LD_LIBRARY_PATH (or regular PATH in the case of Windows), too.
Outside Netbeans the application runs fine, because we set the environment variables inside shell scripts.
We don't want to just place the DLLs or SOs in the usual system directories because we don't want to mess up with the operating system installation during development. In addition, we want to have the flexibility to allow any developer to simply get the project from source control (Mercurial) and have all relative paths just working.
There is already a hack on stack overflow to set environment variables programmatically in Java. However, we are looking for less hackish a solution.
You can override Ant script tasks that NetBeans uses in build.xml file (or edit it directly in the full script in nbproject/build-impl.xml, but not recommended).
The java task is used on run target. You can use env parameter to specify environment variables to the process that will run the JVM.