ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <jakarta-...@ehatchersolutions.com>
Subject Re: [PATCH] Script enhancement to standardize the "project" object exposed
Date Sun, 30 Sep 2001 06:40:36 GMT

----- Original Message -----
From: "Peter Donald" <donaldp@apache.org>
To: <ant-dev@jakarta.apache.org>
Sent: Saturday, September 29, 2001 9:04 PM
Subject: Re: [PATCH] Script enhancement to standardize the "project" object
exposed


> On Sun, 30 Sep 2001 13:25, Erik Hatcher wrote:
> > The <script> task seems to be designed for ad hoc task creation, so why
> > shouldn't it act just like being in the execute() method and have the
same
> > capabilities?
>
> Who saids it shouldn't?

You are!  :)    By keeping a level of indirection between the script code
and the Task object it prevents standard access to the facilities available
to a Task.   It also prevents code reuse by having to hard-code task
references to the task id.

Granted, there is not much to a Task that <script> would need direct access
to that a Project doesn't provide (for example, the log methods are
available on Project also).   I would characterize my stance more on
principle than technical reasons.  <script> code is a Task's execute
implementation, and should really only have access to the Task instance -
and getting the Project reference from that is trivial.

> Hmmm - I thought you could access java objects directly in BSF. Something
> like prefixing it with "java." or similar. Not sure. If not then feel free
to
> send a patch that places a reasonable adaptor object that looks like

Yes, and Sam showed us how (duh!).   Logging isn't really the main thing I
envisioned a Task doing, that was just a simplistic example I provided.
Sam provided nice examples of the use of the <script> task - and yes those
examples only needed Project.   And now that "project" has been added, the
"openjms" could be changed and those script sections could be externalized
and reused in other build scripts easily (many thanks for committing that
patch already Peter).

> I like that it is obtuse because that means less people will use it and
thus
> less people will complain when we break compatability with ant2.

The first sentence of the Ant2 goals begins like this:  "Even though Ant2 is
expected to be incompatible with the current Ant1 series...".   And then
later: "Tasks written for Ant1 won't work in Ant2 as the API of Ant's core
and the names of utility classes are going to change."

So why worry about <script> breaking builds?   Anyone upgrading from 1.x to
2.0 will have many other issues to contend with (most likely) than <script>,
no?    And any tool that is developed to convert Ant 1.x build.xml files to
Ant 2.0 format could warn the user when it encounters <script> that there
are likely to be issues with that task, and there are likely to be other
similar scenarios of a conversion.

> > write a Task without having to create a Java class, compile it, and
> > <taskdef> it.   I view it simply as the implementation of the execute()
> > method of Task, and in that light I think it should be able to have
clean
> > access to the Task object.
>
> Doing this would mean that we are guarenteeing that we break compatability
> with future iterations of ant. Do you see this as a good thing?

<script> is not by any stretch of the imagination a major player in build
scripts.   I would only use it (and I haven't used it in any production
builds, only for demonstration purposes anyway! :) to prototype a task or do
simple things like Sam's examples of incrementing a build number or
replacing characters in a string.   Compatibility will only be broken when
the Task contract changes - and that will cause major ripples throughout
other Java-based tasks as well, so breaking <script> backwards compatibility
at that point is perfectly reasonable to me.

> Some functionality would benefit to be added for usability sake. However
this
> is not the thing I dislike - It is binding to implementation specific
objects
> that will mandate that we break compatability in future that seems kinda
> foolish to me. Sure it is already accessible but it is obtuse enough that
> most people will not use it and thus it will be easier for use to support
in
> future.

I truly understand what you are saying about exposing Task (or other
internal objects) to script code and how internal code changes could break
such code.   But I don't agree that its a bad thing.   Anyone using <script>
should know they are playing with fire and risk incompatibilities in future
releases.... but a 1.x release won't change Task, do you think?   Exposing
"self" to <script> is not going to open the floodgates to folks all of a
sudden writing tasks in this manner, and wacky insane things could be done
with <script> already.

I'm done lobbying for this though - its really a matter of principle to me
as I'm not architecting build scripts that use <script>.   I'm happy that
"project" got added, and would be much happier if "self" also got added.
Sam gave a +1.   I'm not sure of the politics involved at the committer
level, but does that constitute a vote on that change where other committers
are asked to weigh in on it?

    Erik



Mime
View raw message