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

Investigate osgi.cmpn error

        Details

        • Type: Task
        • Status: Closed (View Workflow)
        • Priority: Major
        • Resolution: Done
        • Affects Version/s: None
        • Fix Version/s: None
        • Labels:
          None

          Description

          Situation: Unable to resolve osgi.cmpn. This is interesting as the osgi.cmpn artifact version 6.0.0 was added for this branch (to match the osgi.core version 6.0.0 that replaced bndlib). The osgi.cmpn artifact is included in the master branch of IGB, but in a previous version with the artifact id org.osgi.compendium. Unclear why it is not working, but the "must.not.resolve=*" appears in every error that mentions the osgi.cmpn artifact.

          14:49:00.362 [main] ERROR com.affymetrix.main.OSGiHandler - Unable to resolve osgi.cmpn [74](R 74.0): missing requirement [osgi.cmpn [74](R 74.0)] osgi.compile.time.only; (&(must.not.resolve=*)(!(must.not.resolve=*))) Unresolved requirements: [[osgi.cmpn [74](R 74.0)] osgi.compile.time.only; (&(must.not.resolve=*)(!(must.not.resolve=*)))]

          Task: Determine why this error is appearing, if it can be fixed then update this ticket as needed.

            Attachments

              Issue Links

              relates to

              Task - A task that needs to be done. IGBF-3275 Investigate the OSGI wiring issue

              • Major - Major loss of function.
              • Closed

                Activity

                Ascending order - Click to sort in descending order
                Hide
                Permalink
                nfreese Nowlan Freese added a comment - - edited

                stackoverflow:
                https://stackoverflow.com/questions/59563368/maven-tycho-cannot-resolve-osgi-core-bundle

                https://stackoverflow.com/questions/37421604/how-to-create-a-working-osgi-bundle-with-optional-package-resolution

                Show
                nfreese Nowlan Freese added a comment - - edited stackoverflow: https://stackoverflow.com/questions/59563368/maven-tycho-cannot-resolve-osgi-core-bundle https://stackoverflow.com/questions/37421604/how-to-create-a-working-osgi-bundle-with-optional-package-resolution
                Hide
                Permalink
                nfreese Nowlan Freese added a comment - - edited

                Q and A on OSGI 6 release by BJ Hargrave: https://blog.osgi.org/2015/08/release-6-of-osgi-compendium-osgi.html

                Question: It appears that the compendium jar you uploaded has a manifest entry that indicates it is only intended to be used at compile-time-only. Is this intentional? Is there a different jar I should be deploying at runtime?

                Answer: Yes, it is intentional. The compendium jar was never meant to be used at runtime but people abused it anyway. So for R6 we have added an unresolvable requirement to prevent this. The latest Felix Http implementation (used as the RI in OSGi), already includes the OSGi http packages.

                Don't install osgi.cmpn as a bundle. It wont resolve.

                Blog discussing BJ Hargrave's answers: https://groups.google.com/g/bndtools-users/c/DLY0LdJ5dNI

                Another blog: https://bnd.discourse.group/t/resolve-issue-using-biz-aqute-tester-junit-platform/284

                You should not use osgi.cmpn any more. It is recommended to use the individual API jars for each spec you use. To prevent people from installing (and resolving) osgi.cmpn, its manifest requires the osgi.unresolvable capability which the resolver can never satisfy.

                If you must use osgi.cmpn as a compile scope dependency, then you would need to tell the resolved to never use it.

                The best solution is to completely avoid osgi.cmpn

                Note: I think Karthik had found other blogs that discussed the same idea. Effectively they are pushing for people to avoid osgi.cmpn.

                From Karthik: "OSGI compendium (osgi.cmpn & osgi.compendium) is an aggregate API artifact of OSGI which is not available in Maven any more. We upgraded the version of compendium from 5 to 6 and 7 to solve the errors in the annotations (Symbol not found error) but it did not solve it. For our purposes, using individual artifacts for annotations as well as the wiring issues seems to be a better option."

                Show
                nfreese Nowlan Freese added a comment - - edited Q and A on OSGI 6 release by BJ Hargrave: https://blog.osgi.org/2015/08/release-6-of-osgi-compendium-osgi.html Question : It appears that the compendium jar you uploaded has a manifest entry that indicates it is only intended to be used at compile-time-only. Is this intentional? Is there a different jar I should be deploying at runtime? Answer : Yes, it is intentional. The compendium jar was never meant to be used at runtime but people abused it anyway. So for R6 we have added an unresolvable requirement to prevent this. The latest Felix Http implementation (used as the RI in OSGi), already includes the OSGi http packages. Don't install osgi.cmpn as a bundle. It wont resolve. Blog discussing BJ Hargrave's answers: https://groups.google.com/g/bndtools-users/c/DLY0LdJ5dNI Another blog: https://bnd.discourse.group/t/resolve-issue-using-biz-aqute-tester-junit-platform/284 You should not use osgi.cmpn any more. It is recommended to use the individual API jars for each spec you use. To prevent people from installing (and resolving) osgi.cmpn, its manifest requires the osgi.unresolvable capability which the resolver can never satisfy. If you must use osgi.cmpn as a compile scope dependency, then you would need to tell the resolved to never use it. The best solution is to completely avoid osgi.cmpn Note: I think Karthik had found other blogs that discussed the same idea. Effectively they are pushing for people to avoid osgi.cmpn. From Karthik: "OSGI compendium (osgi.cmpn & osgi.compendium) is an aggregate API artifact of OSGI which is not available in Maven any more. We upgraded the version of compendium from 5 to 6 and 7 to solve the errors in the annotations (Symbol not found error) but it did not solve it. For our purposes, using individual artifacts for annotations as well as the wiring issues seems to be a better option."
                Hide
                Permalink
                nfreese Nowlan Freese added a comment -

                There are two commits:

                Reversion of commit ae6d5bc: https://bitbucket.org/nfreese/nowlanfork-igb/commits/5aafa33f854d1319f4efc23eb764cd884caa798a

                Remove remaining references to osgi compendium: https://bitbucket.org/nfreese/nowlanfork-igb/commits/c8d6a9338e1803f6e243f1ec126d88625f513aa4

                In one of my previous commits I had replaced bndlib with newer versions of osgi core and osgi compendium. While this seemed to satisfy the requirements for the annotations, it caused the error with osgi cmpn discussed above. I reverted the commit so that bndlib would be used instead. I then removed any remaining references to osgi compendium. IGB is able to build (mvn clean install) and I am no longer seeing the osgi.cmpn error when attempting to run the IGB jar.

                Show
                nfreese Nowlan Freese added a comment - There are two commits: Reversion of commit ae6d5bc: https://bitbucket.org/nfreese/nowlanfork-igb/commits/5aafa33f854d1319f4efc23eb764cd884caa798a Remove remaining references to osgi compendium: https://bitbucket.org/nfreese/nowlanfork-igb/commits/c8d6a9338e1803f6e243f1ec126d88625f513aa4 In one of my previous commits I had replaced bndlib with newer versions of osgi core and osgi compendium. While this seemed to satisfy the requirements for the annotations, it caused the error with osgi cmpn discussed above. I reverted the commit so that bndlib would be used instead. I then removed any remaining references to osgi compendium. IGB is able to build (mvn clean install) and I am no longer seeing the osgi.cmpn error when attempting to run the IGB jar.
                Hide
                Permalink
                nfreese Nowlan Freese added a comment -

                To test: Pull the latest changes from the IGBF-3275 branch and build IGB.

                Show
                nfreese Nowlan Freese added a comment - To test: Pull the latest changes from the IGBF-3275 branch and build IGB.
                Hide
                Permalink
                karthik Karthik Raveendran added a comment -

                Test Passes. I was able to build IGB with the new changes.

                Show
                karthik Karthik Raveendran added a comment - Test Passes. I was able to build IGB with the new changes.

                  People

                  • Assignee:
                    nfreese Nowlan Freese
                    Reporter:
                    nfreese Nowlan Freese
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    2 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: