I've spent a good amopunt of time over the last couple of days trying to come up with a strategy for integrating PKI development with Eclipse. I've learned a great bit in the interim and I'd like to share. I'm also soliciting some guidance on how to proceed. First, what I've learned: There are aspects to our cmake system that we are not documenting in the Development section of the website. Probably the most basic is how to do incremental builds, which will really speed up certain aspects of development. If you have the code checked out to ~/workspace/pki, the rpms will be built in ~/workspace/packages and related directories (packages.core, packages.kra and so on). It is not necessary to install the RPMs in order to compile the code. One approach would be to create a directory structure parallel to what the RPM compose scripts do: mkdir workspace/build-pki mkdir workspace/build-pki/core mkdir workspace/build-pki/kra then to compile the core code: cd ~/workspace/build-pki/core cmake -DVAR_INSTALL_DIR:PATH=/var -DBUILD_PKI_CORE:BOOL=ON ../../pki make A comparable set of lines for KRA is cd ~/workspace/build-pki/kra cmake -DVAR_INSTALL_DIR:PATH=/var -DBUILD_PKI_KRA:BOOL=ON ../../pki make These lines can be found in the spec files, under the build sections. For example, in pki/specs/pki-core.spec cd build %cmake -DVAR_INSTALL_DIR:PATH=/var -DBUILD_PKI_CORE:BOOL=ON .. %{__make} VERBOSE=1 %{?_smp_mflags} CMake generats the Makefile etc in what it refers to as "OutOfSource" mode. This means that, while Make is executed in workspace/build-pki/core, the source remains in workspace/pki/base/core. This is a "best practice" to keep the Generated files separate from the revision controlled files. The PKI CMake setup insists on building the code outside of the source tree. This is enforced by the line pki/CMakeLists.txt line 69 include(MacroEnsureOutOfSourceBuild). Changes made in the original source tree are picked up via Makefile rules. This includes changes to the CMake infrastructure, meaning that configuration changes trigger a complete build. This is one of the positive aspects of CMake. CMake knows about eclipse, and has support for generating a project file for C and C++ Development. To configure this: cd ~/workspace/build-pki/core cmake -DVAR_INSTALL_DIR:PATH=/var -DBUILD_PKI_CORE:BOOL=ON -G"Eclipse CDT4 - Unix Makefiles" ../../pki/ This can then be imported into Eclipse. However, the project is a CDT project, not a Java project, and is not really a good match for Java development. Some of the shortcomings are that it does not provide automated refactorings or Type navigation. Ideally, we would have separate projects for the C code and the Java code, and let each live under the rules most appropriate to it. This is where the request for guidance comes from. I think the right approach is to modify the CMake approach to split out the C code from the rest of the Java code. The native tools can still remain in the same source RPM, but would have their own build step, something like: cmake -DVAR_INSTALL_DIR:PATH=/var -DBUILD_PKI_NATIVE:BOOL=ON make For Java development, I'd ideally like to run an embedded tomcat. I'm not there yet: I think I need the target code in the form of a web archive, in the format that it lives in under /usr/share/pki/ca/webapps. This structure is set up by cmake baswed on the code in base/ca/CMakeLists.txt, but does not, as far as I can tell, show up in the target tree. I suspect that the approach would be to redefine the install directory for a cmake invocation to be the same as the build directory, or some other non-system owned directory. Making a Java project throws another curveball here. Since a Java project can't yet be autogenerated from CMake, it probably makes sense to check in the .project and .classpath files used. I've submitted one patch in the past that puts the whole tree into as single project. I could see continuing on this approach, and removing the C files from the build tree so that the CDT project. Even better would be to create one project per end RPM, or jar file, and collect them up into a single Eclipse workspace, and/or working set. I think that this is the right approach. I have set separate Java projects for base/ca base/common base/console base/java-tools base/ocsp base/silent base/symkey base/tks base/util base/tps Should be a CDT project as well. This is pretty well supported: cmake -DVAR_INSTALL_DIR:PATH=/var -DBUILD_PKI_TPS:BOOL=ON -G"Eclipse CDT4 - Unix Makefiles" ../../pki/