Community
Participate
Working Groups
When having a reference on another project you "see" all the sources that are in this referenced projects. It appears that in projects you can have API sources and CORE sources (generally in 2 different src folders) because only the target packaging of the project defines what is public and what is not in the end. (by external tool) I would like to have to possibily in the "Order and export" tab of the project properties->java build path, to uncheck some of the source folders so that referencing projects would not see these classes. This can let me hide core classes and have a clean dependency between projects. One could say the solution is to create 2 different projects. The problem is that I need another one to gather both api and core classes for packaging purposes and it's not possible in Eclipse to have nested projects (is it ??) Thanks.
Created attachment 3054 [details] What to uncheck to allow the described feature
This is something we were looking for 2.1, but it got deferred post 2.1. Will reconsider for 2.2. Glad we aren't the only ones waiting for such a feature.
may be a stupid question but ... is there any way to influence dev team to have this in the near future included in 2.1?
Considering for 3.1
*** Bug 33718 has been marked as a duplicate of this bug. ***
*** Bug 46362 has been marked as a duplicate of this bug. ***
*** Bug 72943 has been marked as a duplicate of this bug. ***
Here is what we propose (from build notes): =============================== Introduced access restrictions so as to better enforce API contracts across components. Problem: Libraries are usually packaged to contain both API for compile-time and implementation for runtime; and thus expose a superset of the API contract to client programs, allowing them to make forbidden assumptions on internals (a typical restriction for Eclipse developpers is to not use internal classes from prerequisite plug-ins). One solution for solving this issue is to separate the API from its implementation into 2 distinct libraries (compile-time/runtime) and then use the classpath rules to only include the API portion on the classpath for compiling. However, this usually proves to be unrealistic, since the API is often mixed with some implementation aspects (not officially part of the API) which are carrying references to its internals (supertype hierarchy, field or method signatures). When it happens, then the compiler needs the implementation also to be on the classpath in order to resolve all signatures appropriately; which goes back to the original problem of exposing too much to unaware clients. Instead, we allowed classpath rules to be associated with some import restrictions so as to select portions of prerequisite projects or libraries which are legal to use inside this project. Access restrictions are expressed as inclusion/exclusion rules on classpath entries (using Ant fileset notation for discriminating on package and/or file names, e.g. excluding='**/internal/' would exclude all types defined any internal package), and can be associated to project, library, classpath variable or classpath container classpath entries. Note that restrictions are automatically combined along a classpath chain. For instance, if a classpath container entry is associated with some restrictions, then when resolved to a set of entries, these will automatically inherit the container restrictions (and could still provide further custom restrictions on a per entry basis). When a forbidden reference to a restricted type is detected, the compiler will issue a problem which severity can be controlled by JavaCore preference "org.eclipse.jdt.core.compiler.problem.forbiddenReference". Corresponding problem marker ID is IProblem.ForbiddenReference. * COMPILER / Reporting Forbidden Reference to Type with Restricted Access * When enabled, the compiler will issue an error or a warning when referring to a type with restricted access, as defined according * to the access restriction specifications. * - option id: "org.eclipse.jdt.core.compiler.problem.forbiddenReference" * - possible values: { "error", "warning", "ignore" } * - default: "ignore" In order to challenge this new functionality before leveraged in UI or PDE, Eclipse developpers need to perform the following two actions: 1. edit some .classpath file to exclude all types located in "**/internal/" packages from prerequisites; i.e. replace line <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/> with <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins" excluding="**/internal/"/> 2. enable compiler warning for forbidden references, i.e. add the following line to the workspace default preferences located in: <workspace>\.metadata\.plugins\org.eclipse.core.runtime\.settings\org.eclipse.jdt.core.prefs org.eclipse.jdt.core.compiler.problem.forbiddenReference=warning Note: alternatively, it could be specified on a per project basis, by adding line to <project>/.settings/org.eclipse.jdt.core.prefs.
Regression tests got added both for builder and reconciler.
Verified for 3.1M3 with build I200411040100
*** Bug 67340 has been marked as a duplicate of this bug. ***
I don't think this fixes the original intent (see screenshot). The fix allows "access rules" to be specified, but still includes everything on the classpath at runtime. The original proposal was to selectively exclude *output folders* from being exported to dependent projects.
