Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Reply-To: <ajack@TrySybase.com>
From: "Adam Jack" <ajack@TrySybase.com>
To: <commons-dev@jakarta.apache.org>
Subject: [PROPOSAL] Commons-Version
Date: Mon, 20 Jan 2003 16:27:30 -0700
Message-ID: <006901c2c0db$81404980$b98cea43@wdn086>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_006A_01C2C0A0.D4E17180"
Importance: Normal
Disposition-Notification-To: "Adam Jack" <ajack@TrySybase.com>

------=_NextPart_000_006A_01C2C0A0.D4E17180
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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 "ajack@neonsoft.com, ajack@openbiz.biz,
ajack@trysybase.com" -- 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


------=_NextPart_000_006A_01C2C0A0.D4E17180
Content-Type: text/plain; charset=us-ascii

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
------=_NextPart_000_006A_01C2C0A0.D4E17180--