IvyDE
  1. IvyDE
  2. IVYDE-350

Workspace resolver seems to ignore setting "Read OSGi metadata"

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.2.0.final
    • Fix Version/s: None
    • Component/s: workspace resolver
    • Labels:
      None
    • Environment:

      Eclipse 4.2 (Juno), Java 1.6, Windows

      Description

      The problem happened with trunk build from builds.apache.org (https://builds.apache.org/job/IvyDE/268/) installed via update site for trunk builds.

      I'm developing two Eclipse plugins A and B in the same workspace. B depends on A. I use an IvyDE classpath container instead of the PDE one for both plugin projects. A has two packages: api (which is exported, i.e. listed in the plugin's manifest in section "Export-Package") and impl (which is not exported, i.e. not listed in the plugin's manifest).

      Now it is possible to access classes of package impl of plugin A from
      the project of plugin B without getting error markers in Eclipse. After
      setting the checkbox "Read OSGi metadata" on the global preferences of
      IvyDE I expected that this will cause IvyDE to setup the OSGi visibility
      constraints but the code in B that accesses the "hidden" classes from A
      is still not marked with an error. If I remove the IvyDE classpath
      containers from the plugin projects and use the PDE classpath container
      the error markers appear.

        Activity

        Riccardo Foschia created issue -
        Hide
        Nicolas Lalevée added a comment -

        After looking further into it, it doesn't work indeed, it is not supported.

        If anyone interested to contribute a patch, see IvyClasspathContainerMapper.java:

            private IAccessRule[] getAccessRules(IJavaProject javaProject) {
                if (!osgiAvailable || !classpathSetup.isReadOSGiMetadata()) {
                    return null;
                }
                // TODO
                // Nicolas: AFAIU, the access rules seems to have to be set on the imported project itself
                // rather than filtering here, afterwards
                return null;
            }
        
        Show
        Nicolas Lalevée added a comment - After looking further into it, it doesn't work indeed, it is not supported. If anyone interested to contribute a patch, see IvyClasspathContainerMapper.java: private IAccessRule[] getAccessRules(IJavaProject javaProject) { if (!osgiAvailable || !classpathSetup.isReadOSGiMetadata()) { return null ; } // TODO // Nicolas: AFAIU, the access rules seems to have to be set on the imported project itself // rather than filtering here, afterwards return null ; }
        Nicolas Lalevée made changes -
        Field Original Value New Value
        Issue Type Bug [ 1 ] Improvement [ 4 ]

          People

          • Assignee:
            Unassigned
            Reporter:
            Riccardo Foschia
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development