There are two areas that I see commons as poor at achieving - release early release often and dependencies. The code itself is generally very good (despite what some might say).
[lang] is an example of this. It has needed a release for some time, if only to fix some of the glaring bugs in 2.0. It has also had changes applied to it that increase dependencies. I know that many reading this don't get my point here. Perhaps if I used the word coupling instead that would help? In the Validate case, there is no need for Validate to be coupled to StringUtils and ArrayUtils. It wasn't in its original design, I was just reverting code back to 2.0. This extends to other packages - ideally, no subpackage within lang should depend on another. We won't achieve that, but it should be a basic goal. (It should be noted that in [collections] I introduced more dependencies/coupling between classes in v3.0 and it has since been shown to be a Bad Thing) As I've tried to explain elsewhere, [lang] is not one jar file but many. It is a place where these tiny pieces of code can be grouped together and looked after, because even smaller projects tend not to work. After all, we ought to be able to create an exception jar, or an enums jar, or a validate jar if we wanted. Finally, it should be noted that [lang] has about 30 open calls, and many are valid. This suggests a wide user base who want this component supported and improved. The issue for us is more to do with [lang] satisfying our own personal isues already, so we don't feel motivated to do anything about it - its not our itch any more. But somehow, we need to at least get 2.1 out, then take it from there. [lang] is actually a great achievement, as almost certainly the most widely used library of its type. Lets not loose that achievement. Stephen ----- Original Message ----- From: "matthew.hawthorne" <[EMAIL PROTECTED]> > Gary Gregory wrote: > > Sorry for the flame but this is a 'shake-my-head-in-disbelief' moment > > that I find discouraging. > > I pretty much agree, but from my POV [lang] stopped moving forward a > while ago anyway. Most new requests > or ideas are rejected as "out of scope" (which is usually valid), and > the project has shifted into > maintenance mode. Along with this came a certain identity crisis, and > that's why the cut-and-paste > philosophy came along. > > As another example, I've never even liked the public constructor in > *Utils classes, even though I understand why it's > done. Helping and supporting users is important, but I think there is a > certain line that has to be drawn. > I think that developers should have the freedom to make classes and > methods final where appropriate, > and make other design decisions that may limit the possible uses of the > library. In losing that ability, I believe that > the quality of the code suffers. And for someone like me, it makes me > less motivated to become involved or share ideas. > > I may be dead wrong, these are just some feelings that I have. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
