Community
Participate
Working Groups
When dealing with JAR'ed bundles, we need to clearly define where the source is going to be located for PDE to be able to: 1. export plugins in this format with/without source. 2. locate and attach source to JARs when computing classpaths. Here are some initial suggestions that came up in a recent discussion with Jeff: 1. If the source is to be packaged inside the JAR alongide the class files, they will appear at the root. This way, the JAR itself can be used as the source attachment zip. 2. If the source is shipped separately (i.e. via the pde.core.source extension point), then the source zip will appear in the same location as it does now but it will be called 'srczip'. As a quick test to see what PDE/Build currently names source zips for bundles with a '.' as a library name, the name of the zip is '@dotsrc.zip', which is not a good name.
How do you handle the case 1) for regular plugins? Why is @dotsrc.zip a problematic name?
Regarding 1, as it will appear in tomorrow's I-build, I use the JAR itself as the source attachment. This will only work if the source is at the root of the JAR. Is that what you do when you build such a JAR with source? Is this already supported by PDE/build? Is this the story that we are going with? 2. Using @dot as prefix for source zips in just weird :-) I suggest a plain "src.zip".
To actually answer Pascal's question re 1., here is how PDE searches for source zips for regular plugins: given a JAR named 'xyz.jar', we first look for a sibling zip file named 'xyzsrc.zip'. If we find it, we attach it. if not, then we look through all the source code locations (i.e. the ones extending the pde.core.source extension point), and we look for the zip file called 'xyzsrc.zip' that would be located in a com.example.xyz_1.0.0 directory. Also, I just double-checked with Philippe to see if JDT understands ZIPs inside JARs when it comes to source attachments and it is no. So as we suspected, when building a JAR'ed bundle with source, the source *.java files must remain in a directory structure inside the JAR. I suggest the *.java files be in a folder called 'src' or the like inside the JAR. This will allow me to figure out quickly if the source is packaged in the JAR itself or if I should start looking for it elsewhere.
See discussion bug #76653.
*** Bug 78525 has been marked as a duplicate of this bug. ***
To answer Jeff's question regarding where source zips would go if source is packaged separately, here is my suggestion: Suppose the jar'd plugin is org.eclipse.ui, then its source will be in: <eclipse_install>/org.eclipse.platform_source_3.1.0/src/org.eclipse.ui_3.1.0/sr c.zip Note that the source plugins constituting the source features could not be JAR'd plugins themselves as we will run into this whole zip in a Jar problem with JDT.
This has been fixed in the jared_plugins branch
Note that there is a PDE UI element to this. DJ was looking at it. Not sure if there is a separate bug. Adding DJ to the fun
See bug 86561.
The branch has been merged back in HEAD.
question: do you support exporting a JAR'd plugin with source inside?
Common! :-)
Reopening because the current solution for source inside a JAR that a '.' classpath is not good. If I choose to export such a plugin in a JAR format, a source zip named 'src.zip' gets generated at the root of the JAR. As you know, this is useless because JDT does not support this nesting when it comes to source attachments (bug 76653). As suggested in bug 76653, when the source is packaged in this JAR, it has to be in unzipped form so that JDT could attach the source when I use the JAR itself as its ows source attachment. It's also better if the source is not at the root of the JAR, but instead in a 'src/' subdirectory of the JAR.
The problem is real, the solution we can think of now is too complex to be implemented in a time that would not require us to drop more important features somewhere else. Deferring to M7.
Would this work? For a given plugin, say org.eclipse.jface.text_3.1.0.jar, zip up the source in org.eclipse.jface.text_3.1.0src.zip. The two files would be siblings in the same directory (plugins). Then if it works as described in comment #3, PDE would just automatically find the source, right?
plugins are to be self contained. Either in a dir or a jar. You could of course have a plugin that contains source for another plugin on an individual basis. This may cause undue bloat. The source lookup mechansim would have to be tweaked to know to look in this new place. We would not know how to manage having a src zip file sitting around. For example, what would update do with it?
Just to give you another data point, in our internal build process at SAS we build each jar twice, one with -g and source code (for developers), one without (for customers). .java and .class files are intermingled in the same subdirs inside the developer jar. This is for a closed source product though. I don't think it would work well for an open source product because it doubles the builds and administration, and many more people will be using the source. Most open source projects I've seen always compile with -g and put the source in a separate archive. Then they have a binary download that has all the jars with no source, and a source download that has the source only. This is the way Apache does it and close to the way Eclipse has done it up to now.
Fixed in HEAD. The fix consists in unzipping the src.zip created by the plugin build script when the source is gathered in the assemble scripts.
