Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-07-08 16:56:15
|
With Ant, everything succeeds on my machine... Can't really tell when = running in IDEA, because the attributes tests always fail there. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Rod Johnson Sent: Thursday, July 08, 2004 6:30 PM To: spr...@li... Subject: [Springframework-developer] Test failures I'm getting over 30 failures when running tests in Eclipse. Some are 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 -=20 digital self defense, top technical experts, no vendor pitches,=20 unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-07-08 21:32:33
|
I completely agree: It's best to just move over the code that's actually = needed for the time being. All that stuff needs proper review before = getting included in the main codebase. Of course, this is not about = doubts regarding Keith's code quality: He definitely does a good job = there! It's just about growing the codebase in a controlled fashion :-) =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von 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 classes from sandbox. The code in question looks pretty high-quality (looks like a variation of some utils from commons-lang, along with some new code of 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\classes >> [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.AbstractJmsTemplate >> [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 = are >>>> 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 |
|
From: Dmitriy K. <dko...@ru...> - 2004-07-08 21:37:45
|
Agreed on the code review point - proper peer review is important part of any successful software project Regards, Dmitriy. jürgen höller [werk3AT] wrote: >I completely agree: It's best to just move over the code that's actually needed for the time being. All that stuff needs proper review before getting included in the main codebase. Of course, this is not about doubts regarding Keith's code quality: He definitely does a good job there! It's just about growing the codebase in a controlled fashion :-) > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag von 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 classes >from sandbox. The code in question looks pretty high-quality (looks like >a variation of some utils from commons-lang, along with some new code of >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\classes >>> [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.AbstractJmsTemplate >>> [javac] String shortName = 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 are >>>>>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 > > |
|
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 |
