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 Wed, 20 Dec 2000 01:18:28 GMT
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" <donaldp@apache.org> 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               |
*-----------------------------------------------------*


Mime
View raw message