It looks like the SongBeamer site which put up some nice ports for the TurboPower OpenSource projects for Delphi 2009+ are now being outdated with some recent updates in SourceForge. But, then again, maybe not? Which versions are best used with Delphi XE?
I'm most interested in Abbrevia, LockBox, and Async Pro. It looks like Abbrevia-SourceForge, AsynPro-SongBeamer, LockBox..?
I am the "owner" of the Turbopower projects on SourceForge. They are all in various states of development, but the most popular ones are XE ready.
I confess that I don't know the exact state of any individual project, but I can say that SourceForge is the best place to get the most recent and up to date "official" version.
As far as I know, the SourceForge versions of the projects are currently actively being maintained, under the direction of Nick Hodges.
Abbrevia is much better on SourceForge. The SongBeamer version was based on unstable code from mid-2008. I started maintaining the project in 2009 and the official 3.05 stable release had a lot of cleanup and fixes after that. v4.0 was released in March 2011, and added new features, include full support for Unicode filenames in zips, bzip2 archives, and decompression support for most of the new zipx compression algorithms (LZMA, bzip2, PPMd, WavPack). The current Subversion trunk also has Zip64 support and much better splitting/spanning support.
Async Pro appears to be better on SourceForge, but it's a bit of a mix. Officially only a handful of components have been updated to Unicode. In the SourceForge release the admin added $IFDEFs to keep the remaining files from compiling, while on SongBeamer they may still compile but might not be correct. There have been a few releases on SongBeamer since the SourceForge 5.0 release, so there may be some fixes not in the official release, but it's not based on the 5.0 release, so they're both missing stuff.
LockBox 2 is better on SongBeamer. The SourceForge version hasn't been updated with Unicode support at all. The SourceForge site does include a LockBox 3 project that supports Delphi 2007 through Delphi XE, but it's entirely new, incompatible code, so the only thing they share is the name. It is being updated though, unlike LB2.
Orpheus is better on SourceForge and incorporates all of the fixes from SongBeamer.
Office Partner has had a Unicode update posted in the SourceForge project's forums, but doesn't have a maintainer, so it's not official released or in the SVN repository. Not available on SongBeamer.
OnGuard and SysTools are the same on both sites.
ShellShock has Unicode support in the SourceForge Subversion repository.
XML Partner has the SongBeamer code committed to the SourceForge Subversion repository.
TP Essentials is better on SongBeamer.
The rest of the TurboPower projects SourceForge projects are dead.
Stay away from LockBox. Version 2.x in now really outdated (but for very simple cryptography needs), while version 3.x developer has somehow "stolen" the LockBox name, writing another library not compatible, and its quality doesn't look good.
Moreover IMHO he has no rights to change the license, only the Initial Developer - Turbo Power - can relicense under different ones, if he didn't like MPL 1.1 he could have created his own library without taking Turbo Power's Lockbox name and Sourceforge project. Thereby you may end up using a library with an invalid license, especially if you plan to use it under GPL terms.
If you have needs for good cryptography look elsewhere.
The sourceforge version of AsyncPro doesn't add the BCB components either - these seem to have suffered a lot since TP opensourced. I had to build packages for this a couple of times to support various versions of RAD studio. Haven't checked the latest songbeamer build.
Related
I have to update a Delphi XE installation for a project to a newer version of Delphi but I don't have much experience with Delphi, the problem is there are plenty of old packages and components in there.
When I install a new version did I have to install all components again (if it possible to install it in this new version) or is it something like an update to my old installation and all installed stuff is now in the new version also?
Updating a Delphi XE application to a newer Delphi is usually quite easy. The only serious issue could be third party components which you must install in the newer Delphi version. Check with each component vendor that a version exists for your target Delphi version.
I always strongly recommand to NOT use any third party component that has no source available. Also don't buy any third party component using a DLL, OCX or other external binary object.
When you buy a third party component, always buy the source code with it. Then throw away any pre-build package or dcu and recompile everything before any serious use. That way you'll be sure to have all required source code and work with that source code.
Once you have the source code, it becomes much easier to port to the next Delphi version. Usually there is just nothing to change (There was only one notable exception in the past between Delphi 2007 and Delphi 2010 when Unicode string were introduced).
When there is something to change, it is usually only the name of a "used" unit. Somtimes Embarcadero move one class from a unit to another one. Sometimes, you have to change a $IFDEF which specify a Delphi version. Look at {$IFDEF VER180} and similar to adapt to you current version (See the online help for such symbol).
And if you still have issues, then ask here...
Upgrading to newer version of Delphi might not be a trivial task.
First problem you will run into are Thid Party Components.
If you don't own the souce code for them it means that they come with precompiled packages and these packages unfortunately arent compatible between different Delphi versions.
If you do have source code for them you might be able to recompile them on newer Delphi versions but this might require you to do some code changes.
So I strongly recomend you first check to see if there are updated versions of these components available that support the Delphi version to which you are planning to upgrade.
For instance if your application relies on BDE (Borland Database Engine) that shipped with older versions of Delphi you Will be forced to do Quite some changes to properly set up the FireDac database framework that ships with newer delphi versions.
I'm looking at moving from Delphi 2007 (purchased by my employer) to Delphi XE Starter Edition (purchased by me because my employer is moving away from Delphi) for some open source/hobby work. So, price is definitely a concern.
Delphi XE Starter Edition doesn't appear to have the integrated DUnit stuff. Are there any recommendations for testing frameworks that will work well with XE Starter? The framework must be automatible; for example, it must must be runnable by a Continuous Integration System such as Hudson or CruiseControl. Of course, free would be best. Integration directly into the IDE would also be handy, but not a requirement.
DUNIT is on SourceForge so you can get it from there. The version on SF is 9.4.0, the same that ships with Delphi XE. The code is however not identical. I do not know if it works with Delphi XE Starter edition but I don't see why it should not.
Will DUnit2 do?
Dunit2 is used in tiOPF framework and said to be quite good. The download sites are:
http://sourceforge.net/projects/dunit2/
http://members.optusnet.com.au/~mcnabp/
http://github.com/graemeg/dunit2
DUnit may be a better choice that DUnit2. With DUnit you can use the jcl and USE_JEDI_JCL to get the line numbers of failures. DUnit2 doesn't appear to support this.
DUNit2 doesn't seem to be getting much attention since Peter's death either. I don't know if it has been updated to use the latest version of delphi but it doesn't look like it.
Is there a project or project in progress for creating a Mercurial plug in for Delphi XE?
Failing that, where can I learn more about creating one?
Delphi XE has SVN support and the integration is an open source project, you can get it's code from here
I read somewhere that they made it generic so it's not tied for SVN, but they add the SVN support because it's more popular and as starting point.
also as Uwe Schuster blog (who developed the version insight for Delphi XE), both Git or Mercurial support are planned.
Q: Will there be support for Git or
Mercurial? A: Support for both is
planned and first tests have been done
in the past months, but I don’t have a
timeframe. (Remember I do have a full
time job, work on Version Insight in
my free time and it’s not the only
thing)
Which is better source control with NetBeans (Ruby on Rails), VSS or subversion?
I want to use source control, so I want to know which is better for NetBeans (RoR). Visual Source safe or Subversion?
Absolutely Subversion.
I'd explain why, but Jeff Atwood has done a great job already and the blog entry links to other sites with great information.
Avoid VSS like the plague. You are far better off with SVN or Git.
I can give you the recommendation to use Subversion if possible. Even according to Microsoft, SourceSafe is a rather limited version control system. It lacks quite essential features such as transactional commits/revisions, branching and merge support, an easily corrupted database etc.
Alan de Smet has put up a rather long list here:
Visual SourceSafe: Microsoft's Source Destruction System
If you for any reason have to live with VSS make sure that you install all service packs and updates as there are a number of highly critical issues in the RTM version (e.g. this update, updates don't come automatically with Windows update).
Anything but SourceSafe. In all seriousness though, Java-based IDEs such as Netbeans, Eclipse and IDEA usually have the best support for Subversion. It's free, and it's fast, and it's solid.
The Subversion Netbeans module is provided as part of the platform and is more likely to be supported than the VSS one.
I don't think you should let an IDE to decide for you which Source ( Control program to use. If anything, it should be the other way around, but best if the decision to choose each (IDE and source control) are decided by its own merits. In case the chosen IDE does not have tight integration with the source control, it's not the end of the world or a show stopper. In other words, you can still be very productive if they're not integrated.
Be careful using any source control within Netbeans.
You need to be very cautious about ensuring that you stick to a version of Subversion that your version of Netbeans supports. Assuming you are using windows you will probably also install tortoise and it constantly checks for tortoise & SVN updates which you may foolishly opt to do and then suddenly your netbeans subversion integration is screwed up.
If you search for netbeans subversion plugin a lot of the top entries include the words "upgrade" and "broke".
My advice would be to avoid the IDE integration altogether. You reduce the number of things that can break and interfere with your work. If you learn the command line options you become platform/ide independent.
I gave up on SVN in Netbeans a while ago after getting frustrated with the constant fiddling with the plugin, netbean versions, and svn versions.
I have used subversion with Netbeans before and it is very effective - subversion allows you to keep your source organised in a nice, simple folder structure whilst being almost universally supported. Besides all of the VSS haters out there, SVN is almost certainly the best "traditional" versioning system out there.
Update 2019:
the Subversion support page date from 2013, for SVN 1.8
And the request for SVN 1.9 (opened in 2015) is still pending.
So using the Git Netbeans integration is a good choice.
As an aside, Ruby itself just got migrated from Subversion to Git.
The initial request for that migration was opened three years ago, and at the time rejected.
But bugs.ruby-lang.org issue 14632 opened one year ago (March 2018) went through.
As announced in "Ruby Repository Moved to Git from Subversion" (April, 23rd 2019),
Today, the canonical repository of the Ruby programming language was moved to Git from Subversion.
The web interface for the new repository is https://git.ruby-lang.org, and is provided by cgit.
We can keep the commit hash from the contributor on the Ruby repository directly.
Is Synapse ready for a Delphi 2009 production applications? Their website doesn't look like it's been updated in a while: http://www.ararat.cz/synapse/doku.php Is the project dead?
I have been using the latest version from the SVN repository without any problems in a commercial application compiled with Delphi 2009.
The D2009 support not released but you can download directly from the svn repository, if you browse the code there, you will see there are changes for D2009 compatibility
http://synalist.svn.sourceforge.net/viewvc/synalist/trunk/