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
>
>
