Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
From: "Daniel Florey" <daniel.florey@web.de>
To: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>
Subject: AW: AW: [proposal] avoiding jar version nightmares
Date: Fri, 17 Dec 2004 22:12:41 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <20041217203257.98486.qmail@web50405.mail.yahoo.com>
Thread-Index: AcTkeLLJTYIjHTzFRV+BpN8KaG9FJgABDEfg
Message-Id: <E1CfPOz-0002n8-00@smtp05.web.de>
Sender: daniel.florey@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=FCngliche Nachricht-----
> Von: =
commons-dev-return-64551-daniel.florey=3Dweb.de@jakarta.apache.org
> =
[mailto:commons-dev-return-64551-daniel.florey=3Dweb.de@jakarta.apache.or=
g]
> 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
>=20
> 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.
>=20
> David
>=20
> --- Daniel Florey <daniel.florey@web.de> wrote:
>=20
> > 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=3Dweb.de@jakarta.apache.org
> > >
> >
> =
[mailto:commons-dev-return-64503-daniel.florey=3Dweb.de@jakarta.apache.or=
g]
> > > 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
> > > > >
> > > > >
> > > >
> > > >
> > > >
> >
> =3D=3D=3D message truncated =3D=3D=3D
>=20
>=20
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>=20
> ---------------------------------------------------------------------
> 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