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]>
