Apache Muse - Source Code Repository and Build Instructions
Getting the Source Code
Web Access: The code repository can be browsed at http://svn.apache.org/viewcvs.cgi/webservices/muse/.
Anonymous SVN: The SVN URL for anonymous users is http://svn.apache.org/repos/asf/webservices/muse/. Instructions for anonymous access are here.
Committer SVN: The SVN URL for committers is https://svn.apache.org/repos/asf/webservices/muse/. Instructions for committer access are here.
Building the Release
To build the Muse distribution archives, you must install Apache Maven, Apache Ant, and a Subversion client on your system. With regard to Maven, we require version 2.0.4. After the installation make sure that mvn.bat (or mvn on non-Windows systems), ant and svn executables are in the search path (on Windows-like systems this would be in the %PATH% variable, on Unix-like systems this would be in the $PATH environment variable).
Once you have installed these three applications, simply download the build file to a directory where you'd like to create the Muse distribution and run ant from that directory. The build will use the Subversion client to pull down the latest files from the Muse repository (subsequent runs of the build will use your local copy of the files). When the build is complete, you can find the distribution archives in /dist.
If you are a committer and you want to make your build available as a snapshot or a release, ASF requires you to provide an MD5 sum and PGP signature for it. The Muse team has a script to do this - simply change the value of the KEY_NAME variable to your own name and provide your password when prompted by GNU PGP. The script will generate an .md5 and .asc file for each archive, as well as your KEYS file. These files must be included with every distribution.
Backwards Compatibility
Muse distributions are versioned with an x.y.z format, where x is the major version number, y is the minor version number, and z is the maintenance version number. For every major release x, subsequent distributions with a major version of x (x.1.0, x.2.0, x.2.1, etc.) are guaranteed to offer compatibility for public Java interfaces and the public methods of Java implementation classes. Private and protected methods in Java implementation classes do not have guaranteed compatibility.
The guaranteed Java interfaces, classes, and methods can be found by reviewing each distribution's JavaDoc. Different major versions may cause compilation errors due to API changes. If such changes are made, they will be documented separately in the release notes in order to ease migration.
Eclipse Development
You can build the individual Muse modules within Eclipse by creating a Java project for each module and downloading the appropriate section of code into each project. The Muse team has tried to make this very easy by creating an entire set of Eclipse projects that you can import into your workspace and that are pre-configured with all of the right Subversion metadata. Please follow the steps below to set up your Eclipse environment with the latest Muse source code:
- Download the Eclipse projects.
The .zip file should be extracted to whatever workspace you will use for Muse development.
- Select File > Import > Existing Projects into Workspace and traverse to the directory
that has all of the Muse Eclipse projects. Click Select All and then Finish.
- You now have all of the projects you need, but no code! To download the code, highlight all
of the projects, right click, and select Team > Update. This will issue the Subversion
command to download any new code from the repository (in this case, that means all of the code).
- You're all done! Whenever you want to build an individual module into a JAR file, you can
right click on the /build/build.jardesc file in each project and select Create JAR.
This will allow you to compile your code without having to run Maven or the entire Muse build process.
You can also keep up-to-date on the latest changes to the code base by performing the Subversion update at any time. Doing this at least once per day ensures that you're always working off the same code as the development team.