Question

While downloading Google Guice I noticed two main “types” of artifacts available on their downloads page:

• guice-3.0.zip; and
• guice-3.0-src.zip

Upon downloading them both and inspecting their contents, they seem to be two totally different “perspectives” of the Guice 3.0 release.

The guice-3.0.zip just contains the Guice jar and its dependencies. The guice-3.0-src.zip, however, did not contain the actual Guice jar, but it did contain all sorts of other goodness: javadocs, examples, etc.

So it got me thinking: there must be different “configurations” of jars that get released inside Java projects. Crossing this idea with what little I know from build tools like Ivy (which has the concept of artifact configurations) and Maven (which has the concept of artifact scopes), I am wondering what the relation is between artifact configuration/scope and the end deliverable (the jar).

Let’s say I was making a utility jar called my-utils.jar. In its Ivy descriptor, I could cite log4j as a compile-time dependency, and junit as a test dependency. I could then specify which of these two “configurations” to resolve against at buildtime.

What I want to know is: what is the “mapping” between these configurations and the content of the jars that are produced in the end result?

For instance, I might package all of my compile configuration dependencies wind up in the main my-utils.jar, but would there ever be a reason to package my test dependencies into a my-utils-test.jar? And what kind of dependencies would go in the my-utils-src.jar?

I know these are a lot of tiny questions, so I guess you can sum everything up as follows:

• For a major project, what are the typical varieties of jars that get released (such as guice-3.0.zip vs guice-3.0-src.zip, etc.), what are the typical contents of each, and how do they map back to the concept of Ivy configurations or Maven scopes?

Answer 1

The one you need to run is guice-3.0.zip. It has the .class files in the correct package structure.

The other JAR, guice-3.0-src.zip, has the .java source files and other things that you might find useful. A smart IDE, like IntelliJ, can use the source JAR to allow you to step into the Guice code with a debugger and see what’s going on.

You can also learn a lot by reading the Guice source code. It helps to see how developers who are smarter than you and me write code.

I’d say that the best example I’ve found is the Efficient Java Matrix Library at Google Code. That has an extensive JUnit test suite that’s available along with the source, the docs, and everything else that you need. I think it’s most impressive. I’d like to emulate it myself.