The first article describes the evolution of eBay's presentation architecture from its early Perl roots to the current Java version, known as version 4:
"The V4 architecture took the approach of representing everything that was going to be used on the front end with strongly typed Java objects on the back end. Does your page use an image? Then there is a Java object for that image. If you want to delete that image, it's as simple or as complex as deleting any other Java class. The same can also be said for links, CSS, and JavaScript. V4 does not use servlets or JSPs to create HTML. Instead, the actual HTML DOM is represented in the Java language, so you can wire together CSS and JavaScript on the server.What about the hardest problem of them all: content? V4's content system is unique and powerful. It uses its own XML-based language to create content contracts. The choice of the word contract is intentional. Contracts define what kind of data is needed to create any variation of a piece (unit) of content. For example, a particular unit may need an integer and a string in English (like "Raymond has 4 cars"), but requires two integers and a string in another language. There may also be multiple variations for gender and cardinality. The contract defines all of this in XML. The contract is then implemented in each language supported by a particular application/page/component. And, of course, it has to be represented as a strongly typed object in Java that requires all of the dynamic data (like "Raymond" and "4" above) to be supplied in order for it to be used. Because everything involved are strongly typed Java objects, everything is enforced at compile time. If an application developer doesn't give the two parameters in his Java code, the code won't compile."
The article goes on to describe how eBay implement the Java representations of the different languages that make up their applications. JavaScript is kept as native code and proxied with Java, CSS files are used as a starting point but then replaced by a Java class file that is used at runtime to generate the CSS, the content contract XML is also converted to Java and so on. The central theme that runs through the eBay approach is using Eclipse code generators to take the grunt work out of doing this conversion. eBay have developed an Eclipse plug-in to convert each source file (JavaScript, CSS, XML) to its Java representation, and custom editors to work with their proprietary XML formats. The first article concludes by showing an example of introspecting a running eBay instance for its V4 components and opening up that component directly in Eclipse.
The second article describes how eBay use a combination of an XML file format and another proprietary plug-in to manage their project dependencies. The XML file allows Eclipse to generate the necessary project and .classpath files, and as with their XML contracts a second plug-in provides an editor for the XML.
As well as their own collection of proprietary Eclipse plug-ins, eBay also use third party ones. Two which get a mention are the Rational ClearCase plug-in for source-code control and static code analysis tool FindBugs which is used by eBay as part of their acceptance of any source code.
A significant aspect of this is the open source nature of the Eclipse platform. Since the source is open it is a comparatively straightforward task for eBay to integrate their proprietary plug-ins with the rest of the IDE.