Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Message-ID: <008401c1b239$60485e40$d1eefea9@homenkf0y0hwu0>
Reply-To: "Stephane Bailliez" <sbailliez@apache.org>
From: "Stephane Bailliez" <sbailliez@apache.org>
To: "Ant Developers List" <ant-dev@jakarta.apache.org>
References: <OFC83E85F8.B2BC52F0-ON85256B5C.004387AB@raleigh.ibm.com>
Subject: Re: Speaking of deprecation...
Date: Sun, 10 Feb 2002 14:46:43 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

----- Original Message -----
From: "Sam Ruby" <rubys@us.ibm.com>


> And there aren't some nasty bugs fixed between Ant versions?  For that
> matter, aren't some nasty versions fixed between OS versions (for whatever
> OS you happen to be running?)

When the compiler crashes every 5 compiles, this is rather critical to me
for development.
That the Sun VM leaks memory like crazy under JVMPI is less problematic
though somewhat annoying. (especially when Sun put this as 'won't fix',
reaching 1GB and putting the system on its knees is a matter of 30 minutes,
thanks)
As this is not open source your alternative is ?
I don't have this problem with Ant, before being a committer I have done
quick patches for Ant, the patches.jar was placed before the Ant jars in the
invoking script. This was extremely easy since all this was under source
control, no one noticed when I upgraded to a release Ant version with this
patch in it. No mail sent with "please add this patched version to your Ant
local repository thank you".

> For everybody, there are some tools which are merely installed.  Where
this
> line is drawn varies.  For many outside of the immediate Ant dev
community,
> Ant is on the other side of this line.

I don't think so. Really.
Reading the CCIUG (Clearcase mailing list) makes me think that build
engineers put as much as possible under source control. There is a
difference between what a developper do and what a build engineer want a
developper to do to make things reproducible.

None of us here is a build engineer but Diane. We probably need more
feedback from advanced build engineers (from the top of my head, Christian
Goetze and Peter Vogel for example) to know the do and do not.

> > Gump runs using  'HEAD' being on the thirdparties and projects. If I
want to
> > build using a particular build label and that's it.
>
> I hadn't mentioned Gump.  I mearly use Gump for daily development and to
> warn others of impending changes.  When I build official releases, I
depend
> solely on released versions of everything (generally the latest ones).

You hadn't but that's what I'm using for the nightly build, only a
deployment script is then run for to assemble all the component into a
modular app. than is packaged with Installshield (multiplatform). I have to
thank you for this work because it is really helpful.

> Again, FWIW, I support the removal of deprecated features for which active
> users can't be identified.  And these discussions typically go round in

How do you indentify them ?
AFAIK the only thing that can be somewhat safely removed are AdaptX and
XSLP, at least that's the one I know of, I don't know from the top of my
head about the other.

> circles without making forward progress unless there is a focus on
specific
> items to be removed.  Blanket statements that nothing can ever be removed
> are provably equivalent to saying that bugs can't be fixed and features
> can't be added.  And wanton removal of features without regard to impact
on
> the community which depends on Ant would be downright silly.

How do you evaluate the impact ? build files found in the Jakarta community
are I think rather simple and short compared to could be found in a shop
making extensive use of it for both independant build, global build and
deployement.

Back 2 years ago when I came to the company I work with now, you should have
seen the complexity of the global build time. I'm glad I replaced it by GUMP
and simpler build files with a centralized repository. It is a snap to
build, upgrade and maintain. Everybody can do it easily, the original author
of the huge build file had a hard time doing any change in it and it was
incorrectly compiled (how many people are actually bitten by
includeAntRuntime, I don't know but a build engineer would not want
something like that as a default since it is plain wrong).

> Concrete examples:
>
>    IMHO, it is time to move beyond the XSLTLiaison notion.  This bloats
the
>    code, makes things more difficult to maintain, and tools like Xalan1
>    which did not support the API are long since removed from maintanance,
>    the web site, cvs etc.

That's a +1 for removal of xslp, adaptx, xalan1 ?

>    On the other hand, removal of the jarfile attribute would just plain be
>    silly.  Pretty much everybody I know of ignores those deprecation
>    warnings, which sets a bad precident as once you get into the habit of
>    ignoring some warnings you miss the really important ones.  Finally,
the
>    code that supports the attribute is pretty much self contained.

Removal no. Removing the documentation for this attribute probably.

no one will ever read the documentation saying 'deprecated', just consider
how many people still think -O does something. Maybe it's back in 1.4 (did
not check the source code), maybe not, maybe they will do something in 1.5,
why not ? maybe this will be -O1, O2, later, who knows. The compiler should
issue a warning when using -O like 'this options does nothing" or something
but certainly not leaving it as is in the usage command line and a small
italic section "does nothing" in the manual with the full explanation of
option below.

Stephane


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