Re: XSP block status
Unico Hommes wrote: 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
Re: XSP block status
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. -- Unico
Re: XSP block status
On Mar 11, 2004, at 8:35 PM, Reinhard Pötz wrote: leo leonid wrote: On Mar 11, 2004, at 6:50 PM, Reinhard Pötz wrote: leo leonid wrote: Hi, I just updated my projects from woody to cocoon forms (absolutely painless, BTW). How did you do the upgrade? I used your ant task ($COCOON_HOME/build.sh woody2CocoonForms-renaming). It did the job quite perfectly. Only improvement tips from my side: - make it accepting paths to project directory without trailing slashes as well Should work ... what did you try? Hmmm... you're right! Can't reproduce it, probably I got the "... directory doesn't exist" error due to an empty space following the paths. - make it covering the change forms.datatype.ValidationError to forms.validation.ValidationError, too. Thanks, added in CVS. Cool! /leo -- Reinhard
Re: XSP block status
leo leonid wrote: On Mar 11, 2004, at 6:50 PM, Reinhard Pötz wrote: leo leonid wrote: Hi, I just updated my projects from woody to cocoon forms (absolutely painless, BTW). How did you do the upgrade? I used your ant task ($COCOON_HOME/build.sh woody2CocoonForms-renaming). It did the job quite perfectly. Only improvement tips from my side: - make it accepting paths to project directory without trailing slashes as well Should work ... what did you try? - make it covering the change forms.datatype.ValidationError to forms.validation.ValidationError, too. Thanks, added in CVS. -- Reinhard
Re: XSP block status
On Mar 11, 2004, at 6:50 PM, Reinhard Pötz wrote: leo leonid wrote: Hi, I just updated my projects from woody to cocoon forms (absolutely painless, BTW). How did you do the upgrade? I used your ant task ($COCOON_HOME/build.sh woody2CocoonForms-renaming). It did the job quite perfectly. Only improvement tips from my side: - make it accepting paths to project directory without trailing slashes as well - make it covering the change forms.datatype.ValidationError to forms.validation.ValidationError, too. to answer my original question: > Was it just a bad moment for CVS-update > or does the move of XSP to its own block affect existing projects? in deed, it was a bad moment for CVS-update. I did a clean build and everything looks fine so far :) /leo -- Reinhard
Re: XSP block status
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. > - 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. > - 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. Stephan.
Re: XSP block status
Am Do, den 11.03.2004 schrieb leo leonid um 18:24: > Hi, > > I just updated my projects from woody to cocoon forms (absolutely > painless, BTW). I see it similar, a simple s/woody/forms/g, and most of the work is done. I doesn't see a real need to keep the woody block, but anyway... > Unfortunately now most of my projects are broken > anyhow, because they use XSP (ESQL), and I was not aware of the XSP > refactoring going on :( > > Was it just a bad moment for CVS-update or does the move of XSP to its > own block affect existing projects? Where do I have to pay attention? > thanks. Bad moment ;-) It shouldn't affect existing projects. When not, share your pain. Stephan.
Re: XSP block status
leo leonid wrote: Hi, I just updated my projects from woody to cocoon forms (absolutely painless, BTW). How did you do the upgrade? -- Reinhard
Re: XSP block status
Hi, I just updated my projects from woody to cocoon forms (absolutely painless, BTW). Unfortunately now most of my projects are broken anyhow, because they use XSP (ESQL), and I was not aware of the XSP refactoring going on :( Was it just a bad moment for CVS-update or does the move of XSP to its own block affect existing projects? Where do I have to pay attention? thanks. /leo On Mar 10, 2004, at 7:24 PM, Unico Hommes wrote: 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? - I18n samples. Needs volunteer. - simpleform samples. Needs volunteer. - session-fw patches are executed before xsp patches but depend on them. Move xsp specific stuff from session-fw to xsp. - some blocks have dependencies on xsp. These need to be declared. Stephan, does that about cover it? -- Unico
