> For example: > SMTPHandler -> CDISMTPHandler > -> SpringSMTPHandler > -> JCASMTPHandler > -> AvalonSMTPHandler > > Please indicate your prefrence: > > [ ] +1 I agree that Agnostic SDI style POJO's are an > effective first step and will participate in the development > work
The first step would be to remove Phoenix specific stuff and replace it with Avalon stuff. I don't understand wether we should wait for the merge (Noel?) or the POJOification can start anyway (AFAIK: 2_1_fcs is the branch having more features and more tested while trunk is the branch with "Services" instead of deprecated "Components") Probably the bigger difference between trunk and 2_1_fcs would be moved in the Avalon<ComponentName> specific classes so the POJOification work would also simplify the merging operations, isn't it? Noel, can you, please, reply to this email I sent a few days ago in the "branch differences"? ----------------- > Intentional differences: > > - trunk has a released and updated version of Phoenix, > which meant changes to lifecycle interfaces. Will the new version run under Loom? > - trunk has some experimental changes that won't be kept. What changes will not be kept? I've seen there is a lot of code change to move from avalon Components (Deprecated) to avalon Services: will this be kept? I see there are still 3 references to avalon components: core/AvalonMailStore, core/AvalonUserStore, mailrepository/filepair/RepositoryManager. --------------------- Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
