<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.0.9">
</HEAD>
<BODY>
On Sat, 2004-10-09 at 09:49, Elliotte Harold wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#737373"><I>Ken Roberts wrote:

&gt; 
&gt;     &lt;!-- the old part
&gt;     &lt;jar jarfile=&quot;${build.dir}/${name}.jar&quot;
&gt;          basedir=&quot;${build.dest}&quot;
&gt;          excludes=&quot;META-INF/MANIFEST.MF&quot;
&gt;          manifest=&quot;${build.dest}/META-INF/MANIFEST.MF&quot;/&gt;
&gt;     --&gt;
&gt;     &lt;!-- the new part --&gt;
&gt;     &lt;property name=&quot;version&quot; value=&quot;1.0&quot;/&gt;
&gt;     &lt;property name=&quot;vendor&quot;  value=&quot;jdom.org&quot;/&gt;
&gt;     &lt;jar jarfile=&quot;${build.dir}/${name}.jar&quot;&gt;
&gt;       &lt;manifest&gt;
&gt;         &lt;attribute name=&quot;Built-By&quot; value=&quot;${user.name}&quot;/&gt;
&gt;         &lt;!--Make something for the whole jar--&gt;
&gt;         &lt;attribute name=&quot;Specification-Title&quot;   value=&quot;JDOM Classes&quot;/&gt;
&gt;         &lt;attribute name=&quot;Specification-Version&quot; value=&quot;${version}&quot;/&gt;
&gt;         &lt;attribute name=&quot;Specification-Vendor&quot;  value=&quot;${vendor}&quot;/&gt;
&gt;         &lt;attribute name=&quot;Implementation-Title&quot;   value=&quot;org.jdom&quot;/&gt;
&gt;         &lt;attribute name=&quot;Implementation-Version&quot; value=&quot;${version}&quot;/&gt;
&gt;         &lt;attribute name=&quot;Implementation-Vendor&quot;  value=&quot;${vendor}&quot;/&gt;
&gt;         &lt;!--Make something for the individual nested packages--&gt;
&gt;         &lt;section name=&quot;org/jdom/input&quot;&gt;
&gt;           &lt;attribute name=&quot;Specification-Title&quot;   value=&quot;JDOM input 
&gt; classes&quot;/&gt;


Why do you call out the individual packages separately here? Wouldn't it 
be enough to have one batch of attributes in the main section? It's not 
as if the individual packages are versioned separately from the main 
release.

Also, could you please elaborate on what exactly you use these 
attributes for and how you use them? Thanks.</I></FONT></PRE>
</BLOCKQUOTE>
<BR>
Until I saw the MANIFEST.MF file distributed with jdom, I did not know you even COULD give separate attributes for each package.&nbsp; The initial post I made builds the manifest that is distributed with the source.<BR>
<BR>
The second post I made is the result of research I should have done before the first one.&nbsp; As long as you have &quot;default&quot; attributes you can add just that information which changes in each package and the rest will &quot;trickle down.&quot;&nbsp; For my personal purposes, just the default attributes are adequate.<BR>
<BR>
Now for the usefulness of this information and what I do with it:<BR>
<BR>
The manifest is designed into .jar files so that the package can be queried for version information.&nbsp; It's designed to be queried by software, so that the dependent software can find out what version of (jdom) it has and either adjust its calls, disable or enable features or refuse to operate altogether.<BR>
<BR>
A code snippet would be as follows:<BR>
<TT><BR>
import java.lang.Package&nbsp; // totally unnecessary but for clarity<BR>
<BR>
public class PackageTester {<BR>
...<BR>
&nbsp;&nbsp;&nbsp; Package pkg = Class.forName(&quot;org.jdom.Document&quot;).getPackage();<BR>
&nbsp;&nbsp;&nbsp; if(!(pkg.isCompatibleWith(&quot;1.0&quot;) {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; throw new Exception(&quot;The JDOM module is too old to be used.&quot;);<BR>
&nbsp;&nbsp;&nbsp; }<BR>
&nbsp;&nbsp;&nbsp; // or<BR>
&nbsp;&nbsp;&nbsp; if(pkg.getImplementationVersion().equals(&quot;1.0.3&quot;)) {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; throw new Exception(&quot;The JDOM module you used has a bug that disables the ABC module!&nbsp; Versions 1.0-1.0.2 and anything after 1.0.3 work fine.&quot;);<BR>
&nbsp;&nbsp;&nbsp; // or<BR>
&nbsp;&nbsp;&nbsp; if(!pkg.getImplementationVersion().equals(&quot;1.0.3&quot;)) {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; throw new Exception(&quot;This application requires version 1.0.3 of jdom, exactly.&nbsp; Any other version is untested.&quot;);<BR>
<BR>
This is fairly primitive, but you can see that testing for a run/no run situation is pretty easy.&nbsp; Considering the number of software packages that are now being used on server side, and the convoluted class paths that can be found, it's important to know that somebody didn't drop in a different version than you are interested in, or if you're trying to upgrade you would want to be sure your upgrade took.<BR>
<BR>
We print module versions out on the java console (server log and client jc) on deployment and load respectively, so any error report has all that information.<BR>
<BR>
It's unfortunate that so many open source projects do not contain a useful MANIFEST.MF in this way.&nbsp; I'm trying to do my part in fixing that in a constructive way.<BR>
<BR>
FYI, the Package documentation requires that version numbers be positive integers separated by dots, so &quot;1.2.4&quot; works but &quot;1.0-rc3&quot; throws a NumberFormatException.<BR>
<BR>
Sorry for so many long posts, and thank you for your time.<BR>
</TT><BR>
</BODY>
</HTML>