Many thanks for the tip Andrew, it's been very useful! The example is great, but it only activates the profile for the jclouds-project module, and we'll need it for every module in the jclouds repo. I've added a new profile and tried to configure its activation to be enabled for all projects, but:
* Only file activation can be used, since other types (property based, etc) would activate the profile also for the other git repositories that inherit from jclouds-project. * File based activation only performs variable substitution for system properties (provided in the command line), but not for properties generated in the pom.xml, which makes it not flexible enough for our needs. These points, and the fact that the modules in the jclouds repo don't have all the same depth, makes it impossible to configure the profile with a file activation that works for every Maven module in the jclouds repo (and not for the others). At least I haven't found how. Then I can only think about two approaches: 1. By default, look for the configuration in the local path, and have a separate profile to use the one in the classpath. The labs and other repos should manually provide the -Pcheckstyle parameter in order to be able to read the configuration (this can be easily added to the Jenkins builds) when running the "checkstyle:checkstyle" goal. 2. By default, look for the configuration in the classpath, and have a profile in the jclouds-project, only activated for it, that uses the local filesystem one. This way: * The jclouds-project will still be the first project to be built (no missing dependency issues). * The jclouds-resources will be the second project to be built, which will install the checkstyle config in the local maven repo. * The other modules in the repo and other repos can be built reading the checkstyle configuration from the classpath (from the installed jclouds-resources jar). This second approach has one limitation: The jclouds-resources.jar must be in the local maven repository, in order to let the modules get the checkstyle configuration. This means that the following command may not work because the jclouds-resources.jar will only be built but not installed to the local Maven repo. mvn clean verify checkstyle:checkstyle Currently this is how the pull requests builds are configured (which is good; we don'w want the artifacts from PR builds, installed in the local repo). If we configure the profiles like point 2, the PR builds would take the checkstyle config from the last deployed snapshot, and this is not a consistent behavior. So... Does anyone have a better idea? If not, do we go for approach 1 or approach 2? Thanks! Ignasi On 28 June 2013 15:02, Andrew Phillips <[email protected]> wrote: >> In order to use the checkstyle.ml config from the classpath, the >> maven-checkstyle-plugin must declare the jclouds-resources dependency >> in its configuration. The problem is that the plugin is configured in >> the jclouds-project, which is the parent pom, and that means the >> jclouds-project needs to have the jclouds-resources.jar in the maven >> repo *before* it can be actually built, and this is where the build >> breaks. > > > What we did when we still used a remote resource for the license files, > which caused the same problem, is to have a jclouds-project profile [1] > which *disabled* the remote-resources execution for jclouds-project only. > > Checkstyle could still work for jclouds-project, it would simply have to > refer to the files by path (since they're in the same repo) rather than use > a dependency. > > Let me know if I can help any more with this! > > ap > > [1] > https://github.com/jclouds/jclouds/blob/ddfb8e58a5a729cabb5edf954a113ee8127cd7cb/project/pom.xml#L912
