Stephan Michels wrote:
Am Mi, den 10.03.2004 schrieb Unico Hommes um 19:24:
There remain a few issues that need resolving.
- InputModuleAction had to move along with xsp because it has a dependency on some xsp helper class. This is unfortunate and maybe unnecessary. Perhaps someone with more knowledge about this class could take a look and see if they can solve this?
- Source samples. Some use xsp's. Move these to xsp block or remove them altogether?
I'm in favour of removing them. But I can't decide that.
Me too. I don't think there remains an appropriate place to move them. What do others think?
- I18n samples. Needs volunteer.
- simpleform samples. Needs volunteer.
Only the first example use XSPs.
- session-fw patches are executed before xsp patches but depend on them. Move xsp specific stuff from session-fw to xsp.
I think this stuff, can stay where it is. The patch mechanism should
now work properly.
Nice one! Thanks.
- some blocks have dependencies on xsp. These need to be declared.
I think the rest comes the paradigm shift to flow+jx early or later.
I was thinking more in the way that some blocks won't work when xsp is not included. For instance eventcache comes to mind. I'll see what more dependencies I can find.
some block _samples_ won't work is of course what you mean.
What we really need is the concept of optional dependencies. Examples:
- during the eventcache build, the xsp samples should be copied over if it's optional xsp dependency is present.
- during the jms build, the xsp and database caching examples should be created if both those optional dependencies are present.
I have been wondering if ant 1.6 gives us some new options for these blocks builds which make this more possible. for example, I think the new import facility would allow us to import generic block build tasks into the block's own (usually non-present) build.xml, avoid generating the blocks build via xsl, and easily add arbitrarily complex sub-dependencies. Does that spark any ideas?
Geoff
