Re: [Springframework-developer] New Spring module

[Colin S. <col...@ex...>]

In fact, it's not a normal empty line after each original line. When I 
check out the new repo, what I get (on my Windows system) is a
   <CR> <CR> <LF>
at the end of each line, instead of the normal
  <CR> <LF>
that should be there.

Now what happens is that CVS on linux/unix stores end of lines as just 
<LF>, and then when you check out they get converted as needed for your 
platform.

When I have seen this sort of thing happen before (and maybe what Rod 
did), was when a file was checked out to a windows system, so that every 
line has the CRLF at the end, but then mailed or transported to a Unix 
system, and then checked in there as is. In this case, the unix client 
doesn't know that it has to strip the CR at the end of each line on 
checking, and the checkin ends up with CRLF in the reop itself. Then 
when you do a subsequent checkout on the windows system, the client on 
the system thinks (correctly) that it has to add a CR before every 
incoming LF, and you end up with CRCRLF at the end of every line.

(Note btw, that it's not the actual CVS client that does the end of line 
handling, it's really the stdio routines in the C library, which handle 
this appropriately for the platform).

In any case, this is sort of a mess :-)


jürgen höller [werk3AT] wrote:

>Hmmm, *all* source files have unnecessary empty lines after each original line. This looks awful and doubles the size. The only exception are the tag classes that Jean-Pierre checked in... Is this some fancy new Eclipse feature on Rod's installation, or even on purpose? ;-)
> 
>Unfortunately, not even a code reformatting helps (at least not with IDEA). So I guess we will probably have to re-checkin the *entire* source tree (except the tag classes, to be accurate ;-). Rod, Thomas, Jean-Pierre - can you try to deal with this, as I'm away till Saturday morning?
> 
>BTW, ResourceBundleViewResolverTestSuite seems broken because it can't read the testviews.properties property: Static attribute definitions are not recognized fully because there are empty lines inbetween them... We really need to re-checkin, as the properties are concerned too.
> 
>Juergen
> 
>
>	-----Ursprüngliche Nachricht----- 
>	Von: Rod Johnson [mailto:rod...@in...] 
>	Gesendet: Do 14.08.2003 09:57 
>	An: spr...@li... 
>	Cc: jürgen höller [werk3AT] 
>	Betreff: Re: [Springframework-developer] New Spring module
>	
>	
>
>	All,
>	
>	Thomas has now completed the job and put the code in the existing "Spring"
>	module. Please work on this by preference.
>	
>	The snapshot was taken at Aug 13 at 0800 GMT: any changes since to the main
>	module will need to be manually replicated.
>	
>	Notes:
>	
>	- I haven't included the samples. I thought it would be better for JP and
>	Ken to add these once they're modified. Changing the imports etc is easy
>	with something like this:
>	
>	  <replace dir="whatever"  token="com.interface21"
>	value="org.springframework">
>	    <exclude name="*.jar"/>
>	  </replace>
>	
>	- I haven't migrated /livetest. I really prefer the mock object approach for
>	database testing. I'd love to test Isabelle's code without needing a
>	database. Any volunteers??
>	
>	- I have put in a new /load tree, with the load testing code and some
>	performance tests for Spring.
>	
>	- The tests pass, and with debug logging we have 75% coverage!
>	
>	Btw we should be able to use mock tests to test for different db resource
>	closure failure scenarios.
>	
>	Regards,
>	Rod
>	
>	----- Original Message -----
>	From: <rod...@in...>
>	To: "jürgen höller [werk3AT] " <jue...@we...>
>	Cc: <spr...@li...>
>	Sent: Wednesday, August 13, 2003 5:14 PM
>	Subject: RE: [Springframework-developer] API simplification
>	
>	
>	> I've done the package rename and will commit it to a
>	> new "spring" module tonight.
>	>
>	> I'll post more details when I'm done.
>	>
>	> I've been considering some potential simplifications. I hate
>	> dead code--it adds bloat and makes frameworks harder to use.
>	> (I've just been working with TopLink...) As we progress to
>	> 1.0 it's a good opportunity to cut back to the
>	> essentials...it will be hard to remove anything (however
>	> useless) afterwards.
>	>
>	> As a start, I'm considering removing the JavaBean event
>	> support from BeanWrapper. I've not used it in any
>	> applications. Has anyone else used it?
>	>
>	> Now Spring has AOP support, it's possible to add listeners to
>	> property change events using interceptors, rather than this
>	> rather kludgy part of the JavaBeans API.
>	>
>	> Removing event support would get rid of about 150 lines of
>	> code in the beans package, and simplify the API for users.
>	>
>	> Any thoughts on this?
>	>
>	> Another candidate on my potential hitlist is the "pass-
>	> through" properties support for FactoryBeans. I've not seen a
>	> need to use this in practice (although I implemented it).
>	>
>	> Regards,
>	> Rod
>	>
>	>
>	> -------------------------------------------------------
>	> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>	> Data Reports, E-commerce, Portals, and Forums are available now.
>	> Download today and enter to win an XBOX or Visual Studio .NET.
>	>
>