Home » Language IDEs » Java Development Tools (JDT) » M9: Refactoring / change signature
| M9: Refactoring / change signature [message #158773] |
Fri, 14 May 2004 18:44  |
Eclipse User |
|
|
|
Originally posted by: rndzank.comcast.net.not_this.net
For some reason, this refactoring doesn't work for me (just tried it in I0514) -
whatever change I make, after OK, nothing happens. Also, if I open preview,
there are no changes shown.
Is this unfinished feature? Bad configuration?
thx
r.
|
|
|
| Re: M9: Refactoring / change signature [message #158808 is a reply to message #158773] |
Fri, 14 May 2004 21:26  |
| Eclipse User |
|
|
|
Originally posted by: akiezun.to.reply.remove.whats.unneeded.mit.edu
Richard Nemec wrote:
> For some reason, this refactoring doesn't work for me (just tried it in
> I0514) - whatever change I make, after OK, nothing happens. Also, if I
> open preview, there are no changes shown.
> Is this unfinished feature? Bad configuration?
>
> thx
>
> r.
works for me in m7.
show us your test case.
a.
|
|
|
| Re: M9: Refactoring / change signature [message #158830 is a reply to message #158808] |
Fri, 14 May 2004 22:39 |
| Eclipse User |
|
|
|
Originally posted by: rndzank.comcast.net.not_this.net
Strange, I created a small example, and everything works.
The problems I had were in a project and workspace created and copied from
previous builds (M8, several Ixxx and Nxxx builds have let their
footprints in the workspace as well, I'm sure).
Will try new workspace, because the existing (after deleting
..metadata dir) complains when importing the project - something
about "Attempted to beginRule: R/, does not match outer scope rule:
P:/....".
No clue...
r.
Adam Kiezun wrote:
> Richard Nemec wrote:
>
>> For some reason, this refactoring doesn't work for me (just tried it
>> in I0514) - whatever change I make, after OK, nothing happens. Also,
>> if I open preview, there are no changes shown.
>> Is this unfinished feature? Bad configuration?
>>
>> thx
>>
>> r.
>
>
> works for me in m7.
> show us your test case.
> a.
>
|
|
|
| Re: M9: Refactoring / change signature [message #158838 is a reply to message #158830] |
Fri, 14 May 2004 22:55 |
| Eclipse User |
|
|
|
Originally posted by: akiezun.to.reply.remove.whats.unneeded.mit.edu
Richard Nemec wrote:
> Strange, I created a small example, and everything works.
>
> The problems I had were in a project and workspace created and copied from
> previous builds (M8, several Ixxx and Nxxx builds have let their
> footprints in the workspace as well, I'm sure).
>
> Will try new workspace, because the existing (after deleting
> .metadata dir) complains when importing the project - something
> about "Attempted to beginRule: R/, does not match outer scope rule:
> P:/....".
>
> No clue...
refactorings like 'change sig' use java search. if search returns no
refs to a method, the refactoring can do nothing.
you can use that test to verify if it's refactoring that's broken or
something in lower layers.
a.
|
|
|
| Re: M9: Refactoring / change signature [message #158870 is a reply to message #158838] |
Sat, 15 May 2004 04:24 |
| Eclipse User |
|
|
|
Originally posted by: rndzank.comcast.net.not_this.net
Adam, you are right. The project has basic problems with Java searching.
The project is big one and quite messy.
Is there a chance to get a guess what could be the critical point there?
Thanks
r.
Adam Kiezun wrote:
> Richard Nemec wrote:
>
>> Strange, I created a small example, and everything works.
>>
>> The problems I had were in a project and workspace created and copied
>> from
>> previous builds (M8, several Ixxx and Nxxx builds have let their
>> footprints in the workspace as well, I'm sure).
>>
>> Will try new workspace, because the existing (after deleting
>> .metadata dir) complains when importing the project - something
>> about "Attempted to beginRule: R/, does not match outer scope rule:
>> P:/....".
>>
>> No clue...
>
>
> refactorings like 'change sig' use java search. if search returns no
> refs to a method, the refactoring can do nothing.
> you can use that test to verify if it's refactoring that's broken or
> something in lower layers.
>
> a.
>
|
|
|
| Re: M9: Refactoring / change signature [message #158924 is a reply to message #158870] |
Mon, 17 May 2004 02:39 |
| Eclipse User |
|
|
|
Originally posted by: rndzank.comcast.net.not_this.net
Please, is there anyone with any suggestion?
So far I found that no matter how I configure and compile the project,
some packages can be searched, and some not (and consequence is that
some can be refactored, some not).
What I tried and didn't help:
- remove built class files and rebuild
- refresh the project
- clean and build
- remove index files from jdt.core
- edit the .classpath file and change order of source directories
Little about the project structure:
- several source dirs
- several include/exclude patterns
Thanks
r.
Richard Nemec wrote:
> Adam, you are right. The project has basic problems with Java searching.
> The project is big one and quite messy.
>
> Is there a chance to get a guess what could be the critical point there?
> Thanks
>
> r.
>
> Adam Kiezun wrote:
>
>> Richard Nemec wrote:
>>
>>> Strange, I created a small example, and everything works.
>>>
>>> The problems I had were in a project and workspace created and copied
>>> from
>>> previous builds (M8, several Ixxx and Nxxx builds have let their
>>> footprints in the workspace as well, I'm sure).
>>>
>>> Will try new workspace, because the existing (after deleting
>>> .metadata dir) complains when importing the project - something
>>> about "Attempted to beginRule: R/, does not match outer scope rule:
>>> P:/....".
>>>
>>> No clue...
>>
>>
>>
>> refactorings like 'change sig' use java search. if search returns no
>> refs to a method, the refactoring can do nothing.
>> you can use that test to verify if it's refactoring that's broken or
>> something in lower layers.
>>
>> a.
>>
|
|
|
| Re: M9: Refactoring / change signature [message #158956 is a reply to message #158924] |
Mon, 17 May 2004 09:39 |
 Jerome Lanneluc
Messages: 572
Registered: July 2009 |
Senior Member |
|
|
It looks like you ran into
https://bugs.eclipse.org/bugs/show_bug.cgi?id=62267.
I don't know any workaround at this time. Sorry.
Jerome
"Richard Nemec" <rndzank.comcast.net@not_this.net> wrote in message
news:c89880$o0i$1@eclipse.org...
> Please, is there anyone with any suggestion?
>
> So far I found that no matter how I configure and compile the project,
> some packages can be searched, and some not (and consequence is that
> some can be refactored, some not).
>
> What I tried and didn't help:
> - remove built class files and rebuild
> - refresh the project
> - clean and build
> - remove index files from jdt.core
> - edit the .classpath file and change order of source directories
>
> Little about the project structure:
> - several source dirs
> - several include/exclude patterns
>
> Thanks
>
> r.
>
> Richard Nemec wrote:
>
> > Adam, you are right. The project has basic problems with Java searching.
> > The project is big one and quite messy.
> >
> > Is there a chance to get a guess what could be the critical point there?
> > Thanks
> >
> > r.
> >
> > Adam Kiezun wrote:
> >
> >> Richard Nemec wrote:
> >>
> >>> Strange, I created a small example, and everything works.
> >>>
> >>> The problems I had were in a project and workspace created and copied
> >>> from
> >>> previous builds (M8, several Ixxx and Nxxx builds have let their
> >>> footprints in the workspace as well, I'm sure).
> >>>
> >>> Will try new workspace, because the existing (after deleting
> >>> .metadata dir) complains when importing the project - something
> >>> about "Attempted to beginRule: R/, does not match outer scope rule:
> >>> P:/....".
> >>>
> >>> No clue...
> >>
> >>
> >>
> >> refactorings like 'change sig' use java search. if search returns no
> >> refs to a method, the refactoring can do nothing.
> >> you can use that test to verify if it's refactoring that's broken or
> >> something in lower layers.
> >>
> >> a.
> >>
|
|
|
| Re: M9: Refactoring / change signature [message #158964 is a reply to message #158956] |
Mon, 17 May 2004 09:56 |
| Eclipse User |
|
|
|
Originally posted by: rndzank.comcast.net.not_this.net
Wouldn't that bug cause consistent no-search/no-refactoring
across the whole workspace?
In my case, I can search/refactor some packages but cannot
others.
Jerome Lanneluc wrote:
> It looks like you ran into
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=62267.
> I don't know any workaround at this time. Sorry.
>
> Jerome
>
> "Richard Nemec" <rndzank.comcast.net@not_this.net> wrote in message
> news:c89880$o0i$1@eclipse.org...
>
>>Please, is there anyone with any suggestion?
>>
>>So far I found that no matter how I configure and compile the project,
>>some packages can be searched, and some not (and consequence is that
>>some can be refactored, some not).
>>
>>What I tried and didn't help:
>>- remove built class files and rebuild
>>- refresh the project
>>- clean and build
>>- remove index files from jdt.core
>>- edit the .classpath file and change order of source directories
>>
>>Little about the project structure:
>>- several source dirs
>>- several include/exclude patterns
>>
>>Thanks
>>
>>r.
>>
>>Richard Nemec wrote:
>>
>>
>>>Adam, you are right. The project has basic problems with Java searching.
>>>The project is big one and quite messy.
>>>
>>>Is there a chance to get a guess what could be the critical point there?
>>>Thanks
>>>
>>>r.
>>>
>>>Adam Kiezun wrote:
>>>
>>>
>>>>Richard Nemec wrote:
>>>>
>>>>
>>>>>Strange, I created a small example, and everything works.
>>>>>
>>>>>The problems I had were in a project and workspace created and copied
>>>>>from
>>>>>previous builds (M8, several Ixxx and Nxxx builds have let their
>>>>>footprints in the workspace as well, I'm sure).
>>>>>
>>>>>Will try new workspace, because the existing (after deleting
>>>>>.metadata dir) complains when importing the project - something
>>>>>about "Attempted to beginRule: R/, does not match outer scope rule:
>>>>>P:/....".
>>>>>
>>>>>No clue...
>>>>
>>>>
>>>>
>>>>refactorings like 'change sig' use java search. if search returns no
>>>>refs to a method, the refactoring can do nothing.
>>>>you can use that test to verify if it's refactoring that's broken or
>>>>something in lower layers.
>>>>
>>>>a.
>>>>
>
>
>
|
|
|
| Re: M9: Refactoring / change signature [message #159021 is a reply to message #158964] |
Mon, 17 May 2004 10:57 |
Jerome Lanneluc
Messages: 572
Registered: July 2009 |
Senior Member |
|
|
If you have steps to reproduce, please enter a bug report and I will
investigate.
"Richard Nemec" <rndzank.comcast.net@not_this.net> wrote in message
news:c8a1ra$hqt$1@eclipse.org...
> Wouldn't that bug cause consistent no-search/no-refactoring
> across the whole workspace?
>
> In my case, I can search/refactor some packages but cannot
> others.
>
> Jerome Lanneluc wrote:
>
> > It looks like you ran into
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=62267.
> > I don't know any workaround at this time. Sorry.
> >
> > Jerome
> >
> > "Richard Nemec" <rndzank.comcast.net@not_this.net> wrote in message
> > news:c89880$o0i$1@eclipse.org...
> >
> >>Please, is there anyone with any suggestion?
> >>
> >>So far I found that no matter how I configure and compile the project,
> >>some packages can be searched, and some not (and consequence is that
> >>some can be refactored, some not).
> >>
> >>What I tried and didn't help:
> >>- remove built class files and rebuild
> >>- refresh the project
> >>- clean and build
> >>- remove index files from jdt.core
> >>- edit the .classpath file and change order of source directories
> >>
> >>Little about the project structure:
> >>- several source dirs
> >>- several include/exclude patterns
> >>
> >>Thanks
> >>
> >>r.
> >>
> >>Richard Nemec wrote:
> >>
> >>
> >>>Adam, you are right. The project has basic problems with Java
searching.
> >>>The project is big one and quite messy.
> >>>
> >>>Is there a chance to get a guess what could be the critical point
there?
> >>>Thanks
> >>>
> >>>r.
> >>>
> >>>Adam Kiezun wrote:
> >>>
> >>>
> >>>>Richard Nemec wrote:
> >>>>
> >>>>
> >>>>>Strange, I created a small example, and everything works.
> >>>>>
> >>>>>The problems I had were in a project and workspace created and copied
> >>>>>from
> >>>>>previous builds (M8, several Ixxx and Nxxx builds have let their
> >>>>>footprints in the workspace as well, I'm sure).
> >>>>>
> >>>>>Will try new workspace, because the existing (after deleting
> >>>>>.metadata dir) complains when importing the project - something
> >>>>>about "Attempted to beginRule: R/, does not match outer scope rule:
> >>>>>P:/....".
> >>>>>
> >>>>>No clue...
> >>>>
> >>>>
> >>>>
> >>>>refactorings like 'change sig' use java search. if search returns no
> >>>>refs to a method, the refactoring can do nothing.
> >>>>you can use that test to verify if it's refactoring that's broken or
> >>>>something in lower layers.
> >>>>
> >>>>a.
> >>>>
> >
> >
> >
|
|
|
| Re: M9: Refactoring / change signature [message #159037 is a reply to message #159021] |
Mon, 17 May 2004 12:17 |
| Eclipse User |
|
|
|
Originally posted by: rndzank.comcast.net.not_this.net
Jerome, thanks for provoking me to finding the steps to reproduce.
Basically I reduced the whole project to single source directory
with some INCLUDEs and come EXCLUDEs. And there you have the problem:
- if ANY includes are present, the search and refactoring is crippled
- if ONLY excludes are configured for the project, search and refact.
are just fine
I cannot afford creating and watching a bug report - would it be possible
to file one with these steps? (just one new project with few sources and
some INCLUDE dirs) Or, perhaps, there already has been something filed?
Thanks
r.
P.S. The more detailed steps are:
- Plain M9 (0514) install
- new workspace, new project
- new source dir and few java classes in some packages
- configure project to INCLUDE some packages
- the included packages will not have search capabilities
Jerome Lanneluc wrote:
> If you have steps to reproduce, please enter a bug report and I will
> investigate.
>
> "Richard Nemec" <rndzank.comcast.net@not_this.net> wrote in message
> news:c8a1ra$hqt$1@eclipse.org...
>
>>Wouldn't that bug cause consistent no-search/no-refactoring
>>across the whole workspace?
>>
>>In my case, I can search/refactor some packages but cannot
>>others.
>>
>>Jerome Lanneluc wrote:
>>
>>
>>>It looks like you ran into
>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=62267.
>>>I don't know any workaround at this time. Sorry.
>>>
>>>Jerome
>>>
>>>"Richard Nemec" <rndzank.comcast.net@not_this.net> wrote in message
>>>news:c89880$o0i$1@eclipse.org...
>>>
>>>
>>>>Please, is there anyone with any suggestion?
>>>>
>>>>So far I found that no matter how I configure and compile the project,
>>>>some packages can be searched, and some not (and consequence is that
>>>>some can be refactored, some not).
>>>>
>>>>What I tried and didn't help:
>>>>- remove built class files and rebuild
>>>>- refresh the project
>>>>- clean and build
>>>>- remove index files from jdt.core
>>>>- edit the .classpath file and change order of source directories
>>>>
>>>>Little about the project structure:
>>>>- several source dirs
>>>>- several include/exclude patterns
>>>>
>>>>Thanks
>>>>
>>>>r.
>>>>
>>>>Richard Nemec wrote:
>>>>
>>>>
>>>>
>>>>>Adam, you are right. The project has basic problems with Java
>
> searching.
>
>>>>>The project is big one and quite messy.
>>>>>
>>>>>Is there a chance to get a guess what could be the critical point
>
> there?
>
>>>>>Thanks
>>>>>
>>>>>r.
>>>>>
>>>>>Adam Kiezun wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Richard Nemec wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Strange, I created a small example, and everything works.
>>>>>>>
>>>>>>>The problems I had were in a project and workspace created and copied
>>>>>>>from
>>>>>>>previous builds (M8, several Ixxx and Nxxx builds have let their
>>>>>>>footprints in the workspace as well, I'm sure).
>>>>>>>
>>>>>>>Will try new workspace, because the existing (after deleting
>>>>>>>.metadata dir) complains when importing the project - something
>>>>>>>about "Attempted to beginRule: R/, does not match outer scope rule:
>>>>>>>P:/....".
>>>>>>>
>>>>>>>No clue...
>>>>>>
>>>>>>
>>>>>>
>>>>>>refactorings like 'change sig' use java search. if search returns no
>>>>>>refs to a method, the refactoring can do nothing.
>>>>>>you can use that test to verify if it's refactoring that's broken or
>>>>>>something in lower layers.
>>>>>>
>>>>>>a.
>>>>>>
>>>
>>>
>>>
>
>
|
|
|
| Re: M9: Refactoring / change signature [message #159060 is a reply to message #159037] |
Mon, 17 May 2004 13:03 |
Jerome Lanneluc
Messages: 572
Registered: July 2009 |
Senior Member |
|
|
I'm not aware of such a problem (there is no existing bug report that
describes this problem).
I just tried the steps you gave and it worked fine for me. You will have to
give even more detailed steps such as what include pattern you use, what are
the name of the packages, what search query failed, etc.
Jerome
"Richard Nemec" <rndzank.comcast.net@not_this.net> wrote in message
news:c8aa39$sis$1@eclipse.org...
> Jerome, thanks for provoking me to finding the steps to reproduce.
> Basically I reduced the whole project to single source directory
> with some INCLUDEs and come EXCLUDEs. And there you have the problem:
> - if ANY includes are present, the search and refactoring is crippled
> - if ONLY excludes are configured for the project, search and refact.
> are just fine
>
> I cannot afford creating and watching a bug report - would it be possible
> to file one with these steps? (just one new project with few sources and
> some INCLUDE dirs) Or, perhaps, there already has been something filed?
>
> Thanks
>
> r.
>
> P.S. The more detailed steps are:
> - Plain M9 (0514) install
> - new workspace, new project
> - new source dir and few java classes in some packages
> - configure project to INCLUDE some packages
> - the included packages will not have search capabilities
>
>
> Jerome Lanneluc wrote:
>
> > If you have steps to reproduce, please enter a bug report and I will
> > investigate.
> >
> > "Richard Nemec" <rndzank.comcast.net@not_this.net> wrote in message
> > news:c8a1ra$hqt$1@eclipse.org...
> >
> >>Wouldn't that bug cause consistent no-search/no-refactoring
> >>across the whole workspace?
> >>
> >>In my case, I can search/refactor some packages but cannot
> >>others.
> >>
> >>Jerome Lanneluc wrote:
> >>
> >>
> >>>It looks like you ran into
> >>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=62267.
> >>>I don't know any workaround at this time. Sorry.
> >>>
> >>>Jerome
> >>>
> >>>"Richard Nemec" <rndzank.comcast.net@not_this.net> wrote in message
> >>>news:c89880$o0i$1@eclipse.org...
> >>>
> >>>
> >>>>Please, is there anyone with any suggestion?
> >>>>
> >>>>So far I found that no matter how I configure and compile the project,
> >>>>some packages can be searched, and some not (and consequence is that
> >>>>some can be refactored, some not).
> >>>>
> >>>>What I tried and didn't help:
> >>>>- remove built class files and rebuild
> >>>>- refresh the project
> >>>>- clean and build
> >>>>- remove index files from jdt.core
> >>>>- edit the .classpath file and change order of source directories
> >>>>
> >>>>Little about the project structure:
> >>>>- several source dirs
> >>>>- several include/exclude patterns
> >>>>
> >>>>Thanks
> >>>>
> >>>>r.
> >>>>
> >>>>Richard Nemec wrote:
> >>>>
> >>>>
> >>>>
> >>>>>Adam, you are right. The project has basic problems with Java
> >
> > searching.
> >
> >>>>>The project is big one and quite messy.
> >>>>>
> >>>>>Is there a chance to get a guess what could be the critical point
> >
> > there?
> >
> >>>>>Thanks
> >>>>>
> >>>>>r.
> >>>>>
> >>>>>Adam Kiezun wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Richard Nemec wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Strange, I created a small example, and everything works.
> >>>>>>>
> >>>>>>>The problems I had were in a project and workspace created and
copied
> >>>>>>>from
> >>>>>>>previous builds (M8, several Ixxx and Nxxx builds have let their
> >>>>>>>footprints in the workspace as well, I'm sure).
> >>>>>>>
> >>>>>>>Will try new workspace, because the existing (after deleting
> >>>>>>>.metadata dir) complains when importing the project - something
> >>>>>>>about "Attempted to beginRule: R/, does not match outer scope rule:
> >>>>>>>P:/....".
> >>>>>>>
> >>>>>>>No clue...
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>refactorings like 'change sig' use java search. if search returns no
> >>>>>>refs to a method, the refactoring can do nothing.
> >>>>>>you can use that test to verify if it's refactoring that's broken or
> >>>>>>something in lower layers.
> >>>>>>
> >>>>>>a.
> >>>>>>
> >>>
> >>>
> >>>
> >
> >
|
|
|
| Re: M9: Refactoring / change signature [message #159147 is a reply to message #159060] |
Tue, 18 May 2004 00:43 |
| Eclipse User |
|
|
|
Originally posted by: rndzank.comcast.net.not_this.net
Here are the steps I just recreated. Thanks for looking into that.
Plain install I0514 (I'm on Win2003 if that matters)
No plugins
Start
Create new Java project ABC
Separate source and classes
Finish
Create package com.abc.one
In that package, create class ABC (OK all defaults)
In that class, create method 'public void abc() {}'
Put cursor on the method and
- Shift-Alt-C (refactor signature)
- Alt-A (add arg)
- Alt-W (preview)
- the diff shows the method to be refactored (and the tree on the top shows
class structure)
Now, go to project preferences
Open JavaBuildPath/Source, select ABC/src/inclusion filter
Click Edit
Add 'com/' and close everything (OK)
Repeat the refactoring with preview:
- Shift-Alt-C (refactor signature)
- Alt-A (add arg)
- Alt-W (preview)
- the diff doesn't show any changes and the tree on the top doesn't shows the
class structure
Jerome Lanneluc wrote:
> I'm not aware of such a problem (there is no existing bug report that
> describes this problem).
>
> I just tried the steps you gave and it worked fine for me. You will have to
> give even more detailed steps such as what include pattern you use, what are
> the name of the packages, what search query failed, etc.
>
> Jerome
>
> "Richard Nemec" <rndzank.comcast.net@not_this.net> wrote in message
> news:c8aa39$sis$1@eclipse.org...
>
>>Jerome, thanks for provoking me to finding the steps to reproduce.
>>Basically I reduced the whole project to single source directory
>>with some INCLUDEs and come EXCLUDEs. And there you have the problem:
>>- if ANY includes are present, the search and refactoring is crippled
>>- if ONLY excludes are configured for the project, search and refact.
>> are just fine
>>
>>I cannot afford creating and watching a bug report - would it be possible
>>to file one with these steps? (just one new project with few sources and
>>some INCLUDE dirs) Or, perhaps, there already has been something filed?
>>
>>Thanks
>>
>>r.
>>
>>P.S. The more detailed steps are:
>>- Plain M9 (0514) install
>>- new workspace, new project
>>- new source dir and few java classes in some packages
>>- configure project to INCLUDE some packages
>>- the included packages will not have search capabilities
>>
>>
>>Jerome Lanneluc wrote:
>>
>>
>>>If you have steps to reproduce, please enter a bug report and I will
>>>investigate.
>>>
>>>"Richard Nemec" <rndzank.comcast.net@not_this.net> wrote in message
>>>news:c8a1ra$hqt$1@eclipse.org...
>>>
>>>
>>>>Wouldn't that bug cause consistent no-search/no-refactoring
>>>>across the whole workspace?
>>>>
>>>>In my case, I can search/refactor some packages but cannot
>>>>others.
>>>>
>>>>Jerome Lanneluc wrote:
>>>>
>>>>
>>>>
>>>>>It looks like you ran into
>>>>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=62267.
>>>>>I don't know any workaround at this time. Sorry.
>>>>>
>>>>>Jerome
>>>>>
>>>>>"Richard Nemec" <rndzank.comcast.net@not_this.net> wrote in message
>>>>>news:c89880$o0i$1@eclipse.org...
>>>>>
>>>>>
>>>>>
>>>>>>Please, is there anyone with any suggestion?
>>>>>>
>>>>>>So far I found that no matter how I configure and compile the project,
>>>>>>some packages can be searched, and some not (and consequence is that
>>>>>>some can be refactored, some not).
>>>>>>
>>>>>>What I tried and didn't help:
>>>>>>- remove built class files and rebuild
>>>>>>- refresh the project
>>>>>>- clean and build
>>>>>>- remove index files from jdt.core
>>>>>>- edit the .classpath file and change order of source directories
>>>>>>
>>>>>>Little about the project structure:
>>>>>>- several source dirs
>>>>>>- several include/exclude patterns
>>>>>>
>>>>>>Thanks
>>>>>>
>>>>>>r.
>>>>>>
>>>>>>Richard Nemec wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Adam, you are right. The project has basic problems with Java
>>>
>>>searching.
>>>
>>>
>>>>>>>The project is big one and quite messy.
>>>>>>>
>>>>>>>Is there a chance to get a guess what could be the critical point
>>>
>>>there?
>>>
>>>
>>>>>>>Thanks
>>>>>>>
>>>>>>>r.
>>>>>>>
>>>>>>>Adam Kiezun wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Richard Nemec wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Strange, I created a small example, and everything works.
>>>>>>>>>
>>>>>>>>>The problems I had were in a project and workspace created and
>
> copied
>
>>>>>>>>>from
>>>>>>>>>previous builds (M8, several Ixxx and Nxxx builds have let their
>>>>>>>>>footprints in the workspace as well, I'm sure).
>>>>>>>>>
>>>>>>>>>Will try new workspace, because the existing (after deleting
>>>>>>>>>.metadata dir) complains when importing the project - something
>>>>>>>>>about "Attempted to beginRule: R/, does not match outer scope rule:
>>>>>>>>>P:/....".
>>>>>>>>>
>>>>>>>>>No clue...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>refactorings like 'change sig' use java search. if search returns no
>>>>>>>>refs to a method, the refactoring can do nothing.
>>>>>>>>you can use that test to verify if it's refactoring that's broken or
>>>>>>>>something in lower layers.
>>>>>>>>
>>>>>>>>a.
>>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
>
|
|
|
| Re: M9: Refactoring / change signature [message #159155 is a reply to message #159147] |
Tue, 18 May 2004 00:48 |
| Eclipse User |
|
|
|
Originally posted by: rndzank.comcast.net.not_this.net
Also can be reproduced in I0517 :(
r.
Richard Nemec wrote:
> Here are the steps I just recreated. Thanks for looking into that.
>
> Plain install I0514 (I'm on Win2003 if that matters)
> No plugins
> Start
> Create new Java project ABC
> Separate source and classes
> Finish
> Create package com.abc.one
> In that package, create class ABC (OK all defaults)
> In that class, create method 'public void abc() {}'
> Put cursor on the method and
> - Shift-Alt-C (refactor signature)
> - Alt-A (add arg)
> - Alt-W (preview)
> - the diff shows the method to be refactored (and the tree on the top
> shows class structure)
> Now, go to project preferences
> Open JavaBuildPath/Source, select ABC/src/inclusion filter
> Click Edit
> Add 'com/' and close everything (OK)
> Repeat the refactoring with preview:
> - Shift-Alt-C (refactor signature)
> - Alt-A (add arg)
> - Alt-W (preview)
> - the diff doesn't show any changes and the tree on the top doesn't
> shows the class structure
>
>
>
> Jerome Lanneluc wrote:
>
>> I'm not aware of such a problem (there is no existing bug report that
>> describes this problem).
>>
>> I just tried the steps you gave and it worked fine for me. You will
>> have to
>> give even more detailed steps such as what include pattern you use,
>> what are
>> the name of the packages, what search query failed, etc.
>>
>> Jerome
>>
>> "Richard Nemec" <rndzank.comcast.net@not_this.net> wrote in message
>> news:c8aa39$sis$1@eclipse.org...
>>
>>> Jerome, thanks for provoking me to finding the steps to reproduce.
>>> Basically I reduced the whole project to single source directory
>>> with some INCLUDEs and come EXCLUDEs. And there you have the problem:
>>> - if ANY includes are present, the search and refactoring is crippled
>>> - if ONLY excludes are configured for the project, search and refact.
>>> are just fine
>>>
>>> I cannot afford creating and watching a bug report - would it be
>>> possible
>>> to file one with these steps? (just one new project with few sources and
>>> some INCLUDE dirs) Or, perhaps, there already has been something filed?
>>>
>>> Thanks
>>>
>>> r.
>>>
>>> P.S. The more detailed steps are:
>>> - Plain M9 (0514) install
>>> - new workspace, new project
>>> - new source dir and few java classes in some packages
>>> - configure project to INCLUDE some packages
>>> - the included packages will not have search capabilities
>>>
>>>
>>> Jerome Lanneluc wrote:
>>>
>>>
>>>> If you have steps to reproduce, please enter a bug report and I will
>>>> investigate.
>>>>
>>>> "Richard Nemec" <rndzank.comcast.net@not_this.net> wrote in message
>>>> news:c8a1ra$hqt$1@eclipse.org...
>>>>
>>>>
>>>>> Wouldn't that bug cause consistent no-search/no-refactoring
>>>>> across the whole workspace?
>>>>>
>>>>> In my case, I can search/refactor some packages but cannot
>>>>> others.
>>>>>
>>>>> Jerome Lanneluc wrote:
>>>>>
>>>>>
>>>>>
>>>>>> It looks like you ran into
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=62267.
>>>>>> I don't know any workaround at this time. Sorry.
>>>>>>
>>>>>> Jerome
>>>>>>
>>>>>> "Richard Nemec" <rndzank.comcast.net@not_this.net> wrote in message
>>>>>> news:c89880$o0i$1@eclipse.org...
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Please, is there anyone with any suggestion?
>>>>>>>
>>>>>>> So far I found that no matter how I configure and compile the
>>>>>>> project,
>>>>>>> some packages can be searched, and some not (and consequence is that
>>>>>>> some can be refactored, some not).
>>>>>>>
>>>>>>> What I tried and didn't help:
>>>>>>> - remove built class files and rebuild
>>>>>>> - refresh the project
>>>>>>> - clean and build
>>>>>>> - remove index files from jdt.core
>>>>>>> - edit the .classpath file and change order of source directories
>>>>>>>
>>>>>>> Little about the project structure:
>>>>>>> - several source dirs
>>>>>>> - several include/exclude patterns
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> r.
>>>>>>>
>>>>>>> Richard Nemec wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Adam, you are right. The project has basic problems with Java
>>>>
>>>>
>>>> searching.
>>>>
>>>>
>>>>>>>> The project is big one and quite messy.
>>>>>>>>
>>>>>>>> Is there a chance to get a guess what could be the critical point
>>>>
>>>>
>>>> there?
>>>>
>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> r.
>>>>>>>>
>>>>>>>> Adam Kiezun wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Richard Nemec wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Strange, I created a small example, and everything works.
>>>>>>>>>>
>>>>>>>>>> The problems I had were in a project and workspace created and
>>
>>
>> copied
>>
>>>>>>>>>> from
>>>>>>>>>> previous builds (M8, several Ixxx and Nxxx builds have let their
>>>>>>>>>> footprints in the workspace as well, I'm sure).
>>>>>>>>>>
>>>>>>>>>> Will try new workspace, because the existing (after deleting
>>>>>>>>>> .metadata dir) complains when importing the project - something
>>>>>>>>>> about "Attempted to beginRule: R/, does not match outer scope
>>>>>>>>>> rule:
>>>>>>>>>> P:/....".
>>>>>>>>>>
>>>>>>>>>> No clue...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> refactorings like 'change sig' use java search. if search
>>>>>>>>> returns no
>>>>>>>>> refs to a method, the refactoring can do nothing.
>>>>>>>>> you can use that test to verify if it's refactoring that's
>>>>>>>>> broken or
>>>>>>>>> something in lower layers.
>>>>>>>>>
>>>>>>>>> a.
>>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>>
|
|
|
| Re: M9: Refactoring / change signature [message #159172 is a reply to message #159155] |
Tue, 18 May 2004 08:36 |
Jerome Lanneluc
Messages: 572
Registered: July 2009 |
Senior Member |
|
|
Thanks for your steps. I now understand the problem. I've entered
https://bugs.eclipse.org/bugs/show_bug.cgi?id=62608 to track it down. Add
yourself to the CC list if you want to be notified when it is resolved.
Also, in the meantime you can use 'com/**' as the inclusion filter. This
should work as you expect.
Jerome
"Richard Nemec" <rndzank.comcast.net@not_this.net> wrote in message
news:c8bm42$k8n$1@eclipse.org...
> Also can be reproduced in I0517 :(
> r.
>
> Richard Nemec wrote:
>
> > Here are the steps I just recreated. Thanks for looking into that.
> >
> > Plain install I0514 (I'm on Win2003 if that matters)
> > No plugins
> > Start
> > Create new Java project ABC
> > Separate source and classes
> > Finish
> > Create package com.abc.one
> > In that package, create class ABC (OK all defaults)
> > In that class, create method 'public void abc() {}'
> > Put cursor on the method and
> > - Shift-Alt-C (refactor signature)
> > - Alt-A (add arg)
> > - Alt-W (preview)
> > - the diff shows the method to be refactored (and the tree on the top
> > shows class structure)
> > Now, go to project preferences
> > Open JavaBuildPath/Source, select ABC/src/inclusion filter
> > Click Edit
> > Add 'com/' and close everything (OK)
> > Repeat the refactoring with preview:
> > - Shift-Alt-C (refactor signature)
> > - Alt-A (add arg)
> > - Alt-W (preview)
> > - the diff doesn't show any changes and the tree on the top doesn't
> > shows the class structure
> >
> >
> >
> > Jerome Lanneluc wrote:
> >
> >> I'm not aware of such a problem (there is no existing bug report that
> >> describes this problem).
> >>
> >> I just tried the steps you gave and it worked fine for me. You will
> >> have to
> >> give even more detailed steps such as what include pattern you use,
> >> what are
> >> the name of the packages, what search query failed, etc.
> >>
> >> Jerome
> >>
> >> "Richard Nemec" <rndzank.comcast.net@not_this.net> wrote in message
> >> news:c8aa39$sis$1@eclipse.org...
> >>
> >>> Jerome, thanks for provoking me to finding the steps to reproduce.
> >>> Basically I reduced the whole project to single source directory
> >>> with some INCLUDEs and come EXCLUDEs. And there you have the problem:
> >>> - if ANY includes are present, the search and refactoring is crippled
> >>> - if ONLY excludes are configured for the project, search and refact.
> >>> are just fine
> >>>
> >>> I cannot afford creating and watching a bug report - would it be
> >>> possible
> >>> to file one with these steps? (just one new project with few sources
and
> >>> some INCLUDE dirs) Or, perhaps, there already has been something
filed?
> >>>
> >>> Thanks
> >>>
> >>> r.
> >>>
> >>> P.S. The more detailed steps are:
> >>> - Plain M9 (0514) install
> >>> - new workspace, new project
> >>> - new source dir and few java classes in some packages
> >>> - configure project to INCLUDE some packages
> >>> - the included packages will not have search capabilities
> >>>
> >>>
> >>> Jerome Lanneluc wrote:
> >>>
> >>>
> >>>> If you have steps to reproduce, please enter a bug report and I will
> >>>> investigate.
> >>>>
> >>>> "Richard Nemec" <rndzank.comcast.net@not_this.net> wrote in message
> >>>> news:c8a1ra$hqt$1@eclipse.org...
> >>>>
> >>>>
> >>>>> Wouldn't that bug cause consistent no-search/no-refactoring
> >>>>> across the whole workspace?
> >>>>>
> >>>>> In my case, I can search/refactor some packages but cannot
> >>>>> others.
> >>>>>
> >>>>> Jerome Lanneluc wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> It looks like you ran into
> >>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=62267.
> >>>>>> I don't know any workaround at this time. Sorry.
> >>>>>>
> >>>>>> Jerome
> >>>>>>
> >>>>>> "Richard Nemec" <rndzank.comcast.net@not_this.net> wrote in message
> >>>>>> news:c89880$o0i$1@eclipse.org...
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Please, is there anyone with any suggestion?
> >>>>>>>
> >>>>>>> So far I found that no matter how I configure and compile the
> >>>>>>> project,
> >>>>>>> some packages can be searched, and some not (and consequence is
that
> >>>>>>> some can be refactored, some not).
> >>>>>>>
> >>>>>>> What I tried and didn't help:
> >>>>>>> - remove built class files and rebuild
> >>>>>>> - refresh the project
> >>>>>>> - clean and build
> >>>>>>> - remove index files from jdt.core
> >>>>>>> - edit the .classpath file and change order of source directories
> >>>>>>>
> >>>>>>> Little about the project structure:
> >>>>>>> - several source dirs
> >>>>>>> - several include/exclude patterns
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>>
> >>>>>>> r.
> >>>>>>>
> >>>>>>> Richard Nemec wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Adam, you are right. The project has basic problems with Java
> >>>>
> >>>>
> >>>> searching.
> >>>>
> >>>>
> >>>>>>>> The project is big one and quite messy.
> >>>>>>>>
> >>>>>>>> Is there a chance to get a guess what could be the critical point
> >>>>
> >>>>
> >>>> there?
> >>>>
> >>>>
> >>>>>>>> Thanks
> >>>>>>>>
> >>>>>>>> r.
> >>>>>>>>
> >>>>>>>> Adam Kiezun wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Richard Nemec wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Strange, I created a small example, and everything works.
> >>>>>>>>>>
> >>>>>>>>>> The problems I had were in a project and workspace created and
> >>
> >>
> >> copied
> >>
> >>>>>>>>>> from
> >>>>>>>>>> previous builds (M8, several Ixxx and Nxxx builds have let
their
> >>>>>>>>>> footprints in the workspace as well, I'm sure).
> >>>>>>>>>>
> >>>>>>>>>> Will try new workspace, because the existing (after deleting
> >>>>>>>>>> .metadata dir) complains when importing the project - something
> >>>>>>>>>> about "Attempted to beginRule: R/, does not match outer scope
> >>>>>>>>>> rule:
> >>>>>>>>>> P:/....".
> >>>>>>>>>>
> >>>>>>>>>> No clue...
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> refactorings like 'change sig' use java search. if search
> >>>>>>>>> returns no
> >>>>>>>>> refs to a method, the refactoring can do nothing.
> >>>>>>>>> you can use that test to verify if it's refactoring that's
> >>>>>>>>> broken or
> >>>>>>>>> something in lower layers.
> >>>>>>>>>
> >>>>>>>>> a.
> >>>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>
> >>
|
|
|
| Re: M9: Refactoring / change signature [message #159218 is a reply to message #159172] |
Tue, 18 May 2004 12:36 |
| Eclipse User |
|
|
|
Originally posted by: rndzank.comcast.net.not_this.net
Whoa! You already fixed it!
THANKS Jerome!
r.
P.S. If I find time I'll try to find steps to reproduce another issue
with project with overlapping sources where I had to configure the second
source using exclusion entry to include some dirs. But that may be more
complicated. Anyway, thanks a lot.
Jerome Lanneluc wrote:
> Thanks for your steps. I now understand the problem. I've entered
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=62608 to track it down. Add
> yourself to the CC list if you want to be notified when it is resolved.
>
> Also, in the meantime you can use 'com/**' as the inclusion filter. This
> should work as you expect.
>
> Jerome
|
|
| |
Goto Forum:
Current Time: Sat Jul 27 16:43:38 GMT 2024
Powered by FUDForum. Page generated in 0.05813 seconds |
] 
Search
Help
Register
Login
Home
