This approach is ok too and sometimes required. Checkstyle can read its
config from the classpath so unpack isn't needed, but this isn't true for
all tools. In that case, dependency unpack is the best alternative.
On 1/21/09 7:47 AM, "jie...@gmail.com" <jie...@gmail.com> wrote:
> Just thought I would chime in with yet another alternative approach, I
> employ a solution slightly different than Brian's assembly solution.
> It is possibly not to be considered clean by the Maven crocodiles. :-)
>
> My top level enterprise parent pom has a few support modules
> immediately in its SCM hierarchy. Some of these modules are nothing
> more than configuration files, e.g. checkstyle.xml, stylesheet.css
> (for maven-javadoc-plugin), etc. They are default <packaging>jar and
> contain nothing but a src/main/resources/com/acme/base/<filename>.
> Then, in the enterprise parent pom I do something like:
>
> <build>
> <plugins>
> <plugin>
> <artifactId>maven-dependency-plugin</artifactId>
> <executions>
> <execution>
> <id>Explode com.acme.base:common-config-checkstyle</id>
> <phase>generate-resources</phase>
> <goals>
> <goal>unpack</goal>
> </goals>
> <configuration>
> <artifactItems>
> <artifactItem>
> <groupId>com.acme.base</groupId>
> <artifactId>common-config-checkstyle</artifactId>
> <overWrite>false</overWrite>
> <outputDirectory>src/main/resources</outputDirectory>
> </artifactItem>
> </artifactItems>
> <silent>true</silent>
> </configuration>
> </execution>
>
> Since this is executed for every sub-module, everyone that inherits
> from this master enterprise base parent (every Maven project in our
> shop) will automatically get the most up to date, and corporate policy
> adhering, configuration file. In your plugins which exploit these
> configuration files, you can simply refer to
> ${basedir}/src/main/resources/com/acme/base/checkstyle.xml, e.g.
>
> I think the only thing that I would change about this solution is that
> having these things unpack during the generate-resources phase is a
> bit too aggressive for our usage pattern. I could probably bring to
> something closer to the install phase, but we then might lose the
> ability to do clever things like mvn checkstyle:checkstyle directly...
> Ideally, I could refer to a resource in a Spring-like manner, e.g.
> classpath:com/acme/base/checkstyle.xml and then I wouldn't need any
> unpack executions in the <build> at all!! Oooh, what a sweet dream
> that would be.. :-) Anyhow, I have a half dozen of these
> common-config-* modules and things are working out pretty smooth
> otherwise.
>
> Good luck!
> -jesse
>
> On Wed, Jan 21, 2009 at 4:01 AM, kukudas <kukuda...@googlemail.com> wrote:
>>
>> Thanks for the clearing Brian,
>>
>> i have read your tutorial and it seems a good approach, however i thought
>> about an alternative aproach maybe you can give me your opinion about it.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
