«

Kenneth P. Turvey wrote:
> Basically I want to replace all the text before the package statement
> with new text. I can write something in a few minutes, but I thought
> someone else might have something already.

The major IDEs can do this.

--
Lew

Kenneth P. Turvey wrote:
> How would you replace the header comment in a collection of files using
> NetBeans?

Menu: Edit / "Replace in Projects" (Ctrl-Shift-H)

replace regex
(.*\n)*(package)
with
/* desiredstring */\npackage

--
Lew

Lew wrote:
> Kenneth P. Turvey wrote:
>> How would you replace the header comment in a collection of files
>> using NetBeans?
>
> Menu: Edit / "Replace in Projects" (Ctrl-Shift-H)
>
> replace regex
> (.*\n)*(package)
> with
> /* desiredstring */\npackage
>
And Eclipse is fundamentally the same thing, through Search > Files.
Once you indicate the file name pattern(s) and the scope of the search,
have set up the regular expression search pattern, and have run through
one search as a sanity check, there's a Replace button you can click to
enter a replace string.

With modern IDEs I see little reason to leave them to do a search &
replace on project files. However, I guess there are always edge cases.
On UNIX-based operating systems you can always fall back on
find/xargs/sed/awk/perl, and on Windows you've got PowerShell. NOTE:
can't remember about NetBeans, but if you make changes to project files
outside Eclipse, don't forget to refresh once you're back in the IDE.

AHS

Arved Sandstrom wrote:
> NOTE:
> can't remember about NetBeans, but if you make changes to project files
> outside Eclipse, don't forget to refresh once you're back in the IDE.
>

That is an aspect of Eclipse that I find annoying. It has this
mysterious shadow copy of files that don't necessarily match what's on
disk even when you don't have editing changes pending. NetBeans
appears to work directly from the file system, which I prefer.

--
Lew

On Mon, 12 Oct 2009, Lew wrote:

> Arved Sandstrom wrote:
>
>> can't remember about NetBeans, but if you make changes to project files
>> outside Eclipse, don't forget to refresh once you're back in the IDE.
>
> That is an aspect of Eclipse that I find annoying. It has this
> mysterious shadow copy of files that don't necessarily match what's on
> disk even when you don't have editing changes pending. NetBeans appears
> to work directly from the file system, which I prefer.

AFAICT, the 'shadow copy' is what's in memory. The situation is the same
as if you had a file open in vi, and crept in behind it and edited it with
something else. No?

There is an annoyance when you have a file open in both a normal view and
a compare view - changes in either view don't show up in the other until
it's saved (IIRC).

tom

--
Science of a sufficiently advanced form is indistinguishable from magic

Lew wrote:
>> That is an aspect of Eclipse that I find annoying. *It has this
>> mysterious shadow copy of files that don't necessarily match what's on
>> disk even when you don't have editing changes pending. *NetBeans appears
>> to work directly from the file system, which I prefer.
>

Tom Anderson wrote:
> AFAICT, the 'shadow copy' is what's in memory. The situation is the same
> as if you had a file open in vi, and crept in behind it and edited it with
> something else. No?
>

I don't know. Maybe.

NetBeans (NB) and Eclipse behave differently. I often have to refresh
Eclipse (or offspring)'s project view but I never seem to need to do
that with NetBeans. In Eclipse I set an option to "refresh
automatically" which obviates some of that behavior. I don't think
NetBeans even has such a setting.

It very well may be exactly what you say, except that NB decides to
"refresh automatically" without asking, but Eclipse insists on asking.

Whatever the reason, I prefer NetBeans's behavior with respect to this
feature.

--
Lew

Lew wrote:
> Arved Sandstrom wrote:
>> NOTE:
>> can't remember about NetBeans, but if you make changes to project files
>> outside Eclipse, don't forget to refresh once you're back in the IDE.
>>
>
> That is an aspect of Eclipse that I find annoying. It has this
> mysterious shadow copy of files that don't necessarily match what's on
> disk even when you don't have editing changes pending. NetBeans
> appears to work directly from the file system, which I prefer.

My guess is that the apps you write are also caching data.

Eclipse is using the equivalent of commit option A.

Arne

In article <4ad37d4a$0$289$>,
=?ISO-8859-1?Q?Arne_Vajh=F8j?= <> wrote:
>Lew wrote:
>> Arved Sandstrom wrote:
>>> NOTE:
>>> can't remember about NetBeans, but if you make changes to project files
>>> outside Eclipse, don't forget to refresh once you're back in the IDE.
>>>
>>
>> That is an aspect of Eclipse that I find annoying. It has this
>> mysterious shadow copy of files that don't necessarily match what's on
>> disk even when you don't have editing changes pending. NetBeans
>> appears to work directly from the file system, which I prefer.
>
>My guess is that the apps you write are also caching data.
>
>Eclipse is using the equivalent of commit option A.

Yeah, but Eclipse sits there and says "My file copy is out of date. You
aren't going to be able to see jack **** unless you refresh. In fact,
I'm not even going to show you my old copy. It's old and nasty and you
wouldn't like it. Please hit F5 to refresh (unless you are in a mode
where F5 won't refresh, in which case hit something else)".

Why it can do this and not refresh for me is... puzzling. Maybe it's
just lonely and likes talking to someone.

Alan
--
Defendit numerus

Alan Morgan wrote:
> In article <4ad37d4a$0$289$>,
> =?ISO-8859-1?Q?Arne_Vajh=F8j?= <> wrote:
>> Lew wrote:
>>> Arved Sandstrom wrote:
>>>> NOTE:
>>>> can't remember about NetBeans, but if you make changes to project files
>>>> outside Eclipse, don't forget to refresh once you're back in the IDE.
>>>>
>>> That is an aspect of Eclipse that I find annoying. It has this
>>> mysterious shadow copy of files that don't necessarily match what's on
>>> disk even when you don't have editing changes pending. NetBeans
>>> appears to work directly from the file system, which I prefer.
>> My guess is that the apps you write are also caching data.
>>
>> Eclipse is using the equivalent of commit option A.
>
> Yeah, but Eclipse sits there and says "My file copy is out of date. You
> aren't going to be able to see jack **** unless you refresh. In fact,
> I'm not even going to show you my old copy. It's old and nasty and you
> wouldn't like it. Please hit F5 to refresh (unless you are in a mode
> where F5 won't refresh, in which case hit something else)".
>
> Why it can do this and not refresh for me is... puzzling. Maybe it's
> just lonely and likes talking to someone.

You will have to ask some Eclipse guy why they chose to do it
that way.

But I am not so surprised. We are not supposed to edit files
behind Eclipse's back. If Eclipse detects it then it wants us
to deal with it instead of making a guess and try to fix it.

Arne

Arne Vajhøj wrote:
> Alan Morgan wrote:
>> In article <4ad37d4a$0$289$>,
>> =?ISO-8859-1?Q?Arne_Vajh=F8j?= <> wrote:
>>> Lew wrote:
>>>> Arved Sandstrom wrote:
>>>>> NOTE:
>>>>> can't remember about NetBeans, but if you make changes to project
>>>>> files
>>>>> outside Eclipse, don't forget to refresh once you're back in the IDE.
>>>>>
>>>> That is an aspect of Eclipse that I find annoying. It has this
>>>> mysterious shadow copy of files that don't necessarily match what's on
>>>> disk even when you don't have editing changes pending. NetBeans
>>>> appears to work directly from the file system, which I prefer.
>>> My guess is that the apps you write are also caching data.
>>>
>>> Eclipse is using the equivalent of commit option A.
>>
>> Yeah, but Eclipse sits there and says "My file copy is out of date. You
>> aren't going to be able to see jack **** unless you refresh. In fact,
>> I'm not even going to show you my old copy. It's old and nasty and you
>> wouldn't like it. Please hit F5 to refresh (unless you are in a mode
>> where F5 won't refresh, in which case hit something else)".
>>
>> Why it can do this and not refresh for me is... puzzling. Maybe it's
>> just lonely and likes talking to someone.
>
> You will have to ask some Eclipse guy why they chose to do it
> that way.
>
> But I am not so surprised. We are not supposed to edit files
> behind Eclipse's back. If Eclipse detects it then it wants us
> to deal with it instead of making a guess and try to fix it.

I believe that the right way of doing it is to:
- get from source control to a dir outside of Eclipse
- edit
- commit changes
- update in Eclipse

Arne