0

I have created a Maven plugin (called unpackTemplates) that unpacks a dependency jar file and copies resource files (in this case, templates) from it into a specific location in a project.

Right now, I put the following into the pom file of every project that has a dependency with templates. It looks like:

<project>
   <groupId>DuriansAreDope</groupId>
   <artifactId>DuriansAreDope</artifactId>
   <version>0.0.1-SNAPSHOT</version>
   <build>
      <plugin>
         <groupId>mycorp</groupId>
         <artifactId>unpackTemplates</artifactId>
         <version>1.0</version>
         <executions>
            <execution>
               <configuration>
                  <groupId>com.mycorp.lib</groupId>
                  <version>1.0</version>
                  <artifactId>Lib-With-Templates</artifactId>
               </configuration>
               <goals>
                  <goal>unpackTemplates</goal>
               </goals>
               <phase>generate-sources</phase>
            </execution>
         </executions>
      </plugin>
      <pluginManagement>....</pluginManagement>
   </build>
   <dependencies>
      <dependency>
         <groupId>com.mycorp.lib</groupId>
         <artifactId>Lib-With-Templates</artifactId>
         <version>1.0</version>
      </dependency>
   </dependencies>
</project>

The above project pom works for us. It calls the plugin and the plugin does it's job. However, we'd like to avoid adding the plugin section to the pom of every project.

It would make more sense to put that plugin section in the dependencies pom. This way the project pom does not need to be modified beyond adding the <dependency> tags as usual. And the dependency has it's plugin run wherever it is installed.

I've seen that the pom file for Gson contains a <build><plugins>...</plugins></build> section in it. When I give my dependencies the following pom files, however, the plugin is not run (although the dependency is found, downloaded, installed, etc correctly).

<project>
   <groupId>com.mycorp.lib</groupId>
   <artifactId>Lib-With-Templates</artifactId>
   <version>1.0</version>
   <build>
      <plugin>
         <groupId>mycorp</groupId>
         <artifactId>unpackTemplates</artifactId>
         <version>1.0</version>
         <executions>
            <execution>
               <configuration>
                  <groupId>com.mycorp.lib</groupId>
                  <version>1.0</version>
                  <artifactId>Lib-With-Templates</artifactId>
               </configuration>
               <goals>
                  <goal>unpackTemplates</goal>
               </goals>
               <phase>generate-sources</phase>
            </execution>
         </executions>
      </plugin>
      <pluginManagement>....</pluginManagement>
   </build>
</project>

Any ideas what I'm doing wrong, or if the Gson pom is simply doing something else entirely?

(NB: The groupId/version/artifactIds in <configuration> are necessary because they are (string) parameters to the plugin; presumably if I got the run-straight-from-dependency approach working I could refactor them away, but again, it's not even running the kludgy version with parameters.)

aarondev
  • 95
  • 6
  • Apart from your plugin do you know that that [kind of plugin already exists?](http://maven.apache.org/plugins/maven-remote-resources-plugin/examples/sharing-resources.html). May be i oversight something but i'm not sure what exactly your problem is? Cause you wrote `It would make more sense to have the library know that the last step of its installation is to run the plugin.` but about which library are you talking. May be you can elaborate that a little bit more. – khmarbaise Jun 04 '13 at 06:59
  • Thanks @khmarbaise. We had found the maven "unpack" plugin, but not the "remote resources" one that you've linked to. Judging from the structure of the parameters, I'd say that they both do similar things: copy files from a dependency into your project. However, we need to have more control over the files: we need to rename them and drop them in specific locations. – aarondev Jun 04 '13 at 13:32
  • @khmarbaise: To elaborate on that last bit: instead of adding the call-to-the-plugin to the project, we'd like to add it to the dependency itself. We're hoping that means the plugin gets run wherever the dependency is installed, without the project needing to know about the the plugin or how to call it. – aarondev Jun 04 '13 at 13:41

1 Answers1

0

two points:

First I agree with khmarbaise in that you don't need a plugin of your own for those tasks. To unpack to a specific location you can use dependency:unpack-dependencies and outputDirectory parameter. If you need more configuration you can use the assembly plugin to structure your artifact (which you want to unpack).

For the second point it seems to me that you want to use the contents of your lib-with-templates in many projects. Why don't you add the plugin and dependency to a parent pom which you include in every pom where you need it? Then you don't need to declare it in "every pom". If you don't really need it in every pom you can put it in a profile and choose a proper activation for it.

HTH!

Jan
  • 930
  • 9
  • 25