RTC representation of "svn:externals"
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
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:
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,
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.
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,
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.
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.