Yes, that makes sense, but I think I didn't explain properly the problem :)
What you say is the 2nd option I suggested: one default profile that works for every project in any repo, and a custom profile for jclouds-project to avoid the dependency issue (but it presents the mvn clean verify limitation). To avoid the "mvn clean verify" issue, the default profile should not pick the checkstyle config from the classpath. This is the current config in master (but it does not work for other repos as they don't have a copy of the checkstyle config file). The ideal thing should be to keep this default profile and have another one that is only active for the other repos, but I haven't found how to configure it, due to the limitations of the profile activation I mentioned. And I'm stuck there. Does this make sense now, or am I just complicating too much a simple thing I can't figure out? Thanks for the follow up! El 29/06/2013 16:03, "Andrew Phillips" <[email protected]> escribió: > 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: >> > > Wait...the idea behind the profile is to *deactivate* remote-resources! So > it's indeed intentional that the profile is *only* active in > jclouds-project. > > There's a *default* invocation (not in a profile) that runs for *all* > projects. The profile is only intended to override that default invocation > to stop remote-resources being run in jclouds-project, which causes the > missing dependency problem you saw. > > Does this make more sense? > > ap >
