All, Ok ... so I hardly inspired a storm of enthusiasm with this e-mail. ;-) Mind you, I didn't get flamed either, so perhaps I oughtn't complain. :-)
Maybe it was the topic, maybe it was how long I made the intro, maybe it was folks are too busy, or maybe it was that I forgot to switch of "Read Notification" (sorry about that.) I will wait to see if any further responses are forthcoming however, since 2 days are about passed, I doubt I should be expecting them. That said, I am still eager to keep on about this. I feel the topic (albeit mundane) to be critical. I do not want to be pushy, but could I trouble somebody to let me know if I somehow presented this incorrectly, or if this forum isn't right for this sort of commons-sandbox proposal, or if this is just low interest given how busy folks are, or whatever. I'd love to know if I ought just wait (im)patiently, or do something else. I do not know if outsider proposals fit the mould sufficiently for you to let me know. I know this topic is perhaps dry, but I am willing to do work, to collaborate with folks to generate something, and I am not asking for much support [I hope] -- other than a place to reside, and support (inclusion) if the result proves interesting. I feel this is the kind of project that is thankless, but once done is valuable to all. (So long as the masses do not need to expend great effort to learn/use it). Personally I see this as very much like JUnit -- replacing a test with a version -- i.e. tools, ant tasks, GUIs, extensions -- and a bunch of introspection to extract these things & link them dynamically. Unlike JUnit though, I'd like to eventually (long term) see apache projects release JARs with a commons.version.Version object embedded. This makes me think it has to be an org.apache project, but perhaps not. Would you ship w/ a mandatory runtime dependency on a non-Jakarta JAR? I'd take your input on that. This could be a sourceforge project, I guess, it just seems a real shame to house it there and then (perhaps) redo things later on Apache. I also worry that anything developed by a group (any volunteers I get) on sourceforge, that isn't originally developed under apache ownership/license, might be hard to bring back to apache later. If you won't allow me to participate on commons I guess I'll have to go that route (or be open to other suggestions). Again, input appreciated. Perhaps it is a problem having somebody walk in "unknown", and want to start a project. If there is no allowance for this, even in commons sandbox, then please let me know. Would it be possible to develop something on source forge called "org.apache.commons.version.*", be under apache license/ownership -- and later be brought in for review? This way you'd not have to trust me w/ access rights on Jakarta. Please let me know your thoughts. regards, Adam -----Original Message----- From: Adam Jack [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 4:28 PM To: '[EMAIL PROTECTED]' 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. << File: commons-version-proposal.html >> regards, Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
