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 22:48, 8 September 2011 by David williams.acm.org (Talk | contribs) (initial content)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

WTP and JEE IDE EPP Package

We (WTP) have long "sponsored" the JEE IDE EPP Package and it is normally the most download package from Eclipse downloads (totalling 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. This document is to give some very high level description of that EPP package and what our 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 if/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 JEE 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 release repository. So, what ever is contributed there, can get included into the package. We, in JEE IDE, do have a policy not to include incubating components, though some packages do.

Extra WTP bundles

The only things we (WTP) put there, in the common repository that is not part of our normal WTP 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 do it. 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.

JEE 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 and Mylyn.

JEE 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 this feature or branding plugin. The Project Lead (Markus Knauer, from EclipseSource) makes changes that effect all EPP packages (such a version numbers) but certainly if there were improvements to be made, the Package Owner (or, 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