title: Gradle change resource files target location in JAR
body: <p>I am Gradle-fying a legacy project with the following structure:</p>
  
  <pre><code>root
  +--- common
  |    \--- config
  +--- module1
  \--- module2
  </code></pre>
  
  <p>In the original project, <code>config</code> is just a folder that contains configuration files organized in subfolders for different environments. It contains a top level folder <code>props</code> and many subfolders as in:</p>
  
  <pre><code>config
  \--- props
       +--- prod
       +--- dev
       +--- john
       \--- mike
  </code></pre>
  
  <p>The project can be configured to use any of the subfolders. The configuration gets loaded by a method that looks like this:</p>
  
  <pre><code>Config.class.getClassLoader().getResourceAsStream("props/" + ENV + "/" + name);
  </code></pre>
  
  <p>where <code>ENV</code> defines the environment (it's a system property), i.e., it can be <code>prod</code>, <code>dev</code>, <code>mike</code>, etc., and <code>name</code> is just the name of the file to load.</p>
  
  <p>When running tests, I need to have the <code>props</code> folder in the classpath. When building the production artifacts (JARs and WARs) I wan't to avoid that and manually copy only the files I need in order to avoid possible conflicts or accidents.</p>
  
  <p>So I decided to make <code>config</code> its own Gradle project and add it as a testCompile dependency to other modules that require configuration. However, if I add the <code>props</code> folder as a resource folder in Gradle, the generate JAR file for the <code>config</code> module will flatten all the subfolders of <code>props</code> (which is the intended behavior), and thus the code above will simply fail. </p>
  
  <p>My question is: is there a way to tell Gradle to copy those files to a subfolder called props instead of to the root of the JAR? </p>
  
  <p>I know it would be easy to refactor the project and move the folders around but we are in a phase of transition from legacy build and deployment tools and want to maintain the original structure as much as possible until we can switch to Gradle completely. It's an iterative process and can't happen overnight. So I need an interim solution.</p>