Re: [orbit-dev] Strange Class Files in Lucene Bundle

[David M Williams <david_williams@xxxxxxxxxx>]

There are occasionally cases where "pack200" does not properly "pack" a jar ... at least in a way it can later be unpacked.

And there are ways to disable pack200 for a jar, independent of the build itself ... that is, it can be specified in the jar itself, by including a file named eclipse.inf in the META-INF directory.
See http://wiki.eclipse.org/JarProcessor_Options

I notice that, in orbit, org.apache.xalan is one such case where we've found it necessary to include
jarprocessor.exclude.pack=true
in an eclipse.inf file, as documented in bug 275122. [1]

Let us know what you find out ... and, if it "works", I recommend documenting the issue in an Orbit bugzilla, so there would be some history of why that jar was not packed.

But, in cases I've seen, problems with "pack" usually show up in more unusual ways than "not being able to access static methods of inner classes". But, not sure there's much of a pattern for these types of corruptions when they do occur, so .... maybe.

Thanks,

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=275122



"Wetzold, Robert" ---11/22/2011 10:49:13 AM---Ah! Thanks for explaining :) Much appreciated. So this is the reason for the difference. Could it be

From: "Wetzold, Robert" <robert.wetzold@xxxxxxx>
To: Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>,
Date: 11/22/2011 10:49 AM
Subject: Re: [orbit-dev] Strange Class Files in Lucene Bundle
Sent by: orbit-dev-bounces@xxxxxxxxxxx

---

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?
 
 
Best regards, Robert
 
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:


Hi Pascal,
 
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.
 
Maybe my scenario again:

- 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.
 
[1] http://build.eclipse.org/orbit/committers/orbit-I/20111122100600/I20111122100600/repository/plugins/org.apache.lucene.core_3.0.3.v201111221053.jar
 
Best regards, Robert
 
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:



Hi,
 
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?
 
 
Best regards, Robert
 
 
Pflichtangaben/Mandatory Disclosure Statements:
www.sap.com/corporate-en/impressum
 
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
 
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev
 _______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev