You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Daniel Florey <da...@web.de> on 2004/12/16 16:03:58 UTC
[proposal] avoiding jar version nightmares
Hi all,
As commons components gain more and more attention you'll find a lot
components in larger java based projects. This can cause much trouble when
subprojects use different incompatible versions of the same component.
I was faced with this problem in the project I'm currently working on and
thought about how to avoid situations like these.
So this is my proposal:
- All versions of a component using the same main version number must be
upwards compatible: Methods in component-1.x must not change in semantic or
syntax compared to component-1.y where x < y. Methods can be marked as
deprecated but must still work in the same way.
- When incompatible api changes or semantic changes of existing methods will
be introduced, a new major version number must indicate this. To ensure that
different versions of the same component can be used by a single
application, the package name must change as well.
Example:
org.apache.commons.component-1 contains the 1.x source code of the
compoenent
org.apache.commons.component-2 contains the 2.x sources
Both versions of the component can be used simultaneous and situations
described at the beginning of this post can be handled.
Disadvantage: When upgrading a project from component-1.x to component-2.x
all includes must be updated.
But the fact that many (even commercial products) ship without indicating by
jar-extension which version of a component is used, this can avoid a lot of
headaches.
What do you think of this approach?
Regards,
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: AW: AW: AW: [proposal] avoiding jar version nightmares
Posted by Oliver Zeigermann <ol...@gmail.com>.
On Sun, 19 Dec 2004 23:17:55 -0000, Stephen Colebourne
<sc...@btopenworld.com> 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 would
> not have changed package from 2 to 3 because as far as I was concerned at
> that time it WAS fully compatible. Only later did we find one constant that
> wasn't.
Yes, shit happens, nothing you can do. But when you already know and
plan that versions are imcompatible there should be something you can
do.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: AW: AW: AW: [proposal] avoiding jar version nightmares
Posted by Stephen Colebourne <sc...@btopenworld.com>.
> 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 the unplanned ones,
like with collections. Your proposal is to change package with each
incompatible new release. Well, applying that 'rule' to collections, I would
not have changed package from 2 to 3 because as far as I was concerned at
that time it WAS fully compatible. Only later did we find one constant that
wasn't.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: AW: AW: AW: AW: [proposal] avoiding jar version nightmares
Posted by David Graham <gr...@yahoo.com>.
--- Matt Sgarlata <sg...@users.sourceforge.net> wrote:
> David Graham wrote:
> > --- Daniel Florey <da...@web.de> 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 the jar.
> >
> >
> > The version may be listed in the manifest file.
>
> This is really pushing the limits of my classloading knowledge, but
> doesn't the Manifest just say which version you need to run? If two
> incompatible versions are specified by two different JARs, then you're
> still up a creek, right? If I understand this correctly, all the
> Manifest can do is make your application puke on startup instead of
> puking at runtime. It doesn't solve the problem of running two versions
>
> of a class at the same time.
>
I've never used the version as anything other than a helpful marker so I
can look at what version of my software is in use. So, I don't know if
any apps or the JVM enforce versioning as you describe.
David
> >
> >
> >>Daniel
> >>
> >
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Jazz up your holiday email with celebrity designs. Learn more.
> > http://celebrity.mail.yahoo.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: AW: AW: AW: AW: [proposal] avoiding jar version nightmares
Posted by Matt Sgarlata <sg...@users.sourceforge.net>.
David Graham wrote:
> --- Daniel Florey <da...@web.de> 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 the jar.
>
>
> The version may be listed in the manifest file.
This is really pushing the limits of my classloading knowledge, but
doesn't the Manifest just say which version you need to run? If two
incompatible versions are specified by two different JARs, then you're
still up a creek, right? If I understand this correctly, all the
Manifest can do is make your application puke on startup instead of
puking at runtime. It doesn't solve the problem of running two versions
of a class at the same time.
> David
>
>
>>Daniel
>>
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Jazz up your holiday email with celebrity designs. Learn more.
> http://celebrity.mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: AW: AW: AW: AW: [proposal] avoiding jar version nightmares
Posted by David Graham <gr...@yahoo.com>.
--- Daniel Florey <da...@web.de> 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 the jar.
The version may be listed in the manifest file.
David
>
> Daniel
>
__________________________________
Do you Yahoo!?
Jazz up your holiday email with celebrity designs. Learn more.
http://celebrity.mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
AW: AW: AW: AW: [proposal] avoiding jar version nightmares
Posted by Daniel Florey <da...@web.de>.
> -----Ursprüngliche Nachricht-----
> Von: commons-dev-return-64747-daniel.florey=web.de@jakarta.apache.org
> [mailto:commons-dev-return-64747-daniel.florey=web.de@jakarta.apache.org]
> Im Auftrag von Craig McClanahan
> Gesendet: Sonntag, 19. Dezember 2004 23:34
> An: ozeigermann@apache.org
> Cc: Jakarta Commons Developers List
> Betreff: Re: AW: AW: AW: [proposal] avoiding jar version nightmares
>
> On Sun, 19 Dec 2004 23:24:52 +0100, Oliver Zeigermann
> <ol...@gmail.com> 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.
> > Semantics could have chages. Consider collections from 2. to 3. What
> > was done there was perfectly alright.
>
> Collections was indeed perfectly alright to make
> backwards-incompatible changes between versions 2 and 3. However, you
> should also note that these changes were *not* universal -- for a very
> large number of classes, the calling sequences *are* backwards
> compatible.
>
> Now, let's assume that Collections had implemented the "package name
> includes major version" rule. If I had restricted myself to the
> (quite large) subset where there was no real change, I would have been
> *incredibly* irritated at having to change package names in *my*
> application's imports -- just because you gratuitously changed the
> package name (and therefore made *all* APIs backward incompatible).
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.
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 the jar.
Daniel
>
> Craig
>
> ---------------------------------------------------------------------
> 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: AW: AW: AW: [proposal] avoiding jar version nightmares
Posted by Craig McClanahan <cr...@gmail.com>.
On Sun, 19 Dec 2004 23:24:52 +0100, Oliver Zeigermann
<ol...@gmail.com> 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.
> Semantics could have chages. Consider collections from 2. to 3. What
> was done there was perfectly alright.
Collections was indeed perfectly alright to make
backwards-incompatible changes between versions 2 and 3. However, you
should also note that these changes were *not* universal -- for a very
large number of classes, the calling sequences *are* backwards
compatible.
Now, let's assume that Collections had implemented the "package name
includes major version" rule. If I had restricted myself to the
(quite large) subset where there was no real change, I would have been
*incredibly* irritated at having to change package names in *my*
application's imports -- just because you gratuitously changed the
package name (and therefore made *all* APIs backward incompatible).
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: AW: AW: AW: [proposal] avoiding jar version nightmares
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Daniel Florey" <da...@web.de>
> 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 semantics of a
class/method (deliberately), to such a degree that it was backwards
incompatible, I would have to create a new class/method with a different
name.
In collections 3, it so happened that I used a new package, but that was
because the GOAL of the release in many ways was to break up a monolith into
smaller easier to understand packages. ie. the packages didn't result from
semantic changes, but they did enable them - the package restructure came
first.
Other projects will vary, beanutils/logging/betwixt/digester are all
thinking of incompatible v2s, and I can't comment on them. Another package
may be the appropriate solution for a particular commons component, however
a blanket rule doesn't work for me, nor does including the version number.
If you create a package it should describe its purpose.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
AW: AW: AW: AW: [proposal] avoiding jar version nightmares
Posted by Daniel Florey <da...@web.de>.
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 prefer to find a common way to handle this. I think it would not be
the best solution if every component is dealing with this issue in its own
way.
Cheers,
Daniel
> -----Ursprüngliche Nachricht-----
> Von: commons-dev-return-64755-daniel.florey=web.de@jakarta.apache.org
> [mailto:commons-dev-return-64755-daniel.florey=web.de@jakarta.apache.org]
> Im Auftrag von Oliver Zeigermann
> 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 -0000, Stephen Colebourne
> <sc...@btopenworld.com> 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.
> > > Semantics could have chages. Consider collections from 2. to 3. What
> > > was done there was perfectly alright.
> >
> > If by this you are suggesting that [collections] 2 and 3 were designed
> to be
> > incompatible then you are wrong. [collections] v3 'moved' classes to new
> > packages, but _left_the_old_ones_deprecated_.
>
> Thanks for clarifying. Did not know the old ones co-existed.
>
> > Some months later I discovered an unintended incompatability in
> > IteratorUtils.EMPTY_ITERATOR, which can be solved by migrating to the
> > 2.1.1/3.1 combination of versions.
> >
> > My point is that they were desinged to be compatible from 2 to 3.
>
> Isn't this almost like having an internal vesioning like Daniel suggested?
>
> Oliver
>
> ---------------------------------------------------------------------
> 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: AW: AW: AW: [proposal] avoiding jar version nightmares
Posted by Oliver Zeigermann <ol...@gmail.com>.
On Sun, 19 Dec 2004 22:46:26 -0000, Stephen Colebourne
<sc...@btopenworld.com> 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.
> > Semantics could have chages. Consider collections from 2. to 3. What
> > was done there was perfectly alright.
>
> If by this you are suggesting that [collections] 2 and 3 were designed to be
> incompatible then you are wrong. [collections] v3 'moved' classes to new
> packages, but _left_the_old_ones_deprecated_.
Thanks for clarifying. Did not know the old ones co-existed.
> Some months later I discovered an unintended incompatability in
> IteratorUtils.EMPTY_ITERATOR, which can be solved by migrating to the
> 2.1.1/3.1 combination of versions.
>
> My point is that they were desinged to be compatible from 2 to 3.
Isn't this almost like having an internal vesioning like Daniel suggested?
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
AW: AW: AW: AW: [proposal] avoiding jar version nightmares
Posted by Daniel Florey <da...@web.de>.
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 versioned package names would be the only way
(beside renaming the component ;-) to solve this issue. Or have I missed
something?
Cheers,
Daniel
> -----Ursprüngliche Nachricht-----
> Von: commons-dev-return-64752-daniel.florey=web.de@jakarta.apache.org
> [mailto:commons-dev-return-64752-daniel.florey=web.de@jakarta.apache.org]
> Im Auftrag von Stephen Colebourne
> Gesendet: Sonntag, 19. Dezember 2004 23:46
> An: Jakarta Commons Developers List; ozeigermann@apache.org
> 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 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 perfectly alright.
>
> If by this you are suggesting that [collections] 2 and 3 were designed to
> be
> incompatible then you are wrong. [collections] v3 'moved' classes to new
> packages, but _left_the_old_ones_deprecated_.
>
> Some months later I discovered an unintended incompatability in
> IteratorUtils.EMPTY_ITERATOR, which can be solved by migrating to the
> 2.1.1/3.1 combination of versions.
>
> My point is that they were desinged to be compatible from 2 to 3.
>
> Stephen
>
>
>
> ---------------------------------------------------------------------
> 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: AW: AW: AW: [proposal] avoiding jar version nightmares
Posted by Stephen Colebourne <sc...@btopenworld.com>.
> 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 perfectly alright.
If by this you are suggesting that [collections] 2 and 3 were designed to be
incompatible then you are wrong. [collections] v3 'moved' classes to new
packages, but _left_the_old_ones_deprecated_.
Some months later I discovered an unintended incompatability in
IteratorUtils.EMPTY_ITERATOR, which can be solved by migrating to the
2.1.1/3.1 combination of versions.
My point is that they were desinged to be compatible from 2 to 3.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: AW: AW: AW: [proposal] avoiding jar version nightmares
Posted by Oliver Zeigermann <ol...@gmail.com>.
On Sun, 19 Dec 2004 14:06:40 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> On Sun, 19 Dec 2004 22:52:48 +0100, Daniel Florey <da...@web.de> 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 classloaders *within* your
> application, and load the conflicting portions into their own class
> loaders (i.e. instead of loading them from /WEB-INF/classes or
> /WEB-INF/lib).
This does not work when you rely on software you can not change.
> > 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 on people who don't have the
> cross-dependency issue, but just want to use a newer version of a
> particular library that *does* maintain backwards compatibilty across
> versions. Therefore, I'd -1 such a proposal on any Commons package
> that I'm involved with.
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 perfectly alright.
I am +1 for all components I am involved with.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: AW: AW: AW: AW: [proposal] avoiding jar version nightmares
Posted by Craig McClanahan <cr...@gmail.com>.
On Sun, 19 Dec 2004 23:51:06 +0100, Daniel Florey <da...@web.de> 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 to make this work (for users with average java knowledge)?
> This is a simple example, but I could give you many others where libraries
> depend on each other and need to share the same classloader. So your
> proposal won't work.
Making this accessible to a Java developer with "average" knowledge
sounds like something a good commons package could deal with :-). But
the basic outline of setting up the class loaders would go something
like this (the key class is java.net.URLClassLoader):
// First, set up URLs for the dependencies of library A (easiest might
// be to use "file:" URLs to the JAR files in a directory or something)
URL urlsA[] = ... list of URLs for library A and its dependencies ...
// Next, get a reference to the webapp class loader
ClassLoader parentA = Thread.currentThread().getContextClassLoader();
// Now, create a new child class loader for library A, making
// it a child of the webapp class loader so classes within the
// library can see everything in your webapp
ClassLoader clA = new URLClassLoader(urlsA, parentA);
and the same sort of thing for library B. (NOTE - you'll need to add
some appropriate exception handling in these code examples ... they
are just an outline)
Now, the trick is gaining access to objects provided by those
libraries ... you can't just say "new Foo()" -- for an instance of
class Foo from library A -- any more because that will only search in
the webapp's class loader. Instead, you need something like:
Class fooClass = clA.loadClass("com.libraryA.Foo");
Foo instance = (Foo) fooClass.newInstance();
You'd probably be well served to set up convenience factory methods
for this sort of stuff if you need to do it a lot.
>
> Daniel
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
AW: AW: AW: AW: [proposal] avoiding jar version nightmares
Posted by Daniel Florey <da...@web.de>.
> -----Ursprüngliche Nachricht-----
> Von: commons-dev-return-64746-daniel.florey=web.de@jakarta.apache.org
> [mailto:commons-dev-return-64746-daniel.florey=web.de@jakarta.apache.org]
> Im Auftrag von Craig McClanahan
> Gesendet: Sonntag, 19. Dezember 2004 23:28
> An: Jakarta Commons Developers List; ozeigermann@apache.org
> Betreff: Re: AW: AW: AW: [proposal] avoiding jar version nightmares
>
> On Sun, 19 Dec 2004 23:25:30 +0100, Oliver Zeigermann
> <ol...@gmail.com> wrote:
> > On Sun, 19 Dec 2004 22:17:10 -0000, Stephen Colebourne
> > <sc...@btopenworld.com> wrote:
> > > I would also -1. Versioned packages is not an acceptable solution.
> >
> > What is an acceptable solution then?
>
> Do what I said already ... create subordinate class loaders *within*
> your application, and load the offending subordinate modules into
> their own class loaders, with their own dependencies.
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 to make this work (for users with average java knowledge)?
This is a simple example, but I could give you many others where libraries
depend on each other and need to share the same classloader. So your
proposal won't work.
Daniel
>
> >
> > Oliver
> >
>
> Craig
>
> ---------------------------------------------------------------------
> 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: AW: AW: AW: [proposal] avoiding jar version nightmares
Posted by Eric Pugh <ep...@upstate.com>.
I have to jump into this as well. I hope I am not just repeating what wiser
minds have already said :-). The idea of changing package names just seems
like a solution that looks simple, but will rapidly become a nightmare. As
far as I know, no other set of libraries follow this pattern, including the
Java libraries, and I think this suggests that doing this isn't wise.
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.
Additionally, people will soon start writing tools similar to
commons-logging that attempt to put a facade over all the versions so you
don't have to know which version you are working with.
I understand why it is a problem, but it seems like a better solution is to
pressure app vendors to upgrade faster (by using tools like Gump that
demonstrate the newer versions are solid against many packages) as well as
implement classloader isolation.
Eric
> -----Original Message-----
> From: Craig McClanahan [mailto:craigmcc@gmail.com]
> Sent: Sunday, December 19, 2004 5:28 PM
> To: Jakarta Commons Developers List; ozeigermann@apache.org
> Subject: Re: AW: AW: AW: [proposal] avoiding jar version nightmares
>
>
> On Sun, 19 Dec 2004 23:25:30 +0100, Oliver Zeigermann
> <ol...@gmail.com> wrote:
> > On Sun, 19 Dec 2004 22:17:10 -0000, Stephen Colebourne
> > <sc...@btopenworld.com> wrote:
> > > I would also -1. Versioned packages is not an acceptable solution.
> >
> > What is an acceptable solution then?
>
> Do what I said already ... create subordinate class loaders *within*
> your application, and load the offending subordinate modules into
> their own class loaders, with their own dependencies.
>
> >
> > Oliver
> >
>
> Craig
>
> ---------------------------------------------------------------------
> 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: AW: AW: AW: [proposal] avoiding jar version nightmares
Posted by Craig McClanahan <cr...@gmail.com>.
On Sun, 19 Dec 2004 23:25:30 +0100, Oliver Zeigermann
<ol...@gmail.com> wrote:
> On Sun, 19 Dec 2004 22:17:10 -0000, Stephen Colebourne
> <sc...@btopenworld.com> wrote:
> > I would also -1. Versioned packages is not an acceptable solution.
>
> What is an acceptable solution then?
Do what I said already ... create subordinate class loaders *within*
your application, and load the offending subordinate modules into
their own class loaders, with their own dependencies.
>
> Oliver
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: AW: AW: AW: [proposal] avoiding jar version nightmares
Posted by Oliver Zeigermann <ol...@gmail.com>.
On Sun, 19 Dec 2004 22:17:10 -0000, Stephen Colebourne
<sc...@btopenworld.com> wrote:
> I would also -1. Versioned packages is not an acceptable solution.
What is an acceptable solution then?
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: AW: AW: AW: [proposal] avoiding jar version nightmares
Posted by Stephen Colebourne <sc...@btopenworld.com>.
>> 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 on people who don't have the
> cross-dependency issue, but just want to use a newer version of a
> particular library that *does* maintain backwards compatibilty across
> versions. Therefore, I'd -1 such a proposal on any Commons package
> that I'm involved with.
I would also -1. Versioned packages is not an acceptable solution.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: AW: AW: AW: [proposal] avoiding jar version nightmares
Posted by Craig McClanahan <cr...@gmail.com>.
On Sun, 19 Dec 2004 22:52:48 +0100, Daniel Florey <da...@web.de> 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 classloaders *within* your
application, and load the conflicting portions into their own class
loaders (i.e. instead of loading them from /WEB-INF/classes or
/WEB-INF/lib).
> 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 on people who don't have the
cross-dependency issue, but just want to use a newer version of a
particular library that *does* maintain backwards compatibilty across
versions. Therefore, I'd -1 such a proposal on any Commons package
that I'm involved with.
> Cheers,
> Daniel
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: AW: AW: [proposal] avoiding jar version nightmares
Posted by Craig McClanahan <cr...@gmail.com>.
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 should examine the manifest of the
applet itself (or the WAR in the case of a webapp) and reject
execution if the specified versions of the declared dependencies are
not present. But nothing stops a container from doing more with this
info (see below for one idea).
What's missing today at the *language* level is the ability to load
incompatible versions into the same class loader. That would take
language and JVM architecture changes -- if that's important to you,
go find the threads on ServerSide or JavaLobby about providing
feedback to the requirements for Mustang (JDK 1.6), since that's the
earliest time we could actually get it into the language itself.
In the mean time, nothing stops a servlet container provider from
assembling dynamically an appropriate parent class loader that
contains just the specified dependencies (instead of, or in addition
to, the kind of thing that Tomcat does with its "shared" and "common"
class loaders). That way, one could provide webapp A with version 1
of the library, and webapp B with version 2 of the same library, which
is pretty much equivalent to what you describe for .NET. Seems like a
good RFE for Tomcat ...
However, this won't solve the "two incompatible versions in the same
webapp" use case -- for that, you'll still need to use child class
loaders. It sounds like this would also be true in the .NET
environment???
Craig
On Sun, 19 Dec 2004 18:37:43 -0500, Matt Sgarlata
<sg...@users.sourceforge.net> wrote:
> Craig McClanahan wrote:
> > On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata
> > <sg...@users.sourceforge.net> 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
> > the direction that J2SE is going from a Sun perspective), talking
> > about the very issue of class loaders and the contortions that you
> > have to go through in order to implement things like webapp reloading.
> > I asked him for a Christmas present to all Java developers -- add
> > something like ClassLoader.unloadClass() or ClassLoader.replaceClass()
> > to deal with things like this. He said "hmm ... that's a hard
> > problem" and proceeded to describe several of the places where
> > implementing this would be extremely difficult (and/or would have
> > nasty performance impacts) in the current architecture of JVMs.
>
> Well what about introducing the versioned library approach that is done
> in .NET? I'm not familiar with the details myself, but Chris Lambrou
> wrote earlier:
>
> The .NET equivalent of a jar file is called an assembly. For libraries,
> this is basically a DLL. Every time the code is compiled, the DLL is
> automatically allocated a unique version number. When you compile your
> code that refers to code in a library assembly, your assembly has an
> explicit dependency on that library assembly. At runtime, when your code
> tries to invoke the library code, an exception will be raised if the
> exact version of the library assembly is not available.
>
> It would appear that if there are bug fixes or other improvements to the
> library, and a recompiled assembly DLL is substituted for the one you
> originally compiled against, then your code will break. At runtime, your
> code will fail to link to the library code, since the version number no
> longer matches. Obviously, a maintenance release of a library component
> shouldn't require a recompilation and redeployment of all software that
> uses the library, so .NET provides a mechanism for you to explicitly
> define a version number. This allows you to provide updated library
> components to users without requiring them to recompile. However, this
> only works if you don't break backwards compatibility.
>
> If you break backwards compatibility in a library, then you have to
> change the version number. However, .NET still allows you to deploy
> different, incompatible versions of the same DLL. When you deploy the
> application, your installer has to register both versions of the DLL
> with the GAC - the Global Assembly Cache. In this way, if you have a
> complex application that contains two components that rely on
> incompatible versions of the same library DLL, the VM instantiates two
> separate versions of the library DLL, and links the two components to
> the appropriate instance.
>
> One possible Java analogy to this would be to bundle all code inside jar
> archives. Each jar contains dependency information, perhaps stored in
> the manifest, or some other meta-file, that describes the jar's own name
> and version number, and a list of the names and version numbers of its
> dependencies. A suitable class loader can then use this meta information
> to stitch the classes together appropriately. Actually, my knowledge of
> java class loaders isn't sufficient for me to assert that this solution
> would definitely work, but it's a start, and I hope all of this serves
> to illustrate how .NET allows multiple versions of the same library to
> coexist.
>
>
> > Regarding the original use case in this thread (an app that wants to
> > use two modules that have conflicting versions of common
> > dependencies), about the best you can do right now is to have your
> > application create its own class loaders for the modules involved, and
> > set up their classpaths to pick up their own versions of the
> > dependencies. That is essentially what a servlet container does
> > (creates a class loader for each webapp) to maintain separation, and
> > allows each webapp to load its own version of a common dependency JAR
> > from its own "class path" ... the /WEB-INF/classes and /WEB-INF/lib
> > directories of that app.
> >
> > Craig
>
> ---------------------------------------------------------------------
> 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: AW: AW: [proposal] avoiding jar version nightmares
Posted by Matt Sgarlata <sg...@users.sourceforge.net>.
Craig McClanahan wrote:
> On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata
> <sg...@users.sourceforge.net> 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
> the direction that J2SE is going from a Sun perspective), talking
> about the very issue of class loaders and the contortions that you
> have to go through in order to implement things like webapp reloading.
> I asked him for a Christmas present to all Java developers -- add
> something like ClassLoader.unloadClass() or ClassLoader.replaceClass()
> to deal with things like this. He said "hmm ... that's a hard
> problem" and proceeded to describe several of the places where
> implementing this would be extremely difficult (and/or would have
> nasty performance impacts) in the current architecture of JVMs.
Well what about introducing the versioned library approach that is done
in .NET? I'm not familiar with the details myself, but Chris Lambrou
wrote earlier:
The .NET equivalent of a jar file is called an assembly. For libraries,
this is basically a DLL. Every time the code is compiled, the DLL is
automatically allocated a unique version number. When you compile your
code that refers to code in a library assembly, your assembly has an
explicit dependency on that library assembly. At runtime, when your code
tries to invoke the library code, an exception will be raised if the
exact version of the library assembly is not available.
It would appear that if there are bug fixes or other improvements to the
library, and a recompiled assembly DLL is substituted for the one you
originally compiled against, then your code will break. At runtime, your
code will fail to link to the library code, since the version number no
longer matches. Obviously, a maintenance release of a library component
shouldn't require a recompilation and redeployment of all software that
uses the library, so .NET provides a mechanism for you to explicitly
define a version number. This allows you to provide updated library
components to users without requiring them to recompile. However, this
only works if you don't break backwards compatibility.
If you break backwards compatibility in a library, then you have to
change the version number. However, .NET still allows you to deploy
different, incompatible versions of the same DLL. When you deploy the
application, your installer has to register both versions of the DLL
with the GAC - the Global Assembly Cache. In this way, if you have a
complex application that contains two components that rely on
incompatible versions of the same library DLL, the VM instantiates two
separate versions of the library DLL, and links the two components to
the appropriate instance.
One possible Java analogy to this would be to bundle all code inside jar
archives. Each jar contains dependency information, perhaps stored in
the manifest, or some other meta-file, that describes the jar's own name
and version number, and a list of the names and version numbers of its
dependencies. A suitable class loader can then use this meta information
to stitch the classes together appropriately. Actually, my knowledge of
java class loaders isn't sufficient for me to assert that this solution
would definitely work, but it's a start, and I hope all of this serves
to illustrate how .NET allows multiple versions of the same library to
coexist.
> Regarding the original use case in this thread (an app that wants to
> use two modules that have conflicting versions of common
> dependencies), about the best you can do right now is to have your
> application create its own class loaders for the modules involved, and
> set up their classpaths to pick up their own versions of the
> dependencies. That is essentially what a servlet container does
> (creates a class loader for each webapp) to maintain separation, and
> allows each webapp to load its own version of a common dependency JAR
> from its own "class path" ... the /WEB-INF/classes and /WEB-INF/lib
> directories of that app.
>
> Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
AW: AW: AW: [proposal] avoiding jar version nightmares
Posted by Daniel Florey <da...@web.de>.
The solution you proposed will not solve the issue as you cannot replace the
classloader of the application server.
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.
Cheers,
Daniel
> -----Ursprüngliche Nachricht-----
> Von: commons-dev-return-64738-daniel.florey=web.de@jakarta.apache.org
> [mailto:commons-dev-return-64738-daniel.florey=web.de@jakarta.apache.org]
> Im Auftrag von Craig McClanahan
> Gesendet: Sonntag, 19. Dezember 2004 22:46
> An: Jakarta Commons Developers List
> Betreff: Re: AW: AW: [proposal] avoiding jar version nightmares
>
> On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata
> <sg...@users.sourceforge.net> 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 solution for.
> > I'm wondering if this isn't something that should be taken care of at
> > the JVM level i.e. - in Java 1.6. The obvious solution seems to be that
> > we need to fix classloaders. They're already a huge nightmare in EJB
> > containers.
> >
> > 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
> the direction that J2SE is going from a Sun perspective), talking
> about the very issue of class loaders and the contortions that you
> have to go through in order to implement things like webapp reloading.
> I asked him for a Christmas present to all Java developers -- add
> something like ClassLoader.unloadClass() or ClassLoader.replaceClass()
> to deal with things like this. He said "hmm ... that's a hard
> problem" and proceeded to describe several of the places where
> implementing this would be extremely difficult (and/or would have
> nasty performance impacts) in the current architecture of JVMs.
>
> Regarding the original use case in this thread (an app that wants to
> use two modules that have conflicting versions of common
> dependencies), about the best you can do right now is to have your
> application create its own class loaders for the modules involved, and
> set up their classpaths to pick up their own versions of the
> dependencies. That is essentially what a servlet container does
> (creates a class loader for each webapp) to maintain separation, and
> allows each webapp to load its own version of a common dependency JAR
> from its own "class path" ... the /WEB-INF/classes and /WEB-INF/lib
> directories of that app.
>
> Craig
>
> ---------------------------------------------------------------------
> 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: AW: AW: [proposal] avoiding jar version nightmares
Posted by Craig McClanahan <cr...@gmail.com>.
On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata
<sg...@users.sourceforge.net> 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 solution for.
> I'm wondering if this isn't something that should be taken care of at
> the JVM level i.e. - in Java 1.6. The obvious solution seems to be that
> we need to fix classloaders. They're already a huge nightmare in EJB
> containers.
>
> 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
the direction that J2SE is going from a Sun perspective), talking
about the very issue of class loaders and the contortions that you
have to go through in order to implement things like webapp reloading.
I asked him for a Christmas present to all Java developers -- add
something like ClassLoader.unloadClass() or ClassLoader.replaceClass()
to deal with things like this. He said "hmm ... that's a hard
problem" and proceeded to describe several of the places where
implementing this would be extremely difficult (and/or would have
nasty performance impacts) in the current architecture of JVMs.
Regarding the original use case in this thread (an app that wants to
use two modules that have conflicting versions of common
dependencies), about the best you can do right now is to have your
application create its own class loaders for the modules involved, and
set up their classpaths to pick up their own versions of the
dependencies. That is essentially what a servlet container does
(creates a class loader for each webapp) to maintain separation, and
allows each webapp to load its own version of a common dependency JAR
from its own "class path" ... the /WEB-INF/classes and /WEB-INF/lib
directories of that app.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [proposal] avoiding jar version nightmares
Posted by Matt Sgarlata <sg...@users.sourceforge.net>.
Emmanuel Bourg wrote:
> Matt Sgarlata wrote:
>
>> 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 the JVM level i.e. - in Java 1.6. The obvious solution seems to
>> be that we need to fix classloaders. They're already a huge nightmare
>> in EJB containers.
>>
>> How do we go about petitioning Sun for something like this?
>
>
> Isn't the isolate API (JSR 121) supposed to address this issue ?
It looks like more information can be found here
http://www.jcp.org/en/jsr/detail?id=121
Unfortunately, I personally find the page incomprehensible. It sounds
like maybe it will address these issues, but it seems like their focus
is more on enhancing performance through multitasking than it is on
solving JAR dependency nightmares. Is there anyone that can comprehend
that page? ;)
I see in section 2.11 that the goal was to include the specification in
J2SE 1.5. I guess it didn't make it. Does that mean the spec is dead?
> Emmanuel Bourg
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [proposal] avoiding jar version nightmares
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Matt Sgarlata wrote:
> 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
> the JVM level i.e. - in Java 1.6. The obvious solution seems to be that
> we need to fix classloaders. They're already a huge nightmare in EJB
> containers.
>
> How do we go about petitioning Sun for something like this?
Isn't the isolate API (JSR 121) supposed to address this issue ?
Emmanuel Bourg
Re: AW: AW: [proposal] avoiding jar version nightmares
Posted by Matt Sgarlata <sg...@users.sourceforge.net>.
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
the JVM level i.e. - in Java 1.6. The obvious solution seems to be that
we need to fix classloaders. They're already a huge nightmare in EJB
containers.
How do we go about petitioning Sun for something like this?
Matt
Oliver Zeigermann wrote:
> On Fri, 17 Dec 2004 22:16:49 +0100, Daniel Florey <da...@web.de> 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
>>package structure and the import statements and repacks this into a new jar?
>>;-)
>>Might be a megaseller...
>
>
> No need to decompile. Libs like BCEL or ASM can do this for us. Other
> than that cool stuff :)
>
> This would need information which part of the software want which version!
> However, it would be very hard to debug if the tool had any bugs in
> it. But of course it would not ;)
>
> When is founding time for the company?
>
> Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: AW: AW: [proposal] avoiding jar version nightmares
Posted by Martin Cooper <mf...@gmail.com>.
On Sat, 18 Dec 2004 00:15:28 +0100, Oliver Zeigermann
<ol...@gmail.com> wrote:
> On Fri, 17 Dec 2004 22:16:49 +0100, Daniel Florey <da...@web.de> 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
> > package structure and the import statements and repacks this into a new jar?
> > ;-)
> > Might be a megaseller...
>
> No need to decompile. Libs like BCEL or ASM can do this for us. Other
> than that cool stuff :)
>
> This would need information which part of the software want which version!
> However, it would be very hard to debug if the tool had any bugs in
> it. But of course it would not ;)
>
> When is founding time for the company?
I think you're too late:
http://forehead.werken.com/
--
Martin Cooper
> Oliver
>
> ---------------------------------------------------------------------
> 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: AW: AW: [proposal] avoiding jar version nightmares
Posted by Oliver Zeigermann <ol...@gmail.com>.
On Fri, 17 Dec 2004 22:16:49 +0100, Daniel Florey <da...@web.de> 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
> package structure and the import statements and repacks this into a new jar?
> ;-)
> Might be a megaseller...
No need to decompile. Libs like BCEL or ASM can do this for us. Other
than that cool stuff :)
This would need information which part of the software want which version!
However, it would be very hard to debug if the tool had any bugs in
it. But of course it would not ;)
When is founding time for the company?
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: AW: AW: [proposal] avoiding jar version nightmares
Posted by Craig McClanahan <cr...@gmail.com>.
On Fri, 17 Dec 2004 22:16:49 +0100, Daniel Florey <da...@web.de> 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 the import statements and repacks this into a new jar?
> ;-)
> Might be a megaseller...
Unfortunately, even such a tool (of which there are some around) will
only solve part of the problem. Consider a package like Digester,
which loads objects based on names in your rules (rather than
importing them directly). Unless your rename process also fixed all
your Digester configurations, you'd break the application using it.
The same issue happens with pretty much any application that uses
ClassLoader.loadClass() directly -- and that covers a surprisingly
large amount of very useful code.
> Daniel
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
AW: AW: [proposal] avoiding jar version nightmares
Posted by Daniel Florey <da...@web.de>.
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 the import statements and repacks this into a new jar?
;-)
Might be a megaseller...
Daniel
> -----Ursprüngliche Nachricht-----
> Von: commons-dev-return-64484-daniel.florey=web.de@jakarta.apache.org
> [mailto:commons-dev-return-64484-daniel.florey=web.de@jakarta.apache.org]
> Im Auftrag von Oliver Zeigermann
> Gesendet: Donnerstag, 16. Dezember 2004 22:44
> An: Jakarta Commons Developers List
> Betreff: Re: AW: [proposal] avoiding jar version nightmares
>
> On Thu, 16 Dec 2004 19:09:54 +0100, Daniel Florey <da...@web.de>
> 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-
> version
> > proposal is just one idea to enable this.
>
> Some versioning class loader as it was thought of in Projector would
> really be a very elegant solution ;)
>
> Oliver
>
> ---------------------------------------------------------------------
> 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: AW: [proposal] avoiding jar version nightmares
Posted by Oliver Zeigermann <ol...@gmail.com>.
On Thu, 16 Dec 2004 19:09:54 +0100, Daniel Florey <da...@web.de> 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-version
> proposal is just one idea to enable this.
Some versioning class loader as it was thought of in Projector would
really be a very elegant solution ;)
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
AW: [proposal] avoiding jar version nightmares
Posted by Daniel Florey <da...@web.de>.
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 hard to figure out, which versions of
each component was in use and how to decompile and refactor the subprojects
to work with the same jars.
As commons components gain more and more attention, more and more commercial
products are using them. It's very common for enterprise applications that
you have to bundle different commercial packages that are not available in
source code. These packages often allow interaction with other packages by
adding some listeners, so it is not possible to deploy them in different
webapps/cassloaders.
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-version
proposal is just one idea to enable this.
Cheers,
Daniel
> -----Ursprüngliche Nachricht-----
> Von: commons-dev-return-64473-daniel.florey=web.de@jakarta.apache.org
> [mailto:commons-dev-return-64473-daniel.florey=web.de@jakarta.apache.org]
> Im Auftrag von David Graham
> Gesendet: Donnerstag, 16. Dezember 2004 18:41
> An: Jakarta Commons Developers List; ozeigermann@apache.org
> Betreff: Re: [proposal] avoiding jar version nightmares
>
> I'm still wondering what commons components caused you guys problems in
> your project? Why should all projects change to renaming packages and
> causing confusion if it's just a few projects that are causing problems?
> My guess is that it's commons collections that is giving you headaches but
> I would like to hear the real world example.
>
> Thanks,
> David
>
> --- Oliver Zeigermann <ol...@gmail.com> wrote:
>
> > On Thu, 16 Dec 2004 09:09:11 -0800 (PST), David Graham
> > <gr...@yahoo.com> wrote:
> > > The only time I've seen versioning problems is when commons components
> > > depend on each other and one of them breaks backwards compatibility
> > like
> > > commons collections did recectly. This is why it's so important for
> > > commons components to have minimal dependencies.
> >
> > Just think of a 1.x version and a 2.x version having the same package
> > and class names, but different method sets or even different
> > semantics. Now in a large project a piece of software from one vendor
> > needs 1.x and another one needs 2.x. Now consider they really need to
> > share the same class loader and you are lost. You would not if you
> > could have both 1.x and 2.x usable at the same time. Daniel's proposal
> > would make this possible.
> >
> > Oliver
> >
> > Disclaimer: Daniel talked this over with me in person yesterday, so
> > our points of view are pretty much aligned.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> 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: [proposal] avoiding jar version nightmares
Posted by David Graham <gr...@yahoo.com>.
I'm still wondering what commons components caused you guys problems in
your project? Why should all projects change to renaming packages and
causing confusion if it's just a few projects that are causing problems?
My guess is that it's commons collections that is giving you headaches but
I would like to hear the real world example.
Thanks,
David
--- Oliver Zeigermann <ol...@gmail.com> wrote:
> On Thu, 16 Dec 2004 09:09:11 -0800 (PST), David Graham
> <gr...@yahoo.com> wrote:
> > The only time I've seen versioning problems is when commons components
> > depend on each other and one of them breaks backwards compatibility
> like
> > commons collections did recectly. This is why it's so important for
> > commons components to have minimal dependencies.
>
> Just think of a 1.x version and a 2.x version having the same package
> and class names, but different method sets or even different
> semantics. Now in a large project a piece of software from one vendor
> needs 1.x and another one needs 2.x. Now consider they really need to
> share the same class loader and you are lost. You would not if you
> could have both 1.x and 2.x usable at the same time. Daniel's proposal
> would make this possible.
>
> Oliver
>
> Disclaimer: Daniel talked this over with me in person yesterday, so
> our points of view are pretty much aligned.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [proposal] avoiding jar version nightmares
Posted by Oliver Zeigermann <ol...@gmail.com>.
On Thu, 16 Dec 2004 09:09:11 -0800 (PST), David Graham
<gr...@yahoo.com> wrote:
> The only time I've seen versioning problems is when commons components
> depend on each other and one of them breaks backwards compatibility like
> commons collections did recectly. This is why it's so important for
> commons components to have minimal dependencies.
Just think of a 1.x version and a 2.x version having the same package
and class names, but different method sets or even different
semantics. Now in a large project a piece of software from one vendor
needs 1.x and another one needs 2.x. Now consider they really need to
share the same class loader and you are lost. You would not if you
could have both 1.x and 2.x usable at the same time. Daniel's proposal
would make this possible.
Oliver
Disclaimer: Daniel talked this over with me in person yesterday, so
our points of view are pretty much aligned.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [proposal] avoiding jar version nightmares
Posted by Oliver Zeigermann <ol...@gmail.com>.
On Fri, 17 Dec 2004 00:43:55 -0000, Stephen Colebourne
<sc...@btopenworld.com> wrote:
> Basically, I believe there is no simple solution to this. The best we can do
> is to encourage tools like clirr which check a library for binary
> compatability. This should become part of each components standard tests.
I am sure clirr is a nice tool, but the knowledge that 1.x is
incompatible with 2.0 is of no big use when you have both in your
classpath.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: AW: [proposal] avoiding jar version nightmares
Posted by Oliver Zeigermann <ol...@gmail.com>.
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 +0000, Chris Lambrou <ma...@chrislambrou.com> wrote:
>
> > 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 assembly. For libraries,
> this is basically a DLL. Every time the code is compiled, the DLL is
> automatically allocated a unique version number. When you compile your
> code that refers to code in a library assembly, your assembly has an
> explicit dependency on that library assembly. At runtime, when your code
> tries to invoke the library code, an exception will be raised if the
> exact version of the library assembly is not available.
>
> It would appear that if there are bug fixes or other improvements to the
> library, and a recompiled assembly DLL is substituted for the one you
> originally compiled against, then your code will break. At runtime, your
> code will fail to link to the library code, since the version number no
> longer matches. Obviously, a maintenance release of a library component
> shouldn't require a recompilation and redeployment of all software that
> uses the library, so .NET provides a mechanism for you to explicitly
> define a version number. This allows you to provide updated library
> components to users without requiring them to recompile. However, this
> only works if you don't break backwards compatibility.
>
> If you break backwards compatibility in a library, then you have to
> change the version number. However, .NET still allows you to deploy
> different, incompatible versions of the same DLL. When you deploy the
> application, your installer has to register both versions of the DLL
> with the GAC - the Global Assembly Cache. In this way, if you have a
> complex application that contains two components that rely on
> incompatible versions of the same library DLL, the VM instantiates two
> separate versions of the library DLL, and links the two components to
> the appropriate instance.
>
> One possible Java analogy to this would be to bundle all code inside jar
> archives. Each jar contains dependency information, perhaps stored in
> the manifest, or some other meta-file, that describes the jar's own name
> and version number, and a list of the names and version numbers of its
> dependencies. A suitable class loader can then use this meta information
> to stitch the classes together appropriately. Actually, my knowledge of
> java class loaders isn't sufficient for me to assert that this solution
> would definitely work, but it's a start, and I hope all of this serves
> to illustrate how .NET allows multiple versions of the same library to
> coexist.
>
> Chris
>
> ---------------------------------------------------------------------
> 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: AW: [proposal] avoiding jar version nightmares
Posted by Chris Lambrou <ma...@chrislambrou.com>.
> 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 assembly. For libraries,
this is basically a DLL. Every time the code is compiled, the DLL is
automatically allocated a unique version number. When you compile your
code that refers to code in a library assembly, your assembly has an
explicit dependency on that library assembly. At runtime, when your code
tries to invoke the library code, an exception will be raised if the
exact version of the library assembly is not available.
It would appear that if there are bug fixes or other improvements to the
library, and a recompiled assembly DLL is substituted for the one you
originally compiled against, then your code will break. At runtime, your
code will fail to link to the library code, since the version number no
longer matches. Obviously, a maintenance release of a library component
shouldn't require a recompilation and redeployment of all software that
uses the library, so .NET provides a mechanism for you to explicitly
define a version number. This allows you to provide updated library
components to users without requiring them to recompile. However, this
only works if you don't break backwards compatibility.
If you break backwards compatibility in a library, then you have to
change the version number. However, .NET still allows you to deploy
different, incompatible versions of the same DLL. When you deploy the
application, your installer has to register both versions of the DLL
with the GAC - the Global Assembly Cache. In this way, if you have a
complex application that contains two components that rely on
incompatible versions of the same library DLL, the VM instantiates two
separate versions of the library DLL, and links the two components to
the appropriate instance.
One possible Java analogy to this would be to bundle all code inside jar
archives. Each jar contains dependency information, perhaps stored in
the manifest, or some other meta-file, that describes the jar's own name
and version number, and a list of the names and version numbers of its
dependencies. A suitable class loader can then use this meta information
to stitch the classes together appropriately. Actually, my knowledge of
java class loaders isn't sufficient for me to assert that this solution
would definitely work, but it's a start, and I hope all of this serves
to illustrate how .NET allows multiple versions of the same library to
coexist.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: AW: [proposal] avoiding jar version nightmares
Posted by Matt Sgarlata <sg...@users.sourceforge.net>.
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. Does anyone else know?
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: AW: AW: [proposal] avoiding jar version nightmares
Posted by Oliver Zeigermann <ol...@gmail.com>.
I think Daniel is right. This would not change anything.
I am not quite sure the problem is yet obvious to anyone: The *same*
classloader must return two *different* versions of the *same* class
for different parts of your software which seems impossible for an
ordinary class loader unless the classes are in a different package.
That's why Daniel proposes to put imcompible class versions in
different packages.
Any better solution?
Oliver
On Fri, 17 Dec 2004 22:12:41 +0100, Daniel Florey <da...@web.de> wrote:
> Don't know. But I think the classloader will still not know which class to
> pick as the names are still identical. So it might depend on the load order
> of the jars which product will fail.
> Or did I got it wrong?
>
> Daniel
>
> > -----Ursprüngliche Nachricht-----
> > Von: commons-dev-return-64551-daniel.florey=web.de@jakarta.apache.org
> > [mailto:commons-dev-return-64551-daniel.florey=web.de@jakarta.apache.org]
> > 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
> > commons 1.x files into productA.jar and commons 2.x files into
> > productB.jar.
> >
> > David
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
AW: AW: [proposal] avoiding jar version nightmares
Posted by Daniel Florey <da...@web.de>.
Don't know. But I think the classloader will still not know which class to
pick as the names are still identical. So it might depend on the load order
of the jars which product will fail.
Or did I got it wrong?
Daniel
> -----Ursprüngliche Nachricht-----
> Von: commons-dev-return-64551-daniel.florey=web.de@jakarta.apache.org
> [mailto:commons-dev-return-64551-daniel.florey=web.de@jakarta.apache.org]
> 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
> commons 1.x files into productA.jar and commons 2.x files into
> productB.jar.
>
> David
>
> --- Daniel Florey <da...@web.de> wrote:
>
> > 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 version of the
> > other
> > product. In situations like these you are absolutely lost, aren't you?
> > So my proposal was about to avoid this horrible situation. Any proposals
> > how
> > to solve this issue in another way?
> > Or is this list not the right place for discussing stuff like this?
> >
> > Cheers,
> > Daniel
> >
> >
> > > -----Urspr|ngliche Nachricht-----
> > > Von: commons-dev-return-64503-daniel.florey=web.de@jakarta.apache.org
> > >
> >
> [mailto:commons-dev-return-64503-daniel.florey=web.de@jakarta.apache.org]
> > > Im Auftrag von David Graham
> > > Gesendet: Freitag, 17. Dezember 2004 02:26
> > > An: Jakarta Commons Developers List
> > > Betreff: Re: [proposal] avoiding jar version nightmares
> > >
> > > Struts uses the deprecation cycle I described and so did the commons
> > > components spawned from Struts the last I knew (validator certainly
> > still
> > > uses the described cycle). A 1.x series is backwards compatible but
> > > deprecated methods may be removed after they have been deprecated for
> > at
> > > least one point release. A jump to 2.x means, among other things,
> > there
> > > are backwards incompatible changes without a deprecation cycle.
> > >
> > > This approach obviously varies by project.
> > >
> > > David
> > >
> > > --- Stephen Colebourne <sc...@btopenworld.com> wrote:
> > >
> > > > Commons has always followed a longer deprecation cycle than
> > described
> > > > below.
> > > > A method deprecated in 1.1, 1.2, 1.3 cannot be removed until 2.0.
> > > >
> > > > 1.1 -> 1.2 -> 1.3 should all be easy compatible changes.
> > > >
> > > > 1.1/1.2 -> 2.0 may cause issues.
> > > >
> > > > In collections we faced a peculiar compatability problem in that a
> > > > constant
> > > > was in both 2.1 and 3.0 but was declared as a different type (by
> > error).
> > > >
> > > > This caused major hassle as it wasn't spotted quickly. (Use 2.1.1 or
> > 3.1
> > > > to
> > > > get around the problem).
> > > >
> > > > Personally, I believe that a different package name for each version
> > is
> > > > overly restricting. Most users will just recompile their code for
> > the
> > > > new
> > > > version and it will just work. Plus, having the same class in two
> > > > different
> > > > packages will be very confusing when using an IDE. This would be
> > > > especially
> > > > true if someone obtains an object from one version and then tries to
> > > > pass it
> > > > to an object of another version.
> > > >
> > > > Also, since human error can be a factor, we would have to version
> > every
> > > > release, minor or major to actually make the system foolproof.
> > > >
> > > > Basically, I believe there is no simple solution to this. The best
> > we
> > > > can do
> > > > is to encourage tools like clirr which check a library for binary
> > > > compatability. This should become part of each components standard
> > > > tests.
> > > >
> > > > Stephen
> > > >
> > > > ----- Original Message -----
> > > > From: "David Graham" <gr...@yahoo.com>
> > > > > All the jakarta projects I've worked on have a deprecation cycle
> > of
> > > > one
> > > > > minor point release. For example, you deprecate a method for the
> > 1.1
> > > > > release and can remove it for the 1.2 release. This gives users
> > time
> > > > to
> > > > > see the deprecation warning and update their code appropriately.
> > IMO,
> > > > > requiring a package name change is overly restrictive and
> > confusing to
> > > > > users.
> > > > >
> > > > > The only time I've seen versioning problems is when commons
> > components
> > > > > depend on each other and one of them breaks backwards
> > compatibility
> > > > like
> > > > > commons collections did recectly. This is why it's so important
> > for
> > > > > commons components to have minimal dependencies.
> > > > >
> > > > > What commons components caused your project problems?
> > > > >
> > > > > David
> > > > >
> > > > >
> > > > > --- Daniel Florey <da...@web.de> wrote:
> > > > >
> > > > >> Hi all,
> > > > >> As commons components gain more and more attention you'll find a
> > lot
> > > > >> components in larger java based projects. This can cause much
> > trouble
> > > > >> when
> > > > >> subprojects use different incompatible versions of the same
> > > > component.
> > > > >> I was faced with this problem in the project I'm currently
> > working on
> > > > >> and
> > > > >> thought about how to avoid situations like these.
> > > > >> So this is my proposal:
> > > > >> - All versions of a component using the same main version number
> > must
> > > > be
> > > > >> upwards compatible: Methods in component-1.x must not change in
> > > > semantic
> > > > >> or
> > > > >> syntax compared to component-1.y where x < y. Methods can be
> > marked
> > > > as
> > > > >> deprecated but must still work in the same way.
> > > > >> - When incompatible api changes or semantic changes of existing
> > > > methods
> > > > >> will
> > > > >> be introduced, a new major version number must indicate this. To
> > > > ensure
> > > > >> that
> > > > >> different versions of the same component can be used by a single
> > > > >> application, the package name must change as well.
> > > > >> Example:
> > > > >> org.apache.commons.component-1 contains the 1.x source code of
> > the
> > > > >> compoenent
> > > > >> org.apache.commons.component-2 contains the 2.x sources
> > > > >>
> > > > >> Both versions of the component can be used simultaneous and
> > > > situations
> > > > >> described at the beginning of this post can be handled.
> > > > >> Disadvantage: When upgrading a project from component-1.x to
> > > > >> component-2.x
> > > > >> all includes must be updated.
> > > > >> But the fact that many (even commercial products) ship without
> > > > >> indicating by
> > > > >> jar-extension which version of a component is used, this can
> > avoid a
> > > > lot
> > > > >> of
> > > > >> headaches.
> > > > >> What do you think of this approach?
> > > > >>
> > > > >> Regards,
> > > > >> Daniel
> > > > >>
> > > > >>
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail:
> > commons-dev-unsubscribe@jakarta.apache.org
> > > > >> For additional commands, e-mail:
> > commons-dev-help@jakarta.apache.org
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > > __________________________________________________
> > > > > Do You Yahoo!?
> > > > > Tired of spam? Yahoo! Mail has the best spam protection around
> > > > > http://mail.yahoo.com
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> > commons-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> >
> === message truncated ===
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> 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: AW: [proposal] avoiding jar version nightmares
Posted by David Graham <gr...@yahoo.com>.
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 <da...@web.de> wrote:
> 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 version of the
> other
> product. In situations like these you are absolutely lost, aren't you?
> So my proposal was about to avoid this horrible situation. Any proposals
> how
> to solve this issue in another way?
> Or is this list not the right place for discussing stuff like this?
>
> Cheers,
> Daniel
>
>
> > -----Urspr�ngliche Nachricht-----
> > Von: commons-dev-return-64503-daniel.florey=web.de@jakarta.apache.org
> >
>
[mailto:commons-dev-return-64503-daniel.florey=web.de@jakarta.apache.org]
> > Im Auftrag von David Graham
> > Gesendet: Freitag, 17. Dezember 2004 02:26
> > An: Jakarta Commons Developers List
> > Betreff: Re: [proposal] avoiding jar version nightmares
> >
> > Struts uses the deprecation cycle I described and so did the commons
> > components spawned from Struts the last I knew (validator certainly
> still
> > uses the described cycle). A 1.x series is backwards compatible but
> > deprecated methods may be removed after they have been deprecated for
> at
> > least one point release. A jump to 2.x means, among other things,
> there
> > are backwards incompatible changes without a deprecation cycle.
> >
> > This approach obviously varies by project.
> >
> > David
> >
> > --- Stephen Colebourne <sc...@btopenworld.com> wrote:
> >
> > > Commons has always followed a longer deprecation cycle than
> described
> > > below.
> > > A method deprecated in 1.1, 1.2, 1.3 cannot be removed until 2.0.
> > >
> > > 1.1 -> 1.2 -> 1.3 should all be easy compatible changes.
> > >
> > > 1.1/1.2 -> 2.0 may cause issues.
> > >
> > > In collections we faced a peculiar compatability problem in that a
> > > constant
> > > was in both 2.1 and 3.0 but was declared as a different type (by
> error).
> > >
> > > This caused major hassle as it wasn't spotted quickly. (Use 2.1.1 or
> 3.1
> > > to
> > > get around the problem).
> > >
> > > Personally, I believe that a different package name for each version
> is
> > > overly restricting. Most users will just recompile their code for
> the
> > > new
> > > version and it will just work. Plus, having the same class in two
> > > different
> > > packages will be very confusing when using an IDE. This would be
> > > especially
> > > true if someone obtains an object from one version and then tries to
> > > pass it
> > > to an object of another version.
> > >
> > > Also, since human error can be a factor, we would have to version
> every
> > > release, minor or major to actually make the system foolproof.
> > >
> > > Basically, I believe there is no simple solution to this. The best
> we
> > > can do
> > > is to encourage tools like clirr which check a library for binary
> > > compatability. This should become part of each components standard
> > > tests.
> > >
> > > Stephen
> > >
> > > ----- Original Message -----
> > > From: "David Graham" <gr...@yahoo.com>
> > > > All the jakarta projects I've worked on have a deprecation cycle
> of
> > > one
> > > > minor point release. For example, you deprecate a method for the
> 1.1
> > > > release and can remove it for the 1.2 release. This gives users
> time
> > > to
> > > > see the deprecation warning and update their code appropriately.
> IMO,
> > > > requiring a package name change is overly restrictive and
> confusing to
> > > > users.
> > > >
> > > > The only time I've seen versioning problems is when commons
> components
> > > > depend on each other and one of them breaks backwards
> compatibility
> > > like
> > > > commons collections did recectly. This is why it's so important
> for
> > > > commons components to have minimal dependencies.
> > > >
> > > > What commons components caused your project problems?
> > > >
> > > > David
> > > >
> > > >
> > > > --- Daniel Florey <da...@web.de> wrote:
> > > >
> > > >> Hi all,
> > > >> As commons components gain more and more attention you'll find a
> lot
> > > >> components in larger java based projects. This can cause much
> trouble
> > > >> when
> > > >> subprojects use different incompatible versions of the same
> > > component.
> > > >> I was faced with this problem in the project I'm currently
> working on
> > > >> and
> > > >> thought about how to avoid situations like these.
> > > >> So this is my proposal:
> > > >> - All versions of a component using the same main version number
> must
> > > be
> > > >> upwards compatible: Methods in component-1.x must not change in
> > > semantic
> > > >> or
> > > >> syntax compared to component-1.y where x < y. Methods can be
> marked
> > > as
> > > >> deprecated but must still work in the same way.
> > > >> - When incompatible api changes or semantic changes of existing
> > > methods
> > > >> will
> > > >> be introduced, a new major version number must indicate this. To
> > > ensure
> > > >> that
> > > >> different versions of the same component can be used by a single
> > > >> application, the package name must change as well.
> > > >> Example:
> > > >> org.apache.commons.component-1 contains the 1.x source code of
> the
> > > >> compoenent
> > > >> org.apache.commons.component-2 contains the 2.x sources
> > > >>
> > > >> Both versions of the component can be used simultaneous and
> > > situations
> > > >> described at the beginning of this post can be handled.
> > > >> Disadvantage: When upgrading a project from component-1.x to
> > > >> component-2.x
> > > >> all includes must be updated.
> > > >> But the fact that many (even commercial products) ship without
> > > >> indicating by
> > > >> jar-extension which version of a component is used, this can
> avoid a
> > > lot
> > > >> of
> > > >> headaches.
> > > >> What do you think of this approach?
> > > >>
> > > >> Regards,
> > > >> Daniel
> > > >>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> > > >> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> > > >>
> > > >>
> > > >
> > > >
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > Tired of spam? Yahoo! Mail has the best spam protection around
> > > > http://mail.yahoo.com
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > >
> > >
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
AW: [proposal] avoiding jar version nightmares
Posted by Daniel Florey <da...@web.de>.
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 version of the other
product. In situations like these you are absolutely lost, aren't you?
So my proposal was about to avoid this horrible situation. Any proposals how
to solve this issue in another way?
Or is this list not the right place for discussing stuff like this?
Cheers,
Daniel
> -----Ursprüngliche Nachricht-----
> Von: commons-dev-return-64503-daniel.florey=web.de@jakarta.apache.org
> [mailto:commons-dev-return-64503-daniel.florey=web.de@jakarta.apache.org]
> Im Auftrag von David Graham
> Gesendet: Freitag, 17. Dezember 2004 02:26
> An: Jakarta Commons Developers List
> Betreff: Re: [proposal] avoiding jar version nightmares
>
> Struts uses the deprecation cycle I described and so did the commons
> components spawned from Struts the last I knew (validator certainly still
> uses the described cycle). A 1.x series is backwards compatible but
> deprecated methods may be removed after they have been deprecated for at
> least one point release. A jump to 2.x means, among other things, there
> are backwards incompatible changes without a deprecation cycle.
>
> This approach obviously varies by project.
>
> David
>
> --- Stephen Colebourne <sc...@btopenworld.com> wrote:
>
> > Commons has always followed a longer deprecation cycle than described
> > below.
> > A method deprecated in 1.1, 1.2, 1.3 cannot be removed until 2.0.
> >
> > 1.1 -> 1.2 -> 1.3 should all be easy compatible changes.
> >
> > 1.1/1.2 -> 2.0 may cause issues.
> >
> > In collections we faced a peculiar compatability problem in that a
> > constant
> > was in both 2.1 and 3.0 but was declared as a different type (by error).
> >
> > This caused major hassle as it wasn't spotted quickly. (Use 2.1.1 or 3.1
> > to
> > get around the problem).
> >
> > Personally, I believe that a different package name for each version is
> > overly restricting. Most users will just recompile their code for the
> > new
> > version and it will just work. Plus, having the same class in two
> > different
> > packages will be very confusing when using an IDE. This would be
> > especially
> > true if someone obtains an object from one version and then tries to
> > pass it
> > to an object of another version.
> >
> > Also, since human error can be a factor, we would have to version every
> > release, minor or major to actually make the system foolproof.
> >
> > Basically, I believe there is no simple solution to this. The best we
> > can do
> > is to encourage tools like clirr which check a library for binary
> > compatability. This should become part of each components standard
> > tests.
> >
> > Stephen
> >
> > ----- Original Message -----
> > From: "David Graham" <gr...@yahoo.com>
> > > All the jakarta projects I've worked on have a deprecation cycle of
> > one
> > > minor point release. For example, you deprecate a method for the 1.1
> > > release and can remove it for the 1.2 release. This gives users time
> > to
> > > see the deprecation warning and update their code appropriately. IMO,
> > > requiring a package name change is overly restrictive and confusing to
> > > users.
> > >
> > > The only time I've seen versioning problems is when commons components
> > > depend on each other and one of them breaks backwards compatibility
> > like
> > > commons collections did recectly. This is why it's so important for
> > > commons components to have minimal dependencies.
> > >
> > > What commons components caused your project problems?
> > >
> > > David
> > >
> > >
> > > --- Daniel Florey <da...@web.de> wrote:
> > >
> > >> Hi all,
> > >> As commons components gain more and more attention you'll find a lot
> > >> components in larger java based projects. This can cause much trouble
> > >> when
> > >> subprojects use different incompatible versions of the same
> > component.
> > >> I was faced with this problem in the project I'm currently working on
> > >> and
> > >> thought about how to avoid situations like these.
> > >> So this is my proposal:
> > >> - All versions of a component using the same main version number must
> > be
> > >> upwards compatible: Methods in component-1.x must not change in
> > semantic
> > >> or
> > >> syntax compared to component-1.y where x < y. Methods can be marked
> > as
> > >> deprecated but must still work in the same way.
> > >> - When incompatible api changes or semantic changes of existing
> > methods
> > >> will
> > >> be introduced, a new major version number must indicate this. To
> > ensure
> > >> that
> > >> different versions of the same component can be used by a single
> > >> application, the package name must change as well.
> > >> Example:
> > >> org.apache.commons.component-1 contains the 1.x source code of the
> > >> compoenent
> > >> org.apache.commons.component-2 contains the 2.x sources
> > >>
> > >> Both versions of the component can be used simultaneous and
> > situations
> > >> described at the beginning of this post can be handled.
> > >> Disadvantage: When upgrading a project from component-1.x to
> > >> component-2.x
> > >> all includes must be updated.
> > >> But the fact that many (even commercial products) ship without
> > >> indicating by
> > >> jar-extension which version of a component is used, this can avoid a
> > lot
> > >> of
> > >> headaches.
> > >> What do you think of this approach?
> > >>
> > >> Regards,
> > >> Daniel
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > >> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >>
> > >>
> > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Tired of spam? Yahoo! Mail has the best spam protection around
> > > http://mail.yahoo.com
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - Easier than ever with enhanced search. Learn more.
> http://info.mail.yahoo.com/mail_250
>
> ---------------------------------------------------------------------
> 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: [proposal] avoiding jar version nightmares
Posted by David Graham <gr...@yahoo.com>.
Struts uses the deprecation cycle I described and so did the commons
components spawned from Struts the last I knew (validator certainly still
uses the described cycle). A 1.x series is backwards compatible but
deprecated methods may be removed after they have been deprecated for at
least one point release. A jump to 2.x means, among other things, there
are backwards incompatible changes without a deprecation cycle.
This approach obviously varies by project.
David
--- Stephen Colebourne <sc...@btopenworld.com> wrote:
> Commons has always followed a longer deprecation cycle than described
> below.
> A method deprecated in 1.1, 1.2, 1.3 cannot be removed until 2.0.
>
> 1.1 -> 1.2 -> 1.3 should all be easy compatible changes.
>
> 1.1/1.2 -> 2.0 may cause issues.
>
> In collections we faced a peculiar compatability problem in that a
> constant
> was in both 2.1 and 3.0 but was declared as a different type (by error).
>
> This caused major hassle as it wasn't spotted quickly. (Use 2.1.1 or 3.1
> to
> get around the problem).
>
> Personally, I believe that a different package name for each version is
> overly restricting. Most users will just recompile their code for the
> new
> version and it will just work. Plus, having the same class in two
> different
> packages will be very confusing when using an IDE. This would be
> especially
> true if someone obtains an object from one version and then tries to
> pass it
> to an object of another version.
>
> Also, since human error can be a factor, we would have to version every
> release, minor or major to actually make the system foolproof.
>
> Basically, I believe there is no simple solution to this. The best we
> can do
> is to encourage tools like clirr which check a library for binary
> compatability. This should become part of each components standard
> tests.
>
> Stephen
>
> ----- Original Message -----
> From: "David Graham" <gr...@yahoo.com>
> > All the jakarta projects I've worked on have a deprecation cycle of
> one
> > minor point release. For example, you deprecate a method for the 1.1
> > release and can remove it for the 1.2 release. This gives users time
> to
> > see the deprecation warning and update their code appropriately. IMO,
> > requiring a package name change is overly restrictive and confusing to
> > users.
> >
> > The only time I've seen versioning problems is when commons components
> > depend on each other and one of them breaks backwards compatibility
> like
> > commons collections did recectly. This is why it's so important for
> > commons components to have minimal dependencies.
> >
> > What commons components caused your project problems?
> >
> > David
> >
> >
> > --- Daniel Florey <da...@web.de> wrote:
> >
> >> Hi all,
> >> As commons components gain more and more attention you'll find a lot
> >> components in larger java based projects. This can cause much trouble
> >> when
> >> subprojects use different incompatible versions of the same
> component.
> >> I was faced with this problem in the project I'm currently working on
> >> and
> >> thought about how to avoid situations like these.
> >> So this is my proposal:
> >> - All versions of a component using the same main version number must
> be
> >> upwards compatible: Methods in component-1.x must not change in
> semantic
> >> or
> >> syntax compared to component-1.y where x < y. Methods can be marked
> as
> >> deprecated but must still work in the same way.
> >> - When incompatible api changes or semantic changes of existing
> methods
> >> will
> >> be introduced, a new major version number must indicate this. To
> ensure
> >> that
> >> different versions of the same component can be used by a single
> >> application, the package name must change as well.
> >> Example:
> >> org.apache.commons.component-1 contains the 1.x source code of the
> >> compoenent
> >> org.apache.commons.component-2 contains the 2.x sources
> >>
> >> Both versions of the component can be used simultaneous and
> situations
> >> described at the beginning of this post can be handled.
> >> Disadvantage: When upgrading a project from component-1.x to
> >> component-2.x
> >> all includes must be updated.
> >> But the fact that many (even commercial products) ship without
> >> indicating by
> >> jar-extension which version of a component is used, this can avoid a
> lot
> >> of
> >> headaches.
> >> What do you think of this approach?
> >>
> >> Regards,
> >> Daniel
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
> > ---------------------------------------------------------------------
> > 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
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [proposal] avoiding jar version nightmares
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Commons has always followed a longer deprecation cycle than described below.
A method deprecated in 1.1, 1.2, 1.3 cannot be removed until 2.0.
1.1 -> 1.2 -> 1.3 should all be easy compatible changes.
1.1/1.2 -> 2.0 may cause issues.
In collections we faced a peculiar compatability problem in that a constant
was in both 2.1 and 3.0 but was declared as a different type (by error).
This caused major hassle as it wasn't spotted quickly. (Use 2.1.1 or 3.1 to
get around the problem).
Personally, I believe that a different package name for each version is
overly restricting. Most users will just recompile their code for the new
version and it will just work. Plus, having the same class in two different
packages will be very confusing when using an IDE. This would be especially
true if someone obtains an object from one version and then tries to pass it
to an object of another version.
Also, since human error can be a factor, we would have to version every
release, minor or major to actually make the system foolproof.
Basically, I believe there is no simple solution to this. The best we can do
is to encourage tools like clirr which check a library for binary
compatability. This should become part of each components standard tests.
Stephen
----- Original Message -----
From: "David Graham" <gr...@yahoo.com>
> All the jakarta projects I've worked on have a deprecation cycle of one
> minor point release. For example, you deprecate a method for the 1.1
> release and can remove it for the 1.2 release. This gives users time to
> see the deprecation warning and update their code appropriately. IMO,
> requiring a package name change is overly restrictive and confusing to
> users.
>
> The only time I've seen versioning problems is when commons components
> depend on each other and one of them breaks backwards compatibility like
> commons collections did recectly. This is why it's so important for
> commons components to have minimal dependencies.
>
> What commons components caused your project problems?
>
> David
>
>
> --- Daniel Florey <da...@web.de> wrote:
>
>> Hi all,
>> As commons components gain more and more attention you'll find a lot
>> components in larger java based projects. This can cause much trouble
>> when
>> subprojects use different incompatible versions of the same component.
>> I was faced with this problem in the project I'm currently working on
>> and
>> thought about how to avoid situations like these.
>> So this is my proposal:
>> - All versions of a component using the same main version number must be
>> upwards compatible: Methods in component-1.x must not change in semantic
>> or
>> syntax compared to component-1.y where x < y. Methods can be marked as
>> deprecated but must still work in the same way.
>> - When incompatible api changes or semantic changes of existing methods
>> will
>> be introduced, a new major version number must indicate this. To ensure
>> that
>> different versions of the same component can be used by a single
>> application, the package name must change as well.
>> Example:
>> org.apache.commons.component-1 contains the 1.x source code of the
>> compoenent
>> org.apache.commons.component-2 contains the 2.x sources
>>
>> Both versions of the component can be used simultaneous and situations
>> described at the beginning of this post can be handled.
>> Disadvantage: When upgrading a project from component-1.x to
>> component-2.x
>> all includes must be updated.
>> But the fact that many (even commercial products) ship without
>> indicating by
>> jar-extension which version of a component is used, this can avoid a lot
>> of
>> headaches.
>> What do you think of this approach?
>>
>> Regards,
>> Daniel
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> 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: [proposal] avoiding jar version nightmares
Posted by David Graham <gr...@yahoo.com>.
All the jakarta projects I've worked on have a deprecation cycle of one
minor point release. For example, you deprecate a method for the 1.1
release and can remove it for the 1.2 release. This gives users time to
see the deprecation warning and update their code appropriately. IMO,
requiring a package name change is overly restrictive and confusing to
users.
The only time I've seen versioning problems is when commons components
depend on each other and one of them breaks backwards compatibility like
commons collections did recectly. This is why it's so important for
commons components to have minimal dependencies.
What commons components caused your project problems?
David
--- Daniel Florey <da...@web.de> wrote:
> Hi all,
> As commons components gain more and more attention you'll find a lot
> components in larger java based projects. This can cause much trouble
> when
> subprojects use different incompatible versions of the same component.
> I was faced with this problem in the project I'm currently working on
> and
> thought about how to avoid situations like these.
> So this is my proposal:
> - All versions of a component using the same main version number must be
> upwards compatible: Methods in component-1.x must not change in semantic
> or
> syntax compared to component-1.y where x < y. Methods can be marked as
> deprecated but must still work in the same way.
> - When incompatible api changes or semantic changes of existing methods
> will
> be introduced, a new major version number must indicate this. To ensure
> that
> different versions of the same component can be used by a single
> application, the package name must change as well.
> Example:
> org.apache.commons.component-1 contains the 1.x source code of the
> compoenent
> org.apache.commons.component-2 contains the 2.x sources
>
> Both versions of the component can be used simultaneous and situations
> described at the beginning of this post can be handled.
> Disadvantage: When upgrading a project from component-1.x to
> component-2.x
> all includes must be updated.
> But the fact that many (even commercial products) ship without
> indicating by
> jar-extension which version of a component is used, this can avoid a lot
> of
> headaches.
> What do you think of this approach?
>
> Regards,
> Daniel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org