+1
Gary Gregory schrieb am So., 5. Juni 2016 um 03:04:
> On Sat, Jun 4, 2016 at 5:06 PM, Niall Pemberton >
> wrote:
>
> > On Sun, Jun 5, 2016 at 12:56 AM, Gary Gregory
> > wrote:
> >
> > > On Sat, Jun 4, 2016 at 4:53 PM, Niall Pemberton <
> > niall.pember...@gmail.com
> > > >
> > > wrote:
> >
On 5 June 2016 at 04:24, Gary Gregory wrote:
> I think it would be nice to have a link to a Javadoc site for ALL
> components in one lump.
>
> This would go on the main page.
>
> Thoughts?
Not sure I see the need.
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persis
Hi,
Gary Gregory schrieb am So., 5. Juni 2016 um
05:24 Uhr:
> I think it would be nice to have a link to a Javadoc site for ALL
> components in one lump.
>
> This would go on the main page.
> Thoughts?
>
I don't have a need for this. If you're looking for a way to browse all the
JavaDocs, I r
On 4 June 2016 at 15:19, Ponomarenko Andrey wrote:
> Hello,
>
> I've just prepared the report on backward compatibility for the Commons IO
> library (BC — binary compatibility, SC — source compatibility):
> http://abi-laboratory.pro/java/tracker/timeline/commons-io/
Thanks for the links.
Howev
+1, showing the Code of Conduct is important also to encourage
contributions and engagement from underrepresented groups.
On 5 Jun 2016 8:47 a.m., "Benedikt Ritter" wrote:
+1
Gary Gregory schrieb am So., 5. Juni 2016 um 03:04:
> On Sat, Jun 4, 2016 at 5:06 PM, Niall Pemberton >
> wrote:
>
> >
I think one advantage is that this timeline output shows all the registered
versions, while Clirr is just for the "previous" version (?). Perhaps it is
also more user-friendly presentation?
On 5 Jun 2016 7:59 a.m., "Benedikt Ritter" wrote:
> How would that be different from Clirr?
>
> Gary Gregor
No, only if it is *enforced* will people start to feel safe and throw out
their new ideas. The trick is making people aware that poor behavior won't
be tolerated. Enforcement starts with the community stepping in and saying
"now, that was uncalled for" or "we do not allow personal attacks" or
whate
Well thanks ! I am new in open source . This helped a lot .
On Sunday, June 5, 2016, James Carman wrote:
> No, only if it is *enforced* will people start to feel safe and throw out
> their new ideas. The trick is making people aware that poor behavior won't
> be tolerated. Enforcement starts wi
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
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
Hello Pascal,
I'd like to have more people who are able to RM for our components. How
about we make an appointment and then do a Hangout/Skype call and I give
you a walk through?
Benedikt
Pascal Schumacher schrieb am Do., 2. Juni 2016
um 23:19 Uhr:
> should be "If somebody else would like to R
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
I think a mere indirection page could do, but see many potential
maintenance issues with updating a single Javadoc folder across Commons
components.
Perhaps we can provide a common XML for Javadoc external references or
there is a Javadoc aggregation tool we could use?
On 5 Jun 2016 4:24 a.m., "Ga
Another thing that has to be resolved before a release. When I run "mvn
clirr:check", clirr reports errors for these classes:
org.apache.commons.lang3.time.DateParser
org.apache.commons.lang3.time.DatePrinter
org.apache.commons.lang3.time.FastDatePrinter
I would have pasted them, but it shows me
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
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 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
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 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
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
SUBMISSION TYPE: TSU
SUBMITTED BY: Gary Gregory
SUBMITTED FOR:Apache Software Foundation
POINT OF CONTACT: Secretary, Apache Software Foundation
EMAIL:secret...@apache.org
FAX: +1-919-573-9199
MANUFACTURER(S):
The Apache Software Foundatio
Hello.
Commons Math as it was in the last official release (v3.6.1) and
consequently as it is in the current development branch has
become unmaintainable.
This conclusion is unavoidable when looking at the following:
1. codebase statistics (as of today):
* src/main/java 90834 lines of
Thanks Benedikt and Stian for the instructions!
Will do that.
Regards,
Haifeng
-Original Message-
From: Stian Soiland-Reyes [mailto:st...@apache.org]
Sent: Saturday, June 4, 2016 6:52 PM
To: Commons Developers List
Subject: Re: US Export classification & ECCN registration for encryptio
23 matches
Mail list logo
