You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simon Kitching <si...@ecnetwork.co.nz> on 2004/03/30 07:20:20 UTC

[digester] runtime version info

Hi,

I notice that Xalan has implemented a new class:
   org.apache.xalan.Version
with a method
   static String getVersion()
and also a static main method which prints the version#.

See:
http://xml.apache.org/xalan-j/apidocs/org/apache/xalan/Version.html

The comment associated with this indicates that having a Version class
is "the upcoming standard" for providing runtime version info for apache
projects.

Do you think we should have a class
   org.apache.commons.digester.Version?

Regards,

Simon


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


Re: [digester] runtime version info

Posted by Nick Chalko <ni...@chalko.com>.
The depot project over in the incubator tries to handle some of these 
problems
See
http://incubator.apache.org/depot/version/

Simon Kitching wrote:

>On Tue, 2004-03-30 at 18:11, matthew.hawthorne wrote:
>  
>
>>Isn't this sort of thing supposed to be handled by manifest files?  I 
>>might be oversimplifying.
>>    
>>
>
>The initial problem that Xalan faced was people reporting bugs in xalan
>when they weren't actually running the version they thought they were,
>because Java1.4 bundles Xalan in the jre libs. I personally made a fool
>of myself over this a few years ago :-(.
>
>Asking people to run
>   java org.apache.xalan.Version
>will quickly sort these out.
>
>But there are commonly bug reports for java programs due to people
>having old versions in the classpath in less insidious ways. Tomcat and
>other containers often cause this problem too,.
>
>In neither case does manually extracting the MANIFEST file from the jar
>you *think* you are loading classes from tell you that you *are* in fact
>getting those classes at runtime.
>
>
>Regards,
>
>Simon
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>  
>


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


Re: [digester] runtime version info

Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Tue, 2004-03-30 at 18:11, matthew.hawthorne wrote:
> Isn't this sort of thing supposed to be handled by manifest files?  I 
> might be oversimplifying.

The initial problem that Xalan faced was people reporting bugs in xalan
when they weren't actually running the version they thought they were,
because Java1.4 bundles Xalan in the jre libs. I personally made a fool
of myself over this a few years ago :-(.

Asking people to run
   java org.apache.xalan.Version
will quickly sort these out.

But there are commonly bug reports for java programs due to people
having old versions in the classpath in less insidious ways. Tomcat and
other containers often cause this problem too,.

In neither case does manually extracting the MANIFEST file from the jar
you *think* you are loading classes from tell you that you *are* in fact
getting those classes at runtime.


Regards,

Simon


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


Re: [digester] runtime version info

Posted by "matthew.hawthorne" <ma...@apache.org>.
Noel J. Bergman wrote:
> "This class implements the upcoming standard of having
> org.apache.project-name.Version.getVersion() be a standard way to get
> version information."
> 
> That's news to me.  I suspect it is news to most.  As far as I know, it may
> be someone's strawman and/or wishful thinking, but this is the first I have
> heard about it.


Isn't this sort of thing supposed to be handled by manifest files?  I 
might be oversimplifying.


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


Re: [digester] runtime version info

Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Tue, 2004-03-30 at 18:33, Craig McClanahan wrote:
> Noel J. Bergman wrote:
> 
> >"This class implements the upcoming standard of having
> >org.apache.project-name.Version.getVersion() be a standard way to get
> >version information."
> >
> >That's news to me.  I suspect it is news to most.  As far as I know, it may
> >be someone's strawman and/or wishful thinking, but this is the first I have
> >heard about it.
> >
> >  
> >
> It's news to me too (maybe it's an XML-land thing?).
> 
> It also sounds pretty much redundant with the existing JDK mechanisms 
> for version discovery (which are based on information in 
> META-INF/MANIFEST.MF).  In particular, check out the javadocs for 
> java.lang.Package and the associated information on Package Version 
> Identification in the JDK docs.  See, for example:
> 
>   http://java.sun.com/j2se/1.4.2/docs/guide/versioning/index.html
> 
> If your project is a good citizen about creating MANIFEST.MF files in 
> your JARs, you get this stuff for free.

That does make the Version.getVersion() method a bit redundant; it would
presumably just be:
  return getPackage("org.apache.foo").getImplementationVersion();

However being able to run:
  java -cp foo.jar org.apache.foo.Version
and get back a version# seems quite nice.

If sun provided a tool with their jre for checking version#s, that could
do the same job:
  java-version-check -cp foo.jar org.apache.foo
but I didn't see any such tool in the versioning docs referred to above.


I wonder how sun's recommended approach works with Xalan/Xerces, given
that Sun tends to distribute classes from these projects as part of the
jre runtime? I'll have to try this later...


Regards,

Simon



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


Re: [digester] runtime version info

Posted by Craig McClanahan <cr...@apache.org>.
Noel J. Bergman wrote:

>"This class implements the upcoming standard of having
>org.apache.project-name.Version.getVersion() be a standard way to get
>version information."
>
>That's news to me.  I suspect it is news to most.  As far as I know, it may
>be someone's strawman and/or wishful thinking, but this is the first I have
>heard about it.
>
>  
>
It's news to me too (maybe it's an XML-land thing?).

It also sounds pretty much redundant with the existing JDK mechanisms 
for version discovery (which are based on information in 
META-INF/MANIFEST.MF).  In particular, check out the javadocs for 
java.lang.Package and the associated information on Package Version 
Identification in the JDK docs.  See, for example:

  http://java.sun.com/j2se/1.4.2/docs/guide/versioning/index.html

If your project is a good citizen about creating MANIFEST.MF files in 
your JARs, you get this stuff for free.

>	--- Noel
>
>  
>
Craig


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


RE: [digester] runtime version info

Posted by "Noel J. Bergman" <no...@devtech.com>.
"This class implements the upcoming standard of having
org.apache.project-name.Version.getVersion() be a standard way to get
version information."

That's news to me.  I suspect it is news to most.  As far as I know, it may
be someone's strawman and/or wishful thinking, but this is the first I have
heard about it.

	--- Noel


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