ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <JFernan...@viquity.com>
Subject RE: Why does the echo task output to System.out? (Was: RE: [submi t] I ntegration of Ant into Visual Age for Java)
Date Mon, 20 Nov 2000 19:46:46 GMT
> From: glennm@ca.ibm.com [mailto:glennm@ca.ibm.com]
> 
> 
> 
> As it stands, with the changes I've made, if the message is 
> directed to an
> output file its _always_ directed to the output file.  The level is
> ignored.  Thats the same behaviour we had previously.  The 
> default level is
> MSG_WARN to ensure output is always visible _by default_.  
> The only thing
> that has changed is the fact that echo'ed messages now have [echo]
> prepended to them.  The level functionality is completely optional.
> 
> Given the previous discussions, it probably would have helped 
> to have read
> the code changes.  Of course, it would have helped if I had 
> updated the
> documentation.
> 
> Now, given all this discussion, is it worth it to redo things so that
> <echo> simply prints to a file _or_ a logger (not both), and 
> <log> inherits
> from echo, adding the level semantics?  Does this give 
> everyone what they
> want?  If so, I'll implement it today.
> 

I am fine with this. Now, notice that given the simplicity of <echo>
you do not really need to implement <log> using inheritance, but that
is up to you. What I care is having different functionalities implemented
by different tasks.

In a separate argument, I still think that part of the problems we are
facing is that Simeon is having to dealt with the non-embedability of the
current ANT code base. We did not considered this issues in 1.2.
I think we be good to have a small discussion on this issues aside from
the GUI specifics, as a general problem, and see if we can spot the 
areas in ANT that we should modify. Then evaluate the finding by seeing how
the apply to the GUI needs.

Some of the issues as I see them are:

  - Management of System.* things: get/setProperties(), in, out, err
streams,
    exit(), and so on.

  - How Project instances are created (from file, or from SAX)

  - How <ant>/<antcall> create subproject instances. How sources are found
    (not necessarily from a file).

  - How to trace progress of the build from the outside.

There may be others,

I belive if we come up with a generic framework to address this issues,
we will simplify antidote's work a lot, and allow other things like XSL
preprocessing and such.

Any comments,

Jose Alberto


> Glenn McAllister
> Software Developer. IBM Toronto Lab, (416) 448-3805
> "An approximate answer to the right question is better than the
> right answer to the wrong question." - John W. Tukey
> 
> 
> Please respond to ant-dev@jakarta.apache.org
> 
> To:   ant-dev@jakarta.apache.org
> cc:
> Subject:  Re: Why does the echo task output to System.out? 
> (Was: RE: [submi
>       t] I ntegration of Ant into Visual Age for Java)
> 
> Simeon Fitch <metasim@yahoo.com> wrote:
> 
> > --- Jose  Alberto Fernandez <JFernandez@viquity.com> wrote:
> >> So the above is equivalent to:
> >>
> >>  <echo message="my message" output="myfile" loglevel="warn" />
> >>
> >> how do I say just write this to the file!!!
> >>
> >
> > You don't.
> 
> This is taking away part of <echo>'s functionality. The output
> attribute has been added to <echo> to have a simple means of writing
> files from inside the build file. This use case is in no way connected
> to logging at all.
> 
> > I think all messages should be available to any listener who wishes
> > to processes it. I don't think there should be any message hidden
> > from the build listeners.
> 
> But if you specify outfile, you want to write to a file, you don't
> intend to log messages. It's some kind of poor man's editor, similar
> to using echo in shell scripts and batch files.
> 
> >> Every time people clump together to different tasks into one just
> >> because it is easy, I looks to me like a hack.
> >
> > I think that is unfair, as I'm not proposing it becuase it is
> > "easy". I happen to think it's desireable behavior.
> 
> In a sense both of you are right. The echo implementation we have now
> is somewhat similar to /bin/sh's echo builtin or the one of
> COMMAND.COM (or is this really an executable of its own?).
> 
> It would probably be cleaner to have two separate tasks, one for
> writing text - maybe redirecting it to a file - and one for writing
> log messages. I'm just not sure, which of both would deserve the name
> echo.
> 
> If we keep them as one task (which might be easiest for new users, I'm
> not sure) maybe we should say you can either specify outfile or
> loglevel, but not both of them? If you don't specify outfile we use
> the logging system, if you do we'll write to the file.
> 
> Stefan
> 
> 
> 

Mime
View raw message