Community
Participate
Working Groups
Re-exporting other bundles should be avoided. If the API of a re-exported bundle changes this always affects the bundle re-exporting. There should not be a need to do this except for maintaining backwards compatibility when bundles are split into smaller units (which should not apply to R4E, yet). It's a good practice and widely used Eclipse convention to add an "internal" segment to the name of packages that are not considered public API. Additionally, these packages should be marked x-internal in the manifest. More background on API conventions can be found on the Mylyn wiki at http://wiki.eclipse.org/Mylyn_Integrator_Reference#Using_Internals or under "API Policy" at http://www.eclipse.org/indigo/planning/EclipseSimultaneousRelease.php . http://wiki.eclipse.org/Evolving_Java-based_APIs is also an excellent source for information on specifying Java APIs.
Steffen, could you please point me to an example of bundle re-exporting..
/org.eclipse.mylyn.reviews.r4e.core/META-INF/MANIFEST.MF: Require-Bundle: org.eclipse.core.runtime, org.eclipse.emf.ecore;visibility:=reexport, org.eclipse.emf.ecore.xmi;visibility:=reexport, org.eclipse.mylyn.reviews.frame.core;visibility:=reexport,
Re-exports should now all be gone from MANIFESTs. Moving to the next release cycle to consider remaining portion of this bug.
* For the re-export, there is one left, It can be fixed by 1) making the UI depend on EMF, 2) remove emf elements from the API. Option 2 is the ideal, however not making it to 0.8 * Re-factoring to use internal within the package name is tracked with Bug 346560
Correction: reexports are already removed as the UI has other dependencies with EMF this bug will be closed since the re-factoring of packages to internal will be tracked on Bug 346560
