Vivek, I've changed the 'Subject' line here so more people might look at it and comment (Instead of "that's a review so I will delete").
So as I understand it, the only reason for integrating "antlr277" into sfwnv is that you need to integrate the latest "antlr3" which has a dependency on the "antlr277" jar file (as in ... "http://www.antlr.org/wiki/pages/viewpage.action?pageId=728";) If that is true, to me is seems silly delivering the whole of "antlr277" when really you only need to deliver its jar file. ### Just a suggestion: You could therefore integrate them both ("antlr277" and "antlr3") at the same time but only create a SUNW package for "antlr3" that includes the required "antlr277" jar file bits. This would also allow you to hide the "antlr277" jar file away somewhere. Also there will only be one /usr/bin/antlr to worry about. ### As I say just a suggestion - comments Also going back to the usr/src/lib/antlr277 ws pathname, are you sure that in the future that a later version of antlr 3 (say 3.2.1) will not have a dependency on a higher version of antlr 2: So I still think it would be better if the pathname in the ws was just usr/src/lib/antlr2 Paul Vivek Titarmare wrote: > > I have uploaded the changes and replaced > the data in the webrev url > (http://cr.opensolaris.org/~vivekrt/6816397-antlr277). > ... cut ... > From: Paul Cunningham [mailto:paul.cunningham at tadpole.com] : ... cut ... >>> 4. antlr277 in workspace pathname >>> Why have you got the version 277 in the pathnames, it should >>> probably be just usr/src/lib/antlr/.... >>> >>> Same also applies to the SUNW package name SUNWantlr277, it >>> should probably just be SUNWantlr >>> >>> And the man page name sunman/antlr277.3 >>> >>> otherwise this will all have to change again for the next >>> revision update from the opensource community. >>> >> [VIVEK] Antlr277 is because we are also going to integrate antlr 3.0 which >> is a part of Drools dependency and antlr 3.0 would actually go in antlr >> folder as you mentioned. Two names are registered namely SUNWantlr277 and >> SUNWantlr. >> Same is the case with manpages which would probably look for antlr277 >> initially but when antlr comes end users can use only antlr (which would >> contain all the information) >> FYI:: antlr 3.0 requires antlr277 and StringTemplate as a dependency. Both >> packages would come soon for code review (once antlr277 is finalized). > > So is it possible that in the future you, or someone-else at Sun, may > need/want to update this to version 2.n.x? If so it might be better if > the directory, etc., was just antlr2 (just checking). > > [VIVEK1] actually no antlr2 series would come. All would come is Antlr 3.x > series and my next review would be for antlr 3.0 which would have just the > name as antlr. ... cut ... >>> 12. Install path usr/share/lib/antlr2.7.7/bin >>> Why is this pkg installed hidden away rather than >>> in /usr/bin ? >>> >> [VIVEK] Changed to /usr/bin. > > okay so we now have /usr/bin/antlr (and antlr-config). Ah, but when > antlr 3.0 is integrated will there be another bin/antlr executable? If > so what will happen then? > > [VIVEK1] Yes, a big question. Can we rename the file after install in the > /usr/bin folder? > At presently that would not be required, but when antlr 3.0 comes in we need > a space for the same. However in the case of antlr 3.0, antlr 2.7.7 is a > dependency which would have its own jar file of antlr 2.7.7. Replacing the > existing antlr file would not matter a lot when antlr 3.0 comes into > picture. -- ---------------------------------------------------------------------- Paul Cunningham Software Engineer Tadpole Business Unit
