On Dec 21, 2012, at 5:01 PM, David Holmes wrote: > On 22/12/2012 10:11 AM, Kelly O'Hair wrote: >> On Dec 21, 2012, at 3:27 PM, David Holmes wrote: >>>> On JarReorder.java, it seems like you have just deleted a warning that >>>> someone explicitly asked for >>>> a class to be included, and also explicitly asked for that class to be >>>> excluded. >>>> If we are changing the tool so that exclusion just silently trumps any >>>> inclusion request, seems like we >>>> should just do that and delete this message. I'm fine with that, but the >>>> if(false) seems a bit terse. >>> >>> Yes ideally this change will trigger a closer look at jarreorder and how it >>> is used. AFAIK those listings have been decaying. But the warning message >>> was far too noisy for the profiles builds. I did not want to go down a path >>> of trying to define per-profile reorder lists given that we haven't >>> maintained this for the full JRE anyway. >> >> Can we add a comment as to that being the reason for the if(false)? Maybe >> file a separate Issue to fix it someday, >> or maybe toss the whole ball of JarReorder wax someday. ;^) > > Okay I'll add a comment and comment out the line and see if there is an > existing CR to revisit jarreorder.
OK. > >>> >>>> Why are some of the makefiles named with a ".txt" suffix? Like >>>> makefiles/profile-includes.txt? >>> >>> Because they aren't makefiles ;-) They are txt files that define named >>> lists that happen to be compatible with makefile variable declarations. >> >> But they aren't plain text files, right? > > What is a plain text file ??? They look like make variable declarations, they > also look like property definitions. I liken these files to the > version.numbers file that happen to contain stuff that looks like makefile > variable declarations - should they be .gmk files too? I guess what I'm saying is that they have a particular syntax, it's not arbitrary text. Leave them as is, we can deal with it later. > >>> >>> These lists also get used by other tools eg javac and javadoc. >> >> Do we have any convention for the file suffix on these yet? Or is the long >> term plan to just use .txt? > > Right now it is the .txt. If we want/need to change this then now is the time > as I'll have to sync this with the langtools changes. Not a huge deal to > change later I suppose. But I'm not sure there is any obviously better choice. I'd have to think about it more. I'm fine with leaving them as .txt files for now. > >>>> Unfortunately, everybody on build-infra will be busy for a few weeks >>>> trying to get the cutover done. :^( >>> >>> Not to mention the Xmas/NewYear break. :( >> >> Yeah, might be a limited vacation for some of us. > > Limited vacation, limited weekends, ... ;-) Yup. :^( -kto > > David > >> -kto >> >>> >>> Thanks, >>> David >>> >>> >>>> >>>> -kto >>>> >>>> >>
