Re: Did somebody say Shut up and Write? :)

[James Cook]

I hate to sound like I'm a whiny child here, but you guys should really read my proposal before you start thinking about implementation specifics like workspace/module.

http://www.visualxs.com/products/frantic/index.html

jim

To: <[EMAIL PROTECTED]>
cc:
Subject: Re: Did somebody say Shut up and Write? :)

On 12/19/00 5:39 A
> I am not sure I lik M, "Peter Donald" <[EMAIL PROTECTED]> wrote:
e 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).

As currently set the primary difference between workspace & module is a
matter of degree... And an explicitness of which is the root. I think that
things like listeners and such could also happen at the workspace level and
not be a module level item. But it's just the start of a thought.

Also, another difference between workspace and module is that modules don't
really need names -- they are part of the name of the workspace. This is
targeted at Diane's 64 subproject files. More places for differentiating
themselves may present themselves.

> 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.

Fair enough. I can see that... The linkage between workspace and module is
explicit, but yes, the linkage between module and workspace is implicit. I
don't have a problem going explicit with this link either...

<module workspace="../../Workspace">
...
</module>

Or some such.

And, if the distinction between Workspace/Module is too overdone, then
obviously this is simple to express in Project terms...

[$DIR/project]
<project name="Whatever">
<target name="foo">
    <exec-child buildfile="childdir/subproject"/>
</target>
</project>

[$DIR/childdir/subproject]
<project name="WhateverChild" parent="../project">
...
</project>

> I much prefer explictness if at all possible. If you have a look at the
> 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.

Right. The aim of Workspace/Module explicitness is to clarify that there is
a root to the system -- the root of course being special because it doesn't
have a parent.

> 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>

Depends on what is in the ref of "blee" since the proposal to abstract this
doesn't take into account definable patterns.. But besides that it's

    <set name="fileset1" type="java.io.File">
      <builder type="filebuilder" recurse="yes">
      <item>grrr.java</item>
    </set>

Or, if particular builders were registered internally (or by explicity
external builders specified in the Workspace) (and it seems that "file"
would be a natural default):

    <set name="fileset1" type="file">
      <item>grr.java</item>
    </set>

So, if there were seperable patterns, which there very well might need to be
for reuse:

    <pattern name="javafiles">
      <item>*.java</item>
    </pattern>

    <set name="fileset1" type="file">
      <usepattern name="javafiles"/>
    </set>

Not top complex -- seems pretty straightforward to me for a worst case
scenario -- and now any type of object could be put into a set. The only
caveat is a task that grabed onto a property or a property set would have to
know of course what types of objects went in.

> 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.

Java types were used as a definitive fallback to allow any kind of types in
properties or property sets to be used.

And ant was designed for primary use on Java projects. If it's useful in
C++, fine -- of course the C++ answer (or at least MSFT answer) to simple
type names of java.io.File are class ids with big long strings. If people
can grok that, they can grok java.io.File. :)

It is obvious that some types will want to be promoted into a simplier
namespace, such as file=java.io.File in a type case and
file=org.apache.ant.FileBuilder in a set builder case.

> 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) .

Like I've said from the beginning and every time I've popped up --
properties follow the same sort of model as System properties -- they are a
global namespace to store things. What you are using them as there is as
local variables with scoping.

And I don't understand unless="targetname" like you've got -- how can a
target resolve to true or false? Either you execute the target and it
succeeds or fails, or don�t.

> 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.

Using namespacing for this sort of thing is interesting to consider. One
thing that I don't like about it is that it would force people to declare
the ant: namespace in their XML files.

Being able to set the classpath for tasks is an interesting idea however it
means 1) each task execution gets its own classloader that has to divorce
itself from the system class loader, and yet manage to pick up system
classes (ie, everything that's not on a defined classpath) and 2) it makes
people have to deal with the fact that it's Java. Since you state that
"java.io.File" is icky for that reason, then I have to point this out.

New VM -- I'd really like to defer out of that to explicit task executions
for launching new processes.

One thing that wasn't in the proposal, but which I've been tinkering with in
code is the concept of default threading.. IE, a attribute which is valid
for all tasks is "fork|spawn|thread="yes"" (name tbd!). This would
automatically in the Task execution logic spawn a thread that would execute
the task and control would return to the main thread and next task. Then a
<join|sync> task could wait until everything caught up. This is a little
different than earlier proposals to this effect because it drive MT down
into the core execution of Ant. I think this is necessary to take advantage
of 4x, 8x, and *x machines to parallelize builds.

> 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.

Which is a hack in essence. Targets are supposed to be descriptors of tasks
to be executed, not method definitions. This is one of the cases where
people using this way doesn't make it right.

>>    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.

Ok.. I do want to make it clear that if such reuse is possible, great -- but
it shouldn't drive any part of the design of building stuff.

>> 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 ;)

Yeah... Ouch.

>>    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 ;)

Huh? CSS styling?

>>    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 ;(

I think that the definition of listeners should be that they are hooked into
place *before* execution moves on. This is one of the reasons that I see
properties/listeners/whatever else that isn't a target as separate from
targets and something that should be in targets.. All of these things need
to be made alive before execution gets started.

..duncan

--
James Duncan Davidson                                        [EMAIL PROTECTED]
                                                                  !try; do()


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]