Development Lifecycle
Cschoenfeld (Talk | contribs) m (-) |
|||
| Line 23: | Line 23: | ||
# generate the OpenCms module structure from the source directory in such a way that classes from the source are compiled, put in a JAR and put into an output folder like <tt>build/system/modules/yourmodule/lib</tt>. The same would be done for JSPs, images and other files which need to get into the module. | # generate the OpenCms module structure from the source directory in such a way that classes from the source are compiled, put in a JAR and put into an output folder like <tt>build/system/modules/yourmodule/lib</tt>. The same would be done for JSPs, images and other files which need to get into the module. | ||
# synchronize the <tt>build</tt> folder with OpenCms. It should be taken as the RFS root for synchronization. | # synchronize the <tt>build</tt> folder with OpenCms. It should be taken as the RFS root for synchronization. | ||
| + | [[Category:Extending OpenCms]] | ||
Latest revision as of 20:21, 27 June 2007
If you are developing a module which relies on custom code you probably use an IDE like Eclipse, Idea or NetBeans. You probably also use the synchronization feature of OpenCms to synchronize your changes in the IDE with the OpenCms VFS.
This module development lifecycle has several phases:
- Edit Files in the IDE
- Synchronize to copy changes made in the IDE to the VFS
- Publish. You must publish if you changed
- a Java class or a Java classpath resource (/system/module/yourmodule/classes/)
- a Java library (/system/module/yourmodule/lib/)
- another resource which needs to be exported (e.g. in /system/workplace/resources/tools/yourtool/icons. They get exported to /resources in the Webapp folder).
- Deploy changes made to classes and resources which belong directly into WEB-INF (e.g. the configuration files in WEB-INF/config). This step is optional if all your modifications are within the boundaries of your module.
- Reload OpenCms or reinitialize the Workplace. You do not need to do this if you changed JSP files. They are reloaded automatically. However, you have to reload whenever you change
- a Java class or a Java classpath resource
- a Java library
- Test changes
If you develop a tool and your changes did not involve classpath relevant files it might suffice to reinitialize the Workplace (this function is available under Administration/Workplace Tools) instead of reloading OpenCms completely.
The above process implies that you have the structure required for an OpenCms module on your disk before you synchronize. You can achieve this by creating the module structure in your IDE or by having it generated.
The latter is certainly more complicated but integrates better with common development scenarios where you have a version control systen and build scripts. The idea would be to
- have a source directory which contains JSP files, classes and other resources in a structure you are used to or which your build system dictates. These files are typically stored in a version controlled directory. Please note that you cannot use such a directory for synchronization with OpenCms because it would import CVS or .svn directories into the VFS.
- generate the OpenCms module structure from the source directory in such a way that classes from the source are compiled, put in a JAR and put into an output folder like build/system/modules/yourmodule/lib. The same would be done for JSPs, images and other files which need to get into the module.
- synchronize the build folder with OpenCms. It should be taken as the RFS root for synchronization.
