ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject Re: antlib descriptor
Date Fri, 22 Feb 2002 08:10:12 GMT
From: "Conor MacNeill" <conor@cortexebusiness.com.au>

> > From: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com]
> 
> BTW, there is only one "n" in Conor.
> 
Sooooorrrrryyyy ;-)

> >
> > Connor you are misunderstanding what roles are
> > designed for. They are not designed as a way to allow
> > polymorphism of arguments to methods.
> 
> Well that is what most examples of Roles have been about. People talk about
> ejbjar in this context a lot and I see that as something that is easily
> solvable with polymorphic behaviour rather than needing the all the
> machinery of roles. A simple method
> 
> addDeploymentTool(DeploymentTool tool)
> 
> should be enough.
> 
> Since <ejbjar> extension is one of your stated goals in defining roles, I
> see considerable overlap.
> 

As I have said before there are areas where any one of those mechanisms are applicable,
and others in which they offer different functionality. As in any programming language
(and lets face it, ANT XML is a programming language) there are more than one way to do
something.

Roles provide name space isolation, and as I said it is for segregation of information at
large.
For example, <DeploymentTool> elements should not be allowed in positions where
tasks or datatype elements are allowed. That means that you need a way to segregate them.
If you just have one big namespace, and given the fact that everything is considered a valid
datatype (they do not need to extend or implement anything), then I do not see how you can
resolve this issue. 

Roles do that for you. The "ejbjar" role where DeploymentTools live is not allowed in TaskContainers
while "task" and "data-type" roles are.

> >
> > In all your examples, the objects you are trying to
> > pass belong to one unique role, i.e data-type.
> > Your proposal, make deal with polymorphic arguments,
> > however it does not resolve the issue of roles like
> > Tasks or datatypes. If we were to use your mechanism
> > we will finish with build files like:
> >
> > <target ...>
> >   <parallel>
> >      <task ant:type="javac" .... />
> >      <task ant:type="copy" .... />
> >   </parallel>
> > </target>
> 
> That doesn't happen in mutant because TaskContainer is still there and it
> does get specific treatment. I don't see that as a problem. In mutant this
> is not a problem and data types cannot be added to a task container unless
> it specifically has a method to accept the datatype. The fact that works in
> Ant1 is a byproduct of Ant1's design limitations. The problem with allowing
> this to happen is it suggests things are possible which are not.
> 
> Consider this
> <project name="paralleldata" basedir="." default="main">
>   <target name="main">
>     <parallel>
>       <fileset dir="..">
>         <include name="**/*.xml"/>
>       </fileset>
>       <echo message="hello"/>
>       <echo message="hello"/>
>     </parallel>
>   </target>
> </project>
> 
> In ant today, this seems to work but the fileset is useless. It is
> misleading. It may even hide a mistake in the build if someone puts in a
> slash and terminates an element prematurely.
> 

I am all with you that the current implementation is awfully bad in this regard.
And by the way, I wonder how other proposals deal with the fact that "data-types" do not
need to extend o.a.t.ant.types.DataType. How do you define the "role" interface? Do you use
Object?
Wouldn't that make datatypes be applycable everywere?

> In mutant you will get this
> D:/antdev/bugs/paralleldata/build.xml:4: parallel does not support the
> "fileset" nested element
> Root cause: org.apache.ant.common.util.ExecutionException: parallel does not
> support the "fileset" nested element
> 
> This is what happens with mutant today.
> 

Which will break ANT1 projects. 

Now you can see why things are the way they are in antlib's proposal.
Roles provide two things:

    1) The interface use by the container to express interest in the role.
    Like TaskContainer.

    2) An optional adapter class to be used to solve java type mismatches.

We have two adapters defined: (1) TaskAdapter, used to make beans become Task;
(2) DataTypeAdapterTask, used to make data-types become Task.

In your case above,  there will be no Unknown elements being created, 
things will be directly resolved to DataTypes and adapted to become Tasks. All very kosher.
Actually, an interesting thing that can be done is that the DT adapter can take a look
and see if <fileset> provides an "id" attribute and if not, it can emit a warning
since as you well said, it would be useless. Unless you are playing some
form of side effects game.

Also, several roles may use the same interface. What that means is that
we are saying that objects of those roles should always be accepted in the same places.
That is the case for tasks and datatypes, they both use the same container interface
therefore they must be accepted in all the same places.

> The underlying problem here is the fact that Ant1 tries to perform
> configuration at parse time when it doesn't have enough information. For
> some tasks it has to defer the config but it does that by making everything
> a task.
> 

True, I do not like the bussiness of UnknownElement and the RuntimeConfigurable
and so on. Now that I am trying to regularize and generalize I can see a lot of 
cleaning and simplification that could be done in the ANT2 way. But for ANT1,
as others have said, we have to live with some of it.

> Regularising treatment of datatypes and tasks in the core does not address
> this. It will just cement the incorrect Ant1 behaviour. I don't see a need
> to have the core behave that generically.
> 

Well we disagree. Had we regularized this thing 7 month ago, we would have caught
the irregularity with data-types and given a proper solution. I think it is imperative
that we address these issues before we finish adding more uncoordinated patches to solve
each one of the individual bugs that keep on comming in.

The code is littered with little tables and littles ifs all over that have been added on
patch after patch after patch, because of the irregularities.

> > You will have to make a special case for TaskContainer
> > and we will be back on the same crappy spot we have
> > been sitting for more than a year.
> 
> 7 months actually.
> 

The irregularities with DataTypes are older than that, I think.
It is more than a year since people are complaining that <typedef>
could not be used as a toplevel task. All because ProjectHelper
is so full of special cases.

In any case, antlib's proposal addresses this issues consistently and
in a backward compatible way.

And by the way, about defining interfaces in the container. No one 
complained about TaskContainer. I have never heard anyone
saying or complining to the fact that your task has to implement
the TaskContainer interface in order to accept Tasks. Now why there
is so much bruhaha about using the same principle for other
containers? It is beyond me.

> >
> > Now lets talk about POLYMORPHISM in its own right.
> >
> > In my opinion, the problem we have in ANT, if that we
> > mix in the syntax of an element: the name of the
> > element to use AND the name of the method to invoke.
> > Polymorphism requires a way to diferentiate one from
> > the other.
> >
> > Your approach provides that separation, so it solves
> > the polymorphic issue. The thing I do not like about
> > it is that it breaks completely any resemblance of
> > DTD. In other words there is no way for AntStructure
> > to generate a DTD. Why?, see the example:
> >
> >  <diff>
> >      <fromFS ant:type="zipfileset"
> > dir="htdocs/manual"
> >  prefix="docs/user-guide"/>
> >      <toFS ant:type="classfileset"
> >  dir="build/classes">
> >         <root classname="org.apache.tools.ant.Main"/>
> >      </toFS>
> >  </diff>
> >
> > There is no way to define a DTD for <formFS> or <toFS>
> > because its structure depends on the the value of
> > 'ant:type' and not on the value of the tag.
> >
> > A much more XML friendly way would be to let the
> > element describe the type and the attribute describe
> > the method to use:
> >
> >  <diff>
> >    <zipfileset ant:as="fromFS"  dir="htdocs/manual"
> > prefix="docs/user-guide"/>
> >    <classfileset ant:as="toFS" dir="build/classes">
> >         <root classname="org.apache.tools.ant.Main"/>
> >    </classfileset>
> >  </diff>
> >
> 
> So you begin to taste the chocolate. 

Oh, did I ever said I did not eat chocolate? I just want the good one,
NO "MILKY-WAY" FOR ME :-)

As I have said before, polymorphism is a good thing, and probably a necessary thing.
But they are no replacement for Roles.

> The problem with the above is that it
> is not easy to support references. Again from mutant
> 
>   <diff>
>      <fromFS ant:refid="my.fileset"/>
>      <toFS ant:refid="your.fileset"/>
>   </diff>
> 
> I actually tried the "ant:as" approach but settled on the "ant:type" syntax
> because of the above. It is more regular to align the nested element name
> with the method.

I think you should reconsider. I think it is imperative that whatever solution we
come up with, particularly in ANT2, needs to be XMLEditors friendly.
There are more and more IDEs that contain XML validating editors and people
want to be able to use it with ANT. Your syntax will make that almost
impossible.

Using "ant:as" would make a lot of diference. It may not solve every case, but it
would help a lot.

Now with your specific issue above, I do not see the problem. The way I envision it
if you do not specify "ant:as" the current rules should apply. The name of the element
is the name of the method, ant its type should be either exactly that of the parameter
of the method or a reference compatible with the type of that parameter.

Anyway, time to go to work....

Jose Alberto



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message