You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Bill Burton <bi...@progress.com> on 2001/01/21 04:01:39 UTC

[PROPOSAL] Class dependency checking for optional tasks

Hello,

I've been thinking about ways to improve usability of Ant, particulary for
first time users.  Here's one idea in that direction.

One of the questions that comes up a lot on the ant-user list is, "Where
do a find the classes for ftp support, etc?"  As a result, it was good to
see Nico's patches to clarify the docs in this area.  I've been thinking
about this problem from a little different perspective.

Overview 

Each task requiring external classes should provide a way the task
developer can declare the required jar file(s) by specifing a class within
each jar to check for the availability of the jar.  If the class isn't
available, the task will throw a BuildException with the name of the
missing jar and the URL where it can be obtained.

This feature is conceptually similar to the <available classname=... />
task but would force the build to stop if the specified class is not
available by throwing a BuildException.

Implementation Details

Task.java would be modified by adding a method similar to the following
(untested):

    /**
     * Tries to load the specified class ensuring any associated jar 
     * file is available.  If the class is not available, a BuildException
     * is thrown with the specified comment.  The comment should concisely 
     * provide information indicating what's missing and where it can be 
     * obtained.
     * 
     * @param name name of class to check in the classpath
     * @param loader class loader or null for the default 
     *        class loader
     * @param comment text describing the name of the class or 
     *        associated jar file and the URL or location where it 
     *        can be obtained
     */
    public void checkForRequiredClass(String name, ClassLoader loader,
String comment)
        throws BuildExeception
    {
        try {
            if (loader == null)
                loader = this.getClass().getClassLoader();
            Class.forName(name, true, loader);
        } catch (ClassNotFoundException cnfe) {
            // Maybe this should also output the location too?
            throw (new BuildException("Missing class " + name + ": " +
comment));
        }
        // Need to catch other exceptions here?
    }

The task developer could use it in either the init() or execute() methods
like this:
    checkForRequiredClass("com.oroinc.net.ftp.FTPClient", null
                          "Requires ORO NetComponents available at       
http://www.savarese.org/oro/software/NetComponents.html");

The <script> task could have many calls to this method, one for BSF and
one for each of the supported scripting languages.

If the consensus is that this is a good idea, I'll work on a patch for
this functionality.

-Bill Burton

Re: [PROPOSAL] Class dependency checking for optional tasks

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Bill Burton wrote:

> Hello,
>
> I've been thinking about ways to improve usability of Ant, particulary for
> first time users.  Here's one idea in that direction.
>
> One of the questions that comes up a lot on the ant-user list is, "Where
> do a find the classes for ftp support, etc?"  As a result, it was good to
> see Nico's patches to clarify the docs in this area.  I've been thinking
> about this problem from a little different perspective.
>
> Overview
>
> Each task requiring external classes should provide a way the task
> developer can declare the required jar file(s) by specifing a class within
> each jar to check for the availability of the jar.  If the class isn't
> available, the task will throw a BuildException with the name of the
> missing jar and the URL where it can be obtained.
>

The JDK docs describe an approach whereby JAR files can declare dependencies on
external packages.  If Ant 2.x allows the packaging of individual tasks in
separate JAR files (perhaps auto-registering them if they are placed in a
special directory?), it would be pretty easy to use this approach.

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

NOTE:  The servlet 2.3 spec requires servlet containers to support this
mechanism for webapps to declare such dependencies.  As such, Tomcat 4.0 has
some support code for implementing this that could be generalized and reused
pretty easily.

Craig McClanahan

RE: [PROPOSAL] Class dependency checking for optional tasks

Posted by Martin van den Bemt <mv...@mvdb.com>.
Don't mind me asking.. What is CJAN ??
If you don't want it before the 1.3 release, count me in on working on this
part. I'm leaving for India soon, so I don't know if I have time left there
(probably sitting on the toilet whol day anyway ;)).. With everybody
swimming in the big river I don't know exactly when I'm gonna leave though.
Do you have any idea on how to implement this ?
Just add some targets to the build.xml or do you want something more "nice".
When it's just adjusting the buid.xml it can probably go into 1.3 (deadline
was first week of february I read..) and more flexible system should
probably be in ant 2 style (whatever that may come to be).

Just let me know what the ant community wants for now...

Mvgr,
Martin van den Bemt
mvdb@mvdb.com


-----Original Message-----
From: Peter Donald [mailto:donaldp@apache.org]
Sent: Sunday, January 21, 2001 4:34 PM
To: ant-dev@jakarta.apache.org
Cc: ant-dev@jakarta.apache.org
Subject: RE: [PROPOSAL] Class dependency checking for optional tasks


At 04:27  21/1/01 +0100, Martin van den Bemt wrote:
>Shouldn't there also be an option to download (maby embedded in the main
>build.xml for ant to download all tasks that depend on external sources?
>(like what they do in netbeans  modules)They also use the build.xml to do
>this.
>
>- You have a default stable distribution
>- You want e.g. the Junit tasks
>- You run build Junit
>- This target gets all the stuff that the junit task needs
>- Rebuilds ant when necessary.

This is what CJAN is supposed to do. Apparently details of it were
discussed before the PMC meeting so hopefully we will see it being worked
on soon. Feel free to jump into it thou ;)

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


---------------------------------------------------------------------
To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ant-dev-help@jakarta.apache.org



RE: [PROPOSAL] Class dependency checking for optional tasks

Posted by "Rosen, Alex" <ar...@silverstream.com>.
> This is what CJAN is supposed to do. Apparently details of it were
> discussed before the PMC meeting so hopefully we will see it
> being worked on soon. Feel free to jump into it thou ;)

When this auto-update discussion last came up, I forwarded this thread to Rene
Schmidt, the JNLP / Java Web Start guy, and he said:

>Thanks for pointing this out. I definitely think that this kind of stuff
>could be done using JNLP. We just need a command-line like launcher.
>I will talk to James about it.

... where James is presumably JDD.

It does seem like this feature is just a variation on JNLP. To me this sounds
like a library taken from part of the Java Web Start implementation, that has
no GUI, or an optional GUI or something. You'd also need a mode where it would
never throw anything away from its JAR cache, since this feature would be
geared more toward standalone apps than "web-like" apps that are always
connected to the Internet.

--Alex


Re: [PROPOSAL] Class dependency checking for optional tasks

Posted by Jon Stevens <jo...@latchkey.com>.
on 1/21/01 7:33 AM, "Peter Donald" <do...@apache.org> wrote:

> This is what CJAN is supposed to do. Apparently details of it were
> discussed before the PMC meeting so hopefully we will see it being worked
> on soon. Feel free to jump into it thou ;)

<http://oss.software.ibm.com/developerworks/opensource/jakarta/proto.zip>

-jon

-- 
Honk if you love peace and quiet.



RE: [PROPOSAL] Class dependency checking for optional tasks

Posted by Peter Donald <do...@apache.org>.
At 04:27  21/1/01 +0100, Martin van den Bemt wrote:
>Shouldn't there also be an option to download (maby embedded in the main
>build.xml for ant to download all tasks that depend on external sources?
>(like what they do in netbeans  modules)They also use the build.xml to do
>this.
>
>- You have a default stable distribution
>- You want e.g. the Junit tasks
>- You run build Junit
>- This target gets all the stuff that the junit task needs
>- Rebuilds ant when necessary.

This is what CJAN is supposed to do. Apparently details of it were
discussed before the PMC meeting so hopefully we will see it being worked
on soon. Feel free to jump into it thou ;)

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


Re: [PROPOSAL] Class dependency checking for optional tasks

Posted by Peter Donald <do...@apache.org>.
At 10:01  20/1/01 -0500, Bill Burton wrote:
>Hello,

hi ;)

>One of the questions that comes up a lot on the ant-user list is, "Where
>do a find the classes for ftp support, etc?"  As a result, it was good to
>see Nico's patches to clarify the docs in this area.  I've been thinking
>about this problem from a little different perspective.

kewl.

>
>Overview 
>
>Each task requiring external classes should provide a way the task
>developer can declare the required jar file(s) by specifing a class within
>each jar to check for the availability of the jar.  If the class isn't
>available, the task will throw a BuildException with the name of the
>missing jar and the URL where it can be obtained.

sounds good.

>    /**
>     * Tries to load the specified class ensuring any associated jar 
>     * file is available.  If the class is not available, a BuildException
>     * is thrown with the specified comment.  The comment should concisely 
>     * provide information indicating what's missing and where it can be 
>     * obtained.
>     * 
>     * @param name name of class to check in the classpath
>     * @param loader class loader or null for the default 
>     *        class loader
>     * @param comment text describing the name of the class or 
>     *        associated jar file and the URL or location where it 
>     *        can be obtained
>     */
>    public void checkForRequiredClass(String name, ClassLoader loader,
>String comment)
>        throws BuildExeception

Unfortunately this would only work in a small proportion of cases. Namely
the cases that use the class via reflection. In the case of FTP it actually
imports the classes explicitly. Thus the ClassNotFound exception would
still be thrown - when class is loaded. It would not even get the
oportunity to define, and instantiate the class so you could call
checkForRequiredClass().

In some cases with tasks that do act via reflection this would be a great
idea. However instead of placing it in Task class I think it may be better
to create a new class TaskUtil to contain it. So you could use it like

void init() throws BuildException
{
  TaskUtil.checkJavaVersion( JavaVersion.JDK1_2 );
  TaskUtil.checkForRequiredClass("com.oroinc.net.ftp.FTPClient", null
                          "Requires ORO NetComponents available at" +

"http://www.savarese.org/oro/software/NetComponents.html");

  TaskUtil.checkFor...();
}

>If the consensus is that this is a good idea, I'll work on a patch for
>this functionality.

I don't think it would apply to FTP task (or majority of cases) but where
it does apply it would be very useful. Love to see a patch ;)

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


Re: [PROPOSAL] Class dependency checking for optional tasks

Posted by Bill Burton <bi...@progress.com>.
Hello,

A couple of months ago, I started work on an Ant 1.3 build file
"optional.xml" that could fetch and install some optional tasks.  So far,
I've implemented a task that can fetch and install the NetComponents jar
for the FTP task.  It would be good to add support for the scripting jars
and any other obvious ones in optional.jar.

If this kind of thing seems appropriate, I'd be willing to work on it some
more.

JNLP seems like the way to go long term but based on the proposed schedule
for the 1.3 release a simpler scheme looks like it would be more
appropriate.  

-Bill Burton

Martin van den Bemt wrote:
> 
> Shouldn't there also be an option to download (maby embedded in the main
> build.xml for ant to download all tasks that depend on external sources?
> (like what they do in netbeans  modules)They also use the build.xml to do
> this.
> 
> - You have a default stable distribution
> - You want e.g. the Junit tasks
> - You run build Junit
> - This target gets all the stuff that the junit task needs
> - Rebuilds ant when necessary.
> 
> or
> - You're using the Junit task in a build.xml
> - If not present, throw a buildexception saying to get the junit optional
> and how to accomplish that. (maby offer it right away for download).
> - rebuild ant when necessary.
> 
> Mvgr,
> Martin van den Bemt

RE: [PROPOSAL] Class dependency checking for optional tasks

Posted by Martin van den Bemt <mv...@mvdb.com>.
Shouldn't there also be an option to download (maby embedded in the main
build.xml for ant to download all tasks that depend on external sources?
(like what they do in netbeans  modules)They also use the build.xml to do
this.

- You have a default stable distribution
- You want e.g. the Junit tasks
- You run build Junit
- This target gets all the stuff that the junit task needs
- Rebuilds ant when necessary.

or
- You're using the Junit task in a build.xml
- If not present, throw a buildexception saying to get the junit optional
and how to accomplish that. (maby offer it right away for download).
- rebuild ant when necessary.

Mvgr,
Martin van den Bemt




-----Original Message-----
From: Bill Burton [mailto:billb@progress.com]
Sent: Sunday, January 21, 2001 4:02 AM
To: Ant Developers Mailing List
Subject: [PROPOSAL] Class dependency checking for optional tasks


Hello,

I've been thinking about ways to improve usability of Ant, particulary for
first time users.  Here's one idea in that direction.

One of the questions that comes up a lot on the ant-user list is, "Where
do a find the classes for ftp support, etc?"  As a result, it was good to
see Nico's patches to clarify the docs in this area.  I've been thinking
about this problem from a little different perspective.

Overview

Each task requiring external classes should provide a way the task
developer can declare the required jar file(s) by specifing a class within
each jar to check for the availability of the jar.  If the class isn't
available, the task will throw a BuildException with the name of the
missing jar and the URL where it can be obtained.

This feature is conceptually similar to the <available classname=... />
task but would force the build to stop if the specified class is not
available by throwing a BuildException.

Implementation Details

Task.java would be modified by adding a method similar to the following
(untested):

    /**
     * Tries to load the specified class ensuring any associated jar
     * file is available.  If the class is not available, a BuildException
     * is thrown with the specified comment.  The comment should concisely
     * provide information indicating what's missing and where it can be
     * obtained.
     *
     * @param name name of class to check in the classpath
     * @param loader class loader or null for the default
     *        class loader
     * @param comment text describing the name of the class or
     *        associated jar file and the URL or location where it
     *        can be obtained
     */
    public void checkForRequiredClass(String name, ClassLoader loader,
String comment)
        throws BuildExeception
    {
        try {
            if (loader == null)
                loader = this.getClass().getClassLoader();
            Class.forName(name, true, loader);
        } catch (ClassNotFoundException cnfe) {
            // Maybe this should also output the location too?
            throw (new BuildException("Missing class " + name + ": " +
comment));
        }
        // Need to catch other exceptions here?
    }

The task developer could use it in either the init() or execute() methods
like this:
    checkForRequiredClass("com.oroinc.net.ftp.FTPClient", null
                          "Requires ORO NetComponents available at
http://www.savarese.org/oro/software/NetComponents.html");

The <script> task could have many calls to this method, one for BSF and
one for each of the supported scripting languages.

If the consensus is that this is a good idea, I'll work on a patch for
this functionality.

-Bill Burton

---------------------------------------------------------------------
To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ant-dev-help@jakarta.apache.org