Menu
▾
▴
Re: [Springframework-developer] Test failures
|
From: Keith D. <kd...@cs...> - 2004-07-08 22:24:43
|
I saw 'keith" and "code quality' in the same sentence and got worried for= a sec ... ;-) This actually raises an interesting question. I use some of the sandbox code, particularly the utility stuff like Assert, heavily in rich client. With moving to a new project repository, we'll still be dependent on the sandbox area. Probably not ideal, as it makes good sense to have users b= e able to run spring-rcp without having to checkout core spring (e.g we sho= uld include the latest spring.jar in the spring-rich-c project.) Hmm... what to do... I obviously see value in a good deal of those classe= s and use them, but there's little point in including them in the core unle= ss they'll be used to support and add value to the core (which given things work so well now, do we event want to go changing things to use them ... = and utility-type code in general I think can be a bit personal... i happen to= be an assertion monkey, for example... ) Should I just treat them as general rcp utilities for now, and just use t= hem over there? I think some, like Assert.java, though, are quite generally useful, so I admit I would prefer to see it in org.springframework.util, = not rcp.util (although we need to make it where it doesn't pull in 15 other classes; (must be that fancy ToStringBuilder stuff)...) However, some ar= e less generally useful, like Cache.java, and for those I could keep over i= n rcp. I completely agree we want to continue to be controlled about what goes into the core! I can take a look at some of these classes again and make a more specific recommendation on this - Keith ----- Original Message -----=20 From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...> To: <spr...@li...> Sent: Thursday, July 08, 2004 5:30 PM Subject: Re: [Springframework-developer] Test failures > I completely agree: It's best to just move over the code that's actuall= y needed for the time being. All that stuff needs proper review before gett= ing included in the main codebase. Of course, this is not about doubts regard= ing Keith's code quality: He definitely does a good job there! It's just abou= t growing the codebase in a controlled fashion :-) > > Juergen > > > ________________________________ > > Von: spr...@li... im Auftrag v= on Colin Sampaleanu > Gesendet: Do 08.07.2004 23:21 > An: spr...@li... > Betreff: Re: [Springframework-developer] Test failures > > > > I moved ClassUtils.java over (along with the related test). I did > comment out 3-4 cases of usage of the Assert class and one ArrayUtils > call in a log.debug call (the latter not really being needed anyways), > as those would have led to bringing in about an additional 12-15 classe= s > from sandbox. The code in question looks pretty high-quality (looks lik= e > a variation of some utils from commons-lang, along with some new code o= f > Keith's), but I did not want to bring it over without thinking about it > a bit more; if it's going to get used in other places that's fine, but > it's a lot to move over if it's just going to support those 3-4 Assert > calls... > > Colin > > > Colin Sampaleanu wrote: > > > This missing class (ClassUtils) is in the Sandbox. I will move it to > > the main tree. > > > > > > Colin Sampaleanu wrote: > > > >> I actually get build breakage right now due to the JMS changes, even > >> from ant: > >> > >> build: > >> [mkdir] Created dir: D:\src\open\spring-colin\spring\target\class= es > >> [mkdir] Created dir: > >> D:\src\open\spring-colin\spring\target\classes\META-INF > >> > >> [javac] Compiling 772 source files to > >> D:\src\open\spring-colin\spring\target > >> \classes > >> [javac] > >> D:\src\open\spring-colin\spring\src\org\springframework\jms\Abstract > >> JmsTemplate.java:63: cannot resolve symbol > >> [javac] symbol : class ClassUtils > >> [javac] location: package util > >> [javac] import org.springframework.util.ClassUtils; > >> [javac] ^ > >> [javac] > >> D:\src\open\spring-colin\spring\src\org\springframework\jms\Abstract > >> JmsTemplate.java:701: cannot resolve symbol > >> [javac] symbol : variable ClassUtils > >> [javac] location: class org.springframework.jms.AbstractJmsTempla= te > >> [javac] String shortName =3D ClassUtils.getShortName( > >> orig.getClass(). > >> getName() ); > >> [javac] ^ > >> [javac] Note: Some input files use or override a deprecated API. > >> [javac] Note: Recompile with -deprecation for details. > >> [javac] 2 errors > >> > >> > >> Mark, is it possible you forgot to check in something? > >> > >> Colin > >> > >> > >> Dmitriy Kopylenko wrote: > >> > >>> All tests pass on my machine in Eclipse. I have 3.0 final with jdk > >>> 1.4.2 installed. > >>> > >>> Dmitriy. > >>> > >>> Rod Johnson wrote: > >>> > >>>> I'm getting over 30 failures when running tests in Eclipse. Some a= re > >>>> JDO-related, and may be genuine failures. The others are JNDI > >>>> related and > >>>> look like some static side-effect is sitting around in the > >>>> NamingContextBuilder. (Eclipse keeps the same JVM up.) > >>>> > >>>> R > >>> > > > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
