Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
WTP/Build/WTP and Java EE IDE EPP Package
WTP and the Java EE IDE EPP Package
We (WTP) have long "sponsored" the Java EE IDE EPP Package and it is normally the most download package from Eclipse downloads (totaling in the millions). Prior to having these EPP packages we produced a WTP all-in-one packages, because WTP is notoriously hard to install ... especially back then, before p2, before a common repo. The Eclipse Foundation, and others, devoted resources to EPP to improve the "out of the box" experience for end-users, to promote the use of Eclipse and its most popularly desired projects. This document is to give some very high level description of that Java EE IDE EPP package and what our (WTP) involvement is.
Activities and Responsibilities
Smoke testing and yea/nay vote
One responsibility is to smoke test the package and vote on the epp-dev mailing list when it is ready to promote for general consumption. This happens for every milestone, and release candidate. There is an EPP Package Testing Page which has general advice for testing all packages and then also specific ones. For Java EE IDE Package, we just point back to our WTP Smoke Test pages. To be honest, it is typical to only test an extremely small subset of function, such as making a dynamic project, create a jsp page, set a break point and make sure the debugger stops on it when 'debug on server'. Plus, typically it is good to check preference pages, make sure the expected ones show up, no NPEs occur, etc. Also, the general advice on how to test, on that wiki page, is useful, such as what to check for in the eclipse.ini file, etc. Each time (e.g. each milestone or release candidate) it is nice to pick a different platform or a different bit architecture, just to have some representative coverage (though, could never be complete and we definitely depend on the community for in depth testing).
There is a special "jee-package" component in the EPP bugzilla product that gets bugs, occasionally. At times, these really are EPP Packaging problems, at other times it is an obvious bug in some component so is a matter of moving to the right place (JEE, XML, Mylyn, Platform, etc.). For a current list of open bugs, see this bug query.
Participation in EPP
EPP (Eclipse Packaging Project) is an Eclipse Project, and like any other Eclipse Project, occasionally there are issues or discussions on the EPP mailing list about the project as a whole, so it is required to subscribe and follow that epp-dev list and participate in the discussion and decision process. In the spring of 2011, all current package maintainers were made committers on the project. Presumably, future committers (and package maintainers) would be voted in following the usual process on the Eclipse Portal.
Content and Structure
The EPP build pulls things from the common Simultaneous Release repository. So, what ever is contributed there, can get included into the package. We, in Java EE IDE, do have a policy not to include incubating components, though some EPP packages do. We also decided to include only "runtime" code, to make the package smaller, since the audience was specifically web-app developers, rather to include SDKs oriented to extenders or committers (the thinking being that audience knows how to install SDKs or source that they need). This also serves as a sort of "test" that our "runtime code" is correctly built and packaged for use by other adopters.
Extra WTP bundles
The only things we (WTP) put there, in the common repository, that is not part of our normal WTP builds, downloads and repository are some capability bundles, and a custom welcome screen bundle (provided by Naci Dai and team). These are essentially built once, put in a special WTP repository, and then via the b3 aggregator, put into the common repository (uncategorized). The capabilities bundles are primarily to show an example of how to make use of capabilities. As they are, they are not actually very useful or complete (for example, JSF and Dali have not contributed) but they do serve as a good example or "proof of concept" on how to get started.
Java EE EPP Feature
There is a feature that lives in the EPP CVS repository (/cvsroot/technology) under the org.eclipse.epp/packages directory, named org.eclipse.epp.package.jee.feature. This is where the contents of the package are defined, we include the obvious, Platform, JDT, as well as most of WTP and its prereqs, plus some components from other Eclipse projects, such as RSE (Remote System Explorer) and Mylyn.
Java EE EPP Branding Plugin
This is a simple branding plugin, org.eclipse.epp.package.jee, where we can define our own icons, hook in our own capabilities and welcome screen.
Typically, there is not much to ever change in the feature or branding plugin. The Project Lead (Markus Knauer, from EclipseSource) usually makes changes that effect all EPP packages (such a version numbers) but certainly if there were improvements to be made, or features to add or remove, the Package Maintainer could make them. As a matter of policy, the EPP project gives final say to the Package Maintainer about what goes in the package, etc.