Un-assigning to give another devloper a chance to pick this up since NZ & ST discovered a good fix for IGBF-1552 & NZ will be working on that next.

Some useful links regarding the issue shared by Dr.Freese

http://igbquickload.org/smokeTestingQuickload/H_sapiens_Dec_2013/GFF3/

https://genome.ucsc.edu/FAQ/FAQformat.html#format3

https://wiki.transvar.org/display/igbman/Track+lines+for+configuring+track+appearance

Code changes :

https://bitbucket.org/noorzahara/integrated-genome-browser-local1/branch/IGBF-1835#diff

[~aloraine] Kindly help review the code.

Just a few change requests:

• Please do not add core/igb/src/main/resources/git.properties.
• Can you please squash all the changes into a single commit?

Suggestions for functional review:

• Obtain a GFF file
• Add a header line indicating color - select a color that IGB would not show as default
• Open the file and check it is the requested color

(Please think of more!)

[~aloraine]

I have squashed all the changes to a single commit.

The functional review was done for this ticket. The code is working fine. It was tested for 3 GFF files with different color indications. The requested color is displayed instead of default in IGB. Kindly submit a pull request for the same.

Shamika Gajanan Kulkarni or Noor Zahara - please attach or provide a link to GFF3 files with track line used for testing/development.

Unable to attach files more than 10 MB.
The file can be found in the link http://igbquickload.org/smokeTestingQuickload/H_sapiens_Dec_2013/GFF3/
In the header add ##track name="test" color=255,255,0 in line 2 to test.

Could you create a smaller version and attach that?
Otherwise, each time someone has to test the functionality, they will have to download and edit the file.
Alternatively (maybe this is better?), create a ticket to add such a file to the smoketest quickload site and/or to the test infrastructure files in the project?
I am working on this today – trying to see if we can support this feature without making lots of changes to the code.
Seems like track style infrastructure is already available to support color in GFF3 track lines, so I'm looking at how this is working for the other file types in hopes of gaining some insight.

I am moving this into the next sprint pending simplification of the IGB build system.
Reason is:
There are a large number of changes to files, reflecting flaws in our architecture.
I feel that this many changes – and the massive amount of effort Noor had to expend just to understand what is going on – simply to support foreground color settings coming from the parsed file itself – ought not to have been necessary. I would like dig a little deeper to understand the ways our architecture made this necessary. It should be easier!

To use an analogy from the building trades: You should not have to install an entirely new wall simply to hang a painting.

However, our build system is overly complex, with a massive level of technical debt left over from older, more primitive versions of mvn. I think this needs to be improved (simplified and clarified) before attempting any major restructuring or analysis of the data intake (parsing) systems.

Noor Zahara - please keep your branch "live" on your fork, with the commits as they are. I am going to reject the pull request, but please be aware that this is not a reflection on your work. This is just so that the pull request no longer appears in the pull request queue while we deal with the blocking issue.