Saturday, September 26, 2009

Using Eclipse With Large Code Bases, Part V

Previous posts described how to use file-system links and various Eclipse features to make a large, single-rooted source tree look like a set of smaller, multi-rooted Eclipse projects.

But there's a catch: the Perforce Eclipse plugin doesn't work, because the Perforce client spec specifies the root of the actual source tree on disk, but the Eclipse Perforce plugin thinks the source tree is rooted at the directory that contains the Eclipse projects.

For example, if we start with this client spec:
Client: originalclient
Root: C:\
//trunk/src/... //originalclient/src/...
and use links to create this Eclipse structure:
child1 → linked to
child2 → linked to
then the Perforce root is C:, but the Eclipse Perforce plugin thinks the root is C:\projects.

To fix this, we updated our link-generation script to generate a second client spec, where the client spec's root is the directory that contains the Eclipse projects, and the client spec maps individual sub-roots to their counterparts in the Eclipse projects (a one-for-one mapping between Perforce and the links):
Client: myclient
Root: C:\projects
//trunk/src/com/parent/child1/... //myclient/Child1/src/com/parent/child1/...
//trunk/src/com/parent/child2/... //myclient/Child2/src/com/parent/child1/...
Note that although we have three different "views" of the source tree (two in Perforce and one in Eclipse), there is only one actual occurrence of each source file on disk, which means changes are kept in sync among all three views.

So if Perforce can do this mapping, why do we need the links at all? In many cases, you might not. In our case, though, the file layout in Perforce is really complicated, and it would be painful to create a client spec that maps all of the files to the file system. For example, there are sixty or so files at the very root of the Perforce tree, and these would have to be mapped to a directory on disk while using client-view exclusions to prevent mapping everything else in the root to that same directory. For us, it's easier to use the second client spec to map only the files we need in Eclipse--and to map them to directories that are actually links into the full tree.

A Powerful And Flexible Java Dependency Analyzer

An earlier post evaluated two Java dependency-analysis plugins for Eclipse. Both plugins are very good at providing an interactive, dynamic view of the code, which allows a programmer to explore dependencies and evaluate the impact of changes.

Recently I had a different requirement: generate reports that summarize dependencies, and provide those reports to management in a format that doesn't require having the code or Eclipse available.

A bit of googling brought up Dependency Finder, which turned out to be an excellent tool--scalable, fast, flexible, well-documented, and easy to install. It comes with a set of reports, with numerous options, and it can be customized to produce specialized reports. It also has a GUI, although that wasn't needed for what I'm using it for.

Support is excellent--a question to the author was answered within a few minutes.

Saturday, September 12, 2009

Test Utils are now open-source

At work, we've been encouraged to find ways to open-source technologies that are useful but aren't core to our business.

While writing unit tests over the past several years, I developed some utilities that make it easier to perform some common test tasks, particularly when used with JMockit and EasyMock.

The utilities are now available as open source.

Update: The genius who develops JMockit has added so many features it's not necessary to use reflection to populate fields, so there's no need for TestUtils to be used with JMockit. TestUtils are still useful with other mocking tools, and when you just want to use reflection for something in a test where you aren't using mocking.