- Organizational Standards and Conventions
- Putting the "Engineering" in Software Engineering
- Working with Logging and Tracing
- Project and Packaging File Structure
- Unit Testing Requirements
- Code Completion and Review Process Requirements
- Communicating the Vision the Wiki Way
- Conclusion
- Links to developerWorks Articles
- Reference
This chapter is from the book
This chapter is from the book
This chapter is from the book
Project and Packaging File Structure
Some basic guidelines for packaging structure are necessary for ensuring consistency across multiple applications and projects within the organization. Without these initial guidelines, everyone will do his or her own thing. Deployment teams within large organizations indicate that often every single application has its own deployment quirks because the teams all took different approaches to packaging.
Actually listing out the directory structure for how applications will be packaged within your environments might be useful. This list would include JAR, WAR, and EAR files to ensure a standard for everyone to follow. In addition, be sure to document specific requirements; for example, the location of JSP files within the Web Archive. The following are some guidelines for project packaging:
- JSP files should reside in a folder that maintains the package naming structure of the application.
- JSP folders should reside within the WEB-INF folder in the WAR file for security purposes.
- The EJB JAR modules and Web WAR modules comprising an application should be packaged together in the same EAR module.
- Utility classes used by a single Web module should be placed within its WEB-INF/lib folder.
- Utility classes used by multiple modules within an application should be placed at the root of the EAR file.
- Utility classes used by multiple applications can be placed on a directory referenced via a shared library definition.
Many teams are looking for additional guidance in how to design applications for proper packaging. I recommend looking to the development team to see how they are doing things now, and how they can be changed for the better. The more you involve the people who actually perform this function the better off your projects will be.
Using External Libraries
The use of third-party and open source libraries must be handled a little differently from other standards within your organization. The main challenge is that trying to guess at all the requirements your development teams may encounter is simply too hard. As such listing all the libraries they may need is difficult. The two schools of thought on the matter are as follow:
- Option 1: Let the application developers package their third-party libraries within the archive file for deployment.
- Option 2: Try to build out shared libraries that everyone can use and depend on.
The reality is probably somewhere in the middle, but personally I like to know what the developers are using and why, even if it does end up packaged in a WAR or EAR file. Logging APIs is a perfect example. Without a little oversight more logging libraries and copies of the same set of libraries will sneak into your system, causing you to lose the control you so nicely put in place earlier in this chapter and possibly causing unexpected class loading conflicts.
One cause of this proliferation of libraries may be the developers’ lack of knowledge or misunderstanding of what features are already available either through WebSphere itself or currently deployed shared libraries within the system. WebSphere shared libraries (see Figure 2.4) help reduce the number of libraries within a system by allowing multiple applications to use them.
)
Figure 2.4 WebSphere shared libraries
Versions of specific libraries should be standardized once they are used within the system. You don’t need every team using a different version of some function. Occasionally, a team may need to use a specific version of an API, but it is probably not the case for all your teams. Special approval can be made on a case-by-case basis to package a particular version with the application if necessary. The key point is to be aware of what libraries are being used by your applications. Understand and document what is being used and why, so you are not surprised when problems occur.
When a team makes a request to use a library, the architecture or governance team should be ready to respond quickly. Development teams do not have time to waste—time is of the essence. Remember you are there to serve the development team, not the other way around, so a quick response, discussion, or approval will ensure that the next request follows the same channels and the development team does not try and circumvent the system.