The various icons and buttons in the Eclipse (Kepler) interface are very, very small on a laptop with a 3200x1800px screen. The red error decoration that appears to indicate errors on files is difficult to see unless my nose a few cm from the screen.
I've played around with adjusting the screen resolution and other settings in the operating system (Windows 8.1), which helps, but results in other applications appearing too large, and even then the Eclipse icons are uncomfortably small. Enlarging the fonts in the Eclipse preferences (window>preferences>Dialog Font) doesn't affect the icon size.
Is there any easy way to force larger icons? Any work arounds (I've used the Magnifier but that's a rather clunky solution)? Should I just buy a magnifying glass and keep it next to my mouse? Maybe someone should make a mouse with a magnifying glass embedded? :)
Thanks.
I struggled with this issue for a little bit too. I noticed a lot of you posted really complicated resolutions but there is a much easier way to do this! Its just a program and you shouldn't have to modify scripts, or install third party tools. The issue is related to High DPI scaling as mentioned above but what I think a lot of you are missing is that you can't directly modify compatibility settings on the launcher itself. The launcher and eclipse are two different programs! You need to browse to the Eclipse.exe and override the High DPI scaling option there. Once set, you can use the launcher as normal. The launcher will hit the executable, launch the eclipse.exe and since you set the compatibility settings on the .exe it will run using those settings. I spent like 10 minutes tracking down where the exe was so if its any help mine was located in: C:\Users\username\AppData\Local\Yatta\Launcher\installations\eclipse-ide-for-java-developers\eclipse.exe
Here is a screen shot of how I set my compatibility settings.
And yes, the icons were super small before adjusting this setting. I tried setting compatibility settings on the launcher itself but it obviously didn't fix the issue. But after setting the override High DPI setting for the eclipse.exe icons are now normal size. Let me know if this works for others!
I figured that one solution would be to run a batch operation on the Eclipse JAR's which contain the icons and double their size. After a bit of tinkering, it worked. Results are pretty good - there's still a few "stubborn" icons which are tiny but most look good.
I put together the code into a small project:
https://github.com/davidglevy/eclipse-icon-enlarger
The project works by:
Iterating over every file in the eclipse base directory (specified in argument line)
If a file is a directory, create a new directory under the present one in the output folder (specified in the argument line)
If a file is a PNG or GIF, double
If a file is another type copy
If a file is a JAR or ZIP, create a target file and process the contents using a similar process:
a. Images are doubled
b. Other files are copied across into the ZipOutputStream as is.
The only problem I've found with this solution is that it really only works once - if you need to download plugins then do so in the original location and re-apply the icon increase batch process.
On the Dell XPS it takes about 5 minutes to run.
Happy for suggestions/improvements but this is really just an adhoc solution while we wait for the Eclipse team to get a fix out.
I found a reference that suggested adding the following to eclipse.ini
-Dswt.enable.autoScale=true
-Dswt.autoScale=200
-Dswt.autoScale.method=nearest
This doubled the size of the icons for me on Windows 10. I am using Eclipse Version: 2020-03 (4.15.0)
Had same problem, to resolve it, create a shortcut of the launcher, right click > properties > compatibility > tick on 'Override high DPI scaling behaviour' and select System Enhanced from the dropdown as shown on pic below. Relaunch eclipse after changes.
For completion I thought I'd add that this issue is solved in Eclipse 4.6 Neon https://www.eclipse.org/downloads/index-developer.php (the current developer version).
The icons look a bit sad (low resolution) but at least they are scaled correctly on my 4k screen.
I'm running on a Dell XPS 15. Rather than stuffing around with resolutions and magnifications and all that, I just did the following:
Right click the launcher icon
Click on "properties"
Select the "compatibility" tab
Choose "Windows XP (Service Pack 3)" for "Run this program in compatibility mode for:".
Everything seems to work fine and the display looks good (if a bit blurry/pixelly). The only difference i can see is that the title bar is in Windows XP style (oh no!!!).
I'm curious to know if this works for others and if anyone comes across any problems.
I found the easiest way was to create a manifest file which forces Windows to scale the application. It is blurry and non-ideal but better than an almost invisible UI! It seems this technique is applicable to any application too.
Create an eclipse.exe.manifest file in the same folder as eclipse.exe and place the following XML within it:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0" processorArchitecture="*"
publicKeyToken="6595b64144ccf1df"
language="*">
</assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.VC90.CRT"
version="9.0.21022.8"
processorArchitecture="amd64"
publicKeyToken="1fc8b3b9a1e18e3b">
</assemblyIdentity>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<ms_windowsSettings:dpiAware xmlns:ms_windowsSettings="http://schemas.microsoft.com/SMI/2005/WindowsSettings">false</ms_windowsSettings:dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>
The best way is to edit the exe manifest with something like resource tuner and add
<application xmlns="urn:schemas-microsoft-com:asm.v3"><windowsSettings><ms_windowsSettings:dpiAware xmlns:ms_windowsSettings="http://schemas.microsoft.com/SMI/2005/WindowsSettings" xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">false</ms_windowsSettings:dpiAware></windowsSettings></application>
after dependency to set the exe as dpi unaware. This way the program will be a little pixelated but it will be in a confortable size.
For anyone seeing this after upgrading their Windows 10 (post April 2018 update), the DPI Scaling Override setting has moved into a dedicated window:
I have looked up solutions for this issue for the last month, but I have not found an ideal solution yet. It seems there should be a way around it, but I just can't find it.
I use a laptop with a 2560x1600 screen with the 200% magnification setting in Windows 8.1 (which makes it looking like a 1280x800 screen but clearer).
Applications that support such "HiDPI" mode look just gorgeous, but the ones that don't (e.g. Eclipse) show tiny icons that are almost unreadable.
I also use an outdated version of Visual Studio. That has not been updated for HiDPI (obviously MS wants me to use a newer version of VS), but it still works kind of ok with HiDPI screens since it just scales things up twice -- the sizes of icons and letters are normal but they look lower-resolution.
After I saw how VS works, I began looking up a way to launch Eclipse in the same mode since it would not be technically very hard to just scale things up like how VS does. I thought there would be an option I could set to launch Eclipse in that mode. I couldn't find it though.
After all, I ended up lowering the screen resolution to 1/4 (from 2560x1600 to 1280x800) with no magnification (from 200% to 100%) and not taking advantage of the high-resolution screen until Eclipse gets updated to support it since I had to do some work, but I am desparately waiting for an answer to this issue.
Best effortless solution is to go for Eclipse Neon. All bugs are fixed as a part of this release. https://bugs.eclipse.org/bugs/show_bug.cgi?id=421383
Have a look at Neon (4.6) M6 - New and Noteworthy, the milestone release contains some automatic scaling for images (e.g. for toolbar).
SWT provides resolution-based auto-scaling
SWT now automatically scales images on high-DPI monitors on Windows
and Linux, similar to the Mac's Retina support on OS X. In the absence
of high-resolution images, SWT will auto-scale the available images to
ensure that SWT-based applications like Eclipse are scaled
proportionately to the resolution of the monitor.
This feature can be disabled on Windows and GTK by setting this VM
argument to false in eclipse.ini or on the command line after -vmargs:
-Dswt.enable.autoScale=false
Auto-scaling cannot be disabled on the Mac as it is provided by the
OS.
Caveats: We're aware that some scaled images look bad at scale factors
less than 200%. This will be improved in M7. Furthermore, we're
working on support for high-DPI images in Platform UI, so that plug-in
providers can add high-DPI icons without doing any code changes.
Or maybe this helps, in Eclipse Mars API for high resolution was added
New APIs have been added to provide support for rendering
high-resolution images on high-DPI monitors. Two constructors have
been added to the Image class. They accept image-provider callbacks
that allow clients to supply resolution-dependent versions of images:
public interface ImageDataProvider {
public ImageData getImageData (int zoom);
}
public interface ImageFileNameProvider {
public String getImagePath (int zoom);
}
Depending on the user's monitor configuration, SWT will request images
with the corresponding zoom level. Here's an example that displays 3
original images, followed by variants whose resolution changes
depending your monitor's resolution: Snippet367.java.
Note that this is just the first step to support high-resolution
images in SWT and Eclipse-based applications. Work is underway to
adopt the new APIs in the platform. Futhermore, more work in SWT is
required to properly support drawing into high-resolution images via
GC.
APIs for high-DPI monitor support
http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2FwhatsNew%2Fplatform_isv_whatsnew.html
The below change works seamlessly.
Quoting from CrazyPenguin's reply
"For those, like me, who found that even on the new Eclipse it wasn't scaled, see here: swt-autoscale-tweaks Basically I added -Dswt.autoScale=quarter to my eclipse.ini file."
-SurfacePro3-
Download and unzip eclipse "32bit Version".
Run on "Windows XP mode".
The compatibility mode for Windows Xp, it's only available for the Eclipse 32 bit version and after running in this compatibility mode the icons and text will be the right size, but blurry because they are scaled from their native resolution to the screen resolution and doing so the quality is lost.
I fixed #Sigh's solution by creating a (Linux) shellscript (.sh) to do something similar. This is very crude, brutal, and requires adoption for your specific system. Use at your own risk. It might break your entire installation. Make backups of the folders before you run this script. Script can be improved.
#!/bin/bash
for J in *.jar
do
echo "Copying $J..."
mkdir -p "/tmp/$J"
cp "$J" "/tmp/$J/"
cd "/tmp/$J"
echo "Extracting $J..."
jar xf "$J"
rm "$J"
echo "Processing images..."
find . -name "*.gif" -exec convert {} -resize 200% {} \;
echo "Compressing $J..."
if [ `ls .[^.]* 2>/dev/null | wc -l` = 0 ]
then
jar cf "$J" *
else
jar cf "$J" * .[!.]*
fi
cd -
mv $J{,-bak}
mv "/tmp/$J/$J" .
rm -rf "/tmp/$J"
echo "Done."
echo ""
done
Run this in /opt/eclipse/plugins and ~/.eclipse/org.eclipse.platform_4.x.x/plugins (or whatever the paths for your installation are). Same issues as with #Sigh's solution: This is a brutal "fix" and breaks after every update or new installation.
Script can be perfected:
Ignore .jar files without /icons/ folder
Only resize images that are 16x16 so you can run this again after every update/installation
Requires imagemagick.
Caveats
It doesn't work on all icons.
Does anyone know where the other assets are or why they aren't resized? Perhaps they are not .gif?
Project Explorer icons are messed up.
Fixes are welcome!
Thank you Sigh David Levy. I could not develop on Eclipse w/out your sol'n.
I had to add a coupla catch (exceptions) to your code to get it to work:
while (srcEntries.hasMoreElements()) {
ZipEntry entry = (ZipEntry) srcEntries.nextElement();
logger.info("Processing zip entry ["+ entry.getName() + "]");
ZipEntry newEntry = new ZipEntry(entry.getName());
try { outStream.putNextEntry(newEntry); }
***catch (Exception e) {
logger.error("error: ", e);
outStream.closeEntry();
continue;*
}**
There is a nice article in JaxEnter for an work around HiDPI for Eclipse
Following solution worked for me
First you need to add this registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\PreferExternalManifest (DWORD) to 1
Next, a manifest file with the same name as the executable must be present in the same folder as the executable. The file is named eclipse.exe.manifest and consists of:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<description>eclipse</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel xmlns:ms_asmv3="urn:schemas-microsoft-com:asm.v3"
level="asInvoker"
ms_asmv3:uiAccess="false">
</requestedExecutionLevel>
</requestedPrivileges>
</security>
</trustInfo>
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<ms_windowsSettings:dpiAware xmlns:ms_windowsSettings="http://schemas.microsoft.com/SMI/2005/WindowsSettings">false</ms_windowsSettings:dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>
you can find more details here
What worked for me at the end was adding the manifest file to the javaw.exe just like Heikki Juntunen said at https://bugs.eclipse.org/bugs/show_bug.cgi?id=421383#c66
The instructions about how to edit the registry and create the manifest file where written by Matthew Cochrane at https://bugs.eclipse.org/bugs/show_bug.cgi?id=421383#c60 and #KItis wrote the instructions here
I put here a copy of that post:
First you need to add this registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\PreferExternalManifest (DWORD) to 1
Next, a manifest file with the same name as the executable must be present in the same folder as the executable. The file is named eclipse.exe.manifest and consists of:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<description>eclipse</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel xmlns:ms_asmv3="urn:schemas-microsoft-com:asm.v3"
level="asInvoker"
ms_asmv3:uiAccess="false">
</requestedExecutionLevel>
</requestedPrivileges>
</security>
</trustInfo>
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<ms_windowsSettings:dpiAware xmlns:ms_windowsSettings="http://schemas.microsoft.com/SMI/2005/WindowsSettings">false</ms_windowsSettings:dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>
If you do not want to install a newer version of eclipse
As mentioned here,
in the eclipse.init file add -Dswt.autoScale=exact after the -vmargs and you are good to go.
Here exact scales the icons to the native zoom.
But you will have to adjust with the blurred and jagged icons.
Here is my solution Inspired by #Sigh's solution (this one doesn't use maven):
https://github.com/gitAmrit/EclipseIconEnlarger/tree/master#eclipseiconenlarger
This works by searching for all images smaller or equal to 16x16px and scaling them up by whatever factor the user wants.
running the utility:
java images.EclipseIconEnlarger eclipseBasePath magnificaitonfactor
eg: java images.EclipseIconEnlarger C:\Users\Amrit\Codes\eclipse 2
eclipseBasePath = path where eclipse.exe is located, for e.g. C:\Users\Amrit\Codes\eclipse magnificationfactor = factor by which the image should be enlarged, for e.g. 2 = double
Here's another command line solution, but this works for Windows.
It requires winrar installed (edit the set winrar line to point to the winrar installation).
It also requires imagemagick to be installed and its path to be added in your commandline.
One last comment is I recommend running this before opening Eclipse for the first time (ie, fresh install). There are icons that get automatically unpacked from jars and saved in eclipse/configuration/org.eclips.osgi/... (potentially among other folders) and editing the .jar file prevents the icon from being resized. You might be able to delete this folder and it might autoextract again, but I can't confirm.
To run, just create a doubler.bat file in your eclipse/plugins directory and it should resize any icon smaller than 32x32 to that proportioned size.
Here's the code:
#echo off
set winrar="C:\Program Files\WinRAR\winrar.exe"
set startpath=%~dp0
::All *.jar in this folder
FOR %%G in (*.jar) do (call :EachJar "%%G")
GOTO :eof
:EachJar
::echo %1
set nameWOQuotes=%~1
mkdir "tmp\%nameWOQuotes%"
::copy "%nameWOQuotes%" "tmp\%nameWOQuotes%.bak" >NUL
%winrar% x -inul "%nameWOQuotes%" *.jpg *.gif *.png *.tif *.tiff "tmp\%nameWOQuotes%\"
::pause
cd "tmp\%nameWOQuotes%"
FOR /R .\ %%H in (*.jpg *.gif *.png *.tif *.tiff) do (
::echo %nameWOQuotes%-%%~nxH >> "%startpath%\output.txt"
identify "%%H" >> "%startpath%\output.txt"
convert "%%H" -resize 32x32^< "%%H" )
%winrar% a -r -u "%startpath%\%nameWOQuotes%" "*"
cd "%startpath%"
rmdir /s /q "tmp\%nameWOQuotes%"
Goto :eof
It creates a file output.txt and inserts all the ORIGINAL images metadata before it is converted, regardless of whether or not it changed size.
I had this problem when I changed my default Windows 10 language from Eng to Italian, with Eclipse being installed when default language was Eng. Reverting Windows language to Eng and rebooting solved the problem. I don’t know what’s happened, Windows rename some folders like C:\Users translating it in your default language (i.e. C:\Utenti) and maybe this is causing problems.
Jae's above solution worked for me. The manifest solution didn't work for me.
Thanks Jae.
Setup:On my windows 8.1 64 bit non tablet laptop I downloaded eclipse 64 bit with jdk 64 bit.
Right mouse click on desktop to access screen resolution and lowered
the screen resolution display from 3000 level to 2048 x 1152.
Click on make text and other items larger or smaller link and
changed it to large 150% instead of extra extra large - 250%.
Logged out and Logged back in.
Restart Eclipse and the icons are now visible even if it is a bit
smaller, but much more legible now.
Has anybody been able to successfully use the Replace dependency filter in the CQ5 Package Manager to uninstall/delete old code? http://dev.day.com/docs/en/crx/current/how_to/package_manager.html
I've recently restructured my directories and I'm trying to find an easy way to uninstall the old branches.
In other words, I am currently working with:
/apps/myproject/old_directory
but want to transition to:
/apps/myproject/new_directory
Like I said, I tried setting the Replace Dependency Filter with the old package name. It appears to be working because it says "Replaces my_packages:oldPackage:1" which is a valid link. However, running the install does nothing to the pre-existing code base.
I realize that I can just uninstall the original package manually, but this will be added to the Package Share, so I'd like to ensure that any current users can just install the upgrade without worrying about unused code.
I'm currently using CQ 5.4
To remove a content branch using a CQ5 package you need a package:
with a filter definition pointing at the content branch to be removed
without any content in that branch
In other words, you can create an empty package with filter definition pointing to areas you want removed. You can do that either on an empty instance, or by manually editing the filter.xml entry to something like:
<?xml version="1.0" encoding="UTF-8"?>
<workspaceFilter version="1.0">
<filter root="/apps/myproject/new_directory"/>
</workspaceFilter>
Installing such package wipes content under the specified path(s). This operation cannot be undone. This works consistently on all CQ5 versions.
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.
To deploy to different azure environments I modify the csdef as part of the compilation step to change the host headers. Doing so requires building the cspkg once for each environment instead of being able to reuse the cspkg and specify different configs for deployment.
I would like to instead modify the csdef file of a cspkg after it has been created, without recompiling. Is that possible, and if so how?
I've done something similar to what you're after to differentiate between test and live environments. First of all you need to create a new .csdef file that you want to use for your alternate settings. This needs to be the complete file as we're just going to swap it out with the original one. Now we need to add this to the cloud project. Right click on the cloud project and select unload project. Right click on it again and select Edit [Name of project]. There's a section that looks a bit like this:
<ItemGroup>
<ServiceConfiguration Include="ServiceConfiguration.Test.cscfg" />
<ServiceDefinition Include="ServiceDefinition.csdef" />
<ServiceConfiguration Include="ServiceConfiguration.cscfg" />
</ItemGroup>
Add a new ServiceDefinition item that points to your newly created file. Now find the following line:
<Import Project="$(CloudExtensionsDir)Microsoft.WindowsAzure.targets" />
Then add this code block, editing the TargeProfile check to be the build configuration you're wanting to use for your alternate and ensuring that it points to your new .csdef file
<Target Name="AfterResolveServiceModel">
<!-- This should be run after it has figured out which definition file to use
but before it's done anything with it. This is all a bit hard coded, but
basically it should remove everything from the SourceServiceDefinition
item and replace it with the one we want if this is a build for test-->
<ItemGroup>
<!-- This is an interesting way of saying remove everything that is in me from me-->
<SourceServiceDefinition Remove="#(SourceServiceDefinition)" />
<TargetServiceDefinition Remove="#(TargetServiceDefinition)" />
</ItemGroup>
<ItemGroup Condition="'$(TargetProfile)' == 'Test'">
<SourceServiceDefinition Include="ServiceDefinition.Test.csdef" />
</ItemGroup>
<ItemGroup Condition="'$(TargetProfile)' != 'Test'">
<SourceServiceDefinition Include="ServiceDefinition.csdef" />
</ItemGroup>
<ItemGroup>
<TargetServiceDefinition Include="#(SourceServiceDefinition->'%(RecursiveDirectory)%(Filename).build%(Extension)')" />
</ItemGroup>
<Message Text="Source Service Definition Changed To Be: #(SourceServiceDefinition)" />
</Target>
To go back to normal, right click on the project and select Reload Project. Now when you build your project, depending on which configuration you use, it will use different .csdef files. It's worth noting that the settings editor in is not aware of your second .csdef file so if you add any new settings through the GUI you will need to add them manually to this alternate version.
If you would want to just have a different CSDEF then you can do it easily by using CSPACK command prompt directly as below:
Open command windows and locate the folder where you have your CSDEF/CSCFG and CSX folder related to your Windows Azure Project
Create multiple CSDEF depend on your minor changes
Be sure to have Windows Azure SDK in path to launch CS* commands
USE CSPACK command and pass parameters to use different CSDEF and Output CSPKG file something similar to as below:
cspack <ProjectName>\ServiceDefinitionOne.csdef /out:ProjectNameSame.csx /out:ProjectOne.cspkg /_AddMoreParams
cspack <ProjectName>\ServiceDefinitionTwo.csdef /out:ProjectNameSame.csx /out:ProjectTwo.cspkg /_AddMoreParams
More about CSPACK: http://msdn.microsoft.com/en-us/library/windowsazure/gg432988.aspx
As far as I know, you can't easily modify the .cspkg after it is created. I guess you probably technically could as the .cspkg is a zip file that follows a certain structure.
The question I'd ask is why? If it is to modify settings like VM role size (since that's defined in the .csdef file), then I think you have a couple of alternative approaches:
Create a seperate Windows Azure deployment project (.csproj) for each variation. Yes, I realize this can be a pain, but it does allow the Visual Studio tooling to work well. The minor pain may be worth it to have the easier to use tool support.
Run a configuration file transformation as part of the build process. Similiar to a web.config transform.
Personally, I go with the different .csproj approach. Mostly because I'm not a config file transformation ninja . . . yet. ;) This was the path of least resistance and it worked pretty well so far.
While looking for a light-weight Scala development environment, I came upon an Scala edit mode for jEdit. I don't know how to put it to use, though. How does one put a new edit mode in jEdit?
All of this can be found inside jEdit's help, Using jEdit -> Writing Edit Modes -> Installing Edit Modes. But, if you are like me, and tried StackOverflow first, here's the short of it.
Place the mode file (in this case, scala.xml) inside the "modes" directory in jEdit home directory -- this can be found through the Utilities menu -- if you want it for all users, or the "modes" directory in user's jEdit's settings diretory -- which can also be found through the Utilities menu -- if the new mode is to be used by only one user.
After that, edit a file "catalog" inside that same directory. It contains a list of supported modes. If you are working on the settings directory, there won't be any examples to use as a reference, but the catalog inside the home directory has plenty.
A settings directory catalog would look like this, for the referenced mode:
<?xml version="1.0"?>
<!DOCTYPE MODES SYSTEM "catalog.dtd">
<MODES>
<!-- Add lines like the following, one for each edit mode you add: -->
<!-- <MODE NAME="foo" FILE="foo.xml" FILE_NAME_GLOB="*.foo" /> -->
<MODE NAME="scala" FILE="scala.xml"
FILE_NAME_GLOB="*.scala" />
</MODES>
May be this JEdit Setup with Scala can help you ?
It refers to a JEdit fully configured to run Scala projects.
http://liftweb.net/images/9/91/Screenshot-jedit.png
You can copy the scala.xml file to $JEDIT_HOME/modes