On May 26, 2009, at 9:02 PM, Daniel wrote:
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?
At least not for custom plugins, except if there are performance
issues. The Gradle core does implement all plugins in Java. The reason
is that we want to have a pure Java core which can be used without
Groovy. This gives us the possibility in the future to easily add
build script engines for other languages (in particular Java).
- Hans
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
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
