Bugzilla – Full Text Bug Listing
| Summary: | SVN Mylyn Connector can not be "unpacked" | ||
|---|---|---|---|
| Product: | Community | Reporter: | David Williams <david_williams> |
| Component: | Cross-Project | Assignee: | Igor Burilo <igor.burilo> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | blocker | ||
| Priority: | P3 | CC: | mober.at+eclipse, stephan.herrmann |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | 311800 | ||
| Bug Blocks: | |||
|
Description
David Williams
Changing Summary, previous value was: Mylyn can not be "unpacked" AFAIK the svn.mylyn contribution is owned by the Subversive project, and not by Mylyn. It is an add-on that nobody should depend on, so removing it from the build should not be a problem. Thank you very much Martin. I was reading too quickly, and unfairly associated it with "mylyn". I'll try removing Subversive until this is fixed (but, I think Buckminster might rely on it). I did have to also remove buckminster.build, as it depends on something from subversive.build, but on my local machine, it did seem to verify after that .... so we'll see how far this gets us. I've just updated Subversive build. count as dup *** This bug has been marked as a duplicate of bug 311800 *** Can someone please give a hint at what the solution to this bug was? I'm seeing pretty much the same for three of our 15 plugins (Object Teams) and can't seem to see what distinguishes the failing three from the rest. Both .jar and .jar.pack.gz are present and can be unpacked manually. Unfortunately this bug and its dup Bug 311800 only say it's "done" but not how. > > I'm seeing pretty much the same for three of our 15 plugins (Object Teams) > and can't seem to see what distinguishes the failing three from the rest. > Both .jar and .jar.pack.gz are present and can be unpacked manually. > This problem is caused by using Java6 pack200. It does not produce backwards compatible pack.gz files if (and only if) there are no .class files in the jar. See bug 275533 for some of the original discussion of the issue. We purposely use Java 5 in the aggregator build to catch cases like this. Can you adjust to use Java 5? I ask because in reality, for Indigo, we will (likely) change to use Java 6 for the aggregator process, but I was reluctant to change before Helios SR2 (since most have to make sure to work with Java 5 for Helios SR2) but ... guess Helios SR2 is not an issue for you and other new-to-Indigo projects. (In reply to comment #7) > This problem is caused by using Java6 pack200. It does not produce backwards > compatible pack.gz files if (and only if) there are no .class files in the jar. > See bug 275533 for some of the original discussion of the issue. We purposely > use Java 5 in the aggregator build to catch cases like this. Thanks for explaining. I can reproduce that the files in question cannot be unpacked with java5 unpack200. In my case it's jars containing nested jars (and no toplevel .class). > Can you adjust to use Java 5? Yes, I can use Java 5 for packing. I'll try and re-contribute tomorrow. (In reply to comment #8) > In my case it's jars containing nested jars Hm, I do not know the details but reading "nested jars" provoked some bad memories... can the nested jars be avoided? See also http://eclipse.org/helios/planning/EclipseSimultaneousRelease.php in section "Jarred bundles": "Also, nested jars should be avoided if possible since it creates problems for projects that has dependencies to such plug-ins. The OSGi runtime is fine with it but the PDE environment is not able to handle classpaths that contain nested jars." (In reply to comment #9) > (In reply to comment #8) > > In my case it's jars containing nested jars > > Hm, I do not know the details but reading "nested jars" provoked some bad > memories... can the nested jars be avoided? See also > > http://eclipse.org/helios/planning/EclipseSimultaneousRelease.php > > in section "Jarred bundles": > > "Also, nested jars should be avoided if possible since it creates problems for > projects that has dependencies to such plug-ins. The OSGi runtime is fine with > it but the PDE environment is not able to handle classpaths that contain nested > jars." Thanks for reminding me. Yes, I will look into these some time soon. Currently, we don't have downstream dependencies, so for M3 this should be OK I hope. |