Oh, that was something that I was wondering about while browsing the code (and looking through the Scala Plugin patch): There's no actual reason to write plugins in Java, or is there?
Cheers, Daniel On Wed, May 27, 2009 at 1:55 AM, Hans Dockter <[email protected]> wrote: > > 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 > > >
