On Mon, 2005-10-17 at 10:28 -0400, James Carman wrote: > Of course, I meant the only *required* dependency that Commons Proxy has is > the JDK itself.
great :) i think that the proposal could be improved. it's usually used as the basis of the introduction paragraph for the component. a good proposal is a powerful weapon against featuritus and scope drift. so, it's important for the long term health of a project. "The package shall create and maintain a suite of utility classes for creating proxy objects" seems just a little short. it seems to me that proxy is more like a minimal core of bridging API's for constructing proxy's (with minimal dependencies) supported by a number of optional implementations. i would also like to reiterate stephen's warning: if you use interfaces, be very sure that you are not going to need to change them in any fashion. i would very strongly suggest implementing the key ProxyFactory logical interface as an abstract class. this isn't bias (i love interfaces when coding applications) but a hard lesson painfully learnt. a few minor points: IMHO it'd be a good idea to note in the comment on the maven dependency page which dependencies are required for what code (preferably with an OPTIONAL at the start of the comment). a lot of users really complain (with good reason) about libraries with lots of core dependencies. the downside of maven (1) builds is that the list of dependencies can prove misleading. the maven mailing list page doesn't seem to have any information. you have some javadoc warnings and checkstyle violations. the distribution build doesn't load the notice and license into the jar MANEFEST. please read http://jakarta.apache.org/commons/releases/prepare.html for more details. commons-proxy.imi, commons-proxy.ipr and lo4j.properties files need a license boilerplate. navigation.xml lists the project as beanutils status.html still says 'collections' in a number of places. the list of required runtime dependencies is probably now outdated. ProxyUtils may well encounter classloading difficulties in some containers. it is possible that the context classloader may be null or inaccessible. i'm not convinced that the instantiateProxyFactory code will cope gracefully under all circumstances. http://jakarta.apache.org/commons/logging/tech.html may prove useful. on a slightly more serious note, the proposal says: "The initial codebase will be contributed by James Carman based on code in the Syringe (http://syringe.dev.java.net) project and can be distributed under the Apache license." has the incubator checked the paperwork for this? some nice to haves: basic package level document. a lot of components include a basic introduction in the package level java docs. the information already contained in status and proposal document would make a good start. since there are a lot of optional dependencies, it would be a very good idea to indicate in the javadocs which classes require which optional dependencies. for some packages, the package level documentation could be used for this. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
