I'm building an Atom plugin and I need to download executable files according to the OS I'm running on. Is there a good practice of where to store such files?
Related
I'm using Goland version 2021.1 on a mac, and recently I've noticed when searching for files, symbols, or types (using command+shift+o), it doesn't index across my entire project. For example, if I have two files A.txt in two different directories, the file search will only show one of them.
Has anyone encountered this?
It's a known issue, please see IDEA-266391. You can download Toolbox App and install the Nightly build of GoLand.
As another workaround, you can invalidate caches via File | Invalidate Caches.
Trying to build an installer using Excelsior JET
I am trying to create an installer for Eclipse RCP application product.
My product is working fine only concern is when i try to make windows installer (using Excelsior JET and install creator) the database does not update.
I didn't look at the tutorial (since it is flash), but is the problem that the MSI does not overwrite an existing database file on installation? If so, this normally has to do with MSI's default file versioning rules - and how it will preserve modified, unversioned files - in essence non-versioned files that have different create and modify date stamps. This issue is a common confusion associated with MSI deployments.
I will check back to see if this is the problem. In the mean time, here is a link to an answer describing ways to deploy data files and per-user files and settings: Create folder and file on Current user profile, from Admin Profile. You might want to install a read-only database file to a per-machine location, and then copy it to the user profile upon application launch.
I'm just starting work on a website which I want to integrate Elasticsearch into. In my development environment, I will need to install ES so that I and other devs can quickly get started with minimum effort.
We're using ASP.NET for the website (so I know all the devs will be running the website on Windows) and Git for source control.
Previously, on a another project, I have followed the installation guide and simply source controlled the following folders in ES:
/bin/
/config/
/lib/
/modules/
please note, the above folders were for ES 2.x so may slightly differ from 5.x
I then created a simple .bat file which devs run when they start working on the project:
cd %~dp0\elastic\bin\
start elasticsearch
cd %~dp0
All the script does is run ES.
However, I wonder if I should even be source controlling these files. Perhaps it would be better if I had a .bat file which would download a fresh copy of ES when a developer starts work?
Just started on the process of converting my app to the windows store.
Having some hard time trying to figure out how to use the desktop app converter when the program comes in a zip package with additional files that needs to be included (Not just the EXE)
What i mean is typically speaking the users would download the zip file from the website and then extract it and run the EXE file. However in that zip file there's things like Drivers and Languages, I suppose i can make an MSI but i wanted to see if this was possible.
Anyone knows a way to just convert the ZIP file using the desktop app converter?
Thank you!
The Desktop App Converter has an option to create a Windows App Package (.appx) from a regular folder. So you just need to unzip your ZIP file and point the DAC at the folder, specifying what EXE should be the entry point: https://learn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-run-desktop-app-converter#no-installer-conversion - note however, that you can't deploy drivers with a Windows App Package (.appx).
Periodically we receive announcements of new maintenance builds of Oxygen XML Editor. It's easy to locate documentation on installing new versions, but I was unable to find any instructions on installing maintenance builds.
In the past I've renamed the downloaded folder, e.g, "17-1", which completely duplicates all the files in Applications (I'm using OS X), then later on deleted the older folders when it seemed safe to do so.
I would like to know the best-practice, most efficient way to routinely install these frequently released maintenance builds.
Since there is no Oxygen installer for OS X (it's just an archive), there is no straightforward way of upgrading (installing in the same folder), like there is for Windows or Linux.
The official upgrade procedure for maintenance builds (it's the same for minor version updates) goes like this:
To upgrade:
For Windows and Linux you can install the new build in the same folder as the previous installation, it will automatically upgrade it.
Before you upgrade, if you have added files or made changes to any of the files from the Oxygen installation folder (especially the frameworks folder), you may want to create a backup of them because they will be overwritten during the upgrade procedure. Custom frameworks will be preserved but we recommend backing them up anyway, just to be safe.
For Mac OS X you will have to either move the old folder from Applications to a different location and put the new version of Oxygen in its place, or install in a different folder. You can then copy any files you may have changed from the old folder (if any) to the new folder.
The Oxygen preferences will be preserved since they are located elsewhere (user home folder).
What I'd like to add is that, if you have custom frameworks and want to keep Oxygen up to date, it's a good idea to keep the custom frameworks in a different folder (from your user home) than the Oxygen installation folder and simply configure Oxygen to load them from that folder (Options > Preferences, Document Type Association > Locations, Additional frameworks directories). This greatly simplifies the upgrade procedure.
Regards,
Adrian
According to a colleague, his way of doing it, FWIW:
I keep all oXygen stuff in the directory /Applications/oxygen
When I get a new oxygen.zip download, I put it there, unzip it, and rename the directory to the oXygen version name. So right now I have
/Applications/oxygen/17.0
I usually compress the previous version and delete the directory for it, but keep the zipfile for a while in case I need to revert to the
old version
I keep the related jarfiles in /Applications/oxygen/lib so that they don't live in the same directory as an oxygen version that might get
upgraded
I create an alias under /Applications named "oxygen" that points to whatever current version of oXygen Editor I'm using (and it needs to
be updated whenever the current directory changes)
I can't accept this as the best answer unless I receive confirmation that this is the ideal method on Mac OS X. If there is another proposed procedure that is conventionally accepted as the best practice, or a definitive answer from an authoritative source, then I will accept that answer.