You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by James Cook <ji...@iname.com> on 2000/12/08 05:39:11 UTC
Tool Integration Problems
I may be beginning to see why the antitdote team resorted to parsing the
build scripts themselves, as opposed to simply using the Project-Target-Task
objects that Ant produces.
It appears that a Task does not have to conform to JavaBean standards,
meaning that there is no way for a tool to ascertain what value an attribute
was set to. For example, given a particular Task such as Mkdir.java, there
is a setDir(File) method, but no getDir() method. Therefore, a tool that
wants to display the value of "dir" to a user for editing is out of luck.
The only alternative is to parse the XML file manually to obtain the value
of these attributes.
Is this a fairly correct statement?
I know there are quite a few different efforts surrounding Ant right now
that may or may not lead to significant changes in the structure. I saw some
discussion relating to the creation of a new package (connector) for two-way
tool integration. Has this started? (I think it is perhaps overkill.) Simply
forcing Task authors to provide getters may be good enough. This can be
validated at parse time (in IntrospectionHelper) for enforcement.
I feel if each tool is responsible for parsing a build file then we are in
for a world of hurt regarding compatibility.
Feedback?
jim
Re: Tool Integration Problems
Posted by James Duncan Davidson <du...@x180.net>.
On 12/8/00 5:15 AM, "Steve Loughran" <st...@iseran.com> wrote:
>> Simply forcing Task authors to provide getters may be good enough. This
> can be
>> validated at parse time (in IntrospectionHelper) for enforcement.
>
> dunno about enforcement. Kind of strict that. But it could be made part of
> the requirements to get your task included into the cvs tree.
Its not needed if the underlying data model is exposed the right way. Done
the way it is in AntEater, there is no need to make this restriction.
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: Tool Integration Problems
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "James Cook" <ji...@iname.com>
To: <an...@jakarta.apache.org>
Sent: Friday, December 08, 2000 4:39 AM
Subject: Tool Integration Problems
> It appears that a Task does not have to conform to JavaBean standards,
> meaning that there is no way for a tool to ascertain what value an
attribute
> was set to. For example, given a particular Task such as Mkdir.java, there
> is a setDir(File) method, but no getDir() method. Therefore, a tool that
> wants to display the value of "dir" to a user for editing is out of luck.
> The only alternative is to parse the XML file manually to obtain the value
> of these attributes.
>
Regardless of what Ant2.0 does regarding the provision of some DOM for an
ant build file, it may be good practice for all future ant tasks to start
adhering to the bean rules and provide side effect free accessor methods.
The reason I've rarely bothered on tasks I've written is that there was no
apparent value in the extra coding effort.
> Simply forcing Task authors to provide getters may be good enough. This
can be
> validated at parse time (in IntrospectionHelper) for enforcement.
dunno about enforcement. Kind of strict that. But it could be made part of
the requirements to get your task included into the cvs tree.
-steve
Re: Tool Integration Problems
Posted by "Simeon H.K. Fitch" <si...@fitch.net>.
James Cook wrote:
>
> I may be beginning to see why the antitdote team resorted to parsing the
> build scripts themselves, as opposed to simply using the Project-Target-Task
> objects that Ant produces.
Thanks for noticing :-) As you probably discovered, Antidote has a
sub-package called "acs" which is short for "Ant Construction Set" :-]
The idea is to provide a set of classes that allow for easy run-time
construction of build data definitions, including instrospection and
customizer support throught the JavaBeans API (see below).
> It appears that a Task does not have to conform to JavaBean standards,
> meaning that there is no way for a tool to ascertain what value an attribute
> was set to. For example, given a particular Task such as Mkdir.java, there
> is a setDir(File) method, but no getDir() method. Therefore, a tool that
> wants to display the value of "dir" to a user for editing is out of luck.
> The only alternative is to parse the XML file manually to obtain the value
> of these attributes.
I know that there are a lot of people on this list that are strongly
against adding API methods to the Ant data model that aren't needed by
the core of Ant. I personally don't understand the emphatic resistence,
but I've decided just to live with it and move forward with the ACS. It
has definately slowed down Antidote development for me, but it does
afford me the ability to enforce certain design patterns, such as the
JavaBeans one. In the ACS, the data model classes do conform to the
property access specification, and also implement the change event
semantics, all with very little additional coding (I have a base class
where the common event and property handling is implemented). Where I
have spent, and will end up spending, additional coding outside the data
model that is necessary for only the GUI (right now) is in the
implementation of full featured BeanInfo classes. Here I'm defining the
set of property accessors that I want truly exposed via the GUI (a
subset of the possible), and providing user friendly descriptions of
each property. I also define customizers for each JavaBean, although
they all right now default to my DynamicCustomizer that is basically a
property sheet.
If I /were/ king 8^], I would require that the tasks (and Project and
Target for that matter) conform to the JavaBeans specification,
supporting proper get/set semantics where appropriate, and encourage
that they use change event support provided by some abstract base class.
This is hardly "extra" work, and it certainly has no performance impact.
I would *not* require the BeanInfo support, as that *is* a lot of extra
work you don't want task developers to care about. If they want
sophisticated support in Antidote (rather than simple instrospection
based editing) then they would need to implement a BeanInfo class, and
maybe a Customizer for it, but that is a different issue, and can be
tackled by a different developer.
> tool integration. Has this started? (I think it is perhaps overkill.) Simply
> forcing Task authors to provide getters may be good enough. This can be
> validated at parse time (in IntrospectionHelper) for enforcement.
You know where I stand on this (although I don't think run-time
enforcement is necessary, just peer review), and I feel that I've heard
a lot from dissenters on this issue.
Are there any other supporters out there, or are we truly in the
minority on this? Does it have to do with unfamiliarity with the
JavaBeans spec, and a belief that it is only for GUI builder support, or
is that basic stuff for everyone?
>
> I feel if each tool is responsible for parsing a build file then we are in
> for a world of hurt regarding compatibility.
>
That is where we are now. I haven't had the time to look at Anteater
yet, or myrmidon, so I don't know where the revolution proposals stand
on this. I'm hoping that the core Ant developers keep an open and
objective mindset and consider the long term possibilities of the tool.
sim
Re: Tool Integration Problems
Posted by James Duncan Davidson <du...@x180.net>.
On 12/7/00 8:39 PM, "James Cook" <ji...@iname.com> wrote:
> It appears that a Task does not have to conform to JavaBean standards,
> meaning that there is no way for a tool to ascertain what value an attribute
> was set to. For example, given a particular Task such as Mkdir.java, there
> is a setDir(File) method, but no getDir() method. Therefore, a tool that
> wants to display the value of "dir" to a user for editing is out of luck.
> The only alternative is to parse the XML file manually to obtain the value
> of these attributes.
>
> Is this a fairly correct statement?
It may be correct in Ant.present.. And there could be a mandate that all
Tasks should have gets, but that is just a mandate and not enforceable at
the code level.
This is one of the many reasons why AntEater doesn't place instances of the
Task implementation itself into the object tree -- but a generic Task object
which has a hold of all the attributes in Hashed form. Therefore, this setup
should allow a FrontEnd (AntEater parlance for a client that is using ant
such as a GUI) to fully breeze through all the attributes of a Task without
requiring that instance implementations of that Task actually implement
gets.
The other benefit to this approach is that instances aren't created until
exactly the time they are needed. This forces all properties to be resolved
right at execution time instead of any other time -- and makes sure that the
task at hand only sees the project tree as it exists right when it is
executed.
> I feel if each tool is responsible for parsing a build file then we are in
> for a world of hurt regarding compatibility.
Yep. The goal in AntEater is to have the ability to get the object tree from
any FrontEnd via a ProjectBuilder.buildFromFile(File file) call and use it
-- centralizing all logic into one place.
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: Tool Integration Problems
Posted by Peter Donald <do...@apache.org>.
At 10:25 9/12/00 -0600, Simeon H.K. Fitch wrote:
>Peter Donald wrote:
>
>> >Simply
>> >forcing Task authors to provide getters may be good enough. This can be
>> >validated at parse time (in IntrospectionHelper) for enforcement.
>>
>> Not desirable. Only a small population of users will ever use the getters
>> but it constitutes a significant amount of work.
>
>I disagree here. Adding a "public String getFoo()" is a 30 second task.
>I would be more than willing to volunteer my time to go through very
>task in Ant and provide such accessor methods if the group voiced
>support for it.
if every property name get<blah> mapped to one property then it would not
be difficult but still a lot of work. However this is not the case.
Sometimes there are 3-4 attributes that map to one underlying attribute or
the task itself modifies the value or uses for some transform etc.
If there was a simple 1-to-1 mapping then it may be acceptable. It is
neither simple nor something that is useful for a minority of users of GUIs.
Have alook at mymidon proposal to see how I think it should be done.
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 |
*-----------------------------------------------------*
AW: AW: Tool Integration Problems
Posted by Christoph Wilhelms <Ch...@t-online.de>.
> > >Indexed properties, as defined by the JavaBeans spec. A little more
> > >involved than the "getFoo()" example, but not a big deal, especially
> > >since it can be handled by an abstract base class or a delegation
class.
> >
> > +1 for bean-spec conform development! Not only for task... Don't you
agree,
> > Sim!?! ;-)
> >
> Aha! You've been lurking and I caught you with my bait! Awahahahahaha!!
> However,
> I still stand firmly in my position against any VAJ code (generated or
> otherwise) in Antidote.
+1 for bean-spec conform model - components!
+1 for bean-spec conform gui - components!
(overall +2 for bean-spec conform developement ;-))
-1 (or more) to IDE-specific code (just like VAJ). If you take a look at the
VAJ-toolintewgration GUI-code you'll notice that there isn't any specific
VAJ code in it! Of course it 1st was generated using VAJ, but after thet I
spend some time in code-beautification and optimizasion! Just some patterns
like "lazy-instantiation" are still in it - and this is IMHO - a fairly good
style of building (GUI)-code, for instantiation and initialization of
properties is in one place (in it's get-method). I am using this
implementation/pattern for GUIs even if there is no VAJ available for it is
more productive than any other handmade coding: you have nearly no chance to
make mistakes ;-). But still it is coding style. I just want to point out,
that it isn't VAJ specific! Really :-)!
Greetings,
Chris
Re: AW: Tool Integration Problems
Posted by "Simeon H.K. Fitch" <si...@fitch.net>.
Christoph Wilhelms wrote:
> >Indexed properties, as defined by the JavaBeans spec. A little more
> >involved than the "getFoo()" example, but not a big deal, especially
> >since it can be handled by an abstract base class or a delegation class.
>
> +1 for bean-spec conform development! Not only for task... Don't you agree,
> Sim!?! ;-)
>
Aha! You've been lurking and I caught you with my bait! Awahahahahaha!!
Seriously, I know where you are going with this, and I have continued to
consider you proposal that the GUI components in Antidote provide a
default ctor so that they can be used in a GUI builder. Either Stephan
or Conor (I forget who) correctly pointed out to me that providing a
default ctor and then an init() method that accepts the data required
for starup shouldn't be any big deal, albeit an extra step required when
using the class by hand.
My comments in my previous mail (above) were relative to the data model,
in which I strongly value a JavaBeans compliant implementation. Lest I
be labeled a hypocrite, I will be happy to make the according changes to
the Antidote GUI components if you are still in favor of them. However,
I still stand firmly in my position against any VAJ code (generated or
otherwise) in Antidote.
Let me know!
sim
AW: Tool Integration Problems
Posted by Christoph Wilhelms <Ch...@t-online.de>.
> > >Simply
> > >forcing Task authors to provide getters may be good enough. This can be
> > >validated at parse time (in IntrospectionHelper) for enforcement.
> >
> > Not desirable. Only a small population of users will ever use the
getters
> > but it constitutes a significant amount of work.
>
>I disagree here. Adding a "public String getFoo()" is a 30 second task.
>I would be more than willing to volunteer my time to go through very
>task in Ant and provide such accessor methods if the group voiced
>support for it.
>
> > Also how would you deal
> > with sub-elements.
>
>Indexed properties, as defined by the JavaBeans spec. A little more
>involved than the "getFoo()" example, but not a big deal, especially
>since it can be handled by an abstract base class or a delegation class.
+1 for bean-spec conform development! Not only for task... Don't you agree,
Sim!?! ;-)
Greetings,
Chris
Re: Tool Integration Problems
Posted by "Simeon H.K. Fitch" <si...@fitch.net>.
Peter Donald wrote:
> >Simply
> >forcing Task authors to provide getters may be good enough. This can be
> >validated at parse time (in IntrospectionHelper) for enforcement.
>
> Not desirable. Only a small population of users will ever use the getters
> but it constitutes a significant amount of work.
I disagree here. Adding a "public String getFoo()" is a 30 second task.
I would be more than willing to volunteer my time to go through very
task in Ant and provide such accessor methods if the group voiced
support for it.
> Also how would you deal
> with sub-elements.
Indexed properties, as defined by the JavaBeans spec. A little more
involved than the "getFoo()" example, but not a big deal, especially
since it can be handled by an abstract base class or a delegation class.
sim
Re: Tool Integration Problems
Posted by Peter Donald <do...@apache.org>.
At 11:39 7/12/00 -0500, you wrote:
>I may be beginning to see why the antitdote team resorted to parsing the
>build scripts themselves, as opposed to simply using the Project-Target-Task
>objects that Ant produces.
;)
>It appears that a Task does not have to conform to JavaBean standards,
>meaning that there is no way for a tool to ascertain what value an attribute
>was set to. For example, given a particular Task such as Mkdir.java, there
>is a setDir(File) method, but no getDir() method. Therefore, a tool that
>wants to display the value of "dir" to a user for editing is out of luck.
>The only alternative is to parse the XML file manually to obtain the value
>of these attributes.
right.
Thats why I like the idea of a DOM-like structure. This DOM-like structure
can be read (and possibly writeable in special cases). This DOM-like
structure is then interpreted into a task object that is then executed.
>Is this a fairly correct statement?
yep.
>I know there are quite a few different efforts surrounding Ant right now
>that may or may not lead to significant changes in the structure. I saw some
>discussion relating to the creation of a new package (connector) for two-way
>tool integration. Has this started? (I think it is perhaps overkill.)
connector stuff is just for running ant from within other tools. Ie there
could be vaj, jbuilder, emacs connectors...
>Simply
>forcing Task authors to provide getters may be good enough. This can be
>validated at parse time (in IntrospectionHelper) for enforcement.
Not desirable. Only a small population of users will ever use the getters
but it constitutes a significant amount of work. Also how would you deal
with sub-elements.
>I feel if each tool is responsible for parsing a build file then we are in
>for a world of hurt regarding compatibility.
exactly ;)
Which is one of the reasons I made a recent proposal. If you have a look at
proposal/myrmidon it is specifically designed to be able to be hosted in
different environments. So it would be very trivial to write a GUI that
modified ant build-files and rerun them. It uses the DOM-like model and
interprests them and IMHO is relatively easy to develope extentions to -
but that is to be expected considering that was one of the main aims of
proposal. Thou I may be biased ;)
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 |
*-----------------------------------------------------*