--- Matt Sgarlata [EMAIL PROTECTED] wrote:
David Graham wrote:
--- Daniel Florey [EMAIL PROTECTED] wrote:
BTW: Another advantage of this approach would be that imports would
indicate
which version of the component is in use. I had a lot of trouble to
find
out, which version of jdom
snip/
an application using 1.x.b will work with component 1.x.a
Does this sound reasonable? Missed something?
Have you seen the guidelines in use by the Apache APR project? It looks
to me like you're basically advocating the same system they have in
place. It might save us hassle to
Count me in! I'm planning on taking some time off for the holidays, so
that should give me time to play around with this :)
Matt
Daniel Florey wrote:
snip/
an application using 1.x.b will work with component 1.x.a
Does this sound reasonable? Missed something?
Have you seen the guidelines in use
Don't forget to do a little light reading first :-)
Mechanism to declare dependencies in a MANIFEST.MF File:
http://java.sun.com/j2se/1.4.2/docs/guide/extensions/versioning.html
ClassLoader implementation for representing an Assembly:
]
[mailto:[EMAIL PROTECTED]
Im Auftrag von Craig McClanahan
Gesendet: Dienstag, 21. Dezember 2004 21:28
An: Jakarta Commons Developers List
Betreff: Re: AW: AW: AW: AW: [proposal] avoiding jar version nightmares
Don't forget to do a little light reading first :-)
Mechanism to declare
On Tue, 21 Dec 2004 21:51:56 +0100, Daniel Florey [EMAIL PROTECTED] wrote:
Thanks for the links. Do you know if there is a maven task to automatically
generate this manifest entries based on the project.xml?
If not this might be a first step in order to allow easy adoption for the
upcoming
David Graham wrote:
--- Daniel Florey [EMAIL PROTECTED] wrote:
BTW: Another advantage of this approach would be that imports would
indicate
which version of the component is in use. I had a lot of trouble to find
out, which version of jdom was in use by some libraries as this was not
indicated by
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Im Auftrag von Craig McClanahan
Gesendet: Sonntag, 19. Dezember 2004 23:28
An: Jakarta Commons Developers List; [EMAIL PROTECTED]
Betreff: Re: AW: AW: AW: [proposal] avoiding jar version nightmares
On
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Im Auftrag von Craig McClanahan
Gesendet: Sonntag, 19. Dezember 2004 23:34
An: [EMAIL PROTECTED]
Cc: Jakarta Commons Developers List
Betreff: Re: AW: AW: AW: [proposal] avoiding jar version nightmares
If components stay backward compatible there of course is no need to include
the versions in the package name.
But I assume that there are some components that have incompatible api
changes (or even worse: same api different behaviour) between major version
numbers.
For packages like these the
So the collections way to handle this issue if to move all classes to a new
subpackage and leave the old ones where they've been before.
To be honest: Is this not very close to my proposal?
Something like:
org.apache.commons.component.version1...
org.apache.commons.component.version2...
I would
On Sun, 19 Dec 2004 23:51:06 +0100, Daniel Florey [EMAIL PROTECTED] wrote:
Simple example:
If you have two libraries:
Library A using component-1.x
Library B using component-2.x
Both libraries provide some servlets that need to live in the same webapp
and get initialized at startup.
How
--- Daniel Florey [EMAIL PROTECTED] wrote:
BTW: Another advantage of this approach would be that imports would
indicate
which version of the component is in use. I had a lot of trouble to find
out, which version of jdom was in use by some libraries as this was not
indicated by the name of
13 matches
Mail list logo
