ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Duncan Davidson <dun...@x180.net>
Subject Re: Did somebody say Shut up and Write? :)
Date Wed, 20 Dec 2000 04:59:52 GMT
On 12/19/00 5:18 PM, "Peter Donald" <donaldp@apache.org> wrote:

> yep but do workspaces need names? ;)

Actually yes. In an editor that keeps track of many projects that you work
on - you can flip between projects with a pull down list if you've got them
named. No editor that does this uses Ant, yet, but it would be nice to
enable.

Or, say you want to have an Email notification -- it'd be nice for that
notification to have a subject along this lines of Workspace "Foo" Build
Results.

Also, if all else fails, Ant can log out an error message that says "Can't
run Project "foo" because..."


> 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 that there is some degree of difference between an internal module
dependency and an external library dependency. However I do see your point
as well -- so....

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

How so.. Assuming that the "blee" ref contains [foo.java, joy.java], you end
up with a fileset that contains [foo.java, joy.java, grrr.java] in both
models. A set is a set.

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

Fair enough. Like I said -- there does need to be something that doesn't
force exposure of java types -- just the ability to do it. I'll work on that
later tonight/tommorrow.

> yep but requiring knowledge of any programming language is wrong IMHO ;)

I disagree. The tool is for programmers to use -- or release engineers to
use which need to have some knowledge of what's going on in programming
space in order to operate. Ant != MS Bob for Builds. :)

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

Are you saying -- using the example that you listed -- that output.dir is a
property that is set at the Project level, you are just tweaking its value
in each of the tasks? Property *assignment* in the scope of a target is a
much different thing than Property *scoping* to a target.

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

Then you're confusing the example needlessly by using the same name in
attribute variables and in target names.

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

Unless you are running on a system that has JAXP installed into lib/ext or
elsewhere on the bootsclasspath as it can be with any JAXP 1.1
implementation that is installed using the extensions mechansim -- and as
will be in the case of all J2SE 1.4+ and J2EE 1.3+ implementations. Playing
class loader tricks here only masks to some degree the need to be aware of
what is in your class name space.

The idea of being able to more tightly specify what classpath is used is
interesting, but needs to be further baked. Until that time -- tasks that
really need to do it can continue to manipulate things. After all, the only
things that really run into classpath issues are compiles.

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

You're arguing both sides here... :) But I've already agreed that requiring
types to be only class names isn't a go.

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

If you only want bar to run if foo runs, then you declare the dependancy:

<target name="bar" depends="foo">..</>

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

Good design does not always mandate reuse. Good coding sometimes uses
existing 'patterns' of thought, yet reimplements it. Sometimes project needs
outweigh reuse. And reuse of things by an external tool shouldn't drive the
internal design of any other tool -- otherwise you get into a situation
where there are so many dependencies that it takes years to get somewhere.

-- 
James Duncan Davidson                                        duncan@x180.net
                                                                  !try; do()


Mime
View raw message