Doug Bateman wrote: > Howdy all, > > Tonight while browsing through the latest commons projects, it > occurred to me the once modest commons project has grown substantially > over time and has a lot of great stuff. There are now lots of sub > projects. Actually, it's 37 active subprojects to be exact. Plus the > archived projects. And the release numbering, JRE requirements, and > dependency graph can get a bit confusing. (Took me several hours to > map it out.)
Thanks! Very interesting. > > So I started thinking about what really makes it important to separate > projects: > + Different large external dependencies you wish to keep separate. As you and others have pointed out, we really don't have these and for the last several years we have been pushing hard to minimize dependencies even among the commons components. > + Projects that aren't related. > + Projects that have very different user communities (e.g. > commons-math versus commons-dbcp). A little humorous for me personally, as I cut the last releases of each of the two above ;) One of the things that makes Commons work is that there are quite a few of us who contribute to multiple components. Sometimes that contribution is to the main development, sometimes it is to things like cleaning up javadoc, checkstyle/findbugs, site maintenance or help with cutting releases. What is "related" about all of the commons components is that they all live here and all get the benefit of some level of attention from the commons community. We have talked several times in the past about breaking commons up via different schemes and each time we come back to this central benefit of "the commons" and decide to keep it as one project. We could of course change our minds about that, which is why we appreciate your suggestion to take stock of where we are. > > And on the flip side, the benefits that come from having one artifact > and one release number to track, instead of a whole heap of release > numbers and dependencies to manage. As others have pointed out, this cuts both ways. Years ago, we had a "combo-jar" release that turned out to be too difficult to maintain and of limited value to users, so it was dropped. As Hen pointed out, most feedback we have gotten is that users like smaller jars with fewer dependencies and good backward compatibility. As Torsten pointed out, the difficulty managing "multi-releases" is also not to be underestimated. IMO we do not do as good a job as we should releasing often and early in Commons and I would be hesitant to make a change that made that situation worse. At the end of the day, I am in the same place as Torsten on this - what exactly do we expect to gain by "consolidation?" If it is to make it easier for users to grab what they need in "bundles" that are sure to work together, I guess that could be a benefit for some users, but I would not want to break up the community to accomplish that. I would also worry about the mechanics of maintaining all of the bundled distros and the havoc that it would wreak on the established user base of the current, more granular, components. As a user, I would want to stick with the granular components. One slightly OT point raised one of Ralph's comments. The "committer lists" in the POMs for our components (so on the web pages) are woefully out of date. This is because we have traditionally added ourselves to components lists as we start to work on them, but we rarely if ever remove ourselves and we never remove people who have left. The same problem exists wrt @author tags that still litter the codebase, most from former Commons committers who are no longer active. Should we clean these up? We could use svn history for the committer lists - say, no commits in the last year and you get removed, but you are welcome to add yourself back with your first new commit? Should we uniformly remove @authors? Phil --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
