ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simeon H.K. Fitch" <>
Subject Re: Contribute new taskdef?
Date Sun, 10 Dec 2000 01:40:28 GMT

Jon Stevens wrote:
> on 12/9/2000 1:36 AM, "David Li" <> wrote:
> > Hi,
> >
> > I am new to Ant list. I have written a couple taskdef for Ant 1.2 that
> > I'd like to contribute to the community. How do I go about doing this?
> > Thanks.
> >
> > David Li
> > DigitalSesame
> Start off by describing what it does?


Correct me if I'm wrong, but I think what you are looking for is some
more guidance on how to effectively volunteer your efforts to the Ant
project. Below is a copy of a write-up it did that was originally posted
in the message
( Some of
this is just my take on things, but you will find the URL to the
official guidelines below.


For getting your submission into Ant, here are the general guidelines
(Antidites, correct me if I get any of this wrong).

1)      Read *everything* at and the five
        listed there.

2)      Before submitting your patch/addition, make sure you have the
        latest version of the source and that your change compiles and 
        works with it.

3)      Make sure your code is propertly documented in JavaDoc format,
        source files have the correct copyright header, and that the
        basically follows the Sun coding conventions document.

4)      Make the appropriate changes and/or additions to the documents

5)      Update or add, as appropriate, to the test code in
        jakarta-ant/src/testcases so regression testing can be applied
        your offering (and ensure you haven't broken anything).

6)      Create the patch file with "cvs diff -u" and post it to the
        along with a jar/zip file containing any new files that you
        have. Please create the zip and the diff relative to the
        jakarta-ant directory so it is easy to apply your changes,
        particularly new source file locations. Post all this to the
        with the subject starting with [PATCH], and include a full
        description of what the patch is, why it's useful, and why
        should test is out for you (the sales pitch). 

7)      Be patient. One of the committers will have to apply the patch,
        build it, and test it. The committer may solicit help from
        in the group on this, particularly if the patch involves
        tools that the committer has no access to. The committer may
        request modification so that the code better fits the design or
        other constraint. You also have to be prepared to accept a
        negative vote on your submission, for one reason or the
        other. This is where the discussion gets interesting, and where
        you have to keep and open mind while at the same time being an
        advocate for your offering. Remember that the discussion isn't
        about your intelligence or technical prowess, but about the
        suitability of functionality you offer or the design
        approach you used. It is meant to be a constructive and
        discussion (ideally, anyway). 

8)      If you make subsequent changes to the patch before it is
        committed, your continued submissions should still be
        based on the latest version of the code (i.e. don't diff your
        diffs). This is no big deal since that is what "cvs diff" gives
        you anyway. Just make sure you include your new files each time.

9)      If a week or so goes by and there is no dialog on your
        don't assume that people aren't interested in your work. Just
        a polite email asking if anyone has had the chance to look at
        referencing your original post with a link to the mailing list
        archive. Due to the voluntary nature of the project, it is easy
        for submissions to drop through the cracks accidentally. It is
        means a commentary on your work.

I hope this helps, and gives you a better feel for how to make sure
your contribution is best offered.


View raw message