Re: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-22 Thread Oliver Zeigermann
Hihi, good point, I actually never have. What phenomena are to be expected? Just like you have compiled something with say 1.4 and let it run on a 1.3 platform? Anyway, I was thinking of this with respect to class loading issues... Oliver On Wed, 22 Dec 2004 13:37:44 +1300, Sharples, Colin <[E

RE: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-21 Thread Sharples, Colin
> I do not think you can compare JDK APIs to commons APIs as you hardly > have more than one version of JDK API in your classpath ;) You mean you've never written an RMI app where the client and server were running different JVM levels? ;-) Colin Sharples IBM Advisory IT Specialist Email: [EMAIL

Re: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-21 Thread Oliver Zeigermann
On Wed, 22 Dec 2004 08:58:13 +1300, Sharples, Colin <[EMAIL PROTECTED]> wrote: > > And, in my experience watching work done with tools like > > Gump, any time > > people do weird trickery with package names, like Sun > > renaming some packages > > from x.y.z to com.sun.x.y.z, this inevitably seems

Re: AW: AW: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-21 Thread Craig McClanahan
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 > upcomin

AW: AW: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-21 Thread Daniel Florey
[EMAIL PROTECTED] > [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 rea

Re: AW: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-21 Thread Craig McClanahan
> >>With regards to problems caused by components that aren't using this new > >>package, I'm thinking that as long as the component does not make any > >>Class.forName calls, we should be OK. If there are Class.forName calls, > >>the component may still be able to work, but w

RE: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-21 Thread Sharples, Colin
> And, in my experience watching work done with tools like > Gump, any time > people do weird trickery with package names, like Sun > renaming some packages > from x.y.z to com.sun.x.y.z, this inevitably seems to cause > lots of problems > somewhere down the line. Exactly. Remember the howls of

Re: AW: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-21 Thread Matt Sgarlata
ECTED] [mailto:commons-dev-return-64857- [EMAIL PROTECTED] Im Auftrag von Matt Sgarlata Gesendet: Dienstag, 21. Dezember 2004 13:04 An: commons-dev@jakarta.apache.org Betreff: Re: AW: AW: [proposal] avoiding jar version nightmares Chris Lambrou wrote: Matt Sgarlata wrote: Does this mean .NET doesn&

Re: AW: AW: [proposal] avoiding jar version nightmares

2004-12-21 Thread Matt Sgarlata
Craig McClanahan wrote: Don't you get to this same result by creating your own URLClassLoader for each "assembly", with its own set of JARs and/or directories making up its "class path"? Haha, yes you probably do get the same result! I for one just didn't understand what this type of a solution w

AW: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-21 Thread Daniel Florey
d ensue if > java.util.Vector were to change its semantics!) > > > Regards, > > Daniel > > Matt > > >>-Ursprüngliche Nachricht- > >>Von: [EMAIL PROTECTED] > >>[mailto:commons-dev-return-64857- > [EMAIL PROTECTED] > >>Im Au

Re: AW: AW: [proposal] avoiding jar version nightmares

2004-12-21 Thread Craig McClanahan
Don't you get to this same result by creating your own URLClassLoader for each "assembly", with its own set of JARs and/or directories making up its "class path"? Craig On Tue, 21 Dec 2004 07:03:50 -0500, Matt Sgarlata <[EMAIL PROTECTED]> wrote: > Chris Lambrou wrote: > > Matt Sgarlata wrote: > >

Re: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-21 Thread Dennis Lundberg
Daniel Florey wrote: In order to find an appropriate solution to this issue, I'd like to identify the different problems that we need to address. Version: What does a version number mean? I'll make a proposal for how to use minor/major version number to have a basis on which we can identify the iss

RE: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-21 Thread Eric Pugh
December 19, 2004 5:28 PM > To: Jakarta Commons Developers List; [EMAIL PROTECTED] > Subject: Re: AW: AW: AW: [proposal] avoiding jar version nightmares > > > On Sun, 19 Dec 2004 23:25:30 +0100, Oliver Zeigermann > <[EMAIL PROTECTED]> wrote: > > On Sun, 19 Dec 20

Re: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-21 Thread Oliver Zeigermann
On Tue, 21 Dec 2004 09:11:55 -0500, Matt Sgarlata <[EMAIL PROTECTED]> wrote: > Daniel Florey wrote: > > I'd prefer to keep the "jar" naming as introducing "assembly" would cause > > some confusion. > > If anyone would be interested I could put a simple proposal to the sandbox. > > Good point, JAR

Re: AW: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-21 Thread David Graham
--- 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, whi

Re: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-21 Thread Matt Sgarlata
Sgarlata Gesendet: Dienstag, 21. Dezember 2004 13:04 An: commons-dev@jakarta.apache.org Betreff: Re: AW: AW: [proposal] avoiding jar version nightmares Chris Lambrou wrote: Matt Sgarlata wrote: Does this mean .NET doesn't have reflection? That's such a killer feature of Java; I can'

AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-21 Thread Daniel Florey
very big problems concerning incompatible jars in the same classloader. Regards, Daniel > -Ursprüngliche Nachricht- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Im Auftrag von Matt Sgarlata > Gesendet: Dienstag, 21. Dezember 2004 13:04 > An: commons-dev@jakarta.

Re: AW: AW: [proposal] avoiding jar version nightmares

2004-12-21 Thread Matt Sgarlata
Chris Lambrou wrote: Matt Sgarlata wrote: Does this mean .NET doesn't have reflection? That's such a killer feature of Java; I can't believe they wouldn't have ported it to .NET. Any .NET developers out there that can tell us how .NET deals with reflection when you have multiple versions of the

Re: AW: AW: [proposal] avoiding jar version nightmares

2004-12-20 Thread Chris Lambrou
Matt Sgarlata wrote: Does this mean .NET doesn't have reflection? That's such a killer feature of Java; I can't believe they wouldn't have ported it to .NET. Any .NET developers out there that can tell us how .NET deals with reflection when you have multiple versions of the same class? Since th

Re: AW: AW: [proposal] avoiding jar version nightmares

2004-12-20 Thread Frank W. Zammetti
.Net does have reflection. Some even say it's somewhat more elegant than Java... I ain't goin' there :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Matt Sgarlata wrote: Daniel Florey wrote: I think handling different versions of classes/j

Re: AW: AW: [proposal] avoiding jar version nightmares

2004-12-20 Thread Matt Sgarlata
Daniel Florey wrote: I think handling different versions of classes/jars at VM level would be a nice feature, but it would be very hard to implement nd to understand when it comes to reflection. Does this mean .NET doesn't have reflection? That's such a killer feature of Java; I can't believe the

Re: AW: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-20 Thread Matt Sgarlata
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

Re: AW: AW: [proposal] avoiding jar version nightmares

2004-12-20 Thread Daniel Florey
I think handling different versions of classes/jars at VM level would be a nice feature, but it would be very hard to implement nd to understand when it comes to reflection. Another proposal would be to do it the j2se-way: When introducing new features to a package (e.g. java.io) don't include th

Re: AW: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-19 Thread David Graham
--- 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

Re: AW: AW: [proposal] avoiding jar version nightmares

2004-12-19 Thread Craig McClanahan
The ability to declare your own versioning information, and that of your dependencies, in a MANIFEST.MF file already exists: http://java.sun.com/j2se/1.4.2/docs/guide/extensions/versioning.html Two existing use cases for this information are applets and servlet containers, where the container s

Re: AW: AW: [proposal] avoiding jar version nightmares

2004-12-19 Thread Matt Sgarlata
Craig McClanahan wrote: On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata <[EMAIL PROTECTED]> wrote: How do we go about petitioning Sun for something like this? A while back now (while the details for Tiger were being planned), I happened to be in a meeting with Graham Hamilton (who basically owns

Re: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-19 Thread Stephen Colebourne
From: "Daniel Florey" <[EMAIL PROTECTED]> 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? Certainly, there is some similarity. Were I to change the semantic

Re: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-19 Thread Oliver Zeigermann
On Sun, 19 Dec 2004 23:17:55 -, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > The incompatabilities that usually hurt the most are the unplanned ones, > like with collections. Your proposal is to change package with each > incompatible new release. Well, applying that 'rule' to collections, I

Re: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-19 Thread Stephen Colebourne
You might be irritated, but I think this is the cost to pay for working around this obvious java lack of managing versioned libraries. I think it's just a matter of getting used to this package naming convention. But it doesn't solve the problem. The incompatabilities that usually hurt the most are

Re: AW: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-19 Thread Craig McClanahan
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

AW: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-19 Thread Daniel Florey
ermann > Gesendet: Sonntag, 19. Dezember 2004 23:51 > An: Stephen Colebourne > Cc: Jakarta Commons Developers List > Betreff: Re: AW: AW: AW: [proposal] avoiding jar version nightmares > > On Sun, 19 Dec 2004 22:46:26 -, Stephen Colebourne > <[EMAIL PROTECTED]> wrote: >

AW: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-19 Thread Daniel Florey
et: Sonntag, 19. Dezember 2004 23:46 > An: Jakarta Commons Developers List; [EMAIL PROTECTED] > Betreff: Re: AW: AW: AW: [proposal] avoiding jar version nightmares > > > Major releases, i.e. e.g. from 1.x to 2.x are there not to be backward > > compatible. Especially, I would even cons

AW: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-19 Thread Daniel Florey
> -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: [propos

Re: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-19 Thread Oliver Zeigermann
On Sun, 19 Dec 2004 22:46:26 -, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > > Major releases, i.e. e.g. from 1.x to 2.x are there not to be backward > > compatible. Especially, I would even consider it dangerous to replace > > a 1.x version with 2.x without checks just to have a newer versi

AW: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-19 Thread Daniel Florey
> -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 j

Re: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-19 Thread Stephen Colebourne
Major releases, i.e. e.g. from 1.x to 2.x are there not to be backward compatible. Especially, I would even consider it dangerous to replace a 1.x version with 2.x without checks just to have a newer version. Semantics could have chages. Consider collections from 2. to 3. What was done there was pe

Re: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-19 Thread Craig McClanahan
On Sun, 19 Dec 2004 23:24:52 +0100, Oliver Zeigermann <[EMAIL PROTECTED]> wrote: > > Major releases, i.e. e.g. from 1.x to 2.x are there not to be backward > compatible. Especially, I would even consider it dangerous to replace > a 1.x version with 2.x without checks just to have a newer version.

Re: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-19 Thread Craig McClanahan
On Sun, 19 Dec 2004 23:25:30 +0100, Oliver Zeigermann <[EMAIL PROTECTED]> wrote: > On Sun, 19 Dec 2004 22:17:10 -, Stephen Colebourne > <[EMAIL PROTECTED]> wrote: > > I would also -1. Versioned packages is not an acceptable solution. > > What is an acceptable solution then? Do what I said alr

Re: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-19 Thread Oliver Zeigermann
On Sun, 19 Dec 2004 22:17:10 -, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > I would also -1. Versioned packages is not an acceptable solution. What is an acceptable solution then? Oliver - To unsubscribe, e-mail: [EMAIL

Re: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-19 Thread Oliver Zeigermann
On Sun, 19 Dec 2004 14:06:40 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On Sun, 19 Dec 2004 22:52:48 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote: > > The solution you proposed will not solve the issue as you cannot replace the > > classloader of the application server. > > That's not

Re: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-19 Thread Stephen Colebourne
Finally I think that my proposal is not that bad. If it's not possible to address this issue in future versions of the java language, this seems to be the only solution. So my vote is +1 to add at least the major version number to the components package name. That would have unacceptable impacts

Re: AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-19 Thread Craig McClanahan
On Sun, 19 Dec 2004 22:52:48 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote: > The solution you proposed will not solve the issue as you cannot replace the > classloader of the application server. That's not what I proposed. If you're inside a webapp, what I proposed is that you create your own c

AW: AW: AW: [proposal] avoiding jar version nightmares

2004-12-19 Thread Daniel Florey
Commons Developers List > Betreff: Re: AW: AW: [proposal] avoiding jar version nightmares > > On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata > <[EMAIL PROTECTED]> wrote: > > This may work, but does BCEL require the use of its own custom > > classloader also? > &g

Re: AW: AW: [proposal] avoiding jar version nightmares

2004-12-19 Thread Craig McClanahan
On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata <[EMAIL PROTECTED]> wrote: > This may work, but does BCEL require the use of its own custom > classloader also? > > This seems to me that this isn't just a problem with commons; it is a > problem with Java itself that .NET already has a very nice s

Re: AW: AW: [proposal] avoiding jar version nightmares

2004-12-19 Thread Craig McClanahan
On Fri, 17 Dec 2004 22:16:49 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote: > This would be really a funny thing, but how could we replace the classloader > of a given application with a custom one? > But what about a tool that decompiles all the product jars, changes the > package structure and

Re: AW: AW: [proposal] avoiding jar version nightmares

2004-12-17 Thread Martin Cooper
On Sat, 18 Dec 2004 00:15:28 +0100, Oliver Zeigermann <[EMAIL PROTECTED]> wrote: > On Fri, 17 Dec 2004 22:16:49 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote: > > This would be really a funny thing, but how could we replace the classloader > > of a given application with a custom one? > > Right.

Re: AW: AW: [proposal] avoiding jar version nightmares

2004-12-17 Thread Matt Sgarlata
This may work, but does BCEL require the use of its own custom classloader also? This seems to me that this isn't just a problem with commons; it is a problem with Java itself that .NET already has a very nice solution for. I'm wondering if this isn't something that should be taken care of at

Re: AW: [proposal] avoiding jar version nightmares

2004-12-17 Thread Oliver Zeigermann
Sounds pretty good. However, I guess the problem is you can not change the class loader implementation of WebSphere or other commercial stuff :( Oliver On Fri, 17 Dec 2004 23:16:42 +, Chris Lambrou <[EMAIL PROTECTED]> wrote: > > > Correct me if I'm wrong, but didn't Microsoft come up with s

Re: AW: [proposal] avoiding jar version nightmares

2004-12-17 Thread Chris Lambrou
Correct me if I'm wrong, but didn't Microsoft come up with some type of solution to DLL hell in Windows 2000 or XP? I seem to recall reading that a long time ago, but I'm not a Windows programmer, so I have no idea. Does anyone else know? The .NET equivalent of a jar file is called an assemb

Re: AW: AW: [proposal] avoiding jar version nightmares

2004-12-17 Thread Oliver Zeigermann
On Fri, 17 Dec 2004 22:16:49 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote: > This would be really a funny thing, but how could we replace the classloader > of a given application with a custom one? Right. Impossible :( > But what about a tool that decompiles all the product jars, changes the >

Re: AW: AW: [proposal] avoiding jar version nightmares

2004-12-17 Thread Oliver Zeigermann
PROTECTED] > > Im Auftrag von David Graham > > Gesendet: Freitag, 17. Dezember 2004 21:33 > > An: Jakarta Commons Developers List > > Betreff: Re: AW: [proposal] avoiding jar version nightmares > > > > What happens if you merge the jars for each product? For examp

AW: AW: [proposal] avoiding jar version nightmares

2004-12-17 Thread Daniel Florey
... Daniel > -Ursprüngliche Nachricht- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Im Auftrag von Oliver Zeigermann > Gesendet: Donnerstag, 16. Dezember 2004 22:44 > An: Jakarta Commons Developers List > Betreff: Re: AW: [proposal] avoiding jar version nightmare

AW: AW: [proposal] avoiding jar version nightmares

2004-12-17 Thread Daniel Florey
[mailto:[EMAIL PROTECTED] > Im Auftrag von David Graham > Gesendet: Freitag, 17. Dezember 2004 21:33 > An: Jakarta Commons Developers List > Betreff: Re: AW: [proposal] avoiding jar version nightmares > > What happens if you merge the jars for each product? For example, put >

Re: AW: [proposal] avoiding jar version nightmares

2004-12-17 Thread David Graham
What happens if you merge the jars for each product? For example, put commons 1.x files into productA.jar and commons 2.x files into productB.jar. David --- Daniel Florey <[EMAIL PROTECTED]> wrote: > So how should we handle situations where two versions of the same > component > need to coexist

Re: AW: [proposal] avoiding jar version nightmares

2004-12-17 Thread Matt Sgarlata
Daniel Florey wrote: > Any proposals how to solve this issue in another way? Correct me if I'm wrong, but didn't Microsoft come up with some type of solution to DLL hell in Windows 2000 or XP? I seem to recall reading that a long time ago, but I'm not a Windows programmer, so I have no idea. D

AW: [proposal] avoiding jar version nightmares

2004-12-17 Thread Daniel Florey
So how should we handle situations where two versions of the same component need to coexist? If I have to integrate two commercial projects where each one uses a different major version of the same component, how can I achieve this? There is no chance to force them to up- or downgrade to the versio

RE: AW: [proposal] avoiding jar version nightmares

2004-12-16 Thread Gary Gregory
Packages look like com.some_domain.org.apache.xerces... gg -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Thursday, December 16, 2004 1:44 PM To: Jakarta Commons Developers List Subject: Re: AW: [proposal] avoiding jar version nightmares On Thu, 16 Dec 2004

Re: AW: [proposal] avoiding jar version nightmares

2004-12-16 Thread Oliver Zeigermann
On Thu, 16 Dec 2004 19:09:54 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote: > So I think we need a solution for this problem. My proposal would be to > allow different major versions of commons components to coexist. If the > class and package names are equal, this is not possible. My package-vers

AW: [proposal] avoiding jar version nightmares

2004-12-16 Thread Daniel Florey
In the project that I've been working on, I had to put together some subprojects into the same ear. As these subprojects interact directly, they needed to share the same classloader. They used different versions of httpclient, collections and jdom (this one caused the most trouble...) and it was ha