OK, I just approved those changes. I was working on a shell script to automate
it--nice to have, but not necessary. Better that you can get it into 4.0.
Thanks!
On 2021/04/15 17:33:20, Micah Kornfield wrote:
> I took a look and added comments. I'm not sure if Bob replied off-list,
> so hopef
I took a look and added comments. I'm not sure if Bob replied off-list,
so hopefully no work was duplicated.
Lets try to be mindful that the project is asynchronous in nature and it
might take a little time to reply.
Cheers,
Micah
On Thu, Apr 15, 2021 at 10:00 AM Nate Bauernfeind <
natebauernf
> I think checking in the java files is fine and probably better then
relying
> on a third party package. We should make sure there are instructions on
> how to regenerate them along with the PR
Micah,
I just opened a pull-request to satisfy ARROW-12111. This is my first
contribution to an apach
Hey Bob,
Someone did publish a 1.12 version of the flatc maven plugin. I double
checked that the plugin and binaries look correct and legit.. but you know,
it's always shady to download some random executable from the internet and
run it. However, I have been using it to generate the arrow flatbuf
I apologize for leaving this hanging, but it looks like 4.0 is leaving the
station :(
Yes, it makes sense to bump it to 1.12, but you can't do that in isolation,
because the flatc binary which is fetched as a Maven dependency is only
available for 1.9. I will get back onto this and finish it thi
It would also be nice to upgrade that java flatbuffer version from 1.9 to
1.12. Is anyone planning on doing this work (as listed in ARROW-12111)?
If I did this work today, might it be possible to get it included in the
4.0.0 release?
On Fri, Mar 26, 2021 at 3:25 PM bobtins wrote:
> OK, original
OK, originally this was part of
https://issues.apache.org/jira/browse/ARROW-12006 and I was going to just add
some doc on flatc, but I will make this a new bug because it's a little bigger:
https://issues.apache.org/jira/browse/ARROW-12111
On 2021/03/23 23:40:50, Micah Kornfield wrote:
> >
>
>
> I have a concern, though. Four other languages (Java would be five) check
> in the generated flatbuffers code, and it appears (based on a quick scan of
> Git logs) that this is done manually. Is there a danger that the binary
> format could change, but some language might get forgotten, and thu
I'm happy to check in the generated Java source. I would also update the Java
build info to reflect this change and document how to regenerate the source as
needed.
I have a concern, though. Four other languages (Java would be five) check in
the generated flatbuffers code, and it appears (based
I think checking in the java files is fine and probably better then relying
on a third party package. We should make sure there are instructions on
how to regenerate them along with the PR
On Monday, March 22, 2021, Antoine Pitrou wrote:
>
> Le 22/03/2021 à 20:17, bobtins a écrit :
>
>> TL;DR:
Le 22/03/2021 à 20:17, bobtins a écrit :
TL;DR: The Java implementation doesn't have generated flatbuffers code
under source control, and the code generation depends on an
unofficially-maintained Maven artifact. Other language implementations do
check in the generated code; would it make sense
TL;DR: The Java implementation doesn't have generated flatbuffers code
under source control, and the code generation depends on an
unofficially-maintained Maven artifact. Other language implementations do
check in the generated code; would it make sense for this to be done for
Java as well?
I'm cu
12 matches
Mail list logo
