Replies: 13 comments 20 replies
-
|
you could change the cache location via I have some ideas which could reduce the footprint a bit but they have to wait for now since some things have to happen before that. |
Beta Was this translation helpful? Give feedback.
-
|
Hello! I have tried to do as you suggested, but the thing is that my maven index is not in the Netbeans cache directory. I am in Ubuntu 22.04 with an snap installation and the folders structure I have inside my snap Netbeans folder is the following:
As you can see, the cache folder is empty (vacío is Spanish for empty) while the current installation folder, the 76 has the maven index and even several "cache" folders. Is this expected? Or is it a problem in the snap installation? Thanks, |
Beta Was this translation helpful? Give feedback.
-
|
oh snap! Things work differently there. @lkishalmi do you have a tip how to change the cache dir of the snap package? |
Beta Was this translation helpful? Give feedback.
-
|
Changing the cache/userdir is only possible from the from command line works though. |
Beta Was this translation helpful? Give feedback.
-
|
@lkishalmi in theory you can add an extra https://github.com/apache/netbeans/blob/master/nb/ide.launcher/unix/netbeans#L89 |
Beta Was this translation helpful? Give feedback.
-
|
Hello @lkishalmi @neilcsmith-net I have edited the "user" netbeans.conf file that exists in /home/my_user/snap/netbeans/current/etc but its content seems to be ignored. At least, the files still are in the same folder and no new files have appear in the folder I have set in the cachedir. |
Beta Was this translation helpful? Give feedback.
-
|
I had similar problems with NetBeans, in that, it would attempt to download the Maven index, usually, unexpectedly. It seemed to be especially problematic when I just had a pom.xml file within my project. I worked around that by naming my file tec.xml. In direct response to this issue, if the user can disable the Maven usage (I use plain Java Project with Existing Sources and my own Compile-On-Save app), then the user may replace the Maven functionality with a class I wrote to satisfy POM style dependencies. You would use the application DependencyViewer, add in dependencies using Maven format GAV's (Group, Artifact, Version). The program downloads those dependencies, performs checksum verification and then can commit to a chosen directory which you would then use to specify your library .jars in NetBeans and that works for me. The downloaded dependency files are kept in C:\temp or /temp, so you have ready access to the files. Upon completion of the commit to directory operation, you could then delete the files from the temp directory. Note it only downloads the transitive dependencies for the given artifact, not the entire Maven repository, so it should be saving even more space for you. The code is available (with dependencies) in tecreations.ca/java/downloads/release/DependencyViewer.jar. I think the shell command you want is 'java -cp DependencyViewer.jar ca.tecreations.pomdeps.DependencyViewer'. |
Beta Was this translation helpful? Give feedback.
-
|
you can disable indexing completely in the maven settings.
and no, NB is not downloading the maven repository (!), I believe you underestimate how large that would be by a few orders of magnitude :) It is just the index of the repository. |
Beta Was this translation helpful? Give feedback.
-
|
edited, and yeah, you're right, that would be all the dependencies of all artifacts in the Maven repo? |
Beta Was this translation helpful? Give feedback.
-
|
@mbien Just out of curiosity, do you know if there is a simple web service which we could call instead of downloading and digesting the repository index ourselves? |
Beta Was this translation helpful? Give feedback.
-
|
we can use the maven central search for a few things but it is not really designed for that (and its slow). Many queries the IDE uses would not work. See #4971 which augments the current IDE features with the search service for things which are actually not in the index (anymore). I wouldn't want to let a pom editor hint scan through maven files and check for artifact updates using the service, that would be a DDOS attack on it. The local index can serve this instantly. #4999 is also pending but is blocked by the JDK 8 requirement. I do also have some ideas how to reduce the index size by throwing away things we don't need, but that would be blocked by it too so I shelved it for now. NB is also scanning the local repo, which means some features will keep working even when the index download is turned off in the settings - which should be a viable option for everyone with storage problems. |
Beta Was this translation helpful? Give feedback.
-
|
but as general comment: storage is cheap. I just checked and you can get 1TB NVMe drives for 55€. 1TB is a lot (and nvme is fast), I am not sure how big of a problem this actually is, given that the typical computer game these days is probably 40gb large, nv drivers alone are already over 600MB. Having your IDE use up a bit of storage for the cache should be ok. |
Beta Was this translation helpful? Give feedback.
-
|
Well, that's true. Also some advice for Linux users with space problems. Symlink can be a solution. On Ubuntu using ZFS is also a good option... |
Beta Was this translation helpful? Give feedback.
-
|
Good morning all, Thank you for your contributions, it is good to see everyone so involved!! Yes, storage may be cheap, but my computer already has already three disks and no more slots to add another one. Changing one of them for a new bigger disk is a kind heavy task, as I would need to migrate all the content. And the one I have problems with is the system disk, with all the S.O. files, basically I would be reinstalling all my computer. Also, you cannot assume that storage is cheap as a general rule. Netbeans is a world wide used tool, storage can be cheap in your country and not in others. Even, inside of your own country it can be cheap for your standards, but maybe not for other people. Even in the case of storage not being an issue, I think that avoid being inefficient with the use of the resources whenever is possible is something to strive for. In fact, even if my lack of space is making things more critical for me, my initial issue was not really with the size of the Maven Index itself, it was with the fact that each new version of Netbeans that snap installs when the program updates, generates its own folder with duplicate data, including the Maven index. The Maven Index does not change its content for each Netbeans versions, it is the same for all of them, so why each Netbeans version should need their own copy of it? So, for that reason I was asking for a way to configure where my Maven Index is stored, to take it out of the version specific folders and put it in a place where every new Netbeans version can access it. That way it would not be downloaded again each time the program is updated and neither stored more than once. Unless I am wrong, of course, and Netbeans changes how it stores the Maven Index information from one version to other, even if the information itself remains the same. If that is the case... I would have to go back slowly to my own corner to start planning my dreaded computer upgrade... |
Beta Was this translation helpful? Give feedback.
-
|
@cpramirez It isn't as simple as it sounds since there are multiple libraries involved in this, and due to non-technical reasons, we can't update them right now. As workaround you can try several things, some which where already mentioned:
NB 18 will have more options there and handle out-of space situations better: #5646, #5655, for a complete solution we would have to get #4999 in first, which is right now not possible.
this is not an assumption we can simply make since the lucene dependency itself might change between versions and make that index incompatible. Yes this can be solved - but testing this scenario is not fun and I would like to ignore this for now and simply let NB create a fresh index if you update NB itself. If you like to live dangerously, share the cache location with the last NB installation, it will indeed reuse everything - this is not tested. (also as sidenote: I don't use snap for NB so I am not the right person to answer questions about it, I use the zip) as last remark: I am trying to fix/mitigate things here I personally don't even care about. My tmp is configured to have 20GB storage and the home folder will never run out of space. The janitor task NetBeans runs will also clean up stale config and cache files if you don't use them anymore. -> contributions welcome |
Beta Was this translation helpful? Give feedback.
-
|
Hi Laszlo,
At tecreations.ca/java/downloads/release/DependencyViewer.jar is a jar
I've produced. It contains a class,
ca.tecreations.pomdeps.DependencyViewer which will allow you to specify
artifacts in group-artifact-version for Maven-style POM files. I have
been using tec.xml, without any negative NB activity. POM.xml files
cause NB to perform much undesirable activity. Nevertheless, specify a
name.xml file in your project directory, insert all you Maven-style
<dependency> values, save, commit to, with or without Empty...
Include the destination directories for your classpath and code
auto-completion should work.
Note for sources and javadoc, that is a separate issue.
Tim
…On 2023-03-09 2:54 p.m., Laszlo Kishalmi wrote:
@mbien <https://github.com/mbien> Just out of curiosity, do you know
if there is a simple web service which we could call instead of
downloading and digesting the repository index ourselves?
—
Reply to this email directly, view it on GitHub
<#5614 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AV2UYHJN2X6ZVWEQJ5MBMJDW3JGP7ANCNFSM6AAAAAAVRBRV4I>.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Hello,
There is. There is. There is DependencyViewer.jar, look on
tecreations.ca, under java / downloads.
It will. Resolve your POM.xml to C:\temp\, or /temp/, on linux. It first
resolves, then downloads with hash checking, but you can confirm or
report. It will place all listed dependencies into your
'.../projectDir/jars/' path. I use it for Spring projects, so mine is
fairly precise. Not perfect... no, you **may** experience version
shadowing, meaning multiple artifacts, despite it being written with
Eclipse Aether 1.?.? and Maven Resolver 3.8.4.
You may or not experience version shadowing, ie spring.3.0.0 && spring
3.0.1, may conflict, maybe not. It depends on what the author did. For
example, if each version only implements new classes, no conflicts and
multiples are acceptable. If not, then no, only the current version is
acceptable.
It would be nice, yes, if we could programmatically download
**suggested** requirements + **optional** requirements. **Standardized**
requirements, **Springs** and **Mine(Tim's)** requirements.
It really depends on what you are trying to make.
My code is public domain, so far, so you may use, edit, sell, your
modifications.
Tim
…On 2023-03-09 2:54 p.m., Laszlo Kishalmi wrote:
@mbien <https://github.com/mbien> Just out of curiosity, do you know
if there is a simple web service which we could call instead of
downloading and digesting the repository index ourselves?
—
Reply to this email directly, view it on GitHub
<#5614 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AV2UYHJN2X6ZVWEQJ5MBMJDW3JGP7ANCNFSM6AAAAAAVRBRV4I>.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
We can start. I have some software in place. I have a
continuous-integration-based build and deploy system.
You could... Make a note.
Create a round table environment for various developers.
Power players... Governments, Julian Assange, Tim., AI
Everyone, Everywhere, since Tim && Time.
U.
Yours.
EveryoneElse.
Everyone.
Tim
…On 2023-03-13 4:24 p.m., Michael Bien wrote:
@cpramirez <https://github.com/cpramirez> It isn't as simple as it
sounds since there are multiple libraries involved in this, and due to
non-technical reasons, we can't update them right now.
As workaround you can try several things, some which where already
mentioned:
* set NB cache folder location to something you prefer
(netbeans.conf or launcher flag)
* you can also try to set the tmp folder property itself
|-J-Djava.io.tmpdir=/path/to/tmpdir| (I actually never tried that
- curious if something breaks)
* use symlinks and point them to wherever you like
* you can disable indexing if you don't really need it
NB 18 will have more options there and handle out-of space situations
better: #5646 <#5646>, #5655
<#5655>, for a complete
solution we would have to get #4999
<#4999> in first, which is
right now not possible.
The Maven Index does not change its content for each Netbeans
versions, it is the same for all of them,
this is not an assumption we can simply make since the lucene
dependency itself might change between versions and make that index
incompatible. Yes this can be solved - but testing this scenario is
not fun and I would like to ignore this for now and simply let NB
create a fresh index if you update NB itself. If you like to live
dangerously, share the cache location with the last NB installation,
it will indeed reuse everything - this is not tested.
(also as sidenote: I don't use snap for NB so I am not the right
person to answer questions about it, I use the zip)
as last remark: I am trying to fix/mitigate things here I personally
don't even care about. My tmp is configured to have 20GB storage and
the home folder will never run out of space. The janitor task NetBeans
runs will also clean up stale config and cache files if you don't use
them anymore.
-> contributions welcome
—
Reply to this email directly, view it on GitHub
<#5614 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AV2UYHOFMDLAIIUKWJQPKE3W36NAHANCNFSM6AAAAAAVRBRV4I>.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
You can do,..., executable jar.
Do what? Sure.
Code works how?, ok, one path, what about all that can? Tim.
…On 13/03/2023 4:24 p.m., Michael Bien wrote:
@cpramirez <https://github.com/cpramirez> It isn't as simple as it
sounds since there are multiple libraries involved in this, and due to
non-technical reasons, we can't update them right now.
As workaround you can try several things, some which where already
mentioned:
* set NB cache folder location to something you prefer
(netbeans.conf or launcher flag)
* you can also try to set the tmp folder property itself
|-J-Djava.io.tmpdir=/path/to/tmpdir| (I actually never tried that
- curious if something breaks)
* use symlinks and point them to wherever you like
* you can disable indexing if you don't really need it
NB 18 will have more options there and handle out-of space situations
better: #5646 <#5646>, #5655
<#5655>, for a complete
solution we would have to get #4999
<#4999> in first, which is
right now not possible.
The Maven Index does not change its content for each Netbeans
versions, it is the same for all of them,
this is not an assumption we can simply make since the lucene
dependency itself might change between versions and make that index
incompatible. Yes this can be solved - but testing this scenario is
not fun and I would like to ignore this for now and simply let NB
create a fresh index if you update NB itself. If you like to live
dangerously, share the cache location with the last NB installation,
it will indeed reuse everything - this is not tested.
(also as sidenote: I don't use snap for NB so I am not the right
person to answer questions about it, I use the zip)
as last remark: I am trying to fix/mitigate things here I personally
don't even care about. My tmp is configured to have 20GB storage and
the home folder will never run out of space. The janitor task NetBeans
runs will also clean up stale config and cache files if you don't use
them anymore.
-> contributions welcome
—
Reply to this email directly, view it on GitHub
<#5614 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AV2UYHOFMDLAIIUKWJQPKE3W36NAHANCNFSM6AAAAAAVRBRV4I>.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
It's really can I eclipe aether and mavenForTarget? Tim, Maven, Gradle,
Spring?
Maybe not., not we might, ... , tecreations.ca
#Tim, @tim, tecreations/dev/notes.php
tim
…On 13/03/2023 4:24 p.m., Michael Bien wrote:
@cpramirez <https://github.com/cpramirez> It isn't as simple as it
sounds since there are multiple libraries involved in this, and due to
non-technical reasons, we can't update them right now.
As workaround you can try several things, some which where already
mentioned:
* set NB cache folder location to something you prefer
(netbeans.conf or launcher flag)
* you can also try to set the tmp folder property itself
|-J-Djava.io.tmpdir=/path/to/tmpdir| (I actually never tried that
- curious if something breaks)
* use symlinks and point them to wherever you like
* you can disable indexing if you don't really need it
NB 18 will have more options there and handle out-of space situations
better: #5646 <#5646>, #5655
<#5655>, for a complete
solution we would have to get #4999
<#4999> in first, which is
right now not possible.
The Maven Index does not change its content for each Netbeans
versions, it is the same for all of them,
this is not an assumption we can simply make since the lucene
dependency itself might change between versions and make that index
incompatible. Yes this can be solved - but testing this scenario is
not fun and I would like to ignore this for now and simply let NB
create a fresh index if you update NB itself. If you like to live
dangerously, share the cache location with the last NB installation,
it will indeed reuse everything - this is not tested.
(also as sidenote: I don't use snap for NB so I am not the right
person to answer questions about it, I use the zip)
as last remark: I am trying to fix/mitigate things here I personally
don't even care about. My tmp is configured to have 20GB storage and
the home folder will never run out of space. The janitor task NetBeans
runs will also clean up stale config and cache files if you don't use
them anymore.
-> contributions welcome
—
Reply to this email directly, view it on GitHub
<#5614 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AV2UYHOFMDLAIIUKWJQPKE3W36NAHANCNFSM6AAAAAAVRBRV4I>.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Hello, @mbien, I'm tim. So, if I understand correctly, you aren't
advising that someone use tecreations.ca/DependencyViewer?
You would suggest either Maven, with specific settings in NB && 4Gradle,
Can't help yet?
I would say, generate a Maven Style Pom. Include artifacts for
MethodNotFound and everything on which they depend. All my Spring
projects work. There is some code over-shadowing, but that is
negligible. It depends on your perspective. && Tim.
Everyone. Everywhere. AllTheTime.
AI.
Tim
Tim
…On 13/03/2023 4:24 p.m., Michael Bien wrote:
@cpramirez <https://github.com/cpramirez> It isn't as simple as it
sounds since there are multiple libraries involved in this, and due to
non-technical reasons, we can't update them right now.
As workaround you can try several things, some which where already
mentioned:
* set NB cache folder location to something you prefer
(netbeans.conf or launcher flag)
* you can also try to set the tmp folder property itself
|-J-Djava.io.tmpdir=/path/to/tmpdir| (I actually never tried that
- curious if something breaks)
* use symlinks and point them to wherever you like
* you can disable indexing if you don't really need it
NB 18 will have more options there and handle out-of space situations
better: #5646 <#5646>, #5655
<#5655>, for a complete
solution we would have to get #4999
<#4999> in first, which is
right now not possible.
The Maven Index does not change its content for each Netbeans
versions, it is the same for all of them,
this is not an assumption we can simply make since the lucene
dependency itself might change between versions and make that index
incompatible. Yes this can be solved - but testing this scenario is
not fun and I would like to ignore this for now and simply let NB
create a fresh index if you update NB itself. If you like to live
dangerously, share the cache location with the last NB installation,
it will indeed reuse everything - this is not tested.
(also as sidenote: I don't use snap for NB so I am not the right
person to answer questions about it, I use the zip)
as last remark: I am trying to fix/mitigate things here I personally
don't even care about. My tmp is configured to have 20GB storage and
the home folder will never run out of space. The janitor task NetBeans
runs will also clean up stale config and cache files if you don't use
them anymore.
-> contributions welcome
—
Reply to this email directly, view it on GitHub
<#5614 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AV2UYHOFMDLAIIUKWJQPKE3W36NAHANCNFSM6AAAAAAVRBRV4I>.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
This has been an issue for years and still looks unresolved. I have 40GB available space, and still get "no space on your cache" errors. The entire process then restarts, and fails again unless you stop it. Why is it necessary to download an entire maven index? If the maven indexing and unpacking fails you simply cannot run or use a maven based project. The only option for creating a Netbeans Application project is via a maven project. |
Beta Was this translation helpful? Give feedback.
-
|
After an hour of Netbeans downloading and unpacking gigabytes of the index, I cannot see anything like it, under ~/.netbeans/21 All tiny files except for a handful, nothing like petabytes that the index was supposed to expand to, after having taken so long. |
Beta Was this translation helpful? Give feedback.
-
Ah, it failed! Why would it? Seemed to complete successfully and no new error notifications appeared in NB. |
Beta Was this translation helpful? Give feedback.
-
|
Try with |
Beta Was this translation helpful? Give feedback.
-
Regardless of how it was edited to remove gazillions of unnecessary files, the last lines of 4856356 21 That is 7 digits: 4,856,356, and it equals to 4.8 megabytes as in four million eight hundred fifty six thousand three hundred fifty six bytes. Am I still wrong about its magnitude as you are asserting? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it's not bytes. Just try it with |
Beta Was this translation helpful? Give feedback.
-
Ah, cool, thanks! I did not know that |
Beta Was this translation helpful? Give feedback.
-
Good morning everyone,
I am having problems with my computer because I am currently low in disk space and anytime that Netbeans is updated, it needs to re-download the Maven Index (which is big), duplicating it and eating my limited free space.
I am currently solving it by cleaning-up the old version folders manually because I cannot wait until the janitor utility suggest to do it, but it would be really helpful if instead of that I could set it up in a place outside of the Netbeans version specific folders, so any new version of the program can access to it instead of having to re-download it again. Do you any of you know if there is any way to configure that?
I have looked on the usual configuration files, even changed my Maven from the Bundled one to an externally installed version, but so far I have had no luck.
Thanks for your time!
Beta Was this translation helpful? Give feedback.
All reactions