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

[Jody Garnett <jody.garnett@xxxxxxxxx>]

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