Skip to main content

Jar metadata for dependency handling

4 replies [Last post]
Joined: 2005-12-22

Is there any possibility to include some kind of dependency metada inside Jars?

What I mean is something like pom.xml files from maven that could be used to determine wich library dependencies are needed with one jar. Maybe the pom.xml could be added inside the jars.

Jar dependency data is necessary for each new project and maven pom files are becoming a standard. However pom files are separate from jars, which makes them easy to edit but difficult to mantain with or distribute with jars.

I'm asking if it's possible to make it standard. So each jar would be like a "integrated circuit" that can be plugged on my application if I have the necessary "connectors" (or dependencies).
For example, any jar could be verified by the VM when loading to check missing, duplicated or wrong jar versions.

-The added metadata should tell information about the jar itself, and about dependencies (just like maven does).
-The metadata should be calculated (or gathered) when assembling a new jar, based just on neccessary dependencies, not every dependency available on classpath.

What do you think? Flaws or strengths?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2007-08-30

See "JAR File Specification - JAR Index" in and "i option" in . I think, if index file present in your JAR file, class loader quickly find all your JAR file and other JAR files classes, because all jar index files automatically is on the classpath.

Joined: 2005-12-22

Thank you very much for your answers.

The above mentioned specification is pretty near to what I was asking. Still I don't see jar version numbers included in the index file (Am I right?).

Do you know why this indexing scheme is not currently used by the community?

Joined: 2007-08-20

There is nothing preventing you from imbedding a pom.xml file in the META-INF section of the jar (or for that matter anywhere in the jar). But to take advantage of this you would either need an special class loader, or an reworked java launcher. This becomes an issue, especially if you have to distribute your application to clients. In this java suffer from a fundamental flaw: it is just too flexible. Jars can be placed anywhere. Class paths have to be set up explicitly, instead of following convention.

If you really hava a need for this consider using a special class path loader which knows how to download dependencies into some kind of central repository. I'm sure you should be able to bastardize the maven code, combine it with a class loader. Package the whole thing as an jar, and create either a native launcher for windows, or if you are fortunate to work on unix/linux use a simple bash shell.

Hope this helps.

Joined: 2003-06-10

If you have a look at the JAR specification you will see that attributes are already specified to define some dependency information. There is the version of the jar file itself, a classpath (of other required jars), and a list of required extensions with minimum versions.
Unfortunately this seems to be rarely used and support is inconsistent. WebStart, for example, ignores the ClassPath attribute. OK maybe it has to, but it isn't a good start. I don't know if using pom.xml would have similar issues with WebStart.