> I would vote for figuring out a graceful way to move to extensions instead > of conventions. I.e. deprecate old behavior instead of breaking it. :) > > If we were post 1.0 I'd be more inclined t agree, but given that we aren't > and it's a very quick change for users to make, and is on the edges anyway, > I'd prefer not carrying the extra baggage.
Fair enough. BTW. I'm nearly always in the 'compatibility' camp as it pushes us to design incrementally and keeps users happy. To me, the version number is just a number (though 1.0 has a PR angle and it's usually wiser to start versioning from at least 0.9 :-) > > @Luke, can you elaborate on on your concern regarding dsl reference? > > We have a nice mechanism for describing what gets "mixed in" to core types, > but this breaks down for extensions. > Where do I document the “application” property that is added to Project? How > do I get the docs for the actual extension into the DSL reference (besides > using javadoc/groovydoc). The structure of this stuff is different to using > convention mixins. It's a great point. So far I did that using javadoc/groovydoc. For example: http://gradle.org/releases/latest/docs/dsl/org.gradle.plugins.ide.eclipse.model.EclipseProject.html As you say it would be very nice to somehow tidy up/centralize information about extensions in the DSL reference. > I think we are going to have to do some work on the dsl docs generation to > accommodate this change. I'm happy to do that, but it won't make m4. > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > -- Szczepan Faber Principal engineer@gradleware Lead@mockito --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
