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
