mplementers of
> > > > this
> > > > * interface outside of the framework will be broken in
> future
> > > > * releases when methods are added to this interface.
> > > > *
> > > > * @since 1.0
> > > > *
>
when methods are added to this interface.
> > > *
> > > * @since 1.0
> > > *
> > > */
> > > public interface IVetoableValue extends IObservableValue {
> > >
> > > Kind regards,
> > > Andrey Loskutov
> > >
> > >
> * @since 1.0
> > *
> > */
> > public interface IVetoableValue extends IObservableValue {
> >
> > Kind regards,
> > Andrey Loskutov
> >
> > http://google.com/+AndreyLoskutov
> >
> >
> > > Gesendet: Dienstag, 14. Juni 2016 um 09
*/
> public interface IVetoableValue extends IObservableValue {
>
> Kind regards,
> Andrey Loskutov
>
> http://google.com/+AndreyLoskutov
>
>
> > Gesendet: Dienstag, 14. Juni 2016 um 09:03 Uhr
> > Von: "Jörg Schaible"
> > An: dev@commons.apache.
Gesendet: Dienstag, 14. Juni 2016 um 09:03 Uhr
> Von: "Jörg Schaible"
> An: dev@commons.apache.org
> Betreff: Re: [ALL] About binary compatibility
>
> Hi,
>
> James Carman wrote:
>
> > Agree we should have a "source of truth". Is there something wro
Hi,
James Carman wrote:
> Agree we should have a "source of truth". Is there something wrong with
> using an "internal" or "impl" package name? The bundle plugin for OSGi
> doesn't export these by default, which would be a nice side effect! :).
While it is a step in the right direction, a packag
Tomcat does this with a simple text file in the root of the
distribution. Compare Tomcat 9 [1] (currently in development) with
Tomcat 8 [2] (stable release).
We actually don't guarantee very much but Tomcat is a very different
type of project. The idea, however, could be re-used.
Mark
[1]
http:/
Agree we should have a "source of truth". Is there something wrong with
using an "internal" or "impl" package name? The bundle plugin for OSGi
doesn't export these by default, which would be a nice side effect! :).
On Mon, Jun 13, 2016 at 3:05 PM Thomas Vandahl wrote:
> On 13.06.16 20:57, James
On 13.06.16 20:57, James Carman wrote:
> I'd rather not make it (the OSGi metadata) the "source of truth".
I'm not insisting on OSGi meta data but I strongly believe that one
(single) source of truth is required. Suggest something else.
Bye, Thomas.
-
On 13.06.16 20:54, Jochen Wiedmann wrote:
> On Mon, Jun 13, 2016 at 8:49 PM, Thomas Vandahl wrote:
>> On 05.06.16 20:33, James Carman wrote:
>>> Not quite. OSGi is a special case. It's much more restrictive than simple
>>> J2SE, because it can be. In the general case, the public API for OSGi is
>>
I'd rather not make it (the OSGi metadata) the "source of truth".
On Mon, Jun 13, 2016 at 2:49 PM Thomas Vandahl wrote:
> On 05.06.16 20:33, James Carman wrote:
> > Not quite. OSGi is a special case. It's much more restrictive than simple
> > J2SE, because it can be. In the general case, the pub
On Mon, Jun 13, 2016 at 8:49 PM, Thomas Vandahl wrote:
> On 05.06.16 20:33, James Carman wrote:
>> Not quite. OSGi is a special case. It's much more restrictive than simple
>> J2SE, because it can be. In the general case, the public API for OSGi is
>> different from the public API for J2SE. Let's
On 05.06.16 20:33, James Carman wrote:
> Not quite. OSGi is a special case. It's much more restrictive than simple
> J2SE, because it can be. In the general case, the public API for OSGi is
> different from the public API for J2SE. Let's not confuse the two.
My intention was to use the OSGi meta d
Jochen Wiedmann <
> > jochen.wiedm...@gmail.com <mailto:jochen.wiedm...@gmail.com>>
> > > wrote:
> > >
> > >> -- Forwarded message ----------
> > >> From: Ralph Goers
> > >> Date: Mon, Jun 6, 2016 at 1:11 AM
> > >> Subject:
On Mon, Jun 6, 2016 at 10:07 PM, Ralph Goers wrote:
> From what I have been reading on the core-libs-dev mailing list that feature
> is part of the
> Java 9 EA releases that are currently being delivered. From this thread it
> appears
> you can build currently build multi-release jars with Mave
wrote:
> >
> >> -- Forwarded message --
> >> From: Ralph Goers
> >> Date: Mon, Jun 6, 2016 at 1:11 AM
> >> Subject: Re: [ALL] About binary compatibility
> >> To: Commons Developers List
> >>
> >>
> >> I think we should
From what I have been reading on the core-libs-dev mailing list that feature is
part of the Java 9 EA releases that are currently being delivered. From this
thread it appears you can build currently build multi-release jars with Maven
[1[.
Ralph
[1] https://www.mail-archive.com/core-libs-dev%
From: Ralph Goers
>>> Date: Mon, Jun 6, 2016 at 1:11 AM
>>> Subject: Re: [ALL] About binary compatibility
>>> To: Commons Developers List
>>>
>>>
>>> I think we should adopt Java 9’s multi-release jars [1] as standard
>>> pract
On Sun, Jun 5, 2016 at 7:12 PM Ralph Goers
wrote:
> I think we should adopt Java 9’s multi-release jars [1] as standard
> practice. While this won’t let us update our APIs without breaking
> compatibility (which may still be necessary), it will allow us to leverage
> some features in newer versi
> On Jun 6, 2016, at 11:38 AM, Gary Gregory wrote:
>
> On Mon, Jun 6, 2016 at 11:11 AM, Jochen Wiedmann <mailto:jochen.wiedm...@gmail.com>>
> wrote:
>
>> -- Forwarded message --
>> From: Ralph Goers
>> Date: Mon, Jun 6, 2016 at
On Mon, Jun 6, 2016 at 11:11 AM, Jochen Wiedmann
wrote:
> -- Forwarded message --
> From: Ralph Goers
> Date: Mon, Jun 6, 2016 at 1:11 AM
> Subject: Re: [ALL] About binary compatibility
> To: Commons Developers List
>
>
> I think we should adopt Java 9
> On Jun 6, 2016, at 11:11 AM, Jochen Wiedmann
> wrote:
>
> -- Forwarded message --
> From: Ralph Goers
> Date: Mon, Jun 6, 2016 at 1:11 AM
> Subject: Re: [ALL] About binary compatibility
> To: Commons Developers List
>
>
> I think we sh
-- Forwarded message --
From: Ralph Goers
Date: Mon, Jun 6, 2016 at 1:11 AM
Subject: Re: [ALL] About binary compatibility
To: Commons Developers List
I think we should adopt Java 9’s multi-release jars [1] as standard
practice. While this won’t let us update our APIs without
I think we should adopt Java 9’s multi-release jars [1] as standard practice.
While this won’t let us update our APIs without breaking compatibility (which
may still be necessary), it will allow us to leverage some features in newer
versions of Java without worrying about breaking backward comp
On Sun, Jun 5, 2016 at 4:46 PM, Oliver Heger
wrote:
> Take BCEL as an example. There was a strong momentum about half a year
> or so ago to push out a new major release breaking BC. Then discussion
> started to revert breaking changes. This would of course have been the
> ideal solution for all u
Not quite. OSGi is a special case. It's much more restrictive than simple
J2SE, because it can be. In the general case, the public API for OSGi is
different from the public API for J2SE. Let's not confuse the two.
On Sun, Jun 5, 2016 at 2:30 PM Gary Gregory wrote:
> On Jun 5, 2016 11:12 AM, "seb
On Jun 5, 2016 11:12 AM, "sebb" wrote:
>
> On 5 June 2016 at 18:51, Thomas Vandahl wrote:
> > On 03.06.16 10:38, sebb wrote:
> >> On 2 June 2016 at 21:42, Benedikt Ritter wrote:
> >>> - we must not break BC in a release that could collide with an earlier
> >>> version. In other words, when we br
On 5 June 2016 at 18:51, Thomas Vandahl wrote:
> On 03.06.16 10:38, sebb wrote:
>> On 2 June 2016 at 21:42, Benedikt Ritter wrote:
>>> - we must not break BC in a release that could collide with an earlier
>>> version. In other words, when we break BC, we have to change package and
>>> maven coor
On 03.06.16 10:38, sebb wrote:
> On 2 June 2016 at 21:42, Benedikt Ritter wrote:
>> - we must not break BC in a release that could collide with an earlier
>> version. In other words, when we break BC, we have to change package and
>> maven coordinates.
>
> +1, with the proviso that we must not br
In the case of BCEL, the coding actually stalled on fixing some bugs
which were proving both difficult to test and fix.
The code that was reverted to become BC was largely orthogonal to that.
On 5 June 2016 at 16:58, Benedikt Ritter wrote:
> Hello Oilver,
>
> Oliver Heger schrieb am So., 5. J
Hello Oilver,
Oliver Heger schrieb am So., 5. Juni 2016 um
16:46 Uhr:
> Hi Benedikt,
>
> Am 02.06.2016 um 22:42 schrieb Benedikt Ritter:
> > Hi,
> >
> > we do seem to have different opinions when it comes to binary
> compatibility
> > and how it should be handled. Usually we would say "this shou
Hi Benedikt,
Am 02.06.2016 um 22:42 schrieb Benedikt Ritter:
> Hi,
>
> we do seem to have different opinions when it comes to binary compatibility
> and how it should be handled. Usually we would say "this should be decided
> on a component basis". However this discussion is coming up again and a
On Thu, Jun 2, 2016 at 11:36 PM, Benson Margulies wrote:
> I don't understand what's wrong with semantic versioning and keeping
> the same maven coordinates. No sane person should be using RELEASE or
> LATEST.
The real problem is, IMO, not the versioning scheme, but the fact,
that most applicatio
On Thu, 02 Jun 2016 21:35:45 +, Benedikt Ritter wrote:
Emmanuel Bourg schrieb am Do., 2. Juni 2016 um
23:26 Uhr:
Le 2/06/2016 à 22:42, Benedikt Ritter a écrit :
> - since our components are depended upon by a lot of projects, we
need to
> take special care regarding compatibility.
+1,
On 2 June 2016 at 21:42, Benedikt Ritter wrote:
> Hi,
>
> we do seem to have different opinions when it comes to binary compatibility
> and how it should be handled. Usually we would say "this should be decided
> on a component basis". However this discussion is coming up again and again
> and I t
Hi Benson,
Benson Margulies wrote:
> Just to cite a fact:
>
> If you write:
>
>
>
>
> ...
> x
> ...
>
> You will get x. Even if transitive dependencies ask for x+10. I only
> learned this recently.
Yes, but you dropped the significant part here: groupId/artifac
On Thu, Jun 2, 2016 at 3:42 PM, Benedikt Ritter wrote:
> Hi,
>
> we do seem to have different opinions when it comes to binary compatibility
> and how it should be handled. Usually we would say "this should be decided
> on a component basis". However this discussion is coming up again and again
>
Benson Margulies schrieb am Fr., 3. Juni 2016 um
00:43 Uhr:
> Just to cite a fact:
>
> If you write:
>
>
>
>
> ...
> x
> ...
>
> You will get x. Even if transitive dependencies ask for x+10. I only
> learned this recently.
>
Yes thats true. Coming back to our exam
Le 3/06/2016 à 00:09, Gary Gregory a écrit :
> -1
>
> Timing is irrelevant. You cannot control what will end up in an app stack.
> Once released, that's it unfortunately, otherwise, the door to jar hell is
> open.
Timing is relevant because the probability of jar hell increases with
time. If the
Just to cite a fact:
If you write:
...
x
...
You will get x. Even if transitive dependencies ask for x+10. I only
learned this recently.
On Thu, Jun 2, 2016 at 6:20 PM, Gary Gregory wrote:
> On Thu, Jun 2, 2016 at 3:11 PM, Ralph Goers
> wrote:
>
>> Dependency
On Thu, Jun 2, 2016 at 3:11 PM, Ralph Goers
wrote:
> Dependency management does not cure this if C 1.2 and C 2.0 are not binary
> compatible. Code compiled with the 1.2 version will fail if those methods
> and classes are not in 2.0.
>
Indeed, hence the BC break -> Maven Coord change requirement
I don't think it has anything to do necessarily with framework or not. The
class loading model is just much easier to deal with these situations. As
Benson said, however, there are definitely other issues to contend with.
On Thu, Jun 2, 2016 at 6:14 PM Benedikt Ritter wrote:
> James Carman schri
James Carman schrieb am Fr., 3. Juni 2016 um
00:04 Uhr:
> You've been in karaf land for too long! ;)
>
It's probably a different story when you're working on a framework. It
pretty unlikely to end up with two version of Spring or Hibernate in your
app. But for a library as wildly used as commons
Dependency management does not cure this if C 1.2 and C 2.0 are not binary
compatible. Code compiled with the 1.2 version will fail if those methods and
classes are not in 2.0.
Ralph
> On Jun 2, 2016, at 3:03 PM, Benson Margulies wrote:
>
> Dependency management cures this; if you don't want
On Thu, Jun 2, 2016 at 3:01 PM, Benedikt Ritter wrote:
> Hello Benson,
>
> Benson Margulies schrieb am Do., 2. Juni 2016 um
> 23:36 Uhr:
>
> > I don't understand what's wrong with semantic versioning and keeping
> > the same maven coordinates. No sane person should be using RELEASE or
> > LATEST
On Thu, Jun 2, 2016 at 2:26 PM, Emmanuel Bourg wrote:
> Le 2/06/2016 à 22:42, Benedikt Ritter a écrit :
>
> > - since our components are depended upon by a lot of projects, we need to
> > take special care regarding compatibility.
>
> +1, thanks God Apache Commons isn't like Guava or BouncyCastle
Yep, those pesky duplicate chains.
On Thu, Jun 2, 2016 at 6:05 PM Benson Margulies
wrote:
> On Thu, Jun 2, 2016 at 6:04 PM, James Carman
> wrote:
> > You've been in karaf land for too long! ;)
>
> I took my team into OSGi to get away from these messes. Of course, we
> got some other messes in th
On Thu, Jun 2, 2016 at 6:04 PM, James Carman wrote:
> You've been in karaf land for too long! ;)
I took my team into OSGi to get away from these messes. Of course, we
got some other messes in their places.
>
> On Thu, Jun 2, 2016 at 5:36 PM Benson Margulies
> wrote:
>
>> I don't understand what
You've been in karaf land for too long! ;)
On Thu, Jun 2, 2016 at 5:36 PM Benson Margulies
wrote:
> I don't understand what's wrong with semantic versioning and keeping
> the same maven coordinates. No sane person should be using RELEASE or
> LATEST.
>
> -
Dependency management cures this; if you don't want to pick up newer
versions, you can prevent it. Since dep management doesn't know about
ranges or semantic versioning, you need to then pay attention if you
want a compatible version that comes along.
I guess it's a question of which poison you pr
Hello Benson,
Benson Margulies schrieb am Do., 2. Juni 2016 um
23:36 Uhr:
> I don't understand what's wrong with semantic versioning and keeping
> the same maven coordinates. No sane person should be using RELEASE or
> LATEST.
>
The problem are transitive dependencies. Consider this example:
M
I don't understand what's wrong with semantic versioning and keeping
the same maven coordinates. No sane person should be using RELEASE or
LATEST.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional command
Emmanuel Bourg schrieb am Do., 2. Juni 2016 um
23:26 Uhr:
> Le 2/06/2016 à 22:42, Benedikt Ritter a écrit :
>
> > - since our components are depended upon by a lot of projects, we need to
> > take special care regarding compatibility.
>
> +1, thanks God Apache Commons isn't like Guava or BouncyCa
Le 2/06/2016 à 22:42, Benedikt Ritter a écrit :
> - since our components are depended upon by a lot of projects, we need to
> take special care regarding compatibility.
+1, thanks God Apache Commons isn't like Guava or BouncyCastle.
> - we must not break BC in a release that could collide with
Hi Benedikt,
Benedikt Ritter wrote:
> Hi,
>
> we do seem to have different opinions when it comes to binary
> compatibility and how it should be handled. Usually we would say "this
> should be decided on a component basis". However this discussion is coming
> up again and again and I think we sh
On Thu, Jun 2, 2016 at 1:42 PM, Benedikt Ritter wrote:
> Hi,
>
> we do seem to have different opinions when it comes to binary compatibility
> and how it should be handled. Usually we would say "this should be decided
> on a component basis". However this discussion is coming up again and again
>
Developers List
Sent: Do., 02 Juni 2016 22:43
Subject: [ALL] About binary compatibility
Hi,
we do seem to have different opinions when it comes to binary compatibility
and how it should be handled. Usually we would say "this should be decided
on a component basis". However this discussion is
Hi,
we do seem to have different opinions when it comes to binary compatibility
and how it should be handled. Usually we would say "this should be decided
on a component basis". However this discussion is coming up again and again
and I think we should try the impossible and agree on something tha
58 matches
Mail list logo
