Stephen Colebourne wrote: > Yes we have many, many problems. > > Site > Is this really our top priority? Is maven 2 helping here? Is maven 1? I > have a distinct memory that commons was used as a practice ground pre > maven-1 to test maven's functionality in a real deployment. Are we about > to subject ourselves to this again?
My explicit intention was for this not to be the case, which is why I isolated it to my own components in the sandbox. All I did was add some requirements based on what commons wanted, so yes, it should help. However, if you are not having any issues now, you shouldn't have to concern yourself with it. > CI > How does another thing to worry about help us. Why not focus on Gump? Paying attention to gump and keeping it up to date would be good for commons as it will help monitor the library externally. That doesn't really directly help the project but its good to know if the false positives don't drown them out. Honestly, I think CI for commons should be a little lower on the list of things to do. Currently, work is being primarily done by a single person at a time which doesn't really need it as much. If it is there, it would be useful to use, but no point pushing on it until it is. > My analysis is that its time for a bit more radical surgery. And I mean > splitting commons into smaller communities. Jakarta Xxx Components sets > the naming pattern. If we do this, then each new group will be small > enough to be able to take decisions by itself, for example on the site. The re-Jakarta-isation of Jakarta? :) I thought the whole purpose was to get rid of the silos, not start building more. This is essentially the problem. Commons needs to decide if it is a bunch of independent components, or an ecosystem where all the components are a part of a single project. Things for being independent: * Users don't care. They probably want one library, not them all. They don't come to commons as their one stop shop for Java components. This could just because right now, it's not a one stop shop. * People usually have itches to scratch so will only work on small parts, not the whole. * Decisions get made easier. Each can use whatever build system it wants, whatever documentation system it wants, whatever code convention it wants. Things against being independent: * Some components depend on each other. Building those groups might help there, but some things will span many (like logging, digester, collections). Remember the talk of commons-all. * Building silos makes it harder to get more people involved. Maven's heavy-handedness about certain things that encourage consistency is not so that it can rule the world, it is so it is easy for people to move around. The medicine is good, it probably just needs to taste better. * Doing things in the same way will mean more people can worry about working on their components rather than infrastructure. Personally, I think being one community is better. Users still don't have to care, but those that want the one stop shop can have that too. People can still scratch itches and not worry about commons infrastructure. As for decisions, if you sum up the number of people interested in making those decisions I think there are few enough that it won't be that hard as long as everyone is objective. That's not to say there should be separate lists. We've done that for big subprojects in Maven and it works just fine. People with special interests can go there, but all the people active across projects hang out and discuss on the main dev list. - Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
