Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-07-19 09:27:59
|
Everybody, =20 Seems like we're finally ready for 1.1 RC1, already with full 1.1 scope: =20 - Mark has provided a refined version of the JMS support - Thomas has already added support for JDBC-generated keys - Darren has committed bind support for Velocity and FreeMarker - Seth has contributed some tag refinements for JSP views. =20 The remaining tasks that I see are: =20 - We need to adapt the source code formatting of the JMS support: I = still see nasty empty lines after each code line on Windows: maybe = Unix/Windows line feed differences? =20 - I'd like to review the source code of the final version of JMS = support. Just about polishing and javadoc, as always before a release = :-) =20 - Thomas is already working on using a single API approach for = JDBC-generated keys, including moving the classes to a different = package. =20 - I'd like to move BindStatus and the new BindStatusHelper class from = servlet.tags to servlet.support. JSPs using the BindTag should still = work, provided that they get freshly compiled. Any objections to this? =20 - I'd like to refine resource loading in VelocityFormView and = FreeMarkerFormView: This is not entirely clean when combined with custom = resource paths yet, from a superficial glance. =20 - We need to add Seth's NestedPathTag and include his BindTag = refinements. I'll do this myself during the course of the week. =20 All things considered, this means a release by the end of the week: Any = earlier date would require dropping one of those tasks, which I don't = think would be worth it. Thoughts? =20 Finally, regarding form simplification macros, i.e. Struts-style HTML = input tag wrappers: Do we already have something here, for either JSP = 2.0, Velocity or FreeMarker? =20 Juergen =20 |
|
From: Darren D. <da...@da...> - 2004-07-19 10:33:52
|
> - I'd like to move BindStatus and the new BindStatusHelper class from > servlet.tags to servlet.support. JSPs using the BindTag should still wo= rk, > provided that they get freshly compiled. Any objections to this? I meant to raise this when I generalised the behaviour of them but it slipped my mind. They should be moved to a non-tag specific package now. > - I'd like to refine resource loading in VelocityFormView and > FreeMarkerFormView: This is not entirely clean when combined with custo= m > resource paths yet, from a superficial glance. VelocityConfigurer (and respective FreeMarkerConfigurer) ensure a SpringResourceLoader is available for use, possibly in addition to any other resource loading strategy in the case of FreeMarker. Does this not cover requirements? I'm a little unclear on what's missing here.. > Finally, regarding form simplification macros, i.e. Struts-style HTML > input tag wrappers: Do we already have something here, for either JSP 2= .0, > Velocity or FreeMarker? not from my side - personal events have overtaken me a little recently.=20 I'd intended contacting Seth again to catch up on this and ensure a consistent approach for the three technologies. My feeling is that it should be fairly quick to add given the basic framework code is OK for resource loading, but I've not really looked closely at it yet. Regards, --=20 Darren Davison Public Key: http://www.davison.uk.net/pages/key.htm |
|
From: Mark P. <mar...@co...> - 2004-07-19 14:06:05
|
Hi, > - We need to adapt the source code formatting of the JMS > support: I still see nasty empty lines after each code line > on Windows: maybe Unix/Windows line feed differences? I'm not seeing this, if you show me how you are detecting this I can clean it up. I am comfortable with the end of the week timeframe for JMS. Cheers, Mark |
|
From: Darren D. <da...@da...> - 2004-07-19 14:46:05
|
> Hi, > >> - We need to adapt the source code formatting of the JMS >> support: I still see nasty empty lines after each code line >> on Windows: maybe Unix/Windows line feed differences? > > I'm not seeing this, if you show me how you are detecting this I can cl= ean > it up. The JMS files are using windows EOL markers (0A 0D) the other files use the Unix convention (0A). You can verify by opening the files with any binary viewer (TextPad on Windows will do it, any Hex viewer on Unix/Linu= x will show it too). I thought the CVS server should automatically convert to the Unix format..? I downloaded AbstractJmsTemplate.java and checked it with both TextPad on 'doze and the nano editor (pico clone) on Linux; they formatted OK on bot= h for me. Emacs would probably show the JMS source as having ^M at the end of each line. --=20 Darren Davison Public Key: http://www.davison.uk.net/pages/key.htm |
|
From: Colin S. <col...@ex...> - 2004-07-19 15:41:48
|
CVS will convert end of lines properly on checkin and checkout, appropriate to the platform being checked out on. However, it is unable to handle the case where somebody creates or modifies a file on Windows (which has CR/LF at the end of lines), then mails it (or whtever) to somebody who then checks it in from a unix system. It will then appear in CVS with the CR still there since that system will not strip out the CR. Then when you subsequently check it out on the windows system, CVS will add another CR, so you end up with CRCRLF. Colin Darren Davison wrote: >>Hi, >> >> >> >>>- We need to adapt the source code formatting of the JMS >>>support: I still see nasty empty lines after each code line >>>on Windows: maybe Unix/Windows line feed differences? >>> >>> >>I'm not seeing this, if you show me how you are detecting this I can clean >>it up. >> >> > >The JMS files are using windows EOL markers (0A 0D) the other files use >the Unix convention (0A). You can verify by opening the files with any >binary viewer (TextPad on Windows will do it, any Hex viewer on Unix/Linux >will show it too). I thought the CVS server should automatically convert >to the Unix format..? > >I downloaded AbstractJmsTemplate.java and checked it with both TextPad on >'doze and the nano editor (pico clone) on Linux; they formatted OK on both >for me. Emacs would probably show the JMS source as having ^M at the end >of each line. > > > > |
