I understood that failing subproject simply doesn`t know anything about
'test-shared' project couse it is evaluated in alphabetical order before
'test-shared'. So I need a way how to define project dependency during
current project evaluation in root build.gradle. If I define this dependency
in subproject build.gradle, it will work I guess.
Narco wrote:
>
> Ok, plugin is what I need I guess. Started to migrate my project script to
> plugin. It is not so simple when plugin has its own subprojects{}.
> Annoying problem is that custom plugin is not printing user readable
> exceptions. Exception just points to line where custom plugin call is
> defined. Should I configure logger to some special way maybe?
>
> Simplest project configurations are building fine. I have stuck in adding
> compile dependency project to current subproject in plugin scope. This is
> my plugin:
>
> public class CsPlugin implements Plugin {
>
> def void use(Project project, ProjectPluginsContainer
> projectPluginsHandler) {
> project.subprojects {
> repositories {
> flatDir name: 'lib', dirs: 'lib'
> }
>
> ...
> usePlugin('java')
> delegate.dependencies {
> compile project(':test-shared')
> }
> ...
> }}}
>
> After then I create jar with classes and add it to my project:
> buildscript {
> repositories {
> flatDir name: 'lib', dirs: 'lib'
> }
> dependencies {
> classpath name: 'Main', version: 'unspecified'
> }
> }
> usePlugin(CsPlugin)
> allprojects {
> version = '3.0.1'
> group = 'lv.ctco.module'
> }
>
> The script throws exception:
> * Where:
> Build file 'C:\work\perf\SCM\Build\scripts\projects\Main\MDL\build.gradle'
> line:
> 35
>
> * What went wrong:
> A problem occurred evaluating root project 'MDL'.
> Cause: No signature of method:
> org.gradle.api.internal.artifacts.dsl.dependencie
> s.DefaultDependencyHandler.subproject() is applicable for argument types:
> (java.
> lang.String) values: [:test-shared]
>
> The plugin doesn`t see this project definition but I know it is defined in
> settings.gradle of project. Please help!
>
>
>
> Adam Murdoch-2 wrote:
>>
>>
>>
>> Narco wrote:
>>> Your help is still required.
>>>
>>>
>>> Narco wrote:
>>>
>>>> Anybody?
>>>>
>>>>
>>>> Narco wrote:
>>>>
>>>>> Hello!
>>>>> I need some guru help now. My goal initially was to develop gradle
>>>>> scripts as standalone package which after then can be added to any
>>>>> multi-project in build classpath to build with default
>>>>> configuration/layout/options which I have defined.
>>>>> To archieve that I have developed root/build.gradle script which works
>>>>> fine with my root/* projects and has no direct definition about any
>>>>> projects. Almost every root/* project (eg root/app/,
>>>>> root/ejb-module-session/) has build.gradle script to define
>>>>> dependencies
>>>>> between other projects and property file to mark its behaviour. Also I
>>>>> have root/setting.gradle where all my projects are defined.
>>>>> Now I want to make standalone file as discussed above.
>>
>> This sound pretty much like what a plugin does: it contains some build
>> logic which is reusable across multiple builds.
>>
>> At the moment, there's no way to implement a plugin as a script. You
>> need to implement it as a class.
>>
>>>>> As I understood
>>>>> from documentation buildSrc folder works absolutely the same if I
>>>>> would
>>>>> be adding jar with compiled build scripts to buildScript() so I
>>>>> started
>>>>> in this way.
>>>>>
>>
>> It contains compiled classes, not compiled build scripts. You use them
>> as you would any class. Gradle doesn't automatically apply any scripts
>> that it finds in buildSrc (though it might be good if there was
>> somewhere you could add scripts).
>>
>> You have a couple of options at this stage:
>>
>> - Implement your reusable code as a plugin.
>>
>> - Use GroovyShell in your root build script to execute the shared script.
>>
>>
>>>>> Adding to root/buildSrc/build.gradle did not worked at all. Gradle
>>>>> just
>>>>> says that none of default tasks (clean, compile etc) is defined.
>>>>> Adding to root/buildSrc/src/main/groovy started to process something
>>>>> but
>>>>> still gives another bad results:
>>>>> C:\work\perf\SCM\Build\Ant\Project\Release_2_0_1\MDL>gradle clean
>>>>> [ant:jar] Warning: skipping jar archive
>>>>> C:\work\perf\SCM\Build\Ant\Project\Relea
>>>>> se_2_0_1\MDL\buildSrc\build\libs\buildSrc-SNAPSHOT.jar because no
>>>>> files
>>>>> were inc
>>>>> luded.
>>>>> [ant:jar] Warning: skipping jar archive
>>>>> C:\work\perf\SCM\Build\Ant\Project\Relea
>>>>> se_2_0_1\MDL\buildSrc\build\libs\buildSrc-SNAPSHOT.jar because no
>>>>> files
>>>>> were inc
>>>>> luded.
>>>>>
>>>>> FAILURE: Build failed with an exception.
>>>>>
>>>>> * Where:
>>>>> Build file
>>>>> 'C:\work\perf\SCM\Build\Ant\Project\Release_2_0_1\MDL\ejb-module-sess
>>>>> ion\build.gradle' line: 10
>>>>>
>>>>> * What went wrong:
>>>>> A problem occurred evaluating project ':ejb-module-session'.
>>>>> Cause: No signature of method:
>>>>> org.gradle.api.internal.artifacts.dsl.dependencie
>>>>> s.DefaultDependencyHandler.compile() is applicable for argument types:
>>>>> (org.grad
>>>>> le.api.internal.artifacts.dependencies.DefaultProjectDependency)
>>>>> values:
>>>>> [Defaul
>>>>> tProjectDependency{dependencyProject='project ':app'',
>>>>> configurationdefault'}]
>>>>>
>>>>> * Try:
>>>>> Run with -s or -d option to get more details. Run with -S option to
>>>>> get
>>>>> the full
>>>>> (very verbose) stacktrace.
>>>>>
>>>>> BUILD FAILED
>>>>>
>>>>> Total time: 3.594 secs
>>>>>
>>>>> One more thing to think about. The functionality I need is not only
>>>>> common multi-project build but also ability to define some
>>>>> multi-project
>>>>> specific behavior in root/build.gradle or project specific in
>>>>> root/app/build.gradle for example. A half of year ago when starting to
>>>>> investigate gradle Hans was sure that this is possible. Now I`m ready
>>>>> to
>>>>> implement it!
>>>>>
>>>>> Please help me asap!
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>> --
>> Adam Murdoch
>> Gradle Developer
>> http://www.gradle.org
>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/buildsrc-and-buildScript%28%29-usability-for-multi-project-builds-tp25888572p25995963.html
Sent from the gradle-user mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
