On Fri, 6 Dec 2002, Costin Manolache wrote:
> There is no dual maintainance. Everyone maintains the code that > he cares about and uses. There is however inter-project debate. Which will run like this: Robert creates a better, leaner, nicer reflection library. Robert refactors beanutils to use this. Refactoring involves removing > > What I have consistently failed to understand about this debate is how > > commons can ask other jakarta projects to refactor out their common code > > when commons is unwilling to do the same job within its own borders. > > Commons is not asking other projects to refactor common code just for the > sake of moving code around and creating dependencies. If someone feels > a piece of code would benefit from having more hands and more diverse > opinions - and is willing to take the risks of more diverse opinions - > then commons may be a good idea. > > It is not in commons charter to create a one-size-fits-all introspection > library. > > What I fail to understand is what is the real issue of debate - > if you want to create a library for reflection, do it. > That doesn't mean you have to force everyone to use it or to stop > people from working on other reflection libraries or to say that the other > reflection code should move to your component. The problem comes when beanutils is refactored to use that library. While I agree that that should be dealt with when that point is reached, it is difficult to find the mental energy to create a library with the aim of using it in some form of application [such as another library] only to find that using that library is blocked in that application. > If a piece of code works well, is stable, fast, clean and does > what it is needed - it will be used, and people will stop working > on other implementations. If some other implementation does > something different and people need that - then probably both > will exist for a while. The biggest issue is the common Commons mailing list. Arguments leak over projects. You say that projects can quite happily run in parallel, duplicating code, but the nature of one mailing list means that they'll keep bumping heads. Discussions about reflection in Lang get tangled with questions as to whether BeanUtils should refactor to use that. Rod adding code to beanutils [which is pretty much his right] will slam into Robert refactoring that code in a month [which is also his right]. If Rod's code is unreleased by then [and robert has the right to -1 and argue against it being released, though it pushes the line a bit] then there's no reason why Robert has to worry about refactoring that work out. So that's what I think the underlying issue is. Yes everyone can run around and do their own thing with one hat on, but there repurcussions down the line to be dealt with and people are trying to forsee them and plan for them. > We must mind our own itches. That's the real issue that people > don't seem to understand. It's the best thing you're saying. In short, do what you want and debate when you're finished. Plus it's the only way open-source ever works, because we're scratching away for our own pleasure. Hen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
