[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ecf-dev] request: test workaround for java 7 bug
|
On Sun, May 6, 2012 at 9:38 PM, Scott Lewis
<slewis@xxxxxxxxxxxxx> wrote:
Hi Ian,
I thought that if both the .jar and the .jar.pack.gz were
present...as is the case in this repo now:
http://download.eclipse.org/rt/ecf/3.5Test/site.p2
that it would not make any difference...because the non-packed jar
would be used...i.e. org.jivesoftware.smack...jar
Ah sorry, I didn't test that. I misread the email. I thought we finally found a way to include the unpacked jar inside a bundle. Yes, Pascal's comment still stands. Maybe somebody else can double check that things actually work now.
...i.e. as per Pascal's comment:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=361628#c32
A little more broadly: Is there some procedure or
workaround...short of restructuring this bundle completely (which
isn't an ECF-authored bundle or lib)...that we can use to avoid this
problem with pack/unpack in the installation of this bundle and it's
internal jars?
If we only list the canonical (unpacked jars) , then this won't be a problem at all. However, users will need to download the un-optimized version (which sucks).
The only other option is for us (p2) to include the version of Java that was used to packed the jar, and then use that logic to determine if we should download the optimized (pack.gz) or canonical (unpacked jars). I'm not sure how invasive a change this is though.
Cheers,
Ian
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com |
http://twitter.com/eclipsesource