Bug 233068 - [api][breaking] tm.discovery.edit should not reexport emf.edit in its Manifest
Summary: [api][breaking] tm.discovery.edit should not reexport emf.edit in its Manifest
Status: RESOLVED FIXED
Alias: None
Product: Target Management
Classification: Tools
Component: Core (show other bugs)
Version: 3.0   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: 3.0 RC2   Edit
Assignee: Martin Oberhuber CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords: api
Depends on:
Blocks:
 
Reported: 2008-05-20 16:26 EDT by Martin Oberhuber CLA
Modified: 2008-05-22 10:34 EDT (History)
3 users (show)

See Also:
mober.at+eclipse: pmc_approved+
javier.montalvoorus: review+

Attachments
Patch fixing the Discovery reexport (3.22 KB, patch)
2008-05-21 15:26 EDT, Martin Oberhuber CLA 		no flags Details | Diff
Patch fixing the FTP reexport (2.52 KB, patch)
2008-05-21 15:31 EDT, Martin Oberhuber CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Oberhuber CLA 2008-05-20 16:26:54 EDT 
From bug 232787 comment 14:

Reexporting bundles gives troubles with versioning, and is not really in line with OSGi strategies. We should remove the
    visibility:="reexport"
statement from org.eclipse.tm.discovery.edit/Manifest.mf

Committers please vote +1 here on the bug if you agree or -1 and explain if you disagree. I'm +1 for it. Javier I'd particularly like your vote as the initial committer of the bundle.
Comment 1 Martin Oberhuber CLA 2008-05-20 16:28:32 EDT 
Note that we'll need to rev up tm.discovery.edit from 2.0.100 to 3.0.0 if we make the change since it's a breaking change. Consequently, the discovery feature will also need to go from 2.0.100 to 3.0.0

But I truly cannot see what sense it should make to reexport the EMF stuff that's totally alien to the project.
Comment 2 David Dykstal CLA 2008-05-20 17:10:08 EDT 
+1. In general re-exporting should probably be something we don't want to do.
Comment 3 Radoslav Gerganov CLA 2008-05-21 02:38:20 EDT 
+1
Comment 4 Uwe Stieber CLA 2008-05-21 02:56:02 EDT 
+1.

If we can, better avoid "weak" dependencies by re-exporting. Might be not always applicable, but at least a good goal to go for.
Comment 5 Martin Oberhuber CLA 2008-05-21 15:26:19 EDT 
Created attachment 101350 [details]
Patch fixing the Discovery reexport

Attached patch fixes the Discovery Reexport.

Note that I've also cleaned up the deprecated "Eclipse-LazyStart:false" entry in the Manifest, and had to rev up the discovery.model.edit version to 3.0 because taking away the reexport is a breaking change.

Patch is committed.
Comment 6 Martin Oberhuber CLA 2008-05-21 15:27:41 EDT 
Patch committed:
[233068][api][breaking] Get rid of EMF reexport in org.eclipse.tm.discovery.model.edit
Comment 7 Martin Oberhuber CLA 2008-05-21 15:31:29 EDT 
Created attachment 101352 [details]
Patch fixing the FTP reexport

A similar problem is in rse.services.files.ftp, which reexports Apache Commons Net. Attached patch gets rid of the reexport.
Comment 8 Martin Oberhuber CLA 2008-05-21 15:32:44 EDT 
2nd patch committed:
[233068][api][breaking] Get rid of Commons.Net reexport in org.eclipse.rse.services.files.ftp

Bug is fixed. DaveD, Rado, Javier -- can any of you place an official bugzilla +1 on a Review flag, thanks.
Comment 9 Martin Oberhuber CLA 2008-05-22 10:34:01 EDT 
Summary of API Changes:
-----------------------
* Commons.net and EMF are no longer reexported by the rse.services.ftp and 
  tm.discovery.model.edit bundles, respectively.

Migration Notes:
Clients who see build problem due to missing references from org.apache.commons.net or EMF, need to edit their MANIFEST.MF file and add the relevant Require-bundle: markup there.