Re: [all] github (was Re: [VOTE] Create additional mailing lists for automated posts)
>GitHub is basically our interactive pull request interface. If we didn’t have that, I bet we’d be running GitLab ourselves or similar. Yes, that is what I think gitbox lacks. Cannot imagine a git-based website having no convenient pr system... >Also, being that the bar to be a committer here is fairly low, getting access to gitbox directly isn’t too difficult. This is decided by what you mean 'low'... As far as I can see in my prs, most of the time I need to wait for very long to get reviewed. I think that can indicate the fact that we have no enough committers(or no enough reviewers). Or, quite some committers only focus on their own prs, but not do any reviews? For examples about my prs at commons-lang,if my memory is correct, only gary (and sometimes kinow) reviewed my prs, and I don't think we have only two committers in commons-lang. Matt Sicker 于2020年7月26日周日 上午1:41写道： > GitHub is basically our interactive pull request interface. If we didn’t > have that, I bet we’d be running GitLab ourselves or similar. > > Also, being that the bar to be a committer here is fairly low, getting > access to gitbox directly isn’t too difficult. > > On Fri, Jul 24, 2020 at 12:17 Xeno Amess wrote: > > > besides, that is JIRA where we can apply patch, but I think it SHOULD be > > done on gutbox. github, gitlab, all of them have a convienent pr system. > > so yes our JIRA is good, I like JIRA. > > But for gitbox, I think it really lack lots of things. > > Or, there be those things, but not open. > > > > Xeno Amess 于 2020年7月25日周六 上午1:11写道： > > > > > you know that is really complex and time costing... > > > especially when we want some trigger invoked like travis-ci. > > > > > > Stefan Bodewig 于 2020年7月25日周六 上午1:06写道： > > > > > >> On 2020-07-24, Xeno Amess wrote: > > >> > > >> > I will explain why github come to be center, but not apache gitbox. > > >> > 1.1 > > >> > I have right to register an account on github. > > >> > 1.2 > > >> > I registered an account at github. > > >> > 1.3 > > >> > I commit then create pr. > > >> > 1.4 > > >> > pr get reviewed then merged. > > >> > > >> I am fully aware of how github works, I use PRs myself. > > >> > > >> The perceived ease[1] of doing this comes at a price and I'm mourning > > >> the loss of community building. > > >> > > >> Stefan > > >> > > >> [1] with gitbox you are certainly able to contribute > > >> > > >> git clone > > >> git checkout -b my-work > > >> ... > > >> git format-patch > > >> attach patch to JIRA > > >> > > >> but you know that. > > >> > > >> - > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >> For additional commands, e-mail: dev-h...@commons.apache.org > > >> > > >> > > > -- > Matt Sicker >
Re: [all] When to update dependencies?
> On Jul 25, 2020, at 5:28 PM, Matt Sicker wrote: > > Exactly. It’s not a general problem, but one specific to various legacy > APIs still commonly used. +1 > >> On Sat, Jul 25, 2020 at 14:56 Bernd Eckenfels >> wrote: >> >> It will only cause problems if this is registered as a service/spi/driver >> like XML, Crypto, JDBC, Authentication and so on. For internal libraries >> functions which don't have such global state it's fine. >> >> Gruss >> Bernd >> >> >> -- >> http://bernd.eckenfels.net >> >> Von: Torsten Curdt >> Gesendet: Saturday, July 25, 2020 8:29:21 PM >> An: Commons Developers List >> Betreff: Re: [all] When to update dependencies? >> >>> >>> They’re not the same class and that’s the problem. It’s similar to >> loading >>> two versions of the same library in OSGi >> >> >> Let's say you are dealing with >> >> org.vafer.Foo >> >> the library relocates this as >> >> org.apache.commons.compress.internal.org.vafer.Foo >> >> The library only deals with >> >> org.apache.commons.compress.internal.org.vafer.Foo >> >> They cannot get mixed up. >> Please explain how this will cause problems. >> > -- > Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Lang][All] Drop pseudo-random number utilities?
Hi.
2020-07-25 21:03 UTC+02:00, Alex Herbert :
>
>
>> On 25 Jul 2020, at 19:25, Gilles Sadowski wrote:
>>
>> Hello.
>>
>> In the thread[1] from which the below quote is extracted:
>>> Would you be willing to provide a PR that deprecates the relevant APIs
>>> and
>>> points to their equivalent in RNG? It will be more cruft we can trim for
>>> 4.0, whenever that happens.
>> Gary mentions that copy/paste is a "coding horror". My understanding
>> is that he advises dropping functionality available from "Commons RNG"
>> (or a trivial use of it).
>> Case in point is a bug recently reported.[2]
>
> I am the the one who implemented the copy and paste to fix that bug.
A bug-fix was needed, and, up to yesterday, the *only* way
to fix it was copy/paste.
IIUC Gary's request, the next major version of [Lang] could
stop providing utilities which exist in other components, in
order to reduce "coding horrors".
> Note
> that the alternatives would be:
>
> - to bring in a dependency on RNG
+1
[But I doubt this will be accepted.]
> - to change to using ThreadLocalRandom for the same functionality
>
> I considered it the minimal change to port the algorithm and remain
> dependency free.
As noted above, the problem is not the fix, but the fact that
with bloat increases the bug count.
> However the code can still be fixed with one of the
> alternatives.
The proposed alternative in to drop RandomUtils altogether
in the next major release of [Lang]; and refer users to [RNG].
Do you see any problem?
> My suggestion for RandomUtils would be to remove the use of java.lang.Random
> and use ThreadLocalRandom. This class would support all of the method in
> RandomUtils except:
>
> public static float nextFloat(final float startInclusive, final float
> endExclusive)
>
> The method that had a bug in LANG-1592 is actually provided by the JDK if
> you use ThreadLocalRandom. A switch to this generator could accompany the
> RandomUtils class being marked as deprecated and stated as delegating to
> ThreadLocalRandom. The RandomUtils then becomes a pass through to
> ThreadLocalRandom, for example:
>
> public static double nextDouble(final double startInclusive, final double
> endExclusive) {
> return ThreadLocalRandom.current().nextDouble(startInclusive,
> endExclusive);
> }
Wrapping a one-liner == code bloat.
>>
>> The change amounts to removing "RandomUtils"[3] and moving all
>> functionality from "RandomStringUtils"[4] (and removing it too) over
>> to "Commons Text" that already defines several similar (perhaps all?)
>> utilities[5] using a more robust approach.
>
> A brief look at RandomStringUtils shows it uses:
>
> o.a.c.lang3.RandomUtils:
> public static int nextInt(final int startInclusive, final int endExclusive)
>
> java.util.Random:
> public int nextInt(int bound)
>
> So would be easy to support after removal of RandomUtils.
>
> The [text] RandomStringGenerator provides the same functionality as
> RandomStringUtils (sampling from a character range). There is a speed
> difference (see partially related RNG-54 [1]). The method in Text is slower
> than that in Lang. But I only looked at generating Hex characters in
> RNG-54.
The final comment was already proposing what we (re)discuss
in this thread, i.e. put algorithms that deal with String/char in
[Text].
I'd be surprised that the RNG part of the algorithm would be
responsible for the performance loss in [Text] vs [Lang].
Any problem fixing [Text] in that respect?
> For ease of maintenance dropping RandomStringUtils in favour of the method
> in [text] seems a good approach. Note that lang has methods for specific
> character sets. This could be added as a feature to the
> RandomStringGenerator.Builder in text so switching from one to the other is
> an easier refactoring task.
Sure.
Regards,
Gilles
>
> Alex
>
> [1]
> https://issues.apache.org/jira/browse/RNG-54?focusedCommentId=16582795&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16582795
>
>
>>
>> Is everyone on the same page?
>>
>> Regards,
>> Gilles
>>
>> [1] https://markmail.org/message/s2o3c57537id37jt
>> [2] https://issues.apache.org/jira/browse/LANG-1592
>> [3]
>> https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=blob;f=src/main/java/org/apache/commons/lang3/RandomUtils.java;h=b1c7f0fb147c586a57cd498734bfb5bc92f19f37;hb=HEAD
>> [4]
>> https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=blob;f=src/main/java/org/apache/commons/lang3/RandomStringUtils.java;h=0d6df4eed0d91bbd32ad378c28400fdf049ee542;hb=HEAD
>> [5]
>> https://gitbox.apache.org/repos/asf?p=commons-text.git;a=blob;f=src/main/java/org/apache/commons/text/RandomStringGenerator.java;h=d8e38e4614dba548ef764225b87626f3a4cda434;hb=HEAD
-
To unsubscribe, e-mail: dev-unsubscr...@com
Re: [all] When to update dependencies?
Exactly. It’s not a general problem, but one specific to various legacy APIs still commonly used. On Sat, Jul 25, 2020 at 14:56 Bernd Eckenfels wrote: > It will only cause problems if this is registered as a service/spi/driver > like XML, Crypto, JDBC, Authentication and so on. For internal libraries > functions which don't have such global state it's fine. > > Gruss > Bernd > > > -- > http://bernd.eckenfels.net > > Von: Torsten Curdt > Gesendet: Saturday, July 25, 2020 8:29:21 PM > An: Commons Developers List > Betreff: Re: [all] When to update dependencies? > > > > > They’re not the same class and that’s the problem. It’s similar to > loading > > two versions of the same library in OSGi > > > Let's say you are dealing with > > org.vafer.Foo > > the library relocates this as > > org.apache.commons.compress.internal.org.vafer.Foo > > The library only deals with > > org.apache.commons.compress.internal.org.vafer.Foo > > They cannot get mixed up. > Please explain how this will cause problems. > -- Matt Sicker
Re: [all] When to update dependencies?
When you copy/shade classes then there is no sealing metadata copied, so unless the code verifies how it is packaged, it will not know that it isn't sealed anymore (or to a different package). But I guess it doesn't matter, there are many libraries which can be shaded and many which can't, for various reasons. That does not mean it's generally not possible to reduce some dependencies. Gruss -- http://bernd.eckenfels.net Von: Gary Gregory Gesendet: Saturday, July 25, 2020 10:22:58 PM An: Commons Developers List Betreff: Re: [all] When to update dependencies? How does this work with sealed jars? Gary On Sat, Jul 25, 2020, 15:57 Bernd Eckenfels wrote: > It will only cause problems if this is registered as a service/spi/driver > like XML, Crypto, JDBC, Authentication and so on. For internal libraries > functions which don't have such global state it's fine. > > Gruss > Bernd > > > -- > http://bernd.eckenfels.net > > Von: Torsten Curdt > Gesendet: Saturday, July 25, 2020 8:29:21 PM > An: Commons Developers List > Betreff: Re: [all] When to update dependencies? > > > > > They’re not the same class and that’s the problem. It’s similar to > loading > > two versions of the same library in OSGi > > > Let's say you are dealing with > > org.vafer.Foo > > the library relocates this as > > org.apache.commons.compress.internal.org.vafer.Foo > > The library only deals with > > org.apache.commons.compress.internal.org.vafer.Foo > > They cannot get mixed up. > Please explain how this will cause problems. >
Re: [all] When to update dependencies?
How does this work with sealed jars? Gary On Sat, Jul 25, 2020, 15:57 Bernd Eckenfels wrote: > It will only cause problems if this is registered as a service/spi/driver > like XML, Crypto, JDBC, Authentication and so on. For internal libraries > functions which don't have such global state it's fine. > > Gruss > Bernd > > > -- > http://bernd.eckenfels.net > > Von: Torsten Curdt > Gesendet: Saturday, July 25, 2020 8:29:21 PM > An: Commons Developers List > Betreff: Re: [all] When to update dependencies? > > > > > They’re not the same class and that’s the problem. It’s similar to > loading > > two versions of the same library in OSGi > > > Let's say you are dealing with > > org.vafer.Foo > > the library relocates this as > > org.apache.commons.compress.internal.org.vafer.Foo > > The library only deals with > > org.apache.commons.compress.internal.org.vafer.Foo > > They cannot get mixed up. > Please explain how this will cause problems. >
Re: [all] When to update dependencies?
It will only cause problems if this is registered as a service/spi/driver like XML, Crypto, JDBC, Authentication and so on. For internal libraries functions which don't have such global state it's fine. Gruss Bernd -- http://bernd.eckenfels.net Von: Torsten Curdt Gesendet: Saturday, July 25, 2020 8:29:21 PM An: Commons Developers List Betreff: Re: [all] When to update dependencies? > > They’re not the same class and that’s the problem. It’s similar to loading > two versions of the same library in OSGi Let's say you are dealing with org.vafer.Foo the library relocates this as org.apache.commons.compress.internal.org.vafer.Foo The library only deals with org.apache.commons.compress.internal.org.vafer.Foo They cannot get mixed up. Please explain how this will cause problems.
Re: [Lang][All] Drop pseudo-random number utilities?
> On 25 Jul 2020, at 19:25, Gilles Sadowski wrote:
>
> Hello.
>
> In the thread[1] from which the below quote is extracted:
>> Would you be willing to provide a PR that deprecates the relevant APIs and
>> points to their equivalent in RNG? It will be more cruft we can trim for
>> 4.0, whenever that happens.
> Gary mentions that copy/paste is a "coding horror". My understanding
> is that he advises dropping functionality available from "Commons RNG"
> (or a trivial use of it).
> Case in point is a bug recently reported.[2]
I am the the one who implemented the copy and paste to fix that bug. Note that
the alternatives would be:
- to bring in a dependency on RNG
- to change to using ThreadLocalRandom for the same functionality
I considered it the minimal change to port the algorithm and remain dependency
free. However the code can still be fixed with one of the alternatives.
My suggestion for RandomUtils would be to remove the use of java.lang.Random
and use ThreadLocalRandom. This class would support all of the method in
RandomUtils except:
public static float nextFloat(final float startInclusive, final float
endExclusive)
The method that had a bug in LANG-1592 is actually provided by the JDK if you
use ThreadLocalRandom. A switch to this generator could accompany the
RandomUtils class being marked as deprecated and stated as delegating to
ThreadLocalRandom. The RandomUtils then becomes a pass through to
ThreadLocalRandom, for example:
public static double nextDouble(final double startInclusive, final double
endExclusive) {
return ThreadLocalRandom.current().nextDouble(startInclusive, endExclusive);
}
>
> The change amounts to removing "RandomUtils"[3] and moving all
> functionality from "RandomStringUtils"[4] (and removing it too) over
> to "Commons Text" that already defines several similar (perhaps all?)
> utilities[5] using a more robust approach.
A brief look at RandomStringUtils shows it uses:
o.a.c.lang3.RandomUtils:
public static int nextInt(final int startInclusive, final int endExclusive)
java.util.Random:
public int nextInt(int bound)
So would be easy to support after removal of RandomUtils.
The [text] RandomStringGenerator provides the same functionality as
RandomStringUtils (sampling from a character range). There is a speed
difference (see partially related RNG-54 [1]). The method in Text is slower
than that in Lang. But I only looked at generating Hex characters in RNG-54.
For ease of maintenance dropping RandomStringUtils in favour of the method in
[text] seems a good approach. Note that lang has methods for specific character
sets. This could be added as a feature to the RandomStringGenerator.Builder in
text so switching from one to the other is an easier refactoring task.
Alex
[1]
https://issues.apache.org/jira/browse/RNG-54?focusedCommentId=16582795&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16582795
>
> Is everyone on the same page?
>
> Regards,
> Gilles
>
> [1] https://markmail.org/message/s2o3c57537id37jt
> [2] https://issues.apache.org/jira/browse/LANG-1592
> [3]
> https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=blob;f=src/main/java/org/apache/commons/lang3/RandomUtils.java;h=b1c7f0fb147c586a57cd498734bfb5bc92f19f37;hb=HEAD
> [4]
> https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=blob;f=src/main/java/org/apache/commons/lang3/RandomStringUtils.java;h=0d6df4eed0d91bbd32ad378c28400fdf049ee542;hb=HEAD
> [5]
> https://gitbox.apache.org/repos/asf?p=commons-text.git;a=blob;f=src/main/java/org/apache/commons/text/RandomStringGenerator.java;h=d8e38e4614dba548ef764225b87626f3a4cda434;hb=HEAD
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
Re: [all] When to update dependencies?
> > They’re not the same class and that’s the problem. It’s similar to loading > two versions of the same library in OSGi Let's say you are dealing with org.vafer.Foo the library relocates this as org.apache.commons.compress.internal.org.vafer.Foo The library only deals with org.apache.commons.compress.internal.org.vafer.Foo They cannot get mixed up. Please explain how this will cause problems.
[Lang][All] Drop pseudo-random number utilities?
Hello. In the thread[1] from which the below quote is extracted: > Would you be willing to provide a PR that deprecates the relevant APIs and > points to their equivalent in RNG? It will be more cruft we can trim for > 4.0, whenever that happens. Gary mentions that copy/paste is a "coding horror". My understanding is that he advises dropping functionality available from "Commons RNG" (or a trivial use of it). Case in point is a bug recently reported.[2] The change amounts to removing "RandomUtils"[3] and moving all functionality from "RandomStringUtils"[4] (and removing it too) over to "Commons Text" that already defines several similar (perhaps all?) utilities[5] using a more robust approach. Is everyone on the same page? Regards, Gilles [1] https://markmail.org/message/s2o3c57537id37jt [2] https://issues.apache.org/jira/browse/LANG-1592 [3] https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=blob;f=src/main/java/org/apache/commons/lang3/RandomUtils.java;h=b1c7f0fb147c586a57cd498734bfb5bc92f19f37;hb=HEAD [4] https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=blob;f=src/main/java/org/apache/commons/lang3/RandomStringUtils.java;h=0d6df4eed0d91bbd32ad378c28400fdf049ee542;hb=HEAD [5] https://gitbox.apache.org/repos/asf?p=commons-text.git;a=blob;f=src/main/java/org/apache/commons/text/RandomStringGenerator.java;h=d8e38e4614dba548ef764225b87626f3a4cda434;hb=HEAD - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] github (was Re: [VOTE] Create additional mailing lists for automated posts)
GitHub is basically our interactive pull request interface. If we didn’t have that, I bet we’d be running GitLab ourselves or similar. Also, being that the bar to be a committer here is fairly low, getting access to gitbox directly isn’t too difficult. On Fri, Jul 24, 2020 at 12:17 Xeno Amess wrote: > besides, that is JIRA where we can apply patch, but I think it SHOULD be > done on gutbox. github, gitlab, all of them have a convienent pr system. > so yes our JIRA is good, I like JIRA. > But for gitbox, I think it really lack lots of things. > Or, there be those things, but not open. > > Xeno Amess 于 2020年7月25日周六 上午1:11写道： > > > you know that is really complex and time costing... > > especially when we want some trigger invoked like travis-ci. > > > > Stefan Bodewig 于 2020年7月25日周六 上午1:06写道： > > > >> On 2020-07-24, Xeno Amess wrote: > >> > >> > I will explain why github come to be center, but not apache gitbox. > >> > 1.1 > >> > I have right to register an account on github. > >> > 1.2 > >> > I registered an account at github. > >> > 1.3 > >> > I commit then create pr. > >> > 1.4 > >> > pr get reviewed then merged. > >> > >> I am fully aware of how github works, I use PRs myself. > >> > >> The perceived ease[1] of doing this comes at a price and I'm mourning > >> the loss of community building. > >> > >> Stefan > >> > >> [1] with gitbox you are certainly able to contribute > >> > >> git clone > >> git checkout -b my-work > >> ... > >> git format-patch > >> attach patch to JIRA > >> > >> but you know that. > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > -- Matt Sicker
Re: [all] When to update dependencies?
They’re not the same class and that’s the problem. It’s similar to loading two versions of the same library in OSGi and allowing the two classes to get mixed up somehow (fun errors like Foo is not type Foo), typically a bug. On Fri, Jul 24, 2020 at 11:30 Gilles Sadowski wrote: > Le ven. 24 juil. 2020 à 17:46, Matt Sicker a écrit : > > > > Shading also violates a lot of common ClassLoader assumptions like not > > having multiple copies of the same class in the same visible context > (even > > if different packages) > > How classes in different packages could be the same class? > > Gilles > > > [...] > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [all] github (was Re: [VOTE] Create additional mailing lists for automated posts)
Hello. Le ven. 24 juil. 2020 à 17:45, Stefan Bodewig a écrit : > > This is an attempt at answering something raised be Gilles in a > different thread. I'm afraid it is getting longer than I > intended. Something seems to need to get out. Sorry. > > On 2020-07-23, Gilles Sadowski wrote: > > > I missed the turn where this project's PMC decided that we must > > be present on GH in order to continue what some of us have been > > doing for more than 10 years. > > The project decided to set up github mirrors and with the exposure to > github you get the rest of the package. Depends on what "get" means. The mirror functionality does not necessarily entail the "rest". For just one example, see [1]. Thus, to mimic Xeno's wording (up to a point): 0. Post a proposal to "dev@". 1. Create a JIRA issue. 2. Create GH PR that will be linked from JIRA. 3. Ask for comment in JIRA. 4. Get review, as JIRA comments (until convergence/compliance). 5. ["none of contributor's business"] Merge. > I don't remember whether we had an explicit vote about enabling github > mirrors, much less whether it has been a component by component > decision. If I'm not mistaken, mirrors come by default with any new git repository. A mirror gives more exposure to the project, which is indeed good, as you say below. > Putting aside what I think about github as a company Why? One should learn from history that this company is accustomed to "gifts" whose cost can (will) appear much later on. > one thing that I > have observed with projects migrating to github across the board is it > seems to lower the barrier for new contributors. And this is good, as said above, but up to a point as you indeed note: > This results in two > things: (1) you get more contributions and (2) the contributors usually > don't stick around, most contributions are drive-by one-off > contributions. > > Gilles, I believe you have seen an uptick in contributions to the > sevaral maths components even if you don't like they way they have > happened. The following might sound dismissive but it is not: We appreciate anyone interested in helping out. However the point is indeed "helping out": If it takes much more time to review/correct/merge a contribution than make it myself, this is not helping out, quite the contrary. Of course, there is a learning curve for a new contributor; I have, every time, spelled out in (fairly) full what was expected but (my impression is the same as yours) for a one-off contribution, it is out of proportion. > > There is a trend to make GH central to the development process > > (marginalizing "dev@" and JIRA and colonizing "issues@"). > > This is troubling me as well. Where "this" is that using github PRs > seems to keep the potential future committers away from the dev list and > they never become part of a component's community. IMO, GitHub's motto could be "Code over community". It's not necessarily bad, but GitHub is understandably (and obviously primarily) interested in *its* community. > We do get more contributions anf the quality of the codebases likely > improves because of this, but I feel it makes the community weaker. There is experimental data that there's no causality link between using GitHub as a mirror and this community's way(s) of working for at least 10 years: * Matt has undertaken the overhaul of [Geometry] codes, without having write access to the Apache repository (cf. [1] for just one example), * ditto, earlier, with the polishing, up to the last percent of coverage, (and more!) of [RNG] by Alex. > Discussions only rarely happen "here" nowadays. Whereas, in the not-so-distant past, this was severely frowned upon. Whether using GitHub almost exclusively (bypassing the "dev" ML and JIRA) is progress or not, it was not approved, but this PMC let it happen. > There are a few people like Gary, Rob and a few others who manage to > devote time across almost all components and I adore them for that. And > we need them because most of the components wouldn't stand a chance to > get a release vote through without them. Those who do the work get to decide. No arguing against that. Being more productive (by necessity) with GitHub, increases the bias, which you noted, of attracting more and more contributors who attempt to get their code merged by, so to speak, "trial and error" (as opposed to "internalize" requirements). > Our component communities have > become too small to sustain themselves and at the same time some of them > see more commits than they used to have in "the good old days" with many > people active on this list. Xeno has a point in saying that this problem did not appear with GitHub. I've raised it myself several times over the years, but the readers here have always remained unfazed. > I haven't got an answer to this. Neither have I, at least not an effective one. Last year, I proposed that we participate in GSoC. By "we", I thought I was meaning "Commons", but only the math-related c
Re: [ANNOUCEMENT] Apache Commons Text 1.9
Applause -Rob > On Jul 25, 2020, at 10:59 AM, Gary Gregory wrote: > > The Apache Commons Team announces the release of Apache Commons Text 1.9. > > This document contains the release notes for the 1.9 version of Apache > Commons Text. > Commons Text is a set of utility functions and reusable components for the > purpose of processing > and manipulating text that should be of use in a Java environment. > > Apache Commons Text is a library focused on algorithms working on strings. > > Release 1.9. Requires Java 8. > > Changes in this version include: > > New features: > o Add StringMatcher.size(). Thanks to Gary Gregory. > o Refactor TextStringBuilder.readFrom(Readable), extracting > readFrom(CharBuffer) and readFrom(Reader). Thanks to Gary Gregory. > o Add BiStringLookup and implementation BiFunctionStringLookup. Thanks to > Gary Gregory. > o Add > org.apache.commons.text.StringSubstitutor.StringSubstitutor(StringSubstitutor). > Thanks to Gary Gregory. > o Add > org.apache.commons.text.TextStringBuilder.TextStringBuilder(CharSequence). > Thanks to Gary Gregory. > o Add org.apache.commons.text.TextStringBuilder.drainChar(int). Thanks to > Gary Gregory. > o Add org.apache.commons.text.TextStringBuilder.drainChars(int, int, > char[]. int). Thanks to Gary Gregory. > o Add org.apache.commons.text.TextStringBuilder.isNotEmpty(). Thanks to > Gary Gregory. > o Add org.apache.commons.text.TextStringBuilder.isReallocated(). Thanks to > Gary Gregory. > o Add org.apache.commons.text.TextStringBuilder.readFrom(Reader, int). > Thanks to Gary Gregory. > o Add org.apache.commons.text.TextStringBuilder.set(String). Thanks to Gary > Gregory. > o Add org.apache.commons.text.TextStringBuilder.wrap(char[]). Thanks to > Gary Gregory. > o Add org.apache.commons.text.TextStringBuilder.wrap(char[], int). Thanks > to Gary Gregory. > o Add org.apache.commons.text.io.StringSubstitutorReader. Thanks to Gary > Gregory. > o Add > org.apache.commons.text.lookup.StringLookupFactory.functionStringLookup(Function V>). Thanks to Gary Gregory. > o Add org.apache.commons.text.matcher.StringMatcher.isMatch(CharSequence, > int). Thanks to Gary Gregory. > o Add org.apache.commons.text.matcher.StringMatcher.isMatch(CharSequence, > int, int, int). Thanks to Gary Gregory. > o Add > org.apache.commons.text.matcher.StringMatcherFactory.andMatcher(StringMatcher...). > Thanks to Gary Gregory. > o Add > org.apache.commons.text.matcher.StringMatcherFactory.stringMatcher(char...). > Thanks to Gary Gregory. > > Fixed Bugs: > o TEXT-166: Removed non-existing parameter from Javadocs and spelled out > parameters in throws. Thanks to Mikko Maunu. > o TEXT-149: StringEscapeUtils.unescapeCsv doesn't remove quotes at begin > and end of string. Thanks to Yuji Konishi. > o TEXT-174: ScriptStringLookup does not accept ":" #126. Thanks to > furkilic. > o TEXT-178: StringSubstitutor incorrectly removes some escape characters. > Thanks to Gary Gregory. > o TEXT-181: Fix Javadocs #135. Thanks to XenoAmess. > o TEXT-182: Fix typos #137. Thanks to XenoAmess. > o TEXT-183: Make ConstantStringLookup.constantCache final #136. Thanks to > XenoAmess. > o TEXT-184: Simplify if in CaseUtils #134. Thanks to XenoAmess. > > Changes: > o [javadoc] Fix compiler warnings in Java code example in Javadoc #124. > Thanks to Johan Hammar. > o TEXT-177: Update from Apache Commons Lang 3.9 to 3.11. Thanks to Gary > Gregory. > o [build] Skip clirr since we use JApiCmp. Thanks to Gary Gregory. > o [test] junit-jupiter 5.5.1 -> 5.5.2. Thanks to Gary Gregory. > o [test] org.assertj:assertj-core 3.13.2 -> 3.16.1. Thanks to Gary Gregory. > o [build] com.puppycrawl.tools:checkstyle 8.23 -> 8.34. Thanks to Gary > Gregory. > o [build] Update JUnit from 5.5.2 to 5.6.2. Thanks to Gary Gregory. > o [build] commons.jacoco.version 0.8.4 -> 0.8.5. Thanks to Gary Gregory. > o [build] commons.javadoc.version 3.1.1 -> 3.2.0. Thanks to Gary Gregory. > o [build] commons.japicmp.version 0.14.1 -> 0.14.3. Thanks to Gary Gregory. > o [build] checkstyle.plugin.version 3.1.0 -> 3.1.1. Thanks to Gary Gregory. > o [build] checkstyle.version 8.27 -> 8.33. Thanks to Gary Gregory. > o [build] org.apache.commons:commons-parent 48 -> 51. Thanks to Gary > Gregory. > o [build] maven-pmd-plugin 3.12.0 -> 3.13.0. Thanks to Gary Gregory. > o [build] org.mockito 3.3.3 -> 3.4.4. Thanks to Gary Gregory. > > > Historical list of changes: > https://commons.apache.org/proper/commons-text/changes-report.html > > For complete information on Apache Commons Text, including instructions on > how to submit bug reports, > patches, or suggestions for improvement, see the Apache Apache Commons Text > website: > > https://commons.apache.org/proper/commons-text > > Download page: > https://commons.apache.org/proper/commons-text/download_text.cgi > > Have fun! > -Gary Gregory for the Apache Commons Team - To unsubscribe, e-mail: dev-unsubscr...@commons.
[ANNOUCEMENT] Apache Commons Text 1.9
The Apache Commons Team announces the release of Apache Commons Text 1.9. This document contains the release notes for the 1.9 version of Apache Commons Text. Commons Text is a set of utility functions and reusable components for the purpose of processing and manipulating text that should be of use in a Java environment. Apache Commons Text is a library focused on algorithms working on strings. Release 1.9. Requires Java 8. Changes in this version include: New features: o Add StringMatcher.size(). Thanks to Gary Gregory. o Refactor TextStringBuilder.readFrom(Readable), extracting readFrom(CharBuffer) and readFrom(Reader). Thanks to Gary Gregory. o Add BiStringLookup and implementation BiFunctionStringLookup. Thanks to Gary Gregory. o Add org.apache.commons.text.StringSubstitutor.StringSubstitutor(StringSubstitutor). Thanks to Gary Gregory. o Add org.apache.commons.text.TextStringBuilder.TextStringBuilder(CharSequence). Thanks to Gary Gregory. o Add org.apache.commons.text.TextStringBuilder.drainChar(int). Thanks to Gary Gregory. o Add org.apache.commons.text.TextStringBuilder.drainChars(int, int, char[]. int). Thanks to Gary Gregory. o Add org.apache.commons.text.TextStringBuilder.isNotEmpty(). Thanks to Gary Gregory. o Add org.apache.commons.text.TextStringBuilder.isReallocated(). Thanks to Gary Gregory. o Add org.apache.commons.text.TextStringBuilder.readFrom(Reader, int). Thanks to Gary Gregory. o Add org.apache.commons.text.TextStringBuilder.set(String). Thanks to Gary Gregory. o Add org.apache.commons.text.TextStringBuilder.wrap(char[]). Thanks to Gary Gregory. o Add org.apache.commons.text.TextStringBuilder.wrap(char[], int). Thanks to Gary Gregory. o Add org.apache.commons.text.io.StringSubstitutorReader. Thanks to Gary Gregory. o Add org.apache.commons.text.lookup.StringLookupFactory.functionStringLookup(Function). Thanks to Gary Gregory. o Add org.apache.commons.text.matcher.StringMatcher.isMatch(CharSequence, int). Thanks to Gary Gregory. o Add org.apache.commons.text.matcher.StringMatcher.isMatch(CharSequence, int, int, int). Thanks to Gary Gregory. o Add org.apache.commons.text.matcher.StringMatcherFactory.andMatcher(StringMatcher...). Thanks to Gary Gregory. o Add org.apache.commons.text.matcher.StringMatcherFactory.stringMatcher(char...). Thanks to Gary Gregory. Fixed Bugs: o TEXT-166: Removed non-existing parameter from Javadocs and spelled out parameters in throws. Thanks to Mikko Maunu. o TEXT-149: StringEscapeUtils.unescapeCsv doesn't remove quotes at begin and end of string. Thanks to Yuji Konishi. o TEXT-174: ScriptStringLookup does not accept ":" #126. Thanks to furkilic. o TEXT-178: StringSubstitutor incorrectly removes some escape characters. Thanks to Gary Gregory. o TEXT-181: Fix Javadocs #135. Thanks to XenoAmess. o TEXT-182: Fix typos #137. Thanks to XenoAmess. o TEXT-183: Make ConstantStringLookup.constantCache final #136. Thanks to XenoAmess. o TEXT-184: Simplify if in CaseUtils #134. Thanks to XenoAmess. Changes: o [javadoc] Fix compiler warnings in Java code example in Javadoc #124. Thanks to Johan Hammar. o TEXT-177: Update from Apache Commons Lang 3.9 to 3.11. Thanks to Gary Gregory. o [build] Skip clirr since we use JApiCmp. Thanks to Gary Gregory. o [test] junit-jupiter 5.5.1 -> 5.5.2. Thanks to Gary Gregory. o [test] org.assertj:assertj-core 3.13.2 -> 3.16.1. Thanks to Gary Gregory. o [build] com.puppycrawl.tools:checkstyle 8.23 -> 8.34. Thanks to Gary Gregory. o [build] Update JUnit from 5.5.2 to 5.6.2. Thanks to Gary Gregory. o [build] commons.jacoco.version 0.8.4 -> 0.8.5. Thanks to Gary Gregory. o [build] commons.javadoc.version 3.1.1 -> 3.2.0. Thanks to Gary Gregory. o [build] commons.japicmp.version 0.14.1 -> 0.14.3. Thanks to Gary Gregory. o [build] checkstyle.plugin.version 3.1.0 -> 3.1.1. Thanks to Gary Gregory. o [build] checkstyle.version 8.27 -> 8.33. Thanks to Gary Gregory. o [build] org.apache.commons:commons-parent 48 -> 51. Thanks to Gary Gregory. o [build] maven-pmd-plugin 3.12.0 -> 3.13.0. Thanks to Gary Gregory. o [build] org.mockito 3.3.3 -> 3.4.4. Thanks to Gary Gregory. Historical list of changes: https://commons.apache.org/proper/commons-text/changes-report.html For complete information on Apache Commons Text, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Apache Commons Text website: https://commons.apache.org/proper/commons-text Download page: https://commons.apache.org/proper/commons-text/download_text.cgi Have fun! -Gary Gregory for the Apache Commons Team
Re: [crypto] New Release
On Fri, Jul 24, 2020 at 8:04 PM Alex Remily wrote: > I'd recommend using MinGW. I installed it through brew on my Mac and cross > compiled the windows build with little difficulty. I expect a similar > experience on Linux. The MinGW install contains all the necessary windows > headers. > Yep, that's what I use: MSYS_NT-10.0-16299 *** 3.1.6-340.x86_64 2020-07-17 05:52 UTC x86_64 Msys Gary > > On Fri, Jul 24, 2020, 7:16 PM Gary Gregory wrote: > > > Thanks Geoffrey, > > > > Are you available at some point to do a webex to straighten out my local > > set up? Just email me directly so we can coordinate. > > > > Gary > > > > On Fri, Jul 24, 2020 at 4:34 PM Geoffrey Blake < > geoffrey.w.bl...@gmail.com > > > > > wrote: > > > > > Hi Gary, > > > > > > windows.h/Windows.h/WINDOWS.H are all names for the same file, on > > > Windows I've found out, the FS is case-insensitive. This is not true > > > on a Linux box though. I submitted a new PR to fix this and get > > > Windows builds working again on a Linux box, as well as testing that > > > windows artifacts will still build via Travis. Hopefully this can > > > unstick the release as you can now cross-compile everything save the > > > OSX shared-lib on one box by pointing Maven to the proper targets. > > > > > > -Geoff > > > > > > On Sat, Jul 18, 2020 at 11:25 AM Gary Gregory > > > wrote: > > > > > > > > On Thu, Jul 2, 2020 at 12:39 PM Geoffrey Blake < > > > geoffrey.w.bl...@gmail.com> > > > > wrote: > > > > > > > > > I took a bit of time to set up an x86 Ubuntu 14.04 VM via > virtualbox > > > > > and vagrant, but it looks like the windows build is broken. There > > are > > > > > typos trying to include "Windows.h" which should be "windows.h" to > > > > > > > > > > > > > Are you sure that this include is not referring the to Microsoft > > header, > > > > for example, on my machine: > > > > > > > > C:\Program Files (x86)\Windows > > Kits\10\Include\10.0.17763.0\um\Windows.h > > > > > > > > ? > > > > > > > > Gary > > > > > > > > > compile with mingw and redefined macros that I think are mixing > > > > > between Linux and windows headers. I won't be able to get to > trying > > > > > to fix and submit any PRs on these this week or next. But anyone > who > > > > > wants to try cross-compiling, here are the packages I installed to > > get > > > > > up and running minimally on Ubuntu: > > > > > > > > > > sudo apt-get install build-essential g++-mingw-w64 > > > > > gcc-aarch64-linux-gnu libc6-dev-i386 > > > > > sudo apt-get install libssl-dev git > > > > > sudo add-apt-repository ppa:openjdk-r/ppa > > > > > sudo apt-get install openjdk-8-jdk > > > > > > > > > > Don't install the Ubuntu supplied maven, its too old. Just grab > the > > > > > 3.6 tarball from apache. > > > > > > > > > > -Geoff > > > > > > > > > > On Tue, Jun 30, 2020 at 8:24 PM Alex Remily > > > > wrote: > > > > > > > > > > > > I'll see if I have any time this weekend, but this part is > largely > > > > > > unfamiliar to me, so not sure how far I'll get even if I have the > > > time > > > > > > to look at it. > > > > > > > > > > > > On Tue, Jun 30, 2020 at 4:59 PM Geoffrey Blake > > > > > > wrote: > > > > > > > > > > > > > > I think you're right Alex. I just happened to look at the > > Makefile > > > > > > > and saw this above the win64 target: > > > > > > > > > > > > > > # for cross-compilation on Ubuntu, install the > > g++-mingw-w64-x86-64 > > > > > package > > > > > > > > > > > > > > We could potentially build everything but MacOS on 1 Ubuntu > > > 16.04LTS > > > > > > > box. Or even a 14.04 box if necessary. Anybody have the time > to > > > try? > > > > > > > > > > > > > > On Thu, Jun 25, 2020 at 4:12 PM Alex Remily < > > alex.rem...@gmail.com > > > > > > > > > wrote: > > > > > > > > > > > > > > > > Not sure if it's relevant or not, but to get the build to > > > compile on > > > > > > > > Windows with MinGW, I commented out line 137 of > > > > > > > > > > > > > > > > > > > https://github.com/apache/commons-crypto/blob/master/src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h > > > > > : > > > > > > > > > > > > > > > > //#define inline __inline; > > > > > > > > > > > > > > > > I never did learn why it was there in the first place, but > the > > > broken > > > > > > > > build was originally reported as > > > > > > > > > > > > > > > > https://issues.apache.org/jira/browse/CRYPTO-137. > > > > > > > > > > > > > > > > Now I'm wondering if it may have had something to do with > > > > > > > > cross-compiling for the build. > > > > > > > > > > > > > > > > On Thu, Jun 25, 2020 at 1:13 PM Geoffrey Blake > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Is there anything needed to help move this release along? > > > From the > > > > > > > > > looks of the Makefile, Windows was using GCC. I don't > think > > > the > > > > > > > > > compiler is going to have much of an impact since the JNI > > > bindings > > > > > are > > > > > > > > > simply calling through to
Re: [crypto] New Release
There is a docker Maven plugin: io.fabric8 docker-maven-plugin 0.33.0 Gary On Sat, Jul 25, 2020, 00:20 Geoffrey Blake wrote: > Docker would be great. Next question, can that be integrated into > Maven for automating these releases that someone knows offhand? > > -Geoff > > On Fri, Jul 24, 2020 at 7:50 PM Alex Remily wrote: > > > > Sounds like a great idea. > > > > On Fri, Jul 24, 2020, 8:29 PM Marcelo Vanzin wrote: > > > > > Is it possible to cross-compile from Linux to MacOS? > > > > > > Even if it isn't, might be a good idea to write a docker image to do > > > the other cross-builds; then from a Mac you can build the MacOS binary > > > and call docker to build all the others. > > > > > > On Fri, Jul 24, 2020 at 5:04 PM Alex Remily > wrote: > > > > > > > > I'd recommend using MinGW. I installed it through brew on my Mac and > > > cross > > > > compiled the windows build with little difficulty. I expect a > similar > > > > experience on Linux. The MinGW install contains all the necessary > > > windows > > > > headers. > > > > > > > > On Fri, Jul 24, 2020, 7:16 PM Gary Gregory > > > wrote: > > > > > > > > > Thanks Geoffrey, > > > > > > > > > > Are you available at some point to do a webex to straighten out my > > > local > > > > > set up? Just email me directly so we can coordinate. > > > > > > > > > > Gary > > > > > > > > > > On Fri, Jul 24, 2020 at 4:34 PM Geoffrey Blake < > > > geoffrey.w.bl...@gmail.com > > > > > > > > > > > wrote: > > > > > > > > > > > Hi Gary, > > > > > > > > > > > > windows.h/Windows.h/WINDOWS.H are all names for the same file, on > > > > > > Windows I've found out, the FS is case-insensitive. This is not > true > > > > > > on a Linux box though. I submitted a new PR to fix this and get > > > > > > Windows builds working again on a Linux box, as well as testing > that > > > > > > windows artifacts will still build via Travis. Hopefully this > can > > > > > > unstick the release as you can now cross-compile everything save > the > > > > > > OSX shared-lib on one box by pointing Maven to the proper > targets. > > > > > > > > > > > > -Geoff > > > > > > > > > > > > On Sat, Jul 18, 2020 at 11:25 AM Gary Gregory < > > > garydgreg...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > > On Thu, Jul 2, 2020 at 12:39 PM Geoffrey Blake < > > > > > > geoffrey.w.bl...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > I took a bit of time to set up an x86 Ubuntu 14.04 VM via > > > virtualbox > > > > > > > > and vagrant, but it looks like the windows build is broken. > > > There > > > > > are > > > > > > > > typos trying to include "Windows.h" which should be > "windows.h" > > > to > > > > > > > > > > > > > > > > > > > > > > Are you sure that this include is not referring the to > Microsoft > > > > > header, > > > > > > > for example, on my machine: > > > > > > > > > > > > > > C:\Program Files (x86)\Windows > > > > > Kits\10\Include\10.0.17763.0\um\Windows.h > > > > > > > > > > > > > > ? > > > > > > > > > > > > > > Gary > > > > > > > > > > > > > > > compile with mingw and redefined macros that I think are > mixing > > > > > > > > between Linux and windows headers. I won't be able to get to > > > trying > > > > > > > > to fix and submit any PRs on these this week or next. But > > > anyone who > > > > > > > > wants to try cross-compiling, here are the packages I > installed > > > to > > > > > get > > > > > > > > up and running minimally on Ubuntu: > > > > > > > > > > > > > > > > sudo apt-get install build-essential g++-mingw-w64 > > > > > > > > gcc-aarch64-linux-gnu libc6-dev-i386 > > > > > > > > sudo apt-get install libssl-dev git > > > > > > > > sudo add-apt-repository ppa:openjdk-r/ppa > > > > > > > > sudo apt-get install openjdk-8-jdk > > > > > > > > > > > > > > > > Don't install the Ubuntu supplied maven, its too old. Just > grab > > > the > > > > > > > > 3.6 tarball from apache. > > > > > > > > > > > > > > > > -Geoff > > > > > > > > > > > > > > > > On Tue, Jun 30, 2020 at 8:24 PM Alex Remily < > > > alex.rem...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > > > > > > I'll see if I have any time this weekend, but this part is > > > largely > > > > > > > > > unfamiliar to me, so not sure how far I'll get even if I > have > > > the > > > > > > time > > > > > > > > > to look at it. > > > > > > > > > > > > > > > > > > On Tue, Jun 30, 2020 at 4:59 PM Geoffrey Blake > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > I think you're right Alex. I just happened to look at > the > > > > > Makefile > > > > > > > > > > and saw this above the win64 target: > > > > > > > > > > > > > > > > > > > > # for cross-compilation on Ubuntu, install the > > > > > g++-mingw-w64-x86-64 > > > > > > > > package > > > > > > > > > > > > > > > > > > > > We could potentially build everything but MacOS on 1 > Ubuntu > > > > > > 16.04LTS > > > > > > > > > > box. Or even a 14.04 box if necessary. Anybody have the > > > ti
Re: [crypto] New Release
I don't see why it couldn't. I don't think OSX images are publicly accessible in Docker Hub though, and if not we'd need a Mac as the base machine to run the build. From the base machine we should be able to call docker using the Maven exec plugin, use docker to pull in the desired linux arch host, and configure that host to cross compile the Windows build using MinGW. Thoughts? I'm convalescing this weekend so I should have some time to try it out. Alex On Sat, Jul 25, 2020 at 12:21 AM Geoffrey Blake wrote: > > Docker would be great. Next question, can that be integrated into > Maven for automating these releases that someone knows offhand? > > -Geoff > > On Fri, Jul 24, 2020 at 7:50 PM Alex Remily wrote: > > > > Sounds like a great idea. > > > > On Fri, Jul 24, 2020, 8:29 PM Marcelo Vanzin wrote: > > > > > Is it possible to cross-compile from Linux to MacOS? > > > > > > Even if it isn't, might be a good idea to write a docker image to do > > > the other cross-builds; then from a Mac you can build the MacOS binary > > > and call docker to build all the others. > > > > > > On Fri, Jul 24, 2020 at 5:04 PM Alex Remily wrote: > > > > > > > > I'd recommend using MinGW. I installed it through brew on my Mac and > > > cross > > > > compiled the windows build with little difficulty. I expect a similar > > > > experience on Linux. The MinGW install contains all the necessary > > > windows > > > > headers. > > > > > > > > On Fri, Jul 24, 2020, 7:16 PM Gary Gregory > > > wrote: > > > > > > > > > Thanks Geoffrey, > > > > > > > > > > Are you available at some point to do a webex to straighten out my > > > local > > > > > set up? Just email me directly so we can coordinate. > > > > > > > > > > Gary > > > > > > > > > > On Fri, Jul 24, 2020 at 4:34 PM Geoffrey Blake < > > > geoffrey.w.bl...@gmail.com > > > > > > > > > > > wrote: > > > > > > > > > > > Hi Gary, > > > > > > > > > > > > windows.h/Windows.h/WINDOWS.H are all names for the same file, on > > > > > > Windows I've found out, the FS is case-insensitive. This is not > > > > > > true > > > > > > on a Linux box though. I submitted a new PR to fix this and get > > > > > > Windows builds working again on a Linux box, as well as testing that > > > > > > windows artifacts will still build via Travis. Hopefully this can > > > > > > unstick the release as you can now cross-compile everything save the > > > > > > OSX shared-lib on one box by pointing Maven to the proper targets. > > > > > > > > > > > > -Geoff > > > > > > > > > > > > On Sat, Jul 18, 2020 at 11:25 AM Gary Gregory < > > > garydgreg...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > > On Thu, Jul 2, 2020 at 12:39 PM Geoffrey Blake < > > > > > > geoffrey.w.bl...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > I took a bit of time to set up an x86 Ubuntu 14.04 VM via > > > virtualbox > > > > > > > > and vagrant, but it looks like the windows build is broken. > > > There > > > > > are > > > > > > > > typos trying to include "Windows.h" which should be "windows.h" > > > to > > > > > > > > > > > > > > > > > > > > > > Are you sure that this include is not referring the to Microsoft > > > > > header, > > > > > > > for example, on my machine: > > > > > > > > > > > > > > C:\Program Files (x86)\Windows > > > > > Kits\10\Include\10.0.17763.0\um\Windows.h > > > > > > > > > > > > > > ? > > > > > > > > > > > > > > Gary > > > > > > > > > > > > > > > compile with mingw and redefined macros that I think are mixing > > > > > > > > between Linux and windows headers. I won't be able to get to > > > trying > > > > > > > > to fix and submit any PRs on these this week or next. But > > > anyone who > > > > > > > > wants to try cross-compiling, here are the packages I installed > > > to > > > > > get > > > > > > > > up and running minimally on Ubuntu: > > > > > > > > > > > > > > > > sudo apt-get install build-essential g++-mingw-w64 > > > > > > > > gcc-aarch64-linux-gnu libc6-dev-i386 > > > > > > > > sudo apt-get install libssl-dev git > > > > > > > > sudo add-apt-repository ppa:openjdk-r/ppa > > > > > > > > sudo apt-get install openjdk-8-jdk > > > > > > > > > > > > > > > > Don't install the Ubuntu supplied maven, its too old. Just grab > > > the > > > > > > > > 3.6 tarball from apache. > > > > > > > > > > > > > > > > -Geoff > > > > > > > > > > > > > > > > On Tue, Jun 30, 2020 at 8:24 PM Alex Remily < > > > alex.rem...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > > > > > > I'll see if I have any time this weekend, but this part is > > > largely > > > > > > > > > unfamiliar to me, so not sure how far I'll get even if I have > > > the > > > > > > time > > > > > > > > > to look at it. > > > > > > > > > > > > > > > > > > On Tue, Jun 30, 2020 at 4:59 PM Geoffrey Blake > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > I think you're right Alex. I just happened to look at the > > > > > Makefile > > > > > > > > > > and saw this above the win64 target: > > > > > > > > > > >
