| title | image |
|---|---|
Creating Modules |
../images/modules.jpg |
With the prototype mostly done, it's time to look over the code and do some refactoring. Things like the BeanEditTemplate, DatePicker and JSR303 validation would be useful in most any project. Libraries don't contribute to the application's lines of code, so it's time to separate the reusable code into a library.
Tapestry libraries are called modules and include an IOC configuration. The configuration class name is included in the META-INF package, allowing modules to just drop in and auto-configure. With the right project setup, modules enjoy all the same live class reloading goodness, so it's easy to develop libraries and an application at the same time.
The first step is to create a project template. The module template is exactly the same as an application. The POM file will build a jar instead of a war, and will include a step to write into META-INF. The IOC configuration class could be called anything, but by convention it's the module name followed by "Module".
Now it's just a matter of dragging files into the new project and some copy/paste into the new module class. One additional configuration is to the ComponentClassResolver which maps a prefix to a package containing pages/components/mixins. Adding the new module as a dependency in the application POM should cause Eclipse to hook everything together and just work -- except for one thing.
When running in the IDE there is no jar and thus no META-INF package, so Tapestry will not load the libraries IOC configuration. To get around this problem, the @ImportModule annotation can be added to the apps development module. This will inform Tapestry about extra IOC configuration when in development mode.
@ImportModule({TapestryDocumentationModule.class,HotelBookingDocumentationModule.class,JacquardModule.class})
public class DevelopmentModule {Now that things are progressing past the prototype stage, it's time to setup some kind of build environment. The first step is putting the code under revision control. Since these modules can be open source, the simplest choice is Github. There are plenty of build tools out there but Jenkins is easy and free. Jenkins is distributed as an application or as a war. Since these builds will be local, the application will work fine. Jenkins has a plugin for both Git and Maven so the build process is pretty simple create a project, add the Git url and a Maven build step. The application can be configured to build after the library, so library updates will trigger an application rebuild.
For simplicity, the libraries will have a snapshot target. This may not be the best idea when using 3rd party libraries, but in this case it should not cause any problems.
When working on a team with more than one person, it's nice to have a continuos build environment. With Jenkins this means a server somewhere. In this case, an AWS EC2 server with Tomcat is simple enough. This time, Jenkins will be installed as a war. The build configuration is the same with the addition of build step to deploy the new war into Tomcat.
Part of the build process is also creating the library jar file. For one-person projects, the standard Maven repository directory works just fine. But for multiple developer projects, some kind of shared repository is needed. The simplest way is to just put the jar files behind a web server that everyone can get to.
Artifactory is nice, and helps simplify development. Java projects have a reputation for being difficult to build. With Maven/Artifactory, it's possible to just checkout the project and have everything just work. To do this make sure Artifactory can satisfy all dependencies. The public ones are simple enough and enabled by default, and it's possible to add others if the artifacts are not in Maven Central.
Lastly it's possible to add things like JDBC jars and local libraries. Artifactory will also generate a settings.xml file. With that the setup becomes simple just get the settings.xml file, checkout the project and let Maven do the rest.
What about sharing the code with the world? In this case, the source is already on GitHub so why not share the jars on Maven Central? There are a few more steps involved, the first being that an account is required. Easy enough and that only needs to happen once. The next step is publishing snapshots. This step is pretty simple and can be useful for jars under heavy development, but at some point fixed releases are required for stable builds. It's possible to do the release procedure by hand, but it's a bit tedious so the best way is to automate it with Jenkins. The steps required are:
1: Increment version number 2. Build/Test the project 3. Sign the jar 4. Copy the jar file to Maven Central
At this point, the project is moving from prototype to development.