ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim O'Brien" <>
Subject RE: cvs commit:....
Date Mon, 26 Jun 2000 15:17:22 GMT

I think optional packages are just as important as core packages, but one
thing I'd like to just insert in this discussion is that emailing a message
does not seem to me to be something that should be included as a core
taskdef.  It makes more sense to include this as an optional taskdef because
it does not increase the runtime requirements ( See Duncan's spec doc at
1&content-type=text/vnd.viewcvs-markup ).

Further down that road, I don't think that the Ant project should contain
any code that deals specfically with sending email when there is an
established and widely embraced standard in JavaMail. We could reimplement
this under APL in the future, and in my case sending a mail attachment is a
feature which would be used immediately for distributing a release to a
number of interested parties.  It may seem like overkill to some, but to
others it may be one of those features that clearly establishes Ant as the
tool to use.

The "core" and "optional" distinction does seem a bit arbitrary, but it is
useful in the following sense.  Optional packages are just that, they do not
sepcifically relate to the core ability of Ant, build management and file

Tim O'Brien

-----Original Message-----
From: Jason Hunter []
Sent: Monday, June 26, 2000 12:35 AM
Subject: Re: cvs commit: jakarta-ant/src/main/com/oreilly/servlet

Conor MacNeill wrote:
> > Whether a task should be optional or not should be dependent on the
> > merits of the task, not on what's easiest for integration.
> I find that a strange statement. Optional tasks are not assumed to be less
> meritorious, IMHO.

I think it's a terminology issue.  There are three kinds of Ant tasks:

* Core tasks, provided with Ant and available to everyone

* Optional tasks, built if and only if certain libraries are on the
person's machine

* Project-specific tasks, things needed by a project but not generally

I was stating that whether something was "core" or "project-specific"
should be decided on the merits of the task.  "Optional" is a crazy
middle ground.  If something is worth being core, then every effort
should be taken to have the necessary JARs bundled with Ant, because you
should be able to build your project using "core" tasks and expect it to
build on any system.  If a task is project-specific, then it shouldn't
leave your project.  Optional tasks should only be used as a very last
resort when something merits being core but there's no way to provide
the necessary supporting JAR.  And even then I don't like the idea very
much.  :-)

> For me, one of the important issues will become change management of this
> code. Will there be restrictions on making changes to this code in the ant
> source tree? If not, how will you stop them diverging? If changes are
> allowed, how will they be kept in sync with your source tree?

No restrictions on making changes, except a note at the top of the file
asking the maker of the change to coordinate with
development if possible.  But really, we're talking about a single file
that does a specific well-defined task, so I'm not real worried about

That is a reason to move it to org.apache.* though, so people won't be
confused if there ever is divergence.

> > I'm sure in
> > this case we can solve the integration issue, and I personally think
> > sending mail is something qualifying as a core task, as async
> > notification of an official build finishing is quite standard.
> >
> Sure, that is a nice feature and where it is required, people could
> the package to make it happen. There is an issue, however, in that
> tasks is currently a compile time concept. Perhaps it might be good to
> optional tasks at runtime (i.e. their presence is ignored if there is no
> appropriate class available, without halting the build).

Optional tasks at runtime?  Sounds like a minefield.

> If Intersourcing, as you called it, involves copying source code, then I
> would have reservations about it.

It's new territory, but generally it involves branching and shipping a
product based on the branch with cherrypick bug fixes.  If you think
about it, that's how we release Tomcat -- create a release branch and
fine tune it while active development progresses on the trunk.


View raw message