Re: [cbi-dev] Fwd: [Bug 387557] JarProcessor 'tampers' eclipse.inf of si

[Igor Fedorenko <igor@xxxxxxxxxxxxxx>]

On 12-09-06 7:01 PM, David M Williams wrote:
> Unless I am missing your point, I think the use case you are missing is
> that eclipse.inf is not always about children.

Apart from -E4, which I believe is not essential, do you have any other
examples how eclipse.inf is used to control pack or unpack configuration?


> Sometimes for example, it gives parameters to pass to the pack200
> program itself (e.g. -E4 is common) and this parameter (or others) must
> be the same when packing, and also used when unpacking, as far as I
> know.  (http://wiki.eclipse.org/JarProcessor_Options)

This is not how I read JarProcessor documentation and I don't think this
matches with JDK documentation either.

From pack200 javadoc [1], the only requirement appears to be is to use
the same packer configuration during normalization and packing
operations, which Tycho does. It does not appear to be necessary to use
the same parameters during unpack, however. In fact, judging by Unpacker
javadoc [2] and from running "unpack200 --help" on command line,
unpacker does not really support any parameters. So whether -E is
specified in eclipse.inf or not, does not affect unpack, as far as I can
tell.


[1] 
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/jar/Pack200.Packer.html
[2] 
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/jar/Pack200.Unpacker.html



> I'll let others with more expertise comment on "never signing children"
> but I've not heard that universally agreed to. (It might be, I'm just
> saying I've never heard that).

Well, Tycho does not sign nested jars and this is unlikely to change
unless somebody provides specific example where signed nested jars are
required. Nested jars a evil after all [3] :-)

[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=111238#c11

--
Regards,
Igor


> HTH
>
>
>
>
> From: Igor Fedorenko <igor@xxxxxxxxxxxxxx>
> To: Common-build Developers discussion <cbi-dev@xxxxxxxxxxx>,
> Date: 09/06/2012 03:58 PM
> Subject: [cbi-dev] Fwd: [Bug 387557] JarProcessor 'tampers' eclipse.inf
> of signed jars in some cases
> Sent by: cbi-dev-bounces@xxxxxxxxxxx
> ------------------------------------------------------------------------
>
>
>
> To make sure I am not missing an important usecase here. Why is use of
> eclipse.inf required for jdt.core?
>
> For example, Tycho never packs or signs nested jars, so
> jarprocessor.exclude.children=true is redundant.
>
> jarprocessor.exclude.pack=true and jarprocessor.exclude.sign=true can be
> easily achieved via pom.xml configuration. And I need to
> double-check if they are actually needed for the projects they are used in.
>
> Anything else is needed/used by jdt.core and platform build in general?
>
> I think getting rid of eclipse.inf is the best solution to this problem.
> Bundles without eclipse.inf can be installed/used by any p2 version, so
> it won't be necessary to update b3 aggregator for example. They will
> also work with p2 Juno SR0 and earlier, which won't be possible if we
> rely on p2 fix only, which I assume will be included in Juno SR2 at the
> earliest.
>
> --
> Regards,
> Igor
>
>
> -------- Original Message --------
> Subject: [Bug 387557] JarProcessor 'tampers' eclipse.inf of signed jars
> in some cases
> Date: Thu, 06 Sep 2012 14:37:59 +0000
> From: bugzilla-daemon@xxxxxxxxxxx
> To: igor@xxxxxxxxxxxxxx
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=387557
> Product/Component: Equinox / p2
>
> Paul Webster <pwebster@xxxxxxxxxx> changed:
>
>             What    |Removed                   |Added
> ----------------------------------------------------------------------------
>                   CC|    |irbull@xxxxxxxxxxxxxxxxx
>
> --- Comment #9 from Paul Webster <pwebster@xxxxxxxxxx> ---
> This effect at least jdt.core and would prevent us from adopting the CBI
> platform build.
>
> Ian, is the code that's changing META-INF/eclipse.inf easy to remove?
>
> PW
>
> --
> You are receiving this mail because:
> You reported the bug.
>
>
> _______________________________________________
> cbi-dev mailing list
> cbi-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cbi-dev
>
>
>
>
> _______________________________________________
> cbi-dev mailing list
> cbi-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cbi-dev