Portlet Factory, Version 6.1.2
Versioning artifacts
If you want the ability to recreate the application over the long term, it is important to capture all of the artifacts used by the project. There is obviously a continuum of software layers involved, (operating system, JVM, Eclipse, and WebSphere Portlet Factory Designer, for example). You should at least capture in some manner the critical software pieces needed to enable a modification in the future. Creating a CD, DVD or other media provides a way to capture a snapshot of most of these underlying layers as well as the project artifacts.
At a project level, you have the following choices for what to place under version control.
- Entire project
- Check in the entire project. Here source control exactly mirrors your working directory structure. This approach is easy, but depending on the features and performance of your source control system, it may prove to be too slow or cumbersome to use. Also, if you have a very large development team, this approach consumes much space on your server.
- New and modified files
- Check in only the files you create or modify in your project. When you create a project, it includes WebSphere Portlet Factory shipping files, source files, and all generated files. Create your own folders in which to store the models, HTML files, Java classes, and other files that you create for your projects.
Only your source files and generated files remain in the project. You can check in the generated files (not recommended) or they can easily be created from the source later if you are trying to reproduce this exact environment. Generated files are located in the WEB-INF/factory/generated/ folder. Using this technique, you can have source files in source control and have each developer install the same version of WebSphere Portlet Factory and any other shipping software needed for the project.
If you use a Shared Team Project in source control and check in only new or modified files, setup a Proto-Project in your source control system that contains all the artifacts you share across team members and do not expect to modify (Jars, builder defs, properties). That way you can create a project for a new team member by simply combining the Proto-Project and the Shared Team Project. There are many variations across these two dimensions (what to capture and how to shape it), of course.
At the very least, these are the project artifacts you should store in your source control system.
- Model files in WEB-INF/models/*.model
- Profile set files in WEB-INF/profiles/*.xml
- HTML files (*.htm, *.html)
- JavaScript libraries, CSS and XSL stylesheets (*.js, *.css, *.xsl)
- Image files (*.jpg, *.gif)
- Configuration files (*.properties, *.xml, and Java resource bundles, for example) except at the top level of the project.
- Java source files in WEB-INF/work/source/*.java
- Custom (client-specific) JAR files
- Custom builder definitions in WEB-INF/builders/*.bdef
- Custom Profile Selection Handler files in WEB- INF/config/selection_handlers/*.xml
- Build scripts for the project
- Project documentation
Do not capture or store in source control the following artifacts.
- Generated project artifacts
- It is not necessary and not recommended that you capture and control artifacts that are generated by the WebSphere Portlet Factory regeneration process (JSPs, Java classes, schemas). These are exactly like the binary outputs of compilers. If you preserve the source files (models, profiles, and builders, for example), the generated artifacts are always reproducible. Generated Java files are located in WEB-INF/factory/generated; generated JSPpages are located in the /genjsp directory; generated Java classes are located in WEB-INF/factory/generated/genjava.
- Property files
- For Shared Team Projects, do not store in source control the property files at the top level of your project (.bowstreet, .classpath, and .project). These are user and system specific.
Parent topic: Deployment for development
Library | Support |