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

EclipseLink/Build/NextGen/BuckminsterEval

< EclipseLink‎ | Build‎ | NextGen
Revision as of 12:06, 4 April 2011 by Eric.gwin.oracle.com (Talk | contribs)

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

Buckminster evaluation

Upon review of the requirements and the tools available it has been decided to go forward with a proof-of-concept based upon Buckminster/PDE/Ant. Since buckminster seems to have the desired combination of scope, capabilities and flexability; while PDE is the same tool used by developement; and Ant can easily fill in any gaps. While it is possible that the combination of Buckminster/Tycho/Maven may be the ultimate iteration to fully replace the current shell/Ant system.

Issues needing resolution

Items identified that need technical resolution:
  • How to specify inclusion of jar artifacts?
    • Separate P2 repo (Still resolving "below threshold")?
    • URL Reader (matcher appears to be buggy)?
  • How is a component jar actually created?
    • PDE may do it. How to specify it must be done? Need .project regen?
  • What issues are there with running our tests?
    • Combination of Non-standard frameworks using junit, junit tests, and ant fixup of result "path" strings.
    • Test suites can be run as simple junit test (Tom does regularly)
    • Also theoretically possible to invoke using Ant.
  • How to specify/generate standalone zips and POJO jars?
    • Presume using Ant or Maven. Need driver mechanism.. mspec?
  • How to setup to only build component if "necessary"?
    • Will this require further breakup of the build, or can intelligence be built in?
    • Can we assume component code change won't require downstream component recompile?
Items found that will need group resolution/discussion include:
  • PDE/SVN integrations assume a flat project structure (trunk/org.eclipse.persistence.core). Fully integrating with these tools will require a SVN restructuring
    • Buckminster SVN integration assumes trunk/tags/branches followed by component structure (trunk/org.eclipse.persistence.core).
      • It may be possible to write a custom resolver to deal with our current system though (to allow our component divisions).
      • Also the branches/<branch>/trunk structure we are using is non-standard and will need to change.
        • Changing this will mean incompatibility with old build sysytem while new system is built.
  • Once development is in Eclipse exclusively, we will NEED to be able to develop (edit code) via SVN through the firewall.
    • How to set this up will need to be resolved and clearly documented.
      • Mike N. hss done this. Needs to be clearly documented, tested and publicized.
  • Buckminster and PDE appear to allow date or revision qualifiers, but not both (.v<DATE>-r<REVISION> not supported).
    • It may be possible to write a custom versioning scheme though.
Results of Group Meeting

The concensus was that the work involved seemed to outway any benefit, and other options namely Tycho were in need of further evaluation.

Back to the top