Community
Participate
Working Groups
Since 3.0, runtime supports running plugins in a jar'ed form (equivalent of zipping the content of a plugin folder), and a derived form of this where the class files are available as siblings of the plugin.xml. Since 3.1, first class tooling for those two cases are being added, however some support would be required from the jdt team (I think Jerome) to be able to find the source which would be a zip in a jar. For example: P1.jar contains plugin.xml (classpath is ".") a/b/A.class a/b/B.class src.zip (<-- a zip containing the source of A.class and B.class) The motivation for asking you this support is the following: If we have the source directly intermixed with the binaries then the java files and other resources will appear on the classpath at runtime.
Pascal, not if the source is in a src/ folder in P1.jar (unless I'm missing something).
Since when the classpath is "." the jar itself is on the classpath, everything in the jar will be on the classpath, including what's in the src folder.
Thanks Pascal. I see. So the less files we have the better. Having the source zipped up would alleviate the problem.
Seems like this topic came up in another bug report but can't place it... Anyway, why is it bad to have the source directly intermingled with the .class files? They would show up as resources sure but people would not really go looking for them (or, if they did, they would expect them to be there). Expecting or enforcing that the source go in src.zip at the root similarly shows up as a resource and may well conflict with a real resource. Observation: the usecase for including source in the plugin jar is sketchy. True some people will want to do that but I suspect most will not try to ship their product this way. In short, if the necessary function is easy to do and makes sense, great. Otherwise, I would not bend over backwards for this.
My concern here is people who don't have a releng team. That is, they use the Plugin export wizard to build their plugins and have no clue how the pde.core.source extension works. Having/enforcing source features is certainly not what they want here. These people put the source in the same plugin as their binary when developing. If they are unable to put the source in the same JAR as the plugin (in some form or another), PDE will not be able to attach source to their JAR entries in the classpath, and good luck trying to debug then. This JAR'ed bundle format will thus be undesirable to people, as their self- hosting experience would become a nightmare without source attachment.
Having a src.zip inside will make the zip file on the classpath anyway... Also, I don't think ZipFiles support reaching entries inside nested zips. So I don't think it would be an easy thing to implement, would likely need to expand the plugin jar, which isn't what you are looking here.
The only thing you can do to a Zip is to reach direct entries, and open an input stream onto them. Then if you want to deal with a nested Zip, you need first to read it entirely... would be deadly, plus would force us to read it entirely so as to cache information for performance reasons (as opposed to lazy approach we currently implement). I would rather agree with Jeff that we should stick to intermixing sources and binaries. Separating sources in a source subfolder would make the distinction quite clear. Alternatively, why not constructing 2 JARs per plugin ? One for binaries, one for sources (optional). Then you can better control what you use and when.
Having two jars would be less than optimal. Remember, the usecase involved here is where we are shipping the whole plugin as one JAR. plugin.xml and all. So we don't really know what to do with this other source jar (how would we handle it?). Extracting a source zip from the plugin is certainly feasible (we have several examples of this support) but is none the less a pain in the butt. Cache management, etc etc. So, I am for putting the source in the plugin jar itself. Intermingled or in some root dir (e.g., src)? I'm not fussed either way. Suspect that JDT can handle either. Perhaps we should support both. For example, if I get a third party jar and inject the right OSGi manifest entries I can convert it into a bundle. If the original jar had source it might be intermingled or in a separate dir. Wonder what the common practice (if any) is here? Note that in general this model (including the source in the plugin at all) should really not be encouraged. I agree with Wassim that not everyone will be able to figure out the source extensions and the idea of source features etc but including the source in the binary distribution is not very spec effective on disk or at runtime (the jar table is bigger).
JDT/Core supports arbitrary source root folders in a JAR, and it doesn't need to be told where sources are located, it will perform some inference when no indication is given (and supports multiple source folders).
A summary: - The "too much stuff on the classpath" problem is non-existent in products, since nobody ships a commercial product with source. - Source attachments are pretty important during self-hosting (e.g. classpath/debugging, etc. )and in non-commercial settings where you package a plugin with/without source and send it to a friend. Here is my suggestion: - JDT does nothing. - PDE/Build addresses bug 76436 by packaging source at the root of the JAR. - PDE/UI does nothing since we already use the JAR itself as its own source attachment.
I agree with the summary except that it will requires to PDE Build to "bend over backwards for this", but it will be considered in the long term.
Just to clarify, does "packaging source at the root of the jar" mean intermingling the source with the .class files?
yes.
Why not putting them in separate src/ folder when packaging ?
We could that too. I'm indifferent.
Philippe, in case of nested zip, why can't you extract the file in a temporary place and use it from here? Note Platform.asLocalURL() will do the extraction.
asLocalURL won't work for it since the bundles of interest (the ones with the source) are in the target. asLocalURL would be executed by the dev Eclipse and so would not have the target bundles as bundles.
This request has an obvious solution which doesn't require any change in JDT/Core. Ok to close ?
Deferring post 3.1
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
