Community
Participate
Working Groups
I20130212-0811 org.eclipse.jdt.debug is split into two libraries jdi.jar and jdimodel.jar. The source for the libraries is stored in two separate source folders. When building the source bundle, the source for each librray should be placed into a separate folder (jdisrc and jdimodelsrc). In the CBI based build, the source for both libraries is being placed at the root of the source bundle. This breaks PDE plug-in import because we need to create separate source folders in the created project based on the libraries. With the source at the root of the jar we have no idea what files are actually source for the bundle and what library they belong to. Source attachments still work because JDT will fall back at looking at the root of the jar, but this will come with some performance penalty. For another example see org.eclipse.pde.build.source
(In reply to comment #0) > I20130212-0811 > > org.eclipse.jdt.debug is split into two libraries jdi.jar and jdimodel.jar. > The source for the libraries is stored in two separate source folders. Actually I see 4 source folders total for the two jars in [1] It seems that folders model/, jdi/, eval/ which make up jdimodel.jar are collapsed into one inside the source bundle. For bug 400956, I am trying to figure out the algorithm for naming the source root inside the source jar. Can you shed some light what PDE expects when importing? Is there some naming convention to be followed for the source roots based on the corresponding nested jar name? [1] http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/tree/org.eclipse.jdt.debug
(In reply to comment #1) > (In reply to comment #0) > > I20130212-0811 > > > > org.eclipse.jdt.debug is split into two libraries jdi.jar and jdimodel.jar. > > The source for the libraries is stored in two separate source folders. > > Actually I see 4 source folders total for the two jars in [1] > It seems that folders model/, jdi/, eval/ which make up jdimodel.jar are > collapsed into one inside the source bundle. > For bug 400956, I am trying to figure out the algorithm for naming the > source root inside the source jar. > Can you shed some light what PDE expects when importing? > > Is there some naming convention to be followed for the source roots based on > the corresponding nested jar name? > > > [1] > http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/tree/org.eclipse.jdt.debug The convention was to put the source for library foo.jar in a folder called foosrc. The naming convention only matters to PDE plug-in import, which can be modified. However, having source roots for the libraries (vs at bundle root) has performance impact. PDE gets the source roots from the manifest file in the source bundle. For example, here is the entry for jdt debug. Eclipse-SourceBundle: org.eclipse.jdt.debug;version="3.8.0.v20130121-1 85839";roots:="jdisrc,jdimodelsrc"
(In reply to comment #2) > (In reply to comment #1) > > (In reply to comment #0) > > > I20130212-0811 > > > > > > org.eclipse.jdt.debug is split into two libraries jdi.jar and jdimodel.jar. > > > The source for the libraries is stored in two separate source folders. > > > > Actually I see 4 source folders total for the two jars in [1] > > It seems that folders model/, jdi/, eval/ which make up jdimodel.jar are > > collapsed into one inside the source bundle. > > For bug 400956, I am trying to figure out the algorithm for naming the > > source root inside the source jar. > > Can you shed some light what PDE expects when importing? > > > > Is there some naming convention to be followed for the source roots based on > > the corresponding nested jar name? > > > > > > [1] > > http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/tree/org.eclipse.jdt.debug > > The convention was to put the source for library foo.jar in a folder called > foosrc. The naming convention only matters to PDE plug-in import, which can > be modified. However, having source roots for the libraries (vs at bundle > root) has performance impact. PDE gets the source roots from the manifest > file in the source bundle. For example, here is the entry for jdt debug. > > Eclipse-SourceBundle: org.eclipse.jdt.debug;version="3.8.0.v20130121-1 > 85839";roots:="jdisrc,jdimodelsrc" thanks Curtis. This matches what I had reverse-engineered from some example source bundles and implemented with bug 400956 now
@Thanh you need to configure distinctSourceRoots=true [1] <plugin> <groupId>org.eclipse.tycho</groupId> <artifactId>tycho-source-plugin</artifactId> <version>${tycho-version}</version> <configuration> <distinctSourceRoots>true</distinctSourceRoots> </configuration> </plugin> in the parent pom to get desired behaviour for nested jar sources. [1] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=e0a74423888b26d8ae968c5757c3a46874c5ac89
(In reply to comment #4) > @Thanh you need to configure distinctSourceRoots=true [1] > I released this into master: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=96bb6ad3a50d9998eff6c3246cfcdcf6c8c68788 We should port this back to 3.8 and 4.2 I think.
(In reply to comment #5) > (In reply to comment #4) > > @Thanh you need to configure distinctSourceRoots=true [1] > > > > I released this into master: > http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/ > commit/?id=96bb6ad3a50d9998eff6c3246cfcdcf6c8c68788 > > > We should port this back to 3.8 and 4.2 I think. Yes, I suggest you "clone" this bug, and set its target to the 4.2.2+ so we can keep better track. (And, to me, 422+ means both 3.8.2 and 4.2.2, if there's a difference in streams, except for a few rare cases).
(In reply to comment #6) > (And, to me, 422+ means both 3.8.2 and 4.2.2, if > there's a difference in streams, except for a few rare cases). No, 3.8.2+ means that. 4.2.2+ only means 4.2.2 maintenance.
(In reply to comment #7) > (In reply to comment #6) > > (And, to me, 422+ means both 3.8.2 and 4.2.2, if > > there's a difference in streams, except for a few rare cases). > > No, 3.8.2+ means that. 4.2.2+ only means 4.2.2 maintenance. Or, if that's too confusing, one can also have two separate bugs. Both approaches are taken by different components.
(In reply to comment #6) > (In reply to comment #5) > > We should port this back to 3.8 and 4.2 I think. > > Yes, I suggest you "clone" this bug, and set its target to the 4.2.2+ so we > can keep better track. (And, to me, 422+ means both 3.8.2 and 4.2.2, if > there's a difference in streams, except for a few rare cases). Forgot to mention I created Bug 403256 as a clone of this bug.