The impact that the Eclipse Platform has made on application development is amazing and unprecedented in many ways. From the story of its birth to its wide feature set, there is nothing bland about this product. The Platform has created commercial product opportunities around it and gives a bountiful amount of freedom and control to end users. This has led to widespread industry adoption and corporate support.
The Platform’s best known component, the Integrated Development Environment (IDE), alone is on par with, if not outright excels against, many similar commercial offerings. Originally a Java IDE, Eclipse makes an excellent PHP development environment with the help of the PHPEclipse plug-in. PHP developers experienced with IDEs will enjoy its extensibility and power and if you have never used an IDE on a PHP project, Eclipse is a great tool to get started with. It has everything you would need in an IDE, runs on many platforms, and best of all, it’s completely free.
Integrated Development Environments
IDEs are simply programs to write programs. They are generally editing environments with tools to help programmers write code quickly and efficiently. As an example, we can create PHP‑driven web applications using a combination of Eclipse and PHPEclipse. Core features typically include:
- Code completion or code insight: The ability of an IDE to know a language’s keywords and function names is crucial. The IDE may use this knowledge to do such things as highlight typographic errors, suggest a list of available functions based on the appropriate situation, or offer a function’s definition from the official documentation.
- Resource management: When creating applications, languages often rely on certain resources, like library or header files, to be at specific locations. IDEs should be able to manage these resources. An IDE should be aware of any required resources so that errors can be spotted at the development stage and not later, in the compile or build stage.
- Debugging tools: In an IDE, you should be able to thoroughly test your application before release. The IDE may be able to give variable values at certain points, connect to different data repositories, or accept different run-time parameters.
- Compile and build: For languages that require a compile or build stage, IDEs translate code from high-level languages to the object code of the targeted platform.
Requirements for these features vary substantially from language to language. Thus, traditionally, an IDE specializes in one language or a set of similar languages. Some famous IDEs and their languages include: JBuilder for Java; Metrowerks CodeWarrior suite for Java, C, and C++; and Microsoft’s Visual Studio for its Visual Basic and C# family of languages.
Using an IDE will save you a lot of effort in writing a program. Some advantages include:
- Less time and effort: The entire purpose of an IDE is to make developing faster and easier. Its tools and features are supposed to help you organize resources, prevent mistakes, and provide shortcuts.
- Enforce project or company standards: Simply by working in the same development environment, a group of programmers will adhere to a standard way of doing things. Standards can be further enforced if the IDE offers predefined templates, or if code libraries are shared between different team members/teams working on the same project.
- Project management: This can be twofold. First, many IDEs have documentation tools that either automate the entry of developer comments, or may actually force developers to write comments in different areas. Second, simply by having a visual presentation of resources, it should be a lot easier to know how an application is laid out as opposed to traversing the file system for arcane files in the file system.
Be careful of some of the pitfalls of using an IDE as it may not be ideal for everyone and might not be suitable in every situation.
- Learning curve: IDEs are complicated tools. Maximizing their benefit will require time and patience.
- A sophisticated IDE may not be a good tool for beginning programmers: If you throw the learning curve of an IDE on top of learning how to program, it can be quite frustrating. Further, features and shortcuts for experienced programmers often hide crucial but mundane details of a language. Details should not be overlooked when learning a new language. Using an IDE may hamper the learning of a new language.
- Will not fix bad code, practices, or design: You still need to be proficient and meticulous. An IDE will not eliminate efficiency or performance problems in your application. IDEs are like paintbrushes. Whether you create a Van Gogh or a Velvet Elvis is dictated by your skill and decisions.
There are many ways to create an application. Plenty of pundits and consultants have become wealthy by creating and pitching system development lifecycle models to companies. Not surprisingly, having many ways of doing something leads to many diverse development models. In each model, steps may be called different things, will have different collaborators, and may even occur in different orders. However, most have these steps in common:
- Requirements Gathering: What do you want the program to do?
- System Design: How is the program designed? What is the structure of the program? How does it interact with other systems? How will the program address each identified requirement?
- Development: Code is written at this stage.
- Testing: Does the application work? Will the program negatively affect other existing systems?
- Acceptance: Do your customers actually like the product? Will it fulfill their business needs?
- Deployment: Pushing the code out to production.
It is not uncommon for each step to use different tools. You may simply use a word processor for the requirements gathering. If you use Unified Modeling Language (UML) for system design, you’ll need a graphical diagramming tool. Traditional IDEs are used in the development stage to write code. An IDE may have a debugger to help with testing, or deployment tools, but this is not always the case. If you use a simple editor like Macromedia HomeSite, you’ll certainly need other tools to test and deploy, and even build if necessary.
An IDE, therefore, is just one tool used in developing an application. As one would expect, use of multiple tools drives up development costs by way of license purchases, training, and integration hassles. Eclipse, however, was built to solve this problem.
A very simplified definition of Eclipse is that it’s an IDE. Out of the box, it is an excellent Java IDE. However, it goes beyond that. Eclipse is based on modules, called plug-ins, which can extend it beyond just writing code. The number of plug-ins available in the Eclipse community is enormous and they cover diverse functionalities. Using plug-ins, we can write programs in any language, including PHP. We can also use plug-ins to perform any task in our development process, from the idea stage of drawing diagrams to the development stage of writing code to the deployment stage of pushing files to a production server.
For most software applications, we wouldn’t need to care about their history or who develops them. Most IDEs are developed by a commercial company and sold for profit to other developers. For those IDEs, previous versions or incarnations only matter to determine upgrade prices.
However, Eclipse is not your typical software application. It’s not only interesting to know its pedigree, but it’s important as well. Knowing its history and who exactly drives development will help you appreciate Eclipse’s architecture, understand some quirks you may encounter, guide you to the proper place to ask for help, and perhaps inspire you to participate in the community of Eclipse developers.
Before Java, the object oriented language that was all the rage was Smalltalk. Object Technologies International (OTI) specialized in development tools for Smalltalk. Among these tools was Envy, a development environment and source-code manager. In 1996, IBM purchased OTI and made it a subsidiary company. Using Envy as a model, the two companies collaborated to create next generation development tools for languages like Smalltalk (Visual Age for Smalltalk) and Java (Visual Age for Java).
Their next collaboration on development tools began in 1999. Development would occur against the backdrop of two industry trends. First, Linux and open source were emerging as major forces in the industry. Seizing on this, IBM developed a ‘Linux strategy’ and publicly committed $1 billion to marketing Linux and supporting open-source software. Second, in web development, it was clear that typical enterprise web applications often required components to be written in different languages. C++ may be required to access an older data store, SQL may be required to access a more modern database, and JSP may be required to deliver the HTML and JavaScript output. Developers often had to use different programs to write these different portions. IBM wanted to create one unified tool for developers’ needs.
In 2001, after a reported development cost of $40 million, the Eclipse Platform was born, which addressed both these industry trends. IBM reaffirmed its Linux strategy by releasing Eclipse as open-source software to the world, and everyone saw how its architecture allowed unparalleled extensibility.
IBM did not release Eclipse into the cold, harsh world to fend for itself. It created and funded the Eclipse Foundation to act as the custodian of the Eclipse Platform. The Foundation’s Board of Stewards was to steer the direction of Eclipse, oversee development progress, and evangelize the product. Originally, the consortium comprised representatives from Borland, IBM, Merant, Red Hat, SuSE, Rational Software, QNX, TogetherSoft, and Webgain. Over time, other companies such as Oracle, SAP, Ericsson, Hitachi, Fujitsu, and Intel were granted membership.
In February 2004, IBM officially spun off the Foundation and reorganized it as an independent, not-for-profit corporation. The reasoning was that no one company, not even IBM in this case, could meet all the demands of the customers and by setting the Foundation free, Eclipse could become an even better platform for creating integrated tools. This is being achieved today. More contributors have joined in to help with the development of Eclipse, and its independence gives the Foundation more flexibility in collaborating with other companies.
The Foundation currently manages several Eclipse-related open-source projects. These top‑level projects range from business intelligence tools to testing tools and web tools. Underneath each top‑level project are smaller subprojects to break down the work.
|
Originally, there was only one top-level project, the Eclipse project, and its purpose was to manage the IDE that is the subject of this book. That is still the official name for the project despite the use of the word ‘Eclipse’ to mean more of the Foundation, or the platform depending on the context, rather than the IDE product. A counterpart to this is the Apache Foundation. Originally, Apache just meant a web server, but today, the Apache Foundation hosts many more projects in addition to its flagship, the web server. Unlike Eclipse, though, the Apache Foundation has re‑branded the server to ‘Apache HTTP Server’. Thus, barring any similar renaming of the Eclipse IDE, the term ‘Eclipse project’ should be referring to the project in charge of the IDE development and not to the Foundation as a whole or any of the other top‑level projects managed by the Foundation. For simplicity sake, though, unless otherwise stated, when we say ‘Eclipse’ in this book, we’ll mean the Eclipse IDE. |
The Eclipse project is divided into three subprojects — the Platform, Java Development Tools (JDT), and the Plug-in Development Environment (PDE). These three compose the Eclipse Software Development Kit (SDK). The Platform subproject manages the IDE infrastructure and essential services. In other words, the Platform makes the IDE what it is. There are about fifteen smaller component projects underneath the Platform. They include things like Ant integration, the core libraries, the text editor, and the help system. The JDT subproject is in charge of the plug-ins that makes Eclipse a world‑class Java IDE — right out of the box. Three components compose this subproject — the core Java editing environment, debugger, and user interface (UI). The PDE subproject manages the interface that gives Eclipse its incredible extensibility. PDE Build and user interface are the components. As we will soon see, plug-ins are essential to the functionality of Eclipse. The PDE subproject makes interfacing, and thus extending, Eclipse easy. The figure below shows the top-level projects undertaken by the Eclipse Foundation and gives an idea of the sub-projects under the Eclipse Project.
A Project Management Committee (PMC) manages the vision and development of the Eclipse project. The PMC Leader, who is appointed by the Board of Directors, generally selects the PMC. Developers are the volunteers who actually write the Eclipse code.
Up to this point, we’ve hinted at how the Eclipse IDE can be your one tool for the whole development process. This seems quite a bold claim, but it is very much a reality with Eclipse thanks to its forward‑thinking architecture.
By itself, the Eclipse Platform does nothing. The core piece of Eclipse is just a small kernel called the Platform Runtime. All functionality of the IDE is a result of interactions between the plug-ins and the kernel. When you launch the Eclipse executable, the kernel checks what plug-ins are available in a special plug-ins directory. Each plug-in has a manifest file that defines how it interacts with the Platform and with other plug-ins. To save startup time and system resources, each plug-in is loaded only when necessary.
The manifest file is XML based and defines the extension points used by the plug-in. Extension points are the basis in communications between plug-ins and the Platform. An extension point either declares the services this plug-in can provide to other plug-ins, or declares how this plug-in will interact with another plug-in’s extension point. This leads to a very interesting behavior of Eclipse. With plug-ins themselves being extensible, the lines often blur between plug-ins. When we actually start coding in PHP, we’ll see how tools in the JDT are extended via the PHPEclipse plug-in. For example, the same tool that is used to show an outline of all functions in a Java class is also used to show PHP functions once PHPEclipse is installed.
When you download the full Eclipse SDK, it includes several plug-ins that give it all the features of an IDE —workspace, Workbench, the JDT, Version and Configuration Management (VCM) system, the help system, and the PDE.
Each application you develop in Eclipse is organized as a project. Each project may hold different files, directories, and settings. The workspace not only manages where the resources are, but also manages the state of resources. Each resource may hold a historical record of changes and other resources might be interested in this information. The workspace coordinates all of these things between resources.
The Workbench is essentially Eclipse’s GUI. From menu items to window panes to buttons, the Workbench handles everything you see and interact with. The Workbench is written in the Eclipse Standard Widget Toolkit (SWT) and JFace. We’ll discuss the SWT and JFace in depth later. Basically, like Java’s native Swing, both are Java GUI libraries. Like the Workbench and everything else, SWT and JFace are plug-ins that are loaded by the runtime kernel.
Since Eclipse made its name as a Java development platform, the JDT (a Java development plug‑in) is included with the standard Eclipse SDK download package. Eclipse’s knowledge of Java syntax, compiling, and debugging come from the JDT. A lot of people do not need Eclipse to do anything more than to be a Java IDE. The JDT is what makes Eclipse a Java IDE.
Version and configuration management system, or more commonly referred to as the Team Tools, manages source code shared by a team. Essentially, the Team Tools allow Eclipse to act as a full Concurrent Versioning System (CVS) client. By talking to the Workbench plug-in, the Team Tools know what files need to be committed and where to place updated files. Branches, tagging, and patches are also managed by the Team Tools. Do not worry if none of this makes sense. We’ll explore more about versioning and CVS inChapter 7.
The help system makes it easy for plug-in developers to create help files and documentation for end users. All the developer needs to do is create the help files in HTML and define the schema using XML. Through the help system, Eclipse pulls in the help file appropriate to the plug-in when requested by the end user.
Finally, in a seemingly circular relationship, the PDE, the tool to create plug-ins, is itself a plug-in. Development and deployment of plug-ins require meticulous attention to detail. The manifest and source code files can grow quite large. The PDE automates much of this work through wizards, templates, and Eclipse’s own workspace. Thanks to the PDE, it is no surprise that there is a large community of Eclipse plug-ins and plug-in developers. Having a native tool builder within the tool lets anyone alter Eclipse to their own individual liking.
|
Eclipse plug-in development is a very rich subject. Entire books have been devoted solely to this topic. Be aware that Eclipse plug-ins are written solely in Java using SWT and JFace. |
For PHP development, we will be using the PHPEclipse plug-in. This third-party plug-in fits nicely into the Eclipse architecture as can be seen in the figure below which shows the Eclipse Platform architecture:
Now that we know the roles and workings of plug-ins, the Workbench plug-in deserves a little bit of extra attention. The JDT and PDE plug-ins rely on the Workbench’s extension points, but not vice versa. If you do not require Java development tools, you can conceivably download just the Eclipse Platform. The Eclipse home site ( http://eclipse.org/downloads/) offers downloads of the Platform without the JDT and PDE plug-ins.
The text editor functionality is in the Workbench. These ‘platform-only’ downloads would have the editor without any sort of indication that this is a Java IDE. The three other ‘core’ plug-ins (help, workspace, and Team Tools) would also be present. However, Eclipse’s functionality would certainly be limited.
The primary purpose of having downloads without the JDT and PDE plug-ins is to allow redistribution and repackaging of Eclipse. If your product involves Eclipse but not Java, you can release a version without the JDT. Another purpose may be to speed up the start-up time and performance of Eclipse. Indeed, the smaller the number of plug-ins that are installed, the faster Eclipse starts up.
The story of the SWT is certainly the most controversial part of the development of Eclipse. SWT does the actual illustration of the Eclipse GUI. Buttons, checkboxes, windows, and the like are all handled by the SWT. If you want to draw a radio button inside a box in a plug-in, you use SWT’s API to do so. In fact, we can use SWT as the basis of the GUI for any Java desktop application.
On the other hand, we have Swing. Swing is the official collection of Java classes used to build user interfaces, objects like windows, text boxes, and such. Swing and SWT sound a lot alike. In fact, you might say it sounds like SWT replaces Swing in Eclipse, and you’d be right. In developing Eclipse, IBM bypassed the officially blessed GUI toolkit and created its own. Needless to say, Sun is not very happy with this, and this is perhaps a reason why Sun, the creator of Java, does not hold, and has never held, any role in the Eclipse Foundation.
SWT integrates much closer to the native operating platform than Swing. For each platform that SWT runs on, the libraries hold a direct mapping from the SWT Java calls to the target platform, which are written in C. Unlike Swing, the JVM does not have to do this mapping. This gives SWT applications a speed advantage when dealing with GUIs. The performance of SWT applications is close to OS-native applications. For common widgets like radio buttons and text boxes, SWT uses the operating system’s native widgets. Only if a widget is not defined will SWT emulate the widget. An SWT-based application running on Windows XP will look like a Windows XP program. The same program will look like a Mac OS X program when running in Mac OS X.
There are downsides to SWT. First and foremost, by integrating tightly with platforms, the interface loses its consistency, and Java applications potentially lose their portability. Each platform requires its own SWT library, and platform-specific code can be written in each one. This opens the door to platform-specific Java, which is philosophically against Sun’s promise of keeping Java platform independent. Since it’s not an officially blessed specification, SWT applications are breaking a standard. If you decide take a side in this issue, be aware that you’re entering a furious religious debate.
|
There are technical downsides to SWT too. Since SWT interaction does not happen in the JVM, developers cannot rely on Java’s garbage collector to destroy objects. You’ll have to be vigilant and do this yourself. Swing also employs a pluggable architecture, which you will lose with SWT. |
IBM was well aware of the tradeoffs when creating SWT. In the end, we can’t argue with the results. If you have ever used a Swing-based desktop application, you would never guess Eclipse was written in Java. Eclipse is a fast and cross-platform application that aesthetically looks good. Pre-compiled binaries are available for all major operating systems including Mac OS X, Linux (GTK and Motif), Windows, and Solaris. SWT makes Eclipse fast and cross platform.
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.
The PHPEclipse project was started to address two problems. First and foremost, it brought PHP functionality to the Eclipse platform. Second, as good as Eclipse is for Java application development, it had its shortcomings as a web development IDE. Anyone who has developed web applications using traditional editors like Macromedia’s HomeSite or Bare Bones’ BBEdit know the annoyance of constantly switching to external applications during development — dropping into Query Analyzer to connect to a database or constantly hitting Refresh in a web browser just to see if your CSS modifications work.
The PHPEclipse plug-in has addressed both issues admirably by focusing on what PHP web developers typically need to create an application. Started in 2002, PHPEclipse’s development is active and its tool set provides everything that we need to write web applications in PHP.
The PHPEclipse package brings to Eclipse:
- An excellent PHP editor that knows about PHP syntax and built-in functions
- A debugger to help troubleshoot PHP code
- phpDocumentor, a tool like JavaDoc, which helps us quickly create documentation for our code
- An interface to SQL databases using the QuantumDB plug-in
- Tools for deployment to production servers via FTP, SFTP, WebDAV
There are other great PHP IDEs like NuSphere’s PhpED and Zend’s Zend Studio that are great at writing PHP applications. There is also another PHP plug-in for Eclipse — Xored’s TruStudio. However, they too suffer from this same lack-of-integration drawback as the editors. None of these other packages comes with the breadth of external tools that PHPEclipse includes. Like Eclipse/PHPEclipse, you can write code quickly, but unlike Eclipse/PHPEclipse, you still need to use other programs to do other tasks. Most of all, Eclipse and PHPEclipse are free while the others require heavy licensing payments.
Eclipse is an IDE unlike any other. It is rare to find a product that enjoys fervent support from both major corporations and the open-source community. Eclipse, however, is one such product. Eclipse came about from IBM’s development and its subsequent rallying of support from industry businesses. Its final handoff of Eclipse to a non-profit corporation has only enhanced Eclipse’s potential. From the very first release, this free product was loaded with features that often cost thousands of dollars in other IDEs. The core philosophy of Eclipse is to be a tool to create other tools. It is often said that the Eclipse Platform is the ultimate tool to make tools. Its end-user license and architecture support this philosophy.
Taking advantage of this architecture is the PHPEclipse plug-in. Designed from the ground up to fulfill the needs of a PHP web developer, the combination of PHPEclipse and the Eclipse Platform gives everyone everything they would need to create web applications in a professional manner.
