You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Peter Donald <pe...@apache.org> on 2002/04/04 15:23:33 UTC

jarlib-* tasks

Hi,

Over last few days I have been working on extracting some tasks from another 
project I was working on. These tasks basically aimed at helping manage 
"Optional Packages" (previously known as "Extensions" and before that 
"Standard Extensions"). These are basically the standard library format for 
most of newer specifications (servlet, ejb etc).

Basically what these specifications demand is a certain set of attributes in 
a jars manifest. One example of attributes required for an extension would be

Extension-Name: org.realityforge.dve 
Specification-Version: 1.0 
Specification-Vendor: Peter Donald 

Which declares a basic extension. You can read more about these extension 
specifications at 

http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html. 

or at

http://jakarta.apache.org/ant/myrmidon/librarys.html

under dependencies.

Anyhow I have got two basic tasks going in myrmidon that I will backport to 
ant1.x and these are; jarlib-display and jarlib-manifest

* jarlib-display: this task will basically display all the Extensions a task
  implements or depends upon. It also displays the Package Specification that 
  a library implements. Some examples of task in action would be

        <jarlib-display file="../../src/ant1compat/jar/ant.jar"/> 
        <jarlib-display> 
            <fileset dir="../../"> 
                <include name="src/ant1compat/jar/*.jar"/> 
                <include name="lib/*.jar"/> 
            </fileset> 
        </jarlib-display> 

  The first would display only the information  in single jar while second 
form would display information in all the jars. The information comes out 
looking somethin like
  
----------------------------------------------------------------------------------
File: 
/mnt/dos-e/projects/jakarta-ant/proposal/myrmidon/src/ant1compat/jar/ant.jar
----------------------------------------------------------------------------------
Extensions Supported By Library:
Extension-Name: org.apache.tools.ant
Specification-Version: 1.4.9
Specification-Vendor: Apache Software Foundation
Implementation-Version: 1.4.9
Implementation-Vendor: Apache Software Foundation

Specifications Supported By Library:
Sections:  org/apache/tools/ant
Specification-Title: Apache Ant
Specification-Version: 1.4.9
Specification-Vendor: Apache Software Foundation
Implementation-Title: org.apache.tools.ant
Implementation-Version: 1.4.9
Implementation-Vendor: Apache Software Foundation

* jarlib-manifest: this task aims to make it easier to generate manifest that 
contain all the correct dependency information. An example invocation of taks 
would be 

        <jarlib-manifest 
            destfile="../../generated-manifest.txt" 
            extension-name="org.realityforge.dve" 
            specification-version="1.0" 
            specification-vendor="Peter Donald" > 
            <attribute name="Main-class" 
                       value="org.realityforg.dve.WorldGen"/> 
            <depends dir="../../"> 
                <include name="src/ant1compat/jar/*.jar"/> 
            </depends> 
            <depends dir="../../"> 
                <include name="lib/*.jar"/> 
            </depends> 
        </jarlib-manifest> 

This would generate a manifest with the specified extension, an extra 
attribute "Main-class" in the main section and all the dependency info. A 
sample output may be

Manifest-Version: 1.0 
Created-By: Myrmidon @@VERSION@@ compiled on @@DATE@@ 
Extension-Name: org.realityforge.dve 
Specification-Version: 1.0 
Specification-Vendor: Peter Donald 
Main-class: org.realityforg.dve.WorldGen 
Extension-List: lib0 lib1 
lib0-Extension-Name: org.apache.tools.ant 
lib0-Specification-Version: 1.4.9 
lib0-Specification-Vendor: Apache Software Foundation 
lib1-Extension-Name: org.apache.tools.ant.taskdefs.optional 
lib1-Specification-Vendor: Apache Software Foundation 
lib1-Specification-Version: 1.4.9 

Notice that by default you don't include the "implementation" details in the 
dependencies generated (at least not by default). To turn on dependency on a 
specific implementation of a library you could specify the attribute 
includeImpl="true" and it would generate

Manifest-Version: 1.0 
Created-By: Myrmidon @@VERSION@@ compiled on @@DATE@@ 
Extension-Name: org.realityforge.dve 
Specification-Version: 1.0 
Specification-Vendor: Peter Donald 
Main-class: org.realityforg.dve.WorldGen 
Extension-List: lib0 lib1 
lib0-Extension-Name: org.apache.tools.ant 
lib0-Specification-Version: 1.4.9 
lib0-Specification-Vendor: Apache Software Foundation 
lib0-Implementation-Version: 1.4.9 
lib0-Implementation-Vendor: Apache Software Foundation 
lib1-Extension-Name: org.apache.tools.ant.taskdefs.optional 
lib1-Specification-Vendor: Apache Software Foundation 
lib1-Implementation-Vendor: Apache Software Foundation 
lib1-Implementation-Version: 1.4.9 
lib1-Specification-Version: 1.4.9 
 
You can also turn on exposure of the Implementation-URL attribute by setting 
the attribute includeURL="true" on the filesets. In the cases where the 
library itself does not contain the implementation-URL attribute you can add 
the baseURL=".." , the javadocs for this attribute are as follows

   /** 
     * String that is the base URL for the librarys 
     * when constructing the "Implementation-URL" 
     * attribute. For instance setting the base to 
     * "http://jakarta.apache.org/avalon/libs/" and then 
     * including the library "excalibur-cli-1.0.jar" in the 
     * fileset will result in the "Implementation-URL" attribute 
     * being set to 
"http://jakarta.apache.org/avalon/libs/excalibur-cli-1.0.jar" 
     * 
     * Note this is only used if the library does not define 
     * "Implementation-URL" itself. 
     * 
     * Note that this also implies includeURL=true 
     */ 


Anyways before I port it across to ant1.x is there any functionality 
requests? The primary reason for creating this is to make projects like 
commons and excalibur easier to manage. Basically they all have lots of 
little libraries and these tasks are the start of making the dependency 
tracking partially-automated.

Anyways before I go ahead and do all this - requests? complaints? suggestions?

-- 
Cheers,

Pete

*------------------------------------------------------*
| "Computers are useless. They can only give you       |
|            answers." - Pablo Picasso                 |
*------------------------------------------------------*

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: jarlib-* tasks

Posted by Peter Donald <pe...@apache.org>.
On Mon, 8 Apr 2002 22:50, Stefan Bodewig wrote:
> On Sat, 6 Apr 2002, Peter Donald <pe...@apache.org> wrote:
> > Well I am actually using the JDK1.2 classes which implement it all
> > correctly anyway.
>
> But if you port it over to 1.x, that means jarlib-* become optional
> tasks.

yep. But as optional tasks are always included in the release now I don't 
think thats a real problem?

-- 
Cheers,

Pete

-------------------------------------------------------
"When we remember we are all mad, the mysteries of life 
disappear and life stands explained." -Mark Twain
-------------------------------------------------------

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: jarlib-* tasks

Posted by Stefan Bodewig <bo...@apache.org>.
On Sat, 6 Apr 2002, Peter Donald <pe...@apache.org> wrote:

> Well I am actually using the JDK1.2 classes which implement it all
> correctly anyway.

But if you port it over to 1.x, that means jarlib-* become optional
tasks.

> As some of the classes are JDK1.2 specific I never planned to have
> it supported in 1.1.

I thought you mail exactly said that, sorry for the confusion.

Stefan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: jarlib-* tasks

Posted by Peter Donald <pe...@apache.org>.
On Sat, 6 Apr 2002 00:14, Stefan Bodewig wrote:
> On Thu, 4 Apr 2002, Peter Donald <pe...@apache.org> wrote:
> > * jarlib-manifest: this task aims to make it easier to generate
> >   manifest that contain all the correct dependency information. An
> >   example invocation of taks would be
>
> Please reuse as much of org.apache.tools.ant.taskdefs.Manifest in this
> as possible so that there is only a single place with all the Manifest
> file logic (how long lines may be, what is allowed to be placed where
> and so on).

Well I am actually using the JDK1.2 classes which implement it all correctly 
anyway. As some of the classes are JDK1.2 specific I never planned to have it 
supported in 1.1. If someone else wants to support 1.1 then I will definetly 
help but until then I am way too lazy ;)

-- 
Cheers,

Pete

*---------------------------------------------------------*
| Contrary to popular belief, UNIX is user-friendly. It   |
| just happens to be selective on who it makes friendship |
| with.                                                   |
|                       - Richard Cook                    |
*---------------------------------------------------------*

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: jarlib-* tasks

Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 4 Apr 2002, Peter Donald <pe...@apache.org> wrote:

> * jarlib-manifest: this task aims to make it easier to generate
>   manifest that contain all the correct dependency information. An
>   example invocation of taks would be

Please reuse as much of org.apache.tools.ant.taskdefs.Manifest in this
as possible so that there is only a single place with all the Manifest
file logic (how long lines may be, what is allowed to be placed where
and so on).

Stefan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: jarlib-* tasks

Posted by Fredrik Lindgren <fr...@chello.se>.
I think a nice thing to have would be an extension or update to the 
"Available" task to enable checking if an implementation of an extension 
is available. If it could also check for versions it would be even 
better. It could use the rules described for applet jars in 
http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html

It could look something like:
<jarlib-available property="ant-available" 
extension-name="org.apache.tools.ant" specification-version="1.4.9" 
implementation-version="1.4.9">
<fileset dir="../../">
<include name="lib/*.jar"/>
</fileset>
</jarlib-available>

Any comments?

/Fredrik Lindgren




Peter Donald wrote:

> Hi,
> 
> Over last few days I have been working on extracting some tasks from another 
> project I was working on. These tasks basically aimed at helping manage 
> "Optional Packages" (previously known as "Extensions" and before that 
> "Standard Extensions"). These are basically the standard library format for 
> most of newer specifications (servlet, ejb etc).
> 
> Basically what these specifications demand is a certain set of attributes in 
> a jars manifest. One example of attributes required for an extension would be
> 
> Extension-Name: org.realityforge.dve 
> Specification-Version: 1.0 
> Specification-Vendor: Peter Donald 
> 
> Which declares a basic extension. You can read more about these extension 
> specifications at 
> 
> http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html. 
> 
> or at
> 
> http://jakarta.apache.org/ant/myrmidon/librarys.html
> 
> under dependencies.
> 
> Anyhow I have got two basic tasks going in myrmidon that I will backport to 
> ant1.x and these are; jarlib-display and jarlib-manifest
> 
> * jarlib-display: this task will basically display all the Extensions a task
>   implements or depends upon. It also displays the Package Specification that 
>   a library implements. Some examples of task in action would be
> 
>         <jarlib-display file="../../src/ant1compat/jar/ant.jar"/> 
>         <jarlib-display> 
>             <fileset dir="../../"> 
>                 <include name="src/ant1compat/jar/*.jar"/> 
>                 <include name="lib/*.jar"/> 
>             </fileset> 
>         </jarlib-display> 
> 
>   The first would display only the information  in single jar while second 
> form would display information in all the jars. The information comes out 
> looking somethin like
>   
> ----------------------------------------------------------------------------------
> File: 
> /mnt/dos-e/projects/jakarta-ant/proposal/myrmidon/src/ant1compat/jar/ant.jar
> ----------------------------------------------------------------------------------
> Extensions Supported By Library:
> Extension-Name: org.apache.tools.ant
> Specification-Version: 1.4.9
> Specification-Vendor: Apache Software Foundation
> Implementation-Version: 1.4.9
> Implementation-Vendor: Apache Software Foundation
> 
> Specifications Supported By Library:
> Sections:  org/apache/tools/ant
> Specification-Title: Apache Ant
> Specification-Version: 1.4.9
> Specification-Vendor: Apache Software Foundation
> Implementation-Title: org.apache.tools.ant
> Implementation-Version: 1.4.9
> Implementation-Vendor: Apache Software Foundation
> 
> * jarlib-manifest: this task aims to make it easier to generate manifest that 
> contain all the correct dependency information. An example invocation of taks 
> would be 
> 
>         <jarlib-manifest 
>             destfile="../../generated-manifest.txt" 
>             extension-name="org.realityforge.dve" 
>             specification-version="1.0" 
>             specification-vendor="Peter Donald" > 
>             <attribute name="Main-class" 
>                        value="org.realityforg.dve.WorldGen"/> 
>             <depends dir="../../"> 
>                 <include name="src/ant1compat/jar/*.jar"/> 
>             </depends> 
>             <depends dir="../../"> 
>                 <include name="lib/*.jar"/> 
>             </depends> 
>         </jarlib-manifest> 
> 
> This would generate a manifest with the specified extension, an extra 
> attribute "Main-class" in the main section and all the dependency info. A 
> sample output may be
> 
> Manifest-Version: 1.0 
> Created-By: Myrmidon @@VERSION@@ compiled on @@DATE@@ 
> Extension-Name: org.realityforge.dve 
> Specification-Version: 1.0 
> Specification-Vendor: Peter Donald 
> Main-class: org.realityforg.dve.WorldGen 
> Extension-List: lib0 lib1 
> lib0-Extension-Name: org.apache.tools.ant 
> lib0-Specification-Version: 1.4.9 
> lib0-Specification-Vendor: Apache Software Foundation 
> lib1-Extension-Name: org.apache.tools.ant.taskdefs.optional 
> lib1-Specification-Vendor: Apache Software Foundation 
> lib1-Specification-Version: 1.4.9 
> 
> Notice that by default you don't include the "implementation" details in the 
> dependencies generated (at least not by default). To turn on dependency on a 
> specific implementation of a library you could specify the attribute 
> includeImpl="true" and it would generate
> 
> Manifest-Version: 1.0 
> Created-By: Myrmidon @@VERSION@@ compiled on @@DATE@@ 
> Extension-Name: org.realityforge.dve 
> Specification-Version: 1.0 
> Specification-Vendor: Peter Donald 
> Main-class: org.realityforg.dve.WorldGen 
> Extension-List: lib0 lib1 
> lib0-Extension-Name: org.apache.tools.ant 
> lib0-Specification-Version: 1.4.9 
> lib0-Specification-Vendor: Apache Software Foundation 
> lib0-Implementation-Version: 1.4.9 
> lib0-Implementation-Vendor: Apache Software Foundation 
> lib1-Extension-Name: org.apache.tools.ant.taskdefs.optional 
> lib1-Specification-Vendor: Apache Software Foundation 
> lib1-Implementation-Vendor: Apache Software Foundation 
> lib1-Implementation-Version: 1.4.9 
> lib1-Specification-Version: 1.4.9 
>  
> You can also turn on exposure of the Implementation-URL attribute by setting 
> the attribute includeURL="true" on the filesets. In the cases where the 
> library itself does not contain the implementation-URL attribute you can add 
> the baseURL=".." , the javadocs for this attribute are as follows
> 
>    /** 
>      * String that is the base URL for the librarys 
>      * when constructing the "Implementation-URL" 
>      * attribute. For instance setting the base to 
>      * "http://jakarta.apache.org/avalon/libs/" and then 
>      * including the library "excalibur-cli-1.0.jar" in the 
>      * fileset will result in the "Implementation-URL" attribute 
>      * being set to 
> "http://jakarta.apache.org/avalon/libs/excalibur-cli-1.0.jar" 
>      * 
>      * Note this is only used if the library does not define 
>      * "Implementation-URL" itself. 
>      * 
>      * Note that this also implies includeURL=true 
>      */ 
> 
> 
> Anyways before I port it across to ant1.x is there any functionality 
> requests? The primary reason for creating this is to make projects like 
> commons and excalibur easier to manage. Basically they all have lots of 
> little libraries and these tasks are the start of making the dependency 
> tracking partially-automated.
> 
> Anyways before I go ahead and do all this - requests? complaints? suggestions?
> 
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>