Re: [VOTE] Release Apache Commons CLI 1.8.0 based on RC2

[Paul King]

+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/commons/cli/converters/" folder in the src
zip that isn't in the github source tree AFAIK, but it's not doing any
harm

Cheers, Paul.


On Mon, May 20, 2024 at 12:55 AM Gary Gregory  wrote:
>
> We have fixed a few bugs and added enhancements since Apache Commons
> CLI 1.7.0 was released, so I would like to release Apache Commons CLI
> 1.8.0.
>
> Apache Commons CLI 1.8.0 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/cli/1.8.0-RC2 (svn
> revision 69280)
>
> The Git tag commons-cli-1.8.0-RC2 commit for this RC is
> 91369572408eff424ff5cec2d46dd9667ceba1b3 which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-cli.git;a=commit;h=91369572408eff424ff5cec2d46dd9667ceba1b3
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-cli.git
> --branch commons-cli-1.8.0-RC2 commons-cli-1.8.0-RC2
>
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1732/commons-cli/commons-cli/1.8.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Sun May 19 14:50:37 UTC 2024
> commons-cli-1.8.0-bin.tar.gz=9e8072c9d1efc8f8d5ecb65d82a02a8e573837ebf6e699b9675db7769c21fadc7157e7691e2a8dfb91267ccdac2671f64403631a394dc094a8481b8d5ffd190f
> commons-cli-1.8.0-bin.zip=281019ef7dbb94702f5b7e5bcd0ed8947bcc55a62f87c4a93c97e34d95751352ccb191a368d8ff59ba389f342b2a7335effee0cf60fa4bbf2428f90ec648e530
> commons-cli-1.8.0-bom.json=2d9b8cb5333bf31a48fdb1037dec84c48434c619a4fe421529df7386f2ede67b76c61d2c490bbb5b6af301f92262a95fb3dff30b91468bb4b6ce555f2f1e1026
> commons-cli-1.8.0-bom.xml=00f5c34db21083b3f2677a931d9b2e10de60c40fa3f58fc2a01ea34e4b5227b800d58231df9194f2a39d2c40e062b859bce5399f93d2188ca230be81bfb93106
> commons-cli-1.8.0-javadoc.jar=ec49e3a71f26ac91b5ce16b6390d82d605cc78843fb93f6bef56484a306bcb2230d173569adfb0b28b3b222396313ecec4b852fd33745000d8712b55b8ad6dbf
> commons-cli-1.8.0-sources.jar=f2740e9695d43cf56f111d47a7fb53ec99044eb69b259921096be0b57c963a19f4282579acf58052d5724cb6273028fe0457309b0b21c59f4039a0960f09c985
> commons-cli-1.8.0-src.tar.gz=588d89d86deb60ac0e182bd4b574e30aac4000dde9da13ee1080844a4982d45f4a4d29fc3ee54c904c74ed6bf14dbb3bffdcbad0eab86ddde8418811f2efb5c2
> commons-cli-1.8.0-src.zip=48513dc3fdf7deae5bfc94c4ef1975659a851a12432f3158ff764fd30ce03bdefeba0e255829e1c4d84f5a6185dbaabec1570917cf73360f395ab6b5b54f9613
> commons-cli-1.8.0-test-sources.jar=a59ae8590b6ebf4a25fe01e18fa55d6b5769b425d6363943671ae32271a17bd3ed226e3e35f0bcc3fafe0aca06a726f2211049cbad1fbb39d3cda008b894c689
> commons-cli-1.8.0-tests.jar=3a85ff142f3ea9ebf5d6d9c5efe407754803424e29f07e18ac8429f3a7c1dd706f518fee669f2108414d7120f8e5fdd2ee464d2096766beca7ec9ce3b80074b4
> commons-cli_commons-cli-1.8.0.spdx.json=1df478ac114f20e50fa7717a12d8838c03bd104f66b277a59b0e640a992e0c25894fc67ee7fde5927b3c5dc1ce6170bcc2010ef55abaec6484a6eae82c60d652
>
> I have tested this with 'mvn' and 'mvn -V -Prelease -Ptest-deploy -P
> jacoco -P japicmp clean package site deploy' using:
>
> openjdk version "17.0.11" 2024-04-16
> OpenJDK Runtime Environment Homebrew (build 17.0.11+0)
> OpenJDK 64-Bit Server VM Homebrew (build 17.0.11+0, mixed mode, sharing)
>
> Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: /usr/local/Cellar/maven/3.9.6/libexec
> Java version: 17.0.11, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@17/17.0.11/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac"
>
> Darwin  23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:09:52
> PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64
>
> Details of changes since 1.7.0 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/cli/1.8.0-RC2/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/cli/1.8.0-RC2/site/changes-report.html
>
> Site:
> 
> https://dist.apache.org/repos/dist/dev/commons/cli/1.8.0-RC2/site/index.html
> (note some *relative* links are broken and the 1.8.0 directories
> are not yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 1.7.0):
> 
> https://dist.apache.org/repos/dist/dev/commons/cli/1.8.0-RC2/site/japicmp.html
>
> RAT Report:
> 
> https://dist.apache.org/repos/dist/dev/commons/cli/1.8.0-RC2/site/rat-report.html
>
> KEYS:
>   https://downloads.apache.org/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I 

Re: [BEANUTILS] Is there a good reason for Converter to not be a FunctionalInterface?

[Paul King]

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 command
> line option string into a class.
>
> I see that Converter is an interface with one method; converting a String
> to an Object.  Is there a good reason for this not to be annotated as
> an @FunctionalInterface?
>
> Claude
> --
> LinkedIn: http://www.linkedin.com/in/claudewarren

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Query related to Apache Commons CLI

[Paul King]

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 these:

Option.builder().longOpt('one').numberOfArgs(2).optionalArg(true).build()
opts.addOption(Option.builder('2').numberOfArgs(1).build()

It gives the behavior you are describing, since indeed the "-2" could
be an optional argument.

Is there any reason you couldn't use the former?

Cheers, Paul.


Virus-free.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, Nov 12, 2023 at 7:52 PM Sruteesh Kumar
 wrote:
>
> I have a doubt on Apache Commons CLI
>
> For DefaultParser, why is a negative number preferably considered as an 
> argument rather than an option
>
> Consider the following case, for example:
> String[] args= {"--one","arg1","-2","arg2"};
>
> Here, -2 is considered as an argument to --one, even if there is a required 
> option with key -2
>
> Why is it preferably considered as an argument rather than an option?

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Request for update on the EOL of maven libraries.

[Paul King]

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 others more actively involved in the respective commons
subprojects (which are released by the ASF) respond if they have any
more detailed information, but a common pattern for many ASF projects
is not to publish EOL dates but rather release new versions in
perpetuity which fix bugs and sometimes introduce new features. Some
projects maintain older branches which are typically released much
less frequently, and in that case, should you require the older
version for some reason, you should use the latest version on that
branch. In your case, you are using the latest branches for all 3
commons projects.

You can find out a little more in the commons users mailing list. That
list reveals the following information regarding commons-codec:

"There is currently no EOS or EOL for Codec 26/Jul/2022" but I'll note
you can upgrade to 1.16 to be using the latest artifact.

Nothing appears to be in those lists for commons-io or
commons-beanutils nor on their respective websites. That typically
implies no explicit EOL is given.
I'll note that for commons-io, the latest version is 2.13.0, so you
can upgrade to that to be on the latest version.
For commons-beanutils you are on the latest version but that project
is not as active. There is a beanutils version2 in the works, but it
seems a little way off still.

Cheers, Paul.

On Tue, Aug 1, 2023 at 9:36 AM Bali3, Varun
 wrote:
>
> Hi Apache Team,
>
> We want to know the EOL dates for below listed maven libraries, please assist 
> in providing information for the same.
>
>
>   1.  commons-io-2.11.0.jar
>   2.  commons-beanutils-1.9.4.jar
>   3.  antlr-2.7.7.jar
>   4.  commons-codec-1.15.jar
>   5.  jakarta.activation-api-2.0.1.jar
>   6.  javax.interceptor-api-1.2.jar
>   7.  j2objc-annotations-1.3.jar
>   8.  xmlsec-2.3.2.jar
>   9.  checker-qual-3.31.0.jar
>   10. dd-trace-api-1.13.0.jar
>   11. jquery-3.6.4.min.js
>   12. shedlock-provider-jdbc-template-5.2.0.jar
>   13. shedlock-core-5.2.0.jar
>   14. shedlock-spring-5.2.0.jar
>   15. plexus-utils-3.5.1.jar
>   16. spring-security-core-6.0.3.jar
>   17. httpcore5-5.1.5.jar
>   18. spring-security-config-6.0.3.jar
>   19. httpcore5-h2-5.1.5.jar
>   20. hibernate-core-6.1.7.Final.jar
>   21. spring-security-crypto-6.0.3.jar
>   22. antlr4-runtime-4.10.1.jar
>   23. spring-security-saml2-service-provider-6.0.3.jar
>   24. spring-security-web-6.0.3.jar
>   25. guava-31.1-jre.jar
>   26. bcutil-jdk18on-1.72.jar
>   27. bcpkix-jdk18on-1.72.jar
>   28. bcprov-jdk18on-1.72.jar
>   29. swagger-ui-4.18.2.jar
>   30. micrometer-commons-1.10.7.jar
>   31. spring-boot-actuator-3.0.7.jar
>   32. spring-boot-3.0.7.jar
>   33. spring-boot-actuator-autoconfigure-3.0.7.jar
>   34. jackson-dataformat-yaml-2.14.3.jar
>   35. spring-boot-jarmode-layertools-3.0.7.jar
>   36. micrometer-observation-1.10.7.jar
>   37. spring-data-commons-3.0.6.jar
>   38. spring-data-jpa-3.0.6.jar
>   39. spring-boot-autoconfigure-3.0.7.jar
>   40. micrometer-core-1.10.7.jar
>   41. swagger-ui-standalone-preset-4.16.1.js
>
>
> Regards,
> Varun Bali
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Is there a need for a commons-physics project?

[Paul King]

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 based on different vintages of the standard. It
> > would be nice to have a single library to be able to use. But I'd
> > check with the JSR folks first to see if there was an interest in
> > having an ASF implementation.
>
> If there is a reference implementation, why work on another?

Actually, just checking the relevant repos, some parts of the
situation aren't too bad at the moment.

The JSR 385 API and extensible service provider interface (but no
actual units) had a release a couple of months ago and lives here:
https://github.com/unitsofmeasurement/unit-api

The Indriya reference implementation had a release a few weeks ago and
lives here:
https://github.com/unitsofmeasurement/indriya

In the past, these releases were a little patchy and sometimes out of
date with one another.
At times, it wasn't clear whether the reference implementation was
meant to live beyond
the JSR spec period (I say that with no internal knowledge of the
expectations of the authors
and very limited visibility of their work) but it now seems like the
reference implementation is
being maintained.

What hasn't changed is that other libraries have also been produced
for other units,
e.g. FEET, MILES, CELSIUS, FAHRENHEIT, LIGHT_YEAR, PARSEC,
and KILOMETER [the reference implementation supports KILO(METRE)].
But these other libraries aren't necessarily on the latest API.

Cheers, Paul.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Is there a need for a commons-physics project?

[Paul King]

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 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 based on different vintages of the standard. It
would be nice to have a single library to be able to use. But I'd
check with the JSR folks first to see if there was an interest in
having an ASF implementation.

I wrote a blog about using these APIs with Groovy here:

https://groovy.apache.org/blog/life-on-mars-units-of

Cheers, Paul.

On Tue, Jul 18, 2023 at 3:14 AM Gilles Sadowski  wrote:
>
> Hi.
>
> Le lun. 17 juil. 2023 à 18:21, Thomas  a écrit :
> >
> > Maybe start small, with a universally usable prerequisite:
> >
> > something like commons-unit as an implementation of javax.measure.
>
> https://github.com/javolution/jscience
> https://github.com/javolution/jscience/blob/master/physics/src/main/java/org/jscience/physics/unit/PhysicsUnit.java
>
> Regards,
> Gilles
>
> >
> > See:
> >
> > https://unitsofmeasurement.github.io/unit-api/site/apidocs/javax/measure/class-use/Unit.html
> >
> > | javax.measure
> > unit-api 1.0 
> > Even if not used for physics projects, it might still be very usefull
> > for dev-ops / JMX / SNMP measurements, and certain business
> > applications. Downside: there are already implementations out there.
> > Else, I find it extremely difficult, to select the topics addressed in
> > something simply called 'physics'. You might end up trying to
> > reimplement Mathematica with Java. |
> >
> > On 17.07.2023 03:55, Dimitrios Efthymiou wrote:
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DRAFT] Board report

[Paul King]

Just looks like the info from the "Issues" section is (accidentally?)
repeated in the "Project Activity" section, i.e. "There are no issues
requiring board attention." appears twice.

On Tue, Sep 13, 2022 at 9:41 AM Gary Gregory  wrote:
>
> What is the glitch?
>
> 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 plan to submit tomorrow at the latest:
> > >
> > > ## Description:
> > > The mission of Apache Commons is the creation and maintenance of Java
> > > focused
> > > reusable libraries and components
> > >
> > > ## Issues:
> > > There are no issues requiring board attention.
> > >
> > > ## Membership Data:
> > > Apache Commons was founded 2007-06-19 (15 years ago)
> > > There are currently 149 committers and 42 PMC members in this project.
> > > The Committer-to-PMC ratio is roughly 5:2.
> > >
> > > Community changes, past quarter:
> > > - No new PMC members. Last addition was Matt Juntunen on 2021-06-25.
> > > - No new committers. Last addition was Claude Warren on 2022-02-01.
> > >
> > > ## Project Activity:
> > > The Commons project released the following in this reporting period:
> > There
> > > are
> > > no issues requiring board attention.
> > > - CONFIGURATION-2.8.0 was released on 2022-07-03.
> > > - IMAGING-1.0-alpha3 was released on 2022-05-19.
> > > - DAEMON-1.3.1 was released on 2022-05-09.
> > >
> > > Once Apache RAT 0.15 releases, we will release commons-parent and release
> > > several components.
> > >
> > > ## Community Health:
> > > The health of the Commons is OK even though the activity has decreased in
> > > all
> > > categories (email lists, Jira, commits, and PRs). We are still processing
> > > Jira
> > > tickets and PRS.
> > >
> > > Gary
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DRAFT] Board report

[Paul King]

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 libraries and components
>
> ## Issues:
> There are no issues requiring board attention.
>
> ## Membership Data:
> Apache Commons was founded 2007-06-19 (15 years ago)
> There are currently 149 committers and 42 PMC members in this project.
> The Committer-to-PMC ratio is roughly 5:2.
>
> Community changes, past quarter:
> - No new PMC members. Last addition was Matt Juntunen on 2021-06-25.
> - No new committers. Last addition was Claude Warren on 2022-02-01.
>
> ## Project Activity:
> The Commons project released the following in this reporting period: There
> are
> no issues requiring board attention.
> - CONFIGURATION-2.8.0 was released on 2022-07-03.
> - IMAGING-1.0-alpha3 was released on 2022-05-19.
> - DAEMON-1.3.1 was released on 2022-05-09.
>
> Once Apache RAT 0.15 releases, we will release commons-parent and release
> several components.
>
> ## Community Health:
> The health of the Commons is OK even though the activity has decreased in
> all
> categories (email lists, Jira, commits, and PRs). We are still processing
> Jira
> tickets and PRS.
>
> Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: The case for a Commons component

[Paul King]

On Mon, Apr 26, 2021 at 12:27 AM sebb  wrote:
>
> I assume this thread is about the possible ML component.
>
> If the code was developed by Commons, I assume it could be used as
> part of Spark.
> However Commons does not currently have many developers who are
> familiar with the field.
> So it would seem to me better to have development done by a project
> which does have relevant experience.
>
> You say that Spark etc have lots of jars.
> Surely that allows for it to be implemented as a separate jar which
> can either be used as part of the Spark platform, or used
> independently?

The stats I gave were for the current minimal use of those algorithms.
Most algorithms are written in Scala, use RDD "dataframes" rather than
say double arrays, and assume you're running on "the platform" which
handles how you might get your data and return results and do logging
etc. in a potentially concurrent world. Some of those design choices
are key to scaling up but don't align with the goal of making the
algorithms runnable "independently".

> The only other option I see is for Commons to persuade some developers
> who are familiar with the field to join Commons to assist with the
> algorithms.

I agree that is the crux of the issue here. The "commons doesn't have
the bandwidth to absorb another algorithm" part of the discussion
seems perfectly legit to me. The "and there is an obvious home
elsewhere" part of the discussion seemed a little more dubious to me,
though obviously that is something which should be considered.

> Existing Commons developers can help manage the logistics of packaging
> and releasing the code, as this does not require in depth knowledge 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 across a clustering example
> > across commons-math (KMeans) vs Apache Ignite, Apache Spark and
> > Rheem/Apache Wayang (incubating) if anyone would find that useful. It
> > would no doubt lead to similar conclusions.
> >
> > Cheers, Paul.
> >
> > On Sun, Apr 25, 2021 at 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:
> > > >
> > > > https://issues.apache.org/jira/browse/MATH-1563
> > >
> > > Thanks for a "real" user's testimony.
> > >
> > > As the ML is still the official forum for such a discussion, I'm quoting
> > > part of your post on JIRA:
> > > ---CUT---
> > > For linear regression, taking just one example dataset, commons-math
> > > is a couple of library calls for a single 2M library and solves the
> > > problem in 240ms. Both Ignite and Spark involve "firing up the
> > > platform" and the code is more complex for simple scenarios. Spark has
> > > a 181M footprint across 210 jars and solves the problem in about 20s.
> > > Ignite has a 87M footprint across 85 jars and solves the problem in >
> > > 40s. But I can also find more complex scenarios which need to scale
> > > where Ignite and Spark really come into their own.
> > > ---CUT---
> > >
> > > A similar rationale was behind my developing/using the SOFM
> > > functionality in the "o.a.c.m.ml.neuralnet" package: I needed a
> > > proof of concept, and taking the "lightweight" path seemed more
> > > effective than experimenting with those platforms.
> > > Admittingly, at that epoch, there were people around, who were
> > > maintaining the clustering and GA codes; hence, the prototyping
> > > of a machine-learning library didn't look strange to anyone.
> > >
> > > Regards,
> > > Gilles
> > >
> > > >>> [...]
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: The case for a Commons component

[Paul King]

Thanks Gilles,

I can provide the same sort of stats across a clustering example
across commons-math (KMeans) vs Apache Ignite, Apache Spark and
Rheem/Apache Wayang (incubating) if anyone would find that useful. It
would no doubt lead to similar conclusions.

Cheers, Paul.

On Sun, Apr 25, 2021 at 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:
> >
> > https://issues.apache.org/jira/browse/MATH-1563
>
> Thanks for a "real" user's testimony.
>
> As the ML is still the official forum for such a discussion, I'm quoting
> part of your post on JIRA:
> ---CUT---
> For linear regression, taking just one example dataset, commons-math
> is a couple of library calls for a single 2M library and solves the
> problem in 240ms. Both Ignite and Spark involve "firing up the
> platform" and the code is more complex for simple scenarios. Spark has
> a 181M footprint across 210 jars and solves the problem in about 20s.
> Ignite has a 87M footprint across 85 jars and solves the problem in >
> 40s. But I can also find more complex scenarios which need to scale
> where Ignite and Spark really come into their own.
> ---CUT---
>
> A similar rationale was behind my developing/using the SOFM
> functionality in the "o.a.c.m.ml.neuralnet" package: I needed a
> proof of concept, and taking the "lightweight" path seemed more
> effective than experimenting with those platforms.
> Admittingly, at that epoch, there were people around, who were
> maintaining the clustering and GA codes; hence, the prototyping
> of a machine-learning library didn't look strange to anyone.
>
> Regards,
> Gilles
>
> >>> [...]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Vote] Create a "machine learning" component

[Paul King]

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:56, Paul King  a écrit :
> >
> > On Wed, Apr 21, 2021 at 4:12 PM Ralph Goers  
> > wrote:
> > >
> > > Why are y’all having a long discussion on Vote thread?
>
> Paul King's comments is interesting information that could
> bear on people's decision on the proposal (especially the
> licence's issue).
> As for the question of whether the purported functionality would
> find a better home elsewhere with the ASF, I'm sure what would
> be the conclusion (apart from Avijit Bask's plain preference (?) to
> develop a standalone component, as per Commons' requirement).
>
> >
> > Fair enough. I am +1 (non-binding).
>
> So currently, IIRC the tally (on creating a dedicated component) is
>   Gilles Sadowski +1
>   Avijit Basak +1
>   Paul King +1
> And several -1 on the initially suggested name; but the proposed
> name has been changed early on to "commons-machinelearning"
> (in order to comply with Commons' tradition of full words and
> descriptive names).
> [Please correct if it doesn't reflect what has been expressed.]
>
> Where does that lead us?
>
> Regards,
> Gilles
>
> >>> [...]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Vote] Create repository for "machine learning" algorithms.

[Paul King]

+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 name: "org.apache.commons.machinelearning"
>
> Component rationale and scope (copied verbatim from the
> OP in the other thread):
> ---CUT---
> Because of an offered contribution, a discussion happened on
> JIRA[1] and in another thread[2] about improving the genetic
> algorithm (GA) implementation currently in the
>org.apache.commons.math4.genetic
> package of the "Commons Math" component.
> It would make sense to group "machine learning" algorithms[3]
> (to which GA belongs) within a single component, where codes from
>   org.apache.commons.math4.ml.neuralnet
>   org.apache.commons.math4.ml.clustering
> would be moved too.
> This would be the fifth (and last) component resulting from my proposal
> (see e.g. [4] among other threads) for the reorganization of the "Commons
> Math"[5] code base into more maintainable components[6][7][8][9], each
> focused on actually related functionalities (thus *not* the wide expertise
> necessary for the maintenance of a full-fledged math library).
> ---CUT---
>
> You might want to read the discussion that proceeded from the
> previous vote request. [10]
>
> Please vote:
>   [ ] Yes.
>   [ ] No, because ...
>
> Thanks,
> Gilles
>
> [1] https://issues.apache.org/jira/projects/MATH/issues/MATH-1563
> [2] https://markmail.org/message/dnujdcxuaq5bwuwe
> [3] https://en.wikipedia.org/wiki/Machine_learning
> [4] https://markmail.org/message/75vuyhzblfadc5op
> [5] http://commons.apache.org/proper/commons-math/
> [6] http://commons.apache.org/proper/commons-rng/
> [7] http://commons.apache.org/proper/commons-numbers/
> [8] http://commons.apache.org/proper/commons-geometry/
> [9] http://commons.apache.org/proper/commons-statistics/
> [10] https://markmail.org/message/m7cyn4aq2rg47jxk
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Vote] Create a "machine learning" component

[Paul King]

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 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 to be reasonably actively developed are Smile[1] and Weka[2]
> > which are licensed under GPL or LGPL. Such a component would be a
> > natural fit for the algorithm you propose. If you look at Apache
> > Spark[3] and Apache Ignite[4], they both offer some "machine learning"
> > offerings but they tend to only support algorithms which are either
> > "embarrassingly" parallel or inherently parallel. They tend not to
> > include sequential by nature algorithms. Even "embarrassingly"
> > parallel algorithms are often not included since they can typically
> > already be used already by Spark, Ignite, Beam, Wayang, or home-grown
> > threads/fibres.
> >
> > There has been previous research into PGA with Hadoop, Spark and
> > Ignite[5][6] but so far, none of that has made it into those
> > distributions as far as I know. I don't know how customisable the
> > Ignite GA algorithm[7] is but it might be worth looking into.
> >
> > With respect to component naming, you either go very broad with "math"
> > or something like "datascience", or potentially too narrow with
> > something like "ml" or "machinelearning". Of the latter two, "ml" is
> > most common when bundled into some other framework. The other
> > alternative is to simply come up with another name but the typical
> > convention within commons is to use a descriptive to purpose name.
> > Numerous "ml" libraries also bundle things like regression into them,
> > so there is precedence for such libraries to be algorithms broadly in
> > the topic space. On the commons math front, I think regression is
> > currently earmarked for statistics but not sure it has made the jump
> > as of yet. An "ml" home would be equally suitable in my mind.
> >
> > Having said all of that, as others have pointed out, the volunteer
> > space in commons is somewhat lean at the moment. I would be happy to
> > help a little from the ASF side of things but machine learning/data
> > science isn't my principal area of expertise nor a major aspect in my
> > "day job" activities, it probably takes others with interest to fully
> > give this the effort it deserves. But sometimes someone has to get the
> > ball rolling before other interested parties show up.
> >
> > Cheers, Paul
> >
> > [1] https://haifengl.github.io/ <https://haifengl.github.io/>
> > [2] https://www.cs.waikato.ac.nz/ml/weka/ 
> > <https://www.cs.waikato.ac.nz/ml/weka/>
> > [3] https://spark.apache.org/mllib/ <https://spark.apache.org/mllib/>
> > [4] https://ignite.apache.org/docs/latest/machine-learning/machine-learning 
> > <https://ignite.apache.org/docs/latest/machine-learning/machine-learning>
> > [5] https://hajirajabeen.github.io/publications/SGA.pdf 
> > <https://hajirajabeen.github.io/publications/SGA.pdf>
> > [6] https://dzone.com/articles/genetic-algorithms-with-apache-ignite 
> > <https://dzone.com/articles/genetic-algorithms-with-apache-ignite>
> > [7] 
> > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/ml/util/genetic/GeneticAlgorithm.html
> >  
> > <https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/ml/util/genetic/GeneticAlgorithm.html>
> >
> > On Sun, Feb 14, 2021 at 6:06 PM Avijit Basak  > <mailto:avijit.ba...@gmail.com>> wrote:
> >>
> >> Hi
> >>
> >>   I would like to mention a few points here. Genetic Algorithm has a
> >> vast range of applications in optimization and search problems. Machine
> >> learning is only one of those.
> >>   If we couple the new GA library with any specific domain like ml it
> >> would be meaningless for people working in other domains. They have to
> >> incorporate the entire ml library which may be completely unrelated to
> >> their project. Coupling it with any technology like spark might also limit
> >> it's usability.
> >>   If a separate 

Re: [Vote] Create a "machine learning" component

[Paul King]

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 to be reasonably actively developed are Smile[1] and Weka[2]
which are licensed under GPL or LGPL. Such a component would be a
natural fit for the algorithm you propose. If you look at Apache
Spark[3] and Apache Ignite[4], they both offer some "machine learning"
offerings but they tend to only support algorithms which are either
"embarrassingly" parallel or inherently parallel. They tend not to
include sequential by nature algorithms. Even "embarrassingly"
parallel algorithms are often not included since they can typically
already be used already by Spark, Ignite, Beam, Wayang, or home-grown
threads/fibres.

There has been previous research into PGA with Hadoop, Spark and
Ignite[5][6] but so far, none of that has made it into those
distributions as far as I know. I don't know how customisable the
Ignite GA algorithm[7] is but it might be worth looking into.

With respect to component naming, you either go very broad with "math"
or something like "datascience", or potentially too narrow with
something like "ml" or "machinelearning". Of the latter two, "ml" is
most common when bundled into some other framework. The other
alternative is to simply come up with another name but the typical
convention within commons is to use a descriptive to purpose name.
Numerous "ml" libraries also bundle things like regression into them,
so there is precedence for such libraries to be algorithms broadly in
the topic space. On the commons math front, I think regression is
currently earmarked for statistics but not sure it has made the jump
as of yet. An "ml" home would be equally suitable in my mind.

Having said all of that, as others have pointed out, the volunteer
space in commons is somewhat lean at the moment. I would be happy to
help a little from the ASF side of things but machine learning/data
science isn't my principal area of expertise nor a major aspect in my
"day job" activities, it probably takes others with interest to fully
give this the effort it deserves. But sometimes someone has to get the
ball rolling before other interested parties show up.

Cheers, Paul

[1] https://haifengl.github.io/
[2] https://www.cs.waikato.ac.nz/ml/weka/
[3] https://spark.apache.org/mllib/
[4] https://ignite.apache.org/docs/latest/machine-learning/machine-learning
[5] https://hajirajabeen.github.io/publications/SGA.pdf
[6] https://dzone.com/articles/genetic-algorithms-with-apache-ignite
[7] 
https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/ml/util/genetic/GeneticAlgorithm.html

On Sun, Feb 14, 2021 at 6:06 PM Avijit Basak  wrote:
>
> Hi
>
>I would like to mention a few points here. Genetic Algorithm has a
> vast range of applications in optimization and search problems. Machine
> learning is only one of those.
>If we couple the new GA library with any specific domain like ml it
> would be meaningless for people working in other domains. They have to
> incorporate the entire ml library which may be completely unrelated to
> their project. Coupling it with any technology like spark might also limit
> it's usability.
>If a separate component is not approved for this change then we can
> incorporate the changes as part of *commons.math* library.
>The same library can be reused in ml or neural network libraries as
> a dependency.
>Kindly share further views on this.
>
> Thanks & Regards
> --Avijit Basak
>
> On Wed, 10 Feb 2021 at 19:49, Gilles Sadowski  wrote:
>
> > Le mer. 10 févr. 2021 à 13:19, sebb  a écrit :
> > >
> > > Likewise, commons-ml is too cryptic.
> > >
> > > Also, the Spark project has a machine-learning library:
> > >
> > > https://spark.apache.org/mllib/
> >
> > Thanks for the pointer.
> >
> > >
> > > Maybe that would be better home?
> >
> > On the face of it, probably.
> > [For sure, Avijit should comment on the suggestion.]
> >
> > On the other hand, "Commons" is the place where one can pick "bare
> > bone" implementations, and add the functionality to one's application
> > without necessarily comply with an overarching framework.
> > [I don't mean that framework compliance is bad; quite the contrary, it is
> > hopefully the result of a thorough reflection by experts.  But ... cf. the
> > numerous "no-dependency" discussions ...]
> >
> > Actually, concerning Avijit's proposed contribution, didn't I say:[1]
> > ---CUT---
> > Thus, I think that we must assess whether the "genetic algorithms"
> > functionality has a reasonable future within "Apache Commons" (i.e.
> > potential users and contributors) while there exist other libraries that
> > seem much more advanced for any serious usage.
> > ---CUT---
> >
> > > I'm also a bit concerned as to whether there are 

Re: [all] Thoughts on build system maven -> gradle??

[Paul King]

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 isn't the same as Java. Gradle also allows you to use Kotlin
for your build scripts which has some advantages but is much further away
from Java.

Personally, I would rate Gradle as easier to work with when you want to do
something a little unusual. But the flip-side is that Gradle allows many
styles/approaches of doing things whereas Maven more rigidly forces a
particular way of doing things. In Gradle, if you want to follow a
more opinionated style ala Maven, I'd recommend the kordamp plugins for
Gradle[1].

Having said all that, I would think that most commons projects fall right
into the suite sport which Maven handles well. If the familiarity of your
committers with Gradle isn't changing over time and if you don't have a
particular need which Maven isn't serving, it would be hard to justify
making the change. I wouldn't recommend trying to support both. It is an
additional maintenance burden to keep the two in sync.

Cheers, Paul.

[1] https://github.com/kordamp/kordamp-gradle-plugins


On Fri, Jul 17, 2020 at 1:02 PM Gary Gregory  wrote:

> Hi All,
>
> I don't see mixing in Groovy as the build language helping anyone, TBH it
> feels like it creates another obstacle for new contributors. The nice thing
> about Maven is that it is well known and you can extend it in Java, and
> Commons is all about Java, so it feels right, especially since both plugins
> we've developed within Commons are Maven plugins, in Java.
>
> Sure, POMs are verbose but that's XML, not Maven. At this point, I am quite
> productive using Maven in Commons, so I would not look forward to either
> migrating or being asked to maintain two build files.
>
> It seems that we finally got rid of most if not all Ant builds in favor of
> Maven, so, again, switching to another build system is not even on my
> radar.
>
> I'd rather we focus on making releasing easier instead of the 100 steps I
> have to do today.
>
> Gary
>
> On Thu, Jul 16, 2020, 22:23 Rob Tompkins  wrote:
>
> >
> >
> > > On Jul 16, 2020, at 9:17 PM, Rob Tompkins  wrote:
> > >
> > >
> > >
> > >> On Jul 16, 2020, at 9:10 PM, Matt Juntunen  >
> > wrote:
> > >>
> > >> Hi Rob,
> > >>
> > >>> I think we might be coming towards time to make this move or at least
> > accommodate for gradle builds in commons.
> > >>
> > >> Are you picturing that continued use of Maven will hinder development?
> > Is it restricting us in some way?
> > >>
> > >
> > > Not at all, just trying to gauge community opinion here.
> >
> > I’d like to reiterate that, clearly, this all may be a non-starter
> because
> > how closely we’re tied to maven. I just wanted to see what people
> thought.
> >
> > >
> > > -Rob
> > >
> > >> Regards,
> > >> Matt
> > >> 
> > >> From: Rob Tompkins 
> > >> Sent: Thursday, July 16, 2020 8:48 PM
> > >> To: Commons Developers List 
> > >> Subject: Re: [all] Thoughts on build system maven -> gradle??
> > >>
> > >>
> > >>
> > >>> On Jul 16, 2020, at 7:00 PM, Alex Remily 
> > wrote:
> > >>>
> > >>> For those of us not as familiar with Gradle, what are some of the
> > >>> benefits?  Drawbacks?
> > >>
> > >> So gradle is an analog of maven, in that it provides dependency
> > management in the same fashion. However, the configuration is written in
> > groovy (not my favorite, but indeed a Turing complete language). Clearly
> > the trade off would be that Apache’s main set of libraries moves off its
> > build system, and that in itself may be a non-starter (I’m ok with that,
> > but I feel the conversation valuable). It seems like newer java projects
> > favor a gradle build system because most java developers these days
> heavily
> > rely upon spring.
> > >>
> > >> I honestly don’t know what the right direction here is, and I’m
> > entirely open minded to anything anyone in the community has to offer.
> > >>
> > >> All the best,
> > >> -Rob
> > >>
> > >>
> > >>>
> > > On Thu, Jul 16, 2020 at 5:30 PM Rob Tompkins 
> > wrote:
> > 
> >  I think we might be coming towards time to make this move or at
> least
> > accommodate for gradle builds in commons. Let’s look to the success the
> > Spring Framework has had here with gradle. That said, I’m merely trying
> to
> > gauge opinions here and am entirely content to stay with maven, if that’s
> > what the community wishes.
> > 
> >  I’m a +1 on at least letting gradle be a part of our systems (don’t
> > have to get rid of maven either).
> > 
> >  Cheers,
> >  -Rob
> > 
> -
> >  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >  For additional commands, e-mail: dev-h...@commons.apache.org
> > 

Re: [LANG] Porting to Kotlin

[Paul King]

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 when making changes/fixing bugs, there
wouldn't be two places to change. Just a thought?

Cheers, Paul.


On Sun, May 10, 2020 at 7:58 PM Isira Seneviratne 
wrote:

> Since the original attachments did not come through, I've created a
> temporary GitHub repository for the proposed library, for anyone who is
> interested: https://github.com/Isira-Seneviratne/commons-lang-kt.git
>
> --
> Isira Seneviratne
> isirase...@gmail.com
>

Re: [LANG] Porting to Kotlin

[Paul King]

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.StringUtils

use(StringUtils) {
assert 'The quick brown fox'.abbreviateMiddle('..', 8) == 'The..fox'
assert 'abcdef'.rotate(3) == 'defabc'
}

Rather than talking about "porting", why not just create a thin
re-purposing layer that provides additional functionality to Kotlin users.
That would be easy to do as a separate project and could be incorporated
into commons lang at a later date if there was sufficient interest?

Cheers, Paul.


On Sat, Apr 25, 2020 at 2:24 PM Isira Seneviratne 
wrote:

> 
> On Mon, Apr 20, 2020 at 8:41 PM Isira Seneviratne 
> wrote:
>
>> Hi all,
>>
>> I'm a new contributor, but I've been using Commons Lang for a while now,
>> and I feel that porting Commons Lang to Kotlin would be very useful for
>> Kotlin development, as a lot of its methods (particularly those in the
>> Utils classes) are not present in the Kotlin standard library, and these
>> could be written as extensions
>> .
>>
>> What do you guys think?
>> --
>> Isira Seneviratne
>> isirase...@gmail.com
>>
>
> I have attached some sample files if anyone is interested.
> --
> Isira Seneviratne
> isirase...@gmail.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] Q: introduction of new development tool

[Paul King]

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 any more as part of your test suite.
>
> This is the same for Java::Geci. The difference is that Java::Geci works
> the other way around. It fetches code from the unit test (or for that
> matter from just any text file which contains snippets) and puts it into
> the JavaDoc (or for that matter into any text file that contains a
> segment). In this sense Java::Geci is more general, not a unit test
> specific tool. It is a tool to copy -- alter -- paste text snippets between
> files.

Good to know, Geci certainly sounds interesting.

Yes, we do it the other way around too for all of our asciidoc guides
but for what we need there's a built-in feature of asciidoc.

Cheers, Paul.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] Q: introduction of new development tool

[Paul King]

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).

For Javadoc containing specially marked code blocks (assumes code is
in ... tags and has the special attribute
class="groovyTestCase") the content is stripped out and placed into
JUnit tests and run as a suite - giving the correct line number
information if it fails. We do it for Groovy code but it could be done
for just Java code.

Examples:

assert [4,5] ==
[1,2,3,4,5].intersect([4,5,6,7,8])

/**
 * Randomly reorders the elements of the specified array.
 * 
 * Integer[] array = [10, 5, 20]
 * def origSize = array.size()
 * def copy = array.toList()
 * array.shuffle()
 * assert array.size() == origSize
 * assert copy.every{ array.contains(it) }
 * 
 *
 * @param self an array
 * @since 3.0.0
 */

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 any more as part of your test suite.

P.S. I haven't used JavadocAssertionTestSuite with Maven, just Gradle.

On Wed, Aug 28, 2019 at 11:43 AM Bruno P. Kinoshita  wrote:
>
>  In Python doctests are handy, where you can write documentation with code 
> blocks, that can be executed with a unit-test running tool, validating the 
> docs.
> It's the first time I heard about Geci. But if you could perhaps show the 
> pros and cons, what is the maintenance involved, whether it would change 
> anything in the final binary that the user sees or not, and any other 
> risks/issues.
> If you are keen to show it in a PR, maybe just one or two examples would be 
> enough to show how it works.
> Thanks! And thanks for your recent contributions to Commons Lang too Peter.
> Bruno
>
> On Wednesday, 28 August 2019, 1:00:50 am NZST, Peter Verhas 
>  wrote:
>
>  I have seen looking over the code of the LANG3 project that there are a lot
> of places where the code is copy/paste. Many times these copy/paste code is
> the result of the shortages of the Java language. We implement methods that
> look more or less the same but they have to be created for all primitive
> types. The maintenance of this code is cumbersome, changed at one place has
> to be changed at the other places as well.
>
> The framework Java::Geci can automate the maintenance of those code
> fragments. The framework is a test dependency ONLY, so it does not present
> an extra dependency for the users.
>
> The application of the framework can also be used to automatically
> copy/update code from the unit tests into the JavaDoc documentation, like
> copying and converting assertion statements into tables with inputs and
> results.
>
> I would be happy to create a few pull requests as a demonstration of how
> Java::Geci can be used for the purposes.
>
> QUESTION:
>
> What is your attitude towards a new tool like this? I do not ask a final
> decision for "yes we want to use it" or "no we do not want". I just want to
> know if the developer community would consider the use of such a tool.
>
> A last note: The tool is extremely non-invasive. Any project using it can
> decide at any point to discontinue the use. All it needs is to delete the
> tests that start the tool, remove the dependency from the POM file and that
> is it.
>
> --
> Peter Verhas
> pe...@verhas.com
> t: +41791542095
> skype: verhas
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [statistics] Proposed OLS grammar

[Paul King]

There are about 10 files using classes from the math3.stat package in
the examples I mentioned. I have stayed away from math4 while it's
still snapshot.

Repo: https://github.com/paulk-asert/groovy-data-science

Slides: https://speakerdeck.com/paulk/groovy-data-science

Most of the examples are in the subprojects/HousePrices project with a
few others just using StatUtil.

It's not my full-time day job to be using those classes but I'd be
keen to have those examples working nicely.

Cheers, Paul.

On Fri, Jul 19, 2019 at 9:11 PM Gilles Sadowski  wrote:
>
> Hi.
>
> Your 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, Paul King :
> > 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 à 01:45, Paul King  a
> >> écrit :
> >> >
> >> > 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
> >>
> >> The new "Commons Statistics" component purports to replace the
> >> functionality
> >> currently defined in the package "org.apache.commons.math4.stat" of
> >> "Commons
> >> Math.
> >>
> >> Regards,
> >> Gilles
> >>
> >> > On Fri, Jul 19, 2019 at 8:50 AM Eric Barnhill 
> >> > wrote:
> >> > >
> >> > > I suggested the following grammar to aim for in our meeting today with
> >> > > the
> >> > > developing OLS module. If you see anything you'd prefer to change
> >> > > let's
> >> > > establish it now , if anyone doesn't like it later, it's on me.
> >> > >
> >> > > RegressionData data = RegressionDataLoader.of(double[][] y, double[]
> >> > > x);
> >> > > Regression ols = new OLSRegression();
> >> > > RegressionResults results = ols.regress(data);
> >> > > betas = results.getBetas() ;
> >> > >
> >> > > where:
> >> > > RegressionData is an interface
> >> > > RegressionDataLoader is a factory class and of() a (possibly
> >> > > overloaded)
> >> > > static method
> >> > > Regression is an interface, implemented by OLSRegression
> >> > > RegressionResults is an interface, the specific class returned is
> >> > > OLSResults which implements it.
> >> > > betas are the intercept and slopes of the regression model
> >> > >
> >> > > I think this preserves abstraction at the levels desired, since we
> >> > > will
> >> > > want in future flexibility as to regression type, posslble state
> >> > > parameters
> >> > > set on the regression object, and results contents and format. But
> >> > > also
> >> > > doesn't take on any unnecessary abstractions.
> >> > >
> >> > > Eric
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [statistics] Proposed OLS grammar

[Paul King]

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 à 01:45, Paul King  a écrit :
> >
> > 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
>
> The new "Commons Statistics" component purports to replace the functionality
> currently defined in the package "org.apache.commons.math4.stat" of "Commons
> Math.
>
> Regards,
> Gilles
>
> > On Fri, Jul 19, 2019 at 8:50 AM Eric Barnhill  
> > wrote:
> > >
> > > I suggested the following grammar to aim for in our meeting today with the
> > > developing OLS module. If you see anything you'd prefer to change let's
> > > establish it now , if anyone doesn't like it later, it's on me.
> > >
> > > RegressionData data = RegressionDataLoader.of(double[][] y, double[] x);
> > > Regression ols = new OLSRegression();
> > > RegressionResults results = ols.regress(data);
> > > betas = results.getBetas() ;
> > >
> > > where:
> > > RegressionData is an interface
> > > RegressionDataLoader is a factory class and of() a (possibly overloaded)
> > > static method
> > > Regression is an interface, implemented by OLSRegression
> > > RegressionResults is an interface, the specific class returned is
> > > OLSResults which implements it.
> > > betas are the intercept and slopes of the regression model
> > >
> > > I think this preserves abstraction at the levels desired, since we will
> > > want in future flexibility as to regression type, posslble state 
> > > parameters
> > > set on the regression object, and results contents and format. But also
> > > doesn't take on any unnecessary abstractions.
> > >
> > > Eric
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [statistics] Proposed OLS grammar

[Paul King]

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 for in our meeting today with the
> developing OLS module. If you see anything you'd prefer to change let's
> establish it now , if anyone doesn't like it later, it's on me.
>
> RegressionData data = RegressionDataLoader.of(double[][] y, double[] x);
> Regression ols = new OLSRegression();
> RegressionResults results = ols.regress(data);
> betas = results.getBetas() ;
>
> where:
> RegressionData is an interface
> RegressionDataLoader is a factory class and of() a (possibly overloaded)
> static method
> Regression is an interface, implemented by OLSRegression
> RegressionResults is an interface, the specific class returned is
> OLSResults which implements it.
> betas are the intercept and slopes of the regression model
>
> I think this preserves abstraction at the levels desired, since we will
> want in future flexibility as to regression type, posslble state parameters
> set on the regression object, and results contents and format. But also
> doesn't take on any unnecessary abstractions.
>
> Eric

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL][RFC] Github subjects don't contain the repo name

[Paul King]

+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 would be would be useful if the repo name was included in
> the subject prefix.
>
> For example.
> Instead of:
>
> [GitHub] zsoltii opened a new pull request #74: Add new function:
> byteCountToDisplayRoundedSize
>
> The subject would be:
>
> [GitHub] (commons-io) zsoltii opened a new pull request #74: Add new
> function: byteCountToDisplayRoundedSize
>
> WDYT?
>
> If there is support for this I will raise an Infra enhancement request.
>
> S.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [collections] breaking changes

[Paul King]

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 <paul.king.as...@gmail.com> wrote:
> In the Groovy build we do this using Bridger
> (https://github.com/dmlloyd/bridger). It's built with gradle (and uses
> Ant). They have a Maven plugin but I haven't used it.
>
> In our build we have this:
>
> compileJava {
> doLast {
> ant.java(classname:'org.jboss.bridger.Bridger', classpath:
> rootProject.configurations.tools.asPath, outputproperty: 'stdout') {
> arg(value:
> "${sourceSets.main.java.outputDir.canonicalPath}/org/codehaus/groovy/runtime/DefaultGroovyMethods.class")
> }
> ant.echo('Bridger: ' + ant.properties.stdout)
> }
> }
>
> And in the relevant source file we have a small number of $$bridge
> methods like this one:
>
> public static  List withDefault$$bridge(List self, Closure init) {
> return withDefault(self, init);
> }
>
> to match the original methods we are duplicating, e.g.:
>
> public static  ListWithDefault withDefault(List self,
> Closure init) {
> // ... code here ...
> }
>
> Cheers, Paul.
>
> On Fri, Mar 30, 2018 at 9:52 AM, Peter Burka <pe...@quux.net> wrote:
>> This could be solved if it were possible to force javac to generate bridge
>> methods. There's an extension which would allow that here:
>> https://github.com/infradna/bridge-method-injector, but I suspect it would
>> complicate the build process quite a bit.
>>
>> On Thu, Mar 29, 2018 at 4:48 PM sebb <seb...@gmail.com> wrote:
>>
>>> The return type is part of the method signature that Java uses to find
>>> resolve references.
>>>
>>> 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 <garydgreg...@gmail.com> wrote:
>>> > Yep, that's no good. I'll revert.
>>> >
>>> > Gary
>>> >
>>> > On Thu, Mar 29, 2018 at 10:16 AM, Paul King <paul.king.as...@gmail.com>
>>> > wrote:
>>> >
>>> >> 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 compile this user of the library:
>>> >>
>>> >> import java.util.List;
>>> >>
>>> >> public class Main {
>>> >> public static void main(String[] args) {
>>> >> doit(new Lib().getMyList());
>>> >> }
>>> >>
>>> >> private static void doit(List list) {
>>> >> System.out.println("list is: " + list);
>>> >> }
>>> >> }
>>> >>
>>> >>
>>> >> Ensure it all works:
>>> >>
>>> >> > java -cp path_to_lib Main
>>> >>
>>> >> Should output:
>>> >>
>>> >> List is: []
>>> >>
>>> >> Now change the Lib class to return ArrayList instead of List and
>>> >> recompile just the Lib class (i.e. importantly don't recompile Main).
>>> >>
>>> >> Now if you try:
>>> >>
>>> >> > java -cp path_to_lib Main
>>> >>
>>> >> you should see:
>>> >>
>>> >> Exception in thread "main" java.lang.NoSuchMethodError:
>>> >> Lib.getMyList()Ljava/util/List;
>>> >> at Main.main(Main.java:5)
>>> >>
>>> >> Cheers, Paul.
>>> >>
>>> >> On Fri, Mar 30, 2018 at 1:41 AM, Gary Gregory <garydgreg...@gmail.com>
>>> >> wrote:
>>> >> > Can you show how older code would not function. Aside from using
>>> >> reflection.
>>> >> >
>>> >> > Gary
>>> >> >
>>> >> > On Thu, Mar 29, 2018, 09:03 Claude Warren <cla

Re: [collections] breaking changes

[Paul King]

In the Groovy build we do this using Bridger
(https://github.com/dmlloyd/bridger). It's built with gradle (and uses
Ant). They have a Maven plugin but I haven't used it.

In our build we have this:

compileJava {
doLast {
ant.java(classname:'org.jboss.bridger.Bridger', classpath:
rootProject.configurations.tools.asPath, outputproperty: 'stdout') {
arg(value:
"${sourceSets.main.java.outputDir.canonicalPath}/org/codehaus/groovy/runtime/DefaultGroovyMethods.class")
}
ant.echo('Bridger: ' + ant.properties.stdout)
}
}

And in the relevant source file we have a small number of $$bridge
methods like this one:

public static  List withDefault$$bridge(List self, Closure init) {
return withDefault(self, init);
}

to match the original methods we are duplicating, e.g.:

public static  ListWithDefault withDefault(List self,
Closure init) {
// ... code here ...
}

Cheers, Paul.

On Fri, Mar 30, 2018 at 9:52 AM, Peter Burka <pe...@quux.net> wrote:
> This could be solved if it were possible to force javac to generate bridge
> methods. There's an extension which would allow that here:
> https://github.com/infradna/bridge-method-injector, but I suspect it would
> complicate the build process quite a bit.
>
> On Thu, Mar 29, 2018 at 4:48 PM sebb <seb...@gmail.com> wrote:
>
>> The return type is part of the method signature that Java uses to find
>> resolve references.
>>
>> 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 <garydgreg...@gmail.com> wrote:
>> > Yep, that's no good. I'll revert.
>> >
>> > Gary
>> >
>> > On Thu, Mar 29, 2018 at 10:16 AM, Paul King <paul.king.as...@gmail.com>
>> > wrote:
>> >
>> >> 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 compile this user of the library:
>> >>
>> >> import java.util.List;
>> >>
>> >> public class Main {
>> >> public static void main(String[] args) {
>> >> doit(new Lib().getMyList());
>> >> }
>> >>
>> >> private static void doit(List list) {
>> >> System.out.println("list is: " + list);
>> >> }
>> >> }
>> >>
>> >>
>> >> Ensure it all works:
>> >>
>> >> > java -cp path_to_lib Main
>> >>
>> >> Should output:
>> >>
>> >> List is: []
>> >>
>> >> Now change the Lib class to return ArrayList instead of List and
>> >> recompile just the Lib class (i.e. importantly don't recompile Main).
>> >>
>> >> Now if you try:
>> >>
>> >> > java -cp path_to_lib Main
>> >>
>> >> you should see:
>> >>
>> >> Exception in thread "main" java.lang.NoSuchMethodError:
>> >> Lib.getMyList()Ljava/util/List;
>> >> at Main.main(Main.java:5)
>> >>
>> >> Cheers, Paul.
>> >>
>> >> On Fri, Mar 30, 2018 at 1:41 AM, Gary Gregory <garydgreg...@gmail.com>
>> >> wrote:
>> >> > Can you show how older code would not function. Aside from using
>> >> reflection.
>> >> >
>> >> > Gary
>> >> >
>> >> > On Thu, Mar 29, 2018, 09:03 Claude Warren <cla...@xenei.com> wrote:
>> >> >
>> >> >> if we are using semantic numbering would this not cause a major
>> revision
>> >> >> change as older code will no longer function?
>> >> >>
>> >> >> Claude
>> >> >>
>> >> >> On Thu, Mar 29, 2018 at 3:51 PM, Gary Gregory <
>> garydgreg...@gmail.com>
>> >> >> wrote:
>> >> >>
>> >> >> > Hi All:
>> >> >> >
>> >> >> > Updating Commons Collections' commons-parent from version 43 to 45
>> >> causes
>> >> >> > the build to fail due to the use of japicmp 

Re: [collections] breaking changes

[Paul King]

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 compile this user of the library:

import java.util.List;

public class Main {
public static void main(String[] args) {
doit(new Lib().getMyList());
}

private static void doit(List list) {
System.out.println("list is: " + list);
}
}


Ensure it all works:

> java -cp path_to_lib Main

Should output:

List is: []

Now change the Lib class to return ArrayList instead of List and
recompile just the Lib class (i.e. importantly don't recompile Main).

Now if you try:

> java -cp path_to_lib Main

you should see:

Exception in thread "main" java.lang.NoSuchMethodError:
Lib.getMyList()Ljava/util/List;
at Main.main(Main.java:5)

Cheers, Paul.

On Fri, Mar 30, 2018 at 1:41 AM, Gary Gregory  wrote:
> Can you show how older code would not function. Aside from using reflection.
>
> Gary
>
> On Thu, Mar 29, 2018, 09:03 Claude Warren  wrote:
>
>> if we are using semantic numbering would this not cause a major revision
>> change as older code will no longer function?
>>
>> Claude
>>
>> On Thu, Mar 29, 2018 at 3:51 PM, Gary Gregory 
>> wrote:
>>
>> > Hi All:
>> >
>> > Updating Commons Collections' commons-parent from version 43 to 45 causes
>> > the build to fail due to the use of japicmp which reports:
>> >
>> > [ERROR] Failed to execute goal
>> > org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on
>> > project commons-collections4: Error generating
>> > japicmp-maven-plugin:0.11.0:cmp-report report: Failed to generate report:
>> > Breaking the build because there is at least one incompatibility:
>> > org.apache.commons.collections4.IteratorUtils.peekingIterator(java.util.
>> > Iterator):METHOD_RETURN_TYPE_CHANGED,org.apache.commons.
>> > collections4.IteratorUtils.pushbackIterator(java.util.
>> > Iterator):METHOD_RETURN_TYPE_CHANGED
>> > -> [Help 1]
>> >
>> > This is caused by:
>> >
>> > - [COLLECTIONS-676] Modify IteratorUtils.pushbackIterator signature to
>> > return PushbackIterator.
>> > - [COLLECTIONS-675] Modify IteratorUtils.peekingIterator signature to
>> > return PeekingIterator.
>> >
>> > Which are reasonable changes IMO.
>> >
>> > Does anyone object to these changes and adding exceptions to allow
>> japicmp
>> > to
>> > not fail the build?
>> >
>> > Thank you,
>> > Gary
>> >
>>
>>
>>
>> --
>> I like: Like Like - The likeliest place on the web
>> 
>> LinkedIn: http://www.linkedin.com/in/claudewarren
>>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Todo utility class

[Paul King]

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 similar using lambdas in Java.

It also has an @AutoImplement annotation which you can place on any
class to get dummy implementations for any abstract methods. By
default you get empty implementations (returning default values if
needed, e.g. false, 0, null) or you specify an exception to throw.

For testing, it also has a @NotYetImplemented annotation and a
GroovyAssert.notYetImplemented() method. Both flip the result of JUnit
tests. That way you can specify what the behavior of your TODO object
is supposed to do and it won't break your test suite.

Cheers, Paul.


On Tue, Mar 20, 2018 at 11:21 AM, Matt Sicker  wrote:
> I’ve used NotImplementedException as a way to do this. In Scala, there is a
> function called ??? which throws a similar exception, and in Kotlin,
> there’s an equivalent function called TODO.
>
> On Mon, Mar 19, 2018 at 20:09, Gary Gregory  wrote:
>
>> Been out with the flu, jumping in late...
>>
>> It seems like using one or more annotations would be better for tooling...
>>
>> Gary
>>
>> On Sun, Mar 18, 2018, 07:57 Gilles  wrote:
>>
>> > On Sun, 18 Mar 2018 13:20:18 +0100, Jochen Wiedmann wrote:
>> > > On Fri, Mar 16, 2018 at 12:05 AM, Gilles
>> > >  wrote:
>> > >
>> > >> Perhaps "Commons Testing".
>> > >> IIUC, such calls are not meant to appear in released code.
>> > >
>> > > Neither would testing.
>> >
>> > Exactly, and the reason why I proposed that home.
>> > Rationale is pretty obvious IMHO: code that contains calls
>> > to a "Todo" class is under test (or in beta state).
>> >
>> > Gilles
>> >
>> > > I like the idea of a Todo class. Makes
>> > > searching for such places extremely neat, and simple.
>> > >
>> > > Jochen
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>> >
>>
> --
> Matt Sicker 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Commons sub project for parallel method execution

[Paul King]

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 two jars (GPars + Groovy), you can use Groovy like this:

@Grab('org.codehaus.gpars:gpars:1.2.1')
import com.arun.student.StudentService
import groovyx.gpars.GParsExecutorsPool

long startTime = System.nanoTime()
def service = new StudentService()
def bookSeries = ["A Song of Ice and Fire": 7, "Wheel of Time": 14,
"Harry Potter": 7]

def tasks = [
{ println service.findStudent("j...@gmail.com", 11, false) },
{ println service.getStudentMarks(1L) },
{ println service.getStudentsByFirstNames(["John","Alice"]) },
{ println service.getRandomLastName() },
{ println service.findStudentIdByName("Kate", "Williams") },
{ service.printMapValues(bookSeries) }
]

GParsExecutorsPool.withPool {
tasks.collect{ it.callAsync() }.collect{ it.get() }
//tasks.eachParallel{ it() } // one of numerous alternatives
}

long executionTime = (System.nanoTime() - startTime) / 100
println "\nTotal elapsed time is $executionTime\n\n"


Cheers, Paul.


On Tue, Jun 13, 2017 at 9:29 AM, Matt Sicker  wrote:
> I'd be interested to see where this leads to. It could end up as a sort of
> Commons Parallel library. Besides providing an execution API, there could
> be plenty of support utilities that tend to be found in all the
> *Util(s)/*Helper classes in projects like all the ones I mentioned earlier
> (basically all sorts of Hadoop-related projects and other distributed
> systems here).
>
> Really, there's so many ways that such a project could head, I'd like to
> hear more ideas on what to focus on.
>
> On 12 June 2017 at 18:19, Gary Gregory  wrote:
>
>> The upshot is that there has to be a way to do this with some custom code
>> to at least have the ability to 'fast path' the code without reflection.
>> Using lambdas should make this fairly syntactically unobtrusive.
>>
>> On Mon, Jun 12, 2017 at 4:02 PM, Arun Mohan 
>> wrote:
>>
>> > Yes, reflection is not very performant but I don't think I have any other
>> > choice since the library has to inspect the object supplied by the client
>> > at runtime to pick out the methods to be invoked using CompletableFuture.
>> > But the performance penalty paid for using reflection will be more than
>> > offset by the savings of parallel method execution, more so as the no of
>> > methods executed in parallel increases.
>> >
>> > On Mon, Jun 12, 2017 at 3:21 PM, Gary Gregory 
>> > wrote:
>> >
>> > > On a lower-level, if you want to use this for lower-level services
>> (where
>> > > there is no network latency for example), you will need to avoid using
>> > > reflection to get the best performance.
>> > >
>> > > Gary
>> > >
>> > > On Mon, Jun 12, 2017 at 3:15 PM, Arun Mohan 
>> > > wrote:
>> > >
>> > > > Hi Gary,
>> > > >
>> > > > Thanks for your response. You have some valid and interesting points
>> > :-)
>> > > > Of course you are right that Spark is much more mature. Thanks for
>> your
>> > > > insight.
>> > > > It will be interesting indeed to find out if the core parallelization
>> > > > engine of Spark can be isolated like you suggest.
>> > > >
>> > > > I started working on this project because I felt that there was no
>> good
>> > > > library for parallelizing method calls which can be plugged in easily
>> > > into
>> > > > an existing java project. Ultimately, if such a solution can be
>> > > > incorporated in the Apache Commons, it would be a useful addition to
>> > the
>> > > > Commons repository.
>> > > >
>> > > > Thanks,
>> > > > Arun
>> > > >
>> > > >
>> > > >
>> > > > On Mon, Jun 12, 2017 at 3:01 PM, Gary Gregory <
>> garydgreg...@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > Hi Arun,
>> > > > >
>> > > > > Sure, and that is to be expected, Spark is more mature than a four
>> > > class
>> > > > > prototype. What I am trying to get to is that in order for the
>> > library
>> > > to
>> > > > > be useful, you will end up with more in a first release, and after
>> a
>> > > > couple
>> > > > > more releases, there will be more and more. Would Spark not have in
>> > its
>> > > > > guts the same kind of code your are proposing here? By extension,
>> > will
>> > > > you
>> > > > > not end up with more framework-like (Spark-like) code and solutions
>> > as
>> > > > > found in Spark? I am just playing devil's advocate here ;-)
>> > > > >
>> > > > >
>> > > > > What would be interesting would be to find out if there is a core
>> > part
>> > > of
>> > > > > Spark that is separable and ex tractable into a Commons component.
>> > > Since
>> > > > > Spark has a proven track record, it is more likely, that such a
>> > library
>> > > > > 

Re: [VOTE] Release Apache Commons CLI 1.4 based on RC1

[Paul King]

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 <paul.king.as...@gmail.com> wrote:
> +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 tests where Groovy uses commons cli directly too.
>
> Cheers, Paul.
>
>
> On Thu, Mar 9, 2017 at 11:30 PM, Benedikt Ritter <brit...@apache.org> wrote:
>> Hi,
>>
>> We have fixed some bugs and added two new features since CLI 1.3.1 was 
>> released,
>> so I would like to release CLI 1.4.
>>
>> CLI 1.4 RC1 is available for review here:
>> https://dist.apache.org/repos/dist/dev/commons/cli/cli-1.4-RC1/ (svn 
>> revision 18640)
>>
>> The tag is here:
>> http://svn.apache.org/repos/asf/commons/proper/cli/tags/cli-1.4-RC1/ 
>> (svn revision 1786159)
>> N.B. the SVN revision is required because SVN tags are not immutable.
>>
>> Maven artifacts are here:
>>   https://repository.apache.org/content/repositories/orgapachecommons-1240
>>
>> These are the Maven Artifacts and their hashes:
>>
>> commons-cli-1.4.pom.asc
>> (SHA1: 94f01d5c45d00d7cfda8f7d0b8e16f57318b02a3)
>> commons-cli-1.4-test-sources.jar
>> (SHA1: 98e1c62e29f0c86c0bd8361cf6fdb59c8a106ff4)
>> commons-cli-1.4.jar
>> (SHA1: c51c00206bb913cd8612b24abd9fa98ae89719b1)
>> commons-cli-1.4-sources.jar.asc
>> (SHA1: 80a7676aba577faafd8278e9b321abaa426f3b45)
>> commons-cli-1.4-tests.jar
>> (SHA1: 1e39d7027793ce92342b10abb4d6437826211534)
>> commons-cli-1.4-tests.jar.asc
>> (SHA1: a558a4e58802af24ce58404df98b8c5737297bc9)
>> commons-cli-1.4-javadoc.jar.asc
>> (SHA1: d67ed3fea7b0346fcfa2a3c9c4092741ce6a84a7)
>> commons-cli-1.4-sources.jar
>> (SHA1: 40dfd9fdef125e19136135e68d54af6d9b0cfbb8)
>> commons-cli-1.4-javadoc.jar
>> (SHA1: 60090d1d137b0dd7a0c293d04fb2280a7eec3860)
>> commons-cli-1.4-test-sources.jar.asc
>> (SHA1: 180e61b1fba50d93291e4cbf35bbdfc0ba04a43f)
>> commons-cli-1.4.jar.asc
>> (SHA1: d6a040cbdc4789aeabe74f8e9f9602c7bd430541)
>> commons-cli-1.4.pom
>> (SHA1: c5aed4264ff37247043f6dcb6613d994ea7f8473)
>>
>> I have tested this with JDK 1.7 and JDK 1.8 using Maven 3.3.9. Note that CLI 
>> required at least Java 5 and I haven’t tested this release with 1.5 or 1.6. 
>> If anybody has such old JDKs installed, I would appreciate some feedback on 
>> this.
>>
>> Details of changes since 1.3.1 are in the release notes:
>>   
>> https://dist.apache.org/repos/dist/dev/commons/cli/cli-1.4-RC1/RELEASE-NOTES.txt
>>   http://home.apache.org/~britter/commons/cli/1.4-RC1/changes-report.html
>>
>> Site:
>>   http://home.apache.org/~britter/commons/cli/1.4-RC1/
>>   (note some *relative* links are broken and the 1.4 directories are not yet 
>> created - these will be OK once the site is deployed)
>>
>> Clirr Report (compared to 1.3.1):
>>   http://home.apache.org/~britter/commons/cli/1.4-RC1/clirr-report.html
>> (Sorry, after updating to commons-parent 42 the clirr report was not 
>> generated anymore. I had to do it by hand, that’s why it has a different 
>> style)
>>
>> RAT Report:
>>   http://home.apache.org/~britter/commons/cli/1.4-RC1/rat-report.html
>>
>> KEYS:
>>   https://www.apache.org/dist/commons/KEYS
>>
>> Please review the release candidate and vote.
>> This vote will close no sooner that 72 hours from now,
>> i.e. sometime after 13:30 UTC 12-March 2017
>>
>>   [ ] +1 Release these artifacts
>>   [ ] +0 OK, but...
>>   [ ] -0 OK, but really should fix...
>>   [ ] -1 I oppose this release because...
>>
>> Thanks!
>>
>> Benedikt
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons CLI 1.4 based on RC1

[Paul King]

+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 tests where Groovy uses commons cli directly too.

Cheers, Paul.


On Thu, Mar 9, 2017 at 11:30 PM, Benedikt Ritter  wrote:
> Hi,
>
> We have fixed some bugs and added two new features since CLI 1.3.1 was 
> released,
> so I would like to release CLI 1.4.
>
> CLI 1.4 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/cli/cli-1.4-RC1/ (svn 
> revision 18640)
>
> The tag is here:
> http://svn.apache.org/repos/asf/commons/proper/cli/tags/cli-1.4-RC1/ (svn 
> revision 1786159)
> N.B. the SVN revision is required because SVN tags are not immutable.
>
> Maven artifacts are here:
>   https://repository.apache.org/content/repositories/orgapachecommons-1240
>
> These are the Maven Artifacts and their hashes:
>
> commons-cli-1.4.pom.asc
> (SHA1: 94f01d5c45d00d7cfda8f7d0b8e16f57318b02a3)
> commons-cli-1.4-test-sources.jar
> (SHA1: 98e1c62e29f0c86c0bd8361cf6fdb59c8a106ff4)
> commons-cli-1.4.jar
> (SHA1: c51c00206bb913cd8612b24abd9fa98ae89719b1)
> commons-cli-1.4-sources.jar.asc
> (SHA1: 80a7676aba577faafd8278e9b321abaa426f3b45)
> commons-cli-1.4-tests.jar
> (SHA1: 1e39d7027793ce92342b10abb4d6437826211534)
> commons-cli-1.4-tests.jar.asc
> (SHA1: a558a4e58802af24ce58404df98b8c5737297bc9)
> commons-cli-1.4-javadoc.jar.asc
> (SHA1: d67ed3fea7b0346fcfa2a3c9c4092741ce6a84a7)
> commons-cli-1.4-sources.jar
> (SHA1: 40dfd9fdef125e19136135e68d54af6d9b0cfbb8)
> commons-cli-1.4-javadoc.jar
> (SHA1: 60090d1d137b0dd7a0c293d04fb2280a7eec3860)
> commons-cli-1.4-test-sources.jar.asc
> (SHA1: 180e61b1fba50d93291e4cbf35bbdfc0ba04a43f)
> commons-cli-1.4.jar.asc
> (SHA1: d6a040cbdc4789aeabe74f8e9f9602c7bd430541)
> commons-cli-1.4.pom
> (SHA1: c5aed4264ff37247043f6dcb6613d994ea7f8473)
>
> I have tested this with JDK 1.7 and JDK 1.8 using Maven 3.3.9. Note that CLI 
> required at least Java 5 and I haven’t tested this release with 1.5 or 1.6. 
> If anybody has such old JDKs installed, I would appreciate some feedback on 
> this.
>
> Details of changes since 1.3.1 are in the release notes:
>   
> https://dist.apache.org/repos/dist/dev/commons/cli/cli-1.4-RC1/RELEASE-NOTES.txt
>   http://home.apache.org/~britter/commons/cli/1.4-RC1/changes-report.html
>
> Site:
>   http://home.apache.org/~britter/commons/cli/1.4-RC1/
>   (note some *relative* links are broken and the 1.4 directories are not yet 
> created - these will be OK once the site is deployed)
>
> Clirr Report (compared to 1.3.1):
>   http://home.apache.org/~britter/commons/cli/1.4-RC1/clirr-report.html
> (Sorry, after updating to commons-parent 42 the clirr report was not 
> generated anymore. I had to do it by hand, that’s why it has a different 
> style)
>
> RAT Report:
>   http://home.apache.org/~britter/commons/cli/1.4-RC1/rat-report.html
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now,
> i.e. sometime after 13:30 UTC 12-March 2017
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thanks!
>
> Benedikt
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [OT][CLI] JCommander Add-ons

[Paul King]

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
providing an annotation-based option while leaving the api part of [cli] in
place as it exist now.

Some groovydoc (search for annotation style):

http://docs.groovy-lang.org/docs/next/html/gapi/groovy/util/CliBuilder.html

Some examples from the Groovy test code (search for @Option):

https://github.com/apache/groovy/blob/master/src/test/groovy/util/CliBuilderTest.groovy

Groovy documentation:

http://docs.groovy-lang.org/docs/next/html/documentation/#_clibuilder

Just three examples (pulled out of above) in case you don't want to click
the links.

Your cli arguments can be specified using an interface spec and can have
inline closures for converters if needed:

import groovy.cli.*

interface ConvertSpec {
@Option(convert={ it.toLowerCase() }) String a()
@Option(convert={ it.toUpperCase() }) String b()
@Option(convert={ Date.parse("-MM-dd", it) }) Date d()
@Unparsed List remaining()
}

Date newYears = Date.parse("-MM-dd", "2016-01-01")
def argz = '''-a John -b Mary -d 2016-01-01 and some more'''.split()
def cli = new CliBuilder()
def options = cli.parseFromSpec(ConvertSpec, argz)
assert options.a() == 'john'
assert options.b() == 'MARY'
assert options.d() == newYears
assert options.remaining() == ['and', 'some', 'more']

Your spec can be an existing class and it supports Groovy's type checking
if you need it:

class MyTypedSpec {
@Option String name
@Option int age
@Unparsed List remaining
}

@TypeChecked
void testTypeCheckedClass() {
def argz = "--name John --age 21 and some more".split()
def cli = new CliBuilder()
def options = new MyTypedSpec()
cli.parseFromInstance(options, argz)
String n = options.name // will be type checked
int a = options.age // will be type checked
assert n == 'John' && a == 21
assert options.remaining == ['and', 'some', 'more']
}

It can also be used directly from scripts as follows (showing some of
the builtin types and enum support):

import groovy.cli.*
import java.math.RoundingMode

// override commandline args for testing
def args = "--name John --flag --born 1980 --discount 3.5 --pi 3.14159
--biography cv.txt --roundingMode DOWN and some more".split()
@OptionField String name
@OptionField boolean flag
@OptionField Integer born
@OptionField float discount
@OptionField BigDecimal pi
@OptionField File biography
@OptionField RoundingMode roundingMode
@UnparsedField List remaining
new CliBuilder().parseFromInstance(this, args)
assert name == 'John'
assert flag
assert born == 1980
assert discount == 3.5f
assert pi == 3.14159G
assert biography == new File('cv.txt')
assert roundingMode == RoundingMode.DOWN
assert remaining == ['and', 'some', 'more']



Cheers, Paul.


On Mon, Oct 31, 2016 at 5:30 AM, Gary Gregory 
wrote:

> For the curious,
>
> I'd love to see [cli] evolve into something like JCommander [1] and it's
> annotation-based system.
>
> In the meantime, I use JCommander mostly but some [cli] in some old
> projects that are in maintenance mode. JCommander is great but is not
> perfect or complete, so I created some add-ons here
> https://github.com/garydgregory/jcommander-addons
>
> Any thoughts or feedback are welcome.
>
> Thank you,
> Gary
>
> [1] http://jcommander.org/
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
>  tl?ie=UTF8=1789=9325=1617290459&
> linkCode=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8>
>
>  1617290459>
> JUnit in Action, Second Edition
>  tl?ie=UTF8=1789=9325=1935182021&
> linkCode=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
>
>  1935182021>
> Spring Batch in Action
>  tl?ie=UTF8=1789=9325=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>  1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

Re: [DISCUSS] Brining clirr to the ASF?

[Paul King]

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 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 strategy upon clirr. So I wonder whether we
> > >> should foster bringing clirr to the ASF (for example by going through
> > >> incubation). We're probably not the only ASF project using Clirr.
> > >>
> > >
> > > +1. Can we bring in code that's under GNU Lesser General Public and
> make
> > it
> > > ASL 2?
> > >
> > > Could fit under a new Commons Build or Clirr component since it is a
> > > "common" build requirement.
> >
> > As Clirr is internally based on BCEL, I'd rather see us build a new
> > tool on top of ASM, which is very well maintained. Besides, that would
> > solve the license problem.
> >
> > Jochen
> >
> >
> > --
> > The next time you hear: "Don't reinvent the wheel!"
> >
> >
> >
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [ANNOUNCE] Apache Commons CLI 1.3.1 released!

[Paul King]

Nice work!

On Thu, Jun 18, 2015 at 4:48 PM, Benedikt Ritter brit...@apache.org 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 messages detailing
 the options available for a command line tool.

 1.3.1 is binary compatible to the last release 1.3. The only change
 compared to 1.3 is the fix of CLI-252 [1]. The minimum required JDK version
 for this release is 1.5.

 Source and binary distributions are available for download from the Apache
 Commons download site:
   http://commons.apache.org/proper/commons-cli/download_cli.cgi

 When downloading, please verify signatures using the KEYS file available at
 the above location.

 Alternatively the release can be pulled via maven:
 dependency
   groupIdcommons-cli/groupId
   artifactIdcommons-cli/artifactId
   version1.3.1/version
 /dependency

 For complete information on Commons CLI, including instructions on how to
 submit bug reports, patches, or suggestions for improvement, see the Apache
 Commons CLI website:

 http://commons.apache.org/proper/commons-cli/

 Thank you!

 Benedikt Ritter,
 on behalf of the Apache Commons Community

 [1] https://issues.apache.org/jira/browse/CLI-252


 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter

Re: [VOTE] Release Apache Commons CLI 1.3.1 based on RC1

[Paul King]

+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 hitting more of the 1.3 Apis and all looks good so far. I
did hit CLI-252,
so happy to have a new release.

On Mon, Jun 15, 2015 at 5:17 PM, Bruno P. Kinoshita 
brunodepau...@yahoo.com.br wrote:

 +1 not binding
 Build works fine with
 Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
 2014-12-15T06:29:23+13:00)
 Maven home: /opt/apache-maven-3.2.5
 Java version: 1.8.0_45, vendor: Oracle Corporation
 Java home: /usr/lib/jvm/java-8-oracle/jre
 Default locale: en_US, platform encoding: UTF-8
 OS name: linux, version: 3.16.0-38-generic, arch: amd64, family:
 unix
 No new errors in reports, all tests pass.

 CheersBruno

   From: Benedikt Ritter brit...@apache.org
  To: Commons Developers List dev@commons.apache.org
  Sent: Sunday, June 14, 2015 10:32 PM
  Subject: [VOTE] Release Apache Commons CLI 1.3.1 based on RC1

 Hi,

 We have introduced a pretty severe bug in CLI 1.3, so I'd like to call a
 vote to release CLI 1.3.1 based on RC1. The only change compared to 1.3 is
 the fix of CLI-252 [1].

 CLI 1.3.1 RC1 is available for review here:
   https://dist.apache.org/repos/dist/dev/commons/cli/ (svn 9362)

 Maven artifacts are here:

 https://repository.apache.org/content/repositories/orgapachecommons-1099/

 Details of changes since 1.3 are in the release notes:
   https://dist.apache.org/repos/dist/dev/commons/cli/RELEASE-NOTES.txt
   http://people.apache.org/~britter/cli-1.3.1-RC1/changes-report.html

 The tag is here:
   http://svn.apache.org/repos/asf/commons/proper/cli/tags/cli-1.3.1-RC1/
 (svn 1685378)

 Site:
   http://people.apache.org/~britter/cli-1.3.1-RC1/
   (note some *relative* links are broken and the 1.3.1 directories are not
 yet created - these will be OK once the site is deployed)

 Clirr Report (compared to 1.3):
   http://people.apache.org/~britter/cli-1.3.1-RC1/clirr-report.html

 RAT Report:
   http://people.apache.org/~britter/cli-1.3.1-RC1/rat-report.html

 KEYS:
   https://www.apache.org/dist/commons/KEYS

 Please review the release candidate and vote.
 This vote will close no sooner that 72 hours from now, i.e. after 13:00
 CEST 17-June 2015

   [ ] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...

 Thanks!

 Benedikt

 [1] https://issues.apache.org/jira/browse/CLI-252


 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter

Re: [CLI] Release 1.3

[Paul King]

Yes Jörg, I'll keep that in mind.

Cheers,Paul.


On Thu, May 7, 2015 at 5:28 PM, Jörg Schaible joerg.schai...@swisspost.com
wrote:

 Hi Paul,

 Paul King wrote:

  On Mon, May 4, 2015 at 4:06 PM, Benedikt Ritter brit...@apache.org
 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 step forward for us. Thanks! (And thanks
  Pascal for doing the checking).
 
  Having said that, I should also give you a little bit more context.
  We forked our own version of PosixParser in late 2012. Our version has
  some of the bug fixes from 1.3 and some of our own bug fixes. So the
  current build
  is still using that class and that in turn refers to a bunch of the
  classes which
  were deprecated in CLI 1.3.
 
  We have a bunch of open Groovy JIRA issues related to CLI 1.2 bugs.
  We'll have to check them individually to see whether we can close off any
  with CLI 1.3 in place. I suspect some might remain because of our use
  of our forked class at present.
 
  We'll certainly have a bunch more feedback when we try to deprecate our
  forked class and migrate ourselves across to the DefaultParser which
 we'll
  do over the coming months once CLI 1.3 is out.
 
  At least with a 1.3 out we'll be in a much better position to iteratively
  move
  across and also give you timely and relevant feedback for any issues that
  we find.

 As ASF committers you're even free to do this yourself directly. Commons is
 open for all.

 Cheers,
 Jörg


 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org

Re: [CLI] Release 1.3

[Paul King]

On Mon, May 4, 2015 at 4:06 PM, Benedikt Ritter brit...@apache.org 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 step forward for us. Thanks! (And thanks Pascal for
doing the checking).

Having said that, I should also give you a little bit more context.
We forked our own version of PosixParser in late 2012. Our version has some
of the bug fixes from 1.3 and some of our own bug fixes. So the current
build
is still using that class and that in turn refers to a bunch of the classes
which
were deprecated in CLI 1.3.

We have a bunch of open Groovy JIRA issues related to CLI 1.2 bugs.
We'll have to check them individually to see whether we can close off any
with CLI 1.3 in place. I suspect some might remain because of our use
of our forked class at present.

We'll certainly have a bunch more feedback when we try to deprecate our
forked class and migrate ourselves across to the DefaultParser which we'll
do over the coming months once CLI 1.3 is out.

At least with a 1.3 out we'll be in a much better position to iteratively
move
across and also give you timely and relevant feedback for any issues that
we find.

Cheers, Paul.

Re: [CLI] Release 1.3

[Paul King]

 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.
 Emmanuel Bourg


Any ETA on a potential release?

Thanks, Paul.