The new Android version, so far called ‘L’ and most likely winding up being called Lollipop when it will be released, has a new visual style called Material Design.
For Android this change of visual style means that the code base also needs to service both old API deployments (lower than v20) as well as the new ones (v21 and upwards). In effect this means you have to create
res/values-v21 directories to customize the layout and modify the styles for the new API.
In your module’s
build.gradle you have to change the
'android-L' and the
'L'. If you have any dependencies on support-v4 or appcompat-v7 you need to switch those to v21.+ to pick up future updates, such as a different release candidates up to the released version.
I have previously written on this subject, but now I am using IntelliJ IDEA 13 with the latest Android SDK of this writing (September 2014) and when you create a project you might be greeted by an error message like the following:
Error:Gradle: A problem occurred configuring project ':projectname'.
> Could not resolve all dependencies for configuration ':projectname:_debugCompile'.
> Could not find any version that matches com.android.support:support-v4:0.0.+.
> Could not find any version that matches com.android.support:appcompat-v7:19.+.
The Android SDK has switched over to Gradle since I last wrote about it. In this case the default setup already searches the local
libs directory under
Projectname/projectname for any jars to compile with the build of the application. But if you would follow the instructions from my previous post the chance is high that you keep running into this problem. Aside from the installation of the
Android Support Library, you will also need to install the
Android Support Repository in order to make dependency resolution work. Do verify that your
Projectname/local.properties contains a set property for
sdk.dir that points to the root of your locally installed Android SDK.
Now, you might still run into problems. The thing is that in your
Projectname/projectname/build.gradle you generally want to have the compile lines for
appcompat-v7 match the version of your
targetSdkVersion. So this might become:
compile fileTree(dir: 'libs', include: ['*.jar'])
These numbers can be found in the SDK under
extras/android/m2repository/com/android/support under the respective entries for
support-v4. If you would use
+ for the version identifier, you run the chance of picking up the latest version, including release candidates and this might break your build. So in this case being explicit is better than depending on it implictly.
Edit: On second thought, it might be better to use 20.+ or 20.0.+ for the version identifier in order to automatically pick up bugfix releases down the line. Looking at the release notes of the support library it seems that Google is quite strict in sticking to semantic versioning.
In an earlier post I documented how to set up an encrypted file store for your keyring. With recent versions of Python keyring (at least 3 and up) the
CryptedFileKeyring backend got removed and replaced by
EncryptedKeyring. So in your
$HOME/.local/share/python_keyring/keyringrc.cfg you need to now have the following:
If PyCharm complains that it
Can't start Mercurial: /usr/bin/hg Probably the path to hg executable is not valid, then check if running hg from the command line triggers a problem running a certain extension. In my case I had a version of
mercurial_keyring that did not play nice with each other. After upgrading these to 3.0.5 and 0.6.0 respectively, the problem went away. I guess PyCharm tests the run of the hg binary and if the shell return code (
echo $?) is something other than 0 will show this warning.
If you are doing Selenium testing using Chromedriver2 0.8 and are having problems with self-signed SSL certificates, this is a known problem and will be fixed in a subsequent release. In the meantime I found that using the Chromedriver 26.0.1383.0 still worked without problems for Chrome 27 and also did not have this SSL certificate regression in it.
Mercurial allows for tying in keyring configuration for those of us who do not want to store passwords in plain-text in our
.hgrc files or constantly using SSH.
First install the Python keyring library by running
pip install keyring. After that is installed, checkout https://bitbucket.org/Mekk/mercurial_keyring/ and add to
$HOME/.hgrc the following:
mercurial_keyring = ~/path/to/mercurial_keyring/mercurial_keyring.py
Next up, configure your repositories, e.g. in the case of Bitbucket I use:
bitbucket.prefix = bitbucket.org/asmodai
bitbucket.username = asmodai
bitbucket.schemes = https
Mercurial keyring will automatically decide on the best keyring to use. On a FreeBSD system with no Gnome or other systems providing a keyring, if you do not specify a specific keyring, the system will use the file
~/.local/share/python_keyring/keyring_pass.cfg. This keyring file stores the passwords encoded in Base64 in plain-text. This is not quite what you would want from a security point of view. You can configure which backend store to use by editing
$HOME/.local/share/python-keyring/keyringrc.cfg. To get a plain-text file with encrypted keys use the following configuration:
This will create the file
~/.local/share/python-keyring/crypted_pass.cfg after initializing the backend store with a password. Look at the documentation for keyring on what other configuration options are available.
Note: make sure the PyCrypto dependency is installed with the
_fastmath module. This in turn depends on the
If you have a Subversion repository setup with multiple top-level projects and their typical branches/tags/trunk setup and want to migrate these to individual Mercurial (Hg) repositories, you can do this with the convert extension.
First you need to enable convert in your
.hgrc by adding a section like the following:
Next, if needed, create a plain-text file, e.g. author-map.txt, containing SVN username to Hg author mappings, e.g.
asmodai=Jeroen Ruigrok van der Werven <firstname.lastname@example.org>.
Next run Hg as follows:
hg --authors author-map.txt --config convert.svn.branches=project/branches --config convert.svn.tags=project/tags --config convert.svn.trunk=project/trunk path/to/svn/repository path/to/destination/hg/repository
This will start a SVN to Hg conversion, picking up only the changes and commit messages applicable for the various paths you gave for the branches, tags, and trunk, effectively splitting off this project from the main SVN tree into its own Hg repository.
Do note that for large SVN repositories this might not be the most efficient conversion way forward. In that case converting once from SVN to Hg and then split off Hg into many Hg repositories might be faster. Will adjust this post when I write that up.
I was playing around with Eclipse and TestNG, the thing you need/want to do is, after you have installed testng via de Eclipse market place and restart Eclipse to go to the project build path.
So right click the project and select from the popup menu
Build Path » Configure Build Path...
In this window, make sure you have selected the
Libraries tab in the right-hand side of the window.
Add Library... and from the resulting window that pops up select TestNG (or JUnit).
When you select
Finish (depending whether you picked TestNG or JUnit), you will then see TestNG under the JRE System Library entry as another library entry. If you expand this you see the
testng.jar being included and pointing to the right jar file that’s in Eclipse’s plugins directory.
When you now press
OK you should see the imports getting resolved.
You will need to remove any external jar dependencies for TestNG or JUnit of course, because it’s double and will most likely lead to problems.
Now, when you go to
Run » Run Configurations... you see a
TestNG (JUnit) entry. When you select that entry and create a new configuration underneath it, it should already resolve everything you need (classes, packages, and so on).
Oh, do keep in mind that you will have to mark the
test folder as a source folder for it all to work. Right click the folder, select
Build Path » Use as Source Folder.
Having resolved recent SSL certificate issues with Mercurial/TortoiseHG, I now encountered a similar issue with the wildcard certificate for
*.google.com where getting a clone would result in a
"SSL: Server certificate verify failed" error.
One way around this issue is to add the fingerprint for this certificate to your configuration. Currently for
*.google.com this is
00:d5:88:35:29:b9:7f:03:92:60:c2:04:e4:b7:01:f0:07:53:15:a8 and one way to get this from a Unix command line is with
openssl s_client -connect code.google.com:443 < /dev/null 2> /dev/null | openssl x509 -in cert-code -fingerprint -noout -in /dev/stdin | tr "[:upper:]" "[:lower:]". This corresponds with Chrome’s certificate view’s thumbprint field, you just need to add colons.
Right click in Explorer, select
TortoiseHG » Global Settings and then click
Edit File and add the following:
code.google.com = 00:d5:88:35:29:b9:7f:03:92:60:c2:04:e4:b7:01:f0:07:53:15:a8
This should make Mercurial/TortoiseHG work, at least until the certificate expires and you need to update it with the latest fingerprint.
For my own development I use Mercurial and TortoiseHG for my version control system. I also use, at the moment, a CAcert certificate to use HTTPS with my repositories. I am not sure what changed when, but apparently the certificates now get verified. So this causes obvious problems trying to push or pull due to
"SSL: Server certificate verify failed" errors.
To make this work on a Windows 7 machine with TortoiseHG in stalled, first download the CAcert root PEM certificate and place it some permanent directory. Next open the TortoiseHG global settings (right click somewhere in Explorer and select
TortoiseHG » Global Settings). In the window that opens click the Edit File button. If it does not exist yet create a section similar to this:
cacerts = C:\path\to\cacert-root.pem
OK and any push and pull action with HTTPS URLs should work as they ought to.