https://github.com/gradle/gradle/pull/69
On Dec 23, 2012, at 10:55 AM, Diwaker Gupta <[email protected]> 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 > <[email protected]> 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> http://about.me/stliu/bio
