call hierarchy for Pogo properties

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

call hierarchy for Pogo properties

Bertrand Barroux
Hi, 

I work on a fairly large mixed java/groovy application. We have some Pogo which are used by both java and groovy code.

The issue I have is for finding usage of a specific field in a Pogo. With a standard java bean, I would normally check the "call hierarchy (ctrl-alt H)" or "workspace references(ctrl-shft G)" on the getter and setter for the field.

I have the feeling that at some point of time I could do the same on a pogo field in the groovy editor : triggering  "call hierarchy" or "workspace references" on the field name would auto-magically show usage in other groovy and java classes "through" the virtual getters of setters for that field.

Has it all been a dream or does such feature really exist ? if not, what would be the best way to deal with this limitation?

Regards,
Bertrand
Reply | Threaded
Open this post in threaded view
|

Re: call hierarchy for Pogo properties

Andrew Eisenberg
So, you're asking about situations like this:

class MyGroovyClass {
  def prop
}

class MyJavaClass {
  void foo() {
    new MyGroovyClass().getProp();
  }
}

A long time ago, I had implemented something like this so that such
references would be found via search, but this  broke refactoring and
I had to remove it.  The refactoring engine uses a search engine and
assumes that all search results have the same name.

That being said thought, there is a bit of a messy way to add extra
search results to the search view (and this is something I just
thought of now).  It's meant more for finding search results in
non-Java/Groovy artifacts (like xml files).  This does not affect
refactoring and so I might be able adapt it for finding getter and
setter references.

This feature won't be able to make it into 2.5.2 (out at the end of
September), but I can probably work on it for 2.5.3.


On Wed, Sep 21, 2011 at 5:32 AM, Bertrand Barroux <[hidden email]> wrote:

> Hi,
> I work on a fairly large mixed java/groovy application. We have some Pogo
> which are used by both java and groovy code.
> The issue I have is for finding usage of a specific field in a Pogo. With a
> standard java bean, I would normally check the "call hierarchy (ctrl-alt H)"
> or "workspace references(ctrl-shft G)" on the getter and setter for the
> field.
> I have the feeling that at some point of time I could do the same on a pogo
> field in the groovy editor : triggering  "call hierarchy" or "workspace
> references" on the field name would auto-magically show usage in other
> groovy and java classes "through" the virtual getters of setters for that
> field.
> Has it all been a dream or does such feature really exist ? if not, what
> would be the best way to deal with this limitation?
> Regards,
> Bertrand

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: call hierarchy for Pogo properties

Bertrand Barroux
Thanks for the answers,
 
What you are describing is exactly the situation I am asking about (except I have thousands of classes in different projects)

What is bothering me is that I haven't managed so far to find ANY way to find usages of the "prop" field (in your example). 

I tried to artificially add a getProp method in the groovy class (which, as a workaround, is a kind of turn-off). But even that way, I cannot manage to find usages in the java class. "Workspace reference" will give me any string in the java classes matching "getProp",( So if the field is for instance "code", or "name, or "id", this is somehow a show stopper),  while "call hierarchy" will give me nothing.

If I try refactoring (rename) on the method getProp, the preview page won't give me anything. 

Is it really how it is supposed to work or am I missing something ? Not being able to find usage of a field or method in the whole codebase is a really major issue.

Regards,

Bertrand
On Wed, Sep 21, 2011 at 18:29, Andrew Eisenberg <[hidden email]> wrote:
So, you're asking about situations like this:

class MyGroovyClass {
 def prop
}

class MyJavaClass {
 void foo() {
   new MyGroovyClass().getProp();
 }
}

A long time ago, I had implemented something like this so that such
references would be found via search, but this  broke refactoring and
I had to remove it.  The refactoring engine uses a search engine and
assumes that all search results have the same name.

That being said thought, there is a bit of a messy way to add extra
search results to the search view (and this is something I just
thought of now).  It's meant more for finding search results in
non-Java/Groovy artifacts (like xml files).  This does not affect
refactoring and so I might be able adapt it for finding getter and
setter references.

This feature won't be able to make it into 2.5.2 (out at the end of
September), but I can probably work on it for 2.5.3.


On Wed, Sep 21, 2011 at 5:32 AM, Bertrand Barroux <[hidden email]> wrote:
> Hi,
> I work on a fairly large mixed java/groovy application. We have some Pogo
> which are used by both java and groovy code.
> The issue I have is for finding usage of a specific field in a Pogo. With a
> standard java bean, I would normally check the "call hierarchy (ctrl-alt H)"
> or "workspace references(ctrl-shft G)" on the getter and setter for the
> field.
> I have the feeling that at some point of time I could do the same on a pogo
> field in the groovy editor : triggering  "call hierarchy" or "workspace
> references" on the field name would auto-magically show usage in other
> groovy and java classes "through" the virtual getters of setters for that
> field.
> Has it all been a dream or does such feature really exist ? if not, what
> would be the best way to deal with this limitation?
> Regards,
> Bertrand

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

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: call hierarchy for Pogo properties

Bertrand Barroux
Erratum : 
The refactoring applied to the artificially created getter will give me the same results as "workspace references", meaning that if I try to rename a field named something such "name" or "id", I necessary end up corrupting my whole code base .



On Thu, Sep 22, 2011 at 09:53, Bertrand Barroux <[hidden email]> wrote:
Thanks for the answers,
 
What you are describing is exactly the situation I am asking about (except I have thousands of classes in different projects)

What is bothering me is that I haven't managed so far to find ANY way to find usages of the "prop" field (in your example). 

I tried to artificially add a getProp method in the groovy class (which, as a workaround, is a kind of turn-off). But even that way, I cannot manage to find usages in the java class. "Workspace reference" will give me any string in the java classes matching "getProp",( So if the field is for instance "code", or "name, or "id", this is somehow a show stopper),  while "call hierarchy" will give me nothing.

If I try refactoring (rename) on the method getProp, the preview page won't give me anything. 

Is it really how it is supposed to work or am I missing something ? Not being able to find usage of a field or method in the whole codebase is a really major issue.

Regards,

Bertrand

On Wed, Sep 21, 2011 at 18:29, Andrew Eisenberg <[hidden email]> wrote:
So, you're asking about situations like this:

class MyGroovyClass {
 def prop
}

class MyJavaClass {
 void foo() {
   new MyGroovyClass().getProp();
 }
}

A long time ago, I had implemented something like this so that such
references would be found via search, but this  broke refactoring and
I had to remove it.  The refactoring engine uses a search engine and
assumes that all search results have the same name.

That being said thought, there is a bit of a messy way to add extra
search results to the search view (and this is something I just
thought of now).  It's meant more for finding search results in
non-Java/Groovy artifacts (like xml files).  This does not affect
refactoring and so I might be able adapt it for finding getter and
setter references.

This feature won't be able to make it into 2.5.2 (out at the end of
September), but I can probably work on it for 2.5.3.


On Wed, Sep 21, 2011 at 5:32 AM, Bertrand Barroux <[hidden email]> wrote:
> Hi,
> I work on a fairly large mixed java/groovy application. We have some Pogo
> which are used by both java and groovy code.
> The issue I have is for finding usage of a specific field in a Pogo. With a
> standard java bean, I would normally check the "call hierarchy (ctrl-alt H)"
> or "workspace references(ctrl-shft G)" on the getter and setter for the
> field.
> I have the feeling that at some point of time I could do the same on a pogo
> field in the groovy editor : triggering  "call hierarchy" or "workspace
> references" on the field name would auto-magically show usage in other
> groovy and java classes "through" the virtual getters of setters for that
> field.
> Has it all been a dream or does such feature really exist ? if not, what
> would be the best way to deal with this limitation?
> Regards,
> Bertrand

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

   http://xircles.codehaus.org/manage_email




Reply | Threaded
Open this post in threaded view
|

Re: call hierarchy for Pogo properties

Andrew Eisenberg
In reply to this post by Bertrand Barroux
As I said, this is not implemented. I raised the following issues to
track searching and refactoring for synthetic getters and setters:
https://jira.codehaus.org/browse/GRECLIPSE-1204
https://jira.codehaus.org/browse/GRECLIPSE-1205

On Thu, Sep 22, 2011 at 12:53 AM, Bertrand Barroux <[hidden email]> wrote:

> Thanks for the answers,
>
> What you are describing is exactly the situation I am asking about (except I
> have thousands of classes in different projects)
> What is bothering me is that I haven't managed so far to find ANY way to
> find usages of the "prop" field (in your example).
> I tried to artificially add a getProp method in the groovy class (which, as
> a workaround, is a kind of turn-off). But even that way, I cannot manage to
> find usages in the java class. "Workspace reference" will give me any string
> in the java classes matching "getProp",( So if the field is for instance
> "code", or "name, or "id", this is somehow a show stopper),  while "call
> hierarchy" will give me nothing.
> If I try refactoring (rename) on the method getProp, the preview page won't
> give me anything.
> Is it really how it is supposed to work or am I missing something ? Not
> being able to find usage of a field or method in the whole codebase is a
> really major issue.
> Regards,
> Bertrand
> On Wed, Sep 21, 2011 at 18:29, Andrew Eisenberg <[hidden email]> wrote:
>>
>> So, you're asking about situations like this:
>>
>> class MyGroovyClass {
>>  def prop
>> }
>>
>> class MyJavaClass {
>>  void foo() {
>>    new MyGroovyClass().getProp();
>>  }
>> }
>>
>> A long time ago, I had implemented something like this so that such
>> references would be found via search, but this  broke refactoring and
>> I had to remove it.  The refactoring engine uses a search engine and
>> assumes that all search results have the same name.
>>
>> That being said thought, there is a bit of a messy way to add extra
>> search results to the search view (and this is something I just
>> thought of now).  It's meant more for finding search results in
>> non-Java/Groovy artifacts (like xml files).  This does not affect
>> refactoring and so I might be able adapt it for finding getter and
>> setter references.
>>
>> This feature won't be able to make it into 2.5.2 (out at the end of
>> September), but I can probably work on it for 2.5.3.
>>
>>
>> On Wed, Sep 21, 2011 at 5:32 AM, Bertrand Barroux <[hidden email]> wrote:
>> > Hi,
>> > I work on a fairly large mixed java/groovy application. We have some
>> > Pogo
>> > which are used by both java and groovy code.
>> > The issue I have is for finding usage of a specific field in a Pogo.
>> > With a
>> > standard java bean, I would normally check the "call hierarchy (ctrl-alt
>> > H)"
>> > or "workspace references(ctrl-shft G)" on the getter and setter for the
>> > field.
>> > I have the feeling that at some point of time I could do the same on a
>> > pogo
>> > field in the groovy editor : triggering  "call hierarchy" or "workspace
>> > references" on the field name would auto-magically show usage in other
>> > groovy and java classes "through" the virtual getters of setters for
>> > that
>> > field.
>> > Has it all been a dream or does such feature really exist ? if not, what
>> > would be the best way to deal with this limitation?
>> > Regards,
>> > Bertrand
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: call hierarchy for Pogo properties

Andrew Eisenberg
In reply to this post by Bertrand Barroux
Just to be clear here.  Perhaps there is a problem with existing
functionality.  Are you saying that even when you explicitly create a
getName() method, searching and refactoring is either finding too many
or too few references?

And I just tried this.  I do see many "potential matches" for
references to getName().  This is something I'll need to take a look
at too.

On Thu, Sep 22, 2011 at 12:56 AM, Bertrand Barroux <[hidden email]> wrote:

> Erratum :
> The refactoring applied to the artificially created getter will give me the
> same results as "workspace references", meaning that if I try to rename a
> field named something such "name" or "id", I necessary end up corrupting my
> whole code base .
>
>
>
> On Thu, Sep 22, 2011 at 09:53, Bertrand Barroux <[hidden email]> wrote:
>>
>> Thanks for the answers,
>>
>> What you are describing is exactly the situation I am asking about (except
>> I have thousands of classes in different projects)
>> What is bothering me is that I haven't managed so far to find ANY way to
>> find usages of the "prop" field (in your example).
>> I tried to artificially add a getProp method in the groovy class (which,
>> as a workaround, is a kind of turn-off). But even that way, I cannot manage
>> to find usages in the java class. "Workspace reference" will give me any
>> string in the java classes matching "getProp",( So if the field is for
>> instance "code", or "name, or "id", this is somehow a show stopper),  while
>> "call hierarchy" will give me nothing.
>> If I try refactoring (rename) on the method getProp, the preview page
>> won't give me anything.
>> Is it really how it is supposed to work or am I missing something ? Not
>> being able to find usage of a field or method in the whole codebase is a
>> really major issue.
>> Regards,
>> Bertrand
>> On Wed, Sep 21, 2011 at 18:29, Andrew Eisenberg <[hidden email]>
>> wrote:
>>>
>>> So, you're asking about situations like this:
>>>
>>> class MyGroovyClass {
>>>  def prop
>>> }
>>>
>>> class MyJavaClass {
>>>  void foo() {
>>>    new MyGroovyClass().getProp();
>>>  }
>>> }
>>>
>>> A long time ago, I had implemented something like this so that such
>>> references would be found via search, but this  broke refactoring and
>>> I had to remove it.  The refactoring engine uses a search engine and
>>> assumes that all search results have the same name.
>>>
>>> That being said thought, there is a bit of a messy way to add extra
>>> search results to the search view (and this is something I just
>>> thought of now).  It's meant more for finding search results in
>>> non-Java/Groovy artifacts (like xml files).  This does not affect
>>> refactoring and so I might be able adapt it for finding getter and
>>> setter references.
>>>
>>> This feature won't be able to make it into 2.5.2 (out at the end of
>>> September), but I can probably work on it for 2.5.3.
>>>
>>>
>>> On Wed, Sep 21, 2011 at 5:32 AM, Bertrand Barroux <[hidden email]> wrote:
>>> > Hi,
>>> > I work on a fairly large mixed java/groovy application. We have some
>>> > Pogo
>>> > which are used by both java and groovy code.
>>> > The issue I have is for finding usage of a specific field in a Pogo.
>>> > With a
>>> > standard java bean, I would normally check the "call hierarchy
>>> > (ctrl-alt H)"
>>> > or "workspace references(ctrl-shft G)" on the getter and setter for the
>>> > field.
>>> > I have the feeling that at some point of time I could do the same on a
>>> > pogo
>>> > field in the groovy editor : triggering  "call hierarchy" or "workspace
>>> > references" on the field name would auto-magically show usage in other
>>> > groovy and java classes "through" the virtual getters of setters for
>>> > that
>>> > field.
>>> > Has it all been a dream or does such feature really exist ? if not,
>>> > what
>>> > would be the best way to deal with this limitation?
>>> > Regards,
>>> > Bertrand
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>
>

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: call hierarchy for Pogo properties

Andrew Eisenberg
Hi Bertrand,

Apologies for not getting back to you earlier on this, but I did a
little deeper dig into the problem.

Simple answer: edit your Java build path and add all of the jars
(except for sources and groovy-XXX.jar) in
org.codehaus.groovy_1.X.X.qualifier/lib.  Your searches will behave a
lot better that way.

Long answer: It seems like there are some missing binary dependencies
when you add the Groovy Libraries classpath container to your
project's classpath.  These dependencies are for corners of groovy
that are often not used, like ant, junit, and ivy.  (Note that
normally these missing dependencies won't matter as long as the part
of groovy that requires them is never invoked.)

So here is what is happening.  When searching for a common method
name, like getName(), JDT comes across a class that has a method
reference getName().  JDT is trying to figure out if the getName()
searched for is the "same" getName() that was found.  It does this by
looking at the declaring type and the declaring type's hierarchy to
see if somewhere up the hierarchy, there is a match.

However, in the case where there are missing binary dependencies, if
the declaring class is coming from (for example) ant-XXX.jar, it will
not know what the declaring class's hierarchy is and JDT will throw up
its hands and say "I don't know" and it will call this method
reference a "potential match".

So, simply by ensuring that the classpath is complete, JDT will be
able to remove these potential matches.

In the future, we will need to determine if it makes sense to include
all of these jars by default.  Originally, we had not wanted to
pollute the classpath with jars that are not needed, but it does seem
like there are consequences to this decision.

--a

On Thu, Sep 22, 2011 at 9:12 AM, Andrew Eisenberg <[hidden email]> wrote:

> Just to be clear here.  Perhaps there is a problem with existing
> functionality.  Are you saying that even when you explicitly create a
> getName() method, searching and refactoring is either finding too many
> or too few references?
>
> And I just tried this.  I do see many "potential matches" for
> references to getName().  This is something I'll need to take a look
> at too.
>
> On Thu, Sep 22, 2011 at 12:56 AM, Bertrand Barroux <[hidden email]> wrote:
>> Erratum :
>> The refactoring applied to the artificially created getter will give me the
>> same results as "workspace references", meaning that if I try to rename a
>> field named something such "name" or "id", I necessary end up corrupting my
>> whole code base .
>>
>>
>>
>> On Thu, Sep 22, 2011 at 09:53, Bertrand Barroux <[hidden email]> wrote:
>>>
>>> Thanks for the answers,
>>>
>>> What you are describing is exactly the situation I am asking about (except
>>> I have thousands of classes in different projects)
>>> What is bothering me is that I haven't managed so far to find ANY way to
>>> find usages of the "prop" field (in your example).
>>> I tried to artificially add a getProp method in the groovy class (which,
>>> as a workaround, is a kind of turn-off). But even that way, I cannot manage
>>> to find usages in the java class. "Workspace reference" will give me any
>>> string in the java classes matching "getProp",( So if the field is for
>>> instance "code", or "name, or "id", this is somehow a show stopper),  while
>>> "call hierarchy" will give me nothing.
>>> If I try refactoring (rename) on the method getProp, the preview page
>>> won't give me anything.
>>> Is it really how it is supposed to work or am I missing something ? Not
>>> being able to find usage of a field or method in the whole codebase is a
>>> really major issue.
>>> Regards,
>>> Bertrand
>>> On Wed, Sep 21, 2011 at 18:29, Andrew Eisenberg <[hidden email]>
>>> wrote:
>>>>
>>>> So, you're asking about situations like this:
>>>>
>>>> class MyGroovyClass {
>>>>  def prop
>>>> }
>>>>
>>>> class MyJavaClass {
>>>>  void foo() {
>>>>    new MyGroovyClass().getProp();
>>>>  }
>>>> }
>>>>
>>>> A long time ago, I had implemented something like this so that such
>>>> references would be found via search, but this  broke refactoring and
>>>> I had to remove it.  The refactoring engine uses a search engine and
>>>> assumes that all search results have the same name.
>>>>
>>>> That being said thought, there is a bit of a messy way to add extra
>>>> search results to the search view (and this is something I just
>>>> thought of now).  It's meant more for finding search results in
>>>> non-Java/Groovy artifacts (like xml files).  This does not affect
>>>> refactoring and so I might be able adapt it for finding getter and
>>>> setter references.
>>>>
>>>> This feature won't be able to make it into 2.5.2 (out at the end of
>>>> September), but I can probably work on it for 2.5.3.
>>>>
>>>>
>>>> On Wed, Sep 21, 2011 at 5:32 AM, Bertrand Barroux <[hidden email]> wrote:
>>>> > Hi,
>>>> > I work on a fairly large mixed java/groovy application. We have some
>>>> > Pogo
>>>> > which are used by both java and groovy code.
>>>> > The issue I have is for finding usage of a specific field in a Pogo.
>>>> > With a
>>>> > standard java bean, I would normally check the "call hierarchy
>>>> > (ctrl-alt H)"
>>>> > or "workspace references(ctrl-shft G)" on the getter and setter for the
>>>> > field.
>>>> > I have the feeling that at some point of time I could do the same on a
>>>> > pogo
>>>> > field in the groovy editor : triggering  "call hierarchy" or "workspace
>>>> > references" on the field name would auto-magically show usage in other
>>>> > groovy and java classes "through" the virtual getters of setters for
>>>> > that
>>>> > field.
>>>> > Has it all been a dream or does such feature really exist ? if not,
>>>> > what
>>>> > would be the best way to deal with this limitation?
>>>> > Regards,
>>>> > Bertrand
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>    http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>
>>
>>
>

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: call hierarchy for Pogo properties

Bertrand Barroux
Thank you very much for the care you took exploring the issue. I'll try what you suggest and let you know.

For the moment, we are using a rather inelegant but very effective work around. In the Pogo, we mark the field we want to "follow" as private, and we let eclipse compiler do it's job, so we only have to follow compilation errors in the Markers view. Of course, it only work for finding usage in the pure java classes.



On Tue, Sep 27, 2011 at 18:05, Andrew Eisenberg <[hidden email]> wrote:
Hi Bertrand,

Apologies for not getting back to you earlier on this, but I did a
little deeper dig into the problem.

Simple answer: edit your Java build path and add all of the jars
(except for sources and groovy-XXX.jar) in
org.codehaus.groovy_1.X.X.qualifier/lib.  Your searches will behave a
lot better that way.

Long answer: It seems like there are some missing binary dependencies
when you add the Groovy Libraries classpath container to your
project's classpath.  These dependencies are for corners of groovy
that are often not used, like ant, junit, and ivy.  (Note that
normally these missing dependencies won't matter as long as the part
of groovy that requires them is never invoked.)

So here is what is happening.  When searching for a common method
name, like getName(), JDT comes across a class that has a method
reference getName().  JDT is trying to figure out if the getName()
searched for is the "same" getName() that was found.  It does this by
looking at the declaring type and the declaring type's hierarchy to
see if somewhere up the hierarchy, there is a match.

However, in the case where there are missing binary dependencies, if
the declaring class is coming from (for example) ant-XXX.jar, it will
not know what the declaring class's hierarchy is and JDT will throw up
its hands and say "I don't know" and it will call this method
reference a "potential match".

So, simply by ensuring that the classpath is complete, JDT will be
able to remove these potential matches.

In the future, we will need to determine if it makes sense to include
all of these jars by default.  Originally, we had not wanted to
pollute the classpath with jars that are not needed, but it does seem
like there are consequences to this decision.

--a

On Thu, Sep 22, 2011 at 9:12 AM, Andrew Eisenberg <[hidden email]> wrote:
> Just to be clear here.  Perhaps there is a problem with existing
> functionality.  Are you saying that even when you explicitly create a
> getName() method, searching and refactoring is either finding too many
> or too few references?
>
> And I just tried this.  I do see many "potential matches" for
> references to getName().  This is something I'll need to take a look
> at too.
>
> On Thu, Sep 22, 2011 at 12:56 AM, Bertrand Barroux <[hidden email]> wrote:
>> Erratum :
>> The refactoring applied to the artificially created getter will give me the
>> same results as "workspace references", meaning that if I try to rename a
>> field named something such "name" or "id", I necessary end up corrupting my
>> whole code base .
>>
>>
>>
>> On Thu, Sep 22, 2011 at 09:53, Bertrand Barroux <[hidden email]> wrote:
>>>
>>> Thanks for the answers,
>>>
>>> What you are describing is exactly the situation I am asking about (except
>>> I have thousands of classes in different projects)
>>> What is bothering me is that I haven't managed so far to find ANY way to
>>> find usages of the "prop" field (in your example).
>>> I tried to artificially add a getProp method in the groovy class (which,
>>> as a workaround, is a kind of turn-off). But even that way, I cannot manage
>>> to find usages in the java class. "Workspace reference" will give me any
>>> string in the java classes matching "getProp",( So if the field is for
>>> instance "code", or "name, or "id", this is somehow a show stopper),  while
>>> "call hierarchy" will give me nothing.
>>> If I try refactoring (rename) on the method getProp, the preview page
>>> won't give me anything.
>>> Is it really how it is supposed to work or am I missing something ? Not
>>> being able to find usage of a field or method in the whole codebase is a
>>> really major issue.
>>> Regards,
>>> Bertrand
>>> On Wed, Sep 21, 2011 at 18:29, Andrew Eisenberg <[hidden email]>
>>> wrote:
>>>>
>>>> So, you're asking about situations like this:
>>>>
>>>> class MyGroovyClass {
>>>>  def prop
>>>> }
>>>>
>>>> class MyJavaClass {
>>>>  void foo() {
>>>>    new MyGroovyClass().getProp();
>>>>  }
>>>> }
>>>>
>>>> A long time ago, I had implemented something like this so that such
>>>> references would be found via search, but this  broke refactoring and
>>>> I had to remove it.  The refactoring engine uses a search engine and
>>>> assumes that all search results have the same name.
>>>>
>>>> That being said thought, there is a bit of a messy way to add extra
>>>> search results to the search view (and this is something I just
>>>> thought of now).  It's meant more for finding search results in
>>>> non-Java/Groovy artifacts (like xml files).  This does not affect
>>>> refactoring and so I might be able adapt it for finding getter and
>>>> setter references.
>>>>
>>>> This feature won't be able to make it into 2.5.2 (out at the end of
>>>> September), but I can probably work on it for 2.5.3.
>>>>
>>>>
>>>> On Wed, Sep 21, 2011 at 5:32 AM, Bertrand Barroux <[hidden email]> wrote:
>>>> > Hi,
>>>> > I work on a fairly large mixed java/groovy application. We have some
>>>> > Pogo
>>>> > which are used by both java and groovy code.
>>>> > The issue I have is for finding usage of a specific field in a Pogo.
>>>> > With a
>>>> > standard java bean, I would normally check the "call hierarchy
>>>> > (ctrl-alt H)"
>>>> > or "workspace references(ctrl-shft G)" on the getter and setter for the
>>>> > field.
>>>> > I have the feeling that at some point of time I could do the same on a
>>>> > pogo
>>>> > field in the groovy editor : triggering  "call hierarchy" or "workspace
>>>> > references" on the field name would auto-magically show usage in other
>>>> > groovy and java classes "through" the virtual getters of setters for
>>>> > that
>>>> > field.
>>>> > Has it all been a dream or does such feature really exist ? if not,
>>>> > what
>>>> > would be the best way to deal with this limitation?
>>>> > Regards,
>>>> > Bertrand
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>    http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>
>>
>>
>

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

   http://xircles.codehaus.org/manage_email