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 05:11:31 GMT
At 08:59  19/12/00 -0800, James Duncan Davidson wrote:
>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.

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

You would scan them at assignment time ? If so it will become a useless
construct in many cases. Many people want the scanning to occur when it is
used . It would make it very difficult for some people use them as many
define patternsets that are used in multiple places to refer to different
files but are covered by same pattern.

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

right. Assignment.

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

eww thats gonna suck. We are gonna have to jump through loops to use
different versioned implementations in 1.4+ then ;(

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

Not really - there is a lot of other things. Namely executing java
programs, running unit tests, running other tools (ie stylebook), running
profiles, etc And this is all just from the project I am currently editing ;)

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

best way to argue ;)
>>> 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">..</>

but that would run foo before bar - you really want bar to run before foo
but only if foo is going to run (and blah is set).

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

right - anything that complicates ant core should not be considered but
reuse due to NIH is despisable in all forms ;)

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