Difference between revisions of "EclipseLink/Development/GIT"

From Eclipsepedia

Jump to: navigation, search
(Open Issues)
(examples)
 
Line 53: Line 53:
 
=== examples ===
 
=== examples ===
  
The EclipseLink examples will be maintained in a separate repository.  
+
The EclipseLink examples will be maintained in a separate repository.
 +
 
 +
== build ==
 +
 
 +
Separate build system artifacts that can evolve independently of each of the above repositories.
  
 
== Open Issues==
 
== Open Issues==

Latest revision as of 12:32, 31 July 2012

This page describes the GIT repository structure of the EclipseLink project. It is currently a proposal under discussion as part of bug 386325.

Contents


[edit] Repositories

The repositories that are hosted by the EclipseLink project are listed below. Within each repository's section is a list of projects contained within it. The test projects are excluded to simplify but are maintained within the same repository as the code they are testing.

[edit] runtime

The projects and build infrastructure

  • org.eclipse.persistence.core
  • org.eclipse.persistence.jpa
    • org.eclipse.persistence.jpa.equinox
    • org.eclipse.persistence.jpa.equinox.weaving
    • org.eclipse.persistence.jpa.jpql - Hermes Parser
    • org.eclipse.persistence.jpa.modelgen
    • org.eclipse.persistence.jpa.osgi
    • org.eclipse.persistence.jpars
    • org.eclipse.persistence.oracle
  • org.eclipse.persistence.moxy
    • org.eclipse.persistence.dynamicxjc
    • org.eclipse.persistence.sdo
  • org.eclipse.persistence.dbws
  • org.eclipse.persistence.nosql
    • org.eclipse.persistence.oracle.nosql
  • oracle.target
  • org.eclipse.persistence.antlr
  • org.eclipse.persistence.asm

[edit] javax.persistence

The javx.persistence library is developed within the EclipseLink project under its EPL+EDL licensing but is based on the JPA specification. It is contained in its own repository since its versions and development is dictated by the JPA expert group and its associated JSRs.

  • javax.persistence


[edit] utils

These projects are development utilities that may depend on the runtime repository's projects but are not required by the runtime.

  • eclipselink.utils.workbench*
  • eclipselink.utils.rename
  • eclipselink.utils.sigcompare
  • eclipselink.utils.jaxb
  • org.eclipse.persistence.dbws.builder

[edit] incubator

This repository includes any code under incubation development.

[edit] examples

The EclipseLink examples will be maintained in a separate repository.

[edit] build

Separate build system artifacts that can evolve independently of each of the above repositories.

[edit] Open Issues

  1. The Hermes JPAQL parser is both an integrated part of the EclipseLink runtime as well as a component of the JPA tooling offered in Dali and other IDEs.
    • Hermes is already suffering from artificial branches imposed upon it by its inclusion in EclipseLink (2.0.1 and 2.1.0 are basically the same library except they are on different EclipseLink branches). It would be cleaner to maintain it separately as we do for javax.persistence, antlr and asm.
  2. Currently the runtime repository contains 3rd party dependencies (as documented in IP Log). These libraries are not maintained or augmented by the EclipseLink project and should be pulled into the development, build, and test environments instead of being stored within this repository. These projects include:
    • com.sun.jersey
    • javax.ejb
    • javax.jms
    • javax.resource
    • javax.transaction
    • javax.validation
    • javax.wsdl
    • javax.xml.soap
    • There are actually two issues here. 3rd party projects included for development, and 3rd party libraries included for compile, test, and runtime dependencies. All should be moved, I had been contemplating creating a separate git repo for binaries
  3. Should the JPA org.eclipse.persistence.jpa.modelgenproject be a utility? Does it have any runtime usage?
  4. Where are the associated ANT integration code and config developed?
    • They are currently in "buildsystem", though the plan involved splitting much of it away into a separate Releng repository since most of the tools there don't need and in fact suffer from multiple branches.
  5. The earlier created oracleddlparser.git repository needs to be integrated into either the runtime or utils repository
    • Thus far it is dealt with as a separate dependency like javax.persistence, and it is my belief it would be detrimental to reintegrate it as there is no current reason to maintain the code in separate streams. - Eric
  6. How should the examples repository be structured?