| Summary: | bundle.jar action does not include linked resource class files | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Alan Underwood <m.alan.underwood> | ||||||
| Component: | Buckminster | Assignee: | Thomas Hallgren <thomas> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | minor | ||||||||
| Priority: | P3 | CC: | Peter.woods, thomas | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Alan Underwood
I am using the latest version of buckminster and eclipse 3.6.1 I have the same problem. I've put a forum post about it here: http://www.eclipse.org/forums/index.php?t=msg&goto=632132 Created attachment 180663 [details]
Patch to fix linked resources issue
This patch seems to fix our problem. Not really sure if it fixes the whole issue, however.
Patch fixes two different things:
1. The URI locating source output folders is now processed by the
workbench path variable manager API to resolve linked resource references.
2. For absolute output paths, creates a product artifact with a full 'base'
path and no additional paths (previously it would create a null 'base' path
and one additional path with the absolute path, which didn't appear to
work).
We also discovered that for linked project resources, Buckminster appears to
treat absolute paths where the final directory element has the same name as the
original resource specially. This results creation of a product artifact with both a 'base' path and an additional path, which causes the final JAR to contain an extra (incorrect) top level directory. This issue has *not* been addressed by this patch.
Thanks very much for the patch, Pete. It works for me. Now to see if somebody will take note and apply to source control. Alan Created attachment 181101 [details]
Test case demonstrating failure
I'm working on a large scale RCP project at the minute for one of my customers.
They want me to improve the build process from using lots of custom Ant and Ivy
scripts to something more intelligible. I've decided that Buckminster is the
right tool for this job, and have created an appropriate R-Map to map out the
project's resources, some C-Queries, etc. These all seem to work pretty well.
The customer uses the ClearCase version control system, however. It's extremely
slow to build from because the "bin/" folder in your project lives on a network
drive with your other project resources. To work around this, they have set up
an Eclipse linked resource that maps "eclipse_build_loc" to, say "D:\Temp\build"
for build output. Then inside each plug-in you include the following in the
".project" file.
------------------
<linkedResources>
<link>
<name>bin</name>
<type>2</type>
<locationURI>eclipse_build_loc/myprojectname</locationURI>
</link>
</linkedResources>
------------------
This maps the output "bin/" directory to live on your local disk instead of on
the network.
Unfortunately when you do a Buckminster build of these plug-ins they don't
include the compiled classes. I thought I was so close after mapping out all the
dozens of search locations out!
Any suggestions on how to work around this? I've tried debugging the Buckminster
process, but the codebase is too large for me to quickly find out what's going
wrong. I'm not above patching my version of Buckminster, if necessary, until you
guys can come up with a fix for this.
Patch applied to helios-maintenance branch, rev 11619. Thanks. |