We now have an understanding of Eclipse’s history, the components involved, and what makes Eclipse tick. Why should we use Eclipse, especially for PHP development? Why not use one of the traditional PHP IDEs, or why even use an IDE at all? There are plenty of advantages, but the four with the largest impact are the plug-in architecture, its generous license, intellectual freedom, and powerful features.
We have explored Eclipse’s plug-in architecture from a high-level technical view. Indeed, the technical flexibility is quite impressive. The architecture’s impact on the industry and our work processes cannot be overstated. It is the use of plug-ins that enables Eclipse to be the only program you need for all the stages of the application development lifecycle.
Imagine that you are building a new web application written in PHP. You first need to draw UML class, sequence, and activity diagrams. PHP coding will obviously be your principal duty. During development, you realize that you need to update a module written in Python. You may also need to explore a database schema. An LDAP server with group and role definitions will handle security, so you’ll need a tool to browse LDAP’s schema. As you work, you debug portions of your application and share your changes with other developers on the team. You move the application to one server for the testing team, another server for the acceptance testing team, and finally a production server when you’re ready to implement your new application.
All of these tasks can be accomplished directly within Eclipse via external plug-ins. Even better, you do not have to create these plug-ins. A large developer community exists that has created plug-ins to extend Eclipse. Some plug-ins are commercial and require a license; however, many are free and open source. When people say that Eclipse ‘enjoys widespread industry support’, it is often a reference to the commercial member companies of the Eclipse Foundation. However, it is also an allusion to the many grassroots volunteers and commercial developers who have given Eclipse more functionality by creating new plug-ins.
|
Eclipse.org maintains a list of plug-ins, commercial and open source, located at http://www.eclipse.org/community. There is also a section with links to plug-in community sites that maintain even larger or more specialized lists. In Appendix A, we highlight some plug-ins that may be helpful to you in PHP development. |
By having all of your tools in Eclipse, you simplify your development environment. Learning curves and software compatibility issues are decreased. Further, since many of the plug-ins are open source, your costs for tools can be lowered.
Eclipse is released under the terms of the Eclipse Public License (EPL). That is, Eclipse is free and open source. To alleviate any prejudgments and confusion, we need to define what ‘free’ means, clarify exactly what ‘open source’ means, and what rights you have under the EPL.
For all practical purposes, ‘free’ means that Eclipse will not cost you any money to use. There is nothing that you have to pay for — either when you initially obtain the program or by means of upgrade fees or royalties. Someone may sell you Eclipse on a CD, but you do not have to buy it as the same can be legally downloaded from its website.
‘Free’ also gives you the freedom to redistribute and alter the program as you see fit. For the latter, this also implies that you have the right to access the source code. By definition, freedom does not require you to obtain permission from the original author to redistribute or modify.
‘Open source’ is a little more complex. Open-source licenses must grant users the basic freedoms explained above. However, they have subtle differences, which lead to larger impacts. One notable and well-publicized difference is whether a license is ‘viral’ in nature. That is, if you modify a program with your own closed-source proprietary code, your code will fall under the open-source license and you lose all intellectual property rights to it. The most famous viral license is the GNU Public License (GPL). This has led to unfair and inaccurate accusations that all open-source licenses are unfriendly to commercial interests.
The EPL is not viral in nature. If you modify Eclipse with your own proprietary code and redistribute this new product, the Eclipse portion is still under the EPL. You must provide access to the recipients for the Eclipse portion; however, your code can still remain closed. You can still retain rights to your code.
This is another reason why Eclipse enjoys commercial support. The EPL was created to create commercial opportunities and yet remain free so that anyone can use it. Companies have created products using Eclipse as a base, and sold them commercially. IBM’s WebSphere Studio products are a prime example. The WebSphere Studio family are IDEs with enterprise-friendly features such as UML diagramming support and J2EE tools built on top of Eclipse.
Being ‘free’ works very well with PHP. We now have a free tool to develop websites using a great, free language. With PHP and Eclipse/PHPEclipse, your development costs drop dramatically.
A more compelling consequence of the plug-in architecture is its meaning for open source in general. Development toolmakers want you to buy as many of their products as possible. They may hinder others from making IDEs for their proprietary language either by charging exorbitant licensing fees or taking a bully-like stand in enforcing patents. They may also offer tighter integration to their other tools while not giving the same access to other vendors. The more you adopt their closed technology, the more they can sell to you, and after time, the more expensive it will be to migrate out if you don’t want to play with them any more.
Eclipse does not adopt this strategy. First and foremost, vendor lock-in is directly against the philosophy of the open-source community. Open-source software is all about giving users rights and freedoms. Second, due to the plug-in architecture, it’s pretty much impossible to lock people in from a technical standpoint. No matter what the language, there’s probably a plug-in for it, and if there isn’t, you can always write one.
No longer are developers tied to one proprietary tool, product, or closed license. If you wish to develop in C# for .NET, you do not have to purchase Microsoft Visual Studio. You can just download one of the C# plug-ins for Eclipse. It is, quite blatantly, the open-source method of embrace and extend.
Finally, if you do not like the way a plug-in or Eclipse is working, you can always change it. The open-source license gives you the rights to modify Eclipse itself. Further, since many plug-ins are themselves open source, you can also modify them for your own use. You may even want to join the project and share your changes with the world.
The most basic requirement for Eclipse is having a computer with Java 1.4 installed and SWT. Both packages have been ported to most modern operating systems. Binaries of the Eclipse Platform are available for platforms such as Mac OS X, Windows XP, Linux (with Motif and GTK 2), Solaris, AIX, and HP-UX. Further, since plug-ins are also written in Java and SWT, most plug-ins are also cross-platform.
With Eclipse, application development is nearly operating-system agnostic. You can work on a project on an XP box at work, commit your changes, download the new code to your Apple Powerbook, and work from home. Programmers in the information technology department can work on a project using their Windows and Linux boxes while front-end HTML coders in marketing can use their Mac OS X machines to create web pages.