RTC representation of "svn:externals"

Joef Huang (46●11●4) | asked May 06 '11, 5:41 p.m.
edited Oct 13 '17, 3:11 p.m. by David Lafreniere (4.8k●7)

Hello,

SVN allows user to piece together files from different repositories into one Eclipse project, by using the "svn:externals" attribute.

In RTC, when trying to load files from different components into one Eclipse project, there is an error complaining about sandbox overlapping.

Is there a way in RTC that allows users to piece together files from different components into one Eclipse project? (similar as what SVN provides)

Thanks.

4 answers

Most liked answers ↑|Newest answers|Oldest answers

permanent link

Geoffrey Clemm (30.1k●3●30●35) | answered May 07 '11, 5:10 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I've submitted work item 164956 for this.
There were two existing work items for two possible implementations for
this (work item 148034 and work item 44004), both referenced by the new
work item.

Cheers,
Geoff

On 5/6/2011 5:53 PM, joefh wrote:

Hello,

SVN allows user to piece together files from different repositories
into one Eclipse project, by using the "svn:externals"
attribute.

In RTC, when trying to load files from different components into one
Eclipse project, there is an error complaining about sandbox
overlapping.

Is there a way in RTC that allows users to piece together files from
different components into one Eclipse project? (similar as what SVN
provides)

Thanks.

Comments

Geoff Alexander commented May 17 '11, 3:05 p.m. | edited Oct 13 '17, 3:09 p.m.

I've submitted work item 164956 for this.
There were two existing work items for two possible implementations for
this (work item 148034 and work item 44004), both referenced by the new
work item.

Cheers,
Geoff

We currently use svn:externals in our project. We need to move our project from SVN to RTC by the end of June. Thus we need an snv:externals like capability in RTC. However, Enhancement 164956 has not yet been implemented (and is currently not in plan). Does someone know of a workaround/alternative solution we can used now?

Here's some more specific details on how we use svn:externals. We have an two Eclipse Java projects that are part of a stand-alone Java application. We also have an Eclipse PDE project for an RTC server plug-in. Our RTC server plug-in depends on code from the two Java projects. What I'd like to do is "tell" Eclipse that our PDE project has a dependency on the two Java projects and have the Java projects' .class and .jar files included in the plug-in when the plug-in is built. But from what I've been able to determine, this isn't possible. If someone knows how to indicate such a dependency, please let me know.

I worked around this Eclipse limitation using SVN externals to include the necessary Java source and third-party JAR files from the Java projects in the PDE project during SVN checkout . This has worked fine for us. I was hoping that we could do something similar with the RTC SCM.

Thanks,
Geoff

permanent link

Michael Valenta (3.7k●3) | answered May 18 '11, 9:14 a.m.
FORUM MODERATOR / JAZZ DEVELOPER

Geoff,

You may be able to achieve similar results using Eclipse links.

1) First you would need to load both the PDE projects and the java projects
2) Next, you would need to create a source folder in the PDE project and, in the folder creation dialog, use the Advanced section at the bottom to create the folder as a link to the source in the java project
3) you would need to repeat the process for the JAR files

One issue with this is that the links will be absolute file system paths. However, you can define variables on the General/Workspace/Linked Resources preference page and use those in your link paths. This would allow each use to customize where they load the projects.

The other question I have is how much flexibility do you have in the structure of these projects. One advantage of using the OSGi model is that any JAR can be a bundle. What we tend to do is make a bundle for each of the JARs we are consuming as well as the ones we produce. This allows the code to be used as part of an OSGi/Eclipse app or as part of a plain Java application without the need to repackage Java code. This may be something worth considering.

Comments

Geoff Alexander commented Jun 23 '11, 1:29 p.m. | edited Oct 13 '17, 3:10 p.m.

Geoff,

You may be able to achieve similar results using Eclipse links.

1) First you would need to load both the PDE projects and the java projects
2) Next, you would need to create a source folder in the PDE project and, in the folder creation dialog, use the Advanced section at the bottom to create the folder as a link to the source in the java project
3) you would need to repeat the process for the JAR files

One issue with this is that the links will be absolute file system paths. However, you can define variables on the General/Workspace/Linked Resources preference page and use those in your link paths. This would allow each use to customize where they load the projects.

The other question I have is how much flexibility do you have in the structure of these projects. One advantage of using the OSGi model is that any JAR can be a bundle. What we tend to do is make a bundle for each of the JARs we are consuming as well as the ones we produce. This allows the code to be used as part of an OSGi/Eclipse app or as part of a plain Java application without the need to repackage Java code. This may be something worth considering.

@mvalenta We are using "Eclipse links" as you suggested. This works fine for project builds within Eclipse. However, PDE builds (by right clicking on site.xml and selecting PDE Tools -> Build Site) in Eclipse don't appear to recognize the Eclipse links. Do you know how to get PDE Build to recognize the Eclipse links?

0	permanent link Kevin Behrens (71●3●2) \| answered May 18 '11, 10:24 a.m. Is there a reason you want to do this in source control rather than a dependency manager such as maven or ivy?

permanent link

Andrew Freed (213●1●12●14) | answered May 23 '11, 1:01 p.m.
JAZZ DEVELOPER

Geoff,

I have the exact same use case. Update your plugin/build.properties as follows:

source.. = src/
output.. = bin/
bin.includes = META-INF/,\
.,\
ProjectA.jar,\
ProjectB.jar,\
other_dependencies_if_you_have_them.jar
jars.compile.order = ProjectA.jar,\
ProjectB.jar,\
.
source.ProjectA.jar = ../ProjectA/src/
output.ProjectA.jar = bin/

source.ProjectB.jar = ../ProjectB/src/
output.ProjectB.jar = bin/

Do NOT forget the "." line under jars.compile.order ... this is what compiles your original plugin code. This update says "compile project A, then project B, then my local plugin code to build this plugin"

Your MANIFEST.MF needs only reference these jars locally:

Bundle-ClassPath: ProjectA.jar,
ProjectB.jar,
.,

Make the appropriate updates if you want to put the jar files in a lib/ or other subfolder ... this trick puts the jars in your project root.

It's all about the answers!

Related questions

RTC representation of "svn:externals"

4 answers

Your answer