RE: [VOTE] POJO pattern
+1 Will help when i can, but dont have much time at the moment. Daniel. -Original Message- From: Danny Angus [mailto:[EMAIL PROTECTED] Sent: 11 April 2005 09:58 To: server-dev@james.apache.org Subject: [VOTE] POJO pattern I propose that work commence to extract James's value add IP from classes supporting Avalon specific lifecycle attributes, and Avalon component dependance, to POJO classes. I further propose that these POJO's are designed to support IoC but are agnostic in their choice of SDI/CDI Therfore I propose that these classes be designed along SDI lines in order that the change is evolutionary and that they can later be factored to allow their use by CDI frameworks by those people who wish to do so. The basic pattern will be to have agnostic POJO's contain James' domain specific code. These POJO's will be extended to produce SDI, CDI, J2EE, or bespoke pattern-specific lifecycle specialisations through inheritance, delegation or injection. These specialisations can then be used to assemble behavioural solutions in CDI SDI or J2EE containers which can be maintaned independantly of the domain specific code in the POJO's 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 [ ] +0 I neither agree nor disagree that Agnostic SDI style POJO's are an effective first step but do not oppose the proposal [ ] -0 I disagree that Agnostic SDI style POJO's are an effective first step but do not oppose the proposal [ ] -1 I disagree that Agnostic SDI style POJO's are an effective first step and oppose the proposal because:.. d. ** * The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] POJO pattern
+1 Danny Angus wrote: I propose that work commence to extract James's value add IP from classes supporting Avalon specific lifecycle attributes, and Avalon component dependance, to POJO classes. I further propose that these POJO's are designed to support IoC but are agnostic in their choice of SDI/CDI Therfore I propose that these classes be designed along SDI lines in order that the change is evolutionary and that they can later be factored to allow their use by CDI frameworks by those people who wish to do so. The basic pattern will be to have agnostic POJO's contain James' domain specific code. These POJO's will be extended to produce SDI, CDI, J2EE, or bespoke pattern-specific lifecycle specialisations through inheritance, delegation or injection. These specialisations can then be used to assemble behavioural solutions in CDI SDI or J2EE containers which can be maintaned independantly of the domain specific code in the POJO's 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 [ ] +0 I neither agree nor disagree that Agnostic SDI style POJO's are an effective first step but do not oppose the proposal [ ] -0 I disagree that Agnostic SDI style POJO's are an effective first step but do not oppose the proposal [ ] -1 I disagree that Agnostic SDI style POJO's are an effective first step and oppose the proposal because:.. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Li mited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] POJO pattern
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 AvalonComponentName 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]
Re: [VOTE] POJO pattern
the merging process, which took almost 2 years (until now) will kill James, if it hasn't killed it already. Nobody knows which is the real head branch, etc. It would be better if you rename 2.1(?), which is the production version (almost), and officially abandon the current head. If somebody wants something from the head he can create a new patch. But this assumes that there is somebody who knows what is in the head and have time for the project, and I guess there is no such person. There is nothing to lose, we don't use anything from the head anyway. - Original Message - From: [EMAIL PROTECTED] To: 'James Developers List' server-dev@james.apache.org Sent: Monday, April 11, 2005 3:33 PM Subject: Re: [VOTE] POJO pattern 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 AvalonComponentName 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Merging (was [VOTE] POJO pattern)
the merging process, which took almost 2 years (until now) Actually, not even one. And that only because I got *really* busy, and was told that I should commit it finished rather than as a work-in-progress, which meant that no one else was contributing to it. Nobody knows which is the real head branch, etc. branch_2_1_fcs has always been the branch for developing the current code, whereas MAIN (trunk/) was future code. We've already said that much of the code change there would go away, except for the build environment, updates to Avalon and Jason's work on IMAP. None of which we want to lose. There is nothing to lose, we don't use anything from the head anyway. That is entirely wrong, as noted above. And part of the issue with the merger is making sure I don't lose any of those important parts. Plus the crazy schedule I've been keeping since last June. Blame me if you want. Enough validity in that, I suppose. I recently installed a VM on my laptop to carry around a JAMES build environment, so that I can work when I catch time, and plan to start committing the merger in parts, rather than as a whole, so that others can help out. Will start tonight when I get back from a client's site. Now I have to go. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Merging (was [VOTE] POJO pattern)
-Original Message- From: Serge Knystautas [mailto:[EMAIL PROTECTED] Sent: 11 April 2005 17:23 To: James Developers List Subject: Re: Merging (was [VOTE] POJO pattern) Noel J. Bergman wrote: the merging process, which took almost 2 years (until now) Actually, not even one. And that only because I got *really* busy, and was told that I should commit it finished rather than as a work-in-progress, which meant that no one else was contributing to it. To be fair, Noel was doing yeoman's work for James in 2003 and 2004. Here we are in Sept 2003 already calling MAIN dead and giving Noel flack for not maintaining two branches... http://marc.theaimsgroup.com/?l=james-devm=106392166516868w=2 There is nothing to lose, we don't use anything from the head anyway. That is entirely wrong, as noted above. And part of the issue with the merger is making sure I don't lose any of those important parts. Plus the crazy schedule I've been keeping since last June. I saw the point was more that we would not lose anything (since everything is in SVN) if we dumped what we have in MAIN (now trunk) and replaced it with branch_2_1_fcs. And, since we're agreeing on an evolutionary move away from our current dependencies, we could replace trunk with what's in branch_2_1_fcs to: - have code releases come off of trunk (simpler), and - only one branch to maintain (more efficient) As far as the IMAP work goes, the bits I've done already and that form the basis of the IMAP implementation can be merged into any source tree. This includes user attributes and my initial work on the new repositories. The protocol stack will take some hack-n-slash to get it going, but once the new way is clear I will start work again (I hope). If somebody does the POP3 server then the IMAP stuff will follow naturally as they are fairly similar in layout terms. IMAP's just a little more complex :) Blame me if you want. Enough validity in that, I suppose. I recently installed a VM on my laptop to carry around a JAMES build environment, so that I can work when I catch time, and plan to start committing the merger in parts, rather than as a whole, so that others can help out. As tempting as it is, you have done way too much to deserve blame. Now that we are building consensus and direction, I'd like to simplify our path to move us forward. While it is painful to just kill a branch, unless you suddenly become unemployed (or we massively and unfairly guilt-trip you into skipping work for a week), I see it as the simplest course of action. -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
imap2
I can't seem to build proposal imap2. Keeps saying that: org.bouncycastle.mail.smime.*; and: import org.bouncycastle.jce.*; don't exist. I already tried copying the relevant jars to tools/lib. Even tried adding entries to include.properties. Somebody must know! Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
