| Re: [jdt-dev] IAccessRules on transitive exports |
|
Thanks Jay for your response. I didn’t raise a bug to begin with as I wasn’t sure if it was a bug, by design, or else if I hadn’t implemented it properly. I did some digging into the source code and found that `IAccessRule.ignoreIfBetter()` is used in the compiler “INameEnvironment” implementation, which on the surface of it looked like
it should do the right thing. I will see if I can do a bug report with a minimal reproducing example. Blessings,
Chief Executive Officer
Greek Welfare Centre SA St Philothei Greek Orthodox Archdiocese of Australia 213 Henley Beach Road TORRENSVILLE SA 5031 Phone: (08) 8212 5100 From: jdt-dev [mailto:jdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Jayaprakash Arthanareeswaran I am not an expert in this area, but I don’t see a lot of code in jdt.core around
IGNORE_IF_BETTER, T just some code in ClasspathEntry that encodes and decodes this value and nothing much. This could be a bug IMO, unless someone can point otherwise. Can you raise a bug so we can
understand this further and work on it? Regards, Jay From: jdt-dev <jdt-dev-bounces@xxxxxxxxxxx>
On Behalf Of Fr Jeremy Krieg Hi team, I pray that you are all well. Executive Summary: I'm having trouble with a custom classpath container that implements access rules on a transitive
dependency. The dependency transitively included via two separate projects. Each of
ZjQcmQRYFpfptBannerStart
ZjQcmQRYFpfptBannerEnd Hi team, I pray that you are all well. Executive Summary: I'm having trouble with a custom classpath container that implements access rules on a transitive dependency. The dependency transitively included via two separate projects.
Each of those projects has different access rules, and despite the fact that I'm specifying K_IGNORE_IF_BETTER, it seems that the access rules of the first get applied to the transitive dependency and the second's get ignored (even if they are "better" = more
accessible). Detail: My workspace has: A jar library osgi.core, which has a set of public packages; Project A, which has osgi.core as its sole dependency, and no classes of its own, but embeds package org.osgi.framework as part of its public API and org.osgi.util.tracker
as a non-public package. Project B, which also has osgi.core as a dependency, but which doesn't embed any packages from it. What I want is for the osgi.core library to be made visible to transitive dependencies, but only the relevant subset of packages that is referenced by the "in-transit" project.
Ie, suppose project D has only project A on its build path - it should be able to see package org.osgi.framework without warnings, org.osgi.util.tracker with warnings, and all other packages of osgi.core should generate errors. Likewise, if it has project
B on its build path, it shouldn't be able to see any of the packages of osgi.core without generating an error. I have implemented a scheme that works fine using Eclipse 2020-06: -Project A's custom container adds osgi.core using JavaCore.newLibraryEntry(), with the export flag set to "true". Likewise for project B. -When Project D has Project A as the sole entry on its build path, the container adds it using JavaCore.newProjectEntry(), export set to "true", combine access rules set to
"true", org.osgi.framework with an IAccessRule of K_ACCESSIBLE, org.osgi.util.tracker with K_DISCOURAGED | K_IGNORE_IF_BETTER, and a final default rule of "**" with K_NON_ACCESSIBLE | K_IGNORE_IF_BETTER. This produces the expected result - classes in project
D can see classes in org.osgi.framework without warning, can see org.osgi.util.tracker with a warning, and an attempt to access any other package in osgi.core generates an error. -Likewise, when Project D has Project A as the sole entry, the container adds it with JavaCore.newProjectEntry(), export true, combine rules true, and a single default rule
of "**" with K_NON_ACCESSIBLE | K_IGNORE_IF_BETTER. This too works as expected. What is not expected is when I try to add both project A and B to the build path at the same time. In this case, instead of the visibility into the transitive dependency osgi.core
being determined by the most lenient access rules (which is what I understood "IGNORE_IF_BETTER" to mean), it is determined by the access rules of whichever dependency appears first on the build path. Ie, if project A comes first, the classes of project D
can see org.osgi.framework and (with a warning) org.osgi.util.tracker - however, if project B comes first on the build path, then none of the org.osgi packages is osgi.core are visible to project D. Am I missing something here? Have I misconfigured it? Does IGNORE_IF_BETTER not work the way that I expect it? Or is there a bug? Any light that anyone could shed on this would be much appreciated. Blessings,
Chief Executive Officer Greek Welfare Centre SA St Philothei Greek Orthodox Archdiocese of Australia 213 Henley Beach Road TORRENSVILLE SA 5031 Phone: (08) 8212 5100 |
