Topics

Fighting NetBeans

whmvd
 

Hi all,

My NetBeans 10 environment was up to date up to 4.17.4, and working. meaning I could build and run the resulting JMRI, and I could also build my own library against the JMRI jar and use that. All good.

Just now, as I do whenever there's a major release (and sometimes in between), I updated to 4.18. As always, I did 'Project JMRI => context menu Git => Remote => pull ...' and chose the 'master -> origin/master' branch. It seemed to do its stuff (although it does it all silently, so if something doesn't work I have no idea how I'd know or where to look).

As of that moment, there are project errors, all in the sources under
JMRI/java/test/jmri/...
and as far as I can tell all to do with not being able to find
import jmri.jmrit.display.layoutEditor.LayoutEditor;
because in all such statements, the last 'LayoutEditor'is underlined and the error states 'cannot find symbol'.

Now the file:
/home/wouter/NetBeansProjects/JMRI/java/src/jmri/jmrit/display/layoutEditor/LayoutEditor.java
itself, which is part of package 'jmri.jmrit.display.layoutEditor' actually exists and has no compilation errors.

A 'realclean' has not helped. In short: I am lost. Has anyone any idea what might be going on?

Thanks,
Wouter

Bob M.
 

Wouter,

I run NetBeans 8.1 on a Windows platform.

I NEVER had any luck using NetBeans with the "three-sided" Git configuration recommended in the JMRI git setup information. NetBeans always overrode that git setup, and caused great git difficulty. Instead, I use a command line shell with Git functionality and do everything git via command line operations instead of via NetBeans.

I did, however, struggle to get NetBeans to build JMRI code after pulling "master" a few days ago. I could not compile a source code file where I added a reference to javax.swing.Timer. It would not compile, even though another line earlier in the modified method _successfully_ referenced javax.Swing.Timer. I don't have _any_ idea how the compiler could have that kind of problem!

I got past the problem but I don't know what I did that solved the problem. It could have been one of multiple attempts to "git pull master" invocations, or one of multiple attempts at running the ant "realclean" target (from within NetBeans) followed by running the ant "panelpro" target. Or I may have manually deleted some files in the build environment (perhaps ones not deleted by the "realclean" target). Net result is I can build "normally" now.

My NetBeans install currently _only_ shows "red marks" on some source files in java/test/jmri/jmrit/layoutEditor/LayoutEditorDialogs .

Regards,
Billybob

-----Original Message-----
From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of whmvd
Sent: Tuesday, December 24, 2019 12:33 PM
To: jmri@jmri-developers.groups.io
Subject: [jmri-developers] Fighting NetBeans

Hi all,

My NetBeans 10 environment was up to date up to 4.17.4, and working. meaning I could build and run the resulting JMRI, and I could also build my own library against the JMRI jar and use that. All good.

Just now, as I do whenever there's a major release (and sometimes in between), I updated to 4.18. As always, I did 'Project JMRI => context menu Git => Remote => pull ...' and chose the 'master -> origin/master' branch. It seemed to do its stuff (although it does it all silently, so if something doesn't work I have no idea how I'd know or where to look).

As of that moment, there are project errors, all in the sources under
JMRI/java/test/jmri/...
and as far as I can tell all to do with not being able to find
import jmri.jmrit.display.layoutEditor.LayoutEditor;
because in all such statements, the last 'LayoutEditor'is underlined and the error states 'cannot find symbol'.

Now the file:
/home/wouter/NetBeansProjects/JMRI/java/src/jmri/jmrit/display/layoutEditor/LayoutEditor.java
itself, which is part of package 'jmri.jmrit.display.layoutEditor' actually exists and has no compilation errors.

A 'realclean' has not helped. In short: I am lost. Has anyone any idea what might be going on?

Thanks,
Wouter

danielb987
 

I use the GitHub Desktop application on both Windows and Linux and it works fine.

GitHub Desktop lets you use git with a graphical user interface. 

Daniel

Bob Jacobsen
 

On Dec 24, 2019, at 10:22 AM, Bob M. <jawhugrps@...> wrote:

I NEVER had any luck using NetBeans with the "three-sided" Git configuration recommended in the JMRI git setup information. NetBeans always overrode that git setup, and caused great git difficulty. Instead, I use a command line shell with Git functionality and do everything git via command line operations instead of via NetBeans.
The above is referring to the setup described in “Setting up a Git environment for JMRI Developers” on this page: https://www.jmri.org/help/en/html/doc/Technical/GitFAQ.shtml

It has the advantage that the “git pull” and “git push” commands do what most people expect. But it requires a particular setup that some Git clients, particularly IDEs, don’t readily do.

There are other choices:

1) Set up a “github” remote, and have both push and pull for master default to your own GitHub repository.

In that case, the “git push” command works as expected, but you have to do “git pull github” to get the most recent contents. Without the remote, that’ll be pulling from your own repository, which is likely to be out of date unless you’ve taken steps to update it.

2) Set up a “myGitHubRepo” remote, and have both push and pull for master default to the main JMRI GitHub repository.

In that case, “git pull” will bring again bring in the most recent content from the main JMRI GitHub. But in this case, “git push” will fail for most developers (Those with push privileges should _NOT_ set up this way; it’s too easy to make a mistake) so they’ll have to do “git push myGitHubRepo” to push content for PRs.


Neither is as good as the default setup, in the sense of convenience. I think (1) is a reasonable alternative to document, particularly if i.e. NetBeans really can’t handle the split pull/push destinations.

Bob
--
Bob Jacobsen
@BobJacobsen

whmvd
 

Thanks to all who chimed in. I am now back in business, but it would be nice to know what got confused, how it got confused, how I could have prevented it and even what finally made the problem go away. More confirmation for self that I am not suited to the world of wizards, IDEs and what-nots.

I do know that restarts, a reboot or two, re-configuration of the classpath, realcleans, cleans, repeated git pulls and more were involved, and all in all it's bound to happen again. And again. Because in the end it was just 'try anything, then try anything else, repeat'.

At least I can go on again, and that's the main thing. And nobody need worry - I only do the occasional pull, all my development work is done in my own library outside of JMRI. I will not be a menace, just a bore!

Thanks again for the suggestions,
Wouter


On Wed, 25 Dec 2019 at 04:02, Bob Jacobsen <rgj1927@...> wrote:


> On Dec 24, 2019, at 10:22 AM, Bob M. <jawhugrps@...> wrote:
>
> I NEVER had any luck using NetBeans with the "three-sided" Git configuration recommended in the JMRI git setup information.  NetBeans always overrode that git setup, and caused great git difficulty.  Instead, I use a command line shell with Git functionality and do everything git via command line operations instead of via NetBeans.

The above is referring to the setup described in “Setting up a Git environment for JMRI Developers” on this page:  https://www.jmri.org/help/en/html/doc/Technical/GitFAQ.shtml

It has the advantage that the “git pull” and “git push” commands do what most people expect.  But it requires a particular setup that some Git clients, particularly IDEs, don’t readily do.

There are other choices:

1) Set up a “github” remote, and have both push and pull for master default to your own GitHub repository.

In that case, the “git push” command works as expected, but you have to do “git pull github” to get the most recent contents.  Without the remote, that’ll be pulling from your own repository, which is likely to be out of date unless you’ve taken steps to update it.

2) Set up a “myGitHubRepo” remote, and have both push and pull for master default to the main JMRI GitHub repository.

In that case, “git pull” will bring again bring in the most recent content from the main JMRI GitHub.  But in this case, “git push” will fail for most developers  (Those with push privileges should _NOT_ set up this way; it’s too easy to make a mistake) so they’ll have to do “git push myGitHubRepo” to push content for PRs.


Neither is as good as the default setup, in the sense of convenience. I think (1) is a reasonable alternative to document, particularly if i.e. NetBeans really can’t handle the split pull/push destinations.

Bob
--
Bob Jacobsen
rgj1927@...






Svata Dedic
 

re. NetBeans, there's a simple test: if you can compile the project (Run -> Clean and Build ... completes OK), but the Editor still shows errors, the IDE's symbol cache may be broken. It happens from time time to time :-/
Most of the time, deleting all in your {netbeans-userdir}/var/cache will help, since the cache will be newly built (not updated) from the fresh sources.

-S.

Dne 25. 12. 19 v 11:37 whmvd napsal(a):

Thanks to all who chimed in. I am now back in business, but it would be nice to know what got confused, how it got confused, how I could have prevented it and even what finally made the problem go away. More confirmation for self that I am not suited to the world of wizards, IDEs and what-nots.
I do know that restarts, a reboot or two, re-configuration of the classpath, realcleans, cleans, repeated git pulls and more were involved, and all in all it's bound to happen again. And again. Because in the end it was just 'try anything, then try anything else, repeat'.
At least I can go on again, and that's the main thing. And nobody need worry - I only do the occasional pull, all my development work is done in my own library outside of JMRI. I will not be a menace, just a bore!
Thanks again for the suggestions,
Wouter
On Wed, 25 Dec 2019 at 04:02, Bob Jacobsen <@BobJacobsen <mailto:@BobJacobsen>> wrote:

> On Dec 24, 2019, at 10:22 AM, Bob M. <jawhugrps@...
<mailto:jawhugrps@...>> wrote:
>
> I NEVER had any luck using NetBeans with the "three-sided" Git
configuration recommended in the JMRI git setup information. NetBeans always overrode that git setup, and caused great git
difficulty.  Instead, I use a command line shell with Git
functionality and do everything git via command line operations
instead of via NetBeans.
The above is referring to the setup described in “Setting up a Git
environment for JMRI Developers” on this page:
https://www.jmri.org/help/en/html/doc/Technical/GitFAQ.shtml
It has the advantage that the “git pull” and “git push” commands do
what most people expect.  But it requires a particular setup that
some Git clients, particularly IDEs, don’t readily do.
There are other choices:
1) Set up a “github” remote, and have both push and pull for master
default to your own GitHub repository.
In that case, the “git push” command works as expected, but you have
to do “git pull github” to get the most recent contents.  Without
the remote, that’ll be pulling from your own repository, which is
likely to be out of date unless you’ve taken steps to update it.
2) Set up a “myGitHubRepo” remote, and have both push and pull for
master default to the main JMRI GitHub repository.
In that case, “git pull” will bring again bring in the most recent
content from the main JMRI GitHub.  But in this case, “git push”
will fail for most developers  (Those with push privileges should
_NOT_ set up this way; it’s too easy to make a mistake) so they’ll
have to do “git push myGitHubRepo” to push content for PRs.
Neither is as good as the default setup, in the sense of
convenience. I think (1) is a reasonable alternative to document,
particularly if i.e. NetBeans really can’t handle the split
pull/push destinations.
Bob
--
Bob Jacobsen
@BobJacobsen <mailto:@BobJacobsen>

whmvd
 

Thank you, Svata. That might very well have had something to do with it. I was hoping to find something cache-like in my hunt to get it working again, but wasn't successful.

Probably the internals of the cache change per version, and 10.0 does not have the directory you mention. I'd guess at filehistory, but can't find confirmation on the net, and I also don't know if that would be sufficient. Pity!

Thanks again,
Wouter


On Wed, 25 Dec 2019 at 15:02, Svata Dedic <garat@...> wrote:
re. NetBeans, there's a simple test: if you can compile the project (Run
-> Clean and Build ... completes OK), but the Editor still shows errors,
the IDE's symbol cache may be broken. It happens from time time to time :-/
Most of the time, deleting all in your {netbeans-userdir}/var/cache will
help, since the cache will be newly built (not updated) from the fresh
sources.

-S.

Dne 25. 12. 19 v 11:37 whmvd napsal(a):
> Thanks to all who chimed in. I am now back in business, but it would be
> nice to know what got confused, how it got confused, how I could have
> prevented it and even what finally made the problem go away. More
> confirmation for self that I am not suited to the world of wizards, IDEs
> and what-nots.
>
> I do know that restarts, a reboot or two, re-configuration of the
> classpath, realcleans, cleans, repeated git pulls and more were
> involved, and all in all it's bound to happen again. And again. Because
> in the end it was just 'try anything, then try anything else, repeat'.
>
> At least I can go on again, and that's the main thing. And nobody need
> worry - I only do the occasional pull, all my development work is done
> in my own library outside of JMRI. I will not be a menace, just a bore!
>
> Thanks again for the suggestions,
> Wouter
>
> On Wed, 25 Dec 2019 at 04:02, Bob Jacobsen <rgj1927@...
> <mailto:rgj1927@...>> wrote:
>
>
>
>      > On Dec 24, 2019, at 10:22 AM, Bob M. <jawhugrps@...
>     <mailto:jawhugrps@...>> wrote:
>      >
>      > I NEVER had any luck using NetBeans with the "three-sided" Git
>     configuration recommended in the JMRI git setup information.
>     NetBeans always overrode that git setup, and caused great git
>     difficulty.  Instead, I use a command line shell with Git
>     functionality and do everything git via command line operations
>     instead of via NetBeans.
>
>     The above is referring to the setup described in “Setting up a Git
>     environment for JMRI Developers” on this page:
>     https://www.jmri.org/help/en/html/doc/Technical/GitFAQ.shtml
>
>     It has the advantage that the “git pull” and “git push” commands do
>     what most people expect.  But it requires a particular setup that
>     some Git clients, particularly IDEs, don’t readily do.
>
>     There are other choices:
>
>     1) Set up a “github” remote, and have both push and pull for master
>     default to your own GitHub repository.
>
>     In that case, the “git push” command works as expected, but you have
>     to do “git pull github” to get the most recent contents.  Without
>     the remote, that’ll be pulling from your own repository, which is
>     likely to be out of date unless you’ve taken steps to update it.
>
>     2) Set up a “myGitHubRepo” remote, and have both push and pull for
>     master default to the main JMRI GitHub repository.
>
>     In that case, “git pull” will bring again bring in the most recent
>     content from the main JMRI GitHub.  But in this case, “git push”
>     will fail for most developers  (Those with push privileges should
>     _NOT_ set up this way; it’s too easy to make a mistake) so they’ll
>     have to do “git push myGitHubRepo” to push content for PRs.
>
>
>     Neither is as good as the default setup, in the sense of
>     convenience. I think (1) is a reasonable alternative to document,
>     particularly if i.e. NetBeans really can’t handle the split
>     pull/push destinations.
>
>     Bob
>     --
>     Bob Jacobsen
>     rgj1927@... <mailto:rgj1927@...>
>
>
>
>
>
>
>




Svata Dedic
 

You can believe me that every NetBeans (up to and including the current master dev build) have such a cache somewhere :) If you run the ide with --userdir parameter, the cache is right inside the userdir directory. I'd recommend to use that instead of the default anyway, it allows to separate different environments.

If you use the _default_ userdir, however, the cache location depends on your OS and is *detached* from the configuration (e.g. to support roaming profiles etc); on Linux, look in ~/.cache/netbeans/{netbeans-version}.

Full details can be found at http://wiki.netbeans.org/FaqWhatIsUserdir ; look for 'cachedir' terms.

-S.

Dne 25. 12. 19 v 16:58 whmvd napsal(a):

Thank you, Svata. That might very well have had something to do with it. I was hoping to find something cache-like in my hunt to get it working again, but wasn't successful.
Probably the internals of the cache change per version, and 10.0 does not have the directory you mention. I'd guess at filehistory, but can't find confirmation on the net, and I also don't know if that would be sufficient. Pity!
Thanks again,
Wouter
On Wed, 25 Dec 2019 at 15:02, Svata Dedic <garat@... <mailto:garat@...>> wrote:
re. NetBeans, there's a simple test: if you can compile the project
(Run
-> Clean and Build ... completes OK), but the Editor still shows
errors,
the IDE's symbol cache may be broken. It happens from time time to
time :-/
Most of the time, deleting all in your {netbeans-userdir}/var/cache
will
help, since the cache will be newly built (not updated) from the fresh
sources.
-S.
Dne 25. 12. 19 v 11:37 whmvd napsal(a):
> Thanks to all who chimed in. I am now back in business, but it
would be
> nice to know what got confused, how it got confused, how I could
have
> prevented it and even what finally made the problem go away. More
> confirmation for self that I am not suited to the world of
wizards, IDEs
> and what-nots.
>
> I do know that restarts, a reboot or two, re-configuration of the
> classpath, realcleans, cleans, repeated git pulls and more were
> involved, and all in all it's bound to happen again. And again.
Because
> in the end it was just 'try anything, then try anything else,
repeat'.
>
> At least I can go on again, and that's the main thing. And nobody
need
> worry - I only do the occasional pull, all my development work is
done
> in my own library outside of JMRI. I will not be a menace, just a
bore!
>
> Thanks again for the suggestions,
> Wouter
>
> On Wed, 25 Dec 2019 at 04:02, Bob Jacobsen <@BobJacobsen
<mailto:@BobJacobsen>
> <mailto:@BobJacobsen <mailto:@BobJacobsen>>> wrote:
>
>
>
>      > On Dec 24, 2019, at 10:22 AM, Bob M.
<jawhugrps@... <mailto:jawhugrps@...>
>     <mailto:jawhugrps@...
<mailto:jawhugrps@...>>> wrote:
>      >
>      > I NEVER had any luck using NetBeans with the "three-sided" Git
>     configuration recommended in the JMRI git setup information.
>     NetBeans always overrode that git setup, and caused great git
>     difficulty.  Instead, I use a command line shell with Git
>     functionality and do everything git via command line operations
>     instead of via NetBeans.
>
>     The above is referring to the setup described in “Setting up
a Git
>     environment for JMRI Developers” on this page:
> https://www.jmri.org/help/en/html/doc/Technical/GitFAQ.shtml
>
>     It has the advantage that the “git pull” and “git push”
commands do
>     what most people expect.  But it requires a particular setup that
>     some Git clients, particularly IDEs, don’t readily do.
>
>     There are other choices:
>
>     1) Set up a “github” remote, and have both push and pull for
master
>     default to your own GitHub repository.
>
>     In that case, the “git push” command works as expected, but
you have
>     to do “git pull github” to get the most recent contents.  Without
>     the remote, that’ll be pulling from your own repository, which is
>     likely to be out of date unless you’ve taken steps to update it.
>
>     2) Set up a “myGitHubRepo” remote, and have both push and
pull for
>     master default to the main JMRI GitHub repository.
>
>     In that case, “git pull” will bring again bring in the most
recent
>     content from the main JMRI GitHub.  But in this case, “git push”
>     will fail for most developers  (Those with push privileges should
>     _NOT_ set up this way; it’s too easy to make a mistake) so
they’ll
>     have to do “git push myGitHubRepo” to push content for PRs.
>
>
>     Neither is as good as the default setup, in the sense of
>     convenience. I think (1) is a reasonable alternative to document,
>     particularly if i.e. NetBeans really can’t handle the split
>     pull/push destinations.
>
>     Bob
>     --
>     Bob Jacobsen
> @BobJacobsen <mailto:@BobJacobsen>
<mailto:@BobJacobsen <mailto:@BobJacobsen>>
>
>
>
>
>
>
>

whmvd
 

Sorry, my mistake in writing unclearly. I did find the cache, but not the specific bits that I'd need to remove. Imoved aside the whole thing, and that meant that my projects disappeared - that was a bit much! So I swiftly put it back...

Thanks again,
Wouter


On Wed, 25 Dec 2019 at 16:15, Svata Dedic <garat@...> wrote:
You can believe me that every NetBeans (up to and including the current
master dev build) have such a cache somewhere :) If you run the ide with
--userdir parameter, the cache is right inside the userdir directory.
I'd recommend to use that instead of the default anyway, it allows to
separate different environments.

If you use the _default_ userdir, however, the cache location depends on
your OS and is *detached* from the configuration (e.g. to support
roaming profiles etc); on Linux, look in
~/.cache/netbeans/{netbeans-version}.

Full details can be found at http://wiki.netbeans.org/FaqWhatIsUserdir ;
look for 'cachedir' terms.

-S.

Dne 25. 12. 19 v 16:58 whmvd napsal(a):
> Thank you, Svata. That might very well have had something to do with it.
> I was hoping to find something cache-like in my hunt to get it working
> again, but wasn't successful.
>
> Probably the internals of the cache change per version, and 10.0 does
> not have the directory you mention. I'd guess at filehistory, but can't
> find confirmation on the net, and I also don't know if that would be
> sufficient. Pity!
>
> Thanks again,
> Wouter
>
> On Wed, 25 Dec 2019 at 15:02, Svata Dedic <garat@...
> <mailto:garat@...>> wrote:
>
>     re. NetBeans, there's a simple test: if you can compile the project
>     (Run
>     -> Clean and Build ... completes OK), but the Editor still shows
>     errors,
>     the IDE's symbol cache may be broken. It happens from time time to
>     time :-/
>     Most of the time, deleting all in your {netbeans-userdir}/var/cache
>     will
>     help, since the cache will be newly built (not updated) from the fresh
>     sources.
>
>     -S.
>
>     Dne 25. 12. 19 v 11:37 whmvd napsal(a):
>      > Thanks to all who chimed in. I am now back in business, but it
>     would be
>      > nice to know what got confused, how it got confused, how I could
>     have
>      > prevented it and even what finally made the problem go away. More
>      > confirmation for self that I am not suited to the world of
>     wizards, IDEs
>      > and what-nots.
>      >
>      > I do know that restarts, a reboot or two, re-configuration of the
>      > classpath, realcleans, cleans, repeated git pulls and more were
>      > involved, and all in all it's bound to happen again. And again.
>     Because
>      > in the end it was just 'try anything, then try anything else,
>     repeat'.
>      >
>      > At least I can go on again, and that's the main thing. And nobody
>     need
>      > worry - I only do the occasional pull, all my development work is
>     done
>      > in my own library outside of JMRI. I will not be a menace, just a
>     bore!
>      >
>      > Thanks again for the suggestions,
>      > Wouter
>      >
>      > On Wed, 25 Dec 2019 at 04:02, Bob Jacobsen <rgj1927@...
>     <mailto:rgj1927@...>
>      > <mailto:rgj1927@... <mailto:rgj1927@...>>> wrote:
>      >
>      >
>      >
>      >      > On Dec 24, 2019, at 10:22 AM, Bob M.
>     <jawhugrps@... <mailto:jawhugrps@...>
>      >     <mailto:jawhugrps@...
>     <mailto:jawhugrps@...>>> wrote:
>      >      >
>      >      > I NEVER had any luck using NetBeans with the "three-sided" Git
>      >     configuration recommended in the JMRI git setup information.
>      >     NetBeans always overrode that git setup, and caused great git
>      >     difficulty.  Instead, I use a command line shell with Git
>      >     functionality and do everything git via command line operations
>      >     instead of via NetBeans.
>      >
>      >     The above is referring to the setup described in “Setting up
>     a Git
>      >     environment for JMRI Developers” on this page:
>      > https://www.jmri.org/help/en/html/doc/Technical/GitFAQ.shtml
>      >
>      >     It has the advantage that the “git pull” and “git push”
>     commands do
>      >     what most people expect.  But it requires a particular setup that
>      >     some Git clients, particularly IDEs, don’t readily do.
>      >
>      >     There are other choices:
>      >
>      >     1) Set up a “github” remote, and have both push and pull for
>     master
>      >     default to your own GitHub repository.
>      >
>      >     In that case, the “git push” command works as expected, but
>     you have
>      >     to do “git pull github” to get the most recent contents.  Without
>      >     the remote, that’ll be pulling from your own repository, which is
>      >     likely to be out of date unless you’ve taken steps to update it.
>      >
>      >     2) Set up a “myGitHubRepo” remote, and have both push and
>     pull for
>      >     master default to the main JMRI GitHub repository.
>      >
>      >     In that case, “git pull” will bring again bring in the most
>     recent
>      >     content from the main JMRI GitHub.  But in this case, “git push”
>      >     will fail for most developers  (Those with push privileges should
>      >     _NOT_ set up this way; it’s too easy to make a mistake) so
>     they’ll
>      >     have to do “git push myGitHubRepo” to push content for PRs.
>      >
>      >
>      >     Neither is as good as the default setup, in the sense of
>      >     convenience. I think (1) is a reasonable alternative to document,
>      >     particularly if i.e. NetBeans really can’t handle the split
>      >     pull/push destinations.
>      >
>      >     Bob
>      >     --
>      >     Bob Jacobsen
>      > rgj1927@... <mailto:rgj1927@...>
>     <mailto:rgj1927@... <mailto:rgj1927@...>>
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>
>
>
>
>




Svata Dedic
 

Dne 25. 12. 19 v 17:31 whmvd napsal(a):
Sorry, my mistake in writing unclearly. I did find the cache, but not the specific bits that I'd need to remove. Imoved aside the whole thing,
Then you mistaked some other directory for cache one.

{userdir}/var/cache (or ~/.cache) never (throughout the NetBeans history) contained any setup, project or configuration data. Even window positions or executed debugger expression evaluations are considered to be 'configuration' and are stored elsewhere (in the {userdir}/config directory}.

-S.

whmvd
 

Ha, well, of all the directories mentioned only the .cache one exists, so that's what I played around with. Ah, never mind. I'm sure it'll happen again, and I can probably get going again when it happens. After all, I now have the experience under my belt!

Kind regards,
Wouter


On Wed, 25 Dec 2019 at 16:50, Svata Dedic <svatopluk.dedic@...> wrote:
Dne 25. 12. 19 v 17:31 whmvd napsal(a):
> Sorry, my mistake in writing unclearly. I did find the cache, but not
> the specific bits that I'd need to remove. Imoved aside the whole thing,

Then you mistaked some other directory for cache one.

{userdir}/var/cache (or ~/.cache) never (throughout the NetBeans
history) contained any setup, project or configuration data. Even window
positions or executed debugger expression evaluations are considered to
be 'configuration' and are stored elsewhere (in the {userdir}/config
directory}.

-S.



George Warner
 

I recently updated to NetBeans 11.1 (from 8.x! Why doesn't "Check for Updates" tell you when there's a new release?!?) because of this very issue… 
NetBeans decided that it couldn't find LayoutEditor… even when I was working in the LayoutEditor (package)?!?
I considered a wipe, clone/download… but I'm behind a 3.5mbps DSL… so I made that "Plan B". ;-)
I switched to the master branch and did a pull ("Fetch Origin" in GitHub desktop)… no good…
Then I tried (crossing fingers) "git fetch upstream;git reset --hard upstream/master;git push origin master --force" (in terminal).
It ran for a minute (or two… 3.5 mbps DSL remember?) and then switched back to my branch and… the problem (what ever it was) went away.
It's been fine ever since.
Hope this helps…

Randall Wood
 

Do note that between releases 8.x and 9.0+ the entire ownership and infrastructure behind NetBeans changed which meant that where 8.x looked for updates could not be updated to tell 8.x installations to look elsewhere.

So I wouldn’t think that failure is the same as this other failure (which Eclipse also sometimes exhibits).

Randall

On Dec 25, 2019, at 17:08, George Warner via Groups.Io <geowar1@...> wrote:

I recently updated to NetBeans 11.1 (from 8.x! Why doesn't "Check for Updates" tell you when there's a new release?!?) because of this very issue… 
NetBeans decided that it couldn't find LayoutEditor… even when I was working in the LayoutEditor (package)?!?
I considered a wipe, clone/download… but I'm behind a 3.5mbps DSL… so I made that "Plan B". ;-)
I switched to the master branch and did a pull ("Fetch Origin" in GitHub desktop)… no good…
Then I tried (crossing fingers) "git fetch upstream;git reset --hard upstream/master;git push origin master --force" (in terminal).
It ran for a minute (or two… 3.5 mbps DSL remember?) and then switched back to my branch and… the problem (what ever it was) went away.
It's been fine ever since.
Hope this helps…

whmvd
 

Well, it helps insofar as I'm now officially not alone with this. So - thank you for your support! :-)

As NOT updating NetBeans also in some convoluted way made the problem go away (for me), it's difficult to ascribe our results to, well, anything, really.

Wouter


On Wed, 25 Dec 2019 at 22:08, George Warner via Groups.Io <geowar1=mac.com@groups.io> wrote:
I recently updated to NetBeans 11.1 (from 8.x! Why doesn't "Check for Updates" tell you when there's a new release?!?) because of this very issue… 
NetBeans decided that it couldn't find LayoutEditor… even when I was working in the LayoutEditor (package)?!?
I considered a wipe, clone/download… but I'm behind a 3.5mbps DSL… so I made that "Plan B". ;-)
I switched to the master branch and did a pull ("Fetch Origin" in GitHub desktop)… no good…
Then I tried (crossing fingers) "git fetch upstream;git reset --hard upstream/master;git push origin master --force" (in terminal).
It ran for a minute (or two… 3.5 mbps DSL remember?) and then switched back to my branch and… the problem (what ever it was) went away.
It's been fine ever since.
Hope this helps…

Andrew Crosland
 

On WIndows, did you manage to setup the desktop for the "three sided" configuration?

I failed and read something that implied the Windows version is deficient in this respect. I have to temporarily change the repo settings to update from upstream then change them back to mush to my own remote.

Andrew

------ Original Message ------
From: "danielb987" <db123@...>
Sent: 24/12/2019 19:24:16
Subject: Re: [jmri-developers] Fighting NetBeans

I use the GitHub Desktop application on both Windows and Linux and it works fine.

GitHub Desktop lets you use git with a graphical user interface. 

Daniel


--
Andrew Crosland

whmvd
 

Thanks for trying, Andrew. My use is very elementary, and the three-sided configuration is (I am assuming, so every chance of error here) overdone. All I ever do is pull from master. That may change at some point in the future, but I'm not expecting it to. Certainly not anytime soon.

The good news for me is that Windows-related problems no longer matter, as I'm on Linux and loving it!

Wouter


On Fri, 27 Dec 2019 at 17:50, Andrew Crosland <andrew@...> wrote:
On WIndows, did you manage to setup the desktop for the "three sided" configuration?

I failed and read something that implied the Windows version is deficient in this respect. I have to temporarily change the repo settings to update from upstream then change them back to mush to my own remote.

Andrew

------ Original Message ------
From: "danielb987" <db123@...>
Sent: 24/12/2019 19:24:16
Subject: Re: [jmri-developers] Fighting NetBeans

I use the GitHub Desktop application on both Windows and Linux and it works fine.

GitHub Desktop lets you use git with a graphical user interface. 

Daniel


--
Andrew Crosland

danielb987
 

Yes.

1) I go to github.com and fork the JMRI repository to my GitHub account.
2) I start GitHub Desktop and clone my forked JMRI repository.
3) I select the Master branch and then merge upstream/master into my master branch if it's not up to date.
4) I create a new branch for the work I'm about to do.
5) I do the commits I want and push them to my repository
6) I then go to github.org and create a PR.

This works fine for me.

Note that I don't let GitHub desktop clone the https://github.com/JMRI/JMRI but the https://github.com/danielb987/JMRI repository.

I don't use GitHub Desktop to create PR:s. It may work, but I haven't tested it. I always use the github.com web site to create PR:s.

Daniel

2019-12-27 18:50 skrev Andrew Crosland:

On WIndows, did you manage to setup the desktop for the "three sided"
configuration?
I failed and read something that implied the Windows version is
deficient in this respect. I have to temporarily change the repo
settings to update from upstream then change them back to mush to my
own remote.
Andrew
------ Original Message ------
From: "danielb987" <db123@...>
To: jmri@jmri-developers.groups.io
Sent: 24/12/2019 19:24:16
Subject: Re: [jmri-developers] Fighting NetBeans

I use the GitHub Desktop application on both Windows and Linux and
it works fine.
GitHub Desktop lets you use git with a graphical user interface.
Daniel
--
Andrew Crosland
Links:
------
[1] https://jmri-developers.groups.io/g/jmri/message/2424
[2] https://groups.io/mt/69252398/1303822
[3] https://jmri-developers.groups.io/g/jmri/post
[4] https://jmri-developers.groups.io/g/jmri/editsub/1303822
[5] https://jmri-developers.groups.io/g/jmri/leave/defanged

Bob Jacobsen
 

Do you do all those steps every time?

Bob

On Dec 27, 2019, at 1:34 PM, danielb987 <db123@...> wrote:

Yes.

1) I go to github.com and fork the JMRI repository to my GitHub account.
2) I start GitHub Desktop and clone my forked JMRI repository.
3) I select the Master branch and then merge upstream/master into my master branch if it's not up to date.
4) I create a new branch for the work I'm about to do.
5) I do the commits I want and push them to my repository
6) I then go to github.org and create a PR.

This works fine for me.

Note that I don't let GitHub desktop clone the https://github.com/JMRI/JMRI but the https://github.com/danielb987/JMRI repository.

I don't use GitHub Desktop to create PR:s. It may work, but I haven't tested it. I always use the github.com web site to create PR:s.

Daniel

2019-12-27 18:50 skrev Andrew Crosland:
On WIndows, did you manage to setup the desktop for the "three sided"
configuration?
I failed and read something that implied the Windows version is
deficient in this respect. I have to temporarily change the repo
settings to update from upstream then change them back to mush to my
own remote.
Andrew
------ Original Message ------
From: "danielb987" <db123@...>
To: jmri@jmri-developers.groups.io
Sent: 24/12/2019 19:24:16
Subject: Re: [jmri-developers] Fighting NetBeans
I use the GitHub Desktop application on both Windows and Linux and
it works fine.
GitHub Desktop lets you use git with a graphical user interface.
Daniel
--
Andrew Crosland
Links:
------
[1] https://jmri-developers.groups.io/g/jmri/message/2424
[2] https://groups.io/mt/69252398/1303822
[3] https://jmri-developers.groups.io/g/jmri/post
[4] https://jmri-developers.groups.io/g/jmri/editsub/1303822
[5] https://jmri-developers.groups.io/g/jmri/leave/defanged

--
Bob Jacobsen
@BobJacobsen

Randall Wood
 

I follow that process, but start at step 3 after the initial cloning (unless I am for some reason creating another clone—I currently have four clones of the repo on my laptop so I can use non-git aware programs to diff things, or compare the behavior of builds from different branches in different forks).

I do start PRs from with the GitHub Desktop application—it merely opens the website’s create PR page with the correct branches already selected.

Randall

On Dec 27, 2019, at 15:42, Bob Jacobsen <@BobJacobsen> wrote:

Do you do all those steps every time?

Bob

On Dec 27, 2019, at 1:34 PM, danielb987 <db123@...> wrote:

Yes.

1) I go to github.com and fork the JMRI repository to my GitHub account.
2) I start GitHub Desktop and clone my forked JMRI repository.
3) I select the Master branch and then merge upstream/master into my master branch if it's not up to date.
4) I create a new branch for the work I'm about to do.
5) I do the commits I want and push them to my repository
6) I then go to github.org and create a PR.

This works fine for me.

Note that I don't let GitHub desktop clone the https://github.com/JMRI/JMRI but the https://github.com/danielb987/JMRI repository.

I don't use GitHub Desktop to create PR:s. It may work, but I haven't tested it. I always use the github.com web site to create PR:s.

Daniel

2019-12-27 18:50 skrev Andrew Crosland:
On WIndows, did you manage to setup the desktop for the "three sided"
configuration?
I failed and read something that implied the Windows version is
deficient in this respect. I have to temporarily change the repo
settings to update from upstream then change them back to mush to my
own remote.
Andrew
------ Original Message ------
From: "danielb987" <db123@...>
To: jmri@jmri-developers.groups.io
Sent: 24/12/2019 19:24:16
Subject: Re: [jmri-developers] Fighting NetBeans
I use the GitHub Desktop application on both Windows and Linux and
it works fine.
GitHub Desktop lets you use git with a graphical user interface.
Daniel
--
Andrew Crosland
Links:
------
[1] https://jmri-developers.groups.io/g/jmri/message/2424
[2] https://groups.io/mt/69252398/1303822
[3] https://jmri-developers.groups.io/g/jmri/post
[4] https://jmri-developers.groups.io/g/jmri/editsub/1303822
[5] https://jmri-developers.groups.io/g/jmri/leave/defanged

--
Bob Jacobsen
@BobJacobsen





Bob Jacobsen
 

The reason for the recommended triangle setup is that it makes it hard to make update master and still be out of date: `git fetch` and `git pull` automatically get the lastest and greatest from the JMRI/JMRI repository.

The 1-6 process, at least as I understand it,does that too because it makes a new fork each time, then clones that onto the local machine, But 1-6 have to be done _each_ time to get the latest JMRI/JMRI content. I don’t know of a convenient way on the GitHub web pages to update a repository from it’s upstream (it can be done with a PR, but that’s way to easy to mess up and inconvenient)

Bob


On Dec 27, 2019, at 3:10 PM, Randall Wood via Groups.Io <rhwood=mac.com@groups.io> wrote:

I follow that process, but start at step 3 after the initial cloning (unless I am for some reason creating another clone—I currently have four clones of the repo on my laptop so I can use non-git aware programs to diff things, or compare the behavior of builds from different branches in different forks).

I do start PRs from with the GitHub Desktop application—it merely opens the website’s create PR page with the correct branches already selected.

Randall
On Dec 27, 2019, at 15:42, Bob Jacobsen <@BobJacobsen> wrote:

Do you do all those steps every time?

Bob

On Dec 27, 2019, at 1:34 PM, danielb987 <db123@...> wrote:

Yes.

1) I go to github.com and fork the JMRI repository to my GitHub account.
2) I start GitHub Desktop and clone my forked JMRI repository.
3) I select the Master branch and then merge upstream/master into my master branch if it's not up to date.
4) I create a new branch for the work I'm about to do.
5) I do the commits I want and push them to my repository
6) I then go to github.org and create a PR.

This works fine for me.

Note that I don't let GitHub desktop clone the https://github.com/JMRI/JMRI but the https://github.com/danielb987/JMRI repository.

I don't use GitHub Desktop to create PR:s. It may work, but I haven't tested it. I always use the github.com web site to create PR:s.

Daniel

2019-12-27 18:50 skrev Andrew Crosland:
On WIndows, did you manage to setup the desktop for the "three sided"
configuration?
I failed and read something that implied the Windows version is
deficient in this respect. I have to temporarily change the repo
settings to update from upstream then change them back to mush to my
own remote.
Andrew
------ Original Message ------
From: "danielb987" <db123@...>
To: jmri@jmri-developers.groups.io
Sent: 24/12/2019 19:24:16
Subject: Re: [jmri-developers] Fighting NetBeans
I use the GitHub Desktop application on both Windows and Linux and
it works fine.
GitHub Desktop lets you use git with a graphical user interface.
Daniel
--
Andrew Crosland
Links:
------
[1] https://jmri-developers.groups.io/g/jmri/message/2424
[2] https://groups.io/mt/69252398/1303822
[3] https://jmri-developers.groups.io/g/jmri/post
[4] https://jmri-developers.groups.io/g/jmri/editsub/1303822
[5] https://jmri-developers.groups.io/g/jmri/leave/defanged

--
Bob Jacobsen
@BobJacobsen







--
Bob Jacobsen
@BobJacobsen