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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Im Auftrag von David Graham > Gesendet: Freitag, 17. Dezember 2004 21:33 > An: Jakarta Commons Developers List > Betreff: Re: AW: [proposal] avoiding jar version nightmares > > What happens if you merge the jars for each product? For example, put > commons 1.x files into productA.jar and commons 2.x files into > productB.jar. > > David > > --- Daniel Florey <[EMAIL PROTECTED]> wrote: > > > So how should we handle situations where two versions of the same > > component > > need to coexist? > > 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: [EMAIL PROTECTED] > > > > > > [mailto:[EMAIL PROTECTED] > > > 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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > > > > > 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 <[EMAIL PROTECTED]> 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: > > [EMAIL PROTECTED] > > > > >> For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > >> > > > > >> > > > > > > > > > > > > > > > __________________________________________________ > > > > > Do You Yahoo!? > > > > > Tired of spam? Yahoo! Mail has the best spam protection around > > > > > http://mail.yahoo.com > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > === message truncated === > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
