FYI, Avalon has a Version class that aims to do some of what you describe. The thought of migrating that to commons [lang] had crossed my mind. (Much other Avalon code has moved to commons).
Can a [version] component stand up in commons? Perhaps. I don't disbute the need, I'm just not sure yet. Stephen ----- Original Message ----- From: "Adam Jack" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 20, 2003 11:27 PM Subject: [PROPOSAL] Commons-Version > To whom it may concern, > > I've been a heavy user of a wide variety of Jakarta software for a number of > years. I'd like to propose a way that I can repay some of that benefit, and > contribute more than just user feedback. > > Jakarta has some amazing software; I've extracted a lot of mileage from it. > Given it, and given the foundation of Java's classloaders and dynamic > linking, I am constantly amazed at how much I use and mix-n-match and yet > have relatively few problems. That said, I would like even less problems. > > For a living I (currently) deploy a reasonable amount of Java software on > top of a reasonably large number of packages (many Jakarta) in a reasonably > wide number of scenarios (from web servers/application servers to command > line) in a reasonably distributed environment. Short and sweet: software > operations, i.e. managing this complex combination of stuff, through > deployments, upgrades and patches -- is a lot of work. I'd like to reduce > the manual effort involved in checking environments. > > I believe Java needs a runtime version class, with a package dedicated to > branding (as in "burning in") and identifying versions. I believe this > would aid enormously with the process of environment debugging. Given > application servers, given numerous classpaths and class loaders (and > implementations), a deployment is vastly more than just an application and > it's jars. A simple, consistent, ubiquitous runtime version object can > remove the uncertainty surrounding versions and version dependencies, and > can support version constraints. > > I believe that a small and tightly focused package, simple to implement and > maintain against for users, and both lightweight and dependence-less can > offer a "no risk" approach to version identification. Since version > branding is only interesting after the fact (and to operators more than > developers), pandering to the developer is necessary to promote use, and to > strive towards ubiquity. This has to be simple, simple, simple. > > I know (from Internet searches) that I am not the only person to have > thought of a version class, many projects have them. What is missing is a > widely utilized implementation and/or approach. Without a consistent way to > determine the versions of the majority of packages there is little > motivation for folks to attempt programmatic determination, and hence manual > effort it required. > > I believe that Java Optional Package JAR versioning > (http://java.sun.com/j2se/1.4/docs/guide/extensions/versioning.html) -- the > stuff inside manifests is important, but not enough. I've tried using > manifests (producing them within Ant and consuming via code) but I've had > minimal real-world success using the results in a programmatic fashion. > Given the various class loader implementations (inside application servers) > getting to that information is not always possible. Much as this may seem > like an argument to fix class loaders, I think there is more to it. Even > JARs with fully descriptive manifests are simply static, waiting to be read, > they do not allow dependency or constraint checking. > > I recognize there are perhaps some red flags here; (1) I am not currently a > committer on any project (2) I am not a "group" of folks (3) there is no > software yet -- so I know this wouldn't make a Jakarta sub-project -- > however I was unable to find similar guidelines for a commons sandbox > project. Hopefully the scope of this is so small, and the dependency so > little, that you'd be willing to entertain this proposal as hopefully > "minimal risk". (You could probably track my history with Jakarta via an > e-mail archive search on "[EMAIL PROTECTED], [EMAIL PROTECTED], > [EMAIL PROTECTED]" -- one job, three address -- to see that I am a legit > user, if not [so far] a code contributor.) > > I recognize that all time and effort is investment, and cost, so I know that > granting me access & an area is not "free" to you, and a bit of a leap of > faith. I am willing (because I believe so strongly in the need for the > result) to jump through almost any hoops you deem to apply. I would happily > accept mentoring, and/or present a prototype implementation for review, etc. > One goal for making this proposal up-front is to ensure I am not missing > some existing venture, that I could be leveraging or contributing to, and > not duplicating effort. > > When (as I hope) this proves useful, and is worth making a dependency, I'd > like it to be a commons project (as opposed to say, a source forge one) so > it could be easily integrated into all the Jakarta projects that I use. > > As such, please accept (for discussion at this point) my proposal for such a > package. All feedback welcomed. > > > > regards, > > Adam > > ---------------------------------------------------------------------------- ---- > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
