nteger age) { }
var mary = new Person("Mary", 25)
Tuple2 nameAndAge = mary.components()
HTH,
Paul.
> Gary
>
> On Sun, Jun 9, 2024, 7:38 AM Paul King wrote:
>
> > May or may not interest you but the Apache Groovy project has Tuple0
> > through to Tuple1
May or may not interest you but the Apache Groovy project has Tuple0
through to Tuple16. They are especially useful from the Groovy
programming language but are also useful from Java. I can elaborate if
it's of interest.
Cheers, Paul.
On Fri, Jun 7, 2024 at 11:41 PM Gary Gregory wrote:
>
> Hello
+1 (non-binding)
I checked:
* hash and signatures for src and bin zips
* no unexpected binary files (just some expected image files under site)
* I tested the staged artifacts against the Groovy groovy-cli-commons
test suite (all tests pass)
* There appears to be an empty
"src/test/java/org/apache
The 1.9.x releases are pre-JDK 8. The project looks set up for a 2.0
release where such a change might make sense but I don't think that
has happened yet.
Cheers, Paul.
On Fri, Dec 29, 2023 at 6:12 PM Claude Warren wrote:
>
> I am looking at BeanUtils as part of the CLI options to parse a comman
I think this question only makes sense if you give the Options spec
you are using.
Using an Options with both of these:
Option.builder().longOpt('one').numberOfArgs(1).build()
Option.builder('2').numberOfArgs(1).build()
It treats the "-2" as you are expecting.
Using an Options with both of thes
Hi Varun,
While you may be obtaining these libraries from the "Maven Central
Repository", nearly all of them are artifacts from their respective
third-party projects. You will need to read the documentation of those
projects and/or approach those projects if you want more information.
I'll let ot
On Tue, Jul 18, 2023 at 8:04 PM Gilles Sadowski wrote:
>
> > Even the "units of measurement" work is a bit fragmented. If you want
> > to use KILOMETERS and MILES for instance, or use FEET, you have to mix
> > and match different libraries with the standard, and the different
> > libraries are all
The main issue with jscience is lack of maintenance. It was invented
around the time of JSR 275 which was ultimately rejected. The newer
"units of measurement" work is in JSR 363 and JSR 385, while the
currency/money stuff is in JSR 354.
Even the "units of measurement" work is a bit fragmented. If
gt;
> Gary
>
> On Mon, Sep 12, 2022, 16:19 Paul King wrote:
>
> > Cut-n-paste glitch re "board attention" under project activity?
> >
> > On Tue, Sep 13, 2022 at 8:57 AM Gary Gregory
> > wrote:
> > >
> > > Here the board report I pl
Cut-n-paste glitch re "board attention" under project activity?
On Tue, Sep 13, 2022 at 8:57 AM Gary Gregory wrote:
>
> Here the board report I plan to submit tomorrow at the latest:
>
> ## Description:
> The mission of Apache Commons is the creation and maintenance of Java
> focused
> reusable l
e of
> the design.
> However this only makes sense if the developers skilled in the are are
> prepared to assist long-term.
>
>
> On Sat, 24 Apr 2021 at 23:32, Paul King wrote:
> >
> > Thanks Gilles,
> >
> > I can provide the same sort of stats acros
8:15 AM Gilles Sadowski wrote:
>
> Hello Paul.
>
> Le sam. 24 avr. 2021 à 04:42, Paul King a écrit :
> >
> > I added some more comments relevant to if the proposed algorithm
> > belongs somewhere in the commons "math" area back in the Jira:
> >
>
I added some more comments relevant to if the proposed algorithm
belongs somewhere in the commons "math" area back in the Jira:
https://issues.apache.org/jira/browse/MATH-1563
Cheers, Paul.
On Wed, Apr 21, 2021 at 7:26 PM Gilles Sadowski wrote:
>
> Le mer. 21 avr. 2021 à 08:
+1 (non-binding)
On Thu, Apr 22, 2021 at 3:06 AM Gilles Sadowski wrote:
>
> Hi.
>
> [This a reboot of the proposal for which the preceding vote
> has just been cancelled.]
>
> Name of component: "Commons Machine Learning"
> Name of "git" repository: "commons-machinelearning"
> Top-level package n
On Wed, Apr 21, 2021 at 4:12 PM Ralph Goers wrote:
>
> Why are y’all having a long discussion on Vote thread?
Fair enough. I am +1 (non-binding).
Cheers, Paul.
> > On Apr 20, 2021, at 10:33 PM, Paul King wrote:
> >
> > Hi Avijit Basak,
> >
> > +1 to thanki
Hi Avijit Basak,
+1 to thanking you for your offer. Just a couple of comments from
someone who is only a marginal contributor to the commons project.
I would be keen to see a new commons component incorporating various
machine learning/data science components. The other main contenders
that seem
There are many useful things that Gradle and/or Groovy can bring you. I
couldn't imagine doing our releases without most of the steps being
automated (yeah we have about 100 steps too!). I agree though that while
Apache Groovy is 95% the same as Java (especially when using its static
nature), it is
There are a number of approaches you could take. Why not just a whole bunch
of methods that map directly to existing functionality, e.g.:
fun Boolean?.isNotTrue() = BooleanUtils.isNotTrue(this)
fun Boolean.toStringYesNo() = BooleanUtils.toStringYesNo(this)
It might be possible to automate and whe
The attachments didn't seem to come through. I am not on the commons PMC
but I would be -1 for changing the existing functionality. They already
work fine for Java and work already as Apache Groovy extension methods:
@Grab('org.apache.commons:commons-lang3:3.10')
import org.apache.commons.lang3.St
Response inline
On Wed, Aug 28, 2019 at 11:55 PM Peter Verhas wrote:
>
> [snip...]
> Paul King
>
> >You can stop using the JavadocAssertionTestSuite at any time.
> >The code will still be in the Javadoc as documentation but just won't
> >be tested
I haven't used Geci, so can't really comment on all the things it
might be capable of.
With respect to something equivalent to Python doctests, in the Groovy
project we
have JavadocAssertionTestBuilder and JavadocAssertionTestSuite classes.
Feel free to look to those for inspiration (at least).
F
our experience as a user of "Commons Math" would be most useful
> to help us craft a better (or, at least, no worse) design for "Commons
> Statistics".
> Would you share pointers to actual use-cases?
>
> Thanks,
> Gilles
>
> 2019-07-19 7:03 UTC+02:00, P
Cool. I'd be keen to try out the API, when you are ready, in my
"Apache Groovy for data science" examples which currently use the
commons math3 classes.
Cheers, Paul.
On Fri, Jul 19, 2019 at 9:51 AM Gilles Sadowski wrote:
>
> Hi.
>
> Le ven. 19 juil. 2019
How does this relate to the OLS classes in commons math?
https://commons.apache.org/proper/commons-math/javadocs/api-3.6.1/org/apache/commons/math3/stat/regression/OLSMultipleLinearRegression.html
On Fri, Jul 19, 2019 at 8:50 AM Eric Barnhill wrote:
>
> I suggested the following grammar to aim fo
+1
On Sat, Mar 2, 2019 at 7:27 AM sebb wrote:
>
> The [GitHub] messages sent by g...@apache.org don't say what repo they relate
> to.
>
> This make it difficult to know which component is involved.
>
> Sometimes the subject includes a JIRA issue, but many subjects give no clue.
>
> I think it wo
Just to clarify, when I said "It's built with gradle and uses Ant", I
mean our build is gradle based and our call of Bridger uses Ant.
Bridger itself is built with Maven.
On Fri, Mar 30, 2018 at 12:20 PM, Paul King wrote:
> In the Groovy build we do this using Bridger
>
Even changing from void to non-void will cause binary incompatibility.
>> (Source-wise, that's fine)
>>
>> On 29 March 2018 at 18:20, Gary Gregory wrote:
>> > Yep, that's no good. I'll revert.
>> >
>> > Gary
>> >
>> >
I haven't looked into the IteratorUtils class at all but it's easy to
show binary incompatibility when changing the return type.
Compile this "library" class:
import java.util.ArrayList;
import java.util.List;
public class Lib {
List getMyList() {
return new ArrayList();
}
}
Now
Groovy has some features which might give you some ideas.
Firstly, it let's you easily create dynamic objects in numerous ways.
Typically you might use a Closure or map of Closures. You can
optionally specify one or more interfaces and if needed give a base
class. You could no doubt do something s
My goto library for such tasks would be GPars. It has both Java and
Groovy support for most things (actors/dataflow) but less so for
asynchronous task execution. It's one of the things that would be good
to explore in light of Java 8. Groovy is now Apache, GPars not at this
stage.
So with adding t
Oh, I did notice that the README.md still has 1.3.1 rather than 1.4
when referencing
how to retrieve the Maven artifact. Is a "mvn commons:readme-md" required?
On Fri, Mar 10, 2017 at 10:00 AM, Paul King wrote:
> +1 (non-binding)
> I checked md5/sha1/asc for the sources jar and
+1 (non-binding)
I checked md5/sha1/asc for the sources jar and src zip.
I ran "mvn test" from the src zip using Java 1.6.0_45 and Maven 3.2.5.
I ran Apache Groovy's test suite against 1.4 which runs quite a few
tests for CliBuilder (which has commons cli under the covers) as well
as numerous other
For Groovy users, in the upcoming Groovy 2.5 release, Groovy's CliBuilder
provides an annotation-based layer on top of [cli]. Most of CliBuilder
relies heavily on Groovy being there but the annotation layer on top much
less so apart from the Closure converters. In any case, it's an example of
provi
For any Gradle users, Cédric put together a little Gradle plugin based
around the japicmp library which we use in Groovy, see here:
https://github.com/apache/groovy/blob/master/gradle/binarycompatibility.gradle
Cheers, Paul.
On Tue, Jun 14, 2016 at 9:56 PM, James Carman
wrote:
> +1 to Jochen's
Nice work!
On Thu, Jun 18, 2015 at 4:48 PM, Benedikt Ritter wrote:
> The Apache Commons Team is pleased to announce the release of Apache
> Commons CLI 1.3.1.
>
> The Apache Commons CLI library provides an API for parsing command line
> options passed to programs. It's also able to print help me
+1 (non-binding)
based on successful run of the Groovy test suite
Notes: since the 1.3 release we have removed GroovyInternalPosixParser
which was our fork of 1.2's PosixParser with some bug fixes of our own plus
some from the 1.3 codebase before 1.3's release and now use DefaultParser.
So we are
Yes Jörg, I'll keep that in mind.
Cheers,Paul.
On Thu, May 7, 2015 at 5:28 PM, Jörg Schaible
wrote:
> Hi Paul,
>
> Paul King wrote:
>
> > On Mon, May 4, 2015 at 4:06 PM, Benedikt Ritter
> wrote
> >>
> >> I would appreciate feedback for the RC from
On Mon, May 4, 2015 at 4:06 PM, Benedikt Ritter wrote
>
> I would appreciate feedback for the RC from the Groovy project.
>
Thanks for your work on progressing the 1.3 release Benedikt. We have built
Groovy using the RC-1 candidate jar and the build and all tests succeed.
This is already a huge s
On Mon, May 4, 2015 at 4:06 PM, Benedikt Ritter wrote
>
> I would appreciate feedback for the RC from the Groovy project.
>
Thanks for your work on progressing the 1.3 release Benedikt. We have built
Groovy using the RC-1 candidate jar and the build and all tests succeed.
This is already a huge s
>
> Le 07/02/2014 17:59, Gary Gregory a écrit :
> > Is there any reason not to release 1.3? It would be nice to flush out the
> > trunk fixes.
I have to recheck the current state of the code. If I remember well the
> new parser was ready, but I'm not sure it has really been tested on the
> field.
40 matches
Mail list logo
