xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane_Curc...@lotus.com
Subject Re: [Proposal] Guidlines for package distribution of Java projects: like XML file being read by class
Date Tue, 23 Nov 1999 13:34:49 GMT
Several comments on the Versioning discussion:

-- New suggestion: has anyone looked at "Open Software Description Format"
or OSD?
    http://www.w3.org/TR/NOTE-OSD.html
This is a pre-existing XML format for describing software releases - just
about what we want.  I'm not sure I like all the fields they use in their
format, but you can always extend it with namespaces.  Check it out.


-- I really like Thomas' idea below, where the actual version info is
stored in an XML file, and then read in by a Version.class.  As he points
out, both communities are happy: XML and text parsers have the info, and
Java programs have the info.  This would also make it simple to have the
version info in just one place for the entire project, since the
documentation could also parse the XML file and pull out version info too.
One important question is where should the XML version file live, both in
source trees and in binary outputs?  Although the Version.class can
gracefully fail when it doesn't find the version.xml (or whatever name)
file, I'd rather that this didn't happen too often.

Re: "Thomas B. Passin" <tpassin@mitretek.org> said:
> ... "How about the
> version is described by an xml file, and the Version class could read
> that file to produce its output."


-- I also agree with Mike on several points.  the version numbers should
probably be stored as strings, or as several *separate* numeric fields.
Yes, it's a tiny bit more programming work to compare versions then, but
it's worth it in my experience.
Also, we should have at least three levels or fields (major, minor,
maintenance release? or something like that?) in the versioning scheme.
It's better to start off with slightly more info in this area, since we'll
probably find additional uses for version info later on.

Re: Mike Pogue <mpogue@apache.org> said (among other things):
> 1) The information should be strings.  Do NOT count on it being a
> floating point number with a single dot...


-- I also support points 2 and 3 that Stefano makes below.
Java projects should be distributed as jar files.  While some
non-developers may be more experienced wit hzip (or gzip) files, I think
that's a fairly minor point.  A big point is that a jar tool exists on most
platforms we'll be on, so we can have just one file for distribution (which
is a big win).  Also, the jar format can be read by many zip utilties, so
you can always use that to unzip in a pinch.

The name-type-version.jar is a pretty good scheme too.  The important point
I like about this is that the name and version are the same ones that the
Version file/class will support, which makes writing automated tools much
easier.

Re: Stefano Mazzocchi <stefano@apache.org> wrote:
> 2) archive type
>
> I propose that every java project is distributed as one or more jar
> file.
>
> 3) package name
>
> I propose the following name model for packages
>
>  name[-type]-version.jar
>
> where
>
>  name := the project name
>  type := an optional indication (bin|src|all|???)
>  version := the version information
>
> note that "name" and "version" _must_ be the one passed by "getName()"
> and "getVersion()" methods in Version.


Hope this wasn't too long a discourse!
----    ----
- Shane         Automation, Test, & Build guy
mailto:shane_curcuru@lotus.com    AIM:xsltest
  http://alphaworks.ibm.com/tech/LotusXSL
  http://xml.apache.org/xalan/index.html


Mime
View raw message