Is it possible somehow possible to add a environment variable to the generated scripts say LD_LIBRARY_PATH=$BASEDIR/native/libs/. I did not find anything in the docs. Maybe there will at least be a "hacky" way using another maven plugin?
The simple solution for this is to use a environment setup file which can be configurate in Appassembler within the pom.xml
Related
I'm having some trouble working out how to run a project in IntelliJ IDEA that makes use of Maven resource filtering.
In my src/main/resources directory I have
spring.xml file that is used to start the application
service.env.properties
I also have the following in src/main/filters
env-uat.properties
env-prd.properties
env-dev.properties
In my pom.xml file I use maven-resources-plugin to create three configuration directories that get included into the final package. Each one is based on one of the filers. This package can then be deployed on any of the three environments without having to be rebuilt.
The issue that I'm having is when I try to run this using IntelliJ IDEA run configs I have to use
-Xbootclasspath/a:target/config/dev;
to force IntelliJ IDEA to pick up the .properties file with the correct filter.
While this works it doesn't seem like it is the right way to go here. Does anyone have any advice on how to handle configuration for multiple environments and how to get IntelliJ IDEA to pick this up through run configurations.
I have set up a Maven project that starts up a standalone Wildfly container using Cargo, but in the process of adding some new features, I need to add some content to the standalone.xml. (Specifically, a security realm.) This seems like it should be a fairly common task, but I can't find a way to do it.
I tried to use the xml-replacement feature built in to cargo, but it doesn't seem to be capable of adding content, only modifying existing content. My second attempt was to use the maven-replacer-plugin, which feels like a hack, but would have done the job. The problem I have with it is that I can't find a way to execute the replacer plugin between when cargo installs the container, and when cargo starts the container.
Thanks in Advance
I'd recommend switching from Cargo to the wildfly-maven-plugin, which is container-specific but more straightforward to use.
You can run any CLI command via the plugin to edit your standalone.xml.
See this example from one of my projects.
Of course you can override the container's configuration, see here and there how you can do that.
In your case if you wanted to put a custom standalone.xml, you simply have to embed the entire file in your project and put it in the configFiles for cargo to deploy it with your container.
I have a regular requirement to execute several goals in Maven so I decided to write a plugin for it. It seemed easiest to define a new lifecycle for this, each phase executing the relevant plugin goal. I need to pass configuration to the plugin, specifically a directory and a version number.
I found that if I use a variable in lifecycle.xml, such as ${projname.directory}, the variable appears to be resolved not at plugin compile time but at project compile time. I'm guessing that lifecycle.xml is used within the project and not touched by the plugin. Is there any reference for understanding exactly how this works?
Also, I'd like to be able to use a default directory name if the projname.directory property is not set - storing this in the plugin source somewhere. I have no idea how to go about this - is there an easy way to do it?
Thanks,
-Dave
As we know, it is possible to specify JDK path in gradle.properties at the project level, in property: org.gradle.java.home. However, this file may be under VCS (i.e. git). Users may have different paths for JDK, hence we can't commit this file.
Is there any safe, project-agnostic way to specify this property, so it works for users and different projects? Maybe using some environment property?
EDIT
I am looking a way to specify JDK per project but not be forced to commit this information.
Your wording is a little confusing since if you place the property in a non-VCS location (like an environment variable) it's not really "cross-user" since every user will have to configure this explicitly.
If you simply want to set properties in a way that is outside of version control there are several ways to do this.
Use an environment variable, like you mention. Simply prefix it with ORG_GRADLE_PROJECT_. For example, ORG_GRADLE_PROJECT_javahome would then be available in your build script as javahome.
Place the properties in a file located at USER_HOME/.gradle/gradle.properties.
Specify the property via the CLI with the -P option.
Use something like the Gradle properties plugin to place additional properties in a separate file ignored by VCS.
Is it possible to define different profiles in gradle? I've written a WebApplication and i want to deploy it with the production settings. Furthermore my app is using PrettyFaces. Since i'm using different two languages i also want a language sepcific build. Here is my use case:
production/en, production/ru
The build with a specific language indicates which db to use and which language is the default one. Furthermore the urls (PrettyFaces) are different files. In my opinion i need a different web.xml and a different pretty-faces.xml ?
Thanks in advance!
Here are some options:
Create a task for each setting, so you can do gradle buildEn or gradle buildRu to differentiate the builds. You can write each task manually, or dynamically generate them.
Pass a project property to your build, e.g. gradle build -Plang=ru. Then you can reference lang from your task and do the logic there. Project properties can also be specified in gradle.properties file if you don't like passing the property every time. Anyway check this out.
Probably not what you want, but you can add behaviour to your build if a certain task is present in the build graph (in the example additional logic is executed when graph contains release task).
Good luck