On 10/17/2014 03:52 AM, Gary Gregory wrote:
On Thu, Oct 16, 2014 at 9:15 PM, sebb seb...@gmail.com wrote:
On 15 October 2014 14:19, ggreg...@apache.org wrote:
Author: ggregory
Date: Wed Oct 15 13:19:50 2014
New Revision: 1632011
URL: http://svn.apache.org/r1632011
Log:
Update Oracle
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
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
On 17 October 2014 09:07, Emmanuel Bourg ebo...@apache.org 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
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:
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 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 changes
Hi,
2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
snip
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
2014-10-17 12:23 GMT+02:00 Benedikt Ritter brit...@apache.org:
Hi,
2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
snip
In TomEE the stack uses [lang], then [lang3] was created and now TomEE
needs [lang] + [lang3] where actually it only needs [lang] features,
ie
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
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
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 brit...@apache.org:
Hi,
2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
snip
In TomEE the stack uses [lang], then [lang3] was created
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,
2014-10-17 13:52 GMT+02:00 Gary Gregory garydgreg...@gmail.com:
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 brit...@apache.org:
Hi,
2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
2014-10-17 13:52 GMT+02:00 Gary Gregory garydgreg...@gmail.com:
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 brit...@apache.org:
Hi,
2014-10-17 15:28 GMT+02:00 Benedikt Ritter brit...@apache.org:
2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
2014-10-17 13:52 GMT+02:00 Gary Gregory garydgreg...@gmail.com:
On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau
rmannibu...@gmail.com
wrote:
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 rmannibu...@gmail.com wrote:
2014-10-17 15:28 GMT+02:00 Benedikt
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
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
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
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
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 rory.odonn...@oracle.com wrote:
Hi Benedict,
As I already mentioned we have prepared guidance on migrating some of the
more common usage patterns of JDK-internal
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:
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 rory.odonn...@oracle.com wrote:
Hi Benedict,
As I already mentioned we have prepared
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.
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
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
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
https://issues.apache.org/jira/browse/INFRA-8382
On 17 October 2014 19:06, Bernd Eckenfels e...@zusammenkunft.net 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
On 17 October 2014 19:08, Romain Manni-Bucau rmannibu...@gmail.com 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
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 seb...@gmail.com a écrit :
On 17 October 2014 19:08, Romain Manni-Bucau rmannibu...@gmail.com
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
On 17 October 2014 19:49, Ole Ersoy ole.er...@gmail.com 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
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
On 17 Oct 2014 21:11, Romain Manni-Bucau rmannibu...@gmail.com 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
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
On 17 October 2014 21:16, Hank Grabowski h...@applieddefense.com 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
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
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
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
On 17 October 2014 21:37, Romain Manni-Bucau rmannibu...@gmail.com 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
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 seb...@gmail.com wrote:
On 17 October 2014 21:37,
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 seb...@gmail.com 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
On 17 October 2014 21:57, Paul Benedict pbened...@apache.org 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,
On 10/17/2014 03:12 PM, sebb wrote:
On 17 October 2014 19:49, Ole Ersoy ole.er...@gmail.com 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
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
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 jamessa...@hotmail.com wrote:
Whilst the changes are the same as the Java 7 implementations, these in
On 17 October 2014 22:56, James Sawle jamessa...@hotmail.com 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
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
On 17 October 2014 23:41, James Sawle jamessa...@hotmail.com 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
50 matches
Mail list logo
