I have a ton of ant projects which I want to migrate to gradle. All projects have in common a config.xml file. This file exists for reasons independent of the build, but I want to keep its information in a single place, so I evaluate it during the ant build as well.
I created a custom plugin with a PluginExtension and a ParserTask. The PluginExtension allows the user to provide the config.xml path as a propertie. The ParserTask locates the file automatically or using the provided path and parses the file if found. It then fills the remaining PluginExtension properties with the respective configuration data from config.xml.
This is working perfectly but has a major drawback: since parsing is done in a task, the respective properties of the PluginExtension are not filled with the information from config.xml during configuration phase of my build. This leads to all kind of smelly workarounds in my build file because I can't set the archives basename at configuration phase or configure the manifest in that phase, so I need to update this information during the execution phase.
How can I parse the config.xml during my build such that the properties are already filled with the correct values during configuration phase?
Moving the configuration information to a properties file and regenerating the config.xml during build time is NOT an option, because I need to maintain the ant build for a while as well. Additionally I need to config.xml file to be part of the version control.
Edit: despite having found an answer myself, I'm still interested in other responses, especially if they address the downside that I have left.
I now moved the parsing into the PluginExtension and called the parser from the PluginExtension Constructor. One downside is left. I can no longer configure where to search for the config.xml using that extension. Instead I have to rely entirely on file search. This is OK for my current use case.
Related
Is there a way to have the spring-configuration-metadata.json file generated in the project files resources/META-INF (as opposed to target\classes\META-INF\spring-configuration-metadata.json) so that it can be pushed to version control on change?
Using spring-boot-configuration-processor dependency with maven
Quickly glancing through the source code of the relevant part of the configuration processor implementation it looks like its hard coded.
Since the spring-boot-configuration-processor works during the "compile" phase of maven, you can probably move the generated file by using other maven plugins (like ant run plugin, filtering probably and so on and so forth). And this should be a direct answer to your question
However, to be honest I don't think you should store this file in version control system for two main reasons:
This file is not a source code in the sense that you or your co-workers should edit it manually.
If someone from your team does refactoring in IDE it may accidentally change stuff in the file, so it will be hard to keep it in-sync. The current implementation makes sure that it will be generated during the compilation process so that it won't happen. The compilation time overhead is negligible.
So bottom line I believe it should be kept in the target folder
We have a maven based Java EE project controlled by the customer. For internal reasons, we cannot execute one of the build steps, but the rest works fine and produces the jar we want.
Since editing the pom file would require taking care when committing to customer's SVN and copying the pom file would require taking care to sync changes comming from there, we are looking for a way to skip this specific step in the build section during the maven call itself, so to say mvn clean install but-leave-out-this-build-plugin-step, is there any?
Edit:
The plugin in question is the rpm-maven-plugin, which prevents the build from running on Windows. We found information how to make it work which won't really fit in our current setup. And since we cannot modify the customer's pom, I was looking for a way to trigger the skipping externally. But maybe there are other ways to just ignore/skip/fake this step?
It depends on what plugin you want to skip. Many plugins have ability to be skipped via system property (-Dblabla).
For deploy plugin it is -Dmaven.deploy.skip=true, for surefire -DskipTests=true.
Read plugin documentation, maybe you can find skip property
The rpm plugin hase a property disabled, unfortunately it is not accessible by a property. So, if setting this property in the customer's pom (or asking for editing it) with a default value of false is an option, this may be the solution.
The code base I am working with has a lot of generated code. In addition, there are also some deprecated files that I would want to exclude from SonarQube analysis. I've read up the documentation and looked at some answers on here about that, but it does not help in my case.
I have a multi-module maven project. So I have multiple projects in my workspace that are all part of a large application. Say I want to exclude this file:
/home/username/workspace/com.mst.rtra.importing.message/bin/com/mst/rtra/importing/message/idl/parse/idlparser.java
I don't really know how to write this in the exclusions settings on SonarQube because of how long the filepath is. Also, what if I want to exclude another file, but from a different module, say :
/home/username/workspace/com.mst.rtra.interpreter.create/
I am confused about I should write this in the exclusions box in project settings. Should I write the absolute file path due to the multi-module nature of this project? Or is there some other convention used?
In addition, if I want to exclude generated files from analysis, I would need to put file:/generated-sources/ as I saw in another answer. However, after analysis, I can still view the analysis results of those files when I open up the project in SonarQube dashboard.
We use ant rather than maven, and an older version of the Sonar ant task at that. But what works for us is setting a sonar.exclusions property in our build.xml, which accepts wildcards for filenames. For example:
<property name="sonar.exclusions" value="**/com/ex/wsdl/asvc/*.java,**/com/ex/wsdl/bsvc/*.java"/>
That skips analyzing all the code generated from a wsdl file for two services. You ought to be able to do something similar for maven.
We are using maven filtering for properties file, in which we inject the build number and time from out Jenkins server.
It would be cool if we could add there properties to our app.local.properties file dynamically, thus not forcing each project maintainer to add them (one time operation, but annoying never the less).
I would like to
Add params to a properties file, before the filter plugin kicks in.
If the destination properties file does not exist -> create it and then add.
I need to edit the properties file in the target directory (the src/main/resources dir should remain untouched).
Nice to have:
Add configuration settings only if they aren't already defined in the file (to avoid duplicating entries added manually)
Is there some maven plugin / hook that I can tap into to do this?
you could build a custom maven build extension and retrieve those properties dynamically from a cetntral service and inject them into the POM in memory, right after the build process starts. Indeed that is how we solved this very problem in our company setup.
I've just posted a full recipe to this Stackoverflow answer
I see a conflict here:
Add params to a properties file, before the filter plugin kicks in.
So you need to edit the properties in src/main/resources, as filter plugin works on these, but at the same time:
I need to edit the properties file in the target directory (the src/main/resources dir should remain untouched).
What I understand is, you'd like to do this filtering somehow "on the fly". I don't think Maven mechanisms could do it; I'd do it completely with the Antrun plugin (excluding the property file from Maven handling) which I'd invoke in the process-resources phase. There's a propertyFile task for editing and saving property files; after saving your changes, you could process the file once more with the regexp task, for example, to apply your filters.
My need is pretty basic but I could not find any clean answer to it: I simply need to be able to distribute a resource in a multi-module project.
Let us consider for example the LICENSE file, which I hereby assume to be the same for all modules. I prefer not to manually copy it into each and every module because the file could change over time. I also prefer not to statically link to resources (even if using relative paths) outside the project folder, because the modular structure can possibly change too.
Is there any plugin that can be used to robustly guarantee that each module is given the required file? It would be equally acceptable for such copy to be obtained by exploiting the POM of the parent project or directly performed by the super project in the modular hierarchy.
you could use the assembly and the dependency plugins.. did you stumble over that link?
http://www.sonatype.com/people/2008/04/how-to-share-resources-across-projects-in-maven/
it describes that option ..its from 2008, but maven is around for quite some time.. so I guess its more or less up to date
edit regarding comment
Another option is the maven-remote-resources-plugin.
For a more detailed example see:
http://maven.apache.org/plugins/maven-remote-resources-plugin/examples/sharing-resources.html
Since their intro speaks actually for itself, I quote (maven.apache.org)
This plugin is used to retrieve JARs of resources from remote repositories, process those resources, and incorporate them into JARs you build with Maven. A very common use-case is the need to package certain resources in a consistent way across your organization: at Apache it is required that every JAR produced contains a copy of the Apache license and a notice file that references all used software in a given project.