common resolver-setup across multiple gradle-builds

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

common resolver-setup across multiple gradle-builds

helmut.denk
hi gradle users,

to share common resolver-setup across multiple gradle-builds
i implemented a class 'ResolverSetup' and use it like this:

*** schnipp *** 
subprojects {
    usePlugin('groovy')
	
    sourceCompatibility = 1.4
    targetCompatibility = 1.4
    group = 'com.mycompany'
    version = '1.0'
    type = 'jar'
    test.stopAtFailuresOrErrors=false

    // ResolverSetup ist custom-BuildLogik -> buildSrc und
    // dient als temporäre Lösung zur einheitlichen Definition 
    // der Resolver (classpath, upload).
    ResolverSetup resolverSetup = new ResolverSetup(project)
	
    dependencies {
    	resolverSetup.setupClasspathResolvers(classpathResolvers);
    }
    uploadLibs {
        resolverSetup.setupUploadResolvers(uploadResolvers);
    }
}
*** schnapp ***

i put the class ResolverSetup into buildSrc/main/java
of each project. but this is not dry.

may be a custom-plugin is what i need here ... ?

have a nice day !
Reply | Threaded
Open this post in threaded view
|

Re: common resolver-setup across multiple gradle-builds

hans_d
Administrator
Hi Helmut,

On Sep 19, 2008, at 1:39 PM, Helmut Denk wrote:

>
> hi gradle users,
>
> to share common resolver-setup across multiple gradle-builds
> i implemented a class 'ResolverSetup' and use it like this:
>
>
> *** schnipp ***
> subprojects {
>     usePlugin('groovy')
>
>     sourceCompatibility = 1.4
>     targetCompatibility = 1.4
>     group = 'com.mycompany'
>     version = '1.0'
>     type = 'jar'

The type property is not in use any longer, unless you use it as a  
custom property. The plugins 'java' and 'groovy' create a jar by  
default, 'war' a war.

>     test.stopAtFailuresOrErrors=false
>
>     // ResolverSetup ist custom-BuildLogik -> buildSrc und
>     // dient als temporäre Lösung zur einheitlichen Definition
>     // der Resolver (classpath, upload).
>     ResolverSetup resolverSetup = new ResolverSetup(project)
>
>     dependencies {
>     resolverSetup.setupClasspathResolvers(classpathResolvers);
>     }
>     uploadLibs {
>         resolverSetup.setupUploadResolvers(uploadResolvers);
>     }
> }
> *** schnapp ***
>
>
> i put the class ResolverSetup into buildSrc/main/java
> of each project. but this is not dry.
>
> may be a custom-plugin is what i need here ... ?

An alternative is to create a separate project for what is now in the  
buildSrc. The artifact produced by this project might be: resolver-
setup-1.0.jar

Now you can add the jar to the build script classpath:

In the settings.gradle file of each of your gradle build you can define:

dependencies 'org:resolver-setup-1.0.jar'

See http://www.gradle.org/api/0.4/org/gradle/api/initialization/ 
Settings.html on how to define resolvers.

Now you can leave either the rest as they are or you use a plugin.  
Your resolver set-up project might contain a plugin. Then in your  
build.gradle file you can say

usePlugin('com.helmutcomp.resolversetup.ResolverPlugin')

instead of doing the stuff in your snippet below  
test.stopAtFailuresOrErrors.

I think the easiest way to learn about our plugin system is to look  
at a simple plugin like War plugin. In general our plugin system is  
very simple at the moment. Making it more powerful is one of the  
major steps towards 1.0.

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: common resolver-setup across multiple gradle-builds

helmut.denk
hallo hans,

very helpful. thanks.
i'll try it out and give feedback.

have a nice weekend.
Reply | Threaded
Open this post in threaded view
|

Re: common resolver-setup across multiple gradle-builds

helmut.denk
hallo hans,

i put everything in plugins and it seems to work.
build.gradle now looks like this:

subprojects {
    usePlugin('custom-groovy')
	
    sourceCompatibility = 1.4
    targetCompatibility = 1.4
    group = 'com.mycompany'
    version = '1.0'
}

for those who are interested in details:

*step 1*

i implemented a standalone project 'gradle-customizations'
with a gradle-build. this project contains following classes:

- com.mycompany.gradle.CustomPluginBase (implements Plugin)
- com.mycompany.gradle.CustomJavaPlugin (extends CustomPluginBase)
- com.mycompany.gradle.CustomGroovyPlugin (extends CustomPluginBase)
- com.mycompany.gradle.CustomWarPlugin (extends CustomPluginBase)

the customization-code defines mycompany-specific resolvers
(classpath, upload) and convention-settings.

*step 2*

i gradle-build 'gradle-customizations' and
copy the resulting jar to buildSrc/lib of
the gradle-builds, that want to use customizations.

*step 3*

i add the following lines to settings.gradle
of the gradle-builds, that want to use customizations:

addFlatDirResolver('lib', "$rootDir/buildSrc/lib")
dependencies(':gradle-customizations:1.0')

*step 4*

i add the following lines to $GRADLE_HOME/plugins.properties

custom-java=com.mycompany.gradle.CustomJavaPlugin
custom-groovy=com.mycompany.gradle.CustomGroovyPlugin
custom-war=com.mycompany.gradle.CustomWarPlugin

this is not DRY in steps 2 and 3. a solution of
this could be, that in the $HOME/.gradle/gradle.properties
there can be declared a resolver and source for
gradle-custom-extensions (plugins).

as always ... there might be even better solutions ;-)

have a successful day !

 

Reply | Threaded
Open this post in threaded view
|

Re: common resolver-setup across multiple gradle-builds

hans_d
Administrator

On Sep 26, 2008, at 11:31 AM, Helmut Denk wrote:

>
> hallo hans,
>
> i put everything in plugins and it seems to work.
> build.gradle now looks like this:
>
>
> subprojects {
>     usePlugin('custom-groovy')
>
>     sourceCompatibility = 1.4
>     targetCompatibility = 1.4
>     group = 'com.mycompany'
>     version = '1.0'
> }
>
>
> for those who are interested in details:
>
> *step 1*
>
> i implemented a standalone project 'gradle-customizations'
> with a gradle-build. this project contains following classes:
>
> - com.mycompany.gradle.CustomPluginBase (implements Plugin)
> - com.mycompany.gradle.CustomJavaPlugin (extends CustomPluginBase)
> - com.mycompany.gradle.CustomGroovyPlugin (extends CustomPluginBase)
> - com.mycompany.gradle.CustomWarPlugin (extends CustomPluginBase)
>
> the customization-code defines mycompany-specific resolvers
> (classpath, upload) and convention-settings.
>
> *step 2*
>
> i gradle-build 'gradle-customizations' and
> copy the resulting jar to buildSrc/lib of
> the gradle-builds, that want to use customizations.
>
> *step 3*
>
> i add the following lines to settings.gradle
> of the gradle-builds, that want to use customizations:
>
> addFlatDirResolver('lib', "$rootDir/buildSrc/lib")
> dependencies(':gradle-customizations:1.0')
>
> *step 4*
>
> i add the following lines to $GRADLE_HOME/plugins.properties
>
> custom-java=com.mycompany.gradle.CustomJavaPlugin
> custom-groovy=com.mycompany.gradle.CustomGroovyPlugin
> custom-war=com.mycompany.gradle.CustomWarPlugin

Just to mention it for other readers of this posting. There is also a  
usePlugin method where you can pass the plugin class (http://
gradle.org/api/0.4/org/gradle/api/Project.html#usePlugin
(java.lang.Class)). If you use this method you don't have to add your  
plugin to the plugin.properties file.

>
> this is not DRY in steps 2 and 3. a solution of
> this could be, that in the $HOME/.gradle/gradle.properties
> there can be declared a resolver and source for
> gradle-custom-extensions (plugins).

When we are going to start the discussion on the dev list about how  
to implement our new plugin system you are very welcome to  
participate :)

Thanks for posting this

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email