On May 25, 2009, at 3:05 PM, Helmut Denk wrote:
hi gradle-users,
i am just about to upgrade and improve my
http://www.nabble.com/common-resolver-setup-across-multiple-gradle-builds-to19570795.html
gradle-customization and want to
share the results ... maybe get some feedback ;-)
here my gradle-build for a spring-web-mvc-project, that
uses custom-resolver-setup:
usePlugin('war')
usePlugin('groovy')
usePlugin('custom-repositories')
artifacts {
archives war
}
dependencies {
compile project(":www-services-common")
compile 'javax.servlet:servlet-api:2.4'
compile 'apache:commons-logging:1.1'
compile 'org.springframework:spring:2.5.4'
compile 'org.springframework:spring-webmvc:2.5.4'
groovy 'org.codehaus.groovy:groovy-all:1.6.3'
testCompile 'org.springframework:spring-test:2.5.4'
testCompile 'org.gmock:gmock:0.8.0'
testCompile 'org.hamcrest:hamcrest-core:1.1'
testCompile 'org.hamcrest:hamcrest-library:1.1'
testCompile 'junit:junit:3.8.1'
}
the 'usePlugin('custom-repositories')' tells gradle to use
mycompany.CustomRepositoriesPlugin, which adds Resolvers
to adapt our inhouse repository-infrastructure.
here is, what CustomRepositoriesPlugin.java does for
the classpathResolvers:
public void apply(Project project, PluginRegistry pluginRegistry,
Map<String, ?> customValues) {
...
ResolverContainer classpathResolvers = project.getRepositories()
classpathResolvers.add(localResolver);
classpathResolvers.add(teamResolver);
classpathResolvers.add(snapshotResolver);
classpathResolvers.add(releasedResolver);
classpathResolvers.add(thirdpartyResolver);
...
}
here is what CustomRepositoriesPlugin.java does for
the uploadResolvers:
public void apply(Project project, PluginRegistry pluginRegistry,
Map<String, ?> customValues) {
...
if (project.getTasks().findByName("uploadLibs") == null) {
logger.info("setting up task uploadLibs ...");
Configuration uploadConfiguration =
project.getConfigurations().findByName("archives");
if (uploadConfiguration == null) {
throw new GradleException("Configuration 'archives' erwartet,
wurde aber
nicht gefunden");
}
project.getTasks().add("uploadLibs", Upload.class);
Upload uploadLibsTask = (Upload)
project.getTasks().findByName("uploadLibs");
uploadLibsTask.setConfiguration(uploadConfiguration);
String deliverTo = (String) project.property("deliverTo");
ResolverContainer uploadResolvers =
uploadLibsTask.getRepositories()
if ("local".equals(deliverTo)) {
uploadResolvers.add(localResolver);
} else if ("shared".equals(deliverTo)) {
uploadResolvers.add(sharedResolver);
} else if ("snapshot".equals(deliverTo)) {
uploadResolvers.add(snapshotResolver);
} else if ("released".equals(deliverTo)) {
uploadResolvers.add(releasedResolver);
} else {
throw new GradleException("erlaubter Wert fuer Project-
Property
'deliverTo' erwartet, aber war: " + deliverTo);
}
} else {
logger.warn("task uploadLibs existiert bereits");
}
...
}
as you see, i create a uploadLibs task for the project and add
a uploadResolver to it. but i am not sure, if this is a smart way
to achieve what i want ... if someone has a better idea, i am
all ears ...
Basically this is solid stuff in my opinion. Thanks for sharing this.
But as soon as you want task creation based on parameter you might
thing about the new Gradle 0.6 rule engine.
You could create a rule for the pattern upload<DeliverTo>
The the users can write:
gradle uploadLocal or gradle uploadShared, ...
Your rule would analyze the pattern and for unknown DeliverTool values
it would do nothing and an UnknownTaskEx would be thrown.
See UG 12.7: http://gradle.org/0.6/docs/userguide/more_about_tasks.html#N10B02
Why are you writing your plugin in Java? If you would do it in Groovy
it might make the code more expressive as you could use a more DSL'is
way of doing things.
***
an issue, that i noticed and which was already discussed in
the mailinglist:
setScanForTestClasses does not work because i use gmock
and have some test-classes like this:
public class MyTests extends GMockTestCase {
...
}
i circumvent this by adding the following code
to the customization:
public void apply(Project project, PluginRegistry pluginRegistry,
Map<String, ?> customValues) {
...
// set include/exclude-pattern für junit
Test testTask = (Test) project.getTasks().findByName("test");
if (testTask != null) {
testTask.setScanForTestClasses(false);
testTask.setStopAtFailuresOrErrors(false);
testTask.include("**/*Test.class", "**/*Tests.class");
testTask.exclude("**/Abstract*.class");
}
...
}
This will be fixed in the soon to come 0.6.1 bug fix release.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
