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
>>>
>>
>>
>
>
>
>
