Costin Manolache wrote:
Nicola Ken Barozzi wrote:
We also need agreement and more feedback on the APIs - the PropertyHelper is probably the one that needs most attention.
Works for me here. We are already using a specialized property interceptor, and it seems to work fine... except when properties are passed down in <ant>. Intercepted ones aren't.
That's one issue - I don't know if <ant> should pass the helpers or not.
Yeah, I'm not sure too. Probably a inheritHelpers="true" could make all happy, but I don't know if it's really what we want.
My impression is that since properties and propertyhelpers are the same meat to use for users, they should be treated similarly.
In practice, when the <ant> that was called failed because the "property was not set", it really puzzeled. I think that probably taking the least-surprise route, ie to pass them, is the most sensible solution.
<antcall> needs a bit of improvments - there is no need to parse the file again, that would speed it up a lot. I mentioned that it is now possible to avoid copy of the properties ( using a "frame" mechanism ).
Errr, I missed that ;-)
My point is that the APIs need to be reviewed and we should find the
simplest and most intuitive form. This is something we'll have to live
with for a while, and we must do all the changes before the final release.
Yup.
The classes I'm currently using are built by Gump, so it will be quite easy to make sure that I can easily follow the API changes.
Should we add a similar mechanism to IntrospectionHelper and do a similar change for references ( ReferenceHelper ? ) ? Project would remain with target management and just delegate all other functionality.
Dunno about IntrospectionHelper (could you please explain a use case?), but I've already found a need for references.
IntrospectionHelper - there are already plently of libraries for doing introspection, some using advanced features we can't include because of dependencies ( JDK1.3, other libs ). There is also JMX who defines a special mechanism for setting attributes ( if someone would want to transparently support JMX components as tasks - in commons-modeler for example :-).
Hmmm, seems like FlexibilitySyndrome, where anything can be a Task... but on the other hand it's really quite cool, 'cause anything can become a task without implementing Task... cool, very nice. It could be used for example to use JSP taglibs as tasks, no?
I think I don't need it now, but it sounds like I'm gonna need it as soon as I see some examples ;-)
Regarding reference helper - it is quite easy to do, if anyone volunteers.
Right now I have enough fun with the other changes ( and modeler and tomcat ) :-)
Yeah, saw that... ok, consider me on the job :-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
