On Oct 27, 2010, at 5:50 AM, Luke Daley wrote:
>
> On 27/10/2010, at 8:40 PM, Peter Ledbrook wrote:
>
>> Switching to the dev list. Further comments at the bottom.
>>
>>> I have a proposal for a change to BuildConfig-defined plugins syntax and behavior for in-place plugins for development and normal mode for releases.
>>>
>>> Here's a sample BuildConfig:
>>> grails {
>>> plugin.location {
>>> // auditTrail = '../audit-trail' // You need to uncomment this to use in-place plugins
>>> }
>>> project.dependency.resolution = {
>>> ...
>>> plugins {
>>> runtime ':audit-trail:1.2' { excludes:'foo' } // You need to comment this out to use in-place plugins
>>> }
>>> }
>>>
>>> I would like to see the following instead:
>>> grails.project.dependency.resolution = {
>>> ...
>>> plugins {
>>> runtime ':audit-trail:1.2' { excludes: 'foo' /*, location:'../audit-trail'*/ } // uncomment the location clause to enable in-place plugins.
>>> }
>>> }
>>>
>>> My proposed behavior would be as follows:
>>> 1 grails.plugin.location is no longer needed to use in-place plugins.
>>> 2 If location is present, then the version in the initial string is ignored.
>
> This doesn't seem right. If it's not used I don't want to have to put it there.
Perhaps it was poorly worded. I'll try again, but it seems like this list prefers text-only so it might be rough.
We have
grails.plugin.location.auditTrail = '../audit-trail'
which would no longer be needed because it will be moved to grails.project.dependency.resolution.
Then there is the
grails.project.dependency.resolution = {
plugins {
runtime ':audit-trail:1.2' {
excludes: 'foo'
location:'../audit-trail'
} } }
structure which we already have, which would gain the "location" clause. Hopefully the excludes clause could then be applied to the in-place plugin as well.
>
>>> 3 The excludes clause works no matter what, which would be inconsistent with the existing behavior and is, in my opinion, broken.
>
> What is being excluded here? plugin dependencies or jar dependencies?
No change there with what is already excluded, except that it also (hopefully) does it for in-place plugins. Plugins and jars both would make me happy, but that's not the proposed change.
>> I quite like this idea. It would certainly allow for a bit more
>> consistency. I'm not sure how easy it would be to get working in the
>> case where an in-place plugin has in-place plugins of its own,
>
> No reason it couldn't work with nested in place plugins.
>
> This seems like a good idea to me.
Thanks!
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Locked
