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]
