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/30 04:32:39 UTC
[PATCH] myrmidon task configurer
Hi,
This is a patch to myrmidon's task configurer, to cache reflection info.
The goal was to start playing with some new configuration features, but
unfortunately I didn't find time to do much with it. I'd like to put this
on hold temporarily, so I'm submitting the changes as they currently stand.
Configuration should be heaps faster now.
Here's what I'd like to try sometime soon-ish:
* Allow an object (task or data type) to override parts of its configuration
process.
This would be an alternative to implementing Configurable (which requires
the object to deal with configuring itself entirely).
The plan is to allow a class to provide a customised introspector (an
ObjectConfigurer) via a static method - getConfigurer(), say. This would
allow a class to do simple things like:
- Explicitly choose an overloaded setter/adder/creator method to use when
there's more than one.
- Ignore certain setter/adder/creator methods.
- Map text content to a particular attribute (e.g. "message" in the <log>
task).
- Deal with attributes or elements whose names are only known at runtime
(e.g. compiler adaptors).
- etc.
* Deal with references.
Have the configurer resolve (and type check) references to data types,
rather than forcing the object do it. An adder method would be passed an
object, and whether that object was obtained by reference, or created and
configured inline, the parent object doesn't know or care.
This raises the issue of ownership, and immutability - maybe a clone gets
passed to the adder methods.
* Polymorphic types.
This was raised a few months ago and it is truely an excellent idea. This
would allow the configurer to pass an adder method, an object of any class
that is assignable to the declared type. As Peter pointed out, this would
neatly solve the adaptor problem that is being discussed.
* Lifecycle management.
It would be handy if the lifecycle of nested objects was handled by the
container, rather than forcing the parent object to do it. Not the
configurer's job, necessarily.
* Put some tests together, and maybe some docs as well (yeah sure).
Adam
Re: [PATCH] myrmidon task configurer
Posted by Peter Donald <pe...@apache.org>.
On Sun, 30 Dec 2001 14:32, Adam Murdoch wrote:
> This is a patch to myrmidon's task configurer, to cache reflection info.
> The goal was to start playing with some new configuration features, but
> unfortunately I didn't find time to do much with it. I'd like to put this
> on hold temporarily, so I'm submitting the changes as they currently stand.
> Configuration should be heaps faster now.
Okay - I just committed this - except I moved it all into the
components.configurator package. If we decide later to allow full
pluggability (rather than a TaskInfo style approach) we can break it out
again.
--
Cheers,
Pete
----------------------------------------------------
"The only way to discover the limits of the possible
is to go beyond them into the impossible."
-Arthur C. Clarke
----------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XSL Tasks
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
----- Original Message -----
From: "Jeff Turner" <je...@socialchange.net.au>
> Might want to look at
>
> http://www.langdale.com.au/styler/
[...]
> Mentioned in a mail by author Arnold deVos <ad...@langdale.com.au>, with
> subject "SUBMIT: candidate for an optional task".
>
> Might be worth adding to the "external tools" page..
I have added this to the external tools page.
Erik
p.s. Where do I find info on how to generate docs from the xdocs? I did it
manually for this one, but I know I've seen a pointer to it before. Its the
jakarta-site2, right? And then what? Thanks!
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XSL Tasks
Posted by Jeff Turner <je...@socialchange.net.au>.
On Tue, Jan 01, 2002 at 09:38:27PM -0600, Bob Lee wrote:
> ----- Original Message -----
> From: "Erik Hatcher" <ja...@ehatchersolutions.com>
> To: "Ant Developers List" <an...@jakarta.apache.org>
> Sent: Tuesday, January 01, 2002 9:27 PM
> Subject: Re: XSL Tasks
>
>
> > ----- Original Message -----
> > From: "Bob Lee" <cr...@crazybob.org>
> >
> >
> > > Specifically, I'm just working on some interface extensions.
> > >
> > > The current interface is geared towards transforming a directory of XML
> > > content.
> > >
> > > I'm making ant targets for my currrent project that use XSL stylesheets
> to
> > > generate code and descriptors for entity beans off of a single XML file.
> >
> > So you're process runs a single XML file through several XSL
> > transformations?
>
> Exactly.
Might want to look at
http://www.langdale.com.au/styler/
"The styler task makes useful combinations of XSLT transformations
easy to specify in an Ant build file. Like the built-in Ant task
style, styler can apply a single transformation to a set of XML files.
But it can also:
- handle multiple transformations, in parallel or pipelined.
- enable transformations that split or merge files
- process non-XML files, especially HTML (based on JTidy)
- apply non-XSLT transformation, especially "regular fragmentations"
- use any custom XMLReader or XMLFilter class to handle new file
formats and transformation techniques.
"
Mentioned in a mail by author Arnold deVos <ad...@langdale.com.au>, with
subject "SUBMIT: candidate for an optional task".
Might be worth adding to the "external tools" page..
--Jeff
> > Erik
>
> Bob
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XSL Tasks
Posted by Bob Lee <cr...@crazybob.org>.
----- Original Message -----
From: "Erik Hatcher" <ja...@ehatchersolutions.com>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Tuesday, January 01, 2002 9:27 PM
Subject: Re: XSL Tasks
> ----- Original Message -----
> From: "Bob Lee" <cr...@crazybob.org>
>
>
> > Specifically, I'm just working on some interface extensions.
> >
> > The current interface is geared towards transforming a directory of XML
> > content.
> >
> > I'm making ant targets for my currrent project that use XSL stylesheets
to
> > generate code and descriptors for entity beans off of a single XML file.
>
> So you're process runs a single XML file through several XSL
> transformations?
Exactly.
> You could, alternatively, use <apply> to accomplish this already probably.
> It certainly isn't the ideal solution, but thought I'd mention it.
>
> > Combining this functionality into the build script rather than having a
> > separate program or script has proven to be clean, convenient, and
> > intuitive, and the XSLTProcess task is an integral component, however
the
> > current interface isn't exactly condusive to this type of application.
>
> There certainly is room for more XML/XSL type functionality, either as
> separate tasks or integrated into <style> if suitable.
>
> > Off the subject, do you think XSLTransform would be more accurate and
> > intuitive label for this task?
>
> +0 - doesn't matter to me... its mapped to <style> and thats how I see it
> mostly. But certainly naming conventions of our tasks needs to be
intuitive
> and clear. (I think all our tasks should be named *Task.java, at least -
> and named close to what its default XML element name is).
>
> By the way, have you given any thought to using Torque/Velocity for your
> code generation process? Its already got an XML driven engine, Ant tasks,
> and customizable Velocity templates to generate code - and should be
easily
> tweakable to generate EJB (*ick*) code.
>
Yeah, I try and steer clear of them, too. I'll look into Velocity, though my
application is painfully simple. Thank you for all of the great help.
> Erik
Bob
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XSL Tasks
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
----- Original Message -----
From: "Bob Lee" <cr...@crazybob.org>
> Specifically, I'm just working on some interface extensions.
>
> The current interface is geared towards transforming a directory of XML
> content.
>
> I'm making ant targets for my currrent project that use XSL stylesheets to
> generate code and descriptors for entity beans off of a single XML file.
So you're process runs a single XML file through several XSL
transformations?
You could, alternatively, use <apply> to accomplish this already probably.
It certainly isn't the ideal solution, but thought I'd mention it.
> Combining this functionality into the build script rather than having a
> separate program or script has proven to be clean, convenient, and
> intuitive, and the XSLTProcess task is an integral component, however the
> current interface isn't exactly condusive to this type of application.
There certainly is room for more XML/XSL type functionality, either as
separate tasks or integrated into <style> if suitable.
> Off the subject, do you think XSLTransform would be more accurate and
> intuitive label for this task?
+0 - doesn't matter to me... its mapped to <style> and thats how I see it
mostly. But certainly naming conventions of our tasks needs to be intuitive
and clear. (I think all our tasks should be named *Task.java, at least -
and named close to what its default XML element name is).
By the way, have you given any thought to using Torque/Velocity for your
code generation process? Its already got an XML driven engine, Ant tasks,
and customizable Velocity templates to generate code - and should be easily
tweakable to generate EJB (*ick*) code.
Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XSL Tasks
Posted by Bob Lee <cr...@crazybob.org>.
Specifically, I'm just working on some interface extensions.
The current interface is geared towards transforming a directory of XML
content.
I'm making ant targets for my currrent project that use XSL stylesheets to
generate code and descriptors for entity beans off of a single XML file.
Combining this functionality into the build script rather than having a
separate program or script has proven to be clean, convenient, and
intuitive, and the XSLTProcess task is an integral component, however the
current interface isn't exactly condusive to this type of application.
Off the subject, do you think XSLTransform would be more accurate and
intuitive label for this task?
Thanks,
Bob
----- Original Message -----
From: "Erik Hatcher" <ja...@ehatchersolutions.com>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Tuesday, January 01, 2002 8:03 PM
Subject: Re: XSL Tasks
> XSLTProcess has had several changes since Ant 1.4.1 (the details are
pasted
> below).
>
> What specifically are you looking for?
>
> When has ant-dev not been open to extensions/patches/contributions? :))
>
> Erik
>
> ----------------------------
>
> Revision : 1.30
> Date : 2001/12/7 16:10:17
> Author : 'bodewig'
> State : 'Exp'
> Lines : +8 -1
> Description :
> register style task as error listener to the Trax transformer and
> factory so messages will get back to Ant's logging system.
> Submitted by: David Leuschner <le...@gmx.net>
> ----------------------------
> Revision : 1.29
> Date : 2001/11/26 18:10:45
> Author : 'rubys'
> State : 'Exp'
> Lines : +12 0
> Description :
> Add support to for XSLT output types.This maps to TraX's:
> transformer.setOutputProperty(OutputKeys.METHOD, type);
> Background/rationalle: I'm looking into spliting Gumps gen.bat and gen.sh
> scripts into a minimal bootstrap and a normal Ant "build.xml".In order
> to achieve this, I need access to the functionallity that Xalan supports
> from the command line via the -text parameter.
> I've provided an implementation to seed the discussion on how this should
> be supported.I am by no means wedded to this approach - if others see a
> better way, either let me know or directly make the change.
> ----------------------------
> Revision : 1.28
> Date : 2001/11/26 3:9:1
> Author : 'rubys'
> State : 'Exp'
> Lines : +1 -1
> Description :
> Seems silly to produce the same log message for every file, particularly
> as this message was already issued previously...
> ----------------------------
> Revision : 1.27
> Date : 2001/10/29 11:16:49
> Author : 'bodewig'
> State : 'Exp'
> Lines : +15 -5
> Description :
> Make <style> support Exolab's new Adaptx processor.
> Submitted by: Arnaud Blandin <bl...@intalio.com>
> ----------------------------
> Revision : 1.26
> Date : 2001/10/28 21:26:29
> Author : 'sbailliez'
> State : 'Exp'
> Lines : +7 -4
> Description :
> Code clean up:
> - removed useless/duplicate imports
> - added explicit imports rather than *
> - changed specifiers order to be conform to JLS.
>
> ----- Original Message -----
> From: "Bob Lee" <cr...@crazybob.org>
> To: "Ant Developers List" <an...@jakarta.apache.org>
> Sent: Tuesday, January 01, 2002 8:41 PM
> Subject: XSL Tasks
>
>
> > Can someone give me a run down of the status of the XSL tasks?
> >
> > I looked at the nightly builds, and the XSLTProcess task doesn't appear
to
> > have changed since the last release. I also have not been able to find
any
> > documentation on it outside of the javadoc.
> >
> > Are extensions to this component welcome?
> >
> > Thanks,
> > Bob
> >
> >
> > --
> > 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>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XSL Tasks
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
XSLTProcess has had several changes since Ant 1.4.1 (the details are pasted
below).
What specifically are you looking for?
When has ant-dev not been open to extensions/patches/contributions? :))
Erik
----------------------------
Revision : 1.30
Date : 2001/12/7 16:10:17
Author : 'bodewig'
State : 'Exp'
Lines : +8 -1
Description :
register style task as error listener to the Trax transformer and
factory so messages will get back to Ant's logging system.
Submitted by: David Leuschner <le...@gmx.net>
----------------------------
Revision : 1.29
Date : 2001/11/26 18:10:45
Author : 'rubys'
State : 'Exp'
Lines : +12 0
Description :
Add support to for XSLT output types.This maps to TraX's:
transformer.setOutputProperty(OutputKeys.METHOD, type);
Background/rationalle: I'm looking into spliting Gumps gen.bat and gen.sh
scripts into a minimal bootstrap and a normal Ant "build.xml".In order
to achieve this, I need access to the functionallity that Xalan supports
from the command line via the -text parameter.
I've provided an implementation to seed the discussion on how this should
be supported.I am by no means wedded to this approach - if others see a
better way, either let me know or directly make the change.
----------------------------
Revision : 1.28
Date : 2001/11/26 3:9:1
Author : 'rubys'
State : 'Exp'
Lines : +1 -1
Description :
Seems silly to produce the same log message for every file, particularly
as this message was already issued previously...
----------------------------
Revision : 1.27
Date : 2001/10/29 11:16:49
Author : 'bodewig'
State : 'Exp'
Lines : +15 -5
Description :
Make <style> support Exolab's new Adaptx processor.
Submitted by: Arnaud Blandin <bl...@intalio.com>
----------------------------
Revision : 1.26
Date : 2001/10/28 21:26:29
Author : 'sbailliez'
State : 'Exp'
Lines : +7 -4
Description :
Code clean up:
- removed useless/duplicate imports
- added explicit imports rather than *
- changed specifiers order to be conform to JLS.
----- Original Message -----
From: "Bob Lee" <cr...@crazybob.org>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Tuesday, January 01, 2002 8:41 PM
Subject: XSL Tasks
> Can someone give me a run down of the status of the XSL tasks?
>
> I looked at the nightly builds, and the XSLTProcess task doesn't appear to
> have changed since the last release. I also have not been able to find any
> documentation on it outside of the javadoc.
>
> Are extensions to this component welcome?
>
> Thanks,
> Bob
>
>
> --
> 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>
XSL Tasks
Posted by Bob Lee <cr...@crazybob.org>.
Can someone give me a run down of the status of the XSL tasks?
I looked at the nightly builds, and the XSLTProcess task doesn't appear to
have changed since the last release. I also have not been able to find any
documentation on it outside of the javadoc.
Are extensions to this component welcome?
Thanks,
Bob
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] myrmidon task configurer
Posted by Adam Murdoch <ad...@yahoo.com>.
> From: Peter Donald [mailto:peter@apache.org]
>
> > Logging would be the main one - say I want to do logging in some deeply
> > nested obect, I need to have something pass me a Logger. Ideally, my
> > object would simply implement LogEnabled, and the container would supply
> > the object with a Logger as part of its "initialisation". The
> alternative
> > would be for the object's parent to supply the logger - this
> would be bad,
> > as it would force the parent to be LogEnabled.
> ...
> > It's possible that a data type might need other components, or the task
> > context, to do its work. Again, having the container supply
> these would be
> > a good thing.
>
> I would like to move away from having sub-elements being
> "intelligent" and
> move towards them just being passive data containers. When you
> need to get
> generate complex information from these items (like processing a
> patternset
> to get a list of files) you pass these passive data items to a
> active service
> (ie FileScanner or something) that would do all the magic for you.
>
I'm not so sure about this one. It's a good pattern, but its necessarily a good restriction to force on all sub-elements.
We already deal with sub-elements that break this model - for example, anywhere where a task can be a sub-element (in <project>, <target>, <parallel>, <try><catch><finally>, whatever). If we can generalise the solution a touch, then we can deal with arbitrary sub-elements that are "active". It's a trade off - if we can generalise cleanly, then Ant becomes far more adaptable for it. If we can't come up with a good generalisation, its not a big deal - right now, we don't have any active sub-elements that aren't tasks (though, I think this is more due to Ant 1 limitations, rather than the concept not being useful). I feel that it is something to at least try.
Here's why I feel splitting passive data container and active evaluator is a good pattern, but not a good rule:
* It becomes awkward when there is a reasonable degree of polymorphism. In general, you've either got to have an evaluator which understands every possible data container (bad, you've lost the main strength of poymorphism), or a data type implementation has to provide both a container and an evaluator (bad, extra work for task writers). In many cases, it's simpler just to provide a data type implementation that encapsulates both config and behaviour.
However, there are other cases where the separation is powerful, where alternative evaluators can be swapped in, and the data container reused.
* Sometimes the "data type" actually represents a service. For example, a compiler or a VFS. The data container/evaluator split stops being useful.
* It forces the task writer to do the evaluation - that is, finding an appropriate evaluator, and doing the evaluation. Ok, not a lot of code in each instance, but it does add up. Often the task is only interested in the result of the evaluation, and does not care where the result comes from. In these cases, having the container supply the result to the task saves work for the task writer. And gives the container much more flexibility in how to go about doing the evaluation.
On a completely different topic, I'm wondering whether introspection might be a better way to deliver services to a task, rather than using Composable and Contexualizable. By "services" I mean both core runtime services and task-specific services:
- Loggers.
- Task executor.
- An execution manager (for external commands).
- file system manager (resolving file names, creating file systems, etc).
- Compiler adaptors.
- etc.
It's nicely declarative, and could take advantage of things like the TaskInfo work, and the configuration stuff above. It would also be an easy win for allowing user and/or build file control over these things.
It might work something like this: For each service required by a task, a service instance can be specified in the build file, either inline or by reference. If an instance is not specified, a default instance is provided by the container. The container decides on which instance to use:
- The user may provide an instance in their preferences.
- A tasklib may provide a default instance for services it introduces.
- The container may provide default instances for core things like loggers, etc.
- There may be no default at all.
An example:
public class Javac extends AbstractTask {
public void setCompiler(JavaCompiler compiler) { ... }
}
would allow build files like:
<javac>
<compiler type="jikes" pedantic="true" failOnWarning="true"/>
</javac>
Or, by reference:
<project>
<jikes id="java-compiler" pedantic="true" failOnWarning="true"/>
<target name="compile">
<javac compiler-ref="java-compiler"/>
</target>
<target name="another-compile">
<javac compiler-ref="java-compiler"/>
</target>
</project>
Or, say, the following in my ~/.antrc:
<antrc>
<jikes pedantic="false" emacsOutput="true"/>
</antrc>
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] myrmidon task configurer
Posted by Peter Donald <pe...@apache.org>.
On Mon, 31 Dec 2001 01:19, Adam Murdoch wrote:
> > It should be possible for a task or any object to only have it's
> > subelements
> > Configurable and where that is not the case there will be a base utility
> > class (see AbstractTaskContainer) to help do the configuring.
> > This utility
> > class will allow the task to call back into the configurer to do the
> > configuring. AbstractTaskContainer is not real easy atm but it
> > sort of shows
> > what I was aiming at.
> >
> > WOuld this be enough for you ?
>
> Not quite. You certainly *could* do this with Configurable - the issue is
> that it's an all or nothing approach. If an object (task or data type)
> implements Configurable, then it has to take care of configuring itself,
> and all its nested objects. It also needs to take care of resolving
> properties and doing type conversions (and presumably the new stuff like
> reference handling and polymorphism).
At the moment it may - however in the future when I finally get around to
reworkin AbstractTaskContainer there will hopefully be much simpler
mechanisms in place that will hide a lot of this complexity.
Im not sure how to make this easier and still keep the system relatively
simple.
> Granted, using AbstractTaskContainer
> makes it easier to do this if the object in question happens to be a task.
> Not much good for a nested type, however.
True but how often do you need a nested type to behave in such a way? Off the
top of my head I can't think of any examples of nested types that aren't
tasks. So lets say we had something like
<if test="foo">
<blah/>
<blee/>
</if>
Then both <blah/> and <blee/> would be tasks and configured by the container.
The IfTask would simple configure itself and then pass <blah/> and <blee/>
back into the container to be ran as tasks.
Can you give a sample task where the nested type is not a task?
> E.g:
>
> public class SomeDataType extends AbstractDataType
> {
> /** @deprecated Needed for backwards compatibility - use {@link
> #setSomeAttr(File)} instead. */ public void setSomeAttr(String value) { ...
> }
>
> public void setSomeAttr(File value) { ... }
>
> /** Returns the configurer to use for this class. */
> public static ObjectConfigurer getConfigurer()
> {
> DefaultObjectConfigurer configurer = new
> DefaultConfigurer(SomeDataType.class);
>
> // Force the introspector to use the File setter method for
> "some-attr" configurer.enableAttribute("some-attr", File.class);
>
> return configurer;
> }
> }
Okay - in Ant2 the "contract" occurs at the XML representation/task model
level. So in this case there would be no need to have a deprecated version
because we could simply delete the old string-based version.
> > > * Deal with references.
> > >
> > > Have the configurer resolve (and type check) references to data types,
> > > rather than forcing the object do it. An adder method would be
> >
> > passed an
> >
> > > object, and whether that object was obtained by reference, or
> >
> > created and
> >
> > > configured inline, the parent object doesn't know or care.
> >
> > +10000
> >
> > The two ways I proposed for doing this were basically recognizing
> > some magic
> > constructs.
> >
> > One construct would be that any element/attribute name that ended
> > with "-ref"
> > would have the "-ref" part removed and the normal attribute/element
> > configuration process would proceed except that it would use the
> > reference.
> >
> > The other constrct is just recognizing the case where an element has one
> > attribute named refid and treat it specially.
> >
> > I favour the first method as it deals with attributes and elements and is
> > generally easier IMHO but the second method is more standard to
> > our current
> > approach.
> >
> > What do you think?
>
> Not entirely clear on how elements are handled in the first method. Want
> to expand on it a bit?
Consider the following. All three <javac/> tasks would be identical.
<path id="foo">
<pathelement value="..."/>
</path>
<javac classpath-ref="foo"/>
<javac>
<classpath-ref id="foo"/>
</javac>
<javac>
<classpath/>
<pathelement value="..."/>
</classpath>
</javac>
Like that?
> Logging would be the main one - say I want to do logging in some deeply
> nested obect, I need to have something pass me a Logger. Ideally, my
> object would simply implement LogEnabled, and the container would supply
> the object with a Logger as part of its "initialisation". The alternative
> would be for the object's parent to supply the logger - this would be bad,
> as it would force the parent to be LogEnabled.
...
> It's possible that a data type might need other components, or the task
> context, to do its work. Again, having the container supply these would be
> a good thing.
I would like to move away from having sub-elements being "intelligent" and
move towards them just being passive data containers. When you need to get
generate complex information from these items (like processing a patternset
to get a list of files) you pass these passive data items to a active service
(ie FileScanner or something) that would do all the magic for you.
--
Cheers,
Pete
*---------------------------------------------------------*
| Programming today is a race between software engineers |
| striving to build bigger and better idiot-proof |
| programs,and the universe trying to produce bigger and |
| better idiots. So far, the universe is winning. |
| - Richard Cook |
*---------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] myrmidon task configurer
Posted by Adam Murdoch <ad...@yahoo.com>.
> From: Peter Donald [mailto:peter@apache.org]
>
> > * Allow an object (task or data type) to override parts of its
> > configuration process.
> >
> > This would be an alternative to implementing Configurable
> (which requires
> > the object to deal with configuring itself entirely).
>
> It should be possible for a task or any object to only have it's
> subelements
> Configurable and where that is not the case there will be a base utility
> class (see AbstractTaskContainer) to help do the configuring.
> This utility
> class will allow the task to call back into the configurer to do the
> configuring. AbstractTaskContainer is not real easy atm but it
> sort of shows
> what I was aiming at.
>
> WOuld this be enough for you ?
>
Not quite. You certainly *could* do this with Configurable - the issue is that it's an all or nothing approach. If an object (task or data type) implements Configurable, then it has to take care of configuring itself, and all its nested objects. It also needs to take care of resolving properties and doing type conversions (and presumably the new stuff like reference handling and polymorphism). Granted, using AbstractTaskContainer makes it easier to do this if the object in question happens to be a task. Not much good for a nested type, however.
What I'd like to do is provide a mechanism where a class can modify its introspector, without needing to implement Configurable (and hence Composable and Contexualizable).
E.g:
public class SomeDataType extends AbstractDataType
{
/** @deprecated Needed for backwards compatibility - use {@link #setSomeAttr(File)} instead. */
public void setSomeAttr(String value) { ... }
public void setSomeAttr(File value) { ... }
/** Returns the configurer to use for this class. */
public static ObjectConfigurer getConfigurer()
{
DefaultObjectConfigurer configurer = new DefaultConfigurer(SomeDataType.class);
// Force the introspector to use the File setter method for "some-attr"
configurer.enableAttribute("some-attr", File.class);
return configurer;
}
}
> > The plan is to allow a class to provide a customised introspector (an
> > ObjectConfigurer) via a static method - getConfigurer(), say.
> This would
> > allow a class to do simple things like:
> >
> > - Explicitly choose an overloaded setter/adder/creator method
> to use when
> > there's more than one.
> > - Ignore certain setter/adder/creator methods.
> > - Map text content to a particular attribute (e.g. "message"
> in the <log>
> > task).
>
> I think all of the above should be done via some sort of TaskInfo object.
>
Absolutely.
TaskInfo seemed a bit too far off, and the introspector was somewhere to deal with this kind of stuff in the meantime. Thinking about it some more, maybe starting on TaskInfo might be a better thing to do.
> > - Deal with attributes or elements whose names are only known
> at runtime
> > (e.g. compiler adaptors).
>
> This is something that still needs to be figured out. Hopefully the above
> utility class would be enough to make this easy.
>
Moving towards a polymorphic, type-based set-up will reduce the need for this kind of stuff. Maybe at that point we could simply say that there's no such thing as an "unknown" attribute or element.
> > * Deal with references.
> >
> > Have the configurer resolve (and type check) references to data types,
> > rather than forcing the object do it. An adder method would be
> passed an
> > object, and whether that object was obtained by reference, or
> created and
> > configured inline, the parent object doesn't know or care.
>
> +10000
>
> The two ways I proposed for doing this were basically recognizing
> some magic
> constructs.
>
> One construct would be that any element/attribute name that ended
> with "-ref"
> would have the "-ref" part removed and the normal attribute/element
> configuration process would proceed except that it would use the
> reference.
>
> The other constrct is just recognizing the case where an element has one
> attribute named refid and treat it specially.
>
> I favour the first method as it deals with attributes and elements and is
> generally easier IMHO but the second method is more standard to
> our current
> approach.
>
> What do you think?
>
Not entirely clear on how elements are handled in the first method. Want to expand on it a bit?
> > This raises the issue of ownership, and immutability - maybe a
> clone gets
> > passed to the adder methods.
>
> Hmmm .. haven't really though much about this but to fit in with
> the rest of
> the model you probably should not be passing a clone...
>
Depends what the model says about whether shared objects can be changed by the objects that use them. A good model would say that they can't be, an evil model would say that they can be.
Cloning was just a thought of how we might enforce that - give each object its own private copy, and isolate them from side effects. Alternatively, we could just say "well, don't change shared stuff, please", or we could stick to immutable data types, or we could not bother.
> > * Polymorphic types.
> >
> > This was raised a few months ago and it is truely an excellent
> idea. This
> > would allow the configurer to pass an adder method, an object
> of any class
> > that is assignable to the declared type. As Peter pointed out,
> this would
> > neatly solve the adaptor problem that is being discussed.
>
> +1
>
I'm wondering how we would represent this in the build file?
Some options:
<javac>
<compiler type="jikes" .. config .. />
</javac>
<javac>
<compiler>
<jikes .. config .. />
<compiler/>
</javac>
<javac>
<jikes .. config .. />
</javac>
The 3rd option won't work if there's more than one element that can take a "jikes" data type. Maybe we use the 1st option, and allow the 3rd one if its unambiguous.
> > * Lifecycle management.
> >
> > It would be handy if the lifecycle of nested objects was handled by the
> > container, rather than forcing the parent object to do it. Not the
> > configurer's job, necessarily.
>
> Can you give a use case for this?
>
Logging would be the main one - say I want to do logging in some deeply nested obect, I need to have something pass me a Logger. Ideally, my object would simply implement LogEnabled, and the container would supply the object with a Logger as part of its "initialisation". The alternative would be for the object's parent to supply the logger - this would be bad, as it would force the parent to be LogEnabled.
Note: "container" == Ant, "object's parent" == every data type or task that recursively includes the nested object, written by a bunch of different task developers.
It's possible that a data type might need other components, or the task context, to do its work. Again, having the container supply these would be a good thing.
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] myrmidon task configurer
Posted by Peter Donald <pe...@apache.org>.
On Sun, 30 Dec 2001 14:32, Adam Murdoch wrote:
> Hi,
>
> This is a patch to myrmidon's task configurer, to cache reflection info.
> The goal was to start playing with some new configuration features, but
> unfortunately I didn't find time to do much with it. I'd like to put this
> on hold temporarily, so I'm submitting the changes as they currently stand.
> Configuration should be heaps faster now.
excellent - will commit the changes next time I reboot - prolly sometime
tomorrow or maybe wendsday given it is new years eve tomorrow ;)
> Here's what I'd like to try sometime soon-ish:
>
> * Allow an object (task or data type) to override parts of its
> configuration process.
>
> This would be an alternative to implementing Configurable (which requires
> the object to deal with configuring itself entirely).
It should be possible for a task or any object to only have it's subelements
Configurable and where that is not the case there will be a base utility
class (see AbstractTaskContainer) to help do the configuring. This utility
class will allow the task to call back into the configurer to do the
configuring. AbstractTaskContainer is not real easy atm but it sort of shows
what I was aiming at.
WOuld this be enough for you ?
> The plan is to allow a class to provide a customised introspector (an
> ObjectConfigurer) via a static method - getConfigurer(), say. This would
> allow a class to do simple things like:
>
> - Explicitly choose an overloaded setter/adder/creator method to use when
> there's more than one.
> - Ignore certain setter/adder/creator methods.
> - Map text content to a particular attribute (e.g. "message" in the <log>
> task).
I think all of the above should be done via some sort of TaskInfo object.
> - Deal with attributes or elements whose names are only known at runtime
> (e.g. compiler adaptors).
This is something that still needs to be figured out. Hopefully the above
utility class would be enough to make this easy.
> * Deal with references.
>
> Have the configurer resolve (and type check) references to data types,
> rather than forcing the object do it. An adder method would be passed an
> object, and whether that object was obtained by reference, or created and
> configured inline, the parent object doesn't know or care.
+10000
The two ways I proposed for doing this were basically recognizing some magic
constructs.
One construct would be that any element/attribute name that ended with "-ref"
would have the "-ref" part removed and the normal attribute/element
configuration process would proceed except that it would use the reference.
The other constrct is just recognizing the case where an element has one
attribute named refid and treat it specially.
I favour the first method as it deals with attributes and elements and is
generally easier IMHO but the second method is more standard to our current
approach.
What do you think?
> This raises the issue of ownership, and immutability - maybe a clone gets
> passed to the adder methods.
Hmmm .. haven't really though much about this but to fit in with the rest of
the model you probably should not be passing a clone...
> * Polymorphic types.
>
> This was raised a few months ago and it is truely an excellent idea. This
> would allow the configurer to pass an adder method, an object of any class
> that is assignable to the declared type. As Peter pointed out, this would
> neatly solve the adaptor problem that is being discussed.
+1
> * Lifecycle management.
>
> It would be handy if the lifecycle of nested objects was handled by the
> container, rather than forcing the parent object to do it. Not the
> configurer's job, necessarily.
Can you give a use case for this?
> * Put some tests together, and maybe some docs as well (yeah sure).
;)
--
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>