Re: [technology-pmc] [CQ 7372] antlr Version: 3.3

[Jody Garnett <jody.garnett@xxxxxxxxx>]

Thanks Micheal (not sure if the technolog-pmc email list reference will bounce for you).

We are putting uDig through an incubation process to join the LocationTech Industry Working Group (i.e. part of the Eclipse Foundation). As such Sharon is reviewing our dependencies, and ANTLR tools apparently has issues.

I am not sure if we can submit the antlr 2.7.7 runtime jar and still be okay? You only use antlr at runtime right? You do not need the command line tools while jiffle is running?

-- 

Jody Garnett

On Saturday, 13 July 2013 at 9:22 PM, Michael Bedward wrote:

Hi all,

I don't know the context for this discussion but here is the story

regarding Jiffle / ANTLR...

I'd be happy to build Jiffle against ANTLR v3.5 but, despite what

Terence Parr might have told you, I don't think that will remove the

dependency on v2.7.7. This is because Jiffle uses Terr's ST library to

generate Java source code. The ANTLR website

(http://www.antlr3.org/download.html) says:

"...unless you are using output=template; For backward compatibility

reasons, ANTLR 3.5 still generates code that uses ST v3 at parse-time"

... and unfortunately ST v3 depends on ANTLR v2.7.7

So my understanding is that I'd have to rewrite the ANTLR grammars for

Jiffle to avoid the dependency.

I've had a long term wish to rewrite the grammars to use ANTLR v4

which offers many new features, but it's the usual sob story... Jiffle

has one dev (me) with no funding and no free time right now.

Happy to talk about it further and help if I can, but the above is the

sum total of my current knowledge.

Michael

On 13 July 2013 14:34, Jody Garnett <jody.garnett@xxxxxxxxx> wrote:

Hello Sharon:

In order not to duplicate the discussion, I am CCing the technology-pmc and

Micheal Bedward (the contact point for Jiffle which controls our Antlr 3.3

transitive dependency).

1. Antlr 2.X stream cannot be approved for Eclipse distribution due to

provenance issues.

Understood.

2. There are quite a few versions of the Runtime Only approved for Eclipse

distribution to date. As such, Version 3.3 Runtime Only would be eligible

for

a "Diff" review with checkin immediately available based on Parallel IP.

Understood.

3. I've been in touch with the Antlr project lead and he has confirmed that

ANTLR 3.5 does not depend on v2 at all anymore. Perhaps you can move up to

this version instead as a view to resolving the 2.x issue.

I checked the dependency on antlr and it is due to two projects:

- groovy

- jiffle

As this is a transitive dependency I do not control what version of antlr

the uDig project uses.

I have CCed Micheal Bedward (the contact point for jiffle) to ask how antlr

works for that project.

Micheal I understand that antlr is split into an antlr.jar (with the tools

needed to generate a grammar) and an antlr-runtime (containing the base

classes

for the AST needed at runtime).

Is it possible that jiffle can make use of only the antlr-runtime?

4. Individual CQs are typically required for each jar included in the

source.

There can be specific instances, however, where we may choose to go a

different

route which you have already experienced with GeoTools. However, mixing

version numbers would definitely require different CQs.

Yes, I was only confused about antlr because antlr 3.3 download

include/requires antlr 2.7.7 (I am glad the author has cleared this up).

If you decide to go with version 3.5 (All), I could look at the download to

help make a decision if you need one or two CQs.

If we go with antlr 3.5 we will try and make only a request for the runtime

(subject to how groovy and Jiffle operate).

It may help to also understand that while you provided source from Maven for

the Geotools content, we typically expect the source to be provided straight

from the third party project. We were, however, comfortable with that

approach

for Geotools. I'm going to look into this in a bit more detail to see how

flexible we can be on that front for moving forward. I’m not sure if this is

helpful or a hinderance for you….

I think the approach is suitable for GeoTools and ImageIO (i.e. both

projects that release a single codebase as a series of src jars - one for

each module). However this is a balance, my preference has always been to

submit a link to the third party repository or source download (however this

has your tripping up over build artefacts and does not *exactly* correspond

to what we wish to distribute).

(I am also hindered by the IPZilla bot that emails me constantly when source

code has not been provided for a CQ - perhaps we could allow it to accept a

link, or I could attach an html file with a link).

I'll wait to hear from you and PMC. We can change this CQ accordingly based

on your response.

To reduce Risk I am trying to keep the version numbers consistent during

this CQ process.

Jody