On 04/02/2013, at 5:56 PM, Szczepan Faber <[email protected]> wrote:
> Coersion of file for a task is pretty cool, yet the workaround is > fairly cheap. The cost is higher than you might think. 1. It hurts docs because you are forced to read the prose to understand the types 2. When there's a type coercion failure, the error message is rather vague 3. It's type specific, and there are nuances to dealing with different types In short, even if solving this does nothing about the problems with convention mapping it's still worth it. > I think that the biggest gain from this story might > actually be kick starting a tidy-up in the convention mapping > business. So there you go, I think that that it's finally time to > start dealing with convention mappings :) This would be my preference as well. > Backwards compatibility for convention mappings is pretty tricky. On > one hand, this feature was advertised as internal in past so > theoretically, we can change it. However, the change might affect > users that don't use the CMs at all, some users might just happen to > consume some 3rd party plugin that uses CMs. I guess that's true for > any kind of breaking change. Yet, I think that there's fair amount of > 3rd party plugins that were inspired on Gradle codebase and hence use > CMs. I'd say that we should have generous migration plan for any > changes in CMs, ideally, we're just fully compatible :) If we introduce a type coercion layer into our MOP that supports deferred values, we might be able to make the existing convention mapping API simply delegate to this. With the impl I'm planning this will be possible I think. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
