Paul,
> With the greatest of respect, your users are far smaller in number that > those to say Servlet (or those to say jdbc - a real balls-up of > backwards compatability) I absolutely agree with you. But it doesn't really matter. We haven't given any notice to our user base, no matter how small that base might be. That's the problem. Part of evolving into an enterprise piece of software is being attentive to the user base, both at the beginning and as it grows. That means you don't do things like this. Otherwise you have trouble getting to the point where you carry a large customer base with you. > I myself, might devise an API that has a custom 'lifecyle' methods for > mailets :- ... > Anyway, that is abig subject that embraces many IoC concerns, and > definately breaks back-compatability. Exactly. It's a big subject, requiring a lot of discussion. And I think it's clear that the James developers don't have a consensus on this one (see the Mailet logging discussion for reference). This will require lots of discussion and time - IMHO we shouldn't do this before 2.2. > >Ok, so that's the argument for preserving as much backwards > >compatibility as possible. So why don't we just leave the code as is, > >compiling and running against frozen versions of these > >libraries/containers from a particular date? > > > Could do. Stephen offers to maintain the forked Cornerstone. Personally I'd -1 this one. For all the reasons I list. > I have pointed out that the wrapper solution, though clever, will not > work for two of the mailets in James codebase ( JDBCAlias and > JDBCListserv ). > This is taken care of by (iii) and (iv). We can add (v), but my concern is custom written mailets, not core code base. As (iii) states, the ServiceManager is exposed analogously to the component manager. As (iv) states, all code stored in the James CVS would be migrated. That includes the JDBCAlias and JDBCListserv. So (v) is unnecessary to deal with these mailets. It's only necessary if custom mailets are using the DataSourceSelector. Not necessarily a bad idea, just doesn't solve the generic problem. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
