Community
Participate
Working Groups
Up to now, the SWT documentation cannot be retrieved independently from the other platform documentation. Up to now, this was not big problem, as SWT was always versioned similar to the other platform plug-ins. Due to the current split into 3.8 and 4.2, one has to decide for a specific version of platform documentation (i.e. 3.8 or 4.2; or specify a version range of [3.8.0, 5.0.0) as an alternative), even if only the SWT documentation within is of interest. To clarify my use case: I have a doc bundle that is dependent on SWT and the SWT documentation (to generate javadoc and link to SWT javadoc). I want to specify an optional (as only needed to compile-time) plug-in dependency to the bundle (currently org.eclipse.platform.doc.isv), which contains the SWT javadoc for this purpose. If the SWT documentation would be available in its own bundle, I could specify dependencies to org.eclipse.swt and org.eclipse.swt.doc.isv in the same version. Now, I have to specify dependencies to org.eclipse.swt and org.eclipse.platform.doc.isv, and I have to allow a version range of [3.8.0, 5.0.0) to enable, that I can build against a 3.8 and 4.2 target respectively. I think it would be better to separate out the SWT documentation into an own org.eclipse.swt.doc.isv bundle and to version it according to the SWT bundle.
I'm not fully understanding the problem with the version ranges. Why does it matter if the doc version range matches the swt version range? I.e., why can't you specify [3.8,4.0) for SWT, and [3.8,5.0) for the doc bundle?
That's exactly what I do. IMHO it would be nicer to have: org.eclipse.swt [3.8,4.0) org.eclipse.swt.doc.isv [3.8,4.0) Also, my production plug-in does not have any dependencies to the eclipse platform (only to swt), and I think it would be nicer if the related doc bundle wouldn't have to either...
