| Chapter 2 Install the XMA Development Environment | ||
|---|---|---|
 | 2.3 Compiling the sources of openXMA yourself |  |
| Chapter 2 Install the XMA Development Environment | ||
|---|---|---|
| | 2.3 Compiling the sources of openXMA yourself | |
If you are actively developing the openXMA framework and want to compile the sources of openXMA libraries and XMA plugins some additional settings are needed. The openXMA core projects are compiled with JDK 1.4.2.
For openXMA core development you need additionally:
Full Eclipse EMF 2.2.2 SDK. It can be found here: http://archive.eclipse.org/modeling/emf/emf/downloads/drops/2.2.2/R200702131851/. Our plugins expect to find EMF below ${PLUGINS}
antvariables.properties
In your Eclipse workspace you need a file called
antvariables.properties. In this file there has
to be defined a variable TOOLS. This variable must point
to a directory where a JDK 1.4.2 is residing in a directory called
jdk142. In our Ant scripts we use this variable in this
way:
<property name="java_rt" value="${TOOLS}/jdk142/jre/lib/rt.jar"/>This
might sound a bit cumbersome but this is our mechanism to ensure that
the openXMA sources are really compiled with a JDK 1.4.2 (with a JDK
1.4.2 compiler and standard library, to choose compile target "1.4" is
not sufficient for this).You have to check out the project openxmaParent
into your workspace to compile openXMA core projects, as all openXMA
build.xml scripts import a file from it:
openxmaParent/script/build_import.xml. In this file some
general settings are defined: Ant Tasks for Maven import, used JDK
version (see above), release directory for javadoc releases.
Checkout swt_maven_install.The
openXMA core projects are compiled against SWT 3.1.2 (we plan to
migrate to SWT 3.3 in the second half of 2008). SWT 3.1.2 is not part
of a public Maven 2 repository. This project's build target
installMavenLocal installs SWT 3.1.2 in your local Maven
repository.
Mapping of Drive Letters to URLs
Unfortunately the library wagon-webdav, which
enables the deployment to a remote Maven repository per Webdav, seems
not be able to work correctly with proxy settings (for this issue see
http://jira.codehaus.org/browse/WAGON-82).
As workaround we decided to map our Codehaus Maven repository URLs simply to drive letters (in the openXMA parent pom the distribution repositories are stated as drive letters). When a openXMA core project is deployed to its Maven repository then also its current javadoc is released to the Codehaus openXMA site. This copying of the javadoc is also done via a mapping to a drive letter. We are aware that this is a very Windows specific solution. If you known a more operation system independent one, please let us know. The following drive letters have to be mapped to this URLs:
X:\ https://dav.codehaus.org/openxma/
For openXMA documentation and javadoc releases
O:\
https://dav.codehaus.org/repository/openxma
The openXMA Maven repository at codehaus.org
P:\
https://dav.codehaus.org/snapshots.repository/openxma/
The openXMA Maven snapshot repository at codehaus.org
A comfortable way to map Windows drive letters to URLs per Webdav offers Novell Netdrive.It is a program available for downloading but cannot be downloaded directly at Novell. Simply search for netdrive.exe at the web. For example it is available there: http://www.phm.k12.in.us/Members/tjcarroll/netdrive.exe
Install it, configure your proxy in it (if one exists) and map the letters to the URLs as given above (choose connection type WebDav and state your Codehaus user and password).
Build targets of openXMA core projects:
installMavenLocal
builds and deploys the project in your local Maven repository. Use this target to build a new version for local testing.
deployMaven
builds and deploys the project to the public Maven Codehaus repository. Also copies the javadoc to the Codehaus openXMA site. Note, that the copying of the javadoc files to Codehaus can take some time. Use this target to release a new version to the public.
deployMaven_no_release_javadoc
builds and deploys the project to the public Codehaus
repository but does not copy the javadoc to the Codehaus openXMA
site. This target should be used for SNAPSHOT releases. (In a future
release deployMaven may be able to detect a SNAPSHOT
release and make no javadoc copying in this case).
This section describes what to do if you plan to release a new version of an openXMA core library.
Release Preperation:
local build
Make a local build with installMavenLocal. This
creates a version as specified in the project's
pom.xml and copies it to your local Maven
repository.
local testing
Test your new version (integration test as well as JUnit testing).
changes.txt and commit
Each openXMA project has a file called changes.txt under the path src/etc/. Committed changes in a project, bug fixes as well as new features, should be documented here (but you do not have to describe any commit here, only when a feature or bugfix is completed). Please state the affected files and a short description of the change itself. If a library changes its behavior or there changes in the dependencies (for example to newer versions of used libraries) this should be especially described. Also, if a new release with tagging is done this should be especially stated (e.g. build version x.y.z, tag x.y.z).
Release SNAPSHOT:
pom.xml - set version
Direct under the project directory there is the project's Maven pom.xml file. Before you release a project be sure that the right version is set in the pom.xml. Some projects have two pom files directly under the project directory (e.g. xmabootrt: pom.xml, xmacom_pom.xml; xma_runtime: pom.xml, xmartserver_pom.xml). In this case the right version has to be set in both pom files! Example:
<version>5.0.4-SNAPSHOT</version>
release a new SNAPSHOT version (Maven)
With deployMaven_no_release_javadoc a new
SNAPSHOT version is released to the public (to the public Maven
Snapshot Codehaus repository at http://dav.codehaus.org/snapshots.repository).
You can repeatly release the same SNAPSHOT version.
Release distribution version:
pom.xml - set version
Direct under the project directory there is the project's Maven pom.xml file. Before you release a project be sure that the right version is set in the pom.xml. Some projects have two pom files directly under the project directory (xmabootrt: pom.xml, xmacom_pom.xml; xma_runtime: pom.xml, xmartserver_pom.xml). In this case the right version has to be set in both pom files! Example:
<version>5.0.4</version>
release a new version (Maven)
With deployMaven a new version and its javadoc is
released to the public (to the public Maven Codehaus repository at
http://dav.codehaus.org/repository/).
A specific version can only be released once.
commit and tag a new version (SVN)
Commit your changes to the source repository. At least the pom.xml and changes.txt file must have been changed if a new version was released. Also tag the version in SVN (e.g. tags/V5_0_4).
update and commit the pom.xml to the next SNAPSHOT version
After releasing a project its pom.xml has to be updated to the next SNAPSHOT version. Also commit this change to SVN (you do not have to write this in the changes.txt file). For example you released a version 1.0.1. In this case you update the pom.xml to 1.0.2-SNAPSHOT or even 1.1.0-SNAPSHOT, depending at what is planned as next version.
Note for sIT Solutions development:
The release cycle described above does not distribute the version
to the shared directory as defined in sIT. For this you need the target
release_sit, as decribed in: sIT Solutions Specifics for Core Development
| |  | |
| 2.2 The Sample Application |  | 2.4 sIT Solutions Specifics for Core Development |