Yep, sounds like you've got the gist of it.
The new configuration model will be developed incrementally in the Gradle
2.x release stream in a way that maintains backward compatibility for
existing builds.
Daz
On Tue, Apr 15, 2014 at 5:01 PM, Andrew Oberstar <ajobers...@gmail.com>wrote:
> Thanks for the reply Daz! Let me try to paraphrase that to make sure I'm
> understanding:
>
> - This configuration is literally targeted for 2.x and is not intended to
> be part of 2.0.
> - The MavenPublish and IvyPublish will probably remain incubating until
> that time.
> - The intention is still to allow some type of user interaction (task
> specification, build type, whatever) to modify the model before everything
> is locked down. i.e. I'll still have some option to provide this version
> inference in the new configuration model. See the issues/stories in the
> design spec:
> - Configuration of publications depends on the output of some task
> - Allow the project version to be determined early in the build
>
> Let me know if I'm still misunderstanding something.
>
> Andy
>
>
> On Tue, Apr 15, 2014 at 9:20 AM, Daz DeBoer <darrell.deb...@gradleware.com
> > wrote:
>
>> One big change coming in Gradle 2.x is a better configuration model.
>> While powerful, the current model involving laziness, live collections, etc
>> can be quite confusing and doesn't provide Gradle with the tools required
>> to improve configuration-time performance. The new configuration model will
>> be driven largely by the requirements of the native-binaries and android
>> support in Gradle, but we expect that it will feed into pretty much every
>> aspect of Gradle.
>>
>> Work on this has already started, in the form of ModelRules and the model
>> {} block in the native-binaries DSL. The new publishing plugins were an
>> early experimental attempt at driving out this new model, and as such they
>> are written in a way that generally assumes non-laziness and simpler
>> evaluation. This was possibly a bit premature, but explains why certain
>> design decisions were made. We expect the usability of the publishing
>> plugins to help drive some of the features of the new configuration model,
>> and these plugins should improve as it is developed.
>>
>> You can read more about the plans for the new model here:
>> https://github.com/gradle/gradle/blob/master/design-docs/unified-configuration-and-task-model.md.
>> Note that this spec is not entirely up-to-date with regard to some of the
>> upcoming changes required for Android support.
>>
>> I won't try to explain this in any more detail here. I'm sure you'll be
>> hearing a lot more about the planned changes in the weeks and months to
>> come.
>>
>> --
>> Darrell (Daz) DeBoer
>> Principal Software Engineer, *Gradleware <http://gradleware.com/>*
>>
>> Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA:
>> http://www.gradlesummit.com
>>
>> On Tue, Apr 15, 2014 at 2:03 AM, Marcin Erdmann <
>> marcin.erdm...@proxerd.pl> wrote:
>>
>>> I was also surprised that the version is evaluated eagerly as soon as
>>> you declare a publication. It means that your options on where you declare
>>> it are limited. It's still usable just a bit less convenient and unexpected
>>> after one get's used to live collections, convention mapping, etc.
>>>
>>>
>>> On Tue, Apr 15, 2014 at 1:42 AM, Andrew Oberstar
>>> <ajobers...@gmail.com>wrote:
>>>
>>>> Hi,
>>>>
>>>> I just added a release plugin to gradle-git (
>>>> https://github.com/ajoberstar/gradle-git), the main functionality of
>>>> which is to infer the project's version based on the tags in a Git
>>>> repository and a little user input in the form of executing a task
>>>> specifying the type of change (the lack of executing one of those tasks is
>>>> the alternative input).
>>>>
>>>> The short version is that, when using this plugin, the project version
>>>> isn't collapsed to a usable value until (at the earliest) the time the task
>>>> graph is ready. It will throw IllegalStateExceptions until that time.
>>>>
>>>> However, the MavenPublish plugin looks for the String value of the
>>>> version right after project evaluation, see the line linked below.
>>>>
>>>>
>>>> https://github.com/gradle/gradle/blob/master/subprojects/maven/src/main/groovy/org/gradle/api/publish/maven/plugins/MavenPublishPlugin.java#L100
>>>>
>>>> Is there any reason it needs to get the collapsed value that "early"
>>>> on? Could it wait until execution of the publish task(s)?
>>>>
>>>> I'd appreciate any insights you have, and I'm willing to help out with
>>>> any changes. Thanks!
>>>>
>>>>
>>>> Andrew Oberstar
>>>>
>>>
>>>
>>
>>
>>
>>
>
--
Darrell (Daz) DeBoer
Principal Software Engineer, *Gradleware <http://gradleware.com>*
Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA:
http://www.gradlesummit.com
