I'm looking for some way to replace patterns in files with values, during build time.
E.g. a configuration file may look the same except that different machines requires different hostnames in some setting. In that case i want to have a template file, where hostname is replaced with ##hostname##
Then when building, I want to create separate versions of the file with the patter replaced with the correct value for each environment.
In ant you could use "replace", is there something similar in maven2? I know that I can run ant form maven, but if theres a maven plugin doing it, I'd prefer that one.
I found http://code.google.com/p/maven-replacer-plugin/
but it's very new...
Suggestions?
Thanks!
The resource plugin is what does filtering in Maven. IIRC it supports the ant syntax as well as the ${foo} maven syntax.
keep up with the maven-replacer-plugin, the project is still alive and well
Maven's resource filtering might help you out.
Why don't you use the Maven-ant plug-in?
Related
In our project we use checkstyle as static analyzer (as maven plugin, I mean maven-checkstyle-plugin). I am new to this tool, and there is one thing I want to find out - what is the difference between failOnError and failOnViolation?
I think the plugin documentation is pretty clear, but the minimum expectation is going to be:
Do you want a log of the errors before failing the build? Then use failOnViolation
Or
Do you want to fail the build immediately, without waiting for errors to be logged? Then use failsOnError
Of course, if you set logViolationsToConsole to false (or on the CLI as -Dcheckstyle.console=false), then both act almost identically and can cause some confusion.
Note: this is not a dupe of this or this other question. Read on: this question is specific to the Code-Sharing template.
I am doing some pretty basic experiments with NativeScript, Angular and the code sharing templates (see: #nativescript/schematics).
Now I am doing some exploration / poc work on how different "build configuration" are supported by the framework. To be clear, I am searching for a simple -and hopefully official- way to have the application use a different version of a specific file (let's call it configuration.ts) based on the current platform (web/ios/android) and environment (development/production/staging?).
Doing the first part is obviously trivial - after all that is the prime purpose of the code sharing schematics. So, different versions of the same file are identified by different extensions. This page explain things pretty simply.
What I don't get as easily is if the framework/template supports any similar convention-based rule that can be used to switch between debug/release (or even better development/staging/production) versions of a file. Think for example of a config.ts file that contains different parameters based on the environment.
I have done some research in the topic, but I was unable to find a conclusive answer:
the old and now retired documentation for the appbuilder platform mentions a (.debug. and .release.) naming convention for files. I don't think this work anymore.
other sources mention passing parameters during the call to tns build / tns run and then fetching them via webpack env variable... See here. This may work, but seems oddly convoluted
third option that gets mentioned is to use hooks to customize the build (or use a plugin that should do the same)
lastly, for some odd reason, the #nativescript/schematics seems to generate a default project that contains two files called environment.ts and environment.prod.ts. I suspect those only work for the web version of the project (read: ng serve) - I wasn't able to get the mobile compiler to recognize files that end with debug.ts, prod.ts or release.ts
While it may be possible that what I am trying to do isn't just supported (yet?), the general confusion an dissenting opinions on the matter make me think I may be missing something.. somewhere.
In case this IS somehow supported, I also wonder how it may integrate with the NativeScript Sidekick app that is often suggested as a tool to ease the build/run process of NativeScript applications (there is no way to specify additional parameters for the tns commands that the Sidekick automates, the only options available are switching between debug/release mode), but this is probably better to be left for another question.
Environment files are not yet supported, passing environment variables from build command could be the viable solution for now.
But of course, you may write your own schematics if you like immediate support for environment files.
I did not look into sharing environment files between web and mobile yet - I do like Manoj's suggestion regarding modifying the schematics, but I'll have to cross that bridge when I get there I guess. I might have an answer to your second question regarding Sidekick. The latest version does support "Webpack" build option which seems to pass the --bundle parameter to tns. The caveat is that this option seems to be more sensitive to typescript errors, even relatively benign ones, so you have to be careful and make sure to fix them all prior to building. In my case I had to lock the version of #types/jasmine in package.json to "2.8.6" in order to avoid some incompatibility between that and the version of typescript that Sidekick's cloud solution is using. Another hint is to check "Clean Build" after npm dependency changes are made. Good luck!
Is there a possibility to use a local application.conf with Play 1.2.5? Our problem is that different developers have somewhat different setups that we don't want to save to version control.
Alternatives found:
Just modifying application.conf
Have to be careful not to commit changes to VCS
Environments : Own environment for each developer : %john, %mary (saved to VCS)
OK alternative, even though we woudn't like to save those to version control
We have do change those during development every now and then -> would cause unnecessary changes
#include : application.conf option for additional configuration files
Play 1.2.5 documentation : This is an experimental feature that does not yet work properly. :(
Something else?
Especially, is there a way to tell Play to use custom file name (as "conf/application.conf.local" instead of default "conf/application.conf"?
You can append:
%my_play_id.#include.application.conf=my_application.conf
At the end of application.conf. One line per developer or environment. You can override some properties in my_application.conf and is not necesary to prepend %my_play_id to the properties changed. For example if you have three developers:
%developer1.#include.application.conf=developer1_conf.conf
%developer2.#include.application.conf=developer2_conf.conf
%developer3.#include.application.conf=developer3_conf.conf
I have looked at the Play! 1.2.5 source code, but find nothing that suggests that Play! would be able to pick up anything other than the file conf/application.conf.
I just encountered Play 1.x module externalconfig that could help. Seems to work for our purposes. As an extra, this helps to keep production passwords etc out from the VCS.
Note that this module works only within Play's Java code - Play modules implemented in Python (as migrate, for example) won't be aware of external configuration. There might be concerns also with other Java modules that rely on onConfigurationRead().
#include have worked for our setup where we import different environment configurations on play 1.2.5.
If your team is small, have each dev check in their own config each with their own prefixed user-key:
%[user-key].[property]=[value]
each developer will then have to change starting up play with
play run --%[user-key] instead of simply play run
What we do is create a application.template configuration for the VCS that has the recomended configuration (instead of the actual application.conf).
This way every developer is responsible to create their own application.conf and to improve the template in the VCS.
This way no one mess with the deploy configuration and the configuration of the other developers.
If you want to version control the deployment configuration just add this to the tagged versions of your VCS
I would like to write a junit test for my Checkstyle extension. Can someone show me how to do it? I know there is a project in github called JUnit-Checkstyle-Test-Wrapper. However, I don't see how using this tool would help me get to my extension and verify its values.
thanks.
Probably the best reference for how to test your checkstyle extension (I assume you've added a checker) is to look at the checkstyle source code, and just copy & change one of the existing tests. For example, here is the test for HeaderCheck. This is probably the best way to start. Remember you can actually extend the Checkstyle test classes.
take a look at a lot of examples for custom Checkstyle checks and UTs for them https://github.com/sevntu-checkstyle/sevntu.checkstyle/tree/master/sevntu-checks
We work with a lot of legacy code and we think about introducing some metrics for new code. Is it possible to let Findbugs and Checkstyle run on changed files only instead of a complete project?
It would be nice to assure that only file with a minimum of quality is checked in, but the code base itself is not (yet) touched and evaluated not to confuse people by thousands of issues.
In theory, it would be possible. You would use a shell script to parse the SVN (or whatever SCM) change logs after a given start date, identify the .java files from these change sets and build two patterns from these:
The Findbugs Maven Plugin expects a comma-separated list of class (or
package) names for the parameter onlyAnalyze, so you'll have
to translate file names to fully qualified class names (this will get
tricky when you're dealing with inner classes)
The Maven Checkstyle Plugin is even worse, it expects a
configuration file for its packageNamesLocation parameter.
Unfortunately, only packages are allowed, not individual files. So
you'll have to translate file names to packages.
In the above examples I assume that you are using maven. I am pretty sure that similar things can be done with ant, but I wouldn't know.
I myself would probably use a Groovy script instead of a shell script to achieve the above results.
Findbugs has ant tasks that can do diffs against different findbugs results to see just the deltas, so only reporting new bugs, see
http://findbugs.sourceforge.net/manual/datamining.html