You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ola Berg <ol...@ports.se> on 2003/01/23 10:24:44 UTC
[version] reflection-based [was:PROPOSAL Commons-Version]
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.
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 versioning components. We would create the problems we were supposed to solve.
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.
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.
One should probably look at [lang] (basic reflection and predicates) and [clazz].
/O
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [version] reflection-based [was:PROPOSAL Commons-Version]
Posted by Ola Berg <ol...@ports.se>.
correction/clarification:
> 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 versioning components.
last four words should have been
"using different versions of [version].
/O
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [version] reflection-based [was:PROPOSAL Commons-Version]
Posted by Adam Jack <aj...@TrySybase.com>.
Adam wrote:
> Nothing is to stop us from
> allowing optional extras, such as ....
Nick wrote:
We also need to deal with ...
Adam replies:
I think any number of optional extensions will be want added, the import
thing [IMHO] must be finding a concise yet sufficiently complete set that
enough folks can agree upon.
regards,
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [version] reflection-based [was:PROPOSAL Commons-Version]
Posted by Nick Chalko <ni...@chalko.com>.
Adam Jack wrote:
>I believe the convention ought be along the lines of:
>
>1) The class naming convention: ( .version. keeps it separate/out of the
>way.)
>
> {primary package path}.version.Version.class
>
> Saves class loaders being inefficient as they search.
>
>2) A single method or public field
>
> String getVersionString()
>
>3) The string format
>
>I guess I'd have to propose as documented here, if it could reach wide
>enough acceptance.
>
> http://jakarta.apache.org/commons/versioning.html
>
>If not, we've need a number of "version format" choices (and perhaps even
>"version versions".)
>
>i.e. Something like:
>
> package mystuff.version;
>
> public class Version
> {
> // For version of version...
> public static final String VERSION_FORMAT = "Jakarta Apache Commons";
> public static final String VERSION_VERSION = "1.0-A1";
>
> // Major = 3, Minor = 0, Point = Beta,
> public static final String VERSION_STRING = "3.0-B1";
>
> // An *optional* interface, if it exists it is used, else fall back
> // to the field VERSION_STRING;
> public String getVersionString()
> {
> // Lame example, could be a wrapper to external version.
> return Version.VERSION_STRING;
> }
> }
>
>If folks are game, I'd happily write something up, and post it here. I am
>sure this example above is incredibly over simplified, and doesn't include
>all that folks might like, but it is for starting discussion purposes.
>Coping with extensions (enhancements -- i.e. new version of version, as you
>said) would have to be carefully considered. Nothing is to stop us from
>allowing optional extras, such as aggregating versions of sub-components and
>such.
>
>Since I am no longer asking for a home, or for access permissions, or a
>project, merely requesting to contribute a document, perhaps I can engage
>any thread stalkers. Do folks have opinions?
>
>
We also need to deal with dev, milestone and snapshot builds.
Ruper uses this. http://krysalis.org/cgi-bin/krywiki.pl?Ruper
|name[[-major.minor[.fixe]][-modifier][-buildNumber]][-variant][.ext]|
* major, minor, fixe , buildNumber are number (0 as default)
* modifier is a status (shortname) + optinal number (release as
default), shortname known (in order):
o null => release
o "rc" => release canditate
o "b","beta" => beta
o "d", "dev" => developpement
o "ea" => early access
o "a", "alpha" => alpha
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [version] reflection-based [was:PROPOSAL Commons-Version]
Posted by Adam Jack <aj...@TrySybase.com>.
Ola,
Thanks for your input, it is good not to be talking completely to myself.
;-)
> There are different use cases for versioning, and I think it would be
foolish to meet them all in the same package.
I assume this statement is not a generalization, but comes from my previous
statement -- summarized: "using versions to debug environments requires
minimal dependencies, or is self-defeating". If not, please clarify. When
you says "one package" I am assuming you mean one distribution (JAR) and not
one Java package. I agree with the latter, but not the former.
As I see it, one creates a framework, unit tests, code samples (public
tests/code-based document for those that like that), one creates tools, one
creates GUIs and more (as optional extras). Nothing portrays a vision better
than some neat working examples of it, that a user can run and see w/
minimal effort. A distribution can contain some or all of these in separate
java packages without being foolish (IMHO). A few well positioned ant
<available>s and it can tolerate developer environments. As I see it the
framework grows as large or small as market forces (i.e. users/user
feedback/contributions) and common sense dictate. Only if it gets too
unwieldy, including if it gets too many dependency, would one split it. I
see no reason not to start by setting the sights high.
Getting back to the main topic: I suspect that you have a "my code plus
legacy code primary focus" whereas I have a "my code plus Apache code plus
future code primary focus". (Not wanting to speak for you, or say you don't
have a wide vision, this is just my take from what I read.) I recognize that
legacy code never seems to goes away, however I firmly believe that
versioning "somebody else's code" is at best risky proposition, and possibly
more often wrong than right, and quite possibly "foolish" ;-). I also
believe there are far more requirements and different approach than you
suggest. Thankfully though -- using your suggestion of a reflection-only
approach -- I think we can agree to disagree on all these aspects whilst
both working in the same general direction...
If we (somebody) can gain acceptance for a convention, then if we agree to
differ then I can write my code for manipulating versions/constraints, you
can write yours (I will help if I were to be invited), and we can both work
on those "branded" versions w/o restriction or much overlap. Good healthy
competition w/ a standard as the foundation so as not to cause interruption
to the masses. :)
I believe the convention ought be along the lines of:
1) The class naming convention: ( .version. keeps it separate/out of the
way.)
{primary package path}.version.Version.class
Saves class loaders being inefficient as they search.
2) A single method or public field
String getVersionString()
3) The string format
I guess I'd have to propose as documented here, if it could reach wide
enough acceptance.
http://jakarta.apache.org/commons/versioning.html
If not, we've need a number of "version format" choices (and perhaps even
"version versions".)
i.e. Something like:
package mystuff.version;
public class Version
{
// For version of version...
public static final String VERSION_FORMAT = "Jakarta Apache Commons";
public static final String VERSION_VERSION = "1.0-A1";
// Major = 3, Minor = 0, Point = Beta,
public static final String VERSION_STRING = "3.0-B1";
// An *optional* interface, if it exists it is used, else fall back
// to the field VERSION_STRING;
public String getVersionString()
{
// Lame example, could be a wrapper to external version.
return Version.VERSION_STRING;
}
}
If folks are game, I'd happily write something up, and post it here. I am
sure this example above is incredibly over simplified, and doesn't include
all that folks might like, but it is for starting discussion purposes.
Coping with extensions (enhancements -- i.e. new version of version, as you
said) would have to be carefully considered. Nothing is to stop us from
allowing optional extras, such as aggregating versions of sub-components and
such.
Since I am no longer asking for a home, or for access permissions, or a
project, merely requesting to contribute a document, perhaps I can engage
any thread stalkers. Do folks have opinions?
Thanks for your input.
regards,
Adam
-----Original Message-----
From: Ola Berg [mailto:ola.berg@ports.se]
Sent: Friday, January 24, 2003 2:21 AM
To: commons-dev@jakarta.apache.org; ajack@TrySybase.com
Subject: RE: [version] reflection-based [was:PROPOSAL Commons-Version]
There are different use cases for versioning, and I think it would be
foolish to meet them all in the same package.
Users
=====
Developers wanting to version their classes
Developers wanting to version other's classes
Developers with simple needs to check version
of a class before using it
Developers with advanced needs to check version
of a class before using it
I am not sure of the difference between "simple" and "advanced" in the two
latter cases.
Approaches for versioning
=========================
Declare a coding-pattern
No package dependencies involved.
Implement an interface
Perhaps from a very very simple jar
Create a version-class that will put
version on an existing class
A more advanced versioning toolkit containing
abstractions of rules etc
Approaches for checking versions
================================
Simple tool (isVersionAbove(), isCompatibleWith( version))
Small version-util jar
Advanced integration with Discovery
I think that the advanced stuff should
be integrated [in | with] Discovery
Discovery is a candidate, since [version] would solve a problem wihtin
Discovery's problem scope (finding the right resource from many candidates).
My 2 cents...
/O
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [version] reflection-based [was:PROPOSAL Commons-Version]
Posted by Ola Berg <ol...@ports.se>.
There are different use cases for versioning, and I think it would be foolish to meet them all in the same package.
Users
=====
Developers wanting to version their classes
Developers wanting to version other's classes
Developers with simple needs to check version
of a class before using it
Developers with advanced needs to check version
of a class before using it
I am not sure of the difference between "simple" and "advanced" in the two latter cases.
Approaches for versioning
=========================
Declare a coding-pattern
No package dependencies involved.
Implement an interface
Perhaps from a very very simple jar
Create a version-class that will put
version on an existing class
A more advanced versioning toolkit containing
abstractions of rules etc
Approaches for checking versions
================================
Simple tool (isVersionAbove(), isCompatibleWith( version))
Small version-util jar
Advanced integration with Discovery
I think that the advanced stuff should
be integrated [in | with] Discovery
Discovery is a candidate, since [version] would solve a problem wihtin Discovery's problem scope (finding the right resource from many candidates).
My 2 cents...
/O
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [version] reflection-based [was:PROPOSAL Commons-Version]
Posted by Adam Jack <aj...@TrySybase.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>