...
server/trunkserver/branches/3.0server/branches/2.2server/branches/2.1server/branches/2.0server/branches/1.2(not tested recently)
...
other relevant documentation
The Geronimo community also maintains build documentation specific to each Geronimo version. While the community attempts to keep all these related docs in sync with each other, you may find some varying information among them.
the community attempts to keep all these related docs in sync with each other, you may find some varying information among them.
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:
- Other projects release SNAPSHOTS on a daily basis. Every day you would build Geronimo, the build process will download and build against newly released artifacts.
- 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 other 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 repository performs the download of 3rd party artifacts Geronimo depends on, and the Geronimo build process obtains the artifacts from the local proxy repository. In doing this, artifacts that causes issues can be rolled back to a previous version, or instead you can pause updates on certain problem artifacts by controlling which are updated from the remote repositories for the Geronimo build process to use.
Prerequisites
Build Machine
...
You will need to figure out which repository the artifact is available from. Look in the BUILD_ROOT/pom.xml file within the <repositories> tag to see the primary repositories utilized. You can also review the build output to see where maven attempted to download the artifact from.
Overriding libraries provided by JVM
...
at compile time
In some cases, Java EE 6 requires newer library versions then what is provided by Java SE 6. For example, EE 6 requires annotations 1.1 api but SE 6 provides annotation 1.0 api. So it is necessary that during a build we override the JVM provided libraries with newer versions.
...