Menu
▾
▴
springframework-developer — Spring Framework developers list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(55) |
Mar
(100) |
Apr
(203) |
May
(330) |
Jun
(190) |
Jul
(302) |
Aug
(323) |
Sep
(197) |
Oct
(245) |
Nov
(490) |
Dec
(330) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(194) |
Feb
(400) |
Mar
(416) |
Apr
(415) |
May
(359) |
Jun
(381) |
Jul
(491) |
Aug
(311) |
Sep
(291) |
Oct
(273) |
Nov
(355) |
Dec
(266) |
| 2005 |
Jan
(306) |
Feb
(303) |
Mar
(520) |
Apr
(346) |
May
(255) |
Jun
(221) |
Jul
(171) |
Aug
(247) |
Sep
(147) |
Oct
(125) |
Nov
(165) |
Dec
(65) |
| 2006 |
Jan
(90) |
Feb
(53) |
Mar
(121) |
Apr
(103) |
May
(113) |
Jun
(103) |
Jul
(104) |
Aug
(67) |
Sep
(78) |
Oct
(82) |
Nov
(78) |
Dec
(70) |
| 2007 |
Jan
(77) |
Feb
(76) |
Mar
(63) |
Apr
(30) |
May
(47) |
Jun
(41) |
Jul
(44) |
Aug
(44) |
Sep
(49) |
Oct
(33) |
Nov
(25) |
Dec
(21) |
| 2008 |
Jan
(45) |
Feb
(13) |
Mar
(15) |
Apr
(12) |
May
(9) |
Jun
(33) |
Jul
(30) |
Aug
(7) |
Sep
(20) |
Oct
(17) |
Nov
(20) |
Dec
(10) |
| 2009 |
Jan
(8) |
Feb
(5) |
Mar
(12) |
Apr
(17) |
May
(19) |
Jun
(97) |
Jul
(77) |
Aug
(33) |
Sep
(24) |
Oct
(41) |
Nov
(16) |
Dec
(32) |
| 2010 |
Jan
(24) |
Feb
(14) |
Mar
(50) |
Apr
(71) |
May
(70) |
Jun
(64) |
Jul
(45) |
Aug
(62) |
Sep
(32) |
Oct
(4) |
Nov
(12) |
Dec
(2) |
| 2011 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(3) |
May
(6) |
Jun
(1) |
Jul
(4) |
Aug
(3) |
Sep
(4) |
Oct
(6) |
Nov
(3) |
Dec
(3) |
| 2012 |
Jan
(4) |
Feb
(8) |
Mar
(6) |
Apr
(10) |
May
(2) |
Jun
(3) |
Jul
(11) |
Aug
(10) |
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(4) |
Feb
(1) |
Mar
(9) |
Apr
(1) |
May
(8) |
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(10) |
Dec
(8) |
| 2014 |
Jan
(3) |
Feb
(12) |
Mar
(9) |
Apr
(12) |
May
(2) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(9) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(7) |
Oct
(9) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(7) |
Feb
(5) |
Mar
(5) |
Apr
(5) |
May
(8) |
Jun
(4) |
Jul
(5) |
Aug
(4) |
Sep
(6) |
Oct
(7) |
Nov
(2) |
Dec
(3) |
| 2017 |
Jan
(7) |
Feb
(8) |
Mar
(7) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(8) |
Sep
(4) |
Oct
(2) |
Nov
(3) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2026 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Darren D. <da...@sh...> - 2005-06-15 12:22:46
|
1118838157
FAILED
[junit] Testcase: testTwoProperties took 0.001 sec
[junit] Testcase: testHandlesEqualsInValue took 0 sec
[junit] Testcase: testHandlesEmptyProperty took 0.001 sec
[junit] Testcase: testHandlesEmptyPropertyWithoutEquals took 0 sec
[junit] Testcase: testIgnoresCommentLinesAndEmptyLines took 0.019 sec
[junit] Testcase: testIgnoresLeadingSpacesAndTabs took 0.001 sec
[junit] Testcase: testNull took 0 sec
[junit] Testcase: testEmptyString took 0 sec
[junit] Exception in thread "main" java.io.FileNotFoundException: /home/users/d/da/davison/checkouts/spring/target/ppc-osx2/test-reports/TEST-org.springframework.beans.support.PagedListHolderTests.xml (Operation not permitted)
[junit] at org.apache.tools.ant.taskdefs.optional.junit.FormatterElement.createFormatter(FormatterElement.java:236)
[junit] at org.apache.tools.ant.taskdefs.optional.junit.FormatterElement.createFormatter(FormatterElement.java:192)
[junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.transferFormatters(JUnitTestRunner.java:586)
[junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:670)
[junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:546)
[junit] Caused by: java.io.FileNotFoundException: /home/users/d/da/davison/checkouts/spring/target/ppc-osx2/test-reports/TEST-org.springframework.beans.support.PagedListHolderTests.xml (Operation not permitted)
[junit] at java.io.FileOutputStream.open(Native Method)
[junit] at java.io.FileOutputStream.<init>(FileOutputStream.java:176)
[junit] at java.io.FileOutputStream.<init>(FileOutputStream.java:131)
[junit] at org.apache.tools.ant.taskdefs.optional.junit.FormatterElement.createFormatter(FormatterElement.java:234)
[junit] ... 4 more
[junit] --- Nested Exception ---
[junit] java.io.FileNotFoundException: /home/users/d/da/davison/checkouts/spring/target/ppc-osx2/test-reports/TEST-org.springframework.beans.support.PagedListHolderTests.xml (Operation not permitted)
[junit] at java.io.FileOutputStream.open(Native Method)
[junit] at java.io.FileOutputStream.<init>(FileOutputStream.java:176)
[junit] at java.io.FileOutputStream.<init>(FileOutputStream.java:131)
[junit] at org.apache.tools.ant.taskdefs.optional.junit.FormatterElement.createFormatter(FormatterElement.java:234)
[junit] at org.apache.tools.ant.taskdefs.optional.junit.FormatterElement.createFormatter(FormatterElement.java:192)
[junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.transferFormatters(JUnitTestRunner.java:586)
[junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:670)
[junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:546)
This is an automated mail from one of the SF Compile Farm machines.
The machine name noted in the subject encountered a failure building
or running the Spring test suite. The last few lines of the output
were included for info.
NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.
See http://springframework.sourceforge.net/test/ for further
information.
|
|
From: Alexandru P. <apo...@ez...> - 2005-06-15 11:03:14
|
#: by Colin Sampaleanu's words the mind was *winged* :# > Juergen, > > Sure, you're right. Java.net has a horrific UI and that combined with > the fact that it's just one project on the java.net site means (IMHO) > it's pretty much of a failure as as a 'Spring-Forge'; I can't see any > real reason why any of those libs would not want to move over to any > sort of decent CVS or SVN infrastructure we set up, but most if not all > will still remain separate to a large degree, with another group of > developers/committers, even in that eventuality. > > I'm not incredibly attached (or at all) to spring-modules as the name of > the CVS module for the new stuff. Any name is ok as long as we're all ok > with it. What about: > spring-projects > projects > What about spring-extensions? :alex |.::the_mindstorm::.| > Any other suggestions are welcome. The common-build system has been in > there for a while. spring-binding and spring-webflow are now in and > compiling. If we can come up with a name that is good for everybody, > I'll import the source to a new module by that name. Then we can send a > request to SF to clean up the old module and all the other obsolete > modules in there.... > > Colin > > > Juergen Hoeller wrote: > >>From my point of view, Spring Modules at java.net has mainly been set up to >>create a separate distribution and community for non-core modules, >>maintained by a separate set of developers. That Spring Modules project >>essentially focuses on integration of more exotic third-party products and >>on further non-core modules. >> >>So in my opinion, it's not quite like they're simply gonna be merged over >>once we move away from SourceForge CVS. This will have to remain separate to >>some degree. Remember that they even use a separate namespace: >>"org.springmodules"... >> >>In any case, calling two different things "Spring modules" isn't a good idea >>by any means, not even as a temporary measure. Could we please get all our >>heads together and clarify this? Rob, Keith, Colin, myself? >> >>Juergen >> >> >>-----Original Message----- >>From: spr...@li... >>[mailto:spr...@li...]On Behalf >>Of Colin Sampaleanu >>Sent: Tuesday, June 14, 2005 6:22 PM >>To: spr...@li... >>Subject: Re: [Springframework-developer] Rules code missing? >> >> >>Andy Depue wrote: >> >> >> >>>On Tuesday 14 June 2005 08:35 am, Colin Sampaleanu wrote: >>> >>> >>> >>> >>>>Not at all. We're however breaking stuff up into proper related projects >>>>with dependencies expressed properly via Ivy config files (still using >>>>Ant for the build). Binding and WebFlow are now in their own projects in >>>>the spring-modules CVS module at _SourceForge_. I'm not 100% clear on >>>>why the rules stuff is moving to the java.net Spring-Modules project. I >>>>need to talk to Keith about that. >>>> >>>> >>>> >>>> >>>> >>>I could see it being confusing that there are two spring-modules projects. >>>Must it be so? >>> >>> >>> >>> >>It's just a module name... But the idea is that once we move to our own >>CVS or SVN the java.net Spring-Modules dies. At that point we have >>fine-grained permissions on each module, and no more performance >>problems, which were the two main reasons to ever set up the java.net >>Spring Modules prject... >> >> >> >> >>------------------------------------------------------- >>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >>from IBM. Find simple to follow Roadmaps, straightforward articles, >>informative Webcasts and more! Get everything you need to get up to >>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >>_______________________________________________ >>Springframework-developer mailing list >>Spr...@li... >>https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> >>------------------------------------------------------- >>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >>from IBM. Find simple to follow Roadmaps, straightforward articles, >>informative Webcasts and more! Get everything you need to get up to >>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >>_______________________________________________ >>Springframework-developer mailing list >>Spr...@li... >>https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Colin S. <col...@ex...> - 2005-06-15 07:14:55
|
I think a root module makes a decent amount of sense here. These are all common projects linked by the common-build system. There may be and are other modules in there which are not related. Otherwise, people have to pull out "." and then remove or ignore all the other stuff, or alternately they have to pull out a bunch of individual modules. Keith Donald wrote: >How about "repository" or "codebase"? > >Is a single root module really that desirable? Just curious. > >Keith > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...] On Behalf Of >Colin Sampaleanu >Sent: Tuesday, June 14, 2005 5:03 PM >To: spr...@li... >Subject: Re: [Springframework-developer] Rules code missing? > >Juergen, > >Sure, you're right. Java.net has a horrific UI and that combined with >the fact that it's just one project on the java.net site means (IMHO) >it's pretty much of a failure as as a 'Spring-Forge'; I can't see any >real reason why any of those libs would not want to move over to any >sort of decent CVS or SVN infrastructure we set up, but most if not all >will still remain separate to a large degree, with another group of >developers/committers, even in that eventuality. > >I'm not incredibly attached (or at all) to spring-modules as the name of >the CVS module for the new stuff. Any name is ok as long as we're all ok >with it. What about: > spring-projects > projects > >Any other suggestions are welcome. The common-build system has been in >there for a while. spring-binding and spring-webflow are now in and >compiling. If we can come up with a name that is good for everybody, >I'll import the source to a new module by that name. Then we can send a >request to SF to clean up the old module and all the other obsolete >modules in there.... > >Colin > > >Juergen Hoeller wrote: > >>From my point of view, Spring Modules at java.net has mainly been set up to > > >>create a separate distribution and community for non-core modules, >>maintained by a separate set of developers. That Spring Modules project >>essentially focuses on integration of more exotic third-party products and >>on further non-core modules. >> >>So in my opinion, it's not quite like they're simply gonna be merged over >>once we move away from SourceForge CVS. This will have to remain separate >> >> >to > > >>some degree. Remember that they even use a separate namespace: >>"org.springmodules"... >> >>In any case, calling two different things "Spring modules" isn't a good >> >> >idea > > >>by any means, not even as a temporary measure. Could we please get all our >>heads together and clarify this? Rob, Keith, Colin, myself? >> >>Juergen >> >> >>-----Original Message----- >>From: spr...@li... >>[mailto:spr...@li...]On Behalf >>Of Colin Sampaleanu >>Sent: Tuesday, June 14, 2005 6:22 PM >>To: spr...@li... >>Subject: Re: [Springframework-developer] Rules code missing? >> >> >>Andy Depue wrote: >> >> >> >> >> >>>On Tuesday 14 June 2005 08:35 am, Colin Sampaleanu wrote: >>> >>> >>> >>> >>> >>> >>>>Not at all. We're however breaking stuff up into proper related projects >>>>with dependencies expressed properly via Ivy config files (still using >>>>Ant for the build). Binding and WebFlow are now in their own projects in >>>>the spring-modules CVS module at _SourceForge_. I'm not 100% clear on >>>>why the rules stuff is moving to the java.net Spring-Modules project. I >>>>need to talk to Keith about that. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>I could see it being confusing that there are two spring-modules projects. >>>Must it be so? >>> >>> >>> >>> >>> >>> >>It's just a module name... But the idea is that once we move to our own >>CVS or SVN the java.net Spring-Modules dies. At that point we have >>fine-grained permissions on each module, and no more performance >>problems, which were the two main reasons to ever set up the java.net >>Spring Modules prject... >> >> >> >> >>------------------------------------------------------- >>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >> >> >>from IBM. Find simple to follow Roadmaps, straightforward articles, > > >>informative Webcasts and more! Get everything you need to get up to >>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >>_______________________________________________ >>Springframework-developer mailing list >>Spr...@li... >>https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> >>------------------------------------------------------- >>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >> >> >>from IBM. Find simple to follow Roadmaps, straightforward articles, > > >>informative Webcasts and more! Get everything you need to get up to >>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >>_______________________________________________ >>Springframework-developer mailing list >>Spr...@li... >>https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> >> > > > > >------------------------------------------------------- >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >from IBM. Find simple to follow Roadmaps, straightforward articles, >informative Webcasts and more! Get everything you need to get up to >speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > >------------------------------------------------------- >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >from IBM. Find simple to follow Roadmaps, straightforward articles, >informative Webcasts and more! Get everything you need to get up to >speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Dmitriy K. <dko...@ru...> - 2005-06-15 02:12:20
|
I guess "FlippableComparator" is the American version of "InvertibleComparator" ;-) Dmitriy. Keith Donald wrote: >Lookin good!!! How come you didn't call InvertibleComparator >"FlippableComparator" ;-) Keith > > > |
|
From: Keith D. <ke...@in...> - 2005-06-15 00:00:27
|
Lookin good!!! How come you didn't call InvertibleComparator "FlippableComparator" ;-) Keith -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Juergen Hoeller Sent: Tuesday, June 14, 2005 4:41 PM To: spr...@li... Subject: Re: [Springframework-developer] enums, styler, comparator Sorry, I guess I caused a misunderstanding here: "core.beans.support.SortDefinition" still exists, like it did before. We're staying fully backwards compatible to Spring 1.2.1. Keith had another SortDefiniton class in the "comparator" package in the sandbox. That's the one I reworked. A side benefit of that is that we don't have two classes named SortDefinition in the production codebase. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Dmitriy Kopylenko Sent: Tuesday, June 14, 2005 9:53 PM To: spr...@li... Subject: Re: [Springframework-developer] enums, styler, comparator >I've also reworked the generic comparators: they reside in "util.comparator" >now. The biggest change there is that there is no SortDefinition class >anymore. Instead, an InvertibleComparator decorator takes over the same >role. SortDefinition already was a Comparator decorator before, so was >arguably misnamed. > > > We're using SortDefinition quite a bit. I guess I'd need to revisit some of our apps and refactor, refactor, refactor... :-) Dmitriy. ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Keith D. <ke...@in...> - 2005-06-14 23:08:50
|
How about "repository" or "codebase"? Is a single root module really that desirable? Just curious. Keith -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Colin Sampaleanu Sent: Tuesday, June 14, 2005 5:03 PM To: spr...@li... Subject: Re: [Springframework-developer] Rules code missing? Juergen, Sure, you're right. Java.net has a horrific UI and that combined with the fact that it's just one project on the java.net site means (IMHO) it's pretty much of a failure as as a 'Spring-Forge'; I can't see any real reason why any of those libs would not want to move over to any sort of decent CVS or SVN infrastructure we set up, but most if not all will still remain separate to a large degree, with another group of developers/committers, even in that eventuality. I'm not incredibly attached (or at all) to spring-modules as the name of the CVS module for the new stuff. Any name is ok as long as we're all ok with it. What about: spring-projects projects Any other suggestions are welcome. The common-build system has been in there for a while. spring-binding and spring-webflow are now in and compiling. If we can come up with a name that is good for everybody, I'll import the source to a new module by that name. Then we can send a request to SF to clean up the old module and all the other obsolete modules in there.... Colin Juergen Hoeller wrote: >From my point of view, Spring Modules at java.net has mainly been set up to >create a separate distribution and community for non-core modules, >maintained by a separate set of developers. That Spring Modules project >essentially focuses on integration of more exotic third-party products and >on further non-core modules. > >So in my opinion, it's not quite like they're simply gonna be merged over >once we move away from SourceForge CVS. This will have to remain separate to >some degree. Remember that they even use a separate namespace: >"org.springmodules"... > >In any case, calling two different things "Spring modules" isn't a good idea >by any means, not even as a temporary measure. Could we please get all our >heads together and clarify this? Rob, Keith, Colin, myself? > >Juergen > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On Behalf >Of Colin Sampaleanu >Sent: Tuesday, June 14, 2005 6:22 PM >To: spr...@li... >Subject: Re: [Springframework-developer] Rules code missing? > > >Andy Depue wrote: > > > >>On Tuesday 14 June 2005 08:35 am, Colin Sampaleanu wrote: >> >> >> >> >>>Not at all. We're however breaking stuff up into proper related projects >>>with dependencies expressed properly via Ivy config files (still using >>>Ant for the build). Binding and WebFlow are now in their own projects in >>>the spring-modules CVS module at _SourceForge_. I'm not 100% clear on >>>why the rules stuff is moving to the java.net Spring-Modules project. I >>>need to talk to Keith about that. >>> >>> >>> >>> >>> >>I could see it being confusing that there are two spring-modules projects. >>Must it be so? >> >> >> >> >It's just a module name... But the idea is that once we move to our own >CVS or SVN the java.net Spring-Modules dies. At that point we have >fine-grained permissions on each module, and no more performance >problems, which were the two main reasons to ever set up the java.net >Spring Modules prject... > > > > >------------------------------------------------------- >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >from IBM. Find simple to follow Roadmaps, straightforward articles, >informative Webcasts and more! Get everything you need to get up to >speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > >------------------------------------------------------- >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >from IBM. Find simple to follow Roadmaps, straightforward articles, >informative Webcasts and more! Get everything you need to get up to >speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <al...@in...> - 2005-06-14 22:28:53
|
View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050615001700Lbuild.283 |
|
From: Nick M. <nic...@gm...> - 2005-06-14 21:49:18
|
> Hopefully sooner rather than later though, we'll move off SF CVS, which > is completely useless. Where to, out of curiosity? -Nick On 6/14/05, Colin Sampaleanu <col...@ex...> wrote: > Not at all. We're however breaking stuff up into proper related projects > with dependencies expressed properly via Ivy config files (still using > Ant for the build). Binding and WebFlow are now in their own projects in > the spring-modules CVS module at _SourceForge_. I'm not 100% clear on > why the rules stuff is moving to the java.net Spring-Modules project. I > need to talk to Keith about that. >=20 > Hopefully sooner rather than later though, we'll move off SF CVS, which > is completely useless. >=20 >=20 > Nick Minutello wrote: >=20 > >Is this part of a general move of Spring to java.net? :-o > > > >I have to say its one of the most horrible sites known to man. Its > >like it was purposely built to make it impossible to find anything.... > > > > > >-Nick > > > > > > > > > >On 6/14/05, Keith Donald <ke...@in...> wrote: > > > > > >>Pardon the work in progress there -- :-) > >> > >>The Rules code will be moving over to spring modules at java.NET most > >>likely. Can you guys hold without it in CVS for a few days until we ge= t it > >>moved over? > >> > >>Thanks, > >> > >>Keith > >> > >>-----Original Message----- > >>From: spr...@li... > >>[mailto:spr...@li...] On Behal= f Of > >>Oliver Hutchison > >>Sent: Monday, June 13, 2005 7:24 PM > >>To: spr...@li... > >>Subject: RE: [Springframework-developer] Rules code missing? > >> > >>It looks like the spring code base is being broken up into modules. I > >>know that the sandbox binding code has moved over to the > >>"spring-binding" module but I've got no idea where the rules stuff has > >>ended up. > >> > >>Ollie > >> > >> > >> > >>>-----Original Message----- > >>>From: spr...@li... > >>>[mailto:spr...@li...] > >>> On Behalf Of Andy Depue > >>>Sent: Tuesday, 14 June 2005 4:41 AM > >>>To: spr...@li... > >>>Subject: [Springframework-developer] Rules code missing? > >>> > >>>I just did a checkout of spring, and the Rules code has > >>>vanished (org.springframework.rules.Rules, for example). The > >>>deleted code exists in the attic with the comment "prepping > >>>for modularization". Where might I find this code now? Or > >>>did I just time this wrong and it has yet to appear back in > >>>cvs somewhere? > >>> > >>> - Andy > >>> > >>> > >>>------------------------------------------------------- > >>>This SF.Net email is sponsored by: NEC IT Guy Games. How far > >>>can you shotput a projector? How fast can you ride your desk > >>>chair down the office luge track? > >>>If you want to score the big prize, get to know the little guy. > >>>Play to win an NEC 61" plasma display: > >>>http://www.necitguy.com/?r=3D20 > >>>_______________________________________________ > >>>Springframework-developer mailing list > >>>Spr...@li... > >>>https://lists.sourceforge.net/lists/listinfo/springframework-developer > >>> > >>> > >>> > >>------------------------------------------------------- > >>This SF.Net email is sponsored by: NEC IT Guy Games. How far can you > >>shotput > >>a projector? How fast can you ride your desk chair down the office luge > >>track? > >>If you want to score the big prize, get to know the little guy. > >>Play to win an NEC 61" plasma display: http://www.necitguy.com/?r > >>_______________________________________________ > >>Springframework-developer mailing list > >>Spr...@li... > >>https://lists.sourceforge.net/lists/listinfo/springframework-developer > >> > >> > >> > >>------------------------------------------------------- > >>This SF.Net email is sponsored by: NEC IT Guy Games. How far can you s= hotput > >>a projector? How fast can you ride your desk chair down the office luge= track? > >>If you want to score the big prize, get to know the little guy. > >>Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=3D20 > >>_______________________________________________ > >>Springframework-developer mailing list > >>Spr...@li... > >>https://lists.sourceforge.net/lists/listinfo/springframework-developer > >> > >> > >> > > > > > >------------------------------------------------------- > >This SF.Net email is sponsored by: NEC IT Guy Games. How far can you sh= otput > >a projector? How fast can you ride your desk chair down the office luge = track? > >If you want to score the big prize, get to know the little guy. > >Play to win an NEC 61" plasma display: http://www.necitguy.com/?r > >_______________________________________________ > >Springframework-developer mailing list > >Spr...@li... > >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you sho= tput > a projector? How fast can you ride your desk chair down the office luge t= rack? > If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=3D20 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Colin S. <col...@ex...> - 2005-06-14 21:03:26
|
Juergen, Sure, you're right. Java.net has a horrific UI and that combined with the fact that it's just one project on the java.net site means (IMHO) it's pretty much of a failure as as a 'Spring-Forge'; I can't see any real reason why any of those libs would not want to move over to any sort of decent CVS or SVN infrastructure we set up, but most if not all will still remain separate to a large degree, with another group of developers/committers, even in that eventuality. I'm not incredibly attached (or at all) to spring-modules as the name of the CVS module for the new stuff. Any name is ok as long as we're all ok with it. What about: spring-projects projects Any other suggestions are welcome. The common-build system has been in there for a while. spring-binding and spring-webflow are now in and compiling. If we can come up with a name that is good for everybody, I'll import the source to a new module by that name. Then we can send a request to SF to clean up the old module and all the other obsolete modules in there.... Colin Juergen Hoeller wrote: >From my point of view, Spring Modules at java.net has mainly been set up to >create a separate distribution and community for non-core modules, >maintained by a separate set of developers. That Spring Modules project >essentially focuses on integration of more exotic third-party products and >on further non-core modules. > >So in my opinion, it's not quite like they're simply gonna be merged over >once we move away from SourceForge CVS. This will have to remain separate to >some degree. Remember that they even use a separate namespace: >"org.springmodules"... > >In any case, calling two different things "Spring modules" isn't a good idea >by any means, not even as a temporary measure. Could we please get all our >heads together and clarify this? Rob, Keith, Colin, myself? > >Juergen > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On Behalf >Of Colin Sampaleanu >Sent: Tuesday, June 14, 2005 6:22 PM >To: spr...@li... >Subject: Re: [Springframework-developer] Rules code missing? > > >Andy Depue wrote: > > > >>On Tuesday 14 June 2005 08:35 am, Colin Sampaleanu wrote: >> >> >> >> >>>Not at all. We're however breaking stuff up into proper related projects >>>with dependencies expressed properly via Ivy config files (still using >>>Ant for the build). Binding and WebFlow are now in their own projects in >>>the spring-modules CVS module at _SourceForge_. I'm not 100% clear on >>>why the rules stuff is moving to the java.net Spring-Modules project. I >>>need to talk to Keith about that. >>> >>> >>> >>> >>> >>I could see it being confusing that there are two spring-modules projects. >>Must it be so? >> >> >> >> >It's just a module name... But the idea is that once we move to our own >CVS or SVN the java.net Spring-Modules dies. At that point we have >fine-grained permissions on each module, and no more performance >problems, which were the two main reasons to ever set up the java.net >Spring Modules prject... > > > > >------------------------------------------------------- >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >from IBM. Find simple to follow Roadmaps, straightforward articles, >informative Webcasts and more! Get everything you need to get up to >speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > >------------------------------------------------------- >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >from IBM. Find simple to follow Roadmaps, straightforward articles, >informative Webcasts and more! Get everything you need to get up to >speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Dmitriy K. <dko...@ru...> - 2005-06-14 20:48:28
|
Roger that ;-) Thanks for the clarification... Dmitriy. Juergen Hoeller wrote: >Sorry, I guess I caused a misunderstanding here: >"core.beans.support.SortDefinition" still exists, like it did before. We're >staying fully backwards compatible to Spring 1.2.1. > >Keith had another SortDefiniton class in the "comparator" package in the >sandbox. That's the one I reworked. A side benefit of that is that we don't >have two classes named SortDefinition in the production codebase. > >Juergen > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On Behalf >Of Dmitriy Kopylenko >Sent: Tuesday, June 14, 2005 9:53 PM >To: spr...@li... >Subject: Re: [Springframework-developer] enums, styler, comparator > > > > > >>I've also reworked the generic comparators: they reside in >> >> >"util.comparator" > > >>now. The biggest change there is that there is no SortDefinition class >>anymore. Instead, an InvertibleComparator decorator takes over the same >>role. SortDefinition already was a Comparator decorator before, so was >>arguably misnamed. >> >> >> >> >> >We're using SortDefinition quite a bit. I guess I'd need to revisit some >of our apps and refactor, refactor, refactor... :-) > >Dmitriy. > > > > >------------------------------------------------------- >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >from IBM. Find simple to follow Roadmaps, straightforward articles, >informative Webcasts and more! Get everything you need to get up to >speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > >------------------------------------------------------- >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >from IBM. Find simple to follow Roadmaps, straightforward articles, >informative Webcasts and more! Get everything you need to get up to >speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Juergen H. <ju...@in...> - 2005-06-14 20:40:55
|
Sorry, I guess I caused a misunderstanding here: "core.beans.support.SortDefinition" still exists, like it did before. We're staying fully backwards compatible to Spring 1.2.1. Keith had another SortDefiniton class in the "comparator" package in the sandbox. That's the one I reworked. A side benefit of that is that we don't have two classes named SortDefinition in the production codebase. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Dmitriy Kopylenko Sent: Tuesday, June 14, 2005 9:53 PM To: spr...@li... Subject: Re: [Springframework-developer] enums, styler, comparator >I've also reworked the generic comparators: they reside in "util.comparator" >now. The biggest change there is that there is no SortDefinition class >anymore. Instead, an InvertibleComparator decorator takes over the same >role. SortDefinition already was a Comparator decorator before, so was >arguably misnamed. > > > We're using SortDefinition quite a bit. I guess I'd need to revisit some of our apps and refactor, refactor, refactor... :-) Dmitriy. ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Dmitriy K. <dko...@ru...> - 2005-06-14 19:53:03
|
>I've also reworked the generic comparators: they reside in "util.comparator" >now. The biggest change there is that there is no SortDefinition class >anymore. Instead, an InvertibleComparator decorator takes over the same >role. SortDefinition already was a Comparator decorator before, so was >arguably misnamed. > > > We're using SortDefinition quite a bit. I guess I'd need to revisit some of our apps and refactor, refactor, refactor... :-) Dmitriy. |
|
From: Juergen H. <ju...@in...> - 2005-06-14 19:41:44
|
Everybody, Keith's LabeledEnum and ToStringCreator stuff has been moved over from the sandbox, to be shipped with Spring 1.2.2 (and to be used by Web Flow PR4). I've rearranged the structure and also reworked the implementations / interfaces quite a bit. ToStringCreator and its helpers reside in the "core.style" package now; LabeledEnum and LabeledEnumResolver in "core.enums" (without separate support subpackage; it's all in one package name). I've also reworked the generic comparators: they reside in "util.comparator" now. The biggest change there is that there is no SortDefinition class anymore. Instead, an InvertibleComparator decorator takes over the same role. SortDefinition already was a Comparator decorator before, so was arguably misnamed. Keith / Erwin, could you please make sure that everything's compiling again on the Web Flow side of things. Once the Web Flow module has found its final home in the CVS structure, that is ;-) Juergen |
|
From: Juergen H. <ju...@in...> - 2005-06-14 18:00:21
|
From my point of view, Spring Modules at java.net has mainly been set up to create a separate distribution and community for non-core modules, maintained by a separate set of developers. That Spring Modules project essentially focuses on integration of more exotic third-party products and on further non-core modules. So in my opinion, it's not quite like they're simply gonna be merged over once we move away from SourceForge CVS. This will have to remain separate to some degree. Remember that they even use a separate namespace: "org.springmodules"... In any case, calling two different things "Spring modules" isn't a good idea by any means, not even as a temporary measure. Could we please get all our heads together and clarify this? Rob, Keith, Colin, myself? Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Colin Sampaleanu Sent: Tuesday, June 14, 2005 6:22 PM To: spr...@li... Subject: Re: [Springframework-developer] Rules code missing? Andy Depue wrote: >On Tuesday 14 June 2005 08:35 am, Colin Sampaleanu wrote: > > >>Not at all. We're however breaking stuff up into proper related projects >>with dependencies expressed properly via Ivy config files (still using >>Ant for the build). Binding and WebFlow are now in their own projects in >>the spring-modules CVS module at _SourceForge_. I'm not 100% clear on >>why the rules stuff is moving to the java.net Spring-Modules project. I >>need to talk to Keith about that. >> >> >> >I could see it being confusing that there are two spring-modules projects. >Must it be so? > > It's just a module name... But the idea is that once we move to our own CVS or SVN the java.net Spring-Modules dies. At that point we have fine-grained permissions on each module, and no more performance problems, which were the two main reasons to ever set up the java.net Spring Modules prject... ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Andy D. <an...@ma...> - 2005-06-14 17:25:36
|
On Tuesday 14 June 2005 09:21 am, Colin Sampaleanu wrote: > It's just a module name... But the idea is that once we move to our own > CVS or SVN the java.net Spring-Modules dies. At that point we have > fine-grained permissions on each module, and no more performance > problems, which were the two main reasons to ever set up the java.net > Spring Modules prject... Ah, sounds good to me then. - Andy |
|
From: Colin S. <col...@ex...> - 2005-06-14 16:21:51
|
Andy Depue wrote: >On Tuesday 14 June 2005 08:35 am, Colin Sampaleanu wrote: > > >>Not at all. We're however breaking stuff up into proper related projects >>with dependencies expressed properly via Ivy config files (still using >>Ant for the build). Binding and WebFlow are now in their own projects in >>the spring-modules CVS module at _SourceForge_. I'm not 100% clear on >>why the rules stuff is moving to the java.net Spring-Modules project. I >>need to talk to Keith about that. >> >> >> >I could see it being confusing that there are two spring-modules projects. >Must it be so? > > It's just a module name... But the idea is that once we move to our own CVS or SVN the java.net Spring-Modules dies. At that point we have fine-grained permissions on each module, and no more performance problems, which were the two main reasons to ever set up the java.net Spring Modules prject... |
|
From: Andy D. <an...@ma...> - 2005-06-14 15:58:19
|
On Tuesday 14 June 2005 08:35 am, Colin Sampaleanu wrote: > Not at all. We're however breaking stuff up into proper related projects > with dependencies expressed properly via Ivy config files (still using > Ant for the build). Binding and WebFlow are now in their own projects in > the spring-modules CVS module at _SourceForge_. I'm not 100% clear on > why the rules stuff is moving to the java.net Spring-Modules project. I > need to talk to Keith about that. > I could see it being confusing that there are two spring-modules projects. Must it be so? - Andy |
|
From: Colin S. <col...@ex...> - 2005-06-14 15:35:43
|
Not at all. We're however breaking stuff up into proper related projects with dependencies expressed properly via Ivy config files (still using Ant for the build). Binding and WebFlow are now in their own projects in the spring-modules CVS module at _SourceForge_. I'm not 100% clear on why the rules stuff is moving to the java.net Spring-Modules project. I need to talk to Keith about that. Hopefully sooner rather than later though, we'll move off SF CVS, which is completely useless. Nick Minutello wrote: >Is this part of a general move of Spring to java.net? :-o > >I have to say its one of the most horrible sites known to man. Its >like it was purposely built to make it impossible to find anything.... > > >-Nick > > > > >On 6/14/05, Keith Donald <ke...@in...> wrote: > > >>Pardon the work in progress there -- :-) >> >>The Rules code will be moving over to spring modules at java.NET most >>likely. Can you guys hold without it in CVS for a few days until we get it >>moved over? >> >>Thanks, >> >>Keith >> >>-----Original Message----- >>From: spr...@li... >>[mailto:spr...@li...] On Behalf Of >>Oliver Hutchison >>Sent: Monday, June 13, 2005 7:24 PM >>To: spr...@li... >>Subject: RE: [Springframework-developer] Rules code missing? >> >>It looks like the spring code base is being broken up into modules. I >>know that the sandbox binding code has moved over to the >>"spring-binding" module but I've got no idea where the rules stuff has >>ended up. >> >>Ollie >> >> >> >>>-----Original Message----- >>>From: spr...@li... >>>[mailto:spr...@li...] >>> On Behalf Of Andy Depue >>>Sent: Tuesday, 14 June 2005 4:41 AM >>>To: spr...@li... >>>Subject: [Springframework-developer] Rules code missing? >>> >>>I just did a checkout of spring, and the Rules code has >>>vanished (org.springframework.rules.Rules, for example). The >>>deleted code exists in the attic with the comment "prepping >>>for modularization". Where might I find this code now? Or >>>did I just time this wrong and it has yet to appear back in >>>cvs somewhere? >>> >>> - Andy >>> >>> >>>------------------------------------------------------- >>>This SF.Net email is sponsored by: NEC IT Guy Games. How far >>>can you shotput a projector? How fast can you ride your desk >>>chair down the office luge track? >>>If you want to score the big prize, get to know the little guy. >>>Play to win an NEC 61" plasma display: >>>http://www.necitguy.com/?r=20 >>>_______________________________________________ >>>Springframework-developer mailing list >>>Spr...@li... >>>https://lists.sourceforge.net/lists/listinfo/springframework-developer >>> >>> >>> >>------------------------------------------------------- >>This SF.Net email is sponsored by: NEC IT Guy Games. How far can you >>shotput >>a projector? How fast can you ride your desk chair down the office luge >>track? >>If you want to score the big prize, get to know the little guy. >>Play to win an NEC 61" plasma display: http://www.necitguy.com/?r >>_______________________________________________ >>Springframework-developer mailing list >>Spr...@li... >>https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput >>a projector? How fast can you ride your desk chair down the office luge track? >>If you want to score the big prize, get to know the little guy. >>Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 >>_______________________________________________ >>Springframework-developer mailing list >>Spr...@li... >>https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> > > >------------------------------------------------------- >This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput >a projector? How fast can you ride your desk chair down the office luge track? >If you want to score the big prize, get to know the little guy. >Play to win an NEC 61" plasma display: http://www.necitguy.com/?r >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Darren D. <da...@sh...> - 2005-06-14 13:24:42
|
1118755475
FAILED
[junit] Testcase: testAutowireWithDefault took 0.04 sec
[junit] Testcase: testAutowireByConstructor took 0.077 sec
[junit] Testcase: testAutowireByConstructorWithSimpleValues took 0.266 sec
[junit] Testcase: testConstructorArgResolution took 0.544 sec
[junit] Testcase: testConstructorArgWithSingleMatch took 0.074 sec
[junit] Testcase: testThrowsExceptionOnTooManyArguments took 0.265 sec
[junit] Testcase: testThrowsExceptionOnAmbiguousResolution took 0.053 sec
[junit] Testcase: testFactoryBeanDefinedAsPrototype took 0.032 sec
[junit] Testcase: testDependsOn took 0.233 sec
[junit] Testcase: testDependsOnInInnerBean took 0.311 sec
[junit] Testcase: testDependenciesThroughConstructorArguments took 0.036 sec
[junit] Testcase: testDependenciesThroughConstructorArgumentAutowiring took 0.033 sec
[junit] Testcase: testDependenciesThroughConstructorArgumentsInInnerBean took 0.243 sec
[junit] Testcase: testDependenciesThroughProperties took 0.06 sec
[junit] Testcase: testDependenciesThroughPropertiesWithInTheMiddle took 0.466 sec
[junit] Testcase: testDependenciesThroughPropertyAutowiringByName took 0.036 sec
[junit] Testcase: testDependenciesThroughPropertyAutowiringByType took 0.655 sec
[junit] Testcase: testDependenciesThroughPropertiesInInnerBean took 0.041 sec
[junit] Testcase: testClassNotFoundWithDefault took 0.038 sec
[junit] Testcase: testClassNotFoundWithNoBeanClassLoader took 0.03 sec
[junit] Testcase: testResourceAndInputStream took 0.555 sec
[junit] Testcase: testClassPathResourceWithImport took 0.065 sec
[junit] Testcase: testUrlResourceWithImport took 0.072 sec
[junit] Testcase: testFileSystemResourceWithImport took 0.127 sec
[junit] Testcase: testLookupOverrideMethodsWithSetterInjection took 2.07 sec
[junit] FAILED
[junit] null
[junit] junit.framework.AssertionFailedError
[junit] at org.springframework.beans.factory.xml.XmlBeanFactoryTests.testLookupOverrideMethodsWithSetterInjection(XmlBeanFactoryTests.java:879)
This is an automated mail from one of the SF Compile Farm machines.
The machine name noted in the subject encountered a failure building
or running the Spring test suite. The last few lines of the output
were included for info.
NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.
See http://springframework.sourceforge.net/test/ for further
information.
|
|
From: <jas...@ma...> - 2005-06-14 10:20:08
|
On 14 Jun 2005, at 09:05, jas...@ma... wrote: > On 14 Jun 2005, at 08:37, Juergen Hoeller wrote: > > Its worth stressing, this is a pretty trivial change - has minimal > coding impact and adds a pretty trivial plugin interface. A couple more examples to show the kind of things possible with CVS HEAD of Spring. We've done the JBI deployment descriptor as a Spring XML extension, which is a bit more hardcore XML mapping... here are the POJOs http://cvs.servicemix.codehaus.org/servicemix/base/src/main/java/org/ servicemix/jbi/deployment/ with the Spring XML extension implementation classes http://cvs.servicemix.codehaus.org/servicemix/base/src/main/java/org/ servicemix/jbi/deployment/impl/ these classes rely on these generic Spring helper classes, which we could move into Spring for others to reuse http://cvs.servicemix.codehaus.org/servicemix/base/src/main/java/org/ servicemix/jbi/config/spring/ finally, here's an example of a deployment descriptor we can parse (with embedded Spring XML being possible within the XML of course :) http://cvs.servicemix.codehaus.org/*checkout*/servicemix/base/src/ test/resources/org/servicemix/jbi/deployment/example.xml?rev=HEAD James ------- http://radio.weblogs.com/0112098/ |
|
From: <jas...@ma...> - 2005-06-14 08:05:47
|
On 14 Jun 2005, at 08:37, Juergen Hoeller wrote: > Hi James, > > Interesting stuff :-) > > However, this needs to be aligned with whatever general way we'll > go for XML > extension stuff in Spring 1.3. Your approach looks reasonably > simple, but > hard-codes a few assumptions, such as the lookup mechanism (even > the lookup > path prefix). Its using the standard META-INF/services/* approach folks use to dynamically resolve extensions on the classpath. See JAXP and heaps of other libraries which use this mechanism. Erik Wiersma offered some interesting comments on my recent blog post... http://radio.weblogs.com/0112098/2005/06/10.html#a527 > We need to be careful regarding what we ship in 1.2.2 here, in > particular if > things are still subject to change. This is not about a release > candidate > for Spring 1.3; it's only a point release for 1.2... > > I'm not opposed to shipping that stuff in 1.2.2 as long as it received > proper review. I'm gonna have a deep look at it myself, but I would > also be > grateful for any further feedback - both by yourself and by other > interested > people :-) > > Spring 1.2.2 is scheduled for next week; it will definitely be > released > before JavaOne. So if we can't agree on that level of XML extension > mechanism in the given timeframe, we need to reconsider on how to > proceed > with the current stuff. OK. Its worth stressing, this is a pretty trivial change - has minimal coding impact and adds a pretty trivial plugin interface. James ------- http://radio.weblogs.com/0112098/ |
|
From: <jas...@ma...> - 2005-06-14 08:00:20
|
On 13 Jun 2005, at 17:47, Fredrik Lindgren wrote: > On Mon, 13 Jun 2005 09:51:04 +0200, <jas...@ma...> wrote: >> >>> Please go ahead and add the custm xml functionality, but in the >>> Spring spirit, keep the validation implementation pluggable. >>> >> >> It is! :) >> >> Whatever the end user uses to validate their XML is up to them - >> either DTD, XSD or no validation are the choices right now. >> > > I know. That's why I support adding the functionality as it is > right now. I only objected to the idea of switching to XSD as a > required/default validation mechanism for the spring XML. > Personally I prefer to use RELAX NG for my validation needs since > it has better support for alternative syntaxes (attribute or child > content) and support for cooccurence constraints which might be > helpful for catching some additional configuration errors. I'll > check out the implementation details and try to get back with more > constructive feedback. Agreed! XSD is a PITA :) It might even be simpler to write the Spring schema in terms of RelaxNG, then code generate the DTD and XSD from it - letting folks use whichever schema validation mechanism they wish - DTD or XSD or if they can Relax NG. http://thaiopensource.com/relaxng/trang.html If nothing else, this will mean we don't have to hand-maintain both the DTD and the XSD - but also RelaxNG is so much simpler to read James ------- http://radio.weblogs.com/0112098/ |
|
From: Juergen H. <ju...@in...> - 2005-06-14 07:37:53
|
Hi James, Interesting stuff :-) However, this needs to be aligned with whatever general way we'll go for XML extension stuff in Spring 1.3. Your approach looks reasonably simple, but hard-codes a few assumptions, such as the lookup mechanism (even the lookup path prefix). We need to be careful regarding what we ship in 1.2.2 here, in particular if things are still subject to change. This is not about a release candidate for Spring 1.3; it's only a point release for 1.2... I'm not opposed to shipping that stuff in 1.2.2 as long as it received proper review. I'm gonna have a deep look at it myself, but I would also be grateful for any further feedback - both by yourself and by other interested people :-) Spring 1.2.2 is scheduled for next week; it will definitely be released before JavaOne. So if we can't agree on that level of XML extension mechanism in the given timeframe, we need to reconsider on how to proceed with the current stuff. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of jas...@ma... Sent: Thursday, June 09, 2005 5:28 PM To: spr...@li... Subject: [Springframework-developer] Extensible XML processing in Spring: prototype version available in CVS HEAD Quite a few folks have wanted some way to extend/enhance Spring's XML configuration file mechanism to provide more concise XML with richer XML validation (through schemas and XSD extension etc). Here's some background ideas... http://article.gmane.org/gmane.comp.java.springframework.devel/8301/ match=neater+xml++xsd Yet another project I work on, ServiceMix, needed this - and I didn't have the heart to go down the XSLT route I've done before (e.g. on ActiveMQ) - so I thought I'd experiment actually working on Spring to provide an 'XML extension point' for XML configuration files. Example ======= First here's the example of what the XML looks like in ServiceMix before, using standard Spring - then afterwards with the 'XML extensions' so you can see the kind of thing I mean. regular Spring config. http://cvs.servicemix.codehaus.org/servicemix/base/src/test/resources/ org/servicemix/jbi/config/example-spring.xml?rev=HEAD&view=auto extended Spring http://cvs.servicemix.codehaus.org/servicemix/base/src/test/resources/ org/servicemix/jbi/config/example.xml?rev=HEAD&view=auto Now ServiceMix users can use a *much* more concise XML, if they want - we can easily add an XSD that can validate the ServiceMix model much better - but we can still mix and match all the great Spring XML stuff in there too. Its just a couple of trivial, simple macros (<components>, <component> and <qname>) to simplify the XML. From ServiceMix's perspective, we've implemented these new tags in the XML using a couple of pretty-trivial classes. The neat thing about this is that folks can now start to mix and match custom XML languages with the Spring XML. e.g. folks building Geronimo's web, JCA and EJB containers can use Spring XML to deal with J2EE deployment descriptors, but allow those files to include Spring XML too! Implementation ============ Now we could use inheritance to add custom XML processing (we did this in ActiveMQ) - each library developer would then provide their own definition reader / bean factory implementation; the problem with that is there are so many kinds of bean factory & application context and many ways to make them - having a custom bean factory didn't seem a clean solution. Plus I'd like us to mix and match different extensions together into the same Spring XML document. So I decided to try add a 'META-INF/services/' style of auto-discovery. The basic idea is that the standard spring configuration mechanism, will parse the regular Spring XML elements, but any new ones it doesn't recognise, it will see if there is an ElementProcessor class registered for the given element name (using namespaces too if need be). An ElementProcessor is a trivial little plugin interface allowing folks to turn any-old-XML into regular Spring <bean> <property> elements. Using XML extensions ================ So if you parse the this example 'extended' spring XML, with the latest CVS HEAD and the ServiceMix jar on your classpath... http://cvs.servicemix.codehaus.org/servicemix/base/src/test/resources/ org/servicemix/jbi/config/example.xml?rev=HEAD&view=auto it will automatically parse these new XML extensions! (To use the ServiceMix example above, since it uses arbitrary XML namespaces, you have to turn of XML validation to avoid using the DTD (*)) The neat thing is, different folks can now provide different extensions on the classpath. So we could have groovy, activemq, servicemix, geronimo-jca and geronimo-ejb, all making their own extensions, having their own XSDs and all used freely inside a single XML document. Impact ===== As it turns out, the impact on the code was surprisingly small and the entire thing only took about a day to implement - most of which was on the ServiceMix side of things (which is much less than the XSLT took to get right on ActiveMQ! :). The impact on the Spring codebase is a couple of fairly straightforward small methods added to the current parser, 1 new extension interface (ElementProcessor) and an optional helper class, ElementProcessorSupport that wraps up a bunch of useful helper methods for transforming DOM nodes and adding Spring XML elements. Due to the minimal impact of these changes & ease of backing them out again, I've gone ahead and checked them straight in. Please take a look and see what you think. I'm using ServiceMix (http:// servicemix.org/) as the test case right now; if there's general agreement among the team with this approach, I'll add some spring specific test cases into CVS to test it out inside the spring unit test suite. Remaining Issues ============= This whole spike was surprisingly simple to do and had minimal impact on Spring. (*) The only gotcha was, Spring uses XML validation by default - which forces a DOCTYPE to be specified - and DOCTYPEs don't like arbitrary namespaces to be used. So I've added an xmlValidating property on AbstractXmlApplicationContext and a new constructor on BeanFactory so you can turn off validation if you want to. (There could be other places in the code that might need to allow validation to be turned off, but that should do for a start). I guess if we had a Spring XSD, then we could enforce validation all the time and folks who wish to extend the XML must specify one more more XSD references in the XML? Thoughts? James ------- http://radio.weblogs.com/0112098/ ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Nick M. <nic...@gm...> - 2005-06-14 03:22:29
|
Is this part of a general move of Spring to java.net? :-o I have to say its one of the most horrible sites known to man. Its like it was purposely built to make it impossible to find anything.... -Nick On 6/14/05, Keith Donald <ke...@in...> wrote: > Pardon the work in progress there -- :-) >=20 > The Rules code will be moving over to spring modules at java.NET most > likely. Can you guys hold without it in CVS for a few days until we get = it > moved over? >=20 > Thanks, >=20 > Keith >=20 > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On Behalf = Of > Oliver Hutchison > Sent: Monday, June 13, 2005 7:24 PM > To: spr...@li... > Subject: RE: [Springframework-developer] Rules code missing? >=20 > It looks like the spring code base is being broken up into modules. I > know that the sandbox binding code has moved over to the > "spring-binding" module but I've got no idea where the rules stuff has > ended up. >=20 > Ollie >=20 > > -----Original Message----- > > From: spr...@li... > > [mailto:spr...@li...] > > On Behalf Of Andy Depue > > Sent: Tuesday, 14 June 2005 4:41 AM > > To: spr...@li... > > Subject: [Springframework-developer] Rules code missing? > > > > I just did a checkout of spring, and the Rules code has > > vanished (org.springframework.rules.Rules, for example). The > > deleted code exists in the attic with the comment "prepping > > for modularization". Where might I find this code now? Or > > did I just time this wrong and it has yet to appear back in > > cvs somewhere? > > > > - Andy > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: NEC IT Guy Games. How far > > can you shotput a projector? How fast can you ride your desk > > chair down the office luge track? > > If you want to score the big prize, get to know the little guy. > > Play to win an NEC 61" plasma display: > > http://www.necitguy.com/?r=3D20 > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you > shotput > a projector? How fast can you ride your desk chair down the office luge > track? > If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you sho= tput > a projector? How fast can you ride your desk chair down the office luge t= rack? > If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=3D20 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Seth L. <set...@gm...> - 2005-06-14 01:05:07
|
On 6/13/05, Oliver Hutchison <Ol...@ou...> wrote: > Any plans on merging with Steven Devijver's very nice valang stuff? ;) The plan is to also rework the commons-validator support to use the underlying rules code. Seth |
1239 messages has been excluded from this view by a project administrator.
