ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <co...@cortexebusiness.com.au>
Subject Re: a task for generating manifest information
Date Fri, 12 Oct 2001 10:57:55 GMT
Peter Donald wrote:

> Hi,
> 
> I hpoe you don't mind but I added this to CVS because I needed it aswell ;)


I have moved this to Ant-dev.

I have some issues with this task.

1. The file does not have an Apache licence statement

2. Manifests are tokenized into lines based on the current platform's 
line.separator. I'm not sure how a Unix system would go parsing a 
Windows manifest - maybe OK.

3. Manifests are read in character by character - seems a strange approach.

4. Continuation lines in manifests do not appear to be handled - will 
throw an exception

5. Entry overrides equals() but not hashcode().

6. currentMethod field is not validated in checkParams, can be null and 
will give and NPE

7. OO concepts seem a little back to front to me - i.e. 
entry.addTo(container).

8. deletes current manifest file before writing new one.

9. Why does Entry implement comparator interface. Only uses it for 
equals which seems strange to me. We probably never would do ordering of 
entries.

10. I think this task is probably not necessary anyway. Although I 
neglected to document the fact (mea culpa), you can inline manifest 
creation in the jar task like this

    <jar jarfile="taskjar2.jar" basedir="." manifest="manifest.mf">
        <include name="src/**/*"/>
        <manifest>
            <attribute name="Built-By" value="${user.name}"/>
        </manifest>
     </jar>

or

     <jar jarfile="taskjar2.jar" basedir="." manifest="manifest.mf">
         <include name="src/**/*"/>
         <manifest>
           <section name="com.blah"
               <attribute name="Built-By" value="${user.name}"/>
           </section>
         </manifest>
      </jar>

This makes manifest files redundant if you wish. If a file based 
manifest is given the manifests are merged. <jar> will dependency check 
against changes in the buildfile.

The structure of the manifests above is much richer than the <entry> 
approach of this task

So, overall, I think there are enough problems to -1 this task. If you 
still want a manifest generating task, it should, for reuse reasons, be 
based on the Manifest class, IMHO. That class can be updated to make 
this easier if need be but it should be pretty much ready to slot in.

Conor


Mime
View raw message