This article presents a hack for sharing JSPs across multiple web projects within WSAD. It uses the external build tool mechanism to invoke an Ant script that perform workspace copy operations necessary to refresh referencing projects. |
I've seen the soft-link capability of Rational ClearCase used to accomplish this when ClearCase was the underlying source control tool. For each project wishing to reference the content of the shared project, soft-links are created to reference the shared JSPs. This solution is flexible with respect to the selection of the shared files. To override the shared copy, simply replace the soft-link with an actual file.
A labor intensive alternative would be to simply copy the JSPs from the shared project to referencing projects that use these JSPs. Whenever content of the shared project changes, it would have to be copied to every referencing project. This is more aggravation than even the avid re-use fanatic is willing to endure. But with the external build tool mechanism of the Eclipse platform and a simple Ant script, much of this manual labor can be automated.
In our example, the shared project is named FirstCommonJSP. Its organization is illustrated by the Eclipse Navigator view screen-shot on the right. There are a few things to note.
By keeping the Ant script in the project that contains the files to be copied, the manner of the sharing of files can be managed together with the files to be shared.
The builders are listed in the order that their associated actions are carried out at build time. As the New button implies, additional builders can be configured to run at build time. You can either specify an executable program with arguments or specify the target of an Ant script. These additional build configurations are known as external tools builders. The figure above shows the builders for a web project. In this screen shot, only the first builder is user-defined (shown with an Ant icon). All the others are defined by plugins.
For our present purpose, we will configure an external build tool to reference an Ant script that performs a copy operation. Using special build tool variables, we can specify the source and target of the copy operations. We will also be able to specify for which builds we want the Ant script to run.
1 <project name="GetContent" default="CopyContent" basedir="."> 2 <target name="CopyContent"> 3 <echo> Running CopyContent </echo> 4 <echo> target = ${targetProject}/WebContent </echo> 5 <copy todir="${targetProject}/WebContent" overwrite="true" > 6 <fileset dir="WebContent" excludes="**/CVS/*"/> 7 </copy> 8 </target> 9 </project> |
Its only task is to copy some files from one directory to another. Hence the default target in line 1 is the only target, namely the CopyContent target whose definition begins on line 2. Lines 3 and 4 are simply print statements. The actual copy task begins on line 5, the most important line of this simple script. Note that the todir parameter is set to the targetProject variable that was set in the external tool builder configuration described below. This is how the script knows the destination of the copy.
Also in line 5, the overwrite attribute of the copy command has been set to true. This is contrary to the default, which will only copy a file in the fileset if the source file is newer than the destination file. This is to ensure that the destination files are always the same as the source files after the copy operation. But in our case, the two timestamps may not be related. So a brute force copy operation is done regardless of timestamp.
Line 6 provides an example of excluding certain items in the copy operation. In this case, we exclude the CVS metadata since we certainly don't want that getting mixed-up between projects.
Line 1 also contains a basedir attribute. By setting it to "." we are setting the base directory to the directory in which the Ant script resides. This has an implication for the dir attribute in line 6. The value of "WebContent" means the WebContent directory relative to the base directory specified in line 1. This does not apply to absolute directory values, such as the todir attribute in line 5.
-DtargetProject="${project_loc}"The ${project_loc} is a special variable populated by the Eclipse external tool mechanism. At runtime, its value will be the absolute path name of the project that was selected when the Ant script was invoked. In our case, this will be the project that is the target of the copy. To view a list of such available variables, click the Variables... button.
Be sure to place the project location in double quotes. Otherwise, if it expands to something with spaces in it, the Java command line interpreter (that runs Ant) will get confused.
The Capture output is not really necessary. It causes output to be sent to the console view. It's nice to have for the first few builds as an indication things are going well. If it bothers you, uncheck it.
Our external build tool is just such an external process. If we ran it independently from the command line, we'd have to manually select the affected folders in Eclipse and invoke the refresh. This refresh panel allows us to specify an automatic refresh. The various options allow us to limit the scope of the refresh. Too large a scope takes too much time. Too small a scope doen't refresh everything that was changed.
Check both boxes
Chose ${project} as the scope. Our script doesn't
change anything outside the project.
Note: If you see a red X on the Target tab, see the Troubleshooting Guide below.
are chosen. Do not choose "Auto builds". This will cause the build to run each time a change to the project is saved. This is usually too often. It can cause the build to run when you don't intend or want it to.
To invoke the configuration builder with these settings, select the project to build in the navigation panel and choose Project --> Rebuild Project as shown below.
1 <copy todir="${targetProject}/WebContent" overwrite="true" > 2 <fileset dir="WebContent"> 3 <exclude name="**/CVS/*"/> 4 <exclude name="**/WEB-INF/**"/> 5 <exclude name="**/META-INF/**"/> 6 </fileset> 7 </copy> |
In the example above, we added excludes for the WEB-INF and META-INF directories. This could be useful if you made your shared project a Web project.
It's instructive to compare this example with the original file. Line 6 of the original file shows an excludes attribute of the fileset tag. This is a convenience mechanism which is handy when you only have a few to list. A comma is used as a separator for multiple excludes. An alternative is to list each exclude on a separate line. For this, the excludes attribute of the fileset tag gives way to a separate exclude tag (note the tag name is singular, the attribute name is plural). This can make a list of excludes easier to read.
The following steps provide a work around.
From this stage, you should be able to perform any edits you wish.