Quantcast

Antlr v3 plugin

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Antlr v3 plugin

Strong Liu
Hi there,

I have created a pull request [1] which add antlr v3 support to gradle[2], would anyone take a look and give some feedback? 

the antlr plugin within gradle distribution only supports antlr v2, and v3 has been released for years ( I guess ), since more and more projects are moving to antlr v3, 
I think it would be great that if gradle supports it


2. http://issues.gradle.org/browse/GRADLE-902
-------------------------
Best Regards,

Strong Liu <stliu at hibernate.org>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Antlr v3 plugin

Adam Murdoch

On 30/03/2012, at 5:19 PM, Strong Liu wrote:

Hi there,

I have created a pull request [1] which add antlr v3 support to gradle[2], would anyone take a look and give some feedback? 

the antlr plugin within gradle distribution only supports antlr v2, and v3 has been released for years ( I guess ), since more and more projects are moving to antlr v3, 
I think it would be great that if gradle supports it



This looks like a well written plugin.

However, I'd rather that it was part of the existing 'antlr' plugin, rather than a completely separate plugin.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Antlr v3 plugin

Russel Winder-3
On Fri, 2012-03-30 at 17:32 +1100, Adam Murdoch wrote:
[...]
>
> However, I'd rather that it was part of the existing 'antlr' plugin, rather than a completely separate plugin.

On the other hand ANTLR 2, 3, and 4 are sufficiently different that it
should be impossible to try using an ANTLR 2 toolchain on an ANTLR 3
project?

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Antlr v3 plugin

Luke Daley-2

On 30/03/2012, at 10:01 AM, Russel Winder wrote:

> On Fri, 2012-03-30 at 17:32 +1100, Adam Murdoch wrote:
> [...]
>>
>> However, I'd rather that it was part of the existing 'antlr' plugin, rather than a completely separate plugin.
>
> On the other hand ANTLR 2, 3, and 4 are sufficiently different that it
> should be impossible to try using an ANTLR 2 toolchain on an ANTLR 3
> project?

The same plugin could offer support for all versions.

--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Antlr v3 plugin

Strong Liu


On Mar 30, 2012, at 5:05 PM, Luke Daley wrote:


On 30/03/2012, at 10:01 AM, Russel Winder wrote:

On Fri, 2012-03-30 at 17:32 +1100, Adam Murdoch wrote:
[...]

However, I'd rather that it was part of the existing 'antlr' plugin, rather than a completely separate plugin.

On the other hand ANTLR 2, 3, and 4 are sufficiently different that it
should be impossible to try using an ANTLR 2 toolchain on an ANTLR 3
project?

The same plugin could offer support for all versions.

some reasons I would vote for a new plugin:

1. antlr v2 plugin has `project.getConfigurations().getByName(COMPILE_CONFIGURATION_NAME).extendsFrom(antlrConfiguration);`
which means project using v2 plugin can only defines antlr configuration w/o compile configuration to include antlr dependency

we can / should not use same way with antlr v3, since antlr v3 requires a complete version ( include antlr v2, antlr v3 and string templete jar ) to generate grammar
but it also has a runtime version for runtime using

so, pseudo code for v3 users:

compile org.antlr:antlr-runtime:3.1
antlr org.antlr:antlr-complete:3.1

it breaks backward compatibility if we changed the v2 behavior or add unnecessary dependencies to the user project if we change v3

2. hard to find the antlr version
we could have adapters for each version within one plugin, but we must know which version is used to choose the right adapter  

two ways I can see to find the antlr version: 
 
using antlr plugin extension and ask user to explicitly set the version or assume v2 as default ( to compatible with the old one)
run antlr in a separated jvm fork first to get the version output


either way I don't see the benefit than having a new antlr v3 plugin, and these two plugin already share most of code 


 


--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Antlr v3 plugin

Luke Daley-2

On 06/04/2012, at 10:25 PM, Strong Liu wrote:



On Mar 30, 2012, at 5:05 PM, Luke Daley wrote:


On 30/03/2012, at 10:01 AM, Russel Winder wrote:

On Fri, 2012-03-30 at 17:32 +1100, Adam Murdoch wrote:
[...]

However, I'd rather that it was part of the existing 'antlr' plugin, rather than a completely separate plugin.

On the other hand ANTLR 2, 3, and 4 are sufficiently different that it
should be impossible to try using an ANTLR 2 toolchain on an ANTLR 3
project?

The same plugin could offer support for all versions.

some reasons I would vote for a new plugin:

1. antlr v2 plugin has `project.getConfigurations().getByName(COMPILE_CONFIGURATION_NAME).extendsFrom(antlrConfiguration);`
which means project using v2 plugin can only defines antlr configuration w/o compile configuration to include antlr dependency

we can / should not use same way with antlr v3, since antlr v3 requires a complete version ( include antlr v2, antlr v3 and string templete jar ) to generate grammar
but it also has a runtime version for runtime using

so, pseudo code for v3 users:

compile org.antlr:antlr-runtime:3.1
antlr org.antlr:antlr-complete:3.1

it breaks backward compatibility if we changed the v2 behavior or add unnecessary dependencies to the user project if we change v3

2. hard to find the antlr version
we could have adapters for each version within one plugin, but we must know which version is used to choose the right adapter  

two ways I can see to find the antlr version: 
 
using antlr plugin extension and ask user to explicitly set the version or assume v2 as default ( to compatible with the old one)
run antlr in a separated jvm fork first to get the version output


either way I don't see the benefit than having a new antlr v3 plugin, and these two plugin already share most of code 

How do we progress this?

-- 
Luke Daley
Principal Engineer, Gradleware 
http://gradleware.com

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Antlr v3 plugin

Steve Ebersole-2
Have y'all decided anything about this?  There has been a pull request
sitting there for 9+ months.


On Thu 12 Apr 2012 06:48:30 AM CDT, Luke Daley wrote:

>
> On 06/04/2012, at 10:25 PM, Strong Liu wrote:
>
>>
>>
>> On Mar 30, 2012, at 5:05 PM, Luke Daley wrote:
>>
>>>
>>> On 30/03/2012, at 10:01 AM, Russel Winder wrote:
>>>
>>>> On Fri, 2012-03-30 at 17:32 +1100, Adam Murdoch wrote:
>>>> [...]
>>>>>
>>>>> However, I'd rather that it was part of the existing 'antlr'
>>>>> plugin, rather than a completely separate plugin.
>>>>
>>>> On the other hand ANTLR 2, 3, and 4 are sufficiently different that it
>>>> should be impossible to try using an ANTLR 2 toolchain on an ANTLR 3
>>>> project?
>>>
>>> The same plugin could offer support for all versions.
>>
>> some reasons I would vote for a new plugin:
>>
>> 1. antlr v2 plugin has
>> `project.getConfigurations().getByName(COMPILE_CONFIGURATION_NAME).extendsFrom(antlrConfiguration);`
>> which means project using v2 plugin can only defines antlr
>> configuration w/o compile configuration to include antlr dependency
>>
>> we can / should not use same way with antlr v3, since antlr v3
>> requires a complete version ( include antlr v2, antlr v3 and string
>> templete jar ) to generate grammar
>> but it also has a runtime version for runtime using
>>
>> so, pseudo code for v3 users:
>>
>> compile org.antlr:antlr-runtime:3.1
>> antlr org.antlr:antlr-complete:3.1
>>
>> it breaks backward compatibility if we changed the v2 behavior or add
>> unnecessary dependencies to the user project if we change v3
>>
>> 2. hard to find the antlr version
>> we could have adapters for each version within one plugin, but we
>> must know which version is used to choose the right adapter
>>
>> two ways I can see to find the antlr version:
>> using antlr plugin extension and ask user to explicitly set the
>> version or assume v2 as default ( to compatible with the old one)
>> run antlr in a separated jvm fork first to get the version output
>>
>>
>> either way I don't see the benefit than having a new antlr v3 plugin,
>> and these two plugin already share most of code
>
> How do we progress this?
>
> --
> Luke Daley
> Principal Engineer, Gradleware
> http://gradleware.com
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Antlr v3 plugin

Adam Murdoch

On 04/12/2012, at 2:13 AM, Steve Ebersole wrote:

Have y'all decided anything about this?  There has been a pull request sitting there for 9+ months.

I'm still pretty keen to have a single plugin deal with both Antlr 2 and Antlr 3.

To deal with the 'antlr' configuration changing we can:

1. Infer the version of Antlr from the dependencies declared in the 'compile' configuration.
2. Infer the implementation from this (with an option to provide your own implementation).
3. Deprecate the 'antlr' configuration.

We want to use this approach in a few places (e.g. inferring the Groovy and Scala compiler implementations from the compile configurations).

To deal with the different APIs we can:

1. Compile some source against Antlr 2 and some source against Antlr 3, probably separated into source sets.
2. Load the appropriate integration at runtime.

Again, we need to do this kind of thing elsewhere (e.g. loading the right Groovy compiler and integration at runtime, dealing with changes to the FindBugs and TestNG APIs, and the Java 5 vs Java 6 APIs), so it's not a big deal if we extract some common stuff for dealing with this.




On Thu 12 Apr 2012 06:48:30 AM CDT, Luke Daley wrote:

On 06/04/2012, at 10:25 PM, Strong Liu wrote:



On Mar 30, 2012, at 5:05 PM, Luke Daley wrote:


On 30/03/2012, at 10:01 AM, Russel Winder wrote:

On Fri, 2012-03-30 at 17:32 +1100, Adam Murdoch wrote:
[...]

However, I'd rather that it was part of the existing 'antlr'
plugin, rather than a completely separate plugin.

On the other hand ANTLR 2, 3, and 4 are sufficiently different that it
should be impossible to try using an ANTLR 2 toolchain on an ANTLR 3
project?

The same plugin could offer support for all versions.

some reasons I would vote for a new plugin:

1. antlr v2 plugin has
`project.getConfigurations().getByName(COMPILE_CONFIGURATION_NAME).extendsFrom(antlrConfiguration);`
which means project using v2 plugin can only defines antlr
configuration w/o compile configuration to include antlr dependency

we can / should not use same way with antlr v3, since antlr v3
requires a complete version ( include antlr v2, antlr v3 and string
templete jar ) to generate grammar
but it also has a runtime version for runtime using

so, pseudo code for v3 users:

compile org.antlr:antlr-runtime:3.1
antlr org.antlr:antlr-complete:3.1

it breaks backward compatibility if we changed the v2 behavior or add
unnecessary dependencies to the user project if we change v3

2. hard to find the antlr version
we could have adapters for each version within one plugin, but we
must know which version is used to choose the right adapter

two ways I can see to find the antlr version:
using antlr plugin extension and ask user to explicitly set the
version or assume v2 as default ( to compatible with the old one)
run antlr in a separated jvm fork first to get the version output


either way I don't see the benefit than having a new antlr v3 plugin,
and these two plugin already share most of code

How do we progress this?

--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email




--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Antlr v3 plugin

Steve Ebersole-2
I am actually thinking I may just skip Antlr 3 in Hibernate and go
right to Antlr 4.  I am willing to help y'all with this (combined
plugin) but I will need quite a bit of help with basically all the
parts you just mentioned above.  All the things you just mentioned are
pretty advanced and have no documentation that I know of...

On Tue 04 Dec 2012 10:21:46 PM CST, Adam Murdoch wrote:

>
> On 04/12/2012, at 2:13 AM, Steve Ebersole wrote:
>
>> Have y'all decided anything about this?  There has been a pull
>> request sitting there for 9+ months.
>
> I'm still pretty keen to have a single plugin deal with both Antlr 2
> and Antlr 3.
>
> To deal with the 'antlr' configuration changing we can:
>
> 1. Infer the version of Antlr from the dependencies declared in the
> 'compile' configuration.
> 2. Infer the implementation from this (with an option to provide your
> own implementation).
> 3. Deprecate the 'antlr' configuration.
>
> We want to use this approach in a few places (e.g. inferring the
> Groovy and Scala compiler implementations from the compile
> configurations).
>
> To deal with the different APIs we can:
>
> 1. Compile some source against Antlr 2 and some source against Antlr
> 3, probably separated into source sets.
> 2. Load the appropriate integration at runtime.
>
> Again, we need to do this kind of thing elsewhere (e.g. loading the
> right Groovy compiler and integration at runtime, dealing with changes
> to the FindBugs and TestNG APIs, and the Java 5 vs Java 6 APIs), so
> it's not a big deal if we extract some common stuff for dealing with this.
>
>
>>
>>
>> On Thu 12 Apr 2012 06:48:30 AM CDT, Luke Daley wrote:
>>>
>>> On 06/04/2012, at 10:25 PM, Strong Liu wrote:
>>>
>>>>
>>>>
>>>> On Mar 30, 2012, at 5:05 PM, Luke Daley wrote:
>>>>
>>>>>
>>>>> On 30/03/2012, at 10:01 AM, Russel Winder wrote:
>>>>>
>>>>>> On Fri, 2012-03-30 at 17:32 +1100, Adam Murdoch wrote:
>>>>>> [...]
>>>>>>>
>>>>>>> However, I'd rather that it was part of the existing 'antlr'
>>>>>>> plugin, rather than a completely separate plugin.
>>>>>>
>>>>>> On the other hand ANTLR 2, 3, and 4 are sufficiently different
>>>>>> that it
>>>>>> should be impossible to try using an ANTLR 2 toolchain on an ANTLR 3
>>>>>> project?
>>>>>
>>>>> The same plugin could offer support for all versions.
>>>>
>>>> some reasons I would vote for a new plugin:
>>>>
>>>> 1. antlr v2 plugin has
>>>> `project.getConfigurations().getByName(COMPILE_CONFIGURATION_NAME).extendsFrom(antlrConfiguration);`
>>>> which means project using v2 plugin can only defines antlr
>>>> configuration w/o compile configuration to include antlr dependency
>>>>
>>>> we can / should not use same way with antlr v3, since antlr v3
>>>> requires a complete version ( include antlr v2, antlr v3 and string
>>>> templete jar ) to generate grammar
>>>> but it also has a runtime version for runtime using
>>>>
>>>> so, pseudo code for v3 users:
>>>>
>>>> compile org.antlr:antlr-runtime:3.1
>>>> antlr org.antlr:antlr-complete:3.1
>>>>
>>>> it breaks backward compatibility if we changed the v2 behavior or add
>>>> unnecessary dependencies to the user project if we change v3
>>>>
>>>> 2. hard to find the antlr version
>>>> we could have adapters for each version within one plugin, but we
>>>> must know which version is used to choose the right adapter
>>>>
>>>> two ways I can see to find the antlr version:
>>>> using antlr plugin extension and ask user to explicitly set the
>>>> version or assume v2 as default ( to compatible with the old one)
>>>> run antlr in a separated jvm fork first to get the version output
>>>>
>>>>
>>>> either way I don't see the benefit than having a new antlr v3 plugin,
>>>> and these two plugin already share most of code
>>>
>>> How do we progress this?
>>>
>>> --
>>> Luke Daley
>>> Principal Engineer, Gradleware
>>> http://gradleware.com
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>
>
> --
> Adam Murdoch
> Gradle Co-founder
> http://www.gradle.org
> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
> http://www.gradleware.com
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Antlr v3 plugin

Adam Murdoch

On 08/12/2012, at 5:19 AM, Steve Ebersole wrote:

I am actually thinking I may just skip Antlr 3 in Hibernate and go right to Antlr 4.  I am willing to help y'all with this (combined plugin) but I will need quite a bit of help with basically all the parts you just mentioned above.  All the things you just mentioned are pretty advanced and have no documentation that I know of…

A good first step would be to infer the Antlr version. We'll change the Scala and Groovy plugins to do this, just to establish the pattern, and you can copy this pattern.

Following that, we can look at:

1. Splitting the Antlr version specific classes out into a separate source set.
2. Adding an Antlr 3 and/or Antlr 4 source set.
3. Using the default Antlr generator implementation based on the inferred Antlr version.
4. Loading the correct integration at runtime based on the inferred Antlr version.
5. Deprecating the 'antlr' configuration.



On Tue 04 Dec 2012 10:21:46 PM CST, Adam Murdoch wrote:

On 04/12/2012, at 2:13 AM, Steve Ebersole wrote:

Have y'all decided anything about this?  There has been a pull
request sitting there for 9+ months.

I'm still pretty keen to have a single plugin deal with both Antlr 2
and Antlr 3.

To deal with the 'antlr' configuration changing we can:

1. Infer the version of Antlr from the dependencies declared in the
'compile' configuration.
2. Infer the implementation from this (with an option to provide your
own implementation).
3. Deprecate the 'antlr' configuration.

We want to use this approach in a few places (e.g. inferring the
Groovy and Scala compiler implementations from the compile
configurations).

To deal with the different APIs we can:

1. Compile some source against Antlr 2 and some source against Antlr
3, probably separated into source sets.
2. Load the appropriate integration at runtime.

Again, we need to do this kind of thing elsewhere (e.g. loading the
right Groovy compiler and integration at runtime, dealing with changes
to the FindBugs and TestNG APIs, and the Java 5 vs Java 6 APIs), so
it's not a big deal if we extract some common stuff for dealing with this.




On Thu 12 Apr 2012 06:48:30 AM CDT, Luke Daley wrote:

On 06/04/2012, at 10:25 PM, Strong Liu wrote:



On Mar 30, 2012, at 5:05 PM, Luke Daley wrote:


On 30/03/2012, at 10:01 AM, Russel Winder wrote:

On Fri, 2012-03-30 at 17:32 +1100, Adam Murdoch wrote:
[...]

However, I'd rather that it was part of the existing 'antlr'
plugin, rather than a completely separate plugin.

On the other hand ANTLR 2, 3, and 4 are sufficiently different
that it
should be impossible to try using an ANTLR 2 toolchain on an ANTLR 3
project?

The same plugin could offer support for all versions.

some reasons I would vote for a new plugin:

1. antlr v2 plugin has
`project.getConfigurations().getByName(COMPILE_CONFIGURATION_NAME).extendsFrom(antlrConfiguration);`
which means project using v2 plugin can only defines antlr
configuration w/o compile configuration to include antlr dependency

we can / should not use same way with antlr v3, since antlr v3
requires a complete version ( include antlr v2, antlr v3 and string
templete jar ) to generate grammar
but it also has a runtime version for runtime using

so, pseudo code for v3 users:

compile org.antlr:antlr-runtime:3.1
antlr org.antlr:antlr-complete:3.1

it breaks backward compatibility if we changed the v2 behavior or add
unnecessary dependencies to the user project if we change v3

2. hard to find the antlr version
we could have adapters for each version within one plugin, but we
must know which version is used to choose the right adapter

two ways I can see to find the antlr version:
using antlr plugin extension and ask user to explicitly set the
version or assume v2 as default ( to compatible with the old one)
run antlr in a separated jvm fork first to get the version output


either way I don't see the benefit than having a new antlr v3 plugin,
and these two plugin already share most of code

How do we progress this?

--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email




--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Antlr v3 plugin

Steve Ebersole-2
On Tue 11 Dec 2012 04:21:45 PM CST, Adam Murdoch wrote:

> On 08/12/2012, at 5:19 AM, Steve Ebersole wrote:
>
>>
>> I am actually thinking I may just skip Antlr 3 in Hibernate and go
>> right to Antlr 4. I am willing to help y'all with this (combined
>> plugin) but I will need quite a bit of help with basically all the
>> parts you just mentioned above. All the things you just mentioned
>> are pretty advanced and have no documentation that I know of…
>
> A good first step would be to infer the Antlr version. We'll change
> the Scala and Groovy plugins to do this, just to establish the
> pattern, and you can copy this pattern.
Infer how?  artifact version?  that seems dicey.

Are these Scala/Groovy change done yet?  Where?

> Following that, we can look at:
>
> 1. Splitting the Antlr version specific classes out into a separate
> source set.
You mean in the gradle plugin code?  Or are you taking here (in combo
with #2) about having dedicated Antlr v2, v3 and v4 *project* source
sets?  If so, see notes on #2.

> 2. Adding an Antlr 3 and/or Antlr 4 source set.
What is the reason you want distinct source sets?  I can't imagine folks
would use a mix of Antlr versions in the same project.

One thing that should certainly change would be default inclusion
patterns.  The recommendation (Antlr team) is to use 'g4' (i.e.,
"MyGramar.g4") as the extension for Antlr 4 grammar files; can't say I
have ever seen an 'official' recommendation for v2/v3 naming though
using 'g' (i.e. "MyGrammar.g") is the norm I have seen.

> 3. Using the default Antlr generator implementation based on the
> inferred Antlr version.
> 4. Loading the correct integration at runtime based on the inferred
> Antlr version.
> 5. Deprecating the 'antlr' configuration.

Does this go

>
>
>>
>>
>> On Tue 04 Dec 2012 10:21:46 PM CST, Adam Murdoch wrote:
>>>
>>>
>>> On 04/12/2012, at 2:13 AM, Steve Ebersole wrote:
>>>
>>>>
>>>> Have y'all decided anything about this? There has been a pull
>>>> request sitting there for 9+ months.
>>>
>>>
>>> I'm still pretty keen to have a single plugin deal with both Antlr 2
>>> and Antlr 3.
>>>
>>> To deal with the 'antlr' configuration changing we can:
>>>
>>> 1. Infer the version of Antlr from the dependencies declared in the
>>> 'compile' configuration.
>>> 2. Infer the implementation from this (with an option to provide your
>>> own implementation).
>>> 3. Deprecate the 'antlr' configuration.
>>>
>>> We want to use this approach in a few places (e.g. inferring the
>>> Groovy and Scala compiler implementations from the compile
>>> configurations).
>>>
>>> To deal with the different APIs we can:
>>>
>>> 1. Compile some source against Antlr 2 and some source against Antlr
>>> 3, probably separated into source sets.
>>> 2. Load the appropriate integration at runtime.
>>>
>>> Again, we need to do this kind of thing elsewhere (e.g. loading the
>>> right Groovy compiler and integration at runtime, dealing with changes
>>> to the FindBugs and TestNG APIs, and the Java 5 vs Java 6 APIs), so
>>> it's not a big deal if we extract some common stuff for dealing with
>>> this.
>>>
>>>
>>>>
>>>>
>>>>
>>>> On Thu 12 Apr 2012 06:48:30 AM CDT, Luke Daley wrote:
>>>>>
>>>>>
>>>>> On 06/04/2012, at 10:25 PM, Strong Liu wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mar 30, 2012, at 5:05 PM, Luke Daley wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 30/03/2012, at 10:01 AM, Russel Winder wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, 2012-03-30 at 17:32 +1100, Adam Murdoch wrote:
>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> However, I'd rather that it was part of the existing 'antlr'
>>>>>>>>> plugin, rather than a completely separate plugin.
>>>>>>>>
>>>>>>>>
>>>>>>>> On the other hand ANTLR 2, 3, and 4 are sufficiently different
>>>>>>>> that it
>>>>>>>> should be impossible to try using an ANTLR 2 toolchain on an
>>>>>>>> ANTLR 3
>>>>>>>> project?
>>>>>>>
>>>>>>>
>>>>>>> The same plugin could offer support for all versions.
>>>>>>
>>>>>>
>>>>>> some reasons I would vote for a new plugin:
>>>>>>
>>>>>> 1. antlr v2 plugin has
>>>>>> `project.getConfigurations().getByName(COMPILE_CONFIGURATION_NAME).extendsFrom(antlrConfiguration);`
>>>>>> which means project using v2 plugin can only defines antlr
>>>>>> configuration w/o compile configuration to include antlr dependency
>>>>>>
>>>>>> we can / should not use same way with antlr v3, since antlr v3
>>>>>> requires a complete version ( include antlr v2, antlr v3 and string
>>>>>> templete jar ) to generate grammar
>>>>>> but it also has a runtime version for runtime using
>>>>>>
>>>>>> so, pseudo code for v3 users:
>>>>>>
>>>>>> compile org.antlr:antlr-runtime:3.1
>>>>>> antlr org.antlr:antlr-complete:3.1
>>>>>>
>>>>>> it breaks backward compatibility if we changed the v2 behavior or add
>>>>>> unnecessary dependencies to the user project if we change v3
>>>>>>
>>>>>> 2. hard to find the antlr version
>>>>>> we could have adapters for each version within one plugin, but we
>>>>>> must know which version is used to choose the right adapter
>>>>>>
>>>>>> two ways I can see to find the antlr version:
>>>>>> using antlr plugin extension and ask user to explicitly set the
>>>>>> version or assume v2 as default ( to compatible with the old one)
>>>>>> run antlr in a separated jvm fork first to get the version output
>>>>>>
>>>>>>
>>>>>> either way I don't see the benefit than having a new antlr v3 plugin,
>>>>>> and these two plugin already share most of code
>>>>>
>>>>>
>>>>> How do we progress this?
>>>>>
>>>>> --
>>>>> Luke Daley
>>>>> Principal Engineer, Gradleware
>>>>> http://gradleware.com
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>> http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Adam Murdoch
>>> Gradle Co-founder
>>> http://www.gradle.org
>>> VP of Engineering, Gradleware Inc. - Gradle Training, Support,
>>> Consulting
>>> http://www.gradleware.com
>>>
>>
>
>
>
> --
> Adam Murdoch
> Gradle Co-founder
> http://www.gradle.org
> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
> http://www.gradleware.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Antlr v3 plugin

Diwaker Gupta
In reply to this post by Steve Ebersole-2
Hey Steve,

Is your antlr3 plugin available somewhere? I'd like to use gradle with
antlr4 and am fine using a specialized plugin for now, rather than
wait for the combined plugin to emerge. Instead of starting from
scratch, I figured it would easier to start with your antlr3 plugin.

cheers,
Diwaker


On Fri, Dec 7, 2012 at 10:19 AM, Steve Ebersole
<[hidden email]> wrote:

> I am actually thinking I may just skip Antlr 3 in Hibernate and go right to
> Antlr 4.  I am willing to help y'all with this (combined plugin) but I will
> need quite a bit of help with basically all the parts you just mentioned
> above.  All the things you just mentioned are pretty advanced and have no
> documentation that I know of...
>
>
> On Tue 04 Dec 2012 10:21:46 PM CST, Adam Murdoch wrote:
>>
>>
>> On 04/12/2012, at 2:13 AM, Steve Ebersole wrote:
>>
>>> Have y'all decided anything about this?  There has been a pull
>>> request sitting there for 9+ months.
>>
>>
>> I'm still pretty keen to have a single plugin deal with both Antlr 2
>> and Antlr 3.
>>
>> To deal with the 'antlr' configuration changing we can:
>>
>> 1. Infer the version of Antlr from the dependencies declared in the
>> 'compile' configuration.
>> 2. Infer the implementation from this (with an option to provide your
>> own implementation).
>> 3. Deprecate the 'antlr' configuration.
>>
>> We want to use this approach in a few places (e.g. inferring the
>> Groovy and Scala compiler implementations from the compile
>> configurations).
>>
>> To deal with the different APIs we can:
>>
>> 1. Compile some source against Antlr 2 and some source against Antlr
>> 3, probably separated into source sets.
>> 2. Load the appropriate integration at runtime.
>>
>> Again, we need to do this kind of thing elsewhere (e.g. loading the
>> right Groovy compiler and integration at runtime, dealing with changes
>> to the FindBugs and TestNG APIs, and the Java 5 vs Java 6 APIs), so
>> it's not a big deal if we extract some common stuff for dealing with this.
>>
>>
>>>
>>>
>>> On Thu 12 Apr 2012 06:48:30 AM CDT, Luke Daley wrote:
>>>>
>>>>
>>>> On 06/04/2012, at 10:25 PM, Strong Liu wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mar 30, 2012, at 5:05 PM, Luke Daley wrote:
>>>>>
>>>>>>
>>>>>> On 30/03/2012, at 10:01 AM, Russel Winder wrote:
>>>>>>
>>>>>>> On Fri, 2012-03-30 at 17:32 +1100, Adam Murdoch wrote:
>>>>>>> [...]
>>>>>>>>
>>>>>>>>
>>>>>>>> However, I'd rather that it was part of the existing 'antlr'
>>>>>>>> plugin, rather than a completely separate plugin.
>>>>>>>
>>>>>>>
>>>>>>> On the other hand ANTLR 2, 3, and 4 are sufficiently different
>>>>>>> that it
>>>>>>> should be impossible to try using an ANTLR 2 toolchain on an ANTLR 3
>>>>>>> project?
>>>>>>
>>>>>>
>>>>>> The same plugin could offer support for all versions.
>>>>>
>>>>>
>>>>> some reasons I would vote for a new plugin:
>>>>>
>>>>> 1. antlr v2 plugin has
>>>>>
>>>>> `project.getConfigurations().getByName(COMPILE_CONFIGURATION_NAME).extendsFrom(antlrConfiguration);`
>>>>> which means project using v2 plugin can only defines antlr
>>>>> configuration w/o compile configuration to include antlr dependency
>>>>>
>>>>> we can / should not use same way with antlr v3, since antlr v3
>>>>> requires a complete version ( include antlr v2, antlr v3 and string
>>>>> templete jar ) to generate grammar
>>>>> but it also has a runtime version for runtime using
>>>>>
>>>>> so, pseudo code for v3 users:
>>>>>
>>>>> compile org.antlr:antlr-runtime:3.1
>>>>> antlr org.antlr:antlr-complete:3.1
>>>>>
>>>>> it breaks backward compatibility if we changed the v2 behavior or add
>>>>> unnecessary dependencies to the user project if we change v3
>>>>>
>>>>> 2. hard to find the antlr version
>>>>> we could have adapters for each version within one plugin, but we
>>>>> must know which version is used to choose the right adapter
>>>>>
>>>>> two ways I can see to find the antlr version:
>>>>> using antlr plugin extension and ask user to explicitly set the
>>>>> version or assume v2 as default ( to compatible with the old one)
>>>>> run antlr in a separated jvm fork first to get the version output
>>>>>
>>>>>
>>>>> either way I don't see the benefit than having a new antlr v3 plugin,
>>>>> and these two plugin already share most of code
>>>>
>>>>
>>>> How do we progress this?
>>>>
>>>> --
>>>> Luke Daley
>>>> Principal Engineer, Gradleware
>>>> http://gradleware.com
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>> --
>> Adam Murdoch
>> Gradle Co-founder
>> http://www.gradle.org
>> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
>> http://www.gradleware.com
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>



--
http://maginatics.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Antlr v3 plugin

Strong Liu
https://github.com/gradle/gradle/pull/69

On Dec 23, 2012, at 10:55 AM, Diwaker Gupta <[hidden email]> wrote:

Hey Steve,

Is your antlr3 plugin available somewhere? I'd like to use gradle with
antlr4 and am fine using a specialized plugin for now, rather than
wait for the combined plugin to emerge. Instead of starting from
scratch, I figured it would easier to start with your antlr3 plugin.

cheers,
Diwaker


On Fri, Dec 7, 2012 at 10:19 AM, Steve Ebersole
<[hidden email]> wrote:
I am actually thinking I may just skip Antlr 3 in Hibernate and go right to
Antlr 4.  I am willing to help y'all with this (combined plugin) but I will
need quite a bit of help with basically all the parts you just mentioned
above.  All the things you just mentioned are pretty advanced and have no
documentation that I know of...


On Tue 04 Dec 2012 10:21:46 PM CST, Adam Murdoch wrote:


On 04/12/2012, at 2:13 AM, Steve Ebersole wrote:

Have y'all decided anything about this?  There has been a pull
request sitting there for 9+ months.


I'm still pretty keen to have a single plugin deal with both Antlr 2
and Antlr 3.

To deal with the 'antlr' configuration changing we can:

1. Infer the version of Antlr from the dependencies declared in the
'compile' configuration.
2. Infer the implementation from this (with an option to provide your
own implementation).
3. Deprecate the 'antlr' configuration.

We want to use this approach in a few places (e.g. inferring the
Groovy and Scala compiler implementations from the compile
configurations).

To deal with the different APIs we can:

1. Compile some source against Antlr 2 and some source against Antlr
3, probably separated into source sets.
2. Load the appropriate integration at runtime.

Again, we need to do this kind of thing elsewhere (e.g. loading the
right Groovy compiler and integration at runtime, dealing with changes
to the FindBugs and TestNG APIs, and the Java 5 vs Java 6 APIs), so
it's not a big deal if we extract some common stuff for dealing with this.




On Thu 12 Apr 2012 06:48:30 AM CDT, Luke Daley wrote:


On 06/04/2012, at 10:25 PM, Strong Liu wrote:



On Mar 30, 2012, at 5:05 PM, Luke Daley wrote:


On 30/03/2012, at 10:01 AM, Russel Winder wrote:

On Fri, 2012-03-30 at 17:32 +1100, Adam Murdoch wrote:
[...]


However, I'd rather that it was part of the existing 'antlr'
plugin, rather than a completely separate plugin.


On the other hand ANTLR 2, 3, and 4 are sufficiently different
that it
should be impossible to try using an ANTLR 2 toolchain on an ANTLR 3
project?


The same plugin could offer support for all versions.


some reasons I would vote for a new plugin:

1. antlr v2 plugin has

`project.getConfigurations().getByName(COMPILE_CONFIGURATION_NAME).extendsFrom(antlrConfiguration);`
which means project using v2 plugin can only defines antlr
configuration w/o compile configuration to include antlr dependency

we can / should not use same way with antlr v3, since antlr v3
requires a complete version ( include antlr v2, antlr v3 and string
templete jar ) to generate grammar
but it also has a runtime version for runtime using

so, pseudo code for v3 users:

compile org.antlr:antlr-runtime:3.1
antlr org.antlr:antlr-complete:3.1

it breaks backward compatibility if we changed the v2 behavior or add
unnecessary dependencies to the user project if we change v3

2. hard to find the antlr version
we could have adapters for each version within one plugin, but we
must know which version is used to choose the right adapter

two ways I can see to find the antlr version:
using antlr plugin extension and ask user to explicitly set the
version or assume v2 as default ( to compatible with the old one)
run antlr in a separated jvm fork first to get the version output


either way I don't see the benefit than having a new antlr v3 plugin,
and these two plugin already share most of code


How do we progress this?

--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email




--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email





--
http://maginatics.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



-------------------------
Best Regards,

Strong Liu <stliu at hibernate.org>

Loading...