commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Jack" <aj...@TrySybase.com>
Subject RE: [version] reflection-based [was:PROPOSAL Commons-Version]
Date Thu, 23 Jan 2003 15:52:56 GMT
Ola,

	I suggest that [version] should contain utilities for determining and
handling versions, and that those 	utilities can handle version information
that is reflection-based
	so that you don't have to implement an interface explicitely.

I'd recognized the benefit of reflection-based for projects not willing to
ship a version package merely to brand a simple version identifier into
themselves. I just felt that it was a little (perhaps restrictively) "hands
off" if the Version (and perhaps Constraints, see below) interfaces
stabilized. That said, I can see benefits with using this approach
exclusively.

I certainly believe there ought be a reflection-based algorithm for
determining Versions, and perhaps even an algorithm for determining proxy's
to existing versions (wrappers to versions out of ones control), and/or
custom version loaders (importers/generators).

	Implementing an interface explicitely could create versioning trouble,
since if it was successful and every 	project implemented the interface,
when using other projects we could have versioning conflicts when the
different packages were created using different using different versions of
[version].
	We would create the problems we were supposed to solve.

I can (now) see this. Using an old version implementation about a newer
interface could certainly be problematic. I am sure it could be managed w/
careful attention -- however the risk associated with such instability are
reduced "take up", defeating a primary goal of ubiquity in version branding.

	So, the utilities must be forgiving and intelligent when determining
versions of other classes. This would 	also make it easier for the other
jakarta projects to insert version information for their classes.

Yes, I agree, that is crucial.

I also think (though it might be overkill for a first attempt) that there
are different versioning policies and version data (Javasoft's 1.1.1_01
differs from Jakarta Commons 1.1.A1) and that this package ought make
intelligent conversions amongst flavours, or (at least) be able to work
containing them all.

	I would very much like to see this determination done in a rule-based
fashion (with a bunch of predicates) 	so that it will be possible to create
rules for already existing classes you don't have control over. 	Versioning
problems occurs first and foremost in other people's code, especially
non-open-source and 	legacy code where you (without [version]) have few
possibilities to fix it.

Nice observation. I'd perhaps supplement it with "Version mismatches
primarily occur with code not deployed one-to-one along with the user's
application. This could be shared code, open-source or not, that is so
popular that multiple installations install it, but not. Alternatively, it
could be code that "comes default" with the application server or other
runtime environment. If it isn't explicitly controlled by user's application
it is a candidate for the classpath crapshoot.

Interesting ... configuring the algorithm. I'd thought about proxy's to
external versions, I'd thought about a reflection-based algorithm, I'd not
thought about this. Interesting. I would suspect a number of
extension/integration techniques would end up being supported, perhaps this
could be one.

	One should probably look at [lang] (basic reflection and predicates) and
[clazz].

For helper code, or for a home for a sub-project?  (I will investigate
them.)

I guess that if we use a reflection-only approach then nobody need ship a
version library to brand, only to manipulate versions. As such "zero
runtime/deployment package dependencies" becomes less important, since there
are (by definition) none. Users that install it can cope with a few (perhaps
optional) dependencies, such as Lang/Clazz, XML parsers, JFC/Swing, Logging,
ANT, etc.

Also, the home for this (as a standalone package with no dependencies)
becomes less important perhaps, other than for awareness/support/utilization
of the branding mechanism. I would still like to see a separate
commons-version, since I fear this would clutter a lang or clazz, but I
guess it could go out to source forge as easily (other than apache
ownership). I believe this needs an appropriate home that allow it to grow
quite significantly, (see next section on "version constraints".)

	---------------------------------------------------------------------------
------------

Having cursorily investigated commons lang & clazz.... I could see how
Clazz's metadata approach to class introspection could be a help in
implementation of "wrapper"/"proxy" to legacy Versions. Lang's Predicates
could form a basic for implement "version constraints" so long as the
constraint statement was loaded separately via introspection, and/or from a
text editable file.

I also think that Discovery's pluggable interface could be used for customer
loaders, Collections and CLI and Logging for general internal
implementation, Digester for importing site constraint files [with separate
plug-in support for DBMS-stored constraints], and perhaps (not read it
enough yet) Validator for environment checking. Hmm, is it scary for a
version tool to rely upon so many version of things, especially young and
dynamic versions of things? One would want the version tool to run in the
environment one is trying to version check. Hmm, boggles the mind... ;-)
Clearly dependencies are something that need to be clearly recognized and
approved for each aspect of a version package's management/checks APIs, and
maybe even tools.

	---------------------------------------------------------------------------
------------

As soon as Versions are in place, I am really interested in version
constraints. I think that branding versions into Java packages is a huge
step forward, but I would hate to have to manually "view" them. I want to
program constraints, observers/alerts, logs. I would like to see a
Constraint interface (or reflection-based mechanism) for stating constraints
such as:

	depends upon org.apache.log4j
		<!-- Available at http://....... !>>

		(Such general statements could be auto-extracted/auto-inserted)
or

	depends upon package org.apache.log4j >= 1.2
		<!-- Since they added Conversion to the log4j.properties file around
then -->

or
	depends upon package org.apache.xerses > x.y
		<!-- 'cos we rely upon xmlns: support allowing xml prefixes -->

or
	general no-alpha-code	<!-- We need production only -->

I think these ought be able to be loaded from a site 'constraints' file (so
operators could customize this w/ predicate patches) and/or burn initial
constraints (that could be supplemented) into a package when it ships. I
would expect an ANT task to provide the developer support for the latter,
generating the code to represent constraints.

Along with that, I could see that an EnvironmentDescription (either of a
test environment or the build environment) could be supported. One of my
biggest love/hate relationships with Java is that one can't compile against
OtherClass.VERSION and have that be anything other than dynamically loaded.
When it is resolved, whatever is found is used. As such, something that
extracts OtherClass.VERSION at compile (or test) time, and generates a class
with such information "copied" could be invaluable. Users could perhaps
request a "delta" of "this environment" verse "build environment" or "test
environment(s)", and get information on different package versions. I
believe that we could have ant tasks for generating such descriptions, and
perhaps even processing the results (along w/ GUI/command line tools).

	---------------------------------------------------------------------------
------------

I've got a tonne of ideas on requirements, on APIs and tools. I'd like to
see a lot implemented, but I'd also go for a simplified/phased approach. I
could keep spewing my thoughts here, or add them into the proposal (didn't
want to make it a book), or I could wait to see if there could be a home for
these ideas here...

regards,

Adam


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


Mime
View raw message