commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Graham <grahamdavid1...@yahoo.com>
Subject Re: AW: [proposal] avoiding jar version nightmares
Date Fri, 17 Dec 2004 20:32:57 GMT
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 <daniel.florey@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 <scolebourne@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" <grahamdavid1980@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 <daniel.florey@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


Mime
View raw message