ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: Did somebody say Shut up and Write? :)
Date Tue, 19 Dec 2000 13:39:31 GMT

kewl ;)

A few comments to start but I think I need a bit of time to digest it ;)

At 04:05  19/12/00 -0800, James Duncan Davidson wrote:
>What's there:
>    a stab at actually looking at Workspace/Module rather than Project.
>    This gets around child/parent Projects and ant-call -- and opens the
>    door to something better.

I am not sure I like the handling of differences between workspace/module.
In many ways I think the difference is rather .. nebulous so not sure what
to make of it. I am also strongly in favour of no intrinsic behaviour
(including searching for workspace from module file). 

We had a few complaints when we implemented this for ant build files. The
two prominent ones were security - mistyping ant in wrong directory could
send you into a long search that could find something in a very far away
place (way up directory tree) and some installations would not instal ant
with this feature enabled.

The other issue was similar - searching could cause "thrashing" if you
happenend to be on a NFS/samba/other remote drive. Typing ant could cause a
4-5 sec delay if you did it in wrong place.

I much prefer explictness if at all possible. If you have a look at the
antfarm proposal it actually explictly imported other projects in. For
example for the following statement

<import name="meep"/>

it would look for meep.ant along "project path". While this project path
was a controlled form of inter-project/workspace searching. For instance
meep could refer to binary drop or source drop - however as long as it
produced meep.jar in correctplace (as defined by a property in meep
project) then it would be fine. I could see this as gret for CJAN.

So I am not sure if seperating module/workspace out is ideal solution. I
was of the understanding that workspace was more a conceptual idea. A
"workspace" of foo was essentially the DAG of project files imported
directly or indirectly from foo. Not sure I guess it needs to be looked at
a bit more.

>    a unification of Properties and Sets with a further abstraction of the
>    current FileSet/PatternSet ideas. Any type of object that can be created
>    with a String constructor can be set as a Property or a member of a
>    Property Set. With a little more definition of builders, this
>    requirement can go away.

I think this may be too complex for users - not sure. While it would be
ideal if we just wanted simple data types and sets of simple data types I
think this approach would fall down in complex case. For example how would
you represent

<property name="foo">
  <fileset dir="bob">
   <fileset ref="bar" />
   <patternset ref="blee" />
   <patternset>
      <include name="grrr.java" />
   </patternset>
  </fileset>
</property>

(I know it is unrealistic but this is worst case scenario). It would also
be unable to represent many other complex types (I am thinking temporary
data-holders between tasks).

However the worst thing about it is that it uses java types - yuck !!!
Remember that many of the target audience doesn't know what java is
(besides being that ugly thing thats is sometimes placed on web-pages). It
seems unreasonable to expect any knowledge of java - especially if ant was
to move towards a c/c++ build system.

Also I don't think I like the restriction that properties could not be
defined in targets. Currently a lot of my build files use something like

<target name="debug-mode" if="debug-mode">
  <property name="output.dir" value="../build/debug"/>
</target> 

<target name="release-mode" depends="debug-mode" unless="debug-mode" >
  <property name="output.dir" value="../build/release"/>
</target> 

and I have recomended a lot of other people use that pattern. (Either that
or the mutual-exclusion of multiple targets version of above) .

>    some simple examples showing how Workspace/Module files can work
>    together
>
>    a bad drawing of the Workspace runtime tree
>
>    other things captured.
>
>So -- comments on Peter's list based on this proposal:
>
>    namespaces -- no reason they can't be in buildfiles, but I don't think
>    that we need to explicitly support them. If namespace attributes or tags
>    are in the file, we just ignore them. If we treat them as such, we only
>    depend on SAX1. No biggie, we should just define what we do.

Right - a while ago I was advocating attributes such as 

ant:classpath="${foo}"
ant:new-vm="true"
ant:log-level="DEBUG"
ant:....

All these things are independent of the actual task and could be
implemented as part of any task. This would stop a lot of special case code
- for example a lot of my tasks used to run in default classpath but I
later needed to specify the classpath. This of course meant a complete and
utter rewrite of everything which I don't think was desirable - and I think
it must be common situation.

Considering the  above attributes are concerns of container (project)
rather than contained component (task) - I think it may be nice/useful to
think about applying them.

>    Ant-call isn't discussed here as the Workspace/Module thoughts are this
>    proposals mechanism for dealing with modularity and multi build files.

ant-call was also used for templating. So instead of writing 10 targets
that do a javac, jar, sign, you can write one target that gets properties
past in via ant-call. It was primitive but a lot of people use it this way
(which is surprising because it is slooooooow in current ant.

>    Jar task info shouldn't be in the Manifest itself. Too much data can go
>    there as is. It should probably be in META-INF/ant.xml or some such.

agreed.

>    Installer. I'd like to see more along these lines. In fact, given that
>    Ant is pretty small (the biggest chunk is the durn XML parser), there's
>    no real reason it can't be used as a task engine to be used by an
>    installer. Probably something where a Module tree would be built
>    at runtime so that things like install dir can be queried instead of
>    being something that is driving off an XML file. I'm not sure that I'd
>    write an installer that drove a project/workspace directly. Maybe I'd
>    write it with Installets or something, but that's a whole different
>    ball of wax. If this works for that purpose, more power. :)

Right - I think it would be better to be at a lower level for installer.
Instead of reusing whole of ant it would just reuse the task execution
engine and ignore the project/module/workspace classes. Hopefully each
different concern would be localised to a different directory and such
reuse would be possible.

>Observations (and Questions) for Diane:
>    I'd like to know more about your build-order issues. Typically divisions
>    between sourcepaths and destpaths seem like they could keep things
>    segregated until you copy the results together into one happy tree.
>    However, the side-compile issue is the biter. I guess I'd like a bit
>    more info there.

Thats what I thought - I think her build situations is really painful. Have
to compile class 1, 2 and 3 with 1.3 JDK, then classes 4,5 6 with 1.2 JDK
and then ... ouchies ;)

>    I agree that if/unless checks need to be for true/false/1/0 type of
>    matches and not existence of property. I would like to know your
>    feeling about execution order. IOW, in AntEater I checked in a
>    buildtarget task that did the if/unless checking.. This is a bit
>    different than doing the if checking in the target def in the fact
>    that all of those items could be centralized in one target instead
>    of spread out through the build files. Would this be helpful?

I am not sure it would be useful. It is similar to the issue of CSS styling
of ant buildfiles but on a more fixed level which sounds painful ;)

>    Logging -- it would be nice to provide a listener to simply write all
>    events out to a file -- or mail the events output to somewhere at
>    a particular email address... Any further comments on this?

Theres a few issues. Sometimes you need to log to different things
depending on how build finished and how long it took and what options were
used to build etc. Similar to what you have ages ago I implemented
something like

<project ...>

  <listener type="org.apache.ant.MailNotification"> 
    <param name="blah" value="blee"/>
  </listener> 

</project>

However I found it too constraining as it missed to much being instantiated
after the project was already in motion - I am not sure of a more viable
solution thou ;(


Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


Mime
View raw message