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
