Contents

Download Infrastructure

P2 Update Sites

EclipseLink organizes its update sites into three different sites; signed "release builds", signed "milestone builds", and unsigned "nightly builds". Where "released builds" consist of product releases and thier associated bugfix maintenance patches, "milestone builds" are tested stable builds released regularly during development, and "nightly builds" are the latest and (hopefully) greatest build of the development codebase. Nightly builds are unsigned, and routinely have issues. However, in most cases these are minor because the continuous build process (cb) regularly builds and tests the codebase as transactions are merged (between 6am-8pm EDT daily). Thus most major issues (regressions) are fixed within hours of the cause. Issues do slip through the cracks though, because only limited testing can be done with the cb (it is limited to a 20 minute run duration), regressions caught by the more extensive nightly build process are usually fixed by the next nightly build. Because of this, milestone and even release builds are directly promoted from nightly builds (after various levels of additional testing).

EclipseLink now utilizes "compound" repositories to make all the builds available in one site available for each type.

Milestone releases are stored similarly. However, it should be noted that due to space restrictions only milestones for versions under development are retained, and due to limitations with P2 the milestone a build belongs to can take some research. It is usually best to simply update to the latest if you choose to use milestone builds. They can be found at:

Nightly builds have similar restrictions. They are only only retained for about a week. The builds are unsigned, and maynot even be stable. It is best not to use them unless you are trying to get past a specific issue you know is resolved with a particular nightly build. The URL to the nightly build update site is:

It should be noted that we have opted to use composite repositories in spite of a major drawback: a user can simply select the category checkbox, and inadvertently select *all* available builds. Thus cluttering , and causing a maintenance head-ache on thier own system. No solution to this issue is currently available, however, not using a composite repository for incremental builds also has issues led to issues that effected all users, all the time.

P2 organization

The Project update site is now centered around a single catagorized feature. The SDK. In the past we made available several features, and corresponding "source" features. Those features are still avalailable, but to select them you will need to unselect "show categorozed items". Currently, only the SDK feature is categorized under "EclipseLink". All past release repositories have been regenerated to use the SDK (binary bundles have not been modified).

The EclipseLink SDK is currently made up of the other six (6) features. They are:

EclipseLink JPA (org.eclipse.persistence.jpa)

EclipseLink MOXy (org.eclipse.persistence.moxy)

EclipseLink SDO (org.eclipse.persistence.sdo)

EclipseLink JPA Source (org.eclipse.persistence.jpa.source)

EclipseLink MOXy Source (org.eclipse.persistence.moxy.source)

EclipseLink SDO Source (org.eclipse.persistence.sdo.source)

Though the jar name of the feature is similar to an EclipseLink bundle of the same name, the two do not conflict because the feature
(or in p2 parlance: the Installable Unit) is stored separately from the bundles it installs/includes.

Feature content

With the exception of the SDK (which includes all the other features), EclipseLink features are not 'nested', but rather are designed as completely autonomous units specific to the utilization of specific EclipseLink functionality. So though every 'feature' depends upon the EclipseLink core, there is no "Core feature". Instead "EclipseLink JPA" groups together all libraries (both project and external) that are distributable and are needed for developing and running an EclipseLink JPA application. The same is true of the MOXy and SDO features. This decision was originally made because it was felt to be more 'developer-centric', more easily understood and resulted in a less cluttered 'update' display.

Now all the features are made available in a single SDK, and nesting may make more conceptual sense, but for backward compatability the original structure has been maintained. In addition there is no real need to change it since, becasue of the nature of OSGi, a specific bundle will only be installed once, no matter how many other bundles (or features) may depend upon it.

It has been requested that a breakdown be made available of the bundles included in each feature outside of the xml projects used to create them (thus sparing the reader from having to understand the "feature.xml" layout). Given the changing nature of these dependencies I will outline the dependencies for the latest release currently under development (2.1.0), with the caveat that the ultimate autority is the feature.xml stored in the "features" subproject of EclipseLink's SVN repository.

Downloadable Content

Since classic zip archives of content are made available via Webpages, it makes little sense to discuss directory hierarchies. It may be of benefit to talk about the web organization, and actual content of the archives will be related below. The latest release available for download can be found on the main download page

Maven Repository

EclipseLink maintains a maven repository for nightly, milestone and release builds. Nightly builds are kept to the latest ten builds per release version. There is a bug being looked into to split the incremental from the release repo. There is also work to determine if recent p2 support for Maven could be utilized to replace the creation of additional Maven repositories.