Hi,
So let's vote on this proposal: change the top level package name on
[math] from org.apache.commons.math to org.apache.commons.math2.
[] +1 change the top level package name
[] 0 I don't care
[] -1 keep the old name
Having read all the arguments in favor of math2 and despite still being
Luc Maisonobe wrote at Dienstag, 19. Mai 2009 22:06:
[snip]
> So let's vote on this proposal: change the top level package name on
> [math] from org.apache.commons.math to org.apache.commons.math2.
>
> [] +1 change the top level package name
> [] 0 I don't care
> [] -1 keep the old name
>
> V
Hi Ceki,
Ceki Gulcu wrote at Dienstag, 19. Mai 2009 22:00:
> Dennis Lundberg wrote:
>>
>> Yes I'm aware of that. My concern is for those people who don't know
>> about that. What will happen if they declare
>> commons-logging:commons-logging without a version in their POM? Or
>> declare the spec
Good news - I think 3.3 is ready to go out. Interested if anyone
thinks there are any JIRA items that should go in.
Bad news - Both Clirr and Jardiff fall over with the following error:
Unable to locate enclosing class
org.apache.commons.collections.DoubleOrderedMap$1 for nested class
org.apache.
+1 (non-binding)
On Wed, May 20, 2009 at 9:59 AM, James Carman
wrote:
> On Tue, May 19, 2009 at 6:21 PM, Henri Yandell wrote:
>> That said - +1. Change the top level package name and groupId to math2.
>>
>> I'll be voting for Lang to be lang3. The only sane thing for us to do
>> until OSGi is th
+1
Luc Maisonobe wrote:
So let's vote on this proposal: change the top level package name on
[math] from org.apache.commons.math to org.apache.commons.math2.
[] +1 change the top level package name
[] 0 I don't care
[] -1 keep the old name
Vote open for 72 hours (up to Friday May 19th 20h00 U
the top level package renaming seem rare in the current big java project.
Binding the version to the package name is not a common strategy as well.
- Original Message -
From: "Luc Maisonobe"
To: "Commons Developers List"
Sent: Tuesday, May 19, 2009 1:06 PM
Subject: [VOTE] [math] top-level package name
So let's vote on this proposal: change the top level package name on
[math] from org.apache.commons.math to org.apache.commons.
On Tue, May 19, 2009 at 6:21 PM, Henri Yandell wrote:
> That said - +1. Change the top level package name and groupId to math2.
>
> I'll be voting for Lang to be lang3. The only sane thing for us to do
> until OSGi is the standard is to put the major version number in the
> package name. This is n
On Tue, May 19, 2009 at 1:06 PM, Luc Maisonobe wrote:
> Henri Yandell a écrit :
>> On Tue, May 19, 2009 at 3:53 AM, wrote:
>>> Hello,
>>>
>>> Considering the ongoing discussion in another thread, the current changes
>>> that have been done on [math] for the last months belong to the major
>>>
Craig L Russell a écrit :
> Sorry for excerpting.
>
> On May 19, 2009, at 2:14 PM, Luc Maisonobe wrote:
>
>> With different packages names, the situation is simpler to handle: you
>> can have both libraries (in any order) in your classpath without
>> problems. You can have both 1.2 even hidden de
On 19/05/2009, Craig L Russell wrote:
> Hi Ted,
>
> On May 19, 2009, at 2:10 PM, Ted Dunning wrote:
>
>
> > What about changing the package name to avoid jar hell?
> >
>
> I don't think there's jar hell.
>
> If users want to use 1.2, they do. If they want to upgrade to new features
> in 2.0, th
Sorry for excerpting.
On May 19, 2009, at 2:14 PM, Luc Maisonobe wrote:
With different packages names, the situation is simpler to handle: you
can have both libraries (in any order) in your classpath without
problems. You can have both 1.2 even hidden deep inside another jumbo
package and 2.0 w
Hi Ted,
On May 19, 2009, at 2:10 PM, Ted Dunning wrote:
What about changing the package name to avoid jar hell?
I don't think there's jar hell.
If users want to use 1.2, they do. If they want to upgrade to new
features in 2.0, they have to also accommodate the incompatible
changes in oth
But of course, with an incompatible change, much more than package name
needs to change!
I don't mind changing package name ... it goes very quickly with a good IDE.
On Tue, May 19, 2009 at 2:14 PM, Luc Maisonobe wrote:
> > What is the policy in the other Apache projects?
>
> It depends. Some ar
Dimitri Pourbaix a écrit :
> Ted,
>
>> +0. Possibly changing to +1 as I think about it more.
>>
>> Dimitry,
>>
>> Is there an argument that you could see would change your mind? What
>> specifically causes your -1? Convenience? Elegance?
>
> Well, for me, the release number is not part of the
What about changing the package name to avoid jar hell?
On Tue, May 19, 2009 at 2:07 PM, Craig L Russell wrote:
> What is the policy in the other Apache projects?
>>
>
> In OpenJPA, the policy is to make compatibility-breaking changes in a major
> release. So if you have a change to a signature o
On May 19, 2009, at 1:42 PM, Dimitri Pourbaix wrote:
Ted,
+0. Possibly changing to +1 as I think about it more.
Dimitry,
Is there an argument that you could see would change your mind? What
specifically causes your -1? Convenience? Elegance?
Well, for me, the release number is not par
He also wants to avoid jar hell. I have been there and sympathize with the
goal.
On Tue, May 19, 2009 at 1:42 PM, Dimitri Pourbaix
wrote:
> Luc wants to add the "2" just to
> warn the users about the lack of backward compatibility.
>
--
Ted Dunning, CTO
DeepDyve
Gilles Sadowski a écrit :
>> So let's vote on this proposal: change the top level package name on
>> [math] from org.apache.commons.math to org.apache.commons.math2.
>>
>> [] +1 change the top level package name
>> [] 0 I don't care
>> [] -1 keep the old name
>>
>
> -1
> But I don't know whether
Ted,
+0. Possibly changing to +1 as I think about it more.
Dimitry,
Is there an argument that you could see would change your mind? What
specifically causes your -1? Convenience? Elegance?
Well, for me, the release number is not part of the name of a package
(of anything in general) even
+0. Possibly changing to +1 as I think about it more.
Dimitry,
Is there an argument that you could see would change your mind? What
specifically causes your -1? Convenience? Elegance?
On Tue, May 19, 2009 at 1:23 PM, Dimitri Pourbaix
wrote:
> Hi,
>
> So let's vote on this proposal: change
> So let's vote on this proposal: change the top level package name on
> [math] from org.apache.commons.math to org.apache.commons.math2.
>
> [] +1 change the top level package name
> [] 0 I don't care
> [] -1 keep the old name
>
-1
But I don't know whether I'm allowed to vote... :-}
Best rega
Hi,
So let's vote on this proposal: change the top level package name on
[math] from org.apache.commons.math to org.apache.commons.math2.
[] +1 change the top level package name
[] 0 I don't care
[] -1 keep the old name
-1
Regards,
Dim.
-
Luc Maisonobe a écrit :
> Henri Yandell a écrit :
>> On Tue, May 19, 2009 at 3:53 AM, wrote:
>>> Hello,
>>>
>>> Considering the ongoing discussion in another thread, the current changes
>>> that have been done on [math] for the last months belong to the major
>>> changes with large incompatibil
Henri Yandell a écrit :
> On Tue, May 19, 2009 at 3:53 AM, wrote:
>> Hello,
>>
>> Considering the ongoing discussion in another thread, the current changes
>> that have been done on [math] for the last months belong to the major
>> changes with large incompatibilities with previous versions. We
Dennis Lundberg wrote:
Yes I'm aware of that. My concern is for those people who don't know
about that. What will happen if they declare
commons-logging:commons-logging without a version in their POM? Or
declare the special token LATEST as a version for commons-logging? Will
they get 1.1.1 or 0.
On Tue, May 19, 2009 at 2:54 PM, Gilles Sadowski
wrote:
> To be clearer, suppose that, as of now,
> * A (v1.0) depends on
> - B (v1.0)
> - Math (v1.2)
>
> * B (v1.0) depends on
> - Math (v1.2)
>
> Everything works fine, and will continue to work as long as A's code and its
> dependencies a
Gilles Sadowski a écrit :
> Hi.
>
>> Given that there *are* incompatibilities, I am +1 on the package renaming.
>>
>>> Should we change the top level package name from org.apache.commons.math to
>>> org.apache.commons.math2 ?
>>>
>
> I don't understand why version 2.0 should be assimilated to a
> > I don't understand why version 2.0 should be assimilated to a new project.
> > Is there someone who is going to work on the v1.2 code base? If not, what
> > is
> > the gain?
> > Anyone who has an application that runs under v1.2 can still use the
> > old JAR, which will be forever compatib
Ceki Gulcu wrote:
>
>
> Dennis Lundberg wrote:
>> Ceki Gulcu wrote:
>>> Hello all,
>>>
>>> I have created an empty Maven project with groupId "commons-logging",
>>> artifactId "commons-logging" and version 0.0.0-EMPTY. There is very
>>> little content (around 500 bytes) in the whole project. This
sebb a écrit :
> On 19/05/2009, James Carman wrote:
>> On Tue, May 19, 2009 at 6:53 AM, wrote:
>> > Hello,
>> >
>> > Considering the ongoing discussion in another thread, the current changes
>> that have been done on [math] for the last months belong to the major
>> changes with large incom
The output of f2j is almost unusable for normal mortals. There will
definitely be a wrapper layer.
Also, there is more than a wrapper in MTJ. There are also higher order
algorithms that use the lower level linear algebra provided by f2j.
On Tue, May 19, 2009 at 2:59 AM, Jin Mingjian wrote:
>
Hi Ceki,
Ceki Gulcu wrote at Dienstag, 19. Mai 2009 14:46:
> Jochen Wiedmann wrote:
>> On Tue, May 19, 2009 at 2:21 PM, Mario Ivankovits
>> wrote:
>>
>>> Nice would be, as opposite to the , to have a global
>>> , no?
>>>
>>> That way, problems like this are sorted out once and for all.
>>>
>>
On Tue, May 19, 2009 at 3:53 AM, wrote:
> Hello,
>
> Considering the ongoing discussion in another thread, the current changes
> that have been done on [math] for the last months belong to the major changes
> with large incompatibilities with previous versions. We have already decided
> that t
On 19/05/2009, Gilles Sadowski wrote:
> Hi.
>
>
> > Given that there *are* incompatibilities, I am +1 on the package renaming.
> >
>
> >> Should we change the top level package name from org.apache.commons.math
> >> to org.apache.commons.math2 ?
> >>
>
>
> I don't understand why version 2.0 sh
Hi.
> Given that there *are* incompatibilities, I am +1 on the package renaming.
>
>> Should we change the top level package name from org.apache.commons.math to
>> org.apache.commons.math2 ?
>>
I don't understand why version 2.0 should be assimilated to a new project.
Is there someone who is go
ATM https://issues.apache.org/jira/browse/RESOURCES has 'nightly builds'
as it's only release version
i was wondering about consolidating on a 1.0 release version
opinions?
- robert
-
To unsubscribe, e-mail: dev-unsubscr...@co
--- On Tue, 5/19/09, Jochen Wiedmann wrote:
> From: Jochen Wiedmann
> Subject: Re: commons-logging version 0.0.0-EMPTY
> To: "Commons Developers List"
> Date: Tuesday, May 19, 2009, 9:40 AM
> On Tue, May 19, 2009 at 2:46 PM, Ceki
> Gulcu
> wrote:
>
> > Jochen, you do realize that global ex
I follow you on the phyliosphical point of view, but sory we expect this
feature on maven for some years and don't see a solution before many months
(years ?)
Commons-logging historical succes don't make it reallu an "isolated" project
2009/5/19 Jochen Wiedmann
> On Tue, May 19, 2009 at 2:46 PM,
On Tue, May 19, 2009 at 2:46 PM, Ceki Gulcu wrote:
> Jochen, you do realize that global exclusions would suffer from the same
> problems as you described in the A B C scenario. Here is a slightly modified
> version of your scenario.
May be, but I'd rather have the overall Maven community work on
> >> Nice would be, as opposite to the , to have a global
> >> , no?
> >>
> >> That way, problems like this are sorted out once and for all.
> >>
> >
> > +1
> Jochen, you do realize that global exclusions would suffer from the same
> problems as you described in the A B C scenario.
The same p
This is required (at least the default impl) for MATH-136 (Spearman's
corr). I am not in love with the API, but need something to use for
Spearman's. In particular, I am not sure the "strategy" enums should be
public (or even exist? Problem is too many combinations to make little
impls for e
luc.maison...@free.fr wrote:
Hello,
Considering the ongoing discussion in another thread, the current changes that
have been done on [math] for the last months belong to the major changes with
large incompatibilities with previous versions. We have already decided that
the version number will
Jim Jagielski wrote:
On May 18, 2009, at 4:46 PM, Mark Thomas wrote:
Phil Steitz wrote:
Mark Thomas wrote:
I have finished working my way through the open POOL bugs.
Of the remaining issues, 2 are bugs that only affect the 2.0 branch
and
rest are improvements.
Given that Tomcat is waitin
>
> nicolas de loof wrote:
>
>> A library autor that MAY use cl-0.0 to remove commons-logging from
>> dependency tree and use SLF4J will anyway have a dependency on
>> cl-over-sfl4j
>> that solves the ClassNotFoundException
>>
>
> Good point but what if the end-user wanted to use commons-logging pr
Jochen Wiedmann wrote:
On Tue, May 19, 2009 at 2:21 PM, Mario Ivankovits wrote:
Nice would be, as opposite to the , to have a global ,
no?
That way, problems like this are sorted out once and for all.
+1
Jochen, you do realize that global exclusions would suffer from the same
problem
The "global exclusion" is rquested since ... some years (I can't exactly
remember, but I've seen it in Jira for a while) and can't be fixed until the
POM schema is changed - something that cannot occur before maven 3.x, so one
or two years.
(For info, the issue with POM format change is that it req
On 19/05/2009, James Carman wrote:
> On Tue, May 19, 2009 at 6:53 AM, wrote:
> > Hello,
> >
> > Considering the ongoing discussion in another thread, the current changes
> that have been done on [math] for the last months belong to the major changes
> with large incompatibilities with previ
nicolas de loof wrote:
A library autor that MAY use cl-0.0 to remove commons-logging from
dependency tree and use SLF4J will anyway have a dependency on cl-over-sfl4j
that solves the ClassNotFoundException
Good point but what if the end-user wanted to use commons-logging proper and not
SLF4J?
Hi Mario,
Global exclusions in Maven would provide a solution with essentially
the same problems and dangers as with 0.0-EMPTY. Anyway, global exclusions have
been requested in the past but afaik nothing came of it. Hence,
0.0-EMPTY.
Mario Ivankovits wrote:
Hmmm
Couldn't we ask the maven
On Tue, May 19, 2009 at 2:21 PM, Mario Ivankovits wrote:
> Nice would be, as opposite to the , to have a global
> , no?
>
> That way, problems like this are sorted out once and for all.
>
>
> Or do I miss something?
+1
--
Don't trust a government that doesn't trust you.
Hmmm
Couldn't we ask the maven devs to extend the pom to allow "global excludes"?
The only thing this 0.0 stuff solves, is, that the user does not need to
exclude commons-logging from each and every dependency.
What you can do ... and what I did.
Nice would be, as opposite to the , to have
A library autor that MAY use cl-0.0 to remove commons-logging from
dependency tree and use SLF4J will anyway have a dependency on cl-over-sfl4j
that solves the ClassNotFoundException
A library that uses slf4j would anyway only declare slf4japi as dependency
and has no reason to force exclusion of c
Jörg Schaible wrote:
Forgive me for asking, but were you aware of the above. And if you
were, would you care to explain a scenario in mind which is troubling
you?
First: The solution is perfect for a normal user i.e. somebody building an
application, not a library/framework. The problem star
On Tue, May 19, 2009 at 6:53 AM, wrote:
> Hello,
>
> Considering the ongoing discussion in another thread, the current changes
> that have been done on [math] for the last months belong to the major changes
> with large incompatibilities with previous versions. We have already decided
> that t
I'd would agree with you if the proposal was to deploy a "99" version.
The 0.0 version is safer whatever dependency strategy you choose : 0.0 will
be considered < to any other version by any comparator-based version
strategy. Maven "nearest" strategy (that is not the simple one to debug)
will not
On May 18, 2009, at 4:46 PM, Mark Thomas wrote:
Phil Steitz wrote:
Mark Thomas wrote:
I have finished working my way through the open POOL bugs.
Of the remaining issues, 2 are bugs that only affect the 2.0
branch and
rest are improvements.
Given that Tomcat is waiting on a DBCP release a
Hi Ceki,
Ceki Gulcu wrote at Dienstag, 19. Mai 2009 12:18:
>
>
> Dennis Lundberg wrote:
>> Ceki Gulcu wrote:
>>> Hello all,
>>>
>>> I have created an empty Maven project with groupId "commons-logging",
>>> artifactId "commons-logging" and version 0.0.0-EMPTY. There is very
>>> little content (a
On Tue, May 19, 2009 at 12:18 PM, Ceki Gulcu wrote:
> Forgive me for asking, but were you aware of the above. And if you
> were, would you care to explain a scenario in mind which is troubling
> you?
Forgive me for asking, Ceki, but are you aware of the fact, how
frequently dependency resolution
Hello,
Considering the ongoing discussion in another thread, the current changes that
have been done on [math] for the last months belong to the major changes with
large incompatibilities with previous versions. We have already decided that
the version number will be 2.0 to acknowledge that. I
Dennis Lundberg wrote:
Ceki Gulcu wrote:
Hello all,
I have created an empty Maven project with groupId "commons-logging",
artifactId "commons-logging" and version 0.0.0-EMPTY. There is very
little content (around 500 bytes) in the whole project. This is to be
expected as the original aim was
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-configuration-test has an issue affecting its community
integrati
Can I ask a question? how about MTJ vs pure F2J? (If I don't use the native
part of MTJ.)
Can I get more must-have things? is it necessary to introduce a wrapper
layer?
Best regards,
Jin
Bill, I strongly discourage adding these methods at this time. We will regret
it.
If you don't want to change (i.e. add new methods) to an interface, then the
sensible thing is to omit these interfaces for 2.0 and introduce them with
2.1.
Bill Barker wrote:
>
> What I actually went for is to a
65 matches
Mail list logo
