[GRADLE-2754] Reading project.properties triggers configuration of any DeferredConfigurable extensions Created: 18/Apr/13  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 1.5
Fix Version/s: None

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Won't Fix Votes: 2


 Description   

We are using the new incubating [PublishingExtension]([1]http://www.gradle.org/docs/1.5/dsl/or...) and registering an [IvyPublication]([2]http://www.gradle.org/docs/1.5/dsl/or...) in its publication container. Since we need to manually populate the `IvyPublication` with all artifacts from all configurations, we are relying on the deferred configuration support for this extension, and thus expect that the extension will be configured at the last possible moment so that all artifacts are already available.

Unfortunately it turns out that reading the project properties using [3]project.properties is triggering the configuration of the publishing extension and thus reading all configuration artifacts too early.
Shall we instruct all users not to do that? If this is "by design", then I guess it deserves to be documented as a known limitation - IMHO it is not that obvious that reading all project properties implies configuring all [DeferredConfigurable]([4]http://www.gradle.org/docs/current/ja...) extensions.
Do you have any suggestion how to make sure the build fails early, if a deferred configurable is configured before project is evaluated (which is undesirable in our case)?

P.S. We are using Gradle 1.5

Regards,
Detelin
----------------------------------------------------------------------------------------
[1] http://www.gradle.org/docs/1.5/dsl/org.gradle.api.publish.PublishingExtension.html
[2] http://www.gradle.org/docs/1.5/dsl/org.gradle.api.publish.ivy.IvyPublication.html
[3] http://www.gradle.org/docs/current/javadoc/org/gradle/api/Project.html#getProperties%28%29
[4] http://www.gradle.org/docs/current/javadoc/org/gradle/api/plugins/DeferredConfigurable.html

 Comments   
Comment by Gradle Forums [ 18/Apr/13 ]

Dev list discussion can be found here: [1]http://gradle.1045684.n5.nabble.com/C...
----------------------------------------------------------------------------------------
[1] http://gradle.1045684.n5.nabble.com/Calling-project-properties-triggers-configuration-of-deferred-configurables-tp5711226.html

Comment by Henry Tung [ 18/Dec/15 ]

Can confirm that this issue remains, and still affects Gradle as far as version 2.9.

For reference, the relevant stacktrace from the following build.gradle block shows where the errant execution takes place:

apply plugin: 'publishing'

publishing {
  new Exception().printStackTrace()
}

properties

yields the trace:

java.lang.Exception
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
	at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:80)
	at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:60)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:235)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:239)
	at build_cpb7oh0wqy8wgz4hvfbfwmjme$_run_closure1.doCall(<path>/build.gradle:4)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
	at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1019)
	at groovy.lang.Closure.call(Closure.java:426)
	at groovy.lang.Closure.call(Closure.java:442)
	at org.gradle.api.internal.ClosureBackedAction.execute(ClosureBackedAction.java:67)
	at org.gradle.listener.ActionBroadcast.execute(ActionBroadcast.java:39)
	at org.gradle.api.internal.plugins.ExtensionsStorage$DeferredConfigurableExtensionHolder.configureNow(ExtensionsStorage.java:183)
	at org.gradle.api.internal.plugins.ExtensionsStorage$DeferredConfigurableExtensionHolder.get(ExtensionsStorage.java:162)
	at org.gradle.api.internal.plugins.ExtensionsStorage.getAsMap(ExtensionsStorage.java:50)
	at org.gradle.api.internal.plugins.DefaultConvention$ExtensionsDynamicObject.getProperties(DefaultConvention.java:168)
	at org.gradle.api.internal.CompositeDynamicObject.getProperties(CompositeDynamicObject.java:130)
	at org.gradle.groovy.scripts.BasicScript.getProperties(BasicScript.java:71)
Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 12:30:35 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.