You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Adam Murdoch <ad...@yahoo.com> on 2001/12/16 12:34:49 UTC
IntrospectionHelper questions
Hi,
Some questions about IntrospectionHelper and friends.
- IntrospectionHelper arbitrarily chooses an attribute setter method for a
class when there is more than one of the same precedence. It silently
ignores the others. Is there a reason for not failing, or at least writing
a warning? Any problems with me adding a warning? Is an arbitrary choice
of setter method really that useful?
- Same sort of thing happens with 'create', 'add' and 'addConfigured'. What
was the intention there? It looks like it was supposed to be choosing one
of them, and ignoring the rest (it's not *quite* doing that). Any problems
with a warning? Again, is arbitrary choice really that useful?
- It looks like a refactor is overdue on the project
parsing/construction/configuring side of things. With a bit of a tidy up,
it should be a fair bit easier to add new features (e.g. the polymorphic
datatypes idea that was raised a while back), improve existing features
(e.g. a lightweight <antcall>), conditionally switch on experimental stuff
(e.g. well, pretty much everything on the 1.9 action list), and reuse (e.g.
for, say, loading up task lib descriptors from an XML file - or in Ant2).
I realise, of course, that this stuff is the core of Ant, and that the whole
backwards compatibility story depends heavily on it. So the question is,
would there be any support for doing this? Exactly what "this" means, we
can decide on later. I'm just trying to get a feel for what is fixed in
stone, and what is fair game for tidy-up.
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: IntrospectionHelper questions
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 18 Dec 2001, Adam Murdoch <ad...@yahoo.com> wrote:
> I'd like to split up building the element/attribute tree, and
> building the target/task tree into 2 separate stages.
I agree completely. Another thing that doesn't really work right now,
that's what triggered thinking about it in the Ant1 context again, is
redefining existing task names with <taskdef> (we will create the task
and all child element instances using the existing task definition
instead of the user supplied one).
> What I'm unsure of is how much room we have to play in.
Not too much, I'd go so far to say that we can only fiddle with privat
and package privat areas and at least simulate the old behavior for
things that get exposed to public - this includes access to
references.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: IntrospectionHelper questions
Posted by Adam Murdoch <ad...@yahoo.com>.
> From: Stefan Bodewig [mailto:bodewig@apache.org]
>
> > I realise, of course, that this stuff is the core of Ant, and that
> > the whole backwards compatibility story depends heavily on it.
>
> Probably, yes. You could try to refactor some things to see where
> problems may arise (like I want to give the whole RuntimeConfigurable
> / UnknownElement combo a second and probably third thought after
This is pretty much what I had in mind. I'd like to split up building the
element/attribute tree, and building the target/task tree into 2 separate
stages. Right now we do both at the same time (if we can - some of the task
tree construction has to get deferred). By splitting it up, we can do
things like:
- Simplify building of both trees.
- Reuse the element/attribute tree in <antcall> and <ant>.
- Swap in different element/attribute tree builders.
- Swap in different task tree builders. E.g. a 'strict' ant 1 project
builder, vs. one that includes experimental ant1.9/ant 2 features.
What I'm unsure of is how much room we have to play in. Which of these
would be considered part of the public API (as in, can't change any
non-private stuff)?
- IntrospectionHelper
- RuntimeConfigurable
- UnknownElement
- TaskAdapter
- ProjectHelper, ignoring configureProject() and the property methods.
- Target.addDataType(), Target.addTask(), Target.execute(),
Target.performTasks(), Target.replaceChild().
- Task.getReplacement(), Task.getRuntimeConfigurableWrapper(),
Task.markInvalid(), Task.maybeConfigure(), Task.perform(),
Task.setRuntimeConfigurableWrapper(), Task.wrapper
Which of these behaviours would be considered fixed?
- Task and data type instantiation at parse time (as opposed to *validation*
at parse time).
- Visibility of references. Objects with an 'id' are constructed and added
to the project references table at parse time. They are configured (ie
attributes set) at runtime, just before they are executed.
Project.getReference() will happily hand out objects that have not been
configured.
> christmas) but you probably wouldn't get far.
>
> Revamping the core, really takes a major version change IMHO.
Oh I know. That's why I'm pestering you with all these questions :)
Leaving all this until Ant2 is an alternative. A very tempting alternative
..
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: IntrospectionHelper questions
Posted by Stefan Bodewig <bo...@apache.org>.
On Sun, 16 Dec 2001, Adam Murdoch <ad...@yahoo.com> wrote:
> - IntrospectionHelper arbitrarily chooses an attribute setter method
> for a class when there is more than one of the same precedence.
You don't have any influence on the order by which the VM hands the
methods to this class, that's why it is an arbitrary choice. Magesh
has changed the code so that the setters with non-String arguments now
take precedence over those with String arguments - this happens in Ant
itself when we keep the old API for backwards compatibility (other
tasks extending Ant's tasks) but take advantage of more sophisticated
things like EnumeratedAttribute or Ant's magic when you use File
arguments.
> Any problems with me adding a warning?
No problem.
> I realise, of course, that this stuff is the core of Ant, and that
> the whole backwards compatibility story depends heavily on it.
Probably, yes. You could try to refactor some things to see where
problems may arise (like I want to give the whole RuntimeConfigurable
/ UnknownElement combo a second and probably third thought after
christmas) but you probably wouldn't get far.
Revamping the core, really takes a major version change IMHO.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: IntrospectionHelper questions
Posted by Peter Donald <pe...@apache.org>.
On Sun, 16 Dec 2001 23:55, Adam Murdoch wrote:
> > At the moment I am actually going through and refactoring this stuff in
> > preparation for Ant2 - but thats largely because we don't need to
> > maintain
> > any backwards compatability there.
>
> No backwards compatability?
yeppo !
> Sounds fantastic. Need a hand?
hell yes! I am currently working out of proposal/myrmidon but it is going to
be fairly dynamic/hectic for the time being (starting to reintegrate ant1
stuff into myrmidon). However if you want to have a look and lend a hand feel
free to.
The main "API" for tasks is in org.apache.myrmidon.api.* - theres a few
changes that still need to be made to it (decouple a bit from Avalon, remove
the JavaVersion stuff etc). But it is mostly stable.
Theres other APIs sitting around in there that you may want to have a look at
and they enable you to embed ant, modify registered tasks etc However they
are fairly fine grained (and thus a little complex). When it gets closer to
being digestable by the public a simple facade needs to be created so that
mere mortals can grok it without too much hassle.
If you want to have a go at it you may want to try to port across ant1.xs
IntrospectionHelper so that the DefaultConfigurator uses it. Currently
DefaultConfigurator does not cache any reflection data and is thus a bit slow
;)
--
Cheers,
Pete
*-------------------------------------*
| Does the name `Pavlov' ring a bell? |
*-------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: IntrospectionHelper questions
Posted by Magesh Umasankar <um...@apache.org>.
From: "Adam Murdoch" <ad...@yahoo.com>
> > user. Want to submit a patch for that?
> Sure. Is writing to System.out bad form?
Yes, it is.
> How about a doc patch instead of a warning?
+1, as documenting it would proactively help the
task writer than for her to see it as a debug warning
message after the task has been written. Of course,
issuing a warning at runtime would be useful too.
But having it do so may be considered pretty
low priority, IMHO.
Cheers,
Magesh
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: IntrospectionHelper questions
Posted by Adam Murdoch <ad...@yahoo.com>.
> -----Original Message-----
> From: Magesh Umasankar [mailto:umagesh@apache.org]
> Sent: Monday, 17 December 2001 12:41 AM
> To: Ant Developers List
> Subject: Re: IntrospectionHelper questions
>
>
> From: "Adam Murdoch" <ad...@yahoo.com>
>
> > Yep - that bit was pretty clear. The behaviour when a
> > String is involved is consistent - it will always choose
> > the non-String one. My question was related to what
> > happens when there's more than one non-String setter
> > method. Ant will choose one of them, based on the order
> > Class.getMethods() returns them (which, according to the
> > Javadocs, is unspecified).
>
> When it isn't a String, Ant will choose the *last* method
> that gets returned by Class.getMethods(). You are right
> in saying that that order is not guaranteed across
> VMs and platforms. So, any task that has lots
> of set methods for the same attribute, is either
> programmed with a single OS/VM in mind or the
> author doesn't care which setter gets called. At the
> moment in Ant 1.1, issuing a debug warning stating
> the methods that get ignored would clarify things to the
> user. Want to submit a patch for that?
>
Sure. Is writing to System.out bad form? I can't see any real easy way of getting hold of a Project to do the logging. How about a doc patch instead of a warning?
> Thanks
> Magesh
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: IntrospectionHelper questions
Posted by Magesh Umasankar <um...@apache.org>.
From: "Adam Murdoch" <ad...@yahoo.com>
> Yep - that bit was pretty clear. The behaviour when a
> String is involved is consistent - it will always choose
> the non-String one. My question was related to what
> happens when there's more than one non-String setter
> method. Ant will choose one of them, based on the order
> Class.getMethods() returns them (which, according to the
> Javadocs, is unspecified).
When it isn't a String, Ant will choose the *last* method
that gets returned by Class.getMethods(). You are right
in saying that that order is not guaranteed across
VMs and platforms. So, any task that has lots
of set methods for the same attribute, is either
programmed with a single OS/VM in mind or the
author doesn't care which setter gets called. At the
moment in Ant 1.1, issuing a debug warning stating
the methods that get ignored would clarify things to the
user. Want to submit a patch for that?
Thanks
Magesh
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: IntrospectionHelper questions
Posted by Adam Murdoch <ad...@yahoo.com>.
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Sunday, 16 December 2001 10:26 PM
> To: Ant Developers List
> Subject: Re: IntrospectionHelper questions
>
>
> On Sun, 16 Dec 2001 22:34, Adam Murdoch wrote:
> > Some questions about IntrospectionHelper and friends.
> >
> > - IntrospectionHelper arbitrarily chooses an attribute setter
> method for a
> > class when there is more than one of the same precedence. It silently
> > ignores the others. Is there a reason for not failing, or at
> least writing
> > a warning? Any problems with me adding a warning? Is an
> arbitrary choice
> > of setter method really that useful?
>
> Well I haven't looked at the code but I was under the impression that it
> would arbitarily choose a setter and ignore the rest. owever it
> would try the
> string setter if the other setter fails.
>
> The reason for this is essentially backwards compatability. We have a few
> classes where something equivelent to the following is present
>
> public void setFoo( final String foo )
> {
> setFoo( Project.toBoolean( foo ) );
> }
>
> public void setFoo( final boolean foo )
> {
> _foo = foo;
> }
>
> We need to keep the first method for backwards compatability
> while the second
> method is how it is supposed to be used.
>
Yep - that bit was pretty clear. The behaviour when a String is involved is consistent - it will always choose the non-String one. My question was related to what happens when there's more than one non-String setter method. Ant will choose one of them, based on the order Class.getMethods() returns them (which, according to the Javadocs, is unspecified).
> > - It looks like a refactor is overdue on the project
> > parsing/construction/configuring side of things. With a bit of
> a tidy up,
> > it should be a fair bit easier to add new features (e.g. the polymorphic
> > datatypes idea that was raised a while back), improve existing features
> > (e.g. a lightweight <antcall>), conditionally switch on
> experimental stuff
> > (e.g. well, pretty much everything on the 1.9 action list), and
> reuse (e.g.
> > for, say, loading up task lib descriptors from an XML file - or
> in Ant2).
> >
> > I realise, of course, that this stuff is the core of Ant, and that the
> > whole backwards compatibility story depends heavily on it. So
> the question
> > is, would there be any support for doing this? Exactly what
> "this" means,
> > we can decide on later. I'm just trying to get a feel for what
> is fixed in
> > stone, and what is fair game for tidy-up.
>
> Well the API and the behaviour is largely set in stone. If you
> can refactor
> the insides to be cleaner then go for it - however because Ant
> was originally
> developed in a manner that makes it difficult to evolve (ie lots
> of protected
> attributes, plenty of public methods, side effects galore) it is
> going to be
> a tough job.
Hmmm. Not sure I'll bother - it's the blurry bits between the API and the insides that I was most interested in tidying up. I guess the backwards compatibility rule means anything not strictly internal (private, say) can't be messed with too much.
>
> At the moment I am actually going through and refactoring this stuff in
> preparation for Ant2 - but thats largely because we don't need to
> maintain
> any backwards compatability there.
>
No backwards compatability? Sounds fantastic. Need a hand?
> --
> Cheers,
>
> Pete
>
> -------------------------------------------------
> "Sometimes its better to keep your mouth shut and
> let people think your an idiot, than to open it
> and remove all doubt."
> -------------------------------------------------
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: IntrospectionHelper questions
Posted by Peter Donald <pe...@apache.org>.
On Sun, 16 Dec 2001 22:34, Adam Murdoch wrote:
> Some questions about IntrospectionHelper and friends.
>
> - IntrospectionHelper arbitrarily chooses an attribute setter method for a
> class when there is more than one of the same precedence. It silently
> ignores the others. Is there a reason for not failing, or at least writing
> a warning? Any problems with me adding a warning? Is an arbitrary choice
> of setter method really that useful?
Well I haven't looked at the code but I was under the impression that it
would arbitarily choose a setter and ignore the rest. owever it would try the
string setter if the other setter fails.
The reason for this is essentially backwards compatability. We have a few
classes where something equivelent to the following is present
public void setFoo( final String foo )
{
setFoo( Project.toBoolean( foo ) );
}
public void setFoo( final boolean foo )
{
_foo = foo;
}
We need to keep the first method for backwards compatability while the second
method is how it is supposed to be used.
> - It looks like a refactor is overdue on the project
> parsing/construction/configuring side of things. With a bit of a tidy up,
> it should be a fair bit easier to add new features (e.g. the polymorphic
> datatypes idea that was raised a while back), improve existing features
> (e.g. a lightweight <antcall>), conditionally switch on experimental stuff
> (e.g. well, pretty much everything on the 1.9 action list), and reuse (e.g.
> for, say, loading up task lib descriptors from an XML file - or in Ant2).
>
> I realise, of course, that this stuff is the core of Ant, and that the
> whole backwards compatibility story depends heavily on it. So the question
> is, would there be any support for doing this? Exactly what "this" means,
> we can decide on later. I'm just trying to get a feel for what is fixed in
> stone, and what is fair game for tidy-up.
Well the API and the behaviour is largely set in stone. If you can refactor
the insides to be cleaner then go for it - however because Ant was originally
developed in a manner that makes it difficult to evolve (ie lots of protected
attributes, plenty of public methods, side effects galore) it is going to be
a tough job.
At the moment I am actually going through and refactoring this stuff in
preparation for Ant2 - but thats largely because we don't need to maintain
any backwards compatability there.
--
Cheers,
Pete
-------------------------------------------------
"Sometimes its better to keep your mouth shut and
let people think your an idiot, than to open it
and remove all doubt."
-------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>