Frequently Asked Questions

The goal of Glean is to make code feedback easy in a couple of different ways:

    
• to let you add or remove feedback tools easily for a given project
• to let you run these tools against any project you have

The first point means that you can easily try out different tools, change your mind, and experiment with what particular feedback is most valuable for your project. For many of the tools, it's as simple as adding the tool's name to the tool.pattern property. The Glean tool scripts are boilerplate Ant script for each tool, often just the one that most anyone would need to write if they were going to use that tool. For most people, this is a good starting point, and with Glean the time needed to try out a tool is minimal. And if the standard boilerplate values aren't just what you want, there are property values that you can override with standard Ant property overrides.

The second point means that you can have a consistent feedback process across any number of projects. You define your project layout with some properties, and then these are used by each of the tools. Since Glean can sit outside of your project build, gathering feedback from a set of projects is simply a matter of pointing Glean at each of their properties settings.

If you already have that flexibility in your build scripts, then you are ahead of the game, and may not need Glean. Then again, if you want to simplify your build scripts, you can let Glean take over the feedback responsibility.

If you are using Maven, then you already have a flexible, extensible system for plugins. Glean is aimed at giving something of that flavor to folks who use Ant.

For the individual developer, it does make the feedback loop potentially longer. The more immediate feedback you can get the better. However, it's going to be hard to get consistent feedback from your IDE for everyone on the team, nor do some people want to put more of a burden on their IDE than it already has. By all means, use IDE plugins to get feedback, but there is a lot of value to the project as a whole to have a more independent set of feedback that everyone can look at.

The tools that Glean can drive are listed on the tools page. You can also look in the tool directory of the release. Each tool has its own directory in there.

If your favorite tool isn't part of Glean, either drop me a note or try creating a script on your own. There is a template build.xml in the templates directory, and some basic instructions for how to write it. If it works for you, I would love to hear about it and add it in to Glean for others to use.

With the current release of Glean you cannot specify multiple source folders. A big part of the reason for this is that most of the tools that Glean drives have you specify the source or class files as a fileset, and a fileset only lets you specify a single directory. Without bringing in other libraries or scripting languages for iteration, there isn't much to do within the confines of the Ant language.

For now, you have a couple of choices:

    
• create multiple project property files for Glean, and run each one separately
    
• modify your build script to create a pseudo-project area, with all of the source files copied in to one tree. You can then point Glean at that area.

The ideas behind Glean developed from working on a project where there were many component parts to the application, and generating feedback for the entire codebase was an important part of the daily build. That feedback process, however, was very much tuned for that application, but even there the feedback was not truly aggregated. For Glean, I wanted to generalize some of the ideas, start simple and grow. Part of that meant focusing on the single-source tree case first. I know others would like to see the a solution to the multiple-source scenario, including myself, it just may take some time.

Some of the tools that Glean runs work against artifacts of a build, such as .class files or test output. If the project directory that Glean is pointed to doesn't have these artifacts, the tools skip over them.