Re: Script to replace header comment

Discussion in 'Java' started by Lew, Oct 11, 2009.

  1. Lew

    Lew Guest

    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
     
    Lew, Oct 11, 2009
    #1
    1. Advertising

  2. Lew

    Lew Guest

    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, Oct 12, 2009
    #2
    1. Advertising

  3. 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, Oct 12, 2009
    #3
  4. Lew

    Lew Guest

    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
     
    Lew, Oct 12, 2009
    #4
  5. Lew

    Tom Anderson Guest

    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
     
    Tom Anderson, Oct 12, 2009
    #5
  6. Lew

    Lew Guest

    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, Oct 12, 2009
    #6
  7. Lew

    Arne Vajhøj Guest

    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
     
    Arne Vajhøj, Oct 12, 2009
    #7
  8. Lew

    Alan Morgan Guest

    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 shit 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, Oct 12, 2009
    #8
  9. Lew

    Arne Vajhøj Guest

    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 shit 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, Oct 12, 2009
    #9
  10. Lew

    Arne Vajhøj Guest

    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 shit 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
     
    Arne Vajhøj, Oct 12, 2009
    #10
  11. Lew

    Lew Guest

    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.

    >


    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.

    >


    Arne Vajhøj wrote:
    > My guess is that the apps you write are also caching data.


    Huh? I don't understand the relevance of that.

    > Eclipse is using the equivalent of commit option A.


    What is that?

    --
    Lew
     
    Lew, Oct 12, 2009
    #11
  12. Lew

    Arne Vajhøj Guest

    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.

    >
    > 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.

    >
    > Arne Vajhøj wrote:
    >> My guess is that the apps you write are also caching data.

    >
    > Huh? I don't understand the relevance of that.


    It seems to be what Eclipse is doing.

    >> Eclipse is using the equivalent of commit option A.

    >
    > What is that?


    Keeping a copy in memory when you write it to disk and
    assume it is still valid when you need it later. The term is
    from the EJB spec.

    Arne
     
    Arne Vajhøj, Oct 13, 2009
    #12
  13. Lew

    Lew Guest

    Arne Vajhøj wrote:
    >>> My guess is that the apps you write are also caching data.


    Lew wrote:
    >> Huh? I don't understand the relevance of that.


    Arne Vajhøj wrote:
    > It seems to be what Eclipse is doing.


    And that's relevant because ... ?

    All I observe as a user of the IDEs is that NetBeans does something I don't
    mind where Eclipse does something I do mind. If Eclipse does it because it's
    caching data, then it's doing it wrong. If my programs annoyed my users
    because I cached data, then I'd be doing it wrong. If NetBeans is caching
    data, then they're doing it right.

    --
    Lew
     
    Lew, Oct 13, 2009
    #13
  14. Lew wrote:
    > Arne Vajhøj wrote:
    >>>> My guess is that the apps you write are also caching data.

    >
    > Lew wrote:
    >>> Huh? I don't understand the relevance of that.

    >
    > Arne Vajhøj wrote:
    >> It seems to be what Eclipse is doing.

    >
    > And that's relevant because ... ?


    You brought the topic of "what" into the discussion - the
    topic of "why" seems relevant to me then.

    > All I observe as a user of the IDEs is that NetBeans does something I
    > don't mind where Eclipse does something I do mind. If Eclipse does it
    > because it's caching data, then it's doing it wrong. If my programs
    > annoyed my users because I cached data, then I'd be doing it wrong.


    No.

    Software works according to some specs.

    If the users follow the docs and get problems then it is
    a bug.

    If the users does not follow the docs and get problems
    then they have shot themselves in the foot.

    If you use commit option A for an EJB solution and change
    data from another application then you can not blame
    the EJB or the app server or Java.

    If Eclipse does not support external editing of files, then
    it does not.

    Given that there are supported ways of doing it then I can
    not see any reason to mess around with Eclipse's caching
    policy.

    Arne
     
    Arne Vajhøj, Oct 13, 2009
    #14
  15. Lew

    Lew Guest

    Lew wrote:
    >> All I observe as a user of the IDEs is that NetBeans does something I
    >> don't mind where Eclipse does something I do mind. If Eclipse does it
    >> because it's caching data, then it's doing it wrong. If my programs
    >> annoyed my users because I cached data, then I'd be doing it wrong.



    Arne Vajhøj wrote:
    > No.


    Yes.

    > Software works according to some specs.
    >
    > If the users follow the docs and get problems then it is
    > a bug.


    I am not discussing bugs here. I am discussing features.

    If a program is implemented perfectly according to spec and it annoys its
    users, they're doing it wrong. The idea is not to annoy your users.

    If you don't give your users what they want, you have missed the point.

    > If the users does not follow the docs and get problems
    > then they have shot themselves in the foot.


    So programmers get to tell users what they want?

    If a program doesn't do what I want, I will use a different program that does.
    Is that what Eclipse's authors want?

    > If you use commit option A for an EJB solution and change
    > data from another application then you can not blame
    > the EJB or the app server or Java.


    That is remarkably irrelevant.

    > If Eclipse does not support external editing of files, then
    > it does not.


    If Eclipse does not support the features that I want, or implements them in a
    way that annoys me, I will use a competitor by preference.

    > Given that there are supported ways of doing it then I can
    > not see any reason to mess around with Eclipse's caching
    > policy.


    Nor can I. That's why I use NetBeans when given a choice. Eclipse's way of
    doing things annoys me.

    Given that Eclipse is the root of commercial products, then those commercial
    products will lose business whenever I have a say in the matter, as long as a
    competitor annoys me less and does what I want better. If it turns out that I
    am representative of a large enough population, then that vendor who annoys
    that population loses. It does not matter if the product performs according
    to spec; the demand side of the value equation will reduce their sales.

    Consider the Edsel. It was exactly what it was intended to be, and it was a
    failure. Ditto New Coke. It's not enough to do things right; you have to do
    the right thing.

    --
    Lew
     
    Lew, Oct 13, 2009
    #15
  16. Tom Anderson wrote:
    > 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
    >

    Well, it's a bit more than that. Create a new source file from outside
    the IDE and save it in a project directory. When you start NetBeans it
    picks up on new packages and folders and files, marking them as New.
    When you start Eclipse it completely ignores any new files, not even
    showing them for addition to version control if that's applicable for
    the project - you have to explicitly refresh the project in order to
    synchronize the Eclipse file system with the real "file" system that it
    maps to.

    The fact that Eclipse does maintain its own file system is why, from
    time to time (not often in my experience) it can get irrevocably out of
    sync with what's really in the OS file system, and not even an Eclipse
    restart always clears that horrendous mess up. I haven't seen anything
    quite this ugly happen with NetBeans.

    AHS
     
    Arved Sandstrom, Oct 14, 2009
    #16
  17. Lew

    Wojtek Guest

    Arved Sandstrom wrote :
    > Tom Anderson wrote:
    >> 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
    >>

    > Well, it's a bit more than that. Create a new source file from outside the
    > IDE and save it in a project directory. When you start NetBeans it picks up
    > on new packages and folders and files, marking them as New. When you start
    > Eclipse it completely ignores any new files, not even showing them for
    > addition to version control if that's applicable for the project - you have
    > to explicitly refresh the project in order to synchronize the Eclipse file
    > system with the real "file" system that it maps to.
    >
    > The fact that Eclipse does maintain its own file system is why, from time to
    > time (not often in my experience) it can get irrevocably out of sync with
    > what's really in the OS file system, and not even an Eclipse restart always
    > clears that horrendous mess up. I haven't seen anything quite this ugly
    > happen with NetBeans.


    I have never run into this. For instance, I have an external code
    generator which I use occasionally. The code generator modifies some
    files, and create directories and files, all within the "project"
    structure.

    Eclipse will detect these changes/additions and present them in the
    source viewer, plus compile them. I have done this with Eclipse running
    and with it not running. Either way works.

    And Eclipse does not have its own file system. It uses the same files
    which you see when viewing the source code using some file manager.

    --
    Wojtek :)
     
    Wojtek, Oct 14, 2009
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Alec S.
    Replies:
    10
    Views:
    10,325
    Alec S.
    Apr 16, 2005
  2. Shane Spraggs
    Replies:
    0
    Views:
    605
    Shane Spraggs
    Jan 16, 2004
  3. mlt
    Replies:
    2
    Views:
    912
    Jean-Marc Bourguet
    Jan 31, 2009
  4. Stefan Ram
    Replies:
    1
    Views:
    391
    Arne Vajhøj
    Oct 11, 2009
  5. Roedy Green

    Re: Script to replace header comment

    Roedy Green, Oct 12, 2009, in forum: Java
    Replies:
    1
    Views:
    587
    Roedy Green
    Oct 12, 2009
Loading...

Share This Page