On 17 October 2014 23:41, James Sawle wrote:
> How do you create new implementations of such basic functionality that is so
> explicitly defined within the API? It is like suggesting that we write 1+1 as
> 1+((1+1)-1) just to look different.
I think sometimes it's about knowing you did it right
How do you create new implementations of such basic functionality that is so
explicitly defined within the API? It is like suggesting that we write 1+1 as
1+((1+1)-1) just to look different.
They should also be made public as they are still useful for Java 6 and prior
(and unfortunately there a
On 17 October 2014 22:56, James Sawle wrote:
> Whilst the changes are the same as the Java 7 implementations, these in fact
> came from OpenJDK implement ions and match the expected behaviour as defined
> by the Javadoc. Any effort to change these so that that have less resemblance
> to the Ora
I apologise for the spelling mistakes in the previous message. Need to remember
not to send messages after drinks on a Friday :p
Sent from my iPhone
> On 17 Oct 2014, at 22:56, James Sawle wrote:
>
> Whilst the changes are the same as the Java 7 implementations, these in fact
> came from Open
Whilst the changes are the same as the Java 7 implementations, these in fact
came from OpenJDK implement ions and match the expected behaviour as defined by
the Javadoc. Any effort to change these so that that have less resemblance to
the Oracle implementation will just cause detrimental side ef
On 10/17/2014 03:12 PM, sebb wrote:
On 17 October 2014 19:49, Ole Ersoy wrote:
Hi,
I'm following the discussion of how MATH-1138 was handled (Which I enjoy
reading because I'm very impressed with how eloquently everyone communicates
their points of view).
Just a warning that I might be ignor
On 17 October 2014 21:57, Paul Benedict wrote:
> FWIW, I have found no difficulty moving code from lang2 to lang3. It's a
> breeze. I did a wholesale replacement of the package name and then fixed
> any compiler problems due to API differences.
Which is why we do it that way, rather than renaming
Each project that finds itself in a mess with have to do explicit
excludes... bummer
Gary
On Fri, Oct 17, 2014 at 3:37 PM, sebb wrote:
> I see; that will really mess up the Maven classpath, because it won't
> be able to detect that
>
> com.sun.mail:javax.mail:1.5.2
>
> is a later version of
>
>
FWIW, I have found no difficulty moving code from lang2 to lang3. It's a
breeze. I did a wholesale replacement of the package name and then fixed
any compiler problems due to API differences.
Cheers,
Paul
On Fri, Oct 17, 2014 at 3:51 PM, sebb wrote:
> On 17 October 2014 21:37, Romain Manni-Buc
On 17 October 2014 21:37, Romain Manni-Bucau wrote:
> Each time you break an api extract this part in compatibility (deprecated)
> n-1 jar and export new one in the v n jar. Grabbing pom dependecy you get
> by default n jars but if you want you can exclude include jars to get n-1
> apis and moreov
Each time you break an api extract this part in compatibility (deprecated)
n-1 jar and export new one in the v n jar. Grabbing pom dependecy you get
by default n jars but if you want you can exclude include jars to get n-1
apis and moreover you didnt break anything for 80% of users.
I know it is f
Hi Hank.
On Fri, 17 Oct 2014 11:31:26 -0400, Hank Grabowski wrote:
Gilles,
This is the original changes to get the bicubic spline working. These
were
originally committed as a diff that was attached to the JIRA
incident. The
suggestions in your email were in response to my questions about w
Ah, that is a more complicated question. Those discussions definitely
aren't part of the repository. As someone now recently bitten by the
confusion in where discussions should be taking place, I agree there should
be a good documentation of those swim lanes. I'm new to contributing to
open sour
On 17 October 2014 21:16, Hank Grabowski wrote:
> The nice thing about Github, from my perspective as a person with only
> read-only access to the ASF repositories, is that it provides me with the
> ability to work in my own fork and then initiate pull requests that can be
> incorporated into the
GitHub user janmaterne opened a pull request:
https://github.com/apache/commons-lang/pull/34
Multiline recursive to string style
Works with ToStringBuilder to create a "deep" toString().
But instead a single line like the RecursiveToStringStyle this creates a
multiline String s
On 17 Oct 2014 21:11, "Romain Manni-Bucau" wrote:
>
> Yes, that what i said we were not impacted even if the stack is big.
>
> Once again in theory you are right but in practise that's boring and
> creates averhead for nothing.
You're not making a lot of sense here. Sebb explained a problem with
The nice thing about Github, from my perspective as a person with only
read-only access to the ASF repositories, is that it provides me with the
ability to work in my own fork and then initiate pull requests that can be
incorporated into the root repository. I think it is still ideal that the
GitH
On 17 October 2014 19:49, Ole Ersoy wrote:
> Hi,
>
> I'm following the discussion of how MATH-1138 was handled (Which I enjoy
> reading because I'm very impressed with how eloquently everyone communicates
> their points of view).
>
> Just a warning that I might be ignoring [2] (Stolen from Gilles)
I didn't want to address the situation in my original response since I was
on a smart phone, a bit torqued up by the original e-mail and I didn't want
to further agitate the situation by addressing the original
implementation. Since it seems that's all happened anyway, if you still
want my newbie
Yes, that what i said we were not impacted even if the stack is big.
Once again in theory you are right but in practise that's boring and
creates averhead for nothing.
Le 17 oct. 2014 22:08, "sebb" a écrit :
> On 17 October 2014 19:08, Romain Manni-Bucau
> wrote:
> > I did it twice or more. it
On 17 October 2014 19:08, Romain Manni-Bucau wrote:
> I did it twice or more. it is not magic but the goal is to put
> removed/changed classes outside the core project (yes it implies some
> modules). this way the core part (what i call core here is what
> doesn't change) stays the same with same
https://issues.apache.org/jira/browse/INFRA-8382
On 17 October 2014 19:06, Bernd Eckenfels wrote:
> Hello,
>
> was this an automatically generated patch mail or is this coming from
> the ASF GIT? In the later case, I wonder if it is possible to
> includethe [Math] tag or at least the repo name/pa
A related issue: when filing a JIRA from the pull request, please
include more than just the PR URL.
I think it's important that the JIRA can be understood without having
to follow the URL.
We don't have control over Github; it could disappear or change URL one day.
I think it's important that o
I see; that will really mess up the Maven classpath, because it won't
be able to detect that
com.sun.mail:javax.mail:1.5.2
is a later version of
javax.mail:mail:1.4.7
So if there are dependencies on both, then both will be added to the classpath.
They also appear to have created copies of most
On 17.10.2014 21:20, Paul Libbrecht wrote:
Thanks Rory,
why would org.w3c.* or org.relaxng.* be JDK internal?
Please see http://docs.oracle.com/javase/8/docs/api/ for a list of Java
SE 8 API packages. Neither org.relaxng nor org.w3c.dom.html/ranges are
part of it.
cheers,
dalibor topic
Thanks Rory,
why would org.w3c.* or org.relaxng.* be JDK internal?
Does it mean… it's going to be included in JDK 9? (probably as a conflicting
version with some priority to included jars thus maybe breaking) ?
Those are trusted software providers since years (Jelly is quite old).
paul
On 17
Hi all,
Le 17/10/2014 16:23, Gilles a écrit :
> Hi.
>
> On Fri, 17 Oct 2014 10:46:53 +0200, Luc Maisonobe wrote:
>> Hi Hank,
>>
>> Le 16/10/2014 20:20, Hank Grabowski a écrit :
>>> OK. I submitted the pull request yesterday. I'm going to now remove
>>> the
>>> diff from JIRA.
>>>
>>> https://gi
commons-launcher attached.
Rgds,Rory
On 17/10/2014 19:22, Paul Libbrecht wrote:
Rory,
I see no attachments here. Can you post it to some web-place please?
paul
On 17 oct. 2014, at 10:42, Rory O'Donnell wrote:
Hi Benedict,
As I already mentioned we have prepared guidance on migrating some
Hi,
I'm following the discussion of how MATH-1138 was handled (Which I enjoy
reading because I'm very impressed with how eloquently everyone communicates
their points of view).
Just a warning that I might be ignoring [2] (Stolen from Gilles), because I
have suggested this before:
Let me try one at a time - commons-jelly attached.
Rgds,Rory
On 17/10/2014 19:22, Paul Libbrecht wrote:
Rory,
I see no attachments here. Can you post it to some web-place please?
paul
On 17 oct. 2014, at 10:42, Rory O'Donnell wrote:
Hi Benedict,
As I already mentioned we have prepared gu
Rory,
I see no attachments here. Can you post it to some web-place please?
paul
On 17 oct. 2014, at 10:42, Rory O'Donnell wrote:
> Hi Benedict,
>
> As I already mentioned we have prepared guidance on migrating some of the
> more common usage patterns of JDK-internal APIs
> to supported publ
I did it twice or more. it is not magic but the goal is to put
removed/changed classes outside the core project (yes it implies some
modules). this way the core part (what i call core here is what
doesn't change) stays the same with same packages and only what moves
changes.
I know it is easier to
Hello,
was this an automatically generated patch mail or is this coming from
the ASF GIT? In the later case, I wonder if it is possible to
includethe [Math] tag or at least the repo name/path in the subject?
Gruss
Bernd
Am
Fri, 17 Oct 2014 08:41:27 - schrieb l...@apache.org:
> Merge remote
On 10/17/14 6:57 AM, Romain Manni-Bucau wrote:
> Well maven showed the opposite. And this is clearly a theory vs practise
> topic so not sure it does worth allimenting this thread since well not agree
Top-posting this kind of statement does no good. If you have a
better approach, please describe
Lets calm down, guys. As Luc said, we are experimenting here,
getting the git workflow established. No one is trying to exclude
or discourage anyone. Hank or Luc, can you respond to Gilles'
questions about the commit? If not, it should be reverted, but
hopefully you can all three agree on a way
Gilles,
This is the original changes to get the bicubic spline working. These were
originally committed as a diff that was attached to the JIRA incident. The
suggestions in your email were in response to my questions about work
carrying forward from that point.
I have been very explicit and verb
Hi.
On Fri, 17 Oct 2014 10:46:53 +0200, Luc Maisonobe wrote:
Hi Hank,
Le 16/10/2014 20:20, Hank Grabowski a écrit :
OK. I submitted the pull request yesterday. I'm going to now
remove the
diff from JIRA.
https://github.com/apache/commons-math/pull/2
Thank you. I have merged this request
Well maven showed the opposite. And this is clearly a theory vs practise
topic so not sure it does worth allimenting this thread since well not agree
Le 17 oct. 2014 15:52, "Matt Benson" a écrit :
> It's not just the broken parts that your dependencies may be using. The
> strategy Commons uses is
I think some people find it unseemly to have both commons 2 and 3 jars in
the classpath. It's OK. This is how a project can make major improvements
and not affect previous clients -- because the package names are different.
The two can live together just fine.
Cheers,
Paul
On Fri, Oct 17, 2014 a
It's not just the broken parts that your dependencies may be using. The
strategy Commons uses is the only way any of us know to permit forward
movement while avoiding jar hell.
Matt
On Oct 17, 2014 8:35 AM, "Romain Manni-Bucau" wrote:
> 2014-10-17 15:28 GMT+02:00 Benedikt Ritter :
> > 2014-10-17
2014-10-17 15:28 GMT+02:00 Benedikt Ritter :
> 2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau :
>
>> 2014-10-17 13:52 GMT+02:00 Gary Gregory :
>> > On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> > wrote:
>> >
>> >> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter :
>> >
2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau :
> 2014-10-17 13:52 GMT+02:00 Gary Gregory :
> > On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> >> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter :
> >> > Hi,
> >> >
> >> > 2014-10-16 15:30 GMT+02:00 Romain
2014-10-17 13:52 GMT+02:00 Gary Gregory :
> On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau
> wrote:
>
>> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter :
>> > Hi,
>> >
>> > 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau :
>> >
>> >
>> >
>> >>
>> >> In TomEE the stack uses [lang], then [lang3] was
Thanks for the heads up. I had core.autocrlf set to true in my git global
settings but maybe GitHub's software wasn't honoring it without the
explicit gitattributes file, that I've now configured. We will see when I
do a pull request for some of those other features in the near future.
On Fri, O
On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau
wrote:
> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter :
> > Hi,
> >
> > 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau :
> >
> >
> >
> >>
> >> In TomEE the stack uses [lang], then [lang3] was created and now TomEE
> >> needs [lang] + [lang3] where
Hi,
James has authored a fine patch for LANG-536 (see below), but it does
include some code that exactly matches Java 7 source. Specifically,
the various compare(primitive, primitive) methods that have been added
to BooleanUtils, NumberUtils and CharUtils are identical to the
methods provided in J
GitHub user alexanderkjall opened a pull request:
https://github.com/apache/commons-collections/pull/4
clarified javadoc for getKey() and size()
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/alexanderkjall/commons-collections p
2014-10-17 12:23 GMT+02:00 Benedikt Ritter :
> Hi,
>
> 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau :
>
>
>
>>
>> In TomEE the stack uses [lang], then [lang3] was created and now TomEE
>> needs [lang] + [lang3] where actually it only needs [lang] features,
>> ie suppose package didn't change then
Hi,
2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau :
>
> In TomEE the stack uses [lang], then [lang3] was created and now TomEE
> needs [lang] + [lang3] where actually it only needs [lang] features,
> ie suppose package didn't change then we wouldn't have had any issue.
> So it means you tend to
Hi Hank,
Le 16/10/2014 20:20, Hank Grabowski a écrit :
> OK. I submitted the pull request yesterday. I'm going to now remove the
> diff from JIRA.
>
> https://github.com/apache/commons-math/pull/2
Thank you. I have merged this request and pushed the result to our main
repository. The only chan
Hi Benedict,
As I already mentioned we have prepared guidance on migrating some of
the more common usage patterns of JDK-internal APIs
to supported public interfaces. The list is on the OpenJDK wiki [0],
along with instructions on how to run the jdeps analysis tool yourself .
I have prepared
Hi Benedict,
As part of the preparations for JDK 9, Oracle's engineers have been
analyzing open source projects like
yours to understand usage. One area of concern involves identifying
compatibility problems, such as
reliance on JDK-internal APIs.
Our engineers have already prepared guidance
Le 17/10/2014 10:16, Duncan Jones a écrit :
> Do you happen to know if GitHub will react to commit messages from SVN
> in order to close PRs, such as described in [1]?
Yes it does.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-
On 17 October 2014 09:07, Emmanuel Bourg wrote:
> Le 17/10/2014 09:44, Duncan Jones a écrit :
>
>> Is there a preferred approach to take here? I have a GitHub account,
>> so presumably I could be given rights to the repositories I commit to
>> (lang) and this would allow me to merge PRs directly i
Le 17/10/2014 09:44, Duncan Jones a écrit :
> Is there a preferred approach to take here? I have a GitHub account,
> so presumably I could be given rights to the repositories I commit to
> (lang) and this would allow me to merge PRs directly into trunk. Would
> such changes be reflected in our SVN
Hi everyone,
Some of our contributors like to use GitHub pull requests (PRs) as a
means of providing patches. Until now, I've tended to access the
.patch version of these pull requests and apply them in SVN.
Is there a preferred approach to take here? I have a GitHub account,
so presumably I coul
56 matches
Mail list logo
