Versions Compared

Old Version 167

changes.mady.by.user Runhua Chi

Saved on

compared with

New Version 168

changes.mady.by.user Russell E Glaue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added a note about a general risk in building from trunk when in SNAPSHOT release, per a recent thread discussing the need for such a general warning to user not knowing about the nature of SNAPSHOT releases.

...

  • server/trunk
  • server/branches/3.0-beta
  • server/branches/2.2
  • server/branches/2.1
  • server/branches/2.0
  • server/branches/1.2 (not tested recently)

...

a general warning about the state of trunk
The source code in server/trunk typically will be in SNAPSHOT release, as opposed to a final release. E.g. 3.0-SNAPSHOT versus 3.0-beta. The community typically finalizes the version from SNAPSHOT release to a regular release when it is branched out of trunk. E.g. branch server/trunk to server/branches/3.0-beta.

Please be aware that when building Geronimo from trunk while in SNAPSHOT release the source code typically depends on the SNAPSHOT releases from all dependency projects. There are two risks from this matter-of-fact:

  1. Other projects release SNAPSHOTS on a daily basis. Every day you would build Geronimo, the build process will download an build against newly released artifacts.
  2. The nature of SNAPSHOT releases is that they are the latest development builds. Though they will be compiled and released, they are not necessarily error free. Additionally, SNAPSHOTS are actively developed and may introduce some new feature or API that might cause Geronimo to fail during its own build.
  • Due to the nature of item #1, item #2 may occur on any future day, and item #2 may persist for an unknown amount of time until issues are corrected.
    The Apache Geronimo community works with dependency projects to resolve issues that prevent Geronimo from building or passing tests, but this is not always resolvable in a speedy fashion. Sometimes the Geronimo community must make dependency changes to resolve issues with pother project's artifacts that persist with issues that go unresolved.

To help mask issues like these that can surface, you can setup a local maven proxy repo (like with nexus) and control what artifacts are downloaded and used in the build process. The local proxy repo performs the download of 3rd party artifacts Geronimo depends on, and the Geronimo build process obtains the artifacts from it. In doing this, artifacts that causes issues can be rolled back to a previous version, or instead you can control what new and updated artifacts are downloaded from the remote repositories for the Geronimo build process to use.

Prerequisites

Build Machine

...