Re: splitting CQL parser & spec into separate repo

[Edward Capriolo]

On Thu, Mar 23, 2017 at 10:56 AM, Eric Evans 
wrote:

> On Wed, Mar 22, 2017 at 10:01 AM, Edward Capriolo 
> wrote:
> > I believe you could accomplish a similar goal by making a multi-module
> > project https://maven.apache.org/guides/mini/guide-multiple-modules.html
> .
> > Probably not as easy thanks to ant, but I think that is a better route.
> One
> > there actually are N dependent projects in the wild you can make the case
> > for overhead which is both technical and in ASF based.
>
> This was my first thought: If we were using Maven, we'd probably
> already have created this as a module[*].
>
>
> [*]: Maybe a surprise to some given how strongly I pushed back against
> it in the Early Days, but we would be so much better off at this point
> with Maven.
>
>
> --
> Eric Evans
> john.eric.ev...@gmail.com
>

Well the ant maven bit is a separate issue: It still could be done with
ant, it could be done in a way that the port is very easy.
http://ant.apache.org/easyant/history/trunk/ref/anttasks/SubModuletask.html

Re: splitting CQL parser & spec into separate repo

[Eric Evans]

On Wed, Mar 22, 2017 at 10:01 AM, Edward Capriolo  wrote:
> I believe you could accomplish a similar goal by making a multi-module
> project https://maven.apache.org/guides/mini/guide-multiple-modules.html.
> Probably not as easy thanks to ant, but I think that is a better route. One
> there actually are N dependent projects in the wild you can make the case
> for overhead which is both technical and in ASF based.

This was my first thought: If we were using Maven, we'd probably
already have created this as a module[*].


[*]: Maybe a surprise to some given how strongly I pushed back against
it in the Early Days, but we would be so much better off at this point
with Maven.


-- 
Eric Evans
john.eric.ev...@gmail.com

Re: splitting CQL parser & spec into separate repo

[Edward Capriolo]

On Tue, Mar 21, 2017 at 5:45 PM, Anthony Grasso 
wrote:

> This is a great idea
>
> +1 (non-binding)
>
> On 22 March 2017 at 07:04, Edward Capriolo  wrote:
>
> > On Tue, Mar 21, 2017 at 3:24 PM, Mark Dewey  wrote:
> >
> > > I can immediately think of a project I would use that in. +1
> > >
> > > On Tue, Mar 21, 2017 at 12:18 PM Jonathan Haddad 
> > > wrote:
> > >
> > > > I created CASSANDRA-13284 a few days ago with the intent of starting
> a
> > > > discussion around the topic of breaking the CQL parser out into a
> > > separate
> > > > project.  I see a few benefits to doing it and was wondering what the
> > > folks
> > > > here thought as well.
> > > >
> > > > First off, the Java CQL parser would obviously continue to be the
> > > reference
> > > > parser.  I'd love to see other languages have CQL parsers as well,
> but
> > > the
> > > > intent here isn't for the OSS C* team to be responsible for
> maintaining
> > > > that.  My vision here is simply the ability to have some high level
> > > > CQLParser.parse(statement) call that returns the parse tree, nothing
> > > more.
> > > >
> > > > It would be nice to be able to leverage that parser in other projects
> > > such
> > > > as IDEs, code gen tools, etc.  It would be outstanding to be able to
> > > create
> > > > the parser tests in such a way that they can be referenced by other
> > > parsers
> > > > in other languages.  Yay code reuse.  It also has the benefit of
> making
> > > the
> > > > codebase a little more modular and a bit easier to understand.
> > > >
> > > > Thoughts?
> > > >
> > > > Jon
> > > >
> > >
> >
> > It turns out that a similar thing was done with Hive.
> >
> > https://calcite.apache.org/
> >
> > https://calcite.apache.org/community/#apache-calcite-one-
> planner-fits-all
> >
> > The challenge is typically adoption. The elevator pitch is like:
> > "EVERYONE WILL SHARE THIS AND IT WILL BE AWESOME". Maybe this is the
> wrong
> > word, but lets just say frenemies
> > exist and they do not like control of something moving to a shared
> medium.
> > Technical issues like ANTLR 3 vs ANTRL 4 etc.
> > For something like Hive the challenge is the parser/planner needs only be
> > fast enough for analytic queries but that would not
> > be the right move for say CQL.
> >
>

I believe you could accomplish a similar goal by making a multi-module
project https://maven.apache.org/guides/mini/guide-multiple-modules.html.
Probably not as easy thanks to ant, but I think that is a better route. One
there actually are N dependent projects in the wild you can make the case
for overhead which is both technical and in ASF based.

Re: splitting CQL parser & spec into separate repo

[Anthony Grasso]

This is a great idea

+1 (non-binding)

On 22 March 2017 at 07:04, Edward Capriolo  wrote:

> On Tue, Mar 21, 2017 at 3:24 PM, Mark Dewey  wrote:
>
> > I can immediately think of a project I would use that in. +1
> >
> > On Tue, Mar 21, 2017 at 12:18 PM Jonathan Haddad 
> > wrote:
> >
> > > I created CASSANDRA-13284 a few days ago with the intent of starting a
> > > discussion around the topic of breaking the CQL parser out into a
> > separate
> > > project.  I see a few benefits to doing it and was wondering what the
> > folks
> > > here thought as well.
> > >
> > > First off, the Java CQL parser would obviously continue to be the
> > reference
> > > parser.  I'd love to see other languages have CQL parsers as well, but
> > the
> > > intent here isn't for the OSS C* team to be responsible for maintaining
> > > that.  My vision here is simply the ability to have some high level
> > > CQLParser.parse(statement) call that returns the parse tree, nothing
> > more.
> > >
> > > It would be nice to be able to leverage that parser in other projects
> > such
> > > as IDEs, code gen tools, etc.  It would be outstanding to be able to
> > create
> > > the parser tests in such a way that they can be referenced by other
> > parsers
> > > in other languages.  Yay code reuse.  It also has the benefit of making
> > the
> > > codebase a little more modular and a bit easier to understand.
> > >
> > > Thoughts?
> > >
> > > Jon
> > >
> >
>
> It turns out that a similar thing was done with Hive.
>
> https://calcite.apache.org/
>
> https://calcite.apache.org/community/#apache-calcite-one-planner-fits-all
>
> The challenge is typically adoption. The elevator pitch is like:
> "EVERYONE WILL SHARE THIS AND IT WILL BE AWESOME". Maybe this is the wrong
> word, but lets just say frenemies
> exist and they do not like control of something moving to a shared medium.
> Technical issues like ANTLR 3 vs ANTRL 4 etc.
> For something like Hive the challenge is the parser/planner needs only be
> fast enough for analytic queries but that would not
> be the right move for say CQL.
>

Re: splitting CQL parser & spec into separate repo

[Mark Dewey]

I can immediately think of a project I would use that in. +1

On Tue, Mar 21, 2017 at 12:18 PM Jonathan Haddad  wrote:

> I created CASSANDRA-13284 a few days ago with the intent of starting a
> discussion around the topic of breaking the CQL parser out into a separate
> project.  I see a few benefits to doing it and was wondering what the folks
> here thought as well.
>
> First off, the Java CQL parser would obviously continue to be the reference
> parser.  I'd love to see other languages have CQL parsers as well, but the
> intent here isn't for the OSS C* team to be responsible for maintaining
> that.  My vision here is simply the ability to have some high level
> CQLParser.parse(statement) call that returns the parse tree, nothing more.
>
> It would be nice to be able to leverage that parser in other projects such
> as IDEs, code gen tools, etc.  It would be outstanding to be able to create
> the parser tests in such a way that they can be referenced by other parsers
> in other languages.  Yay code reuse.  It also has the benefit of making the
> codebase a little more modular and a bit easier to understand.
>
> Thoughts?
>
> Jon
>

splitting CQL parser & spec into separate repo

[Jonathan Haddad]

I created CASSANDRA-13284 a few days ago with the intent of starting a
discussion around the topic of breaking the CQL parser out into a separate
project.  I see a few benefits to doing it and was wondering what the folks
here thought as well.

First off, the Java CQL parser would obviously continue to be the reference
parser.  I'd love to see other languages have CQL parsers as well, but the
intent here isn't for the OSS C* team to be responsible for maintaining
that.  My vision here is simply the ability to have some high level
CQLParser.parse(statement) call that returns the parse tree, nothing more.

It would be nice to be able to leverage that parser in other projects such
as IDEs, code gen tools, etc.  It would be outstanding to be able to create
the parser tests in such a way that they can be referenced by other parsers
in other languages.  Yay code reuse.  It also has the benefit of making the
codebase a little more modular and a bit easier to understand.

Thoughts?

Jon