Skip to main content

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.

Jump to: navigation, search

WTP/Build/WTP and Java EE IDE EPP Package

< WTP‎ | Build
Revision as of 11:38, 10 September 2011 by David williams.acm.org (Talk | contribs) (WTP/Build/WTP and JEE IDE EPP Package moved to WTP/Build/WTP and Java EE IDE EPP Package: Should spell out "Java EE" when used in sentence)

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 ready to promote

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, just 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, to check preference pages, make sure they show up, no NPEs occur, etc. Also, the general advice on how to test 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).

Bug triage

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 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 best to subscribe and follow that epp-dev list and participate in the discussion and decision process.

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.

Back to the top