You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Magesh Umasankar <um...@apache.org> on 2001/12/30 21:08:16 UTC
ValidatedFileAttribute removed
From: <um...@apache.org>
> umagesh 01/12/30 11:53:25
>
> Removed: src/main/org/apache/tools/ant/types DestDir.java
> DestFile.java PreferredAttribute.java SrcDir.java
> SrcFile.java ValidatedFileAttribute.java
> Log:
> Removing DestFIle, DestDir, SrcFile, SrcDir, ValidatedFileAttribute
> and PreferredAttribute.
More sophisticated Validation Mechanism is being discussed
and the one that I had checked in might hamper it. Moreover,
Peter felt my implementation may lead to maintenance issues.
Hence, I have removed the newly introduced references from the
codebase.
Cheers,
Magesh
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ValidatedFileAttribute removed
Posted by Magesh Umasankar <um...@apache.org>.
From: "Steve Loughran" <st...@iseran.com>
> What it did say was that I had experimentally added srcfile and destfile
> attrs into zip, war, jar and ear, as part of the unification of attribute
> names which I proposed a few weeks back, and kind of led to this whole
> thing.
I will say it did ;-)
> But I havent committed any of that, as I was testing to see how it worked,
> and waiting for everyone to come back from xmas. Looks like half the
changes
> are moot now; I will bind the attributes to File instead.
Sorry about messing up your week's work. But I just preferred
to see this implemented the right way and didn't want to leave it
out there long enough for a whole bunch of folks to start using it.
> But maybe I'll keep a copy of the files for historical value.
+1 ;-)
> In my little fixup exercise, I can state that the new datatype paradigm
did
> work nicely, provided your rules matched exactly what the types supported.
> When that case held, what you got was zero effort datatype validation.
> Things like that make creating robust tasks easier, and tasks with
> consistency with existing tasks.
Precisely the aim that I set out to achieve.
> We can start next week with a utils class that performs the standard
> validation stuff.
Maybe FileUtils? I notice an implementation pattern emerging behind
this proposition:
setSrc(String srcFile) would perform new File(srcFile) initially. Later
this
was changed to FIleUtils.resolveFIle(srcFile). This approach was then
replaced with setSrc(File srcFile) with the Introspector making the
resolveFile
call.
Now you are suggesting we change setSrcFile(File) which currently does
this.srcFile = srcFile to setSrcFile(File) which does this.srcFile =
FileUtils.getSrcFile(srcFile). Wonder what it will lead to next... ;-)
+0 on having it in a utility class because it provides APIs for task writers
to choose to use, but it doesn't completely address the issue of automatic
validation.
>
> -Steve
>
Cheers,
Magesh
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ValidatedFileAttribute removed
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Magesh Umasankar" <um...@apache.org>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Sunday, December 30, 2001 12:08
Subject: ValidatedFileAttribute removed
> From: <um...@apache.org>
>
> > umagesh 01/12/30 11:53:25
> >
> > Removed: src/main/org/apache/tools/ant/types DestDir.java
> > DestFile.java PreferredAttribute.java
SrcDir.java
> > SrcFile.java ValidatedFileAttribute.java
> > Log:
> > Removing DestFIle, DestDir, SrcFile, SrcDir, ValidatedFileAttribute
> > and PreferredAttribute.
>
> More sophisticated Validation Mechanism is being discussed
> and the one that I had checked in might hamper it. Moreover,
> Peter felt my implementation may lead to maintenance issues.
> Hence, I have removed the newly introduced references from the
> codebase.
>
There is a message about changes you made to expand.java which is lost in
the ether, probably blocked till after new years day, and I got mixed up
about expand versus gunzip.
What it did say was that I had experimentally added srcfile and destfile
attrs into zip, war, jar and ear, as part of the unification of attribute
names which I proposed a few weeks back, and kind of led to this whole
thing.
But I havent committed any of that, as I was testing to see how it worked,
and waiting for everyone to come back from xmas. Looks like half the changes
are moot now; I will bind the attributes to File instead. But maybe I'll
keep a copy of the files for historical value.
In my little fixup exercise, I can state that the new datatype paradigm did
work nicely, provided your rules matched exactly what the types supported.
When that case held, what you got was zero effort datatype validation.
Things like that make creating robust tasks easier, and tasks with
consistency with existing tasks.
We can start next week with a utils class that performs the standard
validation stuff.
-Steve
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>