I want to include a log4j.properties file in my maven build, but be able to use a different properties file at execution time (using cron on unix)
Any ideas?
You want to be able to change properties per environment.
There are number approach to address this issue.
Create directory in each environment which will contain different files (log4j.properties in your example). Add these directories to your classpath in each environment.
Use filter ability + profile ability of maven in order to populate log4j.properties with correct values in the build time.
Use build server (Jenkins, for example) which essentially will make p.2.
Each of these approaches has it's own drawbacks. I am currently using a bit weired combination of 2&3 because Jenkins limitations.
Related
I am creating a rather custom task that processes a number of input files and outputs a different number of output files.
I want to check the dates of the input files against the existing output files and also might look at the content of the input files to make the determination whether it is up to date or needs to be invoked to become up to date. What properties do I need to set in a doFirst, code the main action, or whatever ( where and when) in my task to set the right state for their dependency checker and task executor so as either appropriately force dependents to build or not.
Also any doc on standard lib utilities to do things like file date checking etc, getting lists of files etc that are easy like in ruby rake.
How do I specify the inputs and outputs to the task ? Especially as the outputs will not be known until the source is parsed and the output directory is scanned for what exists.
a sample that does this in a larger project that has tasks that are dependent on it would be really nice :)
What properties do I need to set in a doFirst, code the main action, or whatever ( where and when) in my task to set the right state for their dependency checker and task executor so as either appropriately force dependents to build or not.
Ideally this should be done as a custom task type. None of this logic should be in any of the Gradle files at all. Either have the logic in a dedicated plugin project that gets published somewhere which you can then reference in the project, or have the logic in buildSrc.
What you are trying to develop is what is known as an incremental task: https://docs.gradle.org/current/userguide/custom_tasks.html#incremental_tasks
These are used heavily throughout Gradle which makes the incremental build of Gradle possible: https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:up_to_date_checks
How do I specify the inputs and outputs to the task ? Especially as the outputs will not be known until the source is parsed and the output directory is scanned for what exists.
Once you have your tasks defined and whatever else you need, in your main Gradle files you would configure them as you would any other plugin or task.
The two links above should be enough to help get you started.
As for a small example, I developed a Gradle plugin that generates files based on some input that is not known until its configured. The 'custom' task type just extends the provided JavaExec. The custom task is Wsdl2java. Then based on user configuration, tasks get registered here using the input file from the user. Since I reused built-in task types, I know for sure that no extra work will done and can rely on Gradle doing the heavy lifting. There's also a test to ensure that configuration cache works as expected: ConfigurationCacheFunctionalTests.
As I mentioned earlier, the links above should be enough to get you started.
Suppose I have a server where many users run different experiments, possibly with different Trains Servers.
I know about the TRAINS_CONFIG_FILE environment variable, but I wonder if this can be made more flexible in one of the following ways:
Specifying the Trains config file dynamically, i.e. during runtime of the training script?
Storing a config file in each of the training repos and specifying its path relatively to the running script path (instead of relatively to ~/)?
Disclaimer: I'm a member of Allegro Trains team
Loading of the configuration is done at import time. This means that if you set the os environment before importing the package, you should be fine:
os.environ['TRAINS_CONFIG_FILE']='~/repo/trains.conf'
from trains import Task
The configuration file is loaded based on the current working directory, this means that if you have os.environ['TRAINS_CONFIG_FILE']='trains.conf' the trains.conf file will be loaded from the running directory at the time the import happens (which usually is the folder where your script is executed from). This means you can have it as part of the repository, and always set the TRAINS_CONFIG_FILE to point to it.
A few notes:
What is the use case for different configuration files ?
Notice that when running with trains-agent , this method will override the configuration that the trains-agent passes to the code.
I want to save Jmeter aggregate report to project's target folder with timestamp,so that everytime I run the tests I get the new unique report, irrespective of OS.
I tried by providing this path /target/jmeter/results/aggReport.csv but it saved it in C:/target/jmeter/results/aggReport.csv Also there was no time stamp.
E.g. 100320182130aggReport.csv which is mmddyyyyhhmmaggReport.csv
This question is in continuation of soemthing I wanted to achieve here and suggested by Dmitri Jmeter: Test plan has two thread groups but it generated only 1 jtl report
I am using Maven, Java 8, Windows 7
Update:
I tried:
In case of JMeter test execution via Maven JMeter's working directory (or Java user.dir property) points to target/jmeter/bin folder so you need to construct the desired path relative to it
Your path starts with / which means it is absolute and points to root folder of the file system
You need to include __time() function into the resulting filename if you want the result to be prepended by the timestamp
Assuming all above your listener "Filename" field should look like:
../results/${__time(MMddyyyyhhmm,)}aggReport.csv
Check out Five Ways To Launch a JMeter Test without Using the JMeter GUI article for more information on various ways of kicking off a JMeter test including using Maven plugin.
I'm following the steps from the Adobe instructions on How to Build AEM Projects using Maven and I'm not seeing how to populate or configure the meta data for the contents.
I can edit and configure the actual files, but when I push the zip file to the CQ instance, the installed component has a jcr:primaryType of nt:folder and the item I'm trying to duplicate has a jcr:primaryType of cq:Component (as well as many other properties). So is there a way to populate that data without needing to manual interact with CQ?
I'm very new to AEM, so it's entirely possible I've overlooked something very simple.
Yes, this is possible to configure JCR node types without manually changing with CQ.
Make sure you have .content.xml file in component folder and it contains correct jcr:primaryType ( e.g. jcr:primaryType="cq:Component").
This file contains metadata for mapping JCR node on File System.
For beginners it may be useful take a look VLT, that used for import/export JCR on File System. Actually component's files in your project should be similar to VLT component export result from JCR.
Currently I'm working in a continuous integration server solution using Hudson.
Now I'm looking for a build job which will be triggered every time it finds a file in a specific directory.
I've found some plugins which allow Hudson to watch and poll files from a directory (File Found Trigger, FSTrigger and SCM File Trigger) but none of them allow me to get the filename and file contents from the file found and use these values during the build execution (My idea would pass these values to a shell script)
Do you guys know if this is something possible to do via any other Hudson plugin? or maybe I'm missing something.
Thanks,
Davi
Two valid solutions:
As suggested by Christopher, read the values from the file via Shell/Batch commands at the beginning of your build-script.(The downside is that Hudson will not be aware of those values in any way)
Use the Envfile Plugin to read the content of the file and interperate it as a set of key-value pairs.
Note that if the File Found Trigger "eats" the flag-file, you may need to create two files -
one to hold the key-value pairs and another to serve as a flag for the File Found Trigger.