Tweet
I have a Java manifest file (text *.MF) which has in it a line that I want to ignore:
Implementation-Version: 03.04.02.0 08/13/2008 02:05 PM
Simple enough, I create a new file format for *.MF files - Done
I create a new Basic Element name called "Compile Date and Version" with a text regular expression of "^Implementation-Version:.*$" - Done
...
So far no way to specify this "Grammar" as unimportant.
...
I open up a folder compare of a number of .jar files each containing a Java Manifest file. I expand all folders (and jar files to expose the packaged subfolders). I double click on one of the *.MF files. Shows me that the line is different (in red). I click on the "Referee", and under the Importance tab I uncheck my Grammar Element "Compile Date and Version" and choose "Use for these files within parent session" or "Use for all files within parent session". Close the window and now the line is in blue. Hey, progress.
Close that file comparison and go back to all of the *.MF files. I see the files I just selected now show as having unimportant differences, but all the other *.MF files still show as red. I select all files and choose "Compare Contents... -> Rules-based Comparison". After doing this, it now shows ALL *.MF files as different again. Double click on ANY *.MF file -> shows as only unimportant differences, close that file compare and again it flags the files in the folder view as "unimportant". This can be repeated any number of times.
The bottom line is that the "Compare Contents... -> Rules-based Comparison" seems to be ignoring the fact that I told it that grammar was unimportant.
To take a step back, here is what I am trying to accomplish:
I want to set for certain file types text that should always be ignored when doing a rule based comparison of more than one file at a time. Just like I have been able to do with previous versions of BC. It seems strange that when I am defining the file grammar (Tools -> File Formats) it does not allow me at that time to specify which tags are unimportant.
Please let me know if I am going about this the wrong way or have found a bug.
Thanks,
-Shawn
Implementation-Version: 03.04.02.0 08/13/2008 02:05 PM
Simple enough, I create a new file format for *.MF files - Done
I create a new Basic Element name called "Compile Date and Version" with a text regular expression of "^Implementation-Version:.*$" - Done
...
So far no way to specify this "Grammar" as unimportant.
...
I open up a folder compare of a number of .jar files each containing a Java Manifest file. I expand all folders (and jar files to expose the packaged subfolders). I double click on one of the *.MF files. Shows me that the line is different (in red). I click on the "Referee", and under the Importance tab I uncheck my Grammar Element "Compile Date and Version" and choose "Use for these files within parent session" or "Use for all files within parent session". Close the window and now the line is in blue. Hey, progress.
Close that file comparison and go back to all of the *.MF files. I see the files I just selected now show as having unimportant differences, but all the other *.MF files still show as red. I select all files and choose "Compare Contents... -> Rules-based Comparison". After doing this, it now shows ALL *.MF files as different again. Double click on ANY *.MF file -> shows as only unimportant differences, close that file compare and again it flags the files in the folder view as "unimportant". This can be repeated any number of times.
The bottom line is that the "Compare Contents... -> Rules-based Comparison" seems to be ignoring the fact that I told it that grammar was unimportant.
To take a step back, here is what I am trying to accomplish:
I want to set for certain file types text that should always be ignored when doing a rule based comparison of more than one file at a time. Just like I have been able to do with previous versions of BC. It seems strange that when I am defining the file grammar (Tools -> File Formats) it does not allow me at that time to specify which tags are unimportant.
Please let me know if I am going about this the wrong way or have found a bug.
Thanks,
-Shawn
Comment