Anyone knows if feasible to add an icon to deployed toolboxes ?
Mathworks's add-ons do have one, but can't figure out how to set one for custom deployed toolboxes:
I naively tried to manually edit .prj file and copy-paste icon markups as done for 'apptool' deployment but it doesn't work (packaging tool automatically erases added markups and no icon appears):
<deployment-project plugin="plugin.apptool" plugin-version="1.0">
<configuration build-checksum="1265605284" file="C:\MyApp.prj" location="C:\" name="MyApp" target="target.mlapps" target-name="Package App">
<param.appname>MyApp</param.appname>
<param.authnamewatermark>Me</param.authnamewatermark>
<param.email />
<param.company>MyCompany</param.company>
<param.icon>${PROJECT_ROOT}\icon_24.png</param.icon>
<param.icons>
<file>${PROJECT_ROOT}\icon_48.png</file>
<file>${PROJECT_ROOT}\icon_24.png</file>
<file>${PROJECT_ROOT}\icon_16.png</file>
</param.icons>
...
I have a Word add-in defined by a manifest xml file with the following overriding:
<DefaultLocale>en-AU</DefaultLocale>
<DisplayName DefaultValue="[DEV] My Add-in">
<Override Locale="en-au" Value="[en-au] My Add-in" />
<Override Locale="en-ca" Value="[en-ca] My Add-in" />
<Override Locale="en-us" Value="[en-us] My Add-in" />
</DisplayName>
<SupportUrl DefaultValue="url-default">
<Override Locale="en-au" Value="url-au" />
<Override Locale="en-ca" Value="url-ca" />
<Override Locale="en-us" Value="url-us" />
</SupportUrl>
I want to test whether the overriding works when my add-in gets loaded in different regions. However, the add-in somehow always shows en-us config ([en-us] My Add-in and url-us for SupportUrl).
What I have done before re-inserting my dev add-in from shared folder:
pick another region/language/time-zone
cleared my %LOCALAPPDATA%\Microsoft\Office\16.0\Wef\ folder
change language settings in all browser types and clear the cache
change language preference in Word
The only thing US left I can find in my machine is the Window display language (which I have no other option to choose) and the keyboard, but I don't think that's where Word task pane gets locale code from.
I would appreciate if someone could point me to the right place for testing this locale overriding.
When re-adding the Manifest put in a new value or Office seems to cache some of the setting.
Azure Service Fabric applications have an ApplicationParameters folder with XML config files targeting different deployment locations. The settings in these files seem to deal with the number of instances/partitions of the contained actors and services; I have not seen examples of these settings affecting actor or service logic.
Additionally, reliable services and reliable actors can specify a configuration package in the ServiceManifest.xml file, which points to a folder containing a Settings.xml file. You are able to create custom configuration sections in Settings.xml and gain access to them via the service's/actor's ConfigurationPackage through ServiceInitializationParameters.CodePackageActivationContext.GetConfigurationPackageObject(). Unlike the configuration at the application level, these configuration files do not seem to easily target specific deployment locations.
What is the proper way to tailor actor/service logic via configuration files that target deployment locations? For example, if your service is dependent on an external API with different URLs for development vs. production environments, how can these be established easily with config files? If the ApplicationParameters files are the answer, how do you programmatically access this information from the actor or service? If custom sections within the Settings.xml file is the answer, how does the actor/service know which environment it is in?
Take a look at the "Per-environment service configuration settings" section here: Managing application parameters for multiple environments.
In short, you can create a ConfigOverride when importing the service manifest to the application manifest. Suppose that you have the following setting in the Settings.xml for the Stateful1 service:
<Section Name="MyConfigSection">
<Parameter Name="MaxQueueSize" Value="25" />
</Section>
In the application manifest, you would specify the following:
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="Stateful1Pkg" ServiceManifestVersion="1.0.0" />
<ConfigOverrides>
<ConfigOverride Name="Config">
<Settings>
<Section Name="MyConfigSection">
<Parameter Name="MaxQueueSize" Value="[Stateful1_MaxQueueSize]" />
</Section>
</Settings>
</ConfigOverride>
</ConfigOverrides>
</ServiceManifestImport>
You can then specify the application/environment-specific value for MaxQueueSize using application parameters.
I've gotten some weird effects lately, where sometimes when I deploy my CQ application via Maven to my local AEM Server, it would't update correctly.
E.g. when changing something in a dialog of a component, I have to delete the /app/myapp folder in CRX and deploy again to get changes to appear.
I'm also having a hard time reproducing the effect. It happens seemingly in random intervals.
Please check your filter.xml file. This descriptor should contain all the root paths for your application so most probably: /app/myapp, /etc/designs/myapp and maybe couple others.
For more information please check vault documentation (section using filters). This file is used by CQ package manager to install the content.
In previous CQ versions there was a behaviour that filters were almost ignored. Starting from CQ 5.6 if any content path does not match filter.xml regexps it won't be installed. This does not match exactly your issue but kindly check if updating filter.xml file helps.
Here is what I use for our project and has worked flawlessly on AEM6 but should also work perfectly on CQ 5.6. Replace "ourProject" with whatever is appropriate and let me know if you still have issues.
<?xml version="1.0" encoding="UTF-8"?>
<workspaceFilter version="1.0">
<filter root="/apps/ourProject">
<exclude pattern=".*install" />
</filter>
<filter root="/etc/ourProject"/>
<filter root="/etc/designs/ourProject" />
<filter root="/etc/widgets" />
<filter root="/etc/workflows" mode="update"/>
</workspaceFilter>
I'm looking to use Cordova CLI instead of a home grown ant solution for command line management of a phonegap/cordova project. I'm wondering what parts of the directory tree, if any, should not be placed under version control?
It depends on you project and your workflow.
For a lot of projects, the ./www folder would be sufficient as already mentioned, however there are some other folders that could be good to have depending on what aspects of the cli you are using.
Examples:
./merges for platform specific HTML/CSS/JS overrides
./.cordova for cli hooks (like before_build, after_plugin_add, etc)
Plus anything else custom you might want to keep out of ./www during development. For example, I have a ./src folder and the contents are concatenated and added to ./www as part of our build process. Our unit tests are also outside of ./www.
Instead of including a specific folder, I have a .gitignore that keeps build artefacts like ./platforms/* and ./plugins/* out of version control.
2015 - Cordova 5.1.1 answer
After working for some time with a Cordova project from 3.4.0 to 5.1.1, here's my feedback!
My .gitignore file looks like:
*~
**~
platforms/**
plugins/**
The www / .cordova and other folders you need are versionned.
My .cordova folder is currently empty (I used to have some errors when no .cordova folder, maybe it's not the case anymore)
All the plugins and platforms should be registered into the config.xml file.
If you add plugins by command line, use cordova plugin add $pluginName --save --shrinkwrap -> it will add the plugin automatically to config.xml and fix the version number, making the Cordova project easier to share among developers.
Read more about it and about sharing cordova projects, by the feature author.
Having the plugins in config.xml permits the plugins to be installed on other developer computers when they install a platform. Without that they will need to add themselves the plugin.
Somehow the config.xml acts like a package.json for NPM projects. But I still don't know how to handle a new plugin added, as far as I know the plugins are only installed during platform installation, there's no npm insall/update equivalent (but you can uninstall/reinstall the platform).
Here's an example config.xml from my project:
<?xml version='1.0' encoding='utf-8'?>
<widget id="co.xxx" version="0.2.6" xmlns="http://www.w3.org/ns/widgets" xmlns:android="http://schemas.android.com/apk/res/android" xmlns:cdv="http://cordova.apache.org/ns/1.0" xmlns:gap="http://phonegap.com/ns/1.0">
<name>xxx</name>
<description>
Your Knowledge Network
</description>
<author email="info#xxx.co" href="https://xxx.co">
xxx
</author>
<content src="index.html" />
<preference name="permissions" value="none" />
<preference name="StatusBarOverlaysWebView" value="false" />
<preference name="android-minSdkVersion" value="14" />
<preference name="android-targetSdkVersion" value="22" />
<preference name="phonegap-version" value="cli-5.1.1" />
<plugin name="cordova-plugin-device" spec="1.0.1" />
<plugin name="cordova-plugin-console" spec="1.0.1" />
<plugin name="cordova-plugin-whitelist" spec="1.1.0" />
<plugin name="cordova-plugin-crosswalk-webview" spec="1.2.0" />
<access origin="*" />
<allow-intent href="*" />
<engine name="browser" spec="^3.6.0" />
<engine name="android" spec="^4.0.2" />
<plugin name="cordova-plugin-statusbar" spec="^1.0.1" />
</widget>
The platforms do not get automatically installed (as far as I know), but at least when an user install the platform, he'll get the right platform version!
Some other people are using Plugman, a tool intended to manage Cordova plugins (not tested yet).
Well what u control is your own choise, although, I would personaly only use version-control on the www folder, since is where all your coding and stored content is ( html, css, js, images, audio, etc ), all the rest will be static content (in most of the cases)
Unfortunately I can't add only a comment, so here's my reply for #blockhead and Sebastien Lorber:
It is not necessary to save files from folder 'platform' even file 'AndroidManifest.xml' (or any configuration file for other platform). You can specify your preferences in 'config.xml' and it will affects these generated platform specific configuration files (e.g. AndroidManifest) - see phonegap documentation.
Then you can have under version control only folder 'www' and file 'config.xml'.
If anyone wants to code of Cordova CLI android platform centered (Android Hybrid complex project) into subversion then these files can be excluded while developing with team:
// to exclude files into repo
.gitignore
.gradle
.idea
local.properties
android.iml
/build
/gradlew
/gradlew.bat
/gradle
CordovaLib/CordovaLib.iml
If anyone is having problems with an svn error while import project of Gradle option from disk only not inbuilt subversion client of android studio then the following link will be helpful to you:
https://stackoverflow.com/a/34633162/5287727
I have been a cordova dev since v2.9 and the typical advice of excluding the platform and plugin folders works most of the time.... except for when it doesn't.
I have noticed on a project that feels like it uses every plugin known to man that this mantra has broken down, and I am unable to easily go back and forth in version control and reliably produce a new build.
This is for a few reasons:
Apple changes things up, and as time goes along there are a number of cordova hacks that need to be added to a project to get it to be reliable. For example, iOS 10 added a requirement that if you use the camera, then you needed to specify what you were using it for - or the app would crash when you tried. While I was waiting for the camera plugin to fix this, I needed to edit the iOS source files, then some time later I needed to build an old version, and in crept the issues.
But the real pain is when plugins stray from the cordova way of doing things. This project I am referring to uses the Adobe Aviary / Image editing SDK. Their instructions are to install the plugin, copy over some sdk files downloaded separately, then install it again. I tried making a script that wouldn't kill it, but it has ended up just being that I now commit the plugins and platforms directory to the app - this way I can go back in time and reliably recreate a build.
Yes it adds more size to source control, yes I would love to do it "right", but it has bitten me hard. Just my $0.02
TL/DR - When you starting working with more than a couple of plugins, you might need to consider adding the platforms and plugins folder to source control
Update 2019-11-05
For the project I was referencing we have since made a commitment to just use things that integrate correctly, and now I believe it is better to not check platforms into source control at all. If the plugin doesn't work, the client should not be using it.
Cordova has also moved away from providing an upgrade path for platforms, instead requiring you to remove and add the platform again - this means that this workflow is the only way forward in my opinion.