Hi I will change the code in trunk to use the NewFileComponent later this afternoon. Then we have the weekend for the team city servers to crunch on testing as well.
Willem fixes the last remaning issues on the windows box, and I think I got the occasional failing ones on the HP/AIX boxes as well. The change is only the META-INF/service/ .../ file trick by setting the "file" scheme to use NewFileComponent, instead of FileComponent. Then we can run with it for a while until we are all happy and can do the last transition and zap the old code. On Thu, Feb 5, 2009 at 11:07 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > On Thu, Feb 5, 2009 at 10:19 AM, Willem Jiang <willem.ji...@gmail.com> wrote: >> Hi Claus, >> >> I'm monitoring the tests in windows box for a while, now it looks good :) >> >> I just have th quick note for the NewFileComponent. >> >> If we plan to rename the newfile component to file component when all >> the file tests become stable, we don't need to mark the FileComponent as >> deprecated or we should add this information into the FileComponent java >> doc. >> >> Because current user can't change they code to use NewFileComponent now >> and the NewFileComponent will finally be rename to FileComponent. >> >> Am I right? > Yes it should eventually be renamed form NewFileComponent to FileComponent. > > We are in a kind of "in between" state right now. The faster/better we > can test it on different OS then faster > we can change the default in camel-core to use NewFileComponent, using > the service/.../file trick. > > Then the old File component that is marked as @deprecated will not be > used at all. It is just there in case there is a strange bug, then we > can swtich over and use it for comparison. > > After eg a week or so, and Team City is also happy then we can do the > big switch and remove the @deprecated and rename the NewFile to File. > > > >> >> Willem >> >> >> Claus Ibsen wrote: >>> Hi >>> >>> In Camel 2.0 we have refactored the File component to leverage a VFS >>> within Camel itself (common code/interface is named GenericFileXXX) >>> >>> As the file component is used extensivly within Camel itself and to >>> test all camel components it would be great if we could give it a test >>> drive on various OS before making the change permanent. >>> >>> So if you have the time then please test it as: >>> >>> 1) >>> You can change to use NewFileComponent by: >>> >>> Change these lines: >>> class=org.apache.camel.component.file.FileComponent >>> strategy.factory.class=org.apache.camel.component.file.strategy.FileProcessStrategyFactory >>> >>> To: >>> class=org.apache.camel.component.file.NewFileComponent >>> strategy.factory.class=org.apache.camel.component.file.strategy.NewFileProcessStrategyFactory >>> >>> In the file: >>> src/main/resources/META-INF/services/org/apache/camel/component/file >>> >>> 2) >>> Run tests in camel-core, camel-spring, camel-ftp, or if you have the >>> time the full package :) >>> >>> mvn clean install >>> >>> >>> For a period of time we will have both file components in Camel 2.0 >>> (the old and the new) side by side. The idea is to keep the old in >>> case something was overlooked and we can switch back for comparison. >>> When everything works and is rock solid then we will remove the old >>> one and make the new the default one. >>> >>> After this test and if it goes well, then we will switch to use the >>> NewFileComponent in Camel trunk code and run with it for a while, and >>> give TeamCity its chance to run extensivly test with it. >>> >>> But before that I would love to iron out any obscure issues on other >>> platforms, than what I use (Mac OS) >>> >>> >> >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
