From: "Conor MacNeill" <[EMAIL PROTECTED]>
> > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
>
> 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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
