RFC: Patch to _GrailsTest.

[Luke Daley]

Hi all,

http://github.com/alkemist/grails/commit/5ff20daa329cf74cd344400d1d9efc3bfa748118

This is a reasonably significant change, but is backwards compatible.
It may break some testing plugins though, looking into this.

I strongly think this is better. Contrast what it means for the spock
plugin…

Pre:
http://pastie.textmate.org/671597

Post:
http://pastie.textmate.org/671588

Before the patch I am forced to create new phases in order to
configure what I need to. So this means two integration test style
startup/shutdowns, and two functional test startup/shutdowns.

There are a bunch of other things that I want to improve in this area,
but they all hinge on this being the way forward.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Richard Vowles]

That looks like it would work a lot more nicely for Easyb as well, and probably for the Selenium plugin.

On Wed, Oct 28, 2009 at 11:22 AM, Luke Daley <ld@...> wrote:

Hi all,

http://github.com/alkemist/grails/commit/5ff20daa329cf74cd344400d1d9efc3bfa748118

This is a reasonably significant change, but is backwards compatible.
It may break some testing plugins though, looking into this.

I strongly think this is better. Contrast what it means for the spock
plugin…

--
---
Richard Vowles,
Grails, Groovy, Java
Consistency is the last refuge of the unimaginative - Oscar Wilde
ph: [phone], linkedin, skype:rvowles
get 2Gb shared disk space in the cloud - Dropbox, its incredibly useful! - http://tinyurl.com/cmcceh
podcast: http://www.illegalargument.com

[Luke Daley]

I have inspected Gustav's version of _GrailsTest in the easyb plugin.  
It's a slightly different approach which is not quite as flexible.

This, plus some coming improvements, will make it possible for easyb  
tests to be run via grails test-app.

If this patch gets accepted, I'll work with Gustav (or whoever is  
currently doing the easyb plugin) to make it work.

Already checked out Rob's selenium plugin, it's compatible with this  
patch.

On 28/10/2009, at 8:31 AM, Richard Vowles wrote:

> That looks like it would work a lot more nicely for Easyb as well,  
> and probably for the Selenium plugin.
>
> On Wed, Oct 28, 2009 at 11:22 AM, Luke Daley <ld@...> wrote:
> Hi all,
>
> http://github.com/alkemist/grails/commit/5ff20daa329cf74cd344400d1d9efc3bfa748118
>
> This is a reasonably significant change, but is backwards compatible.
> It may break some testing plugins though, looking into this.
>
> I strongly think this is better. Contrast what it means for the spock
> plugin…
>
> --
> ---
> Richard Vowles,
> Grails, Groovy, Java
> Consistency is the last refuge of the unimaginative - Oscar Wilde
> ph: [phone], linkedin, skype:rvowles
> get 2Gb shared disk space in the cloud - Dropbox, its incredibly  
> useful! - http://tinyurl.com/cmcceh
> podcast: http://www.illegalargument.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Richard Vowles]

Gustav did the patch to make the script run (easybtest), but I am currently working on the plugin, so if the patch is accepted, I am happy to do  the changes necessary to get it working...

On Wed, Oct 28, 2009 at 11:38 AM, Luke Daley <ld@...> wrote:

I have inspected Gustav's version of _GrailsTest in the easyb plugin. It's a slightly different approach which is not quite as flexible.

This, plus some coming improvements, will make it possible for easyb tests to be run via grails test-app.

If this patch gets accepted, I'll work with Gustav (or whoever is currently doing the easyb plugin) to make it work.

Already checked out Rob's selenium plugin, it's compatible with this patch.

--
---
Richard Vowles,
Grails, Groovy, Java
Consistency is the last refuge of the unimaginative - Oscar Wilde
ph: [phone], linkedin, skype:rvowles
get 2Gb shared disk space in the cloud - Dropbox, its incredibly useful! - http://tinyurl.com/cmcceh
podcast: http://www.illegalargument.com

[Peter Ledbrook]

> http://github.com/alkemist/grails/commit/5ff20daa329cf74cd344400d1d9efc3bfa748118
>
> This is a reasonably significant change, but is backwards compatible.
> It may break some testing plugins though, looking into this.

It seems to be tricky to pull all your changes except this one, so
shall we hold off on the pull until you're ready with the changes?

Cheers,

Peter

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Luke Daley]

On 28/10/2009, at 4:39 PM, Peter Ledbrook wrote:

>> http://github.com/alkemist/grails/commit/5ff20daa329cf74cd344400d1d9efc3bfa748118
>>
>> This is a reasonably significant change, but is backwards compatible.
>> It may break some testing plugins though, looking into this.
>
> It seems to be tricky to pull all your changes except this one, so
> shall we hold off on the pull until you're ready with the changes?

Are you getting conflicts, or just unsure of how to do this with Git?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Peter Ledbrook]

>> It seems to be tricky to pull all your changes except this one, so
>> shall we hold off on the pull until you're ready with the changes?
>
> Are you getting conflicts, or just unsure of how to do this with Git?

Not conflicts. I just can't see a way to pull all your changes up to
but *not* including the latest one. You can do cherry-picking, but I
believe that has implications that mean it's not a great solution,
particularly if we want to merge your fork again later.

Peter

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Luke Daley]

On 28/10/2009, at 11:06 PM, Peter Ledbrook wrote:

>>> It seems to be tricky to pull all your changes except this one, so
>>> shall we hold off on the pull until you're ready with the changes?
>>
>> Are you getting conflicts, or just unsure of how to do this with Git?
>
> Not conflicts. I just can't see a way to pull all your changes up to
> but *not* including the latest one. You can do cherry-picking, but I
> believe that has implications that mean it's not a great solution,
> particularly if we want to merge your fork again later.

This is beyond my git knowledge.

I know you could fetch my changes, then use merge to merge them into  
your branch, but don't know what the implications of that long term are.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Peter Ledbrook]

> This is beyond my git knowledge.
>
> I know you could fetch my changes, then use merge to merge them into your
> branch, but don't know what the implications of that long term are.

Yes, that's the standard approach, but it will merge *all* the changes
you've pushed to the target branch. So if you want to push more
changes, it probably makes sense to hold off the merge until you're
done (I got the impression your most recent commit was the start of a
piece of work rather than a standalone one).

Cheers,

Peter

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Luke Daley]

On 28/10/2009, at 11:22 PM, Peter Ledbrook wrote:

>> This is beyond my git knowledge.
>>
>> I know you could fetch my changes, then use merge to merge them  
>> into your
>> branch, but don't know what the implications of that long term are.
>
> Yes, that's the standard approach, but it will merge *all* the changes
> you've pushed to the target branch. So if you want to push more
> changes, it probably makes sense to hold off the merge until you're
> done (I got the impression your most recent commit was the start of a
> piece of work rather than a standalone one).

I am now pursuing this just to understand Git better. I can't seem to  
find a way to just “merge up to a point”. I'll keep looking into it.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[joel.reed]

On 10/28/2009 08:34 PM, Luke Daley wrote:

>
> On 28/10/2009, at 11:22 PM, Peter Ledbrook wrote:
>
>>> This is beyond my git knowledge.
>>>
>>> I know you could fetch my changes, then use merge to merge them into
>>> your
>>> branch, but don't know what the implications of that long term are.
>>
>> Yes, that's the standard approach, but it will merge *all* the changes
>> you've pushed to the target branch. So if you want to push more
>> changes, it probably makes sense to hold off the merge until you're
>> done (I got the impression your most recent commit was the start of a
>> piece of work rather than a standalone one).
>
> I am now pursuing this just to understand Git better. I can't seem to
> find a way to just “merge up to a point”. I'll keep looking into it.

I think you want to

1) git fetch the remote repo
2) git checkout the revision you wish to merge up to (creating a new
branch with -b)
3) git merge the newly created branch into your working branch destination.

Maybe there's an easier way, but I don't know it.

jr

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-3]

On Thu, Oct 29, 2009 at 1:34 AM, Luke Daley <ld@...> wrote:

>
> On 28/10/2009, at 11:22 PM, Peter Ledbrook wrote:
>
>>> This is beyond my git knowledge.
>>>
>>> I know you could fetch my changes, then use merge to merge them into your
>>> branch, but don't know what the implications of that long term are.
>>
>> Yes, that's the standard approach, but it will merge *all* the changes
>> you've pushed to the target branch. So if you want to push more
>> changes, it probably makes sense to hold off the merge until you're
>> done (I got the impression your most recent commit was the start of a
>> piece of work rather than a standalone one).
>
> I am now pursuing this just to understand Git better. I can't seem to find a
> way to just “merge up to a point”. I'll keep looking into it.

What is the status of your changes Luke? Are they ready to be merged.

BTW This change is not good:

http://github.com/alkemist/grails/commit/a4539073118e8d7214ee93479bf85ca7f2ef5c43

As it means the integration test running cycle will blow up if there
is no 'persistenceInterceptor' bean defined

Regards,
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>



--
Graeme Rocher
Head of Grails Development
SpringSource - Weapons for the War on Java Complexity
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Luke Daley]

On 29/10/2009, at 6:47 PM, Graeme Rocher wrote:

> What is the status of your changes Luke? Are they ready to be merged.

More being worked on atm.

> BTW This change is not good:
>
> http://github.com/alkemist/grails/commit/a4539073118e8d7214ee93479bf85ca7f2ef5c43
>
> As it means the integration test running cycle will blow up if there
> is no 'persistenceInterceptor' bean defined

Ok, will revert.

Where would the other PersistenceContextInterceptor's come from?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-3]

On Thu, Oct 29, 2009 at 10:04 AM, Luke Daley <ld@...> wrote:

>
> On 29/10/2009, at 6:47 PM, Graeme Rocher wrote:
>
>> What is the status of your changes Luke? Are they ready to be merged.
>
> More being worked on atm.
>
>> BTW This change is not good:
>>
>>
>> http://github.com/alkemist/grails/commit/a4539073118e8d7214ee93479bf85ca7f2ef5c43
>>
>> As it means the integration test running cycle will blow up if there
>> is no 'persistenceInterceptor' bean defined
>
> Ok, will revert.
>
> Where would the other PersistenceContextInterceptor's come from?

Well there is a hibernate one, but when hibernate is not installed its
not there. But there may be others for other persistence providers

Cheers
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>



--
Graeme Rocher
Head of Grails Development
SpringSource - Weapons for the War on Java Complexity
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Luke Daley]

On 29/10/2009, at 7:07 PM, Graeme Rocher wrote:

> On Thu, Oct 29, 2009 at 10:04 AM, Luke Daley <ld@...> wrote:
>>
>> On 29/10/2009, at 6:47 PM, Graeme Rocher wrote:
>>
>>> What is the status of your changes Luke? Are they ready to be  
>>> merged.
>>
>> More being worked on atm.
>>
>>> BTW This change is not good:
>>>
>>>
>>> http://github.com/alkemist/grails/commit/a4539073118e8d7214ee93479bf85ca7f2ef5c43
>>>
>>> As it means the integration test running cycle will blow up if there
>>> is no 'persistenceInterceptor' bean defined
>>
>> Ok, will revert.
>>
>> Where would the other PersistenceContextInterceptor's come from?
>
> Well there is a hibernate one, but when hibernate is not installed its
> not there. But there may be others for other persistence providers

Right, so it's not that they will be named differently, it's that that  
code has the potential to throw a NoSuchBeanDefinitionException.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-3]

On Thu, Oct 29, 2009 at 10:29 AM, Luke Daley <ld@...> wrote:

>
> On 29/10/2009, at 7:07 PM, Graeme Rocher wrote:
>
>> On Thu, Oct 29, 2009 at 10:04 AM, Luke Daley <ld@...> wrote:
>>>
>>> On 29/10/2009, at 6:47 PM, Graeme Rocher wrote:
>>>
>>>> What is the status of your changes Luke? Are they ready to be merged.
>>>
>>> More being worked on atm.
>>>
>>>> BTW This change is not good:
>>>>
>>>>
>>>>
>>>> http://github.com/alkemist/grails/commit/a4539073118e8d7214ee93479bf85ca7f2ef5c43
>>>>
>>>> As it means the integration test running cycle will blow up if there
>>>> is no 'persistenceInterceptor' bean defined
>>>
>>> Ok, will revert.
>>>
>>> Where would the other PersistenceContextInterceptor's come from?
>>
>> Well there is a hibernate one, but when hibernate is not installed its
>> not there. But there may be others for other persistence providers
>
> Right, so it's not that they will be named differently, it's that that code
> has the potential to throw a NoSuchBeanDefinitionException.

Correct.

>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>



--
Graeme Rocher
Head of Grails Development
SpringSource - Weapons for the War on Java Complexity
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Luke Daley]

On 29/10/2009, at 8:30 PM, Graeme Rocher wrote:

>>>>> BTW This change is not good:
>>>>>
>>>>>
>>>>>
>>>>> http://github.com/alkemist/grails/commit/a4539073118e8d7214ee93479bf85ca7f2ef5c43
>>>>>
>>>>> As it means the integration test running cycle will blow up if  
>>>>> there
>>>>> is no 'persistenceInterceptor' bean defined

http://github.com/alkemist/grails/commit/9382207528497975b4732909ff21222dbc7330a6

Is that acceptable?


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-3]

On Thu, Oct 29, 2009 at 12:52 PM, Luke Daley <ld@...> wrote:

>
> On 29/10/2009, at 8:30 PM, Graeme Rocher wrote:
>
>>>>>> BTW This change is not good:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://github.com/alkemist/grails/commit/a4539073118e8d7214ee93479bf85ca7f2ef5c43
>>>>>>
>>>>>> As it means the integration test running cycle will blow up if there
>>>>>> is no 'persistenceInterceptor' bean defined
>
> http://github.com/alkemist/grails/commit/9382207528497975b4732909ff21222dbc7330a6
>
> Is that acceptable?

It solves the lack of a bean being there problem (although it would be
better to use a containsBean check), however there may still be a
problem if you have multiple persistence plugins installed that
provide different interceptors (for example if you are using a
combination of Hibernate and JCR/couchdb/etc.)

Cheers
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>



--
Graeme Rocher
Head of Grails Development
SpringSource - Weapons for the War on Java Complexity
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email