In fact, you don’t even need to change the minor version (assuming this is
the only thing being done). You can just do a “point release”, changing
only the third digit, or 3.9.1
On Sat, Aug 24, 2019 at 9:43 PM Bruno P. Kinoshita wrote:
> I think it makes sense, good to go with 3.x then. Thanks
If you feel nervous, you can always push a branch or something and let
folks take a look.
On Sat, Jul 20, 2019 at 8:06 PM Matt Sicker wrote:
> I believe it’s CTR on Pool, so go for it.
>
> On Sat, Jul 20, 2019 at 18:45, Phil Steitz wrote:
>
> > I am working on a patch for POOL-361. I think the
On Wed, Jun 26, 2019 at 7:15 PM Gary Gregory wrote:
> We do not have a 1.0, so it is OK to break BC IMO.
+1
Fair enough. And very good point. It only came to mind for me, because of
the work stuff. Thanks
On Thu, Jun 13, 2019 at 9:09 AM Gary Gregory wrote:
> On Thu, Jun 13, 2019 at 8:51 AM James Carman
> wrote:
>
> > SCXML seems to have stalled quite a bit. I’m not trying to t
I’ve encouraged them to contribute upstream and help out. If a regular
project was in this sort of trouble, the PMC would want to report it. Do
we need to do the same for our sub modules?
On Thu, Jun 13, 2019 at 8:33 AM Gary Gregory wrote:
> On Thu, Jun 13, 2019 at 8:30 AM James Carman
>
Should we mention the issues with SCXML2?
On Thu, Jun 13, 2019 at 8:25 AM Gary Gregory wrote:
> ## Description:
> - Apache Commons is an Apache project focused on all aspects of reusable
>Java components.
>
> ## Issues:
> - There are no issues requiring board attention at this time.
>
> ##
I like it. Seems like a logical thing to do. Another idea would be adding
at an arbitrary index.
On Wed, Jun 12, 2019 at 5:04 PM Gary Gregory wrote:
> Hi All:
>
> We have org.apache.commons.lang3.ArrayUtils.add(T[], T).
>
> WDYT about adding a method that adds the element at the beginning of t
On Sun, Jun 9, 2019 at 7:36 AM sebb wrote:
>
> Huh?
> That can still cause jar issues, *precisely because* only one jar will
> reach the Java classpath.
>
> Suppose there is jar1 with API-V1.
> This is depended on by app1 and app2.
>
> Then jar2 is produced with API-V2 (not BC-compatible with API
On Sun, Jun 9, 2019 at 5:40 AM Gilles Sadowski wrote:
>
> Ultimately the PMC still needs to vote on the release, no?
> Hence I don't see what advantage there is in allowing different
> beta policies. [Of course, no component is required to provide
> a beta release...]
> What the proposal aims to
On Wed, Jun 5, 2019 at 12:16 PM Gilles Sadowski wrote:
>
> Case mainly in point is getting to the first release of new components.
> This is happening now for [Imaging], and will be soon (hopefully) for
> [Numbers], [Statistics] and [Geometry].
>
Okay, so the main issue is getting releases out in
,
just explaining why I’m having a hard time understanding what you’re
doing. Maybe this will be a learning opportunity for me! :)
On Wed, Jun 5, 2019 at 11:33 AM Gilles Sadowski
wrote:
> Le mer. 5 juin 2019 à 17:04, James Carman a
> écrit :
> >
> > What sort of comparison are
What sort of comparison are you looking to do within the same code?
Performance?
On Wed, Jun 5, 2019 at 10:54 AM Gilles Sadowski
wrote:
> Le mer. 5 juin 2019 à 16:22, sebb a écrit :
> >
> > On Wed, 5 Jun 2019 at 15:06, Gilles Sadowski
> wrote:
> > >
> > > Le mer. 5 juin 2019 à 15:59, sebb a é
Wouldn’t you have a package collision between two different alpha releases?
On Wed, Jun 5, 2019 at 10:56 AM Gilles Sadowski
wrote:
> Le mer. 5 juin 2019 à 16:47, James Carman a
> écrit :
> >
> > Ok, what about 1.2?
>
> How is it different?
>
> Gilles
>
> &
Ok, what about 1.2?
On Wed, Jun 5, 2019 at 10:44 AM Gilles Sadowski
wrote:
> Le mer. 5 juin 2019 à 16:18, James Carman a
> écrit :
> >
> > What happens if/when you want to release a 2.0-alpha1 in the future?
>
> Hmm, what happens?
> [At point, we'
What happens if/when you want to release a 2.0-alpha1 in the future?
On Tue, Jun 4, 2019 at 6:53 AM Gilles Sadowski wrote:
> Hello.
>
> Does someone see a practical way to automate package names
> and source files conversions so that each all alpha/beta releases
> can be used together (e.g. to c
ed my colleagues to get involved and start submitting
PRs. Perhaps we'll get some "new blood" to help revive SCXML. Thanks
to Ate and Woonsan for their hard work on this library! The folks at
work are really digging using it!
Thanks,
James
On Fri, May 17, 2019 at 6:00 PM James
A coworker of mine was wanting to use SCXML2. Obviously we can't use
SNAPSHOTs in production, so I was just wondering if we are close to
buttoning up 2.0. If need be, I can offer to help get it out the door
(it has been a while).
Thanks,
James
--
I wish to resign from the Apache Commons PMC. Thank you.
Could we start something in the sandbox? It's not modifying existing code.
On Sat, Jun 18, 2016 at 8:43 AM Jörg Schaible wrote:
> Hi Gilles,
>
> Gilles wrote:
>
> > Hi.
> >
> > On Fri, 17 Jun 2016 16:01:20 -0700, Ted Dunning wrote:
> >> Gilles,
> >>
> >> Thanks for links.
> >>
> >> I just read t
We should probably tally the votes at this point, but it is pretty clear
that there is no consensus, unfortunately. I honestly have no idea what to
do at this point. I have limited connectivity today.
On Fri, Jun 17, 2016 at 12:51 PM Benedikt Ritter wrote:
> James Carman schrieb am Sa.,
the philosophy
(if we want to maintain that philosophy).
On Tue, Jun 14, 2016 at 10:57 AM Gary Gregory
wrote:
> On Jun 14, 2016 7:51 AM, "James Carman"
> wrote:
> >
> > The trick is if we want to require a major version upgrade to bump JDK
> > levels. That
s a show stopper for Daikon. It will continue to be shipped with our
> private version of BCEL if it is not fixed.
>
> > -Original Message-
> > From: James Carman [mailto:ja...@carmanconsulting.com]
> > Sent: Tuesday, June 14, 2016 8:51 AM
> > To: Commons Devel
Are they show stoppers?
On Tue, Jun 14, 2016 at 11:50 AM Mark Roberts
wrote:
> I can tell you right now I would vote -1 as you have not picked up the fix
> for https://issues.apache.org/jira/browse/BCEL-243.
>
> Also, I think https://issues.apache.org/jira/browse/BCEL-195 is fixed,
> but has not
Can folks perhaps combine commons-io to help?
On Tue, Jun 14, 2016 at 11:27 AM Gary Gregory
wrote:
> On Jun 14, 2016 5:19 AM, "James Carman"
> wrote:
> >
> > Are Readers that hard to create?
>
> No, but remembering how to do this is a pain:
>
>
mplementers of
> > > > this
> > > > * interface outside of the framework will be broken in
> future
> > > > * releases when methods are added to this interface.
> > > > *
> > > > * @since 1.0
> > > > *
>
The trick is if we want to require a major version upgrade to bump JDK
levels. That's why you'd want to bump it now if possible.
On Tue, Jun 14, 2016 at 10:41 AM Matt Sicker wrote:
> I'd prefer to get to 1.7 as soon as possible, but if the API is ready for a
> 1.0 release already, we could wait
Are Readers that hard to create?
On Tue, Jun 14, 2016 at 2:17 AM Gary Gregory wrote:
> On Mon, Jun 13, 2016 at 11:13 PM, Benedikt Ritter
> wrote:
>
> > I don't like how we're evolving CSVFormat. It is becoming a dumping
> ground
> > for anything that may be useful or convenient. The more method
+1 to Jochen's idea and I'd love to contribute to that effort!
On Tue, Jun 14, 2016 at 2:40 AM Jochen Wiedmann
wrote:
> On Tue, Jun 14, 2016 at 8:23 AM, Gary Gregory
> wrote:
>
> >> as Jochen has pointed out, Clirr seems to be unmaintained. However we
> build
> >> a good part of our release str
Agree we should have a "source of truth". Is there something wrong with
using an "internal" or "impl" package name? The bundle plugin for OSGi
doesn't export these by default, which would be a nice side effect! :).
On Mon, Jun 13, 2016 at 3:05 PM Thomas Vandahl
I'd rather not make it (the OSGi metadata) the "source of truth".
On Mon, Jun 13, 2016 at 2:49 PM Thomas Vandahl wrote:
> On 05.06.16 20:33, James Carman wrote:
> > Not quite. OSGi is a special case. It's much more restrictive than simple
> > J2SE, because
Transactions on Mathematical Software
> (TOMS). The latest (Algorithm 959) is interesting although I have no idea
> where to find the code and am dismayed that it is a library under the GPL.
>
> > -Original Message-
> > From: Niall Pemberton [mailto:niall.pember...@g
by-side for the Sun compiler.
On Sun, Jun 12, 2016 at 5:49 PM Gary Gregory wrote:
> On Jun 12, 2016 2:45 PM, "James Carman"
> wrote:
> >
> > I don't off the top of my head. All I have is anecdotal stuff in my
> brain,
> > but then again I can't re
n getting jitted down to a simple hash jumptable
>
> Original message ----
> From: James Carman
> Date: 06/12/2016 5:19 PM (GMT-05:00)
> To: Commons Developers List
> Subject: Re: svn commit: r1748015 - in /commons/proper/imaging/trunk/src:
> changes/changes.xml
&
I was referring to JIT.
On Sun, Jun 12, 2016 at 5:18 PM dbrosIus wrote:
> Interesting. Source?
>
> Original message
> From: James Carman
> Date: 06/12/2016 5:12 PM (GMT-05:00)
> To: Commons Developers List
> Subject: Re: svn commit: r1748015 - in /c
Doesn't it all compiled down to the same thing? It gets optimized at
runtime anyway. I would go for the more readable option, unless there are
extremely compelling performance numbers.
On Sun, Jun 12, 2016 at 4:38 PM Benedikt Ritter wrote:
> Yes, the if-else could also be implemented using a swi
Can it be used in non-I/O situations?
On Sun, Jun 12, 2016 at 8:15 AM sebb wrote:
> IO is a better fit than NET, but I'm not sure that it is better than LANG.
>
> On 12 June 2016 at 13:03, James Carman wrote:
> > It has general stream/reader stuff too.
> >
> >
ays think about file system
> operations...
>
>
> >
> > Am 12.06.2016 um 13:40 schrieb James Carman:
> > > Is it only I/O related?
> > >
> > > On Sun, Jun 12, 2016 at 7:05 AM Benedikt Ritter
> > wrote:
> > >
> > >> Hi,
> &g
Is it only I/O related?
On Sun, Jun 12, 2016 at 7:05 AM Benedikt Ritter wrote:
> Hi,
>
> CircuitBreaker is a pattern usually used when working with remote systems.
> We have a CircuitBreaker implementation added to [LANG] in the concurrent
> package. Now I'm wondering whether it would better fit
We (the Commons PMC) have not decided yet what to do, but I just wanted to
gauge the interest in joining the math IPMC if we choose to go TLP by way
of the incubator. The idea would be that math (whatever its name may be),
would go through the incubator in order to enrich its community prior to
bec
2016 at 1:36 AM Ralph Goers
wrote:
> -1 (binding)
>
> At least until there are enough people to have a viable PMC.
>
> Ralph
>
> > On Jun 10, 2016, at 8:47 PM, James Carman
> wrote:
> >
> > Since it has been suggested that the previously passing vote shou
On Sat, Jun 11, 2016 at 12:48 AM James Carman
wrote:
>
> Phil Seitz
> Luc Maisonobe
> Gary Gregory
> Thomas Neidhart
> Gilles Sadowski
> William Barker
> Otmar Ertl
>
>
Apologies to Phil for misspelling his name, Steitz.
On Fri, Jun 10, 2016 at 11:11 PM Ralph Goers
wrote:
>
> Personally, I think the vote that took place to move Math to a TLP should
> now be considered void since the proposed PMC no longer exists.
> Furthermore, at the moment Math doesn’t have a sufficient number of
> participants to make it a via
I like the idea of splitting Math into multiple components. Even Phil, in
the TLP VOTE thread, said:
"We are probably at the point where we should consider splitting [math]
itself into separately released subcomponents (could be done in Commons,
but starts smelling a little Jakarta-ish when Commo
Here's my +1 (binding).
On Fri, Jun 10, 2016 at 11:47 PM James Carman
wrote:
> Since it has been suggested that the previously passing vote should be
> voided, I propose we vote again to move Commons Math to a TLP:
>
> +1 - Yes, move Commons Math to a TLP
> -1 - No, do not
On Fri, Jun 10, 2016 at 11:11 PM Ralph Goers
wrote:
>
> Personally, I think the vote that took place to move Math to a TLP should
> now be considered void since the proposed PMC no longer exists.
> Furthermore, at the moment Math doesn’t have a sufficient number of
> participants to make it a via
Since it has been suggested that the previously passing vote should be
voided, I propose we vote again to move Commons Math to a TLP:
+1 - Yes, move Commons Math to a TLP
-1 - No, do not move Commons Math to a TLP
The vote will remain open for 72 hours.
Thank you,
James Carman
On Fri, Jun 10, 2016 at 3:29 PM Ralph Goers
wrote:
> Not only is the original chair not available, neither is a quorum of the
> proposed PMC. Why are you pushing this? I, for one, am perfectly content
> to keep Math here and see if those who have expressed interest in helping
> out actually do
We already voted to make it go TLP and it passed. The original chair of
the new project isn't available any more. Gilles, are you willing to chair
the new project? Is anyone else willing to help Gilles perhaps take Math
through the incubator to gather more momentum? Can we perhaps reach out to
On Fri, Jun 10, 2016 at 1:05 PM Gary Gregory wrote:
>
> I think mailing the list for each component is nice. It seems polite, less
> overbearing and less brute-force; IOW more community oriented. The VOTE is
> nice because it gives folks a few days to voice and record their objection
> (I do not
On Fri, Jun 10, 2016 at 12:52 PM Gary Gregory
wrote:
> I agree with Jörg's email below. Furthermore, to me, the best chance [math]
> has a shot to survive and prosper (I'm a glass-half-full kinda guy) is to
> stay in Commons in its current single module form (KISS) _because_ a bunch
> of [math] d
ahead.
That's what I mean. I don't mean force everyone to move right now.
On Fri, Jun 10, 2016 at 8:57 AM James Carman
wrote:
> Is anyone opposed at this time to moving everything at once?
>
> On Fri, Jun 10, 2016 at 8:56 AM Benedikt Ritter
> wrote:
>
>> Jochen Wiedmann
Is anyone opposed at this time to moving everything at once?
On Fri, Jun 10, 2016 at 8:56 AM Benedikt Ritter wrote:
> Jochen Wiedmann schrieb am Fr., 10. Juni 2016
> um 14:14 Uhr:
>
> > On Fri, Jun 10, 2016 at 9:28 AM, Kristian Rosenvold
> > wrote:
> >
> > > This vote passes by lazy consensus.
I can get on board with that model I suppose. What we talked about long ago
was an event listener model for knowing what's going on internally with a
library. These events could be delivered asynchronously from the calls
coming from an application.
On Fri, Jun 10, 2016 at 7:03 AM sebb wrote:
> On
Exactly!
On Thu, Jun 9, 2016 at 10:54 PM Ralph Goers
wrote:
> Given how few Math committees there are, that would require going into the
> incubator.
>
> Ralph
>
> > On Jun 9, 2016, at 6:24 PM, James Carman
> wrote:
> >
> > TLP TLP TLP!
> >
>
TLP TLP TLP!
You can split it up into whatever you want.
On Sun, Jun 5, 2016 at 8:49 PM Gilles wrote:
> 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 unavo
I'll check it out. The printf sounds nice
On Thu, Jun 9, 2016 at 7:18 PM Ralph Goers
wrote:
>
> > On Jun 9, 2016, at 3:55 PM, James Carman
> wrote:
> >
> > On Thu, Jun 9, 2016 at 2:19 PM Matt Sicker wrote:
> >
> >> There is a huge list of
On Thu, Jun 9, 2016 at 2:19 PM Matt Sicker wrote:
> There is a huge list of advantages to using log4j-api over slf4j-api
> nowadays, plus I do prefer to use Apache dependencies in Apache projects
> unless the competition is clearly better for the use case (like using Jetty
> instead of Tomcat in
Let's be clear here. We are proposing changing the code because someone
used a SNAPSHOT version and released their code which uses it? That code
was never released and I don't know that it's right to bind us to a
work-in-progress. It's bad enough we have to be saddled forever with the
burden of
On Mon, Jun 6, 2016 at 10:01 PM Gary Gregory wrote:
> Hi All:
>
> IMO. if [crypto] is to have a dependency on a logging framework, it should
> be Log4j 2, not Commons Logging. Log4j 2 has an API module, which you can
> pair with any number of implementations: Log4j's own Core, JUL, SLF4J, and
> s
+1
On Tue, Jun 7, 2016 at 1:11 PM Benedikt Ritter wrote:
> Hello Sebb,
>
> sebb schrieb am Di., 7. Juni 2016 um 18:09 Uhr:
>
> > Does the project *need* to use any Java7 features?
> >
> > Is it working OK now with Java 6 as the minimum?
> >
> > If the answers are No and Yes then moving to Java 7
On Tue, Jun 7, 2016 at 8:15 AM Jochen Wiedmann
wrote:
> In the light of the current discussions, you may be right.
>
> However, what I still don't understand: Why is BC such an issue for people?
>
> I think, it is perfectly reasonable to do, what other projects do:
>
> - Maintain several release
We have to be willing to reevaluate the BC stringency we have had. Is it
working for our users? Is it worth the trouble it causes (people have left
this community over it)? Are there better options? Is it too strict and
could just be relaxed?
Our BC policies sound good on paper and do address thin
This was proposed long ago.
On Tue, Jun 7, 2016 at 4:46 AM Jochen Wiedmann
wrote:
> On Tue, Jun 7, 2016 at 10:43 AM, Gary Gregory
> wrote:
>
> > We have a bunch of components that just got in the queue to migrate from
> > Svn to Git. BCEL would just be another one...
>
> Maybe we could take the
+1 Torsten
On Tue, Jun 7, 2016 at 6:17 AM Torsten Curdt wrote:
> >
> > 1) I don't believe we should force users to migrate their code in
> > order to support java 7/8.
> >
>
> ...and that line of thinking is why it feels like commons projects are
> effectively stuck in the past.
>
> No one needs
+1
On Tue, Jun 7, 2016 at 2:37 AM Kristian Rosenvold
wrote:
> Hello,
>
> I'd like to call a VOTE by LAZY
> consensus for migrating the Apache Commons IO component to git. Please
> object to this vote if you see a problem with this. Otherwise this vote
> will be considered as passed after 72 hour
+1
On Mon, Jun 6, 2016 at 3:17 PM Benedikt Ritter wrote:
> Hello,
>
> as done before for other components, I'd like to call a VOTE by LAZY
> consensus for migrating the Apache Commons CSV component to git. Please
> object to this vote if you see a problem with this. Otherwise this vote
> will be
On Sun, Jun 5, 2016 at 7:12 PM Ralph Goers
wrote:
> 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 versi
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
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
I don't think it has anything to do necessarily with framework or not. The
class loading model is just much easier to deal with these situations. As
Benson said, however, there are definitely other issues to contend with.
On Thu, Jun 2, 2016 at 6:14 PM Benedikt Ritter wrote:
> Jame
Yep, those pesky duplicate chains.
On Thu, Jun 2, 2016 at 6:05 PM Benson Margulies
wrote:
> On Thu, Jun 2, 2016 at 6:04 PM, James Carman
> wrote:
> > You've been in karaf land for too long! ;)
>
> I took my team into OSGi to get away from these messes. Of course, we
>
You've been in karaf land for too long! ;)
On Thu, Jun 2, 2016 at 5:36 PM Benson Margulies
wrote:
> I don't understand what's wrong with semantic versioning and keeping
> the same maven coordinates. No sane person should be using RELEASE or
> LATEST.
>
> -
Why not create a release prep branch for each release when ready? The
"gitflow" treatment of master is that's what's currently "in production" or
whatever. I don't really care for that model, but it is popular. For
libraries that support multiple versions, I don't know how realistic that
is.
On We
+1
On Wed, May 25, 2016 at 4:43 PM Bernd Eckenfels
wrote:
> Hello,
>
> I would like to be able to use Git with the Apache Commons VFS repo. As
> we agreed upon I call out the intention to do this and ask you for your
> oppinion.
>
> Now that we have the 2.1 release out of the way the switch wont
That definitely seems easier. +1. Would that mess up any sort of sync jobs
(maven and stuff)?
On Fri, Apr 15, 2016 at 7:26 PM Gary Gregory wrote:
> I am OK with anything that makes releasing easier.
>
> Gary
>
> On Fri, Apr 15, 2016 at 4:02 PM, sebb wrote:
>
> > The dist layout currently splits
On Fri, Apr 15, 2016 at 4:13 PM sebb wrote:
>
> As already explained, this is not possible with Git.
> Infra have disabled updating of certain tags includig the ones used
> for releases.
Sorry, didn't realize if this was something we imposed on ourselves and
asked infra to do for us or if it wa
On Fri, Apr 15, 2016 at 1:43 PM sebb wrote:
>
> "the regular process" is what is under discussion.
>
>
I meant the regular process used by the maven release plugin. :) That's
"regular" to me, because that's what I use all the time. I think we have
an opportunity to streamline what we do here q
On Fri, Apr 15, 2016 at 12:57 PM James Carman
wrote:
> On Fri, Apr 15, 2016 at 12:53 PM sebb wrote:
>
>> That is effectively what the final release tag is.
>> We vote on the RC tag, and create the release tag from the successful RC
>> tag.
>>
>>
> Yep, we
On Fri, Apr 15, 2016 at 12:53 PM sebb wrote:
> That is effectively what the final release tag is.
> We vote on the RC tag, and create the release tag from the successful RC
> tag.
>
>
Yep, we're not far off. What I'm proposing is that we try to use the Maven
Release Plugin to create our releases
On Fri, Apr 15, 2016 at 12:38 PM James Carman
wrote:
> On Fri, Apr 15, 2016 at 11:50 AM Benson Margulies
> wrote:
>
>>
>> The problem is that this PMC does not want a tag named after the real
>> (not RC) version to come into existence until after the vote passes.
>
On Fri, Apr 15, 2016 at 11:50 AM Benson Margulies
wrote:
>
> The problem is that this PMC does not want a tag named after the real
> (not RC) version to come into existence until after the vote passes.
>
>
Well, that's the thing that is somewhat silly. The fact that there's a
"tag" doesn't (or
What is with everyone's aversion to using the Maven Release Plugin? I
realize that it may not do exactly what we need out of the box, but it's a
very useful tool. At home, I push a button in my Jenkins setup and it cuts
a new release to the Nexus OSS staging repository awaiting me to finalize
it.
I don't think we take away karma, just membership to the PMC.
On Mon, Apr 11, 2016 at 12:45 PM Benson Margulies
wrote:
> I'm a member emeritus. Can I do it without being voted as something else?
>
>
> On Mon, Apr 11, 2016 at 12:33 PM, Gary Gregory
> wrote:
> > I think we got started and staled
George Dictionary... Book 1*
> *Nonfiction Webster, NoahDictionary... Book 1*
> *Quest Bryson, Bill A Walk... Book 2*
> *Reference Merriam, George Dictionary... Book 1*
> *Reference Webster, Noah Dictionary... Book 1*
> *Travel Bryson, Bill
Couldn't you achieve the same thing using any SortedSet and
CompareToBuilder?
On Fri, Apr 8, 2016 at 2:17 AM Daniel Vimont wrote:
> Hello all,
>
> I've just published a new extension to the standard Java Collections
> Framework to both GitHub and the Maven Central Repository, and am
> considering
Fernández +1 (non-binding)
> Uwe Barthel +1 (non-binding)
> Emmanuel Bourg +1
> James Carman -0
> sebb -0.9
> Uma Gangumalla +1 (non-binding)
> Haifeng Chen +1 (non-binding)
> Cheng A Xu +1 (non-binding)
> Dong Chen +1 (non-binding)
> Oliver Heger + 0.5
> Thomas Vandahl
+1 drop ant
On Mon, Mar 21, 2016 at 5:06 PM Oliver Heger
wrote:
> Hi Benedikt,
>
> Am 21.03.2016 um 09:58 schrieb Benedikt Ritter:
> > Hello Oliver,
> >
> > very nice artifacts, good work.
> >
> > - builds with java 6, 7 and 8
> > - site looks good
> > - reports look good
> >
> > Only thing I fo
-0, I don't like the idea of a JNI library.
On Mon, Mar 21, 2016 at 4:45 AM Benedikt Ritter wrote:
> Hi all,
>
> after long discussions I think we have gathered enough information to
> decide whether we want to accept the Chimera project as a new Apache
> Commons component.
>
> Proposed name: Ap
Still not a fan. My vote stands
On Mon, Feb 22, 2016 at 6:37 PM Gary Gregory wrote:
> We already have commons-daemon that has C bits.
>
> Gary
> On Feb 22, 2016 3:27 PM, "James Carman"
> wrote:
>
> > Not a big fan of introducing JNI-based library to Commons. I
Not a big fan of introducing JNI-based library to Commons. I'm -0
On Sat, Feb 20, 2016 at 6:15 AM Benedikt Ritter wrote:
> Hi,
>
> I'd like to discuss the next steps for moving the Chimera component to
> Apache Commons. So far, none of the other PMC members has expressed his or
> her thoughts ab
Okay, folks, this is definitely getting out of hand. Let's put a moratorium
on this thread for the weekend or something and try to come back together
next week and try to move forward. I would urge folks to watch this while
we wait:
https://m.youtube.com/watch?v=rOWmrlft2FI
p.s. Phil, I do hope y
Passion is a good thing. It means he gives a damn. Gilles obviously cares
quite a bit about the subject matter. I think it's great that he's willing
to crack open some code that a lot of folks wouldn't touch and propose some
interesting changes. Perhaps adding the new implementations alongside the
For the record, I really do like epsilon also.
On Mon, Feb 1, 2016 at 12:14 PM James Carman
wrote:
> Apache Math
>
> On Mon, Feb 1, 2016 at 12:06 PM Phil Steitz wrote:
>
>> Please select your top choice among the following suggested names
>> for the new [math]-based T
Good question. I have proposed it many times in the past
On Mon, Feb 1, 2016 at 5:03 PM Gilles wrote:
> On Mon, 01 Feb 2016 15:05:57 +0000, James Carman wrote:
> > On Mon, Feb 1, 2016 at 9:50 AM Gilles
> > wrote:
> >
> >>
> >> "Math"
Apache Math
On Mon, Feb 1, 2016 at 12:06 PM Phil Steitz wrote:
> Please select your top choice among the following suggested names
> for the new [math]-based TLP. All are welcome and encouraged to
> respond. This POLL will be open for 72 hours, at which time two
> tallies will be presented: o
On Mon, Feb 1, 2016 at 9:50 AM Gilles wrote:
>
> "Math" is (a bit?) overwhelming for a team of 5- people.
>
> In "Commons" there was the rationale of accepting only "common"
> algorithms (although that was fairly fuzzy as a limitation).
> Not so with that overly general name.
> It's a library tha
t;>>>
> >>>> On Jan 24, 2016, at 3:17 PM, Gilles
> >>>> wrote:
> >>>>>
> >>>>>
> >>>>> Just plain and simple "Apache Math" maybe?
> >>>>> Or is it taken already?
> >>>
I'm okay with that too. Apache Math
On Sun, Jan 24, 2016 at 5:17 PM Gilles wrote:
> Just plain and simple "Apache Math" maybe?
> Or is it taken already?
>
> Gilles
>
> On Sun, 24 Jan 2016 14:46:17 -0700, Phil Steitz wrote:
> > On 1/24/16 2:16 PM, James C
the traditions of Apache, being a native American tribe, Geronimo being a
> native American chief, as well as a few others. -- H
>
> On 24 January 2016 at 13:51, Gary Gregory wrote:
>
> > On Jan 24, 2016 1:46 PM, "Phil Steitz" wrote:
> > >
> > > On
Maybe Apache Gauss?
On Sun, Jan 24, 2016 at 4:16 PM James Carman
wrote:
> I guess it depends on the scope of what the new TLP is going to do.
> Umbrella projects aren't that popular these days, from what I understand.
> Maybe an homage to a famous mathematician? Apache Newton
1 - 100 of 1158 matches
Mail list logo