Researching MATH-414, I am seeing this stacktrace:
org.apache.commons.math.ConvergenceException: Continued fraction diverged to
NaN for value ?
at
org.apache.commons.math.util.ContinuedFraction.evaluate(ContinuedFraction.java:186)
The "?" should represent positive infinity (the actual paramet
On Nov 24, 2010, at 2:54 PM, Niall Pemberton wrote:
> On Wed, Nov 24, 2010 at 7:43 PM, James Carman
> wrote:
>> On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
>> wrote:
>>>
>>> I disagree. The "rule" should be that a new package and artifactId is
>>> required when compatibility is broken, not
That's already part of the binary compatibility rule
On Nov 24, 2010 4:31 PM, "Ralph Goers" wrote:
>
> On Nov 24, 2010, at 11:43 AM, James Carman wrote:
>
>> On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
>> wrote:
>>>
>>> I disagree. The "rule" should be that a new package and artifactId is
requi
On Nov 24, 2010, at 11:43 AM, James Carman wrote:
> On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
> wrote:
>>
>> I disagree. The "rule" should be that a new package and artifactId is
>> required when compatibility is broken, not when a version change occurs.
>> Exceptions should be based on t
They would need to change together to be of any use obviously.
On Nov 24, 2010 3:55 PM, "Niall Pemberton"
wrote:
> On Wed, Nov 24, 2010 at 7:43 PM, James Carman
> wrote:
>> On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
>> wrote:
>>>
>>> I disagree. The "rule" should be that a new package and art
On Wed, Nov 24, 2010 at 7:43 PM, James Carman
wrote:
> On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
> wrote:
>>
>> I disagree. The "rule" should be that a new package and artifactId is
>> required when compatibility is broken, not when a version change occurs.
>> Exceptions should be based on
Luc Maisonobe wrote:
> Le 24/11/2010 20:43, James Carman a écrit :
>> On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
>> wrote:
>>>
>>> I disagree. The "rule" should be that a new package and artifactId is
>>> required when compatibility is broken, not when a version change occurs.
>>> Exceptions s
Am 24.11.2010 21:17, schrieb Luc Maisonobe:
Le 24/11/2010 20:43, James Carman a écrit :
On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
wrote:
I disagree. The "rule" should be that a new package and artifactId is required
when compatibility is broken, not when a version change occurs. Excepti
Le 24/11/2010 20:43, James Carman a écrit :
> On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
> wrote:
>>
>> I disagree. The "rule" should be that a new package and artifactId is
>> required when compatibility is broken, not when a version change occurs.
>> Exceptions should be based on that polic
On Wed, Nov 24, 2010 at 12:16 PM, Niall Pemberton
wrote:
>
> Package name change decisions should be based purely on whether a
> component decides whether breaking binary compatibility is acceptable
> or not.
>
> I also think conflating version/packagename/maven issues causes
> confusion. The deci
On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
wrote:
>
> I disagree. The "rule" should be that a new package and artifactId is
> required when compatibility is broken, not when a version change occurs.
> Exceptions should be based on that policy, not on a version change occurs.
>
Ok, so how abo
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Commons Wiki" for
change notification.
The "LocalBadContent" page has been changed by sebbapache.
http://wiki.apache.org/commons/LocalBadContent?action=diff&rev1=7&rev2=8
--
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Commons Wiki" for
change notification.
The "MavenGroupIDChange" page has been changed by sebbapache.
The comment on this change is: What is jar hell.
http://wiki.apache.org/commons/MavenGroupIDChange?action=diff&rev1=4&rev2=
Le 24/11/2010 18:44, sebb a écrit :
> On 24 November 2010 17:01, Luc Maisonobe wrote:
>> Le 24/11/2010 17:19, Dietmar Wolz a écrit :
>>>
>>>
that depends on math 2.1. Orekit itself (or whatever other immediate
dependency) may not have cut a release changing its internal use to 3.0.
>>
On 24 November 2010 17:01, Luc Maisonobe wrote:
> Le 24/11/2010 17:19, Dietmar Wolz a écrit :
>>
>>
>>> that depends on math 2.1. Orekit itself (or whatever other immediate
>>> dependency) may not have cut a release changing its internal use to 3.0. At
>>
>> Is this realistic? I would expect qui
On Wed, Nov 24, 2010 at 3:36 PM, James Carman
wrote:
> We've had this package name/artifactId change discussion numerous
> times and I think it's time we put this thing to a vote. What I
> propose is that we say that this is a rule and in order to "break"
> that rule, you have to provide strong e
On Nov 24, 2010, at 7:36 AM, James Carman wrote:
> We've had this package name/artifactId change discussion numerous
> times and I think it's time we put this thing to a vote. What I
> propose is that we say that this is a rule and in order to "break"
> that rule, you have to provide strong evid
Le 24/11/2010 17:19, Dietmar Wolz a écrit :
>
>
>> that depends on math 2.1. Orekit itself (or whatever other immediate
>> dependency) may not have cut a release changing its internal use to 3.0. At
>
> Is this realistic? I would expect quite early an Orekit version supporting CM
> 3.0.
For
On Nov 24, 2010, at 8:18 AM, James Carman wrote:
> On Wed, Nov 24, 2010 at 11:11 AM, Stephen Colebourne
> wrote:
>>
>> For example, if a whole set of new features is added, it can be worth
>> using a new version number for marketing reasons (advertising the
>> major new features). This can resu
On Wed, Nov 24, 2010 at 11:11 AM, Stephen Colebourne
wrote:
> While I hardly count as having a vote now, I do have an opinion ;-)
>
Cycles welcome :))
>
> I think that the formulation below is too strong. I'd argue that
> changing the package name is required when there is significant
> incompat
Le 24/11/2010 17:09, Dietmar Wolz a écrit :
>
>
>> The name change is not for maintaining several versions in parallel. It
>> is to allow projects to have parts depending on the old (unmaintained)
>> version and new (maintained) version to compile and let them go back in
>> sync progressively. It
On Wed, Nov 24, 2010 at 10:36 AM, James Carman
wrote:
>
> [ ] +1 - accept this as a rule
> [ ] -1 - do not accept this as a rule
>
Here's my +1
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands
On Wed, Nov 24, 2010 at 11:07 AM, sebb wrote:
>> A major version change requires that you change the package name (the
>> part that comes after org.apache.commons) and the Maven artifactId to
>> the component's name with the major version appended to the end.
>>
>> [ ] +1 - accept this as a rule
>
+1
Gary
On Nov 24, 2010, at 7:36, "James Carman" wrote:
> We've had this package name/artifactId change discussion numerous
> times and I think it's time we put this thing to a vote. What I
> propose is that we say that this is a rule and in order to "break"
> that rule, you have to provide st
On Wed, Nov 24, 2010 at 4:38 AM, Luc Maisonobe wrote:
> Hi all,
>
> We have cut a branch for 2.X some times ago and starting work on 3.0.
> 2.2 is (as far as I am concerned) both a bug fix release and a
> transition release towards 3.0. The recent thread about repackaging a
> set of user-related e
>that depends on math 2.1. Orekit itself (or whatever other immediate
>dependency) may not have cut a release changing its internal use to 3.0. At
Is this realistic? I would expect quite early an Orekit version supporting CM
3.0.
May be not a release but the actual Orekit trunk. So for your o
On Wed, Nov 24, 2010 at 11:11 AM, Stephen Colebourne
wrote:
>
> For example, if a whole set of new features is added, it can be worth
> using a new version number for marketing reasons (advertising the
> major new features). This can result in a major version that is still
> compatible.
>
> It is
> [...]
>
> As I said, the use case driving the need for the package name change is
> really beyond users' control, so I am +1 on the package name change for 3.0
>
> >
> > [1] I would be the first to have a little less work as a result of the name
> >change.
+1
Gilles
P.S. Can we do the c
On Wed, Nov 24, 2010 at 11:09 AM, Dietmar Wolz wrote:
>
> The question is: Are there projects using CM where the transition time is
> large enough to justify the usage of two different versions of CM at
> the same time? I am usually working in an OSGI-context where in principal
> such situations a
While I hardly count as having a vote now, I do have an opinion ;-)
I think that the formulation below is too strong. I'd argue that
changing the package name is required when there is significant
incompatibility, but a major version change might not cause such
incompatibility.
For example, if a
>The name change is not for maintaining several versions in parallel. It
>is to allow projects to have parts depending on the old (unmaintained)
>version and new (maintained) version to compile and let them go back in
>sync progressively. It is exactly the same process than the change in
>2.2 for
On 24 November 2010 15:36, James Carman wrote:
> We've had this package name/artifactId change discussion numerous
> times and I think it's time we put this thing to a vote. What I
> propose is that we say that this is a rule and in order to "break"
> that rule, you have to provide strong evidenc
On Wed, Nov 24, 2010 at 10:34 AM, Gilles Sadowski <
gil...@harfang.homelinux.org> wrote:
> Hello.
>
> > If you break compatibility, then the advisable thing to do is change
> > the package name (and artifactId, etc.). Now, if we can be almost
> > certain that there would be no case that you would
On Wed, Nov 24, 2010 at 10:34 AM, Gilles Sadowski
wrote:
>
> Wouldn't it mean that at least one of the two libraries is not an active
> project? Otherwise I'd think they would benefit from upgrading.
>
So what if it isn't? If the library works for what you need it to do
and it relies on an older
We've had this package name/artifactId change discussion numerous
times and I think it's time we put this thing to a vote. What I
propose is that we say that this is a rule and in order to "break"
that rule, you have to provide strong evidence that the component's
situation is unique and not affec
Hello.
> If you break compatibility, then the advisable thing to do is change
> the package name (and artifactId, etc.). Now, if we can be almost
> certain that there would be no case that you wouldn't have a situation
> come up where two different, incompatible versions of math would be
> requir
Ok, so if you guys go to a 3.0 version which breaks compatibility,
then I'd suggest you do the package/artifactId "switcheroo". Note,
this is not technically changing the name of the project. It's merely
a way to avoid "jar hell" (as has been discussed numerous times).
Yes, it will involve a bit
Le 24/11/2010 15:34, James Carman a écrit :
> If you break compatibility, then the advisable thing to do is change
> the package name (and artifactId, etc.). Now, if we can be almost
> certain that there would be no case that you wouldn't have a situation
> come up where two different, incompatibl
Le 24/11/2010 15:27, Gilles Sadowski a écrit :
> Hi.
>
>>> [...]
>>>
>>> The name change is an option only if we can reasonably expect that
>>> applications would use both "math" and "math3".
>>
>> No, the sole purpose of such a change is to avoid jar hell for
>> applications that do not use fancy
If you break compatibility, then the advisable thing to do is change
the package name (and artifactId, etc.). Now, if we can be almost
certain that there would be no case that you wouldn't have a situation
come up where two different, incompatible versions of math would be
required on the classpat
Hi.
> > [...]
> >
> > The name change is an option only if we can reasonably expect that
> > applications would use both "math" and "math3".
>
> No, the sole purpose of such a change is to avoid jar hell for
> applications that do not use fancy loading mechanisms like OSGi.
Why, "no"?
"Jar hel
Le 24/11/2010 13:10, Gilles Sadowski a écrit :
> Hi Luc.
>
>> [...]
I also noticed we now have an increasing number of users and some
complex projects among them. So it may be time for us to follow the
general trend proposed for commons components and switch our top level
Hello.
> [...]
>
> I would very much like to have 2.X released early, preferably in
> December. I also think 3.0 should be released early (perhaps during
> spring) as some projects I know of would need it.
>
++1 (for both releases)
Gilles
-
Hi Luc.
> [...]
> >>
> >> I also noticed we now have an increasing number of users and some
> >> complex projects among them. So it may be time for us to follow the
> >> general trend proposed for commons components and switch our top level
> >> package name from org.apache.commons.math to org.apa
On 24 November 2010 11:02, Stefan Bodewig wrote:
> On 2010-11-24, sebb wrote:
>
>> On 24 November 2010 09:46, Stefan Bodewig wrote:
>>> On 2010-11-22, Jörg Schaible wrote:
>
Stefan Bodewig wrote:
>
> The commons-lang3 builds fail[2] and too me it looks as if this was
> because AWT is
On 24 November 2010 10:45, Luc Maisonobe wrote:
> Le 24/11/2010 11:34, sebb a écrit :
>> On 24 November 2010 09:38, Luc Maisonobe wrote:
>>> Hi all,
>>>
>>> We have cut a branch for 2.X some times ago and starting work on 3.0.
>>> 2.2 is (as far as I am concerned) both a bug fix release and a
>>>
On 2010-11-24, sebb wrote:
> On 24 November 2010 09:46, Stefan Bodewig wrote:
>> On 2010-11-22, Jörg Schaible wrote:
>>> Stefan Bodewig wrote:
The commons-lang3 builds fail[2] and too me it looks as if this was
because AWT is not running in headless mode,
>> confirmed by passing -Dar
Le 24/11/2010 11:34, sebb a écrit :
> On 24 November 2010 09:38, Luc Maisonobe wrote:
>> Hi all,
>>
>> We have cut a branch for 2.X some times ago and starting work on 3.0.
>> 2.2 is (as far as I am concerned) both a bug fix release and a
>> transition release towards 3.0. The recent thread about
On 24 November 2010 09:46, Stefan Bodewig wrote:
> On 2010-11-22, Jörg Schaible wrote:
>
>> Stefan Bodewig wrote:
>
>>> The commons-lang3 builds fail[2] and too me it looks as if this was
>>> because AWT is not running in headless mode,
>
> confirmed by passing -DargLine=-Djava.awt.headless=true t
On 24 November 2010 09:38, Luc Maisonobe wrote:
> Hi all,
>
> We have cut a branch for 2.X some times ago and starting work on 3.0.
> 2.2 is (as far as I am concerned) both a bug fix release and a
> transition release towards 3.0. The recent thread about repackaging a
> set of user-related excepti
On 2010-11-22, Jörg Schaible wrote:
> Stefan Bodewig wrote:
>> The commons-lang3 builds fail[2] and too me it looks as if this was
>> because AWT is not running in headless mode,
confirmed by passing -DargLine=-Djava.awt.headless=true to mvn - the
builds now pass.
>> I am suprised the problem d
Hi all,
We have cut a branch for 2.X some times ago and starting work on 3.0.
2.2 is (as far as I am concerned) both a bug fix release and a
transition release towards 3.0. The recent thread about repackaging a
set of user-related exceptions showed this point of view.
I first intended to wait unt
52 matches
Mail list logo
