Ah! Thanks for explaining J Much appreciated. So this is the reason for the difference. Could it be that this process is faulty and causes a corrupt file? Did you hear of such issues before where some of the resulting files were not usable? Copying over the original ones solves it. Is there a switch in Orbit not to compress the Lucene 3.0.3 core bundle for a quick test? From: orbit-dev-bounces@xxxxxxxxxxx [mailto:orbit-dev-bounces@xxxxxxxxxxx] On Behalf Of Pascal Rapicault Sent: Dienstag, 22. November 2011 16:43 To: Orbit Developer discussion Subject: Re: [orbit-dev] Strange Class Files in Lucene Bundle Pack200 is a lost less compression at the semantic level from the code level, however it changes the structure of the classfile. Bottom line if you pack and unpack a jar you will not get the same class files. Also in the past we ran into problems with packing. On 2011-11-22, at 10:36 AM, Wetzold, Robert wrote:
thanks for the fast answer. I don’t think it can be related to a compressor, since the extracted file should be exactly the same size since it must be a lossless compression. - First file: bundle from Orbit [1]. In there, org/apache/lucene/document/Field$1.class is 217 Bytes - Second file: original from SVN, there, the same file is 220 Bytes The difference is even bigger for Field.class. 5,61Kb vs 5,64. Something is happening to the class files. I am a little clueless here as it is my only explanation so far on why it cannot be resolved but it does not seem very logical to me. But since copying the class files from SVN to a local version of the orbit file works there must be some link there. From: orbit-dev-bounces@xxxxxxxxxxx [mailto:orbit-dev-bounces@xxxxxxxxxxx] On Behalf Of Pascal Rapicault Sent: Dienstag, 22. November 2011 15:05 To: Orbit Developer discussion Subject: Re: [orbit-dev] Strange Class Files in Lucene Bundle The size difference could be resulting from the pack200 process. If you grab the class files directly from the SCM and use that, does it work? On 2011-11-22, at 7:53 AM, Wetzold, Robert wrote: I have now adjusted our project to use the newest Orbit IBuild and it basically works great except for one bundle: Apache Lucene Core 3.0.3. Concrete: The static methods of the inner Field class will not be accessible, e.g. Field.Index & Field.Store. There will be a “cannot be resolved to a type” message. Now the strangest part: If I overwrite the “org” folder and its contents in the bundle with the contents I had originally checked in and which comes from Lucene and reload the target platform it will suddenly work (open bundle in winrar, drag old org folder in there). I compared some random files in the bundle and in the original and e.g. the Field.class is 220 bytes in the original but 217 in the bundle. Why is there a difference? I assumed the class files structure is simply packed into the jar. Could this difference be the reason why it does not work or am I on the totally wrong track here? Pflichtangaben/Mandatory Disclosure Statements: Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank. This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation. _______________________________________________ orbit-dev mailing list orbit-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/orbit-dev |