Uploaded image for project: 'IGB'
  1. IGB
  2. IGBF-3349

Remove guava (google) upper bound version requirement for ProtAnnot

    Details

    • Type: Task
    • Status: Closed (View Workflow)
    • Priority: Blocker
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Story Points:
      3
    • Sprint:
      Summer 2 2023 May 29, Summer 4 2023 June 26, Summer 5 2023 July 10, Summer 6 2023 July 24, Summer 7 2023 Aug 7

      Description

      Situation: As part of IGBF-3310 we updated the com.google.guava dependency on IGB master to a newer version (32.1.1-jre) as the newer version does not have a known vulnerability. However, the Protannot manifest currently specifies an Import-Package for:

      com.google.common.base;version="\"[16.0,17)\"",
      com.google.common.collect;version="\"[16.0,17)\"",
      com.google.common.eventbus;version="\"[16.0,17)\"",
      

      This prevents ProtAnnot from appearing in the IGB app store while running the current version of master.

      Task: Update/Release a new version of Protannot that can use the newer version of com.google.guava. If possible, set it so that Protannot is not dependent on a specific version of com.google.guava.

        Attachments

          Issue Links

            Activity

            Hide
            kgopu Kaushik Gopu added a comment -

            After upgrading Guava to the latest version, 31.1-jre, and eliminating outdated imports from the pom.xml file, the ProtAnnot feature is now visible in the master IGB. However, Dr. Freese suggests that including the entire Guava library in Protannot might be excessive, as Protannot only requires a few specific components from Guava. I have uploaded the modified code to the repository for future reference: https://bitbucket.org/kaushik-gopu/kgopu_proant/branch/IGBF-3349

            Show
            kgopu Kaushik Gopu added a comment - After upgrading Guava to the latest version, 31.1-jre, and eliminating outdated imports from the pom.xml file, the ProtAnnot feature is now visible in the master IGB . However, Dr. Freese suggests that including the entire Guava library in Protannot might be excessive, as Protannot only requires a few specific components from Guava. I have uploaded the modified code to the repository for future reference: https://bitbucket.org/kaushik-gopu/kgopu_proant/branch/IGBF-3349
            Hide
            ann.loraine Ann Loraine added a comment - - edited

            A quick note:

            If ProtAnnot is going to rely on the platform (IGB) to provide the necessary package, we need to specify which version of IGB is needed, since the currently released version of IGB does not have this. This is difficult.

            In light of this difficulty, it might be good for ProtAnnot to package its required library along with the App and not use the library provided by the framework. If we do this, then ProtAnnot developers would not have to keep track of all the myriad 3rd-party libraries that are getting packaged with IGB as part of the platform.

            Show
            ann.loraine Ann Loraine added a comment - - edited A quick note: If ProtAnnot is going to rely on the platform (IGB) to provide the necessary package, we need to specify which version of IGB is needed, since the currently released version of IGB does not have this. This is difficult. In light of this difficulty, it might be good for ProtAnnot to package its required library along with the App and not use the library provided by the framework. If we do this, then ProtAnnot developers would not have to keep track of all the myriad 3rd-party libraries that are getting packaged with IGB as part of the platform.
            Hide
            kgopu Kaushik Gopu added a comment -

            Instead of mentioning specific versions, we can use version="0" in the plugins so that they can dynamically pick the version being used by IGB at runtime. This approach will save us from hardcoding specific version numbers. However, it's important to note that modifying the dependency versions to align with IGB's version might be time-consuming. This is because every time we upgrade a dependency in IGB, we would need to review all the plugins and adjust their respective versions accordingly.

            To sum up, even though every plugin has its own pom.xml to manage dependencies, they are only valid for compile time. They look over IGB for dependencies and import the necessary ones, which we basically mention in <Import-Package> </Import-Package>, and use them during runtime. either we can make plugins version independent or change the versions whenever there is an dependency upgrade happens in IGB.

            Show
            kgopu Kaushik Gopu added a comment - Instead of mentioning specific versions, we can use version="0" in the plugins so that they can dynamically pick the version being used by IGB at runtime. This approach will save us from hardcoding specific version numbers. However, it's important to note that modifying the dependency versions to align with IGB's version might be time-consuming. This is because every time we upgrade a dependency in IGB, we would need to review all the plugins and adjust their respective versions accordingly. To sum up, even though every plugin has its own pom.xml to manage dependencies, they are only valid for compile time. They look over IGB for dependencies and import the necessary ones, which we basically mention in <Import-Package> </Import-Package>, and use them during runtime. either we can make plugins version independent or change the versions whenever there is an dependency upgrade happens in IGB.
            Show
            ann.loraine Ann Loraine added a comment - Reference: https://stackoverflow.com/questions/36188935/how-to-exclude-version-numbers-from-import-package-with-maven-bundle-plugin
            Hide
            ann.loraine Ann Loraine added a comment - - edited

            Summary of discussion:

            • Try this: set the "import-packages" bundle plugin configuration to * and then report back as to what the bundle plugin inserted into the corresponding section of the MANIFEST
            • We think that probably the best solution that properly balances flexibility and safety is to specify version 16 as the acceptable guava package version. We think that this will ensure that the ProtAnnot app will be able to properly function in currently released and future versions IGB.
            • We note that ProtAnnot is indeed explicitly importing the above package in its java code.
            • We note also that at some point in the past, someone edited the import-packages directive to maven bundle plugin, making it specify which packages to import into the bundle and which versions. See: this commit.
            • We recalled that App Store somehow or other needs to be able to figure out which versions of IGB a given App version can be installed into. [~aloraine] remembers (but could be wrong) that App Store code parses the bundled MANIFEST to determine IGB compatibility. This means that an App developer, one way or another, has to somehow insert some kind of text into the MANIFEST's OSGI-specific import packages statement that indicate IGB version.
            • [~aloraine] requests Kaushik Gopu and/or Nowlan Freese write about / document this issue and these concerns in a way that will help future developers of Apps to understand the platform and its use.
            Show
            ann.loraine Ann Loraine added a comment - - edited Summary of discussion: Try this: set the "import-packages" bundle plugin configuration to * and then report back as to what the bundle plugin inserted into the corresponding section of the MANIFEST We think that probably the best solution that properly balances flexibility and safety is to specify version 16 as the acceptable guava package version. We think that this will ensure that the ProtAnnot app will be able to properly function in currently released and future versions IGB. We note that ProtAnnot is indeed explicitly importing the above package in its java code. We note also that at some point in the past, someone edited the import-packages directive to maven bundle plugin, making it specify which packages to import into the bundle and which versions. See: this commit . We recalled that App Store somehow or other needs to be able to figure out which versions of IGB a given App version can be installed into. [~aloraine] remembers (but could be wrong) that App Store code parses the bundled MANIFEST to determine IGB compatibility. This means that an App developer, one way or another, has to somehow insert some kind of text into the MANIFEST's OSGI-specific import packages statement that indicate IGB version. [~aloraine] requests Kaushik Gopu and/or Nowlan Freese write about / document this issue and these concerns in a way that will help future developers of Apps to understand the platform and its use.
            Hide
            nfreese Nowlan Freese added a comment - - edited
                                    <Import-Package>
                                        com.apple.eawt,
                                        org.lorainelab.igb.*;version=9.1.0,
                                        *
                                    </Import-Package>
            

            leads to:

            Import-Package: org.lorainelab.igb.genoviz.extensions;version="9.1.0",or
             g.lorainelab.igb.genoviz.extensions.glyph;version="9.1.0",org.lorainela
             b.igb.image.exporter.service;version="9.1.0",org.lorainelab.igb.javafx;
             version="9.1.0",org.lorainelab.igb.menu.api;version="9.1.0",org.loraine
             lab.igb.menu.api.model;version="9.1.0",org.lorainelab.igb.services;vers
             ion="9.1.0",com.affymetrix.common;version="[9.1,10)",com.affymetrix.gen
             ometry;version="[9.1,10)",com.affymetrix.genometry.comparator;version="
             [9.1,10)",com.affymetrix.genometry.event;version="[9.1,10)",com.affymet
             rix.genometry.span;version="[9.1,10)",com.affymetrix.genometry.symmetry
             ;version="[9.1,10)",com.affymetrix.genometry.symmetry.impl;version="[9.
             1,10)",com.affymetrix.genometry.thread;version="[9.1,10)",com.affymetri
             x.genometry.util;version="[9.1,10)",com.affymetrix.genoviz.awt;version=
             "[1.1,2)",com.affymetrix.genoviz.bioviews;version="[1.1,2)",com.affymet
             rix.genoviz.event;version="[1.1,2)",com.affymetrix.genoviz.glyph;versio
             n="[1.1,2)",com.affymetrix.genoviz.swing;version="[1.1,2)",com.affymetr
             ix.genoviz.util;version="[1.1,2)",com.affymetrix.genoviz.widget;version
             ="[1.1,2)",com.affymetrix.genoviz.widget.tieredmap;version="[1.1,2)",co
             m.affymetrix.igb.shared;version="[9.1,10)",com.affymetrix.igb.swing;ver
             sion="[9.1,10)",com.affymetrix.igb.swing.jide;version="[9.1,10)",com.go
             ogle.common.base;version="[16.0,17)",com.google.common.collect;version=
             "[16.0,17)",com.google.common.eventbus;version="[16.0,17)",javax.swing,
             javax.swing.border,javax.swing.table,javax.xml.bind,javax.xml.bind.anno
             tation,javax.xml.namespace,javax.xml.parsers,javax.xml.xpath,net.miginf
             ocom.layout,net.miginfocom.swing,org.apache.commons.io;version="[1.4,2)
             ",org.apache.commons.lang3.text;version="[3.4,4)",org.osgi.service.comp
             onent;version="[1.2,2)",org.slf4j;version="[1.7,2)",org.w3c.dom,org.xml
             .sax,com.apple.eawt
            

            Note that the google version is still being set to between 16 and 17, unsure of why. This version of protannot does appear to work correctly in IGB 9.1.10 (IGB with version 16 of google).

            Show
            nfreese Nowlan Freese added a comment - - edited <Import-Package> com.apple.eawt, org.lorainelab.igb.*;version=9.1.0, * </Import-Package> leads to: Import-Package: org.lorainelab.igb.genoviz.extensions;version= "9.1.0" ,or g.lorainelab.igb.genoviz.extensions.glyph;version= "9.1.0" ,org.lorainela b.igb.image.exporter.service;version= "9.1.0" ,org.lorainelab.igb.javafx; version= "9.1.0" ,org.lorainelab.igb.menu.api;version= "9.1.0" ,org.loraine lab.igb.menu.api.model;version= "9.1.0" ,org.lorainelab.igb.services;vers ion= "9.1.0" ,com.affymetrix.common;version= "[9.1,10)" ,com.affymetrix.gen ometry;version= "[9.1,10)" ,com.affymetrix.genometry.comparator;version=" [9.1,10) ",com.affymetrix.genometry.event;version=" [9.1,10)",com.affymet rix.genometry.span;version= "[9.1,10)" ,com.affymetrix.genometry.symmetry ;version= "[9.1,10)" ,com.affymetrix.genometry.symmetry.impl;version="[9. 1,10) ",com.affymetrix.genometry.thread;version=" [9.1,10)",com.affymetri x.genometry.util;version= "[9.1,10)" ,com.affymetrix.genoviz.awt;version= "[1.1,2)" ,com.affymetrix.genoviz.bioviews;version= "[1.1,2)" ,com.affymet rix.genoviz.event;version= "[1.1,2)" ,com.affymetrix.genoviz.glyph;versio n= "[1.1,2)" ,com.affymetrix.genoviz.swing;version= "[1.1,2)" ,com.affymetr ix.genoviz.util;version= "[1.1,2)" ,com.affymetrix.genoviz.widget;version = "[1.1,2)" ,com.affymetrix.genoviz.widget.tieredmap;version= "[1.1,2)" ,co m.affymetrix.igb.shared;version= "[9.1,10)" ,com.affymetrix.igb.swing;ver sion= "[9.1,10)" ,com.affymetrix.igb.swing.jide;version= "[9.1,10)" ,com.go ogle.common.base;version= "[16.0,17)" ,com.google.common.collect;version= "[16.0,17)" ,com.google.common.eventbus;version= "[16.0,17)" ,javax.swing, javax.swing.border,javax.swing.table,javax.xml.bind,javax.xml.bind.anno tation,javax.xml.namespace,javax.xml.parsers,javax.xml.xpath,net.miginf ocom.layout,net.miginfocom.swing,org.apache.commons.io;version="[1.4,2) ",org.apache.commons.lang3.text;version=" [3.4,4)",org.osgi.service.comp onent;version= "[1.2,2)" ,org.slf4j;version= "[1.7,2)" ,org.w3c.dom,org.xml .sax,com.apple.eawt Note that the google version is still being set to between 16 and 17, unsure of why. This version of protannot does appear to work correctly in IGB 9.1.10 (IGB with version 16 of google).
            Hide
            nfreese Nowlan Freese added a comment - - edited

            Documentation on maven-bundle-plugin Import-Package: https://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html

            <Import-Package>
            The <Import-Package> instruction is a list of packages that are required by the bundle’s contained packages. The default for this header is "", resulting in importing all referred packages. This header rarely has to be explicitly specified. However, in certain cases when there is an unwanted import, such an import can be removed by using a negation package pattern. The package patterns work in the same way as for <Export-Package>, which means they are ordered. For example, if you wanted to import all packages except org.foo.impl you would specify "!org.foo.impl,"

            <Import-Package> is assumed to be "*", which imports everything referred to by the bundle content, but not contained in the bundle. Any exported packages are also imported by default, to ensure a consistent class space.

            Testing Protannot on my system, completely omitting the Import-Package results in the manifest containing the same/similar Import-Package section as if I had included *. This version of ProtAnnot works in IGB 9.1.10 using google version 16.

            Show
            nfreese Nowlan Freese added a comment - - edited Documentation on maven-bundle-plugin Import-Package: https://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html <Import-Package> The <Import-Package> instruction is a list of packages that are required by the bundle’s contained packages. The default for this header is "", resulting in importing all referred packages. This header rarely has to be explicitly specified. However, in certain cases when there is an unwanted import, such an import can be removed by using a negation package pattern. The package patterns work in the same way as for <Export-Package>, which means they are ordered. For example, if you wanted to import all packages except org.foo.impl you would specify "!org.foo.impl," <Import-Package> is assumed to be "*", which imports everything referred to by the bundle content, but not contained in the bundle. Any exported packages are also imported by default, to ensure a consistent class space. Testing Protannot on my system, completely omitting the Import-Package results in the manifest containing the same/similar Import-Package section as if I had included *. This version of ProtAnnot works in IGB 9.1.10 using google version 16.
            Hide
            nfreese Nowlan Freese added a comment -

            works in 9.1.12

            com.google.common.base;version=32.1.1,
            com.google.common.collect;version=32.1.1,
            com.google.common.eventbus;version=32.1.1,
            

            works in 9.1.12 and 9.1.10

            com.google.common.base;version=16.0,
            com.google.common.collect;version=16.0,
            com.google.common.eventbus;version=16.0,
            

            works in 9.1.12 and 9.1.10

            com.google.common.base;version="\"[16.0,33)\"",
            com.google.common.collect;version="\"[16.0,33)\"",
            com.google.common.eventbus;version="\"[16.0,33)\"",
            
            Show
            nfreese Nowlan Freese added a comment - works in 9.1.12 com.google.common.base;version=32.1.1, com.google.common.collect;version=32.1.1, com.google.common.eventbus;version=32.1.1, works in 9.1.12 and 9.1.10 com.google.common.base;version=16.0, com.google.common.collect;version=16.0, com.google.common.eventbus;version=16.0, works in 9.1.12 and 9.1.10 com.google.common.base;version= "\" [16.0,33)\"", com.google.common.collect;version= "\" [16.0,33)\"", com.google.common.eventbus;version= "\" [16.0,33)\"",
            Hide
            nfreese Nowlan Freese added a comment -

            One other interesting comment on Stackoverflow: https://stackoverflow.com/questions/36187308/how-to-configure-maven-bundle-plugin

            Add an empty <Export-Package/> tag : by default, this plugin export all packages but .internal. .impl.. If your package doesn't use this convention, you risk to export internal classes of your bundle.

            Show
            nfreese Nowlan Freese added a comment - One other interesting comment on Stackoverflow: https://stackoverflow.com/questions/36187308/how-to-configure-maven-bundle-plugin Add an empty <Export-Package/> tag : by default, this plugin export all packages but .internal. .impl. . If your package doesn't use this convention, you risk to export internal classes of your bundle.
            Hide
            kgopu Kaushik Gopu added a comment -

            As Nowlan Freese suggested, I would also like to go with the same approach(exclusion of upper bound version) because, it is compatible with any newer version and most importantly we don't need to make any version changes in future whenever we upgrade some dependency in IGB. assigning base version to package means it is compatible with any version >= base version.
            Below are the details about changes that were commited to repo.
            *commit
            *branch
            Moving to first level review.

            Show
            kgopu Kaushik Gopu added a comment - As Nowlan Freese suggested, I would also like to go with the same approach(exclusion of upper bound version) because, it is compatible with any newer version and most importantly we don't need to make any version changes in future whenever we upgrade some dependency in IGB. assigning base version to package means it is compatible with any version >= base version. Below are the details about changes that were commited to repo. * commit * branch Moving to first level review.
            Hide
            ann.loraine Ann Loraine added a comment -

            For some reason when I'm connected to the UNCC VPN I get "bad gateway" errors from bitbucket. Moving back to "Needs first level review" since I can't actually test this now while I'm using the VPN.

            Show
            ann.loraine Ann Loraine added a comment - For some reason when I'm connected to the UNCC VPN I get "bad gateway" errors from bitbucket. Moving back to "Needs first level review" since I can't actually test this now while I'm using the VPN.
            Hide
            ann.loraine Ann Loraine added a comment -

            Request for Kaushik Gopu:

            Please build new xml and jar files for the new branch and deploy to the Downloads section of the fork so that I can test it.

            Show
            ann.loraine Ann Loraine added a comment - Request for Kaushik Gopu : Please build new xml and jar files for the new branch and deploy to the Downloads section of the fork so that I can test it.
            Hide
            nfreese Nowlan Freese added a comment -

            Tested Kaushik's protannot branch locally on Mac following the testing guidelines outlined in IGBF-3381.

            IGB release-9.1.10
            Installed version 9.1.3 of ProtAnnot through the App Manager. After adding Kaushik's protannot as a new repository the app manager showed that I could update protannot from 9.1.3 to 9.1.4. ProtAnnot worked correctly.

            IGB main-JDK8
            With the default app manager repositories ProtAnnot is not available. After adding Kaushik's protannot as a new repository the app manager showed that I could install protannot version 9.1.4. ProtAnnot worked correctly.

            Looking at the commit, I don't think we should make changes to the version logic for non Google/Guava dependencies. Please limit the changes to just Google/Guava. We may need to make additional changes to versions in IGBF-3393 or when we are able to get the R6 declarative services annotations working in IGB.

            Show
            nfreese Nowlan Freese added a comment - Tested Kaushik's protannot branch locally on Mac following the testing guidelines outlined in IGBF-3381 . IGB release-9.1.10 Installed version 9.1.3 of ProtAnnot through the App Manager. After adding Kaushik's protannot as a new repository the app manager showed that I could update protannot from 9.1.3 to 9.1.4. ProtAnnot worked correctly. IGB main-JDK8 With the default app manager repositories ProtAnnot is not available. After adding Kaushik's protannot as a new repository the app manager showed that I could install protannot version 9.1.4. ProtAnnot worked correctly. Looking at the commit , I don't think we should make changes to the version logic for non Google/Guava dependencies. Please limit the changes to just Google/Guava. We may need to make additional changes to versions in IGBF-3393 or when we are able to get the R6 declarative services annotations working in IGB.
            Hide
            kgopu Kaushik Gopu added a comment - - edited

            *Reverted non guava version changes. here is the commit.
            *pipeline build was successful.
            *moving to first level review.

            Show
            kgopu Kaushik Gopu added a comment - - edited *Reverted non guava version changes. here is the commit . *pipeline build was successful. *moving to first level review.
            Hide
            nfreese Nowlan Freese added a comment -

            Retested following testing outlined in previous commit, everything is working.

            Please squash commits then submit pull request.

            Show
            nfreese Nowlan Freese added a comment - Retested following testing outlined in previous commit, everything is working. Please squash commits then submit pull request.
            Hide
            nfreese Nowlan Freese added a comment - - edited

            Regarding running out of build minutes, I contacted Bitbucket and this was the response:

            John commented:

            Hi Nowlan,

            Thank you for reaching out to Atlassian. My name is John and I'm from the Billing and Licensing team. I'll be happy to look into your request.

            Unfortunately, we can't increase build minutes for Bitbucket standard Free plans (max 5 users). However, upon taking a look into your account, you may be eligible to receive a free academic Bitbucket Cloud subscription that is intended for members (students, professors, and so forth) of colleges and universities (criteria listed below). This may be a good direction for increasing build minutes.

            Special pricing is available for qualified Academic institutions. The following organizations are eligible for an Atlassian Academic License:

            Collegiate-level or higher educational institutions: vocational schools, junior colleges, colleges, universities, or scientific or technical schools that are accredited by a national accrediting agency.
            Administrative offices & boards of education: Provincial, district, regional, national and state administrative offices and authorities of the Educational Institutions defined above.
            K-12 administrative offices: K-12 educational institutions for administrative office use only (i.e. no K-12 student data may be submitted to the products or services).
            Public libraries
            Collegiate-level or higher home-school programs
            Research institutes that are affiliated with an accredited university.
            Teaching hospitals that are affiliated with an accredited university.
            Training and teaching organizations that are accredited by a statutory government qualifications body.
            You can apply and provide details of your academic institution by requesting a Bitbucket academic subscription. Our team will then review the application and get back to you. We can further proceed, once approved.

            I hope the above information helps.

            I have used the link to submit my information for an academic subscription.

            UPDATE: I am now on a University license.

            Show
            nfreese Nowlan Freese added a comment - - edited Regarding running out of build minutes, I contacted Bitbucket and this was the response: John commented: Hi Nowlan, Thank you for reaching out to Atlassian. My name is John and I'm from the Billing and Licensing team. I'll be happy to look into your request. Unfortunately, we can't increase build minutes for Bitbucket standard Free plans (max 5 users). However, upon taking a look into your account, you may be eligible to receive a free academic Bitbucket Cloud subscription that is intended for members (students, professors, and so forth) of colleges and universities (criteria listed below). This may be a good direction for increasing build minutes. Special pricing is available for qualified Academic institutions. The following organizations are eligible for an Atlassian Academic License: Collegiate-level or higher educational institutions: vocational schools, junior colleges, colleges, universities, or scientific or technical schools that are accredited by a national accrediting agency. Administrative offices & boards of education: Provincial, district, regional, national and state administrative offices and authorities of the Educational Institutions defined above. K-12 administrative offices: K-12 educational institutions for administrative office use only (i.e. no K-12 student data may be submitted to the products or services). Public libraries Collegiate-level or higher home-school programs Research institutes that are affiliated with an accredited university. Teaching hospitals that are affiliated with an accredited university. Training and teaching organizations that are accredited by a statutory government qualifications body. You can apply and provide details of your academic institution by requesting a Bitbucket academic subscription . Our team will then review the application and get back to you. We can further proceed, once approved. I hope the above information helps. I have used the link to submit my information for an academic subscription. UPDATE: I am now on a University license.
            Hide
            kgopu Kaushik Gopu added a comment - - edited
            Show
            kgopu Kaushik Gopu added a comment - - edited commits squashed Pull request submitted
            Hide
            nfreese Nowlan Freese added a comment -

            Tested on IGB 9.1.10 and main-JDK8. Everything is working correctly. On 9.1.10 with ProtAnnot 9.1.3 installed, I could see the update button in the App Manager to update to 9.1.4.

            Closing ticket.

            Show
            nfreese Nowlan Freese added a comment - Tested on IGB 9.1.10 and main-JDK8. Everything is working correctly. On 9.1.10 with ProtAnnot 9.1.3 installed, I could see the update button in the App Manager to update to 9.1.4. Closing ticket.

              People

              • Assignee:
                kgopu Kaushik Gopu
                Reporter:
                nfreese Nowlan Freese
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: