You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Peter Donald <pe...@apache.org> on 2001/12/29 06:31:21 UTC
Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types
On Wed, 26 Dec 2001 06:50, Magesh Umasankar wrote:
> Hi,
>
> > Modified: src/main/org/apache/tools/ant IntrospectionHelper.java
> > Added: src/main/org/apache/tools/ant/types DestDir.java
> > DestFile.java PreferredAttribute.java SrcDir.java
> > SrcFile.java ValidatedFileAttribute.java
> > Log:
> > IntrospectionHelper has been modified such that overridden setter
>
> methods
>
> > that take in 'PreferredAttribute's as argument gain higher precedence.
> > New attribute types - SrcDir, SrcFile, DestDir and DestFile are
>
> introduced. Each of these types is a PreferredAttribute.
Justa note that I would prefer that changes like this be discussed before
they get done or at least implemented in a proposal branch first.
> A lot of the tasks that we have perform one validation or another before
> performing the actual execution. One such validation that is commonly
> repeated is the check to see if a file exists, if it is a directory, or if
> it is a
> file, etc. These are the common rules that most of the tasks check:
>
> 1. Src File must exist and must be a file.
> 2. Src Dir must exist and must be a directory.
> 3. Dest File may not exist, but if it does exist, it must be a file.
> 4. Dest Dir may not exist, but if it does exist, it must be a directory.
Yep - validation is some that needs factoring out but I am not sure this is
the way to do it.
> These new classes encapsulate this validation thereby minimizing
> the validation code that the task writer has to write.
>
> I have modified IntrospectionHelper such that it stays backwards
> compatible while at the same time takes advantage of the newly
> introduced 'PreferredAttribute' mechanism. I look at PreferredAttribute
> as a stop gap measure till Ant2 is released at which time, this may go off,
> as we wouldn't be backwards compatible anyway.
>
> There are a lot of tasks that currently take in File as argument to the
> setter methods. I will be refactoring these shortly, such that they take
> in ValidatedFileAttributes as arguments.
>
> The concept of validation here is somewhat similar to EnumeratedAttribute.
Type and validation of type are different concepts and shouldn't be merged
together. There should be a method that allows validation to be extracted
outside the task but I don't like the way that you do it. For example lets
consider that there may be N different types. Each instance of a type may
have M rules applied to it. Thus under your system you could potentially have
N x M objects!!!! I would much prefer to have just M objects that could be
composed together - much more manageable ;)
Heres one way of "fixing" this - maybe to wait till Ant2. Lets call the
objects that do checking "Validators". Each time we call a setter for either
an attribute or an element we call an associated chain of Validators (chain
may be null in which case zero validation occurs).
The chain of validators is built up by looking at the TaskInfo object - which
lists all validators that must be run etc. Because writing the TaskInfo
object would be monotonous we could have them automagically generated based
on comments in javadocs for the setters. ie. Something like
/**
* ...
*
* @validator org.apache.ant.validators.SourceValidator
*/
void setSrc( File src )
{
}
This would mean much less objects required to do validating and so forth and
should be relatively easy to implement by Task writers (not so easy for us
though).
--
Cheers,
Pete
--------------------------------------------
Beer is proof that God loves us and wants
us to be happy. -- Benjamin Franklin
--------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types
Posted by Peter Donald <pe...@apache.org>.
On Mon, 31 Dec 2001 02:42, Magesh Umasankar wrote:
> > If the ant task itself is used outside ants container it is likely going
>
> to
>
> > have issues anyway. Both Ant1.x and Ant2 will most likely continue to
>
> behave
>
> > in this manner so I don't consider this a great loss.
>
> We have suggested that we will be working to provide API support in the
> 1.9 action plan.
> http://jakarta.apache.org/ant/ant2/actionlist.html#embeddor
True but tasks will still be run in a container - it will just be that this
container will be able to be easily mbedded in other applications ;)
--
Cheers,
Pete
--------------------------------------------
Sorry, I forgot to take my medication today.
--------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types
Posted by Magesh Umasankar <um...@apache.org>.
From: "Peter Donald" <pe...@apache.org>
> > ok, but I understood you OKed some sort of a wrapper.
>
> I guess I must have got confused - which thread was this in again? It
http://marc.theaimsgroup.com/?t=100891536700002&r=1&w=2
Specfically, http://marc.theaimsgroup.com/?l=ant-dev&m=100897943010533&w=2
> probably would have been useful to show code snippets as I talk better in
> code ;)
Well, the code is there now and you have expressed your opinion ;-)
> Not a -1 more a -0. If you want to fix it then do it if you don't consider
it
> in need of fixing then feel free to ignore me ;)
I guess I will just back them out so that we can discuss this further. But
here
is how I look at it. You pass a non-numeric string to a setter that takes
in, say,
Integer as parameter, it is still going to 'validate' it to see if it a
numeric
or else throw a NumberFormatException. So, in effect, SrcFile et al. hasn't
really introduced as yet an unseen/unknown concept.
> If the ant task itself is used outside ants container it is likely going
to
> have issues anyway. Both Ant1.x and Ant2 will most likely continue to
behave
> in this manner so I don't consider this a great loss.
We have suggested that we will be working to provide API support in the
1.9 action plan.
http://jakarta.apache.org/ant/ant2/actionlist.html#embeddor
> Do whatever you feel like - I was basically just saying - erk!
Then, erk it is ;-)
Cheers,
Magesh
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types
Posted by Peter Donald <pe...@apache.org>.
On Sun, 30 Dec 2001 16:27, Magesh Umasankar wrote:
> From: "Peter Donald" <pe...@apache.org>
>
> > Justa note that I would prefer that changes like this be discussed before
> > they get done or at least implemented in a proposal branch first.
>
> ok, but I understood you OKed some sort of a wrapper.
I guess I must have got confused - which thread was this in again? It
probably would have been useful to show code snippets as I talk better in
code ;)
> I can back them out,
> of course, if you are giving a -1 to this implementation (I understand you
> are
> from what I read, but please confirm). If you had provided these comments
> earlier, it might have helped too.
Not a -1 more a -0. If you want to fix it then do it if you don't consider it
in need of fixing then feel free to ignore me ;)
> > Type and validation of type are different concepts and shouldn't be
> > merged together. There should be a method that allows validation to be
> > extracted
>
> EnumeratedAttribute, IIRC, performs validation also...
Thats only because Ant1.x has a abysmal type system ;) If it was impossible
to create an enum that wasn't one of the selected enums then you would need
no validation. BTW I just implemented this in myrmidon yesterday. Have a look
at antlib.core.StringToEnumConverter ;)
>
> > outside the task but I don't like the way that you do it. For example
> > lets consider that there may be N different types. Each instance of a
> > type may have M rules applied to it. Thus under your system you could
> > potentially
>
> have
>
> > N x M objects!!!! I would much prefer to have just M objects that could
> > be composed together - much more manageable ;)
>
> Hmm... what if the validator class composes the validation using
> other smaller validator class methods? We can also do some daisy chaining
> mechanism this way. Or, have I not understood correctly the issue you
> are pointing out?
Precisely what I was thinking!
> > /**
> > * ...
> > *
> > * @validator org.apache.ant.validators.SourceValidator
> > */
> > void setSrc( File src )
> > {
> > }
>
> This type of mechanism might not be ideal for the API user? What you say
> will
> have an effect only if setSrc is invoked by An't core. If say somebody
> uses Ant's API to launch a task from some external environment for whatever
> reason,
> the checkings will not happen. I see you are proposing something similar
> to @assert?
If the ant task itself is used outside ants container it is likely going to
have issues anyway. Both Ant1.x and Ant2 will most likely continue to behave
in this manner so I don't consider this a great loss.
> > should be relatively easy to implement by Task writers (not so easy for
> > us though).
>
> Let me know.
Do whatever you feel like - I was basically just saying - erk!
--
Cheers,
Pete
--------------------------------
These aren't the droids you're
looking for. Move along.
--------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
From: "Magesh Umasankar" <um...@apache.org>
> From: "Jose Alberto Fernandez" <j_...@yahoo.com>
>
> > Oh I do not mind having classes that do the syntactic verification
> > if the default Java classes do not. That I think it is fine. Where
> > I have a problem is when we try to go beyond syntax into semantics.
>
> Differentiating between syntactic and semantic validations
> make sense in client-server/servlet-EJB environments. But
> why should we be differentiating between them in Ant? After all,
> if we do not do semantic validation during 'setting' tme, it is going
> to be performed (hopefully) in the execute method - there are
> no multiple layers involved here (at least ATM). Do you suggest
> against doing semantic validations during 'setting' time because
> you envision Ant being used in some sort of a client-server
> env where setters are called by the client and execute is called
> by the server? Or is it something else?
>
My reasons are quite simple. Tasks are the ones that need to decide the
semantics of their attributes. Diferent tasks in different circumstances
should be able to impose different constraints on their arguments.
Imposing a blank semantics on all usages of an attribute limits their usage.
However, this does not mean that we cannot greatly simplify and standardize the
semantic checking of the arguments. For example, We could provide a datatype
whose constructor makes certain the syntax is proper. And which provides
verification methods for the task to call in order to perform standard semantic checkings:
mustExist()
mustBeDirectory()
including more complex checks like: mustBeSrcDir().
The point is that this gives a chance to the task to decide what does it wants to enforce
but it does it in a standarized way (applying a standard set of definitions).
It also means that developers may subclass the standard types and provide their own
enforcement rules for their tasks.
Something like that seem much more flexible to me.
Jose Alberto
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types
Posted by Magesh Umasankar <um...@apache.org>.
From: "Jose Alberto Fernandez" <j_...@yahoo.com>
> Oh I do not mind having classes that do the syntactic verification
> if the default Java classes do not. That I think it is fine. Where
> I have a problem is when we try to go beyond syntax into semantics.
Differentiating between syntactic and semantic validations
make sense in client-server/servlet-EJB environments. But
why should we be differentiating between them in Ant? After all,
if we do not do semantic validation during 'setting' tme, it is going
to be performed (hopefully) in the execute method - there are
no multiple layers involved here (at least ATM). Do you suggest
against doing semantic validations during 'setting' time because
you envision Ant being used in some sort of a client-server
env where setters are called by the client and execute is called
by the server? Or is it something else?
>
> Jose Alberto
>
Magesh
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
I am not a commiter, but I completely agreed with
Peter on this one. 8-o
This is a very substantial change, and as it has been
stressed before anything we add to the API gets set in
stone and we are stuck with it for the whole of ANT1´s
life. Some comments below:
--- Magesh Umasankar <um...@apache.org> wrote:
>
> ok, but I understood you OKed some sort of a
> wrapper. I can back them out,
> of course, if you are giving a -1 to this
> implementation (I understand you
> are
> from what I read, but please confirm). If you had
> provided these comments
> earlier, it might have helped too.
>
I think it is dificult to understand completely the
consequences of some of this proposals, just by
reading one e-mail account of it. That is why it is a
good idea to submit this things as proposals, and make
all the changes to tasks there so one can understand
the settle implications of things.
For example, I had a real problem with the
consequences of this change on <property>. The fact
that an input file had to be managed as if it where an
output file just to shortcut the validation, tell me
that we have a problem. I cannot believe this will be
the only place ever were we will have such a
situation.
It is a very small issue, which one cannot grasp just
by reading your explanatory message, but it rises a
red flag, at least to me.
> > > The concept of validation here is somewhat
> similar to
> EnumeratedAttribute.
> >
> > Type and validation of type are different concepts
> and shouldn't be merged
> > together. There should be a method that allows
> validation to be extracted
>
> EnumeratedAttribute, IIRC, performs validation
> also...
>
This to me is just syntactic validation and would be
equivalent to verifying that the string being passed
corresponds to a valid filename, whether it exists or
not. This is what (I think) File(String) will (or
should) do.
> > Heres one way of "fixing" this - maybe to wait
> till Ant2.
Please, do not add new APIs which we already believe
are broken or wrong. This is a problem we have had
several times, someone adds some new idea with the
best of intentions, there is little review or
discussion because the person has committing rights,
and then there is no way out of it when problems
arise.
The commiters put a very high bar for non committers
to get anything in, lots of discussions and -1s. But I
do not perceive the same level of discussions when
other committers make important changes.
As I said, everyone is working with the best
intensions in mind, but no one can forsee all the
consequences of some changes.
Jose Alberto
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types
Posted by Magesh Umasankar <um...@apache.org>.
From: "Peter Donald" <pe...@apache.org>
> Justa note that I would prefer that changes like this be discussed before
> they get done or at least implemented in a proposal branch first.
ok, but I understood you OKed some sort of a wrapper. I can back them out,
of course, if you are giving a -1 to this implementation (I understand you
are
from what I read, but please confirm). If you had provided these comments
earlier, it might have helped too.
> > The concept of validation here is somewhat similar to
EnumeratedAttribute.
>
> Type and validation of type are different concepts and shouldn't be merged
> together. There should be a method that allows validation to be extracted
EnumeratedAttribute, IIRC, performs validation also...
> outside the task but I don't like the way that you do it. For example lets
> consider that there may be N different types. Each instance of a type may
> have M rules applied to it. Thus under your system you could potentially
have
> N x M objects!!!! I would much prefer to have just M objects that could be
> composed together - much more manageable ;)
Hmm... what if the validator class composes the validation using
other smaller validator class methods? We can also do some daisy chaining
mechanism this way. Or, have I not understood correctly the issue you
are pointing out?
> Heres one way of "fixing" this - maybe to wait till Ant2. Lets call the
> objects that do checking "Validators". Each time we call a setter for
either
> an attribute or an element we call an associated chain of Validators
(chain
> may be null in which case zero validation occurs).
>
> The chain of validators is built up by looking at the TaskInfo object -
which
> lists all validators that must be run etc. Because writing the TaskInfo
> object would be monotonous we could have them automagically generated
based
> on comments in javadocs for the setters. ie. Something like
>
> /**
> * ...
> *
> * @validator org.apache.ant.validators.SourceValidator
> */
> void setSrc( File src )
> {
> }
This type of mechanism might not be ideal for the API user? What you say
will
have an effect only if setSrc is invoked by An't core. If say somebody uses
Ant's API to launch a task from some external environment for whatever
reason,
the checkings will not happen. I see you are proposing something similar to
@assert?
> This would mean much less objects required to do validating and so forth
and
> should be relatively easy to implement by Task writers (not so easy for us
> though).
Let me know.
Cheers,
Magesh
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>