In the context of Eclipse Plugin Development, while associating an application with a product, what's the difference between product definition via .product configuration file and via extension? I know that the product configuration file allows one to specify lot of other launching and branding configuration options.
However, in the product configuration file, under Overview tab in Product Definition section there is Product and Application association. One can also associate the application for a product by adding the org.eclipse.core.runtime.products extension.
Editing application value in one DOES NOT update the other. The Run/Debug Configuration uses product/application information from the extension.
What's the purpose of defining specifying application inside the product configuration file if that's not sync'ed with the extension definition?
Related
I use configuration files for all properties of my apps, that is working fine. Running them on cloud hub I would like to have these properties show up in the app settings of the runtime manager (for reviewing or editing the settings "on the fly" without a new deployment).
I know you can overwrite them via the settings, but I would like to see the list of all properties beforehand – like if you don't use configuration files but submit them via the deployment dialog.
Any way to archive this?
In Anypoint Runtime Manager you can only see the properties defined there. Properties files are not inspectable nor visible.
I develop plugin for IntelliJ. How can I modify custom properties for my plugin tests?
For example I want to set idea.max.content.load.filesize property to, say, 100MiB
These are system properties, so java.lang.System#setProperty
Depending on the properties you wish to modify, you may be able to use idea.properties, which contains the "default properties used to run IntelliJ IDEA" (per the link you provided). To modify the file, you go to Help > Edit Custom Properties... (see these steps).
For example, I used this approach to address a problem where my machine's security software was blocking plugins that used IntelliJ's default config directory (C:\Users<user>\AppData...).
This is the Windows OS default Application Data directory and is included in the paths scanned by the security software. By moving my idea.properties file to a different directory (c:/development/idea/caches/), not automatically scanned by the security software, my plugins were no longer blocked.
It's a different use case from what you're describing, but may be an approach worth looking into.
We're making a project that is primarily a Windows Service EXE.
We're using WIX (with heat) to create an installer, that creates the relevant files and registers the EXE with Windows Services.
We've got to the point of implementing the installer upgrade logic, which largely JustWorks(TM) by setting the Version attribute of the Product tag in the .wxs file.
One issue that I can't see how to manage is the config files of the tool.
The tool has various config settings that can be modified from within the tool.
We're using ASP.NET, which has built in settings/config management, and the config settings that get changed are declared as "User" settings. When we run the save the config changes, it creates a secondary config file which overrides the default settings in the primary config file.
The primary config file exists at <installRoot>\MyCustomService.exe.config, and the secondary config file is at <complicated\Path>\vX.Y.Z\user.config.
Where X.Y.Z is the AssemblyInfo version number which is held in sync with the WIX Version number.
When we install a new version, the tool starts looking in a new path for the user.config ... and can't find it. So functionally, installing a new version resets all of the user's configuration :( .
What is the appropriate way to get a WIX upgrade installation to maintain the existing config?
ASP.NET config supports upgrading user settings from one version to the next, using the .Upgrade() method. You're better off using that rather than manage this in the installer.
This question has details on how to manage that: How do you keep user.config settings across different assembly versions in .net?
but the core solution is:
if (Settings.Default.UpgradeRequired)
{
Settings.Default.Upgrade();
Settings.Default.UpgradeRequired = false;
Settings.Default.Save();
}
Having created UpdateRequired as a user property existing only to manage this process
I am creating a plugin using Grail 3 (3.2.11). My plugin needs to access different properties (e.g. URLs) for each environment (e.g. development, staging, production). When writing a Grails application I add the properties to the application.yml file. Where do they go in the plugin? I tried adding them to application.yml of the plugin and that does not work as expected. If I add them to the application.yml file of the application using the plugin they work. But I want the properties to be part of the plugin so each person who uses the plugin does not need to provide the properties. I would expect it to work like message properties. Where a plugin can have message properties and an application can override them by providing the same property in their local application message.properties. What am I not understanding.
In the same conf directory as application.yml you can place a plugin.yml (or plugin.groovy) which should allow you to change the plugin configuration similar to the way its done in the application's config file(s).
I created a new webdesign project, and restarted the Designer, but it does not show when I try to change the web design project. I've checked it contains all the normal directories and files (navpoints, widgets, project.xml, properties.xml, etc). The log file says it's loaded, but when I click on the project name in the designer to change web design project, I see all the other projects but not this one.
If you have a extension project (under the devel directory) and a web design project (under the devel/webdesign directory, and they have the same name, the web design project will not be visible.
A common convention to prevent this is to append the suffix "_t" to the extension project name. For example, you might have the following directory locations:
devel/myproject_t
devel/webdesign/myproject
Keep in mind that these are independent of any github names used for these projects, which could follow this convention, but more commonly follow the convention of a "_webdesign" suffix for the web design project, but no suffix for the extension project.