You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Jeff Turner <je...@socialchange.net.au> on 2001/11/16 13:35:56 UTC
Standardized jar manifest entries? (Re: How do you version jar files?)
(was getting off-topic for ant-user)
On Fri, Nov 16, 2001 at 09:36:24AM +0100, Markus Kohler wrote:
> Hi,
>
> > -----Original Message-----
> > From: Peter Donald [mailto:donaldp@apache.org]
> > Sent: Friday, November 16, 2001 12:19 AM
> > To: Ant Users List
> > Subject: Re: How do you version jar files?
> >
> >
> > On Fri, 16 Nov 2001 09:47, Conor MacNeill wrote:
> > > Scott,
> > >
> > > There are a number of ways to version jars depending on your taste.
[..]
> > > 4. Add a manifest entry to the jar.
[..]
>
> If Java would have a standard for this (I haven't found one) it would
> be really cool to support this with an Ant Task.
Java's official versioning spec [1] seems curiously irrelevant. It talks
about API specifications, and implementations thereof; not the sort of
scenario most people deal with. It's primary use-case seems to be
applets (it amuses me how Sun documents can be dated this way;)
So how about defining a Jakarta-wide standard subset of jar manifest
entries? Something very simple, eg:
Package-name: xalan
Package-version: 2.2
Package-depends: xerces, 1.4.3
Then write a standard Java tool that can query any conforming jar, and
print this info. The dependency information would allow the tool to
recursively trace down dependencies, and print a complete list.
Btw, note the difference between "Class-Path:" and "Package-depends:".
One specifies physical jar names (a brittle, error-prone solution), and
the other specifies logical, abstract dependencies. This "abstractness"
would allow jar taxonomies to be defined; eg:
Package-depends: jaxp-parser, 1,1
would be satisfied by any JAXP 1.1-compatible parser.
Then one could have an abstract-to-physical-dependency mapping tool, to
translate "xerces, 1.4.3" to wherever you keep your 1.4.3 xerces.jar. An
init script or custom ClassLoader could then make use of this info, so
you'd no longer need 15 xerces.jar files on your harddisk :)
alexandria-dev folks (JvZ, SamR, Geir,..): think of this as proposing a
"guaranteed substratum" of jar metadata, which Gump, JJAR etc can use.
Does that sound workable? Don't be distracted by talk of taxonomies and
classloaders.. those are just applications. All I'm proposing right now
is 3 standardized manifest entries, and a tool to read them. That alone,
if adopted widely, would be of great benefit in a world of proliferating
unidentifiable jars.
--Jeff
[1] http://java.sun.com/j2se/1.4/docs/guide/extensions/versioning.html
[..]
>
> Markus
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Standardized jar manifest entries? (Re: How do you version jar files?)
Posted by Peter Donald <do...@apache.org>.
On Sat, 17 Nov 2001 04:02, Craig R. McClanahan wrote:
> On Fri, 16 Nov 2001, Jeff Turner wrote:
> > Java's official versioning spec [1] seems curiously irrelevant. It talks
> > about API specifications, and implementations thereof; not the sort of
> > scenario most people deal with. It's primary use-case seems to be
> > applets (it amuses me how Sun documents can be dated this way;)
>
> I'm not so sure this concept is irrelevant to general purpose application
> development.
>
> * Does your application architecture expose abstractions as
> interfaces (or abstract classes)?
>
> * Do you have more than one implementation of those abstractions?
>
> * Do the implementations rev independently of (and probably at a faster
> rate than) the abstractions?
>
> If so, exactly the same versioning model is quite reasonable.
except of course that the spec offers no method to indicate that your
specification is backwards incompatible with previous versions. That alon
makes it almost irrelevent.
--
Cheers,
Pete
----------------------------------------------------------------
Fools ignore complexity. Pragmatists suffer it.
Some can avoid it. Geniuses remove it.
-- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982
----------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Standardized jar manifest entries? (Re: How do you version jar files?)
Posted by Peter Donald <do...@apache.org>.
On Sat, 17 Nov 2001 04:02, Craig R. McClanahan wrote:
> On Fri, 16 Nov 2001, Jeff Turner wrote:
> > Java's official versioning spec [1] seems curiously irrelevant. It talks
> > about API specifications, and implementations thereof; not the sort of
> > scenario most people deal with. It's primary use-case seems to be
> > applets (it amuses me how Sun documents can be dated this way;)
>
> I'm not so sure this concept is irrelevant to general purpose application
> development.
>
> * Does your application architecture expose abstractions as
> interfaces (or abstract classes)?
>
> * Do you have more than one implementation of those abstractions?
>
> * Do the implementations rev independently of (and probably at a faster
> rate than) the abstractions?
>
> If so, exactly the same versioning model is quite reasonable.
except of course that the spec offers no method to indicate that your
specification is backwards incompatible with previous versions. That alon
makes it almost irrelevent.
--
Cheers,
Pete
----------------------------------------------------------------
Fools ignore complexity. Pragmatists suffer it.
Some can avoid it. Geniuses remove it.
-- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982
----------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Standardized jar manifest entries? (Re: How do you version jar
files?)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 16 Nov 2001, Jeff Turner wrote:
>
> Java's official versioning spec [1] seems curiously irrelevant. It talks
> about API specifications, and implementations thereof; not the sort of
> scenario most people deal with. It's primary use-case seems to be
> applets (it amuses me how Sun documents can be dated this way;)
>
I'm not so sure this concept is irrelevant to general purpose application
development.
* Does your application architecture expose abstractions as
interfaces (or abstract classes)?
* Do you have more than one implementation of those abstractions?
* Do the implementations rev independently of (and probably at a faster
rate than) the abstractions?
If so, exactly the same versioning model is quite reasonable.
Craig McClanahan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Standardized jar manifest entries? (Re: How do you version jar files?)
Posted by Danny Angus <da...@thought.co.uk>.
I will, ta, although I'm in danger of getting sucked so deep into Jakarta
stuff that I lose sight of *my job* !
> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@octo.com]
> Sent: Friday, November 16, 2001 3:31 PM
> To: Jakarta General List
> Subject: Re: Standardized jar manifest entries? (Re: How do you version
> jar files?)
>
>
> You should also have a look at the jjar project in Jakarta
> Commons and also
> the related discussion threads on jakarta-commons on the subject.
> There are
> some common ideas :)
>
> -Vincent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Standardized jar manifest entries? (Re: How do you version jar files?)
Posted by Vincent Massol <vm...@octo.com>.
You should also have a look at the jjar project in Jakarta Commons and also
the related discussion threads on jakarta-commons on the subject. There are
some common ideas :)
-Vincent
----- Original Message -----
From: "Danny Angus" <da...@thought.co.uk>
To: "Jakarta General List" <ge...@jakarta.apache.org>
Cc: "'Ant Users List'" <an...@jakarta.apache.org>
Sent: Friday, November 16, 2001 2:01 PM
Subject: RE: Standardized jar manifest entries? (Re: How do you version jar
files?)
> I like this, a lot, if I had a +1 here I'd use it..
> its simple
> its addresses a real need
> it would facilitate the production of tools to deal with the nightmare
that
> is .jars and the classpath
>
> Ant could check jars against dependencies, and build the jars from scratch
> only if need be.
> A new tool could be produced to manage the jar collections on a machine,
(an
> Ant subproject?) and export the list to the classpath, only one entry for
> each package-name, and that the highest version.
>
> Of course that suggests there should be a fourth entry like
>
> Package-stability: alpha | beta | release
>
> so you could a) see this info, and b) decide what version should be used
> based on stability.
>
> d.
>
>
> > -----Original Message-----
> > From: Jeff Turner [mailto:jeff@socialchange.net.au]
> > Sent: Friday, November 16, 2001 12:36 PM
>
>
> <snip>
> > So how about defining a Jakarta-wide standard subset of jar manifest
> > entries? Something very simple, eg:
> >
> > Package-name: xalan
> > Package-version: 2.2
> > Package-depends: xerces, 1.4.3
> >
> > Then write a standard Java tool that can query any conforming jar, and
> > print this info. The dependency information would allow the tool to
> > recursively trace down dependencies, and print a complete list.
> <snip>
> > Does that sound workable? Don't be distracted by talk of taxonomies and
> > classloaders.. those are just applications. All I'm proposing right now
> > is 3 standardized manifest entries, and a tool to read them. That alone,
> > if adopted widely, would be of great benefit in a world of proliferating
> > unidentifiable jars.
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Standardized jar manifest entries? (Re: How do you version jar
files?)
Posted by co...@covalent.net.
On Sun, 18 Nov 2001, Peter Donald wrote:
> * there is no formal syntax defined for Extension-Name or
> Implementation-Vendor-Id. By convention most people use the name of the java
> packages (ie reverse dns names in most cases) but this is not required.
It's a name - I don't think it needs a formal syntax. The same thing is
true for namespaces in XML - the only thing that matter is "equal".
> * syntax for versions is dewey decimal and there is no way to indicate
> backwards incompatability. As long as number is bigger it assumed to be
> compatible. ie 1.2.3.4.5 is meant to be compatible with 1.3, 2.3, 4.5 and
> there is no way in lifetime of extension for it to be incompatible. I would
> prefer a more fixed interpretation (ie major.minor.micro). Ages ago Rodney
> Waldhoff sent an email titled "RFC: Versioning Guidelines" to commons-dev and
> I responded to it. I think that had a good interpretation - it was the same
> as what we have been using in Avalon aswell.
That's because specifications _must_ be backward compatible. If it's no
longer backward compatible - then it's a different specification. I think
it makes sense - if 2 specs are not backward compatible it's better to
treat them as completely different things.
The only problem is when you have pieces of code that depend on both, and
you use the same package names. Which is another argument for the
"specs _must_ be backward compatible", and if they're not - you must use
different name and different package...
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Standardized jar manifest entries? (Re: How do you version jar files?)
Posted by Peter Donald <do...@apache.org>.
On Sun, 18 Nov 2001 00:52, Jeff Turner wrote:
> There are two documents mentioning versioning:
>
> 1) The "Optional Package" spec:
> The http://java.sun.com/j2se/1.4/docs/guide/extensions/versioning.html
Thats the one I am talking about.
> The "Optional Package" spec suggests these manifest entries:
>
> Extension-Name: javax.help
> Specification-Vendor: Sun Microsystems, Inc
> Specification-Version: 1.0
> Implementation-Vendor-Id: com.sun
> Implementation-Vendor: Sun Microsystems, Inc
> Implementation-Version: 1.0
Yep. I just finished implementing this in Avalon/Phoenix, Servlet2.3/Catalina
already implements this and newer EJB spec currently (or will) need to
support this. I have also been pushing strongly for this to be used in Ant2.
There are a few issues with the spec, the two that irritate me mostly are;
* there is no formal syntax defined for Extension-Name or
Implementation-Vendor-Id. By convention most people use the name of the java
packages (ie reverse dns names in most cases) but this is not required.
* syntax for versions is dewey decimal and there is no way to indicate
backwards incompatability. As long as number is bigger it assumed to be
compatible. ie 1.2.3.4.5 is meant to be compatible with 1.3, 2.3, 4.5 and
there is no way in lifetime of extension for it to be incompatible. I would
prefer a more fixed interpretation (ie major.minor.micro). Ages ago Rodney
Waldhoff sent an email titled "RFC: Versioning Guidelines" to commons-dev and
I responded to it. I think that had a good interpretation - it was the same
as what we have been using in Avalon aswell.
> So the questions is, do we want to:
>
> 1) "add fixed rules of interpretation" to one of these attribute sets
+1
> Assuming 1), which spec? We've both been assuming the "Optional Package"
> spec, but I think the "Java Product Versioning" spec is more
> appropriate, as it is _intended_ to be general-purpose; it's just
> horribly under-specified :)
I would still use the "Optional Package" even though it has painful
terminology and several severe limitations mainly as it is a standard. We can
add extra interpretations on top of that to bring it into bounds of
reasonable IMHO. Namely fix those two issues above and we would have a
workable system.
--
Cheers,
Pete
-------------------------------------------------------
"I would like to take you seriously but to do so would
affront your intelligence" -William F. Buckley, JR
-------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Standardized jar manifest entries? (Re: How do you version jar files?)
Posted by Jeff Turner <je...@socialchange.net.au>.
(detaching ant-user, where this is very OT)
On Sat, Nov 17, 2001 at 01:12:10AM +1100, Peter Donald wrote:
> Personally I would instead choose to just enhance the jdk1.3 "Optional
> Pacakge" spec with an extra attribute. (ie Jakarta-Rules: true or something
> better named) and then just add more fixed rules on interpretation of
> versions. The reason is that the "Optional Pacakge" spec is used in servlet,
> ejb and applet containers (and webstart???) atm. It will most likely be
> incorporated into other specs as time goes on.
>
> It would be much less effort IMO to create a document and magic attribute
> that described meanings exactly rather than adding another cutdown version
> which is not used anywhere outside jakarta.
I think we've both been barking up the wrong tree.. mostly me :P
There are two documents mentioning versioning:
1) The "Optional Package" spec:
The http://java.sun.com/j2se/1.4/docs/guide/extensions/versioning.html
2) The "Java Product Versioning" spec:
http://java.sun.com/j2se/1.4/docs/guide/versioning/spec/VersioningSpecification.html
The "Optional Package" spec suggests these manifest entries:
Extension-Name: javax.help
Specification-Vendor: Sun Microsystems, Inc
Specification-Version: 1.0
Implementation-Vendor-Id: com.sun
Implementation-Vendor: Sun Microsystems, Inc
Implementation-Version: 1.0
The "Java Product Versioning" spec has these:
Specification-Title: Java Utility Classes
Specification-Vendor: Sun Microsystems Inc.
Specification-Version: 1.3
Implementation-Title: java.util
Implementation-Vendor: SunMicrosystems. Inc.
Implementation-Version: build57"
The difference is all in the name/title/id attributes:
- The "Optional Package" spec defines how one jar can declare a
dependency on another (to say "I need extension 'javax.help'"). It's
"Extension-Name" attribute must be a reliable identity.
- The "Java Product Versioning" spec says nothing about how to specify
dependencies. Therefore the "Specification-Title" attribute is purely
informational.
So the questions is, do we want to:
1) "add fixed rules of interpretation" to one of these attribute sets
2) define our own attribute set and associated meanings
Assuming 1), which spec? We've both been assuming the "Optional Package"
spec, but I think the "Java Product Versioning" spec is more
appropriate, as it is _intended_ to be general-purpose; it's just
horribly under-specified :)
--Jeff
> On Sat, 17 Nov 2001 01:01, Danny Angus wrote:
> > I like this, a lot, if I had a +1 here I'd use it..
> > its simple
> > its addresses a real need
> > it would facilitate the production of tools to deal with the nightmare that
> > is .jars and the classpath
> >
> > Ant could check jars against dependencies, and build the jars from scratch
> > only if need be.
> > A new tool could be produced to manage the jar collections on a machine,
> > (an Ant subproject?) and export the list to the classpath, only one entry
> > for each package-name, and that the highest version.
> >
> > Of course that suggests there should be a fourth entry like
> >
> > Package-stability: alpha | beta | release
> >
> > so you could a) see this info, and b) decide what version should be used
> > based on stability.
> >
> > d.
> >
> > > -----Original Message-----
> > > From: Jeff Turner [mailto:jeff@socialchange.net.au]
> > > Sent: Friday, November 16, 2001 12:36 PM
> >
> > <snip>
> >
> > > So how about defining a Jakarta-wide standard subset of jar manifest
> > > entries? Something very simple, eg:
> > >
> > > Package-name: xalan
> > > Package-version: 2.2
> > > Package-depends: xerces, 1.4.3
> > >
> > > Then write a standard Java tool that can query any conforming jar, and
> > > print this info. The dependency information would allow the tool to
> > > recursively trace down dependencies, and print a complete list.
> >
> > <snip>
> >
> > > Does that sound workable? Don't be distracted by talk of taxonomies and
> > > classloaders.. those are just applications. All I'm proposing right now
> > > is 3 standardized manifest entries, and a tool to read them. That alone,
> > > if adopted widely, would be of great benefit in a world of proliferating
> > > unidentifiable jars.
>
> --
> Cheers,
>
> Pete
>
> ----------------------------------
> Ancient Go proverb: "Only amateurs
> try to come up with 'fancy' moves"
> ----------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Standardized jar manifest entries? (Re: How do you version jar files?)
Posted by Peter Donald <do...@apache.org>.
Personally I would instead choose to just enhance the jdk1.3 "Optional
Pacakge" spec with an extra attribute. (ie Jakarta-Rules: true or something
better named) and then just add more fixed rules on interpretation of
versions. The reason is that the "Optional Pacakge" spec is used in servlet,
ejb and applet containers (and webstart???) atm. It will most likely be
incorporated into other specs as time goes on.
It would be much less effort IMO to create a document and magic attribute
that described meanings exactly rather than adding another cutdown version
which is not used anywhere outside jakarta.
On Sat, 17 Nov 2001 01:01, Danny Angus wrote:
> I like this, a lot, if I had a +1 here I'd use it..
> its simple
> its addresses a real need
> it would facilitate the production of tools to deal with the nightmare that
> is .jars and the classpath
>
> Ant could check jars against dependencies, and build the jars from scratch
> only if need be.
> A new tool could be produced to manage the jar collections on a machine,
> (an Ant subproject?) and export the list to the classpath, only one entry
> for each package-name, and that the highest version.
>
> Of course that suggests there should be a fourth entry like
>
> Package-stability: alpha | beta | release
>
> so you could a) see this info, and b) decide what version should be used
> based on stability.
>
> d.
>
> > -----Original Message-----
> > From: Jeff Turner [mailto:jeff@socialchange.net.au]
> > Sent: Friday, November 16, 2001 12:36 PM
>
> <snip>
>
> > So how about defining a Jakarta-wide standard subset of jar manifest
> > entries? Something very simple, eg:
> >
> > Package-name: xalan
> > Package-version: 2.2
> > Package-depends: xerces, 1.4.3
> >
> > Then write a standard Java tool that can query any conforming jar, and
> > print this info. The dependency information would allow the tool to
> > recursively trace down dependencies, and print a complete list.
>
> <snip>
>
> > Does that sound workable? Don't be distracted by talk of taxonomies and
> > classloaders.. those are just applications. All I'm proposing right now
> > is 3 standardized manifest entries, and a tool to read them. That alone,
> > if adopted widely, would be of great benefit in a world of proliferating
> > unidentifiable jars.
--
Cheers,
Pete
----------------------------------
Ancient Go proverb: "Only amateurs
try to come up with 'fancy' moves"
----------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Standardized jar manifest entries? (Re: How do you version jar files?)
Posted by Peter Donald <do...@apache.org>.
Personally I would instead choose to just enhance the jdk1.3 "Optional
Pacakge" spec with an extra attribute. (ie Jakarta-Rules: true or something
better named) and then just add more fixed rules on interpretation of
versions. The reason is that the "Optional Pacakge" spec is used in servlet,
ejb and applet containers (and webstart???) atm. It will most likely be
incorporated into other specs as time goes on.
It would be much less effort IMO to create a document and magic attribute
that described meanings exactly rather than adding another cutdown version
which is not used anywhere outside jakarta.
On Sat, 17 Nov 2001 01:01, Danny Angus wrote:
> I like this, a lot, if I had a +1 here I'd use it..
> its simple
> its addresses a real need
> it would facilitate the production of tools to deal with the nightmare that
> is .jars and the classpath
>
> Ant could check jars against dependencies, and build the jars from scratch
> only if need be.
> A new tool could be produced to manage the jar collections on a machine,
> (an Ant subproject?) and export the list to the classpath, only one entry
> for each package-name, and that the highest version.
>
> Of course that suggests there should be a fourth entry like
>
> Package-stability: alpha | beta | release
>
> so you could a) see this info, and b) decide what version should be used
> based on stability.
>
> d.
>
> > -----Original Message-----
> > From: Jeff Turner [mailto:jeff@socialchange.net.au]
> > Sent: Friday, November 16, 2001 12:36 PM
>
> <snip>
>
> > So how about defining a Jakarta-wide standard subset of jar manifest
> > entries? Something very simple, eg:
> >
> > Package-name: xalan
> > Package-version: 2.2
> > Package-depends: xerces, 1.4.3
> >
> > Then write a standard Java tool that can query any conforming jar, and
> > print this info. The dependency information would allow the tool to
> > recursively trace down dependencies, and print a complete list.
>
> <snip>
>
> > Does that sound workable? Don't be distracted by talk of taxonomies and
> > classloaders.. those are just applications. All I'm proposing right now
> > is 3 standardized manifest entries, and a tool to read them. That alone,
> > if adopted widely, would be of great benefit in a world of proliferating
> > unidentifiable jars.
--
Cheers,
Pete
----------------------------------
Ancient Go proverb: "Only amateurs
try to come up with 'fancy' moves"
----------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Standardized jar manifest entries? (Re: How do you version jar files?)
Posted by Danny Angus <da...@thought.co.uk>.
I like this, a lot, if I had a +1 here I'd use it..
its simple
its addresses a real need
it would facilitate the production of tools to deal with the nightmare that
is .jars and the classpath
Ant could check jars against dependencies, and build the jars from scratch
only if need be.
A new tool could be produced to manage the jar collections on a machine, (an
Ant subproject?) and export the list to the classpath, only one entry for
each package-name, and that the highest version.
Of course that suggests there should be a fourth entry like
Package-stability: alpha | beta | release
so you could a) see this info, and b) decide what version should be used
based on stability.
d.
> -----Original Message-----
> From: Jeff Turner [mailto:jeff@socialchange.net.au]
> Sent: Friday, November 16, 2001 12:36 PM
<snip>
> So how about defining a Jakarta-wide standard subset of jar manifest
> entries? Something very simple, eg:
>
> Package-name: xalan
> Package-version: 2.2
> Package-depends: xerces, 1.4.3
>
> Then write a standard Java tool that can query any conforming jar, and
> print this info. The dependency information would allow the tool to
> recursively trace down dependencies, and print a complete list.
<snip>
> Does that sound workable? Don't be distracted by talk of taxonomies and
> classloaders.. those are just applications. All I'm proposing right now
> is 3 standardized manifest entries, and a tool to read them. That alone,
> if adopted widely, would be of great benefit in a world of proliferating
> unidentifiable jars.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Standardized jar manifest entries? (Re: How do you version jar files?)
Posted by Danny Angus <da...@thought.co.uk>.
I like this, a lot, if I had a +1 here I'd use it..
its simple
its addresses a real need
it would facilitate the production of tools to deal with the nightmare that
is .jars and the classpath
Ant could check jars against dependencies, and build the jars from scratch
only if need be.
A new tool could be produced to manage the jar collections on a machine, (an
Ant subproject?) and export the list to the classpath, only one entry for
each package-name, and that the highest version.
Of course that suggests there should be a fourth entry like
Package-stability: alpha | beta | release
so you could a) see this info, and b) decide what version should be used
based on stability.
d.
> -----Original Message-----
> From: Jeff Turner [mailto:jeff@socialchange.net.au]
> Sent: Friday, November 16, 2001 12:36 PM
<snip>
> So how about defining a Jakarta-wide standard subset of jar manifest
> entries? Something very simple, eg:
>
> Package-name: xalan
> Package-version: 2.2
> Package-depends: xerces, 1.4.3
>
> Then write a standard Java tool that can query any conforming jar, and
> print this info. The dependency information would allow the tool to
> recursively trace down dependencies, and print a complete list.
<snip>
> Does that sound workable? Don't be distracted by talk of taxonomies and
> classloaders.. those are just applications. All I'm proposing right now
> is 3 standardized manifest entries, and a tool to read them. That alone,
> if adopted widely, would be of great benefit in a world of proliferating
> unidentifiable jars.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Standardized jar manifest entries? (Re: How do you version jar
files?)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 16 Nov 2001, Jeff Turner wrote:
>
> Java's official versioning spec [1] seems curiously irrelevant. It talks
> about API specifications, and implementations thereof; not the sort of
> scenario most people deal with. It's primary use-case seems to be
> applets (it amuses me how Sun documents can be dated this way;)
>
I'm not so sure this concept is irrelevant to general purpose application
development.
* Does your application architecture expose abstractions as
interfaces (or abstract classes)?
* Do you have more than one implementation of those abstractions?
* Do the implementations rev independently of (and probably at a faster
rate than) the abstractions?
If so, exactly the same versioning model is quite reasonable.
Craig McClanahan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>