Bugzilla – Full Text Bug Listing
| Summary: | Mirroring from TM update sites fails because of missing dependencies | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] Target Management | Reporter: | Miles Daffin <miles.daffin> | ||||
| Component: | RSE | Assignee: | dsdp.tm.rse-inbox <tm.rse-inbox> | ||||
| Status: | NEW --- | QA Contact: | Martin Oberhuber <mober.at+eclipse> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | thomas | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Miles Daffin
The issue is not new, and has been investigated at length. See bug 236026 and bug 238309 - I can't count how many hours I have already wasted on this and similar problems. I guess eventually we settled on no longer touching the system and keeping it in a state that seems to work for the majority of our users. If you could make a very concrete suggestion how to improve the situation without breaking other consumers (as per the 2 bugs cited above) I'll happily do it. If I remember right, last time I tried disabling "linux" in the feature.xml the PDE build wouldn't build it any more on our Linux based build machine - that's why I had to revert that change. FWIW, I have also considered simply discontinuing WinCE and no longer shipping it just in order to avoid this problem. Note that the "TM Local Terminal" has the same issue except it works on Linux only and fails on Windows... for that one we settled on a different solution (enable install on Windows but disable at runtime: bug 314193 Thanks in advance for your help getting rid of this nasty mess. Why is it problematic to let the requirement have the same filter as the bundle that it points to? I don't understand your terminology. What is "requirement" in your context ? I'm using p2 terminology, sorry if I was unclear.
A feature 'includes' or 'requires' a bundle. They both result in 'requirements' in a p2 InstallableUnit.
When you're on the "Plug-ins and Fragments" tab in the feature manifest editor and add a bundle, you have an option to specify "Operating Systems", "Window Systems", "Languages", and "Architecture" on the left hand side. It is imperative that you enter win32 in the "Operating Systems" field and "x86" in the "Architecture" field for the bundle discussed in this bugzilla. This publisher will transform this into a filtered p2 requirement, i.e. a requirement that is only active for the specified environment. Failing to do this, means that the requirement is active for all environments.
In short,the MANIFEST.MF of the plug-in contains this filter:
(&(arch=x86)(os=win32))
Your feature.xml must contain something like this:
<plugin
id="org.eclipse.tm.rapi"
os="win32"
arch="x86"
download-size="0"
install-size="0"
version="0.0.0"
unpack="false"/>
I think I tried this in the past, but since feature.xml also drives PDE build my workspace didn't compile any more on the build machine (which was a Linux host). (In reply to comment #5) > I think I tried this in the past, but since feature.xml also drives PDE build > my workspace didn't compile any more on the build machine (which was a Linux > host). In that case, you are facing more than one problem. The thing you publish now is broken for all environments except win32.x86 and the repository is impossible to mirror using a validating mirroring tool like the b3 aggregator. I guess this problem also makes it impossible to include this feature in a contribution to Indigo? I suggest you add the needed filter and try your build again. If it fails, perhaps I can help out. I did as you suggested, and nightly build fails with this: BUILD FAILED /home/data/users/moberhuber/ws2/org.eclipse.releng.basebuilder/plugins/org.eclipse.pde.build_3.6.100.v20110121-1730/scripts/build.xml:35: The following error occurred while executing this line: /home/data/users/moberhuber/ws2/org.eclipse.releng.basebuilder/plugins/org.eclipse.pde.build_3.6.100.v20110121-1730/scripts/build.xml:91: The following error occurred while executing this line: /home/data/users/moberhuber/ws2/org.eclipse.rse.build/customTargets.xml:30: The following error occurred while executing this line: /opt/public/tools/tm/ws2/org.eclipse.releng.basebuilder/plugins/org.eclipse.pde.build_3.6.100.v20110121-1730/scripts/genericTargets.xml:107: Unable to generate source (org.eclipse.tm.rapi.source) from binary bundle org.eclipse.tm.rapi_0.2.200.N20110407-0451. How do you suggest to proceed? This is exactly the problem I've seen before and couldn't get fixed in spite of investing several hours. Note that this is not our hudson build, but our "legacy build" which runs on build.eclipse.org -- from what I remember, the hudson build doesn't even get that far and when we try adding WinCE to the hudson build the unittests don't run any more. Is this build fairly straight forward? I.e. is it just features and bundles that you want to generate source for, sign, pack, and publish to an update site? Well, we have a couple requirements: - We need to produce "rseserver" as standalone Java app, comprised of code that goes into the client as well - I want the .api_description files to be generated for PDE API Tooling (currently not supported by Tycho, and AFAIK also not by Athena CBI) - We have a couple standalone downloads (.zip format) but I could live with getting rid of these and using a p2 repo instead - We have terminal.local that is "linux only" and winCE which is "windows only" (currently not supported by Athena CBI) Our build was simple enough to work with Athena / CBI on hudson.eclipse.org - in fact we use that for our daily unittests. But the build output is not exactly as we need it, that's why our legacy builder is still running. (In reply to comment #9) > Well, we have a couple requirements: > > - We need to produce "rseserver" as standalone Java app, comprised of code > that goes into the client as well > I assume that you have an ant-task today to create that app as a jar with a main class? > - I want the .api_description files to be generated for PDE API Tooling > (currently not supported by Tycho, and AFAIK also not by Athena CBI) > Not sure what this means. Do you mean that you want to generate a target definition that can be used as an API baseline? Is there some functionality in PDE to perform this generation? You say you "want" :-) Does that mean that this would be a good enhancement or is it done in some other way by your legacy build? > - We have terminal.local that is "linux only" and winCE which is "windows only" > (currently not supported by Athena CBI) > I assume that terminal.local and winCE are environ specific installable features in this context? Or are they products? (In reply to comment #10) > I assume that you have an ant-task today to create that app as a jar with a > main class? See the "serverruntime" target here: http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.rse/releng/org.eclipse.rse.build/customTargets.xml?view=markup&root=Tools_Project > > - I want the .api_description files to be generated for PDE API Tooling > > (currently not supported by Tycho, and AFAIK also not by Athena CBI) > > > Not sure what this means. Do you mean that you want to generate a target > definition that can be used as an API baseline? Is there some functionality in > PDE to perform this generation? PDE build generates those files when "generateAPIDescription=true" in build.properties http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.rse/releng/org.eclipse.rse.build/build.properties?view=markup&root=Tools_Project Tycho doesn't support this yet, and for some odd reason we also didn't get it to work with Athena CBI Talking about build.properties, I also wnat the "generateSourceReferences=true" feature to allow "import from repository" in PDE. > I assume that terminal.local and winCE are environ specific installable > features in this context? Or are they products? Installable features. Created attachment 192760 [details]
Reverse patch
I've reverted the change again in order to not jeopardize our N-builds.
Reverse patch attached.
Regarding the (In reply to comment #11) > > I assume that you have an ant-task today to create that app as a jar with a > > main class? > > See the "serverruntime" target here: Looks fairly straight forward and reusable. > PDE build generates those files when "generateAPIDescription=true" in build.properties > Tycho doesn't support this yet, and for some odd reason we also didn't get it > to work with Athena CBI I must admit I haven't seen this before, but as of today, Buckminster has support for it. It was trivial to add since we just delegate to the ant task that PDE provides. > Talking about build.properties, I also wnat the "generateSourceReferences=true" > feature to allow "import from repository" in PDE. We support this generation for CVS, SVN, and GIT repositories. Any suggestion how to proceed? As it stands, our legacy builder is still blocked by the issue from comment #7 so I've reverted the requested change to make the wince feature consistent with its underlying bundles. I'm still not sure whether this is a defect in PDE Build and its source generation facility, or something else. For TM 3.3m7 I have upgraded to basebuilder R37_M6 and replaced the "EclipseGenerator" aplication by "UpdateSitePublisher", if that helps. (In reply to comment #14) > Any suggestion how to proceed? > I would recommend that you use Buckminster. In 3.7, we have built in support that covers all the functionality that you need. Sorry but I don't have time fiddling with another releng system that I'm completely unfamiliar with, just to resolve an issue that (from what it seems) matters to hardly anyone in the community. Quite frankly, I'd rather get rid of the offending winCE feature entirely than investing countless hours into revamping our entire releng. Or get the issue with PDE Build fixed which apparently jeopardizes source generation for RAPI when it's appropriately declared in the feature.xml. While I sympathize with being short of time, that was also the reason for my recommendation. I think the transition would be fairly quick and painless given the apparent simplicity of your build. But time needs to be spent on learning of course, so my assumption might be wrong. Your problem is definitely worth a bugzilla entry against PDE build. My guess though, is that it will take some time to get it fixed. I didn't think getting rid of the problematic feature altogether was an option. |