Clearly the hamcrest Java library has a stable release, but as far as I can tell the hamcrest-php, hamcrest-python and hamcrest-as3 (and presumably others, but those are the ones I care about at the moment) do not; you can only acquire them in source code form. This is, putting it mildly, a bit of a pain when I have to deploy a versioned copy of a library to a production machine.
Does the community around these libraries have any plan to make stable releases of them?
The PHP Hamcrest library is available via PEAR:
pear channel-discover hamcrest.googlecode.com/svn/pear
pear install hamcrest/Hamcrest
While the latest version is 0.3.0, it's very stable, and my company has been using it with PHPUnit since the summer. Once I get some time to commit a few local additions I have been working on, I'll release a 1.0.0 version.
Related
I have one project who need the version 1.0.0 of a visual components library (devExpress). I also have another project who need the version 2.0.0 of the devExpress. Probleme in delphi I can install only one version of the library. How can I handle this ?
To avoid possible source file collisions, installing several different versions of DevExpress VCL controls on a single machine is not supported. However, there are workarounds provided in the How to have several build versions installed on one machine article.
it throws an error while starting that libgtk3 cannot be find.
Is it possible to build an electron app to work on systems with libgtk2?
Actually it would be perfect if AppImage included all nesessary lib dependencies(like fuse for example), even if it would be a big filesize of image.
According to issue #10780 on GitHub, Electron upgraded back in 2017 to Chrome 61, which requires GTK+ 3. Therefore it is not possible to run Electron on a system with only GTK+ 2 installed.
The idea of AppImages is that an application should contain all libraries it needs to run. However, libraries like GTK+ need to integrate deeply into the system (GTK+ requires libXrandr.so, libglib.so, etc. just to name a few) and have a ton of dependencies which would blow the package up. It is therefore pretty difficult to build an app which contains all different dependencies it has (and even imagine having three or more AppImages containing GTK+ and dependencies sitting on your hard drive).
And in the case of GTK+, it is in most use-cases not enough to just install libgtk (any version), because you might want to profit from dependencies which are just "recommended".
The project I've been working on needs to upgrade it's grails version from 2.2.3 to 2.5.1. Needless to say, the project is huge and I am sure there will be lots of issues while upgrading.
What are the precautions needed while upgrading? And what are the changes required in the dependencies below:
dependencies {
runtime 'mysql:mysql-connector-java:5.1.34'
compile ('ar.com.fdvs:DynamicJasper:5.0.0')
compile ('org.apache.poi:poi:3.10-FINAL')
compile ("com.aspose:aspose-words:14.5.0")
compile ("com.aspose:aspose-cells:8.4.2")
}
As well as in plugins below:
plugins {
compile ":aws-sdk:1.6.7"
compile ":export:1.5"
}
You can find the high level changes listed for each major release up to 2.5.0 in the 2.5.1 documentation.
You will need to note all of the features which will change during the upgrade, identify where you are using them and plan how you are going to migrate.
What I usually do when upgrading the Grails version (apart from reading the upgrade sections of the version I'm upgrading to and all in between major versions) is create a new empty application with the new Grails.
And then use a tree compare tool (like meld) and compare all the build and configuration files to see what has changed.
This way you get most of the needed changes without much trouble. You still need to test your application thoroughly. Hopefully you have lots of unit and integration tests to help you with that...
I am using Xcode 4.2.1 and I have this problem running an existing application on the iOS simulator:
svn: The path '.' appears to be part of a Subversion 1.7 or greater
working copy. Please upgrade your Subversion client to use this
working copy.
/Users/me/Library/Developer/Xcode/DerivedData/myproject-dxfzldckuqdmlrghowwkdrbgoigy/Build /Intermediates/myproject.build/Debug-iphonesimulator/MyProject.build/Script-9567AEA113C59633000AA291.sh: No Subversion revision found at /Users/me/Library/Developer/Xcode/DerivedData/myproject-dxfzldckuqdmlrghowwkdrbgoigy/Build/Intermediates/myproject.build/Debug-iphonesimulator/MyProject.build/Script-9567AEA113C59633000AA291.sh line 32.
Building revision
Command /bin/sh failed with exit code 1
I have a Subversion server 1.7.1 installed and also on the client side I upgraded to 1.7.1.
I did a svn upgrade and then I get this error in Xcode.
If I repeat the svn upgrade on the terminal I get the message Can't upgrade '...' as it is not a pre-1.7 working copy directory.
So what is wrong? How an I solve the problem?
Xcode doesn't yet support SVN 1.7. Only 1.6 is supported. In order to fix your problem, you'll need to switch to using an SVN 1.6 compatible working copy.
Since SVN 1.7 client is unable to work with 1.6 working copies at all, you'll need to remove SVN 1.7.x from your client and revert to 1.6. (Or perhaps just adjust your PATH so the SVN 1.6 tools are first.) Once 1.6 is back, delete or move aside your existing working copy and check out a fresh copy with SVN 1.6. Now Xcode should be able to work with your working copy.
Note that you can freely use SVN 1.6 client with an SVN 1.7 server. Some of the newer features won't be available, but it will work. There's no need to downgrade the server or your server-side repositories.
Keep an eye on the Xcode release notes in updates as I'm sure Apple will note when Xcode is capable of using SVN 1.7. When a 1.7 compatible release of Xcode becomes available, it should then be safe to upgrade your client to 1.7 and migrate your working copy again.
There is a post that appears to imply that you can fool XCode into using svn 1.7 client by changing your PATH and setting up a couple of soft links in strategic places. Unfortunately, the post is in Chinese. Fortunately, Google translate and the presence of UNIX commands make it possible to decrypt what the post is saying. I will try it in the next few days, and update the answer if anything useful comes out of this exercise.
EDIT: I tried the steps from the post, and it worked. Here is what I did:
Downloaded and installed svn client 1.7.2 into /opt/subversion
Added /opt/subversion/bin to my PATH in .bash_profile
Created a backup directory /Developer/usr/bin/orig.svn
Moved /Developer/usr/bin/svn* to /Developer/usr/bin/orig.svn
Ran ln -s /opt/subversion/bin/svn* /Developer/usr/bin/
After that I re-started XCode, went to Organizer, and was able to attach a working copy of a checkout created with svn 1.7.2 client. Organizer showed a green dot next to the repository, displayed a list of revisions, etc., so at this point I believe that the trick has worked.
You can download and install a binary package from http://www.wandisco.com/subversion/download#osx
The package will install to /opt/subversion while the xcode version of SVN is installed in /usr/bin. If you prepend /opt/subversion/bin to your path variable, it will be chosen instead of the xcode version.
If you don't want to mess with your path, you can just alias one version or the other. man alias for details.
More and more gems I run into requires building "native extensive", such as RedCloth. Are there tools that are open-source or free that is sufficient to do that? I heard MS Visual Studio also has a free version. Will that be enough to build native extensions?
If you installed Ruby with the RubyInstaller (as you should), then the DevKit has everything you need.
If you use the obsolete MSVC6 builds, then you need to install Microsoft Visual C++ 6.0, because newer versions of MSVC are incompatible. Good luck finding that, though, MSVC6 isn't even from this millenium.