At 11:38 19/12/00 -0800, James Duncan Davidson wrote:
>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.
okay.
>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.
yep but do workspaces need names? ;)
>> 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...
kewl.
>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>
Yep - but that assumes that project/modules must have a singular parent. I
would like it if some cases (ie jaxp) has multiple "parents". ie Ant uses
jaxp as does cocoon/avalon/xerces/crimson/whatever. In otherworlds how do
you reuse modules/projects from other projects cleanly.
I think I still like the building of a DAG via import statements.
>> 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>
Yep but what you have done here is flattened it. In many cases the
flattened tree looses information contained in hierarchial objects so I am
not sure iof flattening is way to go.
>> 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.
Well most of the people I got to use ant don't use it for java projects.
Most of them use it form manipulating xml/html/xsl etc
>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. :)
yep but requiring knowledge of any programming language is wrong IMHO ;)
>> 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.
nope - global variables. The particular values of the variables can either
be one set or another set. It is common for you to have debug versions or
release versions - which requires either 2x number of targets or setting
of alternate global properties at start. Naturally the second approach is
more usable.
>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.
replace that value with foo - it is just a variable name ;)
>> 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.
agreed that would suck ;(
>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)
simple-enough. In reality I would do something like
primordial <-- Core Ant classes <-- XML/Non-core ant files
<-- foo classpath
This means that the tasks can still use Task object/interface but doesn't
import xml/other tricky libs into classpath so you could use SAX2 in the
one task while SAX1 in another andant could be "run" via SAX1. All safely
insulated.
>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.
People who have to deal with classpath already know enough about java that
this is a non-issue.
>New VM -- I'd really like to defer out of that to explicit task executions
>for launching new processes.
perhaps - currently it is just a flag on certain tasks - however people
have asked for this on a lot of other occasions. Basically things like
tasks that consume copious amounts of memory (javadoc/classic javac) can be
isolated if needed and won't send ants java instance into a GC fit ;)
>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.
agreed it would be interesting.
>> 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.
However it is the only way to do somethings.
ie
<target name="foo" depends="bar" if="blee" />
<target name="bar" if="blah" />
Just say you only want bar to run if foo runs. There is no way to do it
unless you do some custom scripting to manipulate proeprties.
>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.
good design should always be a priority in opensource projects. We don't
have any deadlines and do this because it is fun. We should not hack
together something poorly for any reason IMHO (except maybe usability) ;)
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 |
*-----------------------------------------------------*
