On Mon, Nov 17, 2008 at 8:35 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: >> ATM the cryptographic mailet code is packaged into: >> >> * org.apache.james.security >> (http://svn.apache.org/repos/asf/james/mailet/crypto/trunk/src/main/java/org/apache/james/security/) >> * org.apache.james.transport.mailets.smime >> (http://svn.apache.org/repos/asf/james/mailet/crypto/trunk/src/main/java/org/apache/james/transport/mailets/smime/) >> * org.apache.james.transport.matchers.smime >> (http://svn.apache.org/repos/asf/james/mailet/crypto/trunk/src/main/java/org/apache/james/transport/matchers/smime/) >> >> i was wondering about repackaging >> >> basing on 'org.apache.mailet.crypto' would follow the tentative >> convention adopted in base mailets but i'm open to suggestions >> >> opinions? > > I'm fine with repackaging, but we should remember that this will mean > that we need many <mailetpackages>/<matcherpackages> in our config, and > that we won't provide backward compatibility for config.xml unless we > add some hardcoded hack or we add a compatibility layer with > matchers/mailets in the old places.
crypto is little bit of a special case (it isn't in the 2.x code stream and it's not packaged now under o.a.j.transport) but i agree that this is an issue that needs discussion before standard > I don't know anymore if we are still on a backward compatible config.xml > or if we decided to abandon that goal. IMHO more detail is needed about what a commitment means in detail are we committing to: 1. maintain compatibility with 2.3 or with earlier versions of 3.0? 2. maintain compatibility with custom configurations? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
