I'm looking for the appropriate location to place resources that are used by the build, like a license header template file or a file with code formatter settings.
The buildSrc seems like the most appropiate place (e.g. buildSrc/src/main/resources), but I only found it mentioned in the context of Build sources.
Another option would be src/build/resources. Perhaps there are better locations I didn't consider.
What would be the most appropriate directory for these resources?
In many gradle builds the convention of using $rootproject/gradle as folder for build resources has been established. you can have a config folder to store your license files / checkstyle configs etc. in there.
Related
I am having trouble getting a good work flow using Maven for a webapp.
My context.xml fragment points to the target/MY_WEB_APP folder and so I would like a quick way to get modified resource files into that folder.
My resource files are in src/main/resources and they get copied to target/classes when I run Maven resources:resources. However unless I run a full build I don't get those files in the target/MY_WEB_APP folder. The full build takes a couple of minutes and I only want to copy the modified resource files.
All of the resources are classpath resources and are hot swappable as the frameworks can be set to auto-reload. An example is the Struts config files that are auto-reloaded on each request as I have set struts.devMode=true. Hence if I can get it into the correct location then I don't need to do a full build.
Currently I have a text editor that has the open resource file target/MY_WEB_APP/WEB-INF/classes/my-resource.xml and I manually copy the modified file from my IDE into the editor. This is obviously a very, very silly way to work and there must be a better way.
How can this be done without the manual copy and paste?
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.
The follow structure
src
service
service1
Service.java
Service.properties
I want that the output generated by gradle would be
classes
service
service1
Service.class
Service.properties
So, I need that the files(.properties) keep in the same directory of the class after build, but the gradle copy the files .properties (resources) to another directory
how can I do it?
I assume you are trying to place them there so they can be loaded from the classpath? The best way to make them available to your class loader is to place them into src/main/resources which is part of the standard directory layout. Gradle will find them there and they will be placed at the root of your jar (by default I believe it ignores property files in src/main/java).
It would also be good to move your java files to to src/main/java. Using the standard directory layout is a convention that will help other developers understand the code. It also allows you to use certain tools out of the box with less configuration because those tools can make assumptions about where things live.
So the new structure would be like:
service1-project
src
main
java
service1.java
resources
service.properties
If you use the standard directory layout, I think you will achieve the end-result of what you are trying to do (which is really to load the properties file within Java). If for some reason you have to avoid the standard directory layout, then you have to start doing custom configuration (a downside of using a non-standard project layout). In Gradle, you should be able to do this by hooking into the Java Plugin's processSourceSetResources target.
I'd like to generate some resources (JavaHelp search index in this case), but I can't seen to see where those generate files should go to get into the jar. I put them in target/generated-sources, but they are ignored. Should it be target/classes?
/generated-sources directory is used by various tools generating sources (duh!), like xjc or wsdl2java. This directory is later included in the compilation phase.
/target/classes is everything that should be included in the final JAR, which answers your question. Also the contents of /src/main/resources is included, but this directory is typically part of version control and is not meant for generated artifacts.
It turns out that generated-source directories are not automatically included in the jar. However, Intellj assumes there are and treats them as such, hence my confusion.
You need to use the Maven build helper plugin to fix this issue, for example:
https://github.com/alexec/javahelp-skeleton/blob/master/pom.xml
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.