ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Hunter <>
Subject Re: cvs commit: jakarta-ant/src/main/com/oreilly/servlet
Date Mon, 26 Jun 2000 04:35:26 GMT
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 install
> the package to make it happen. There is an issue, however, in that optional
> tasks is currently a compile time concept. Perhaps it might be good to have
> 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