I'm about to backup my (Linux) home directory, and in the process of culling some of the larger files/subdirectories whose contents I dont need (e.g. .cache, .ccache etc.) - I noticed I have a pretty sizable .gradle subdirectory.
I very rarely use the gradle build tool, but I must have used it for something a couple of years back. My question: Is there important information/settings in a user's .gradle folder, or is it basically just cached dependencies / gradle's own auto-downloaded data?
From the docs:
https://docs.gradle.org/current/userguide/directory_layout.html#dir:gradle_user_home
The Gradle user home directory ($USER_HOME/.gradle by default) is used to store global configuration properties and initialization scripts as well as caches and log files.
Generally, locally it does not matter. However, more advanced use cases (CI/CD) allow you to share or even relocate certain caches: https://docs.gradle.org/current/userguide/build_cache.html
The only notable item of importance is a global gradle.properties file you may have created. If you did, it would be located at $GRADLE_USER_HOME/gradle.properties where GRADLE_USER_HOME by default is $USER_HOME/.gradle. If there any credentials in there you do not have saved else where, considering backing those up.
Otherwise, it is safe to delete. Granted you do not mind having to redownload dependencies etc. again.
Related
I have a simple question: what is "C:\Users\\%USERNAME%\\.gradle" folder used for?
I need to know whether it's safe to remove the folder without any unwanted consequences, I'd also like to know what information is stored in this folder.
From Gradle Docs:
The Gradle user home directory ($USER_HOME/.gradle by default) is used to store global configuration properties and initialization scripts as well as caches and log files
If you don't use Gradle for development, then there is probably something else on your system that does. I wouldn't recommend deleting it, but feel free to check it out yourself. Here's what it should look like: directory structure.
If you are unsure of whether you are using Gradle inadvertently, which I think is more likely than something else using it completely by itself, I suggest checking out the tools you are using to develop (If you are developing Java, this is a common tool).
You may have Gradle installed because of Android Studio
we have an old jar loaded instead of the correct jar. this was a temperory issue and when we restarted the server it picked the correct jar, so I was searching for what might be the cause of this, and I found that there are two places tmp/_WL_user and /AdminServer/tmp they contain copies of application jars. can someone explain the purpose of these two locations and when WebLogic loads the jars from them?
These are temporary application directories. Normally, these files and directories are deleted automatically when no longer needed. However, it is possible to delete them manually to save disk space. Please bear in mind that WLS should be STOPPED prior to deleting these files.
The /tmp/WL_user is actually the cache of your Admin/managed server. In case you accidentally delete the actual jar/war/ear file, your application will still run even if you do a restart of the server. It will only look for the actual location of the jar file only when you remove the /tmp/WL_user directory and restart the servers.
Wroth noting if you have staging enabled, you will also find a directory named 'stage'. This is generally enabled in production where you will find another copy of the jar file. I a not sure of the purpose, but this is again to keep another copy of the jar file to avoid any accidental removal from the original source directory.
Hope this clarifies.
There is this new shining Yarn feature called Plug'n'Play.
I would like to know what it does exactly?
I know it's creating a .pnp folder and a .pnp.js file, but does it change anything else on the machine, like a config file somewhere?
Thank you.
I designed and implemented PnP, so I can talk hours about it 🙂
tl;dr: We only write the .pnp.js and .pnp folders (on top of the regular Yarn cache). We don't store configuration anywhere else.
Without Plug'n'Play
When you run yarn install (even without PnP), a few things happen:
If you use the offline mirror feature, we download the tarballs from the registry and store them within the offline mirror folder
Regardless of whether or not you use the offline mirror, we unpack all the tarballs downloaded and store their files in the Yarn cache
We then figure out which files from the cache should be copied into which location in the node_modules
We apply the computed changes (a bunch of rsync operations, basically)
With Plug'n'Play
With PnP, the workflow becomes like this:
No changes, we download the tarballs from the registry in the offline mirror (if enabled)
No changes, we still unpack them into the Yarn cache
We generate a .pnp.js file¹
And that's it. There is no other generated file than the .pnp.js file (and the cache, but it already was there before).
¹ As you mentioned, we also generate a .pnp folder (.yarn as of Yarn 2) in the project. This folder is meant to contain two types of data:
Unplugged packages are packages that must be local to the project. Typically, those are the packages with postinstall scripts (we cannot store them into the cache, as the generated artifacts might be different from a project to another).
Virtual packages, which are symlinks created for each package in your dependency tree that lists peer dependencies. Without going into the details, they are a necessary part of the design, and are required to make require.resolve work as before. Those files don't exist anymore as of Yarn 2 🎉
How does it work?
The .pnp.js file contains information similar to the following:
webpack#1.0.0 -> /cache/webpack-1.0.0/
-> it depends on lodash#1.0.0
lodash#1.0.0 -> /cache/lodash-1.0.0/
-> no dependencies
By having those information, the resolution can correctly infer that when a file within /cache/webpack-1.0.0 makes a require call to lodash, then the required files must be loaded from /cache/lodash-1.0.0. It's a bit more complex in practice (we keep an inverse map for improved perfs, we use relative paths to ensure portability, etc), but the general concept is there.
Bonus round: With Plug'n'Play+Zip loading (Yarn 2)
Bonus: With Yarn 2, we're about to improve this workflow even more. This is what it will look like:
We download the tarballs from the registry and store then into the cache (no more distinction between offline mirror and cache - they are the same)
We generate the same .pnp.js file as before
And that's it! As you can see we don't unpack the packages anymore (instead, we use a Node loader to read them from the package archives at runtime).
Doing this has a very interesting property: if both your cache and .pnp.js files are there, you don't need to run yarn install for your application to work! And to ensure you have those files, you just have to add them to your repository and version them as you would with everything else.²
It's very useful, as you don't need to remember to run yarn install after git rebase, git pull, or git checkout, and your CI systems become faster and stabler as they don't need special setup - just clone your application and it'll just work.
² Before someone mentions it - checking-in binary files within a repository is perfectly fine. The reason why node_modules were a very bad thing to check-in within your repository was because of the exponential number of text files, which was putting a huge strain on Git - technically, but also philosophically as code reviews were made impossible.
In the case I described we don't suffer from the same problem, because the number of files is constrained (exactly one file for each package), and reviewing them is very easy - in fact, it's better in that you can clearly see how many new packages are added to your project by a PR!
It imports only the parts of a package you are going to use, making the bloated node_modules folder much, much leaner.
Think about for example having relative big libraries like lodash or ramda when you use only 4-5 functions from them - how much you could save getting only the actually used minimum.
I believe it is not yet 100% fully stable, but still a nice option to keep on your radar :)
Is it possible to append/remove a ressource file to a binary at execution time?
I have an application written with go, which saves/searches data from a database file, and i would like this database file to be embedded to the binary, and updated by the application itself.
This way the application would be self contained with its database.
Modifying the executable, this is generally a very bad idea.
Several issues pop right into my head, such as:
Does the current user have sufficient permissions?
Is the file locked during execution?
What about multiple running instances of the application?
Even if you manage to do just that, think of what anti-virus and firewall applications will say to it: most when they detect the change will flag the executable and/or contain it, or deny running it, or some may even delete it. Rightfully, as this is what many viruses do: modify existing executables.
Also virus scanner databases maintain reports where files (their contents) are identified based on the hash of their content. Modifying the executable will naturally change the file content hash, thus render the file unknown / suspicious to these databases.
As mentioned, just write / cache data in separate file(s), preferably in user's home folder or in the application folder (next to the executable, optionally in sub-folders). Or make the cache file / folder a changeable option (command line flags).
Technically, this is possible, but this is a bad idea. Your application could be run by users not having write permissions to your binary.
If you're talking about a portable app, your best option might be using a file in the same directory the binary is located, otherwise - use the user's home directory according to the conventions of the OS you're running on. You can use the os/user package to find the home directory.
UPDATE: I missed a layer in the directory structure (the laravel parent folder, specifically). I'm quite embarassed...
I have a Mercurial repository tracking a Laravel project I've built under
IIS 6, with the following directory structure:
inetpub
|--laravel
|--app
|--bootstrap
|--vendor
|--wwwroot
|--Project
|--OtherScript (set to ignore in .hgignore)
I now want to begin work on a second project, and have modified the directory structure accordingly:
inetpub
|--laravel
|--app
|--app2
|--bootstrap
|--bootstrap2
|--vendor
|--wwwroot
|--Project
|--Project2
|--OtherScript (set to ignore in .hgignore)
I've added the "2" folders to the .hgignore for the original repository, but I'm having trouble working out how to set up a separate repository that ignores the original project folders, and will just track the 2s. I thought I could just create a new repository covering inetpub that uses a different .hgignore file, but when I create the repository it automatically references the .hgignore file established for the first repository. I'm presumably missing something, but I'm not sure what. How can I make this work? The project is just starting, so restructuring is entirely viable if that's necessary.
Two repositories residing in the same directory does not work.
There are several options which might suit your needs, though:
a) Use a parent directory in which you organize your projects in sub-directories. This is usually the recommended the standard approach with mercurial; each of the sub-direcoties becomes an independent repository. The parent directory would not contain much, but can be made a separate repository as well, if desired.
b) Use branches for different projects. Switching between projects then requires switching branches in your project.
c) You can extend option (a) and consider using sub-repositories or guest repositories. They come with some rough edges, thus their use will need careful consideration. You can also start with option (a) and convert it to option (c) at any later time. See Subrepository and also the links in the 'Alternatives' section.
As an aid to others fumbling their way to a better understanding of doing this with Sourcetree, here's a quick overview of what I've done based on planetmaker's advice.
Used the "Clone/New" option to created individual new repositories from the app, bootstrap and Project folders (I've determined that there's no point in tracking vendor).
Committed the contents of each of those repositories.
Created a new Project_Repository folder outside of inetpub
Created a new Repository from the Project_Repository folder
With the Project_Repository tab open, selected "Add Subdirectory" from the Repository menu, and selected the app directory.
Repeat 4. for bootstrap and Project
After doing that, I have a current copy of the content of all 3 directories in the Project_Repository folder, along with the appropriate .hg files. I'm optimistic that this will work well for Project2 as well.