Discussion:
Notice of change to batch "signing service"
(too old to reply)
David M Williams
2015-04-11 06:48:01 UTC
Permalink
I wanted to let everyone know that "we" are changing the version of Java's
pack200 at the infrastructure service I call "batch signer". (Bug 463510)
It was using Java 6 level of pack200, and we have moved to the Java 8
level of pack200.

This command is described at
https://wiki.eclipse.org/IT_Infrastructure_Doc#ZIP_and_JAR_files_from_the_Commandline_.28Queued.29

This does not directly impact Tycho users or Buckminster users (which do
their own re-pack and pack, based on the VM the build is running, I
assume) but might effect PDE users, which traditionally have used this
service to "re-pack" (condition) and sign jars -- and, then at some short
later time are "packed". At that "some later time", it is the release
engineers responsibility to use the same version to 'pack' as was used to
'repack'.

While no direct impact to Tycho or Buckminster builders, the principles
and consequences of moving from one level (Java 6) to another (Java 8)
apply with any builder, so the following points may be useful information
to all.

If you have "old byte codes", or, even new ones, compiled at the Java 4,
Java 5, or Java 6 level, you *might* find some of those bytes codes no
longer survive the "re-pack", sign, and "pack" process (where as maybe the
would survived, when using Java 6 to run your build (and hence your
repack/pack). That is, if user tries to download the pack.gz file, and
unpack into a normal jar, it may be reported to have in "invalid
signature" or in some other way "broken".

In my experience, with Orbit jars, the "error rate" is about 1.7%. Others,
for some unknown reason, see higher rates (such as 20-30%?) . Some of
these cases *might* be bugs in the pack/unpack programs, but it's just as
likely that there are "bugs" (fringe cases) where the byte codes for lower
levels of Java are not quite "right". All I know for sure: it has never
been perfect.

But, luckily, easy to solve.
All three builders (PDE, Tycho, and Buckminster) allow you to specify an
'eclipse.inf' file in the META-INF directory, with a directive (line) that
is:
jarprocessor.exclude.pack=true

Thus, that one problematic jar is not packed, but is still signed.

So important point 1: be sure you "pack200" with the same version you used
to do "repack" (if the builder doesn't do it for you automatically).
Important point 2: I wouldn't recommend studying the byte codes and trying
to find a pattern of code that is the cause (unless you just happen to
love byte codes), ... just slap in an eclipse.inf file and move on to more
important things.
Important point 3: You should not, ever never, "re-sign" and certainly not
re-pack or pack200 a jar that has already been signed or processed by
pack200. That pretty much guarantees the jar will be broken. In more ways
than one. (Bug 461669)

The reason for making this move, now, is that it is best to "keep up" with
what our users are using, and, with versions of Java that are expected to
stay in service for a while ... otherwise, we might have to monkey around
with this during a service release, which is less than ideal.

* Bonus, for reading this far in my wordy note: Why jump two levels, from
6 to 8, why not move to Java 7 first? Well it turns out, at the moment,
the versions of pack200 and unpack200 that ship with Java 7 and Java 8 are
exactly the same. But, the advantage is, in some service release, there
might be a new version and we'd pick it up automatically, as long as we
use /shared/common/jdk1.8.0_x86-latest consistently. Double bonus:
remember that pack200 and unpack200 have little to do with Java source
code they are stand-alone executables, written in C-code, that simply
manipulate byte codes. Which is how p2 can let you specify any version of
pack200 you want, no mater which version of Java you are using.

Naturally, feel free to comment in Bug 463510 if any questions or concrete
problems known.
Alexander Nyßen
2015-04-11 07:58:37 UTC
Permalink
David,

I admit I am not very acquainted with the internals of signing and pack200. However, we are using Tycho for our builds, but our jobs provide the following option when calling Maven (which seems to be used by a couple of other hudson jobs as well; it was probably recommended in some instructions I don’t remember):

-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/sun-jdk1.6.0_21_x64/jre/bin" -Xmx768m

I assume we will have to adopt this to something like the following then, right:

-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/jdk1.8.0_x86-latest/jre/bin“

Is there a way to confirm that a build behaves as expected (do the sim-rel repo-reports for instance cover this)?

Cheers
Alexander
I wanted to let everyone know that "we" are changing the version of Java's pack200 at the infrastructure service I call "batch signer". (Bug 463510 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510>)
It was using Java 6 level of pack200, and we have moved to the Java 8 level of pack200.
This command is described at
https://wiki.eclipse.org/IT_Infrastructure_Doc#ZIP_and_JAR_files_from_the_Commandline_.28Queued.29 <https://wiki.eclipse.org/IT_Infrastructure_Doc#ZIP_and_JAR_files_from_the_Commandline_.28Queued.29>
This does not directly impact Tycho users or Buckminster users (which do their own re-pack and pack, based on the VM the build is running, I assume) but might effect PDE users, which traditionally have used this service to "re-pack" (condition) and sign jars -- and, then at some short later time are "packed". At that "some later time", it is the release engineers responsibility to use the same version to 'pack' as was used to 'repack'.
While no direct impact to Tycho or Buckminster builders, the principles and consequences of moving from one level (Java 6) to another (Java 8) apply with any builder, so the following points may be useful information to all.
If you have "old byte codes", or, even new ones, compiled at the Java 4, Java 5, or Java 6 level, you *might* find some of those bytes codes no longer survive the "re-pack", sign, and "pack" process (where as maybe the would survived, when using Java 6 to run your build (and hence your repack/pack). That is, if user tries to download the pack.gz file, and unpack into a normal jar, it may be reported to have in "invalid signature" or in some other way "broken".
In my experience, with Orbit jars, the "error rate" is about 1.7%. Others, for some unknown reason, see higher rates (such as 20-30%?) . Some of these cases *might* be bugs in the pack/unpack programs, but it's just as likely that there are "bugs" (fringe cases) where the byte codes for lower levels of Java are not quite "right". All I know for sure: it has never been perfect.
But, luckily, easy to solve.
jarprocessor.exclude.pack=true
Thus, that one problematic jar is not packed, but is still signed.
So important point 1: be sure you "pack200" with the same version you used to do "repack" (if the builder doesn't do it for you automatically).
Important point 2: I wouldn't recommend studying the byte codes and trying to find a pattern of code that is the cause (unless you just happen to love byte codes), ... just slap in an eclipse.inf file and move on to more important things.
Important point 3: You should not, ever never, "re-sign" and certainly not re-pack or pack200 a jar that has already been signed or processed by pack200. That pretty much guarantees the jar will be broken. In more ways than one. (Bug 461669 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=461669>)
The reason for making this move, now, is that it is best to "keep up" with what our users are using, and, with versions of Java that are expected to stay in service for a while ... otherwise, we might have to monkey around with this during a service release, which is less than ideal.
* Bonus, for reading this far in my wordy note: Why jump two levels, from 6 to 8, why not move to Java 7 first? Well it turns out, at the moment, the versions of pack200 and unpack200 that ship with Java 7 and Java 8 are exactly the same <https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510#c27>. But, the advantage is, in some service release, there might be a new version and we'd pick it up automatically, as long as we use /shared/common/jdk1.8.0_x86-latest consistently. Double bonus: remember that pack200 and unpack200 have little to do with Java source code they are stand-alone executables, written in C-code, that simply manipulate byte codes. Which is how p2 can let you specify any version of pack200 you want <https://wiki.eclipse.org/JarProcessor_Options#Other_properties>, no mater which version of Java you are using.
Naturally, feel free to comment in Bug 463510 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510> if any questions or concrete problems known.
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743

http://www.itemis.de
***@itemis.de

itemis AG
Am Brambusch 15-24
44536 LÃŒnen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino
Ed Willink
2015-04-11 08:35:48 UTC
Permalink
Hi

You explain why relatively few projects shared the pain at M6;
Maven/Tycho was insulated.

The easiest way to test is to run the aggregator build and note down all the

[exec] - mirroring artifact
osgi.bundle,org.eclipse.m2m.qvt.oml,3.5.0.v20150324-1623
[exec] doing copy of optimized artifact
[exec] unpacking optimized artifact
[exec] Unable to unpack artifact
osgi.bundle,org.eclipse.m2m.qvt.oml,3.5.0.v20150324-1623 in repository
file:/shared/simrel/mars/aggregation/final/aggregate: Invalid
content:org/eclipse/m2m/internal/qvt/oml/stdlib/model/StdlibFactory.class

errors that are in your contribution. Just put a META-INF/eclipse.inf
containing

jarprocessor.exclude.pack=true

in each of them rebuild, recontribute and you're done.

If you want to be a bit more sociable you can check each of your
*.pack.gz files before contributing by

unpack200 xxx.pack.gz xxx.jar
jarsigner -verify xxx.jar

Bad files report a SHA1 digest failure.

Regards

Ed Willink
Post by Alexander Nyßen
David,
I admit I am not very acquainted with the internals of signing and
pack200. However, we are using Tycho for our builds, but our jobs
provide the following option when calling Maven (which seems to be
used by a couple of other hudson jobs as well; it was probably
-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/sun-jdk1.6.0_21_x64/jre/bin"
-Xmx768m
-Dorg.eclipse.update.jarprocessor.pack200="*/shared/common/jdk1.8.0_x86-latest*/jre/bin“
Is there a way to confirm that a build behaves as expected (do the
sim-rel repo-reports for instance cover this)?
Cheers
Alexander
Am 11.04.2015 um 08:48 schrieb David M Williams
I wanted to let everyone know that "we" are changing the version of
Java's pack200 at the infrastructure service I call "batch signer".
(*_Bug 463510_* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510>)
It was using Java 6 level of pack200, and we have moved to the Java 8 level of pack200.
This command is described at
https://wiki.eclipse.org/IT_Infrastructure_Doc#ZIP_and_JAR_files_from_the_Commandline_.28Queued.29
This does not directly impact Tycho users or Buckminster users (which
do their own re-pack and pack, based on the VM the build is running,
I assume) but might effect PDE users, which traditionally have used
this service to "re-pack" (condition) and sign jars -- and, then at
some short later time are "packed". At that "some later time", it is
the release engineers responsibility to use the same version to
'pack' as was used to 'repack'.
While no direct impact to Tycho or Buckminster builders, the
principles and consequences of moving from one level (Java 6) to
another (Java 8) apply with any builder, so the following points may
be useful information to all.
If you have "old byte codes", or, even new ones, compiled at the Java
4, Java 5, or Java 6 level, you *might* find some of those bytes
codes no longer survive the "re-pack", sign, and "pack" process
(where as maybe the would survived, when using Java 6 to run your
build (and hence your repack/pack). That is, if user tries to
download the pack.gz file, and unpack into a normal jar, it may be
reported to have in "invalid signature" or in some other way "broken".
In my experience, with Orbit jars, the "error rate" is about 1.7%.
Others, for some unknown reason, see higher rates (such as 20-30%?) .
Some of these cases *might* be bugs in the pack/unpack programs, but
it's just as likely that there are "bugs" (fringe cases) where the
byte codes for lower levels of Java are not quite "right". All I
know for sure: it has never been perfect.
But, luckily, easy to solve.
All three builders (PDE, Tycho, and Buckminster) allow you to specify
an 'eclipse.inf' file in the META-INF directory, with a directive
jarprocessor.exclude.pack*=true*
Thus, that one problematic jar is not packed, but is still signed.
So important point 1: be sure you "pack200" with the same version you
used to do "repack" (if the builder doesn't do it for you
automatically).
Important point 2: I wouldn't recommend studying the byte codes and
trying to find a pattern of code that is the cause (unless you just
happen to love byte codes), ... just slap in an eclipse.inf file and
move on to more important things.
Important point 3: You should not, ever never, "re-sign" and
certainly not re-pack or pack200 a jar that has already been signed
or processed by pack200. That pretty much guarantees the jar will be
broken. In more ways than one. (*_Bug 461669_*
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=461669>)
The reason for making this move, now, is that it is best to "keep up"
with what our users are using, and, with versions of Java that are
expected to stay in service for a while ... otherwise, we might have
to monkey around with this during a service release, which is less
than ideal.
* Bonus, for reading this far in my wordy note: Why jump two levels,
from 6 to 8, why not move to Java 7 first? Well it turns out, at the
moment, the versions of pack200 and unpack200 that ship with Java 7
and Java 8 are exactly the same
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510#c27>. But, the
advantage is, in some service release, there might be a new version
and we'd pick it up automatically, as long as we use
remember that pack200 and unpack200 have little to do with Java
source code they are stand-alone executables, written in C-code, that
simply manipulate byte codes. Which is how p2 can let you specify any
version of pack200 you want
<https://wiki.eclipse.org/JarProcessor_Options#Other_properties>, no
mater which version of Java you are using.
Naturally, feel free to comment in *_Bug 463510_*
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510>if any
questions or concrete problems known.
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer
Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743
http://www.itemis.de
itemis AG
Am Brambusch 15-24
44536 Lünen
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg
Pietrek, Jens Trompeter, Sebastian Neus
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5863 / Virus Database: 4328/9508 - Release Date: 04/11/15
David M Williams
2015-04-11 18:01:21 UTC
Permalink
... we are using Tycho for our builds, but our jobs provide the
following option when calling Maven
(which seems to be used by a couple of other hudson jobs as well;
-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/sun-jdk1.6.0_21_x64/jre/bin"
-Dorg.eclipse.update.jarprocessor.pack200="
/shared/common/jdk1.8.0_x86-latest/jre/bin“

This was probably recommended because you were using Java 7 or 8 to "run
your build" but it was determined to "minimize issues" to use the lower
version of pack200 (Especially when many users or pre-reqs were using Java
6). So, a) yes, eventually you'll "minimize issues" by using jdk 7 or 8
version, but b) that should be "automatic" if you are using Java 7 or 8 to
run your builds, so I'd try leaving it out .. perhaps commented out, for
when you need it again when you move to Java 9 :)

As far as checking yourself, Ed has already described one basic procedure.
The b3 aggregator will also check, but only if you select the "build"
option, which can take a long time, if you are trying to build the whole
Sim. Release. It is possible, though, so set up your own b3 aggregator job
(just for testing) that uses only your contribution, plus the minimum
number of "prereq" contributions. It is not exactly easy to set this up --
the first time -- but, once set up, is relatively easy to keep up to date.


One more: There are some bash scripts in the sim release test project,
that are not very efficient, but are an easy way to check a whole
directory of jars and pack.gz jars. Those two scripts are verify.sh and
verifydir.sh (both need to be in your on your path, and you execute
verifydir.sh (and it calls verfiy.sh). You may need to make your own copy
and adjust for your system, and your needs.

Another almost-off-topic tidbit: Many are surprised they "have errors"
because they have tested "installing" or "updating" using p2, and it works
fine. The reason is that p2 tries it's best to "recover from errors" so
often if there are problems with *.jar.pack.gz, then it will simply try
the *.jar file directly, which would work. But, for our Sim. Release repo
(and should for all repos) we want the repo to be "perfect" and not allow
it to contain "badly packed" jars. Doing so ends up causing "extra
downloads", and wasting users time when they do an update.

I realize it is not easy to get a "perfect repo", it takes extra effort,
but that's part of the whole purpose of having or joining the Sim.
Release, so everyone's extra effort is acknowledged, and appreciated.

Thanks for the questions!





From: Alexander Nyßen <***@itemis.de>
To: Cross project issues <cross-project-issues-***@eclipse.org>,
Date: 04/11/2015 03:59 AM
Subject: Re: [cross-project-issues-dev] Notice of change to batch
"signing service"
Sent by: cross-project-issues-dev-***@eclipse.org



David,

I admit I am not very acquainted with the internals of signing and
pack200. However, we are using Tycho for our builds, but our jobs provide
the following option when calling Maven (which seems to be used by a
couple of other hudson jobs as well; it was probably recommended in some
instructions I don’t remember):

-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/sun-jdk1.6.0_21_x64/jre/bin"
-Xmx768m

I assume we will have to adopt this to something like the following then,
right:

-Dorg.eclipse.update.jarprocessor.pack200="
/shared/common/jdk1.8.0_x86-latest/jre/bin“

Is there a way to confirm that a build behaves as expected (do the sim-rel
repo-reports for instance cover this)?

Cheers
Alexander
I wanted to let everyone know that "we" are changing the version of Java's
pack200 at the infrastructure service I call "batch signer". (Bug 463510)

It was using Java 6 level of pack200, and we have moved to the Java 8
level of pack200.

This command is described at
https://wiki.eclipse.org/IT_Infrastructure_Doc#ZIP_and_JAR_files_from_the_Commandline_.28Queued.29


This does not directly impact Tycho users or Buckminster users (which do
their own re-pack and pack, based on the VM the build is running, I
assume) but might effect PDE users, which traditionally have used this
service to "re-pack" (condition) and sign jars -- and, then at some short
later time are "packed". At that "some later time", it is the release
engineers responsibility to use the same version to 'pack' as was used to
'repack'.

While no direct impact to Tycho or Buckminster builders, the principles
and consequences of moving from one level (Java 6) to another (Java 8)
apply with any builder, so the following points may be useful information
to all.

If you have "old byte codes", or, even new ones, compiled at the Java 4,
Java 5, or Java 6 level, you *might* find some of those bytes codes no
longer survive the "re-pack", sign, and "pack" process (where as maybe the
would survived, when using Java 6 to run your build (and hence your
repack/pack). That is, if user tries to download the pack.gz file, and
unpack into a normal jar, it may be reported to have in "invalid
signature" or in some other way "broken".

In my experience, with Orbit jars, the "error rate" is about 1.7%. Others,
for some unknown reason, see higher rates (such as 20-30%?) . Some of
these cases *might* be bugs in the pack/unpack programs, but it's just as
likely that there are "bugs" (fringe cases) where the byte codes for lower
levels of Java are not quite "right". All I know for sure: it has never
been perfect.

But, luckily, easy to solve.
All three builders (PDE, Tycho, and Buckminster) allow you to specify an
'eclipse.inf' file in the META-INF directory, with a directive (line) that
is:
jarprocessor.exclude.pack=true

Thus, that one problematic jar is not packed, but is still signed.

So important point 1: be sure you "pack200" with the same version you used
to do "repack" (if the builder doesn't do it for you automatically).
Important point 2: I wouldn't recommend studying the byte codes and trying
to find a pattern of code that is the cause (unless you just happen to
love byte codes), ... just slap in an eclipse.inf file and move on to more
important things.
Important point 3: You should not, ever never, "re-sign" and certainly not
re-pack or pack200 a jar that has already been signed or processed by
pack200. That pretty much guarantees the jar will be broken. In more ways
than one. (Bug 461669)

The reason for making this move, now, is that it is best to "keep up" with
what our users are using, and, with versions of Java that are expected to
stay in service for a while ... otherwise, we might have to monkey around
with this during a service release, which is less than ideal.

* Bonus, for reading this far in my wordy note: Why jump two levels, from
6 to 8, why not move to Java 7 first? Well it turns out, at the moment,
the versions of pack200 and unpack200 that ship with Java 7 and Java 8 are
exactly the same. But, the advantage is, in some service release, there
might be a new version and we'd pick it up automatically, as long as we
use /shared/common/jdk1.8.0_x86-latest consistently. Double bonus:
remember that pack200 and unpack200 have little to do with Java source
code they are stand-alone executables, written in C-code, that simply
manipulate byte codes. Which is how p2 can let you specify any version of
pack200 you want, no mater which version of Java you are using.

Naturally, feel free to comment in Bug 463510 if any questions or concrete
problems known.




_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743

http://www.itemis.de
***@itemis.de

itemis AG
Am Brambusch 15-24
44536 LÃŒnen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer
Fiorentino


[attachment "signature.asc" deleted by David M Williams/Raleigh/IBM]
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
David M Williams
2015-04-14 15:56:15 UTC
Permalink
Since I sent the original notice, guess it is up to me to send this one.

The Eclipse Foundation has decided to revert this change.

Details in Bug 463510

I do not know that their plan is, nor do I know what to recommend to
anyone, at this point. I guess ask in Bug 463510, if anyone does have
questions.





From: David M Williams/Raleigh/***@IBMUS
To: Cross project issues <cross-project-issues-***@eclipse.org>,
Date: 04/11/2015 02:02 PM
Subject: Re: [cross-project-issues-dev] Notice of change to batch
"signing service"
... we are using Tycho for our builds, but our jobs provide the
following option when calling Maven
(which seems to be used by a couple of other hudson jobs as well;
-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/sun-jdk1.6.0_21_x64/jre/bin"
-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/jdk1.8.0_x86-latest/jre/bin“


This was probably recommended because you were using Java 7 or 8 to "run
your build" but it was determined to "minimize issues" to use the lower
version of pack200 (Especially when many users or pre-reqs were using Java
6). So, a) yes, eventually you'll "minimize issues" by using jdk 7 or 8
version, but b) that should be "automatic" if you are using Java 7 or 8 to
run your builds, so I'd try leaving it out .. perhaps commented out, for
when you need it again when you move to Java 9 :)

As far as checking yourself, Ed has already described one basic procedure.
The b3 aggregator will also check, but only if you select the "build"
option, which can take a long time, if you are trying to build the whole
Sim. Release. It is possible, though, so set up your own b3 aggregator job
(just for testing) that uses only your contribution, plus the minimum
number of "prereq" contributions. It is not exactly easy to set this up --
the first time -- but, once set up, is relatively easy to keep up to date.


One more: There are some bash scripts in the sim release test project,
that are not very efficient, but are an easy way to check a whole
directory of jars and pack.gz jars. Those two scripts are verify.sh and
verifydir.sh (both need to be in your on your path, and you execute
verifydir.sh (and it calls verfiy.sh). You may need to make your own copy
and adjust for your system, and your needs.

Another almost-off-topic tidbit: Many are surprised they "have errors"
because they have tested "installing" or "updating" using p2, and it works
fine. The reason is that p2 tries it's best to "recover from errors" so
often if there are problems with *.jar.pack.gz, then it will simply try
the *.jar file directly, which would work. But, for our Sim. Release repo
(and should for all repos) we want the repo to be "perfect" and not allow
it to contain "badly packed" jars. Doing so ends up causing "extra
downloads", and wasting users time when they do an update.

I realize it is not easy to get a "perfect repo", it takes extra effort,
but that's part of the whole purpose of having or joining the Sim.
Release, so everyone's extra effort is acknowledged, and appreciated.

Thanks for the questions!





From: Alexander Nyßen <***@itemis.de>
To: Cross project issues <cross-project-issues-***@eclipse.org>,
Date: 04/11/2015 03:59 AM
Subject: Re: [cross-project-issues-dev] Notice of change to batch
"signing service"
Sent by: cross-project-issues-dev-***@eclipse.org



David,

I admit I am not very acquainted with the internals of signing and
pack200. However, we are using Tycho for our builds, but our jobs provide
the following option when calling Maven (which seems to be used by a
couple of other hudson jobs as well; it was probably recommended in some
instructions I don’t remember):

-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/sun-jdk1.6.0_21_x64/jre/bin"
-Xmx768m

I assume we will have to adopt this to something like the following then,
right:

-Dorg.eclipse.update.jarprocessor.pack200="
/shared/common/jdk1.8.0_x86-latest/jre/bin“

Is there a way to confirm that a build behaves as expected (do the sim-rel
repo-reports for instance cover this)?

Cheers
Alexander
I wanted to let everyone know that "we" are changing the version of Java's
pack200 at the infrastructure service I call "batch signer". (Bug 463510)

It was using Java 6 level of pack200, and we have moved to the Java 8
level of pack200.

This command is described at
https://wiki.eclipse.org/IT_Infrastructure_Doc#ZIP_and_JAR_files_from_the_Commandline_.28Queued.29


This does not directly impact Tycho users or Buckminster users (which do
their own re-pack and pack, based on the VM the build is running, I
assume) but might effect PDE users, which traditionally have used this
service to "re-pack" (condition) and sign jars -- and, then at some short
later time are "packed". At that "some later time", it is the release
engineers responsibility to use the same version to 'pack' as was used to
'repack'.

While no direct impact to Tycho or Buckminster builders, the principles
and consequences of moving from one level (Java 6) to another (Java 8)
apply with any builder, so the following points may be useful information
to all.

If you have "old byte codes", or, even new ones, compiled at the Java 4,
Java 5, or Java 6 level, you *might* find some of those bytes codes no
longer survive the "re-pack", sign, and "pack" process (where as maybe the
would survived, when using Java 6 to run your build (and hence your
repack/pack). That is, if user tries to download the pack.gz file, and
unpack into a normal jar, it may be reported to have in "invalid
signature" or in some other way "broken".

In my experience, with Orbit jars, the "error rate" is about 1.7%. Others,
for some unknown reason, see higher rates (such as 20-30%?) . Some of
these cases *might* be bugs in the pack/unpack programs, but it's just as
likely that there are "bugs" (fringe cases) where the byte codes for lower
levels of Java are not quite "right". All I know for sure: it has never
been perfect.

But, luckily, easy to solve.
All three builders (PDE, Tycho, and Buckminster) allow you to specify an
'eclipse.inf' file in the META-INF directory, with a directive (line) that
is:
jarprocessor.exclude.pack=true

Thus, that one problematic jar is not packed, but is still signed.

So important point 1: be sure you "pack200" with the same version you used
to do "repack" (if the builder doesn't do it for you automatically).
Important point 2: I wouldn't recommend studying the byte codes and trying
to find a pattern of code that is the cause (unless you just happen to
love byte codes), ... just slap in an eclipse.inf file and move on to more
important things.
Important point 3: You should not, ever never, "re-sign" and certainly not
re-pack or pack200 a jar that has already been signed or processed by
pack200. That pretty much guarantees the jar will be broken. In more ways
than one. (Bug 461669)

The reason for making this move, now, is that it is best to "keep up" with
what our users are using, and, with versions of Java that are expected to
stay in service for a while ... otherwise, we might have to monkey around
with this during a service release, which is less than ideal.

* Bonus, for reading this far in my wordy note: Why jump two levels, from
6 to 8, why not move to Java 7 first? Well it turns out, at the moment,
the versions of pack200 and unpack200 that ship with Java 7 and Java 8 are
exactly the same. But, the advantage is, in some service release, there
might be a new version and we'd pick it up automatically, as long as we
use /shared/common/jdk1.8.0_x86-latest consistently. Double bonus:
remember that pack200 and unpack200 have little to do with Java source
code they are stand-alone executables, written in C-code, that simply
manipulate byte codes. Which is how p2 can let you specify any version of
pack200 you want, no mater which version of Java you are using.

Naturally, feel free to comment in Bug 463510 if any questions or concrete
problems known.




_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743

http://www.itemis.de
***@itemis.de

itemis AG
Am Brambusch 15-24
44536 LÃŒnen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer
Fiorentino


[attachment "signature.asc" deleted by David M Williams/Raleigh/IBM]
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Wim Jongman
2015-04-24 13:19:25 UTC
Permalink
David, Nebula got a report from a user that his build no longer works [2].
Does this relate to the changes of the signing service?

I have added the eclipse.inf file but that did not make a difference [1]

[1] ****************************************
Thanks for investigatio but the build is still broken - sorry to say. Ist
there a chance to sign with SHA-1 instead of SHA-256?

Caused by: java.lang.RuntimeException: "Messages while trying children
repositories.": ["": ["Problems downloading artifact:
osgi.bundle,org.eclipse.nebula.widgets.gallery,0.6.0.201504221032.":
["Error reading signed
content:C:\Users\fgdrf\AppData\Local\Temp\signatureFile6052487094287027653.jar"]]]



[2] *****************************************

I'm using nebula gallery widget and get follwowing errors since April, 15th.

It seems that signing has changed between version 0.6.0.201504080923 and
0.6.0.201504150758 from SHA1-Digest to SHA-256-Digest.

What are the consequences and implications for users? How can I get my
project compiling again?

Thanks in advance

Maven-Output

[INFO] Downloading org.eclipse.nebula.widgets.
gallery
[INFO] Fetching org.eclipse.nebula.widgets.gallery_0.6.0.201504200907.jar
(0B of 114,42kB at 0B/s) from
http://download.eclipse.org/technology/nebula/snapshot/plugins/
[INFO] 1 operation remaining.
[INFO] Fetching org.eclipse.nebula.widgets.gallery_0.6.0.201504200907.jar
(4kB of 114,42kB at 0B/s) from
http://download.eclipse.org/technology/nebula/snapshot/plugins/
[ERROR] Internal error: java.lang.RuntimeException: "Messages while trying
children repositories.": ["": ["Problems downloading artifact:
osgi.bundle,org.eclipse.nebula.widgets.gallery,0.6.0.201504200
907.": ["Error reading signed
content:C:\Users\fgdrf\AppData\Local\Temp\signatureFile6731347807242863988.jar"]]]
-> [Help 1]
org.apache.maven.InternalErrorException: Internal error:
java.lang.RuntimeException: "Messages while trying children repositories.":
["": ["Problems downloading artifact: osgi.bundle,org.eclipse.nebul
a.widgets.gallery,0.6.0.201504200907.": ["Error reading signed
content:C:\Users\fgdrf\AppData\Local\Temp\signatureFile6731347807242863988.jar"]]]
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: java.lang.RuntimeException: "Messages while trying children
repositories.": ["": ["Problems downloading artifact:
osgi.bundle,org.eclipse.nebula.widgets.gallery,0.6.0.201504200907.": ["Erro
r reading signed
content:C:\Users\fgdrf\AppData\Local\Temp\signatureFile6731347807242863988.jar"]]]
at
org.eclipse.tycho.p2.impl.resolver.ResolutionContextImpl.downloadArtifacts(ResolutionContextImpl.java:515)
at
org.eclipse.tycho.p2.impl.resolver.P2ResolverImpl.resolveProject(P2ResolverImpl.java:105)
at
org.eclipse.tycho.p2.impl.resolver.P2ResolverImpl.resolveProject(P2ResolverImpl.java:69)
at
org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.doResolvePlatform(P2TargetPlatformResolver.java:342)
at
org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.resolvePlatform(P2TargetPlatformResolver.java:162)
at
org.eclipse.tycho.core.resolver.DefaultTychoDependencyResolver.resolveProject(DefaultTychoDependencyResolver.java:85)
at
org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:91)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:274)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
... 11 more

_______________________________________________
nebula-dev mailing list
nebula-***@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/nebula-dev
Post by David M Williams
Since I sent the original notice, guess it is up to me to send this one.
The Eclipse Foundation has decided to revert this change.
Details in *Bug 463510*
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510>
I do not know that their plan is, nor do I know what to recommend to
anyone, at this point. I guess ask in *Bug 463510*
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510>, if anyone does
have questions.
Date: 04/11/2015 02:02 PM
Subject: Re: [cross-project-issues-dev] Notice of change to batch
"signing service"
------------------------------
... we are using Tycho for our builds, but our jobs provide the
following option when calling Maven
(which seems to be used by a couple of other hudson jobs as well;
-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/sun-jdk1.6.0_21_x64/jre/bin"
I assume we will have to adopt this to something like the following
-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/jdk1.8.0_x86-latest/jre/bin“
This was probably recommended because you were using Java 7 or 8 to "run
your build" but it was determined to "minimize issues" to use the lower
version of pack200 (Especially when many users or pre-reqs were using Java
6). So, a) yes, eventually you'll "minimize issues" by using jdk 7 or 8
version, but b) that should be "automatic" if you are using Java 7 or 8 to
run your builds, so I'd try leaving it out .. perhaps commented out, for
when you need it again when you move to Java 9 :)
As far as checking yourself, Ed has already described one basic procedure.
The b3 aggregator will also check, but only if you select the "build"
option, which can take a long time, if you are trying to build the whole
Sim. Release. It is possible, though, so set up your own b3 aggregator job
(just for testing) that uses only your contribution, plus the minimum
number of "prereq" contributions. It is not exactly easy to set this up --
the first time -- but, once set up, is relatively easy to keep up to date.
One more: There are some bash scripts in the sim release test project,
that are not very efficient, but are an easy way to check a whole directory
of jars and pack.gz jars. Those two scripts are *verify.sh*
<http://git.eclipse.org/c/simrel/org.eclipse.simrel.tests.git/plain/bundles/org.eclipse.simrel.tests-bundle/verify.sh>
and *verifydir.sh*
<http://git.eclipse.org/c/simrel/org.eclipse.simrel.tests.git/plain/bundles/org.eclipse.simrel.tests-bundle/verifydir.sh>
(both need to be in your on your path, and you execute verifydir.sh (and it
calls verfiy.sh). You may need to make your own copy and adjust for your
system, and your needs.
Another almost-off-topic tidbit: Many are surprised they "have errors"
because they have tested "installing" or "updating" using p2, and it works
fine. The reason is that p2 tries it's best to "recover from errors" so
often if there are problems with *.jar.pack.gz, then it will simply try the
*.jar file directly, which would work. But, for our Sim. Release repo (and
should for all repos) we want the repo to be "perfect" and not allow it to
contain "badly packed" jars. Doing so ends up causing "extra downloads",
and wasting users time when they do an update.
I realize it is not easy to get a "perfect repo", it takes extra effort,
but that's part of the whole purpose of having or joining the Sim. Release,
so everyone's extra effort is acknowledged, and appreciated.
Thanks for the questions!
Date: 04/11/2015 03:59 AM
Subject: Re: [cross-project-issues-dev] Notice of change to batch
"signing service"
------------------------------
David,
I admit I am not very acquainted with the internals of signing and
pack200. However, we are using Tycho for our builds, but our jobs provide
the following option when calling Maven (which seems to be used by a couple
of other hudson jobs as well; it was probably recommended in some
-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/sun-jdk1.6.0_21_x64/jre/bin"
-Xmx768m
-Dorg.eclipse.update.jarprocessor.pack200="
*/shared/common/jdk1.8.0_x86-latest*/jre/bin“
Is there a way to confirm that a build behaves as expected (do the sim-rel
repo-reports for instance cover this)?
Cheers
Alexander
Am 11.04.2015 um 08:48 schrieb David M Williams <
I wanted to let everyone know that "we" are changing the version of Java's
pack200 at the infrastructure service I call "batch signer". (*Bug
463510* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510>)
It was using Java 6 level of pack200, and we have moved to the Java 8 level of pack200.
This command is described at
*https://wiki.eclipse.org/IT_Infrastructure_Doc#ZIP_and_JAR_files_from_the_Commandline_.28Queued.29*
<https://wiki.eclipse.org/IT_Infrastructure_Doc#ZIP_and_JAR_files_from_the_Commandline_.28Queued.29>
This does not directly impact Tycho users or Buckminster users (which do
their own re-pack and pack, based on the VM the build is running, I assume)
but might effect PDE users, which traditionally have used this service to
"re-pack" (condition) and sign jars -- and, then at some short later time
are "packed". At that "some later time", it is the release engineers
responsibility to use the same version to 'pack' as was used to 'repack'.
While no direct impact to Tycho or Buckminster builders, the principles
and consequences of moving from one level (Java 6) to another (Java 8)
apply with any builder, so the following points may be useful information
to all.
If you have "old byte codes", or, even new ones, compiled at the Java 4,
Java 5, or Java 6 level, you *might* find some of those bytes codes no
longer survive the "re-pack", sign, and "pack" process (where as maybe the
would survived, when using Java 6 to run your build (and hence your
repack/pack). That is, if user tries to download the pack.gz file, and
unpack into a normal jar, it may be reported to have in "invalid signature"
or in some other way "broken".
In my experience, with Orbit jars, the "error rate" is about 1.7%. Others,
for some unknown reason, see higher rates (such as 20-30%?) . Some of these
cases *might* be bugs in the pack/unpack programs, but it's just as likely
that there are "bugs" (fringe cases) where the byte codes for lower levels
of Java are not quite "right". All I know for sure: it has never been
perfect.
But, luckily, easy to solve.
All three builders (PDE, Tycho, and Buckminster) allow you to specify an
'eclipse.inf' file in the META-INF directory, with a directive (line) that
jarprocessor.exclude.pack*=true*
Thus, that one problematic jar is not packed, but is still signed.
So important point 1: be sure you "pack200" with the same version you used
to do "repack" (if the builder doesn't do it for you automatically).
Important point 2: I wouldn't recommend studying the byte codes and trying
to find a pattern of code that is the cause (unless you just happen to love
byte codes), ... just slap in an eclipse.inf file and move on to more
important things.
Important point 3: You should not, ever never, "re-sign" and certainly not
re-pack or pack200 a jar that has already been signed or processed by
pack200. That pretty much guarantees the jar will be broken. In more ways
than one. (*Bug 461669*
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=461669>)
The reason for making this move, now, is that it is best to "keep up" with
what our users are using, and, with versions of Java that are expected to
stay in service for a while ... otherwise, we might have to monkey around
with this during a service release, which is less than ideal.
* Bonus, for reading this far in my wordy note: Why jump two levels, from
6 to 8, why not move to Java 7 first? Well it turns out, at the moment, the
versions of pack200 and unpack200 that ship with Java 7 and Java 8 are *exactly
the same* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510#c27>.
But, the advantage is, in some service release, there might be a new
version and we'd pick it up automatically, as long as we use
remember that pack200 and unpack200 have little to do with Java source code
they are stand-alone executables, written in C-code, that simply manipulate
byte codes. Which is how p2 can let you *specify any version of pack200
you want* <https://wiki.eclipse.org/JarProcessor_Options#Other_properties>,
no mater which version of Java you are using.
Naturally, feel free to comment in *Bug 463510*
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510> if any questions
or concrete problems known.
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
*https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev*
<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer
Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743
*http://www.itemis.de* <http://www.itemis.de/>
itemis AG
Am Brambusch 15-24
44536 LÃŒnen
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens
Trompeter, Sebastian Neus
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino
[attachment "signature.asc" deleted by David M Williams/Raleigh/IBM]
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
*https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev*
<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
David M Williams
2015-04-24 14:26:28 UTC
Permalink
Might be related. I can't look much now, need to be offline a few hours,
but suggest anyone having trouble with signing or packing to open a
cross-project bug, and I'll try to look at this afternoon.

Be sure to specify what builder and which VM version all parties use.

Thanks,






From: Wim Jongman <***@gmail.com>
To: Cross project issues <cross-project-issues-***@eclipse.org>,
Date: 04/24/2015 09:21 AM
Subject: Re: [cross-project-issues-dev] Notice of change to batch
"signing service" - reverted
Sent by: cross-project-issues-dev-***@eclipse.org



David, Nebula got a report from a user that his build no longer works [2].
Does this relate to the changes of the signing service?

I have added the eclipse.inf file but that did not make a difference [1]

[1] ****************************************
Thanks for investigatio but the build is still broken - sorry to say. Ist
there a chance to sign with SHA-1 instead of SHA-256?

Caused by: java.lang.RuntimeException: "Messages while trying children
repositories.": ["": ["Problems downloading artifact:
osgi.bundle,org.eclipse.nebula.widgets.gallery,0.6.0.201504221032.":
["Error reading signed
content:C:\Users\fgdrf\AppData\Local\Temp\signatureFile6052487094287027653.jar"]]]



[2] *****************************************

I'm using nebula gallery widget and get follwowing errors since April,
15th.

It seems that signing has changed between version 0.6.0.201504080923 and
0.6.0.201504150758 from SHA1-Digest to SHA-256-Digest.

What are the consequences and implications for users? How can I get my
project compiling again?

Thanks in advance

Maven-Output

[INFO] Downloading org.eclipse.nebula.widgets.
gallery
[INFO] Fetching org.eclipse.nebula.widgets.gallery_0.6.0.201504200907.jar
(0B of 114,42kB at 0B/s) from
http://download.eclipse.org/technology/nebula/snapshot/plugins/
[INFO] 1 operation remaining.
[INFO] Fetching org.eclipse.nebula.widgets.gallery_0.6.0.201504200907.jar
(4kB of 114,42kB at 0B/s) from
http://download.eclipse.org/technology/nebula/snapshot/plugins/
[ERROR] Internal error: java.lang.RuntimeException: "Messages while trying
children repositories.": ["": ["Problems downloading artifact:
osgi.bundle,org.eclipse.nebula.widgets.gallery,0.6.0.201504200
907.": ["Error reading signed
content:C:\Users\fgdrf\AppData\Local\Temp\signatureFile6731347807242863988.jar"]]]
-> [Help 1]
org.apache.maven.InternalErrorException: Internal error:
java.lang.RuntimeException: "Messages while trying children
repositories.": ["": ["Problems downloading artifact:
osgi.bundle,org.eclipse.nebul
a.widgets.gallery,0.6.0.201504200907.": ["Error reading signed
content:C:\Users\fgdrf\AppData\Local\Temp\signatureFile6731347807242863988.jar"]]]
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: java.lang.RuntimeException: "Messages while trying children
repositories.": ["": ["Problems downloading artifact:
osgi.bundle,org.eclipse.nebula.widgets.gallery,0.6.0.201504200907.":
["Erro
r reading signed
content:C:\Users\fgdrf\AppData\Local\Temp\signatureFile6731347807242863988.jar"]]]
at
org.eclipse.tycho.p2.impl.resolver.ResolutionContextImpl.downloadArtifacts(ResolutionContextImpl.java:515)
at
org.eclipse.tycho.p2.impl.resolver.P2ResolverImpl.resolveProject(P2ResolverImpl.java:105)
at
org.eclipse.tycho.p2.impl.resolver.P2ResolverImpl.resolveProject(P2ResolverImpl.java:69)
at
org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.doResolvePlatform(P2TargetPlatformResolver.java:342)
at
org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.resolvePlatform(P2TargetPlatformResolver.java:162)
at
org.eclipse.tycho.core.resolver.DefaultTychoDependencyResolver.resolveProject(DefaultTychoDependencyResolver.java:85)
at
org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:91)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:274)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
... 11 more

_______________________________________________
nebula-dev mailing list
nebula-***@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/nebula-dev

On Tue, Apr 14, 2015 at 5:56 PM, David M Williams <
***@us.ibm.com> wrote:
Since I sent the original notice, guess it is up to me to send this one.

The Eclipse Foundation has decided to revert this change.

Details in Bug 463510

I do not know that their plan is, nor do I know what to recommend to
anyone, at this point. I guess ask in Bug 463510, if anyone does have
questions.





From: David M Williams/Raleigh/***@IBMUS
To: Cross project issues <cross-project-issues-***@eclipse.org>,
Date: 04/11/2015 02:02 PM
Subject: Re: [cross-project-issues-dev] Notice of change to batch
"signing service"
... we are using Tycho for our builds, but our jobs provide the
following option when calling Maven
(which seems to be used by a couple of other hudson jobs as well;
-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/sun-jdk1.6.0_21_x64/jre/bin"
-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/jdk1.8.0_x86-latest/jre/bin“


This was probably recommended because you were using Java 7 or 8 to "run
your build" but it was determined to "minimize issues" to use the lower
version of pack200 (Especially when many users or pre-reqs were using Java
6). So, a) yes, eventually you'll "minimize issues" by using jdk 7 or 8
version, but b) that should be "automatic" if you are using Java 7 or 8 to
run your builds, so I'd try leaving it out .. perhaps commented out, for
when you need it again when you move to Java 9 :)

As far as checking yourself, Ed has already described one basic procedure.
The b3 aggregator will also check, but only if you select the "build"
option, which can take a long time, if you are trying to build the whole
Sim. Release. It is possible, though, so set up your own b3 aggregator job
(just for testing) that uses only your contribution, plus the minimum
number of "prereq" contributions. It is not exactly easy to set this up --
the first time -- but, once set up, is relatively easy to keep up to date.


One more: There are some bash scripts in the sim release test project,
that are not very efficient, but are an easy way to check a whole
directory of jars and pack.gz jars. Those two scripts are verify.sh and
verifydir.sh (both need to be in your on your path, and you execute
verifydir.sh (and it calls verfiy.sh). You may need to make your own copy
and adjust for your system, and your needs.

Another almost-off-topic tidbit: Many are surprised they "have errors"
because they have tested "installing" or "updating" using p2, and it works
fine. The reason is that p2 tries it's best to "recover from errors" so
often if there are problems with *.jar.pack.gz, then it will simply try
the *.jar file directly, which would work. But, for our Sim. Release repo
(and should for all repos) we want the repo to be "perfect" and not allow
it to contain "badly packed" jars. Doing so ends up causing "extra
downloads", and wasting users time when they do an update.

I realize it is not easy to get a "perfect repo", it takes extra effort,
but that's part of the whole purpose of having or joining the Sim.
Release, so everyone's extra effort is acknowledged, and appreciated.

Thanks for the questions!





From: Alexander Nyßen <***@itemis.de>
To: Cross project issues <cross-project-issues-***@eclipse.org>,
Date: 04/11/2015 03:59 AM
Subject: Re: [cross-project-issues-dev] Notice of change to batch
"signing service"
Sent by: cross-project-issues-dev-***@eclipse.org



David,

I admit I am not very acquainted with the internals of signing and
pack200. However, we are using Tycho for our builds, but our jobs provide
the following option when calling Maven (which seems to be used by a
couple of other hudson jobs as well; it was probably recommended in some
instructions I don’t remember):

-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/sun-jdk1.6.0_21_x64/jre/bin"
-Xmx768m

I assume we will have to adopt this to something like the following then,
right:

-Dorg.eclipse.update.jarprocessor.pack200="
/shared/common/jdk1.8.0_x86-latest/jre/bin“

Is there a way to confirm that a build behaves as expected (do the sim-rel
repo-reports for instance cover this)?

Cheers
Alexander
I wanted to let everyone know that "we" are changing the version of Java's
pack200 at the infrastructure service I call "batch signer". (Bug 463510)

It was using Java 6 level of pack200, and we have moved to the Java 8
level of pack200.

This command is described at
https://wiki.eclipse.org/IT_Infrastructure_Doc#ZIP_and_JAR_files_from_the_Commandline_.28Queued.29


This does not directly impact Tycho users or Buckminster users (which do
their own re-pack and pack, based on the VM the build is running, I
assume) but might effect PDE users, which traditionally have used this
service to "re-pack" (condition) and sign jars -- and, then at some short
later time are "packed". At that "some later time", it is the release
engineers responsibility to use the same version to 'pack' as was used to
'repack'.

While no direct impact to Tycho or Buckminster builders, the principles
and consequences of moving from one level (Java 6) to another (Java 8)
apply with any builder, so the following points may be useful information
to all.

If you have "old byte codes", or, even new ones, compiled at the Java 4,
Java 5, or Java 6 level, you *might* find some of those bytes codes no
longer survive the "re-pack", sign, and "pack" process (where as maybe the
would survived, when using Java 6 to run your build (and hence your
repack/pack). That is, if user tries to download the pack.gz file, and
unpack into a normal jar, it may be reported to have in "invalid
signature" or in some other way "broken".

In my experience, with Orbit jars, the "error rate" is about 1.7%. Others,
for some unknown reason, see higher rates (such as 20-30%?) . Some of
these cases *might* be bugs in the pack/unpack programs, but it's just as
likely that there are "bugs" (fringe cases) where the byte codes for lower
levels of Java are not quite "right". All I know for sure: it has never
been perfect.

But, luckily, easy to solve.
All three builders (PDE, Tycho, and Buckminster) allow you to specify an
'eclipse.inf' file in the META-INF directory, with a directive (line) that
is:
jarprocessor.exclude.pack=true

Thus, that one problematic jar is not packed, but is still signed.

So important point 1: be sure you "pack200" with the same version you used
to do "repack" (if the builder doesn't do it for you automatically).
Important point 2: I wouldn't recommend studying the byte codes and trying
to find a pattern of code that is the cause (unless you just happen to
love byte codes), ... just slap in an eclipse.inf file and move on to more
important things.
Important point 3: You should not, ever never, "re-sign" and certainly not
re-pack or pack200 a jar that has already been signed or processed by
pack200. That pretty much guarantees the jar will be broken. In more ways
than one. (Bug 461669)

The reason for making this move, now, is that it is best to "keep up" with
what our users are using, and, with versions of Java that are expected to
stay in service for a while ... otherwise, we might have to monkey around
with this during a service release, which is less than ideal.

* Bonus, for reading this far in my wordy note: Why jump two levels, from
6 to 8, why not move to Java 7 first? Well it turns out, at the moment,
the versions of pack200 and unpack200 that ship with Java 7 and Java 8 are
exactly the same. But, the advantage is, in some service release, there
might be a new version and we'd pick it up automatically, as long as we
use /shared/common/jdk1.8.0_x86-latest consistently. Double bonus:
remember that pack200 and unpack200 have little to do with Java source
code they are stand-alone executables, written in C-code, that simply
manipulate byte codes. Which is how p2 can let you specify any version of
pack200 you want, no mater which version of Java you are using.

Naturally, feel free to comment in Bug 463510 if any questions or concrete
problems known.




_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743

http://www.itemis.de
***@itemis.de

itemis AG
Am Brambusch 15-24
44536 LÃŒnen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer
Fiorentino


[attachment "signature.asc" deleted by David M Williams/Raleigh/IBM]
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Tom Schindl
2015-04-27 06:31:44 UTC
Permalink
Hi,

I see my build failing and succeeding at will because of pack200
problems. So I filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=465527

Tom
Post by David M Williams
Might be related. I can't look much now, need to be offline a few
hours, but suggest anyone having trouble with signing or packing to open
a cross-project bug, and I'll try to look at this afternoon.
Be sure to specify what builder and which VM version all parties use.
Thanks,
Date: 04/24/2015 09:21 AM
Subject: Re: [cross-project-issues-dev] Notice of change to batch
"signing service" - reverted
------------------------------------------------------------------------
David, Nebula got a report from a user that his build no longer works
[2]. Does this relate to the changes of the signing service?
I have added the eclipse.inf file but that did not make a difference [1]
[1] ****************************************
Thanks for investigatio but the build is still broken - sorry to say.
Ist there a chance to sign with SHA-1 instead of SHA-256?
Caused by: java.lang.RuntimeException: "Messages while trying children
["Error reading signed
content:C:\Users\fgdrf\AppData\Local\Temp\signatureFile6052487094287027653.jar"]]]
[2] *****************************************
I'm using nebula gallery widget and get follwowing errors since April, 15th.
It seems that signing has changed between version 0.6.0.201504080923 and
0.6.0.201504150758 from SHA1-Digest to SHA-256-Digest.
What are the consequences and implications for users? How can I get my
project compiling again?
Thanks in advance
Maven-Output
[INFO] Downloading org.eclipse.nebula.widgets.
gallery
[INFO] Fetching
org.eclipse.nebula.widgets.gallery_0.6.0.201504200907.jar (0B of
114,42kB at 0B/s) from
_http://download.eclipse.org/technology/nebula/snapshot/plugins/_
[INFO] 1 operation remaining.
[INFO] Fetching
org.eclipse.nebula.widgets.gallery_0.6.0.201504200907.jar (4kB of
114,42kB at 0B/s) from
_http://download.eclipse.org/technology/nebula/snapshot/plugins/_
[ERROR] Internal error: java.lang.RuntimeException: "Messages while
osgi.bundle,org.eclipse.nebula.widgets.gallery,0.6.0.201504200
907.": ["Error reading signed
content:C:\Users\fgdrf\AppData\Local\Temp\signatureFile6731347807242863988.jar"]]]
-> [Help 1]
java.lang.RuntimeException: "Messages while trying children
osgi.bundle,org.eclipse.nebul
a.widgets.gallery,0.6.0.201504200907.": ["Error reading signed
content:C:\Users\fgdrf\AppData\Local\Temp\signatureFile6731347807242863988.jar"]]]
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: java.lang.RuntimeException: "Messages while trying children
osgi.bundle,org.eclipse.nebula.widgets.gallery,0.6.0.201504200907.": ["Erro
r reading signed
content:C:\Users\fgdrf\AppData\Local\Temp\signatureFile6731347807242863988.jar"]]]
at
org.eclipse.tycho.p2.impl.resolver.ResolutionContextImpl.downloadArtifacts(ResolutionContextImpl.java:515)
at
org.eclipse.tycho.p2.impl.resolver.P2ResolverImpl.resolveProject(P2ResolverImpl.java:105)
at
org.eclipse.tycho.p2.impl.resolver.P2ResolverImpl.resolveProject(P2ResolverImpl.java:69)
at
org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.doResolvePlatform(P2TargetPlatformResolver.java:342)
at
org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.resolvePlatform(P2TargetPlatformResolver.java:162)
at
org.eclipse.tycho.core.resolver.DefaultTychoDependencyResolver.resolveProject(DefaultTychoDependencyResolver.java:85)
at
org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:91)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:274)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
... 11 more
_______________________________________________
nebula-dev mailing list_
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit_
__https://dev.eclipse.org/mailman/listinfo/nebula-dev_
On Tue, Apr 14, 2015 at 5:56 PM, David M Williams
Since I sent the original notice, guess it is up to me to send this one.
The Eclipse Foundation has decided to revert this change.
Details in *_Bug 463510_*
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510>
I do not know that their plan is, nor do I know what to recommend to
anyone, at this point. I guess ask in *_Bug 463510_*
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510>, if anyone does
have questions.
Date: 04/11/2015 02:02 PM
Subject: Re: [cross-project-issues-dev] Notice of change to batch
"signing service"
------------------------------------------------------------------------
... we are using Tycho for our builds, but our jobs provide the
following option when calling Maven
(which seems to be used by a couple of other hudson jobs as well;
-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/sun-jdk1.6.0_21_x64/jre/bin"
I assume we will have to adopt this to something like the following
-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/jdk1.8.0_x86-latest/jre/bin“
This was probably recommended because you were using Java 7 or 8 to "run
your build" but it was determined to "minimize issues" to use the lower
version of pack200 (Especially when many users or pre-reqs were using
Java 6). So, a) yes, eventually you'll "minimize issues" by using jdk 7
or 8 version, but b) that should be "automatic" if you are using Java 7
or 8 to run your builds, so I'd try leaving it out .. perhaps commented
out, for when you need it again when you move to Java 9 :)
As far as checking yourself, Ed has already described one basic
procedure. The b3 aggregator will also check, but only if you select the
"build" option, which can take a long time, if you are trying to build
the whole Sim. Release. It is possible, though, so set up your own b3
aggregator job (just for testing) that uses only your contribution, plus
the minimum number of "prereq" contributions. It is not exactly easy to
set this up -- the first time -- but, once set up, is relatively easy to
keep up to date.
One more: There are some bash scripts in the sim release test project,
that are not very efficient, but are an easy way to check a whole
directory of jars and pack.gz jars. Those two scripts are _verify.sh_
<http://git.eclipse.org/c/simrel/org.eclipse.simrel.tests.git/plain/bundles/org.eclipse.simrel.tests-bundle/verify.sh>and
_verifydir.sh_
<http://git.eclipse.org/c/simrel/org.eclipse.simrel.tests.git/plain/bundles/org.eclipse.simrel.tests-bundle/verifydir.sh>(both
need to be in your on your path, and you execute verifydir.sh (and it
calls verfiy.sh). You may need to make your own copy and adjust for your
system, and your needs.
Another almost-off-topic tidbit: Many are surprised they "have errors"
because they have tested "installing" or "updating" using p2, and it
works fine. The reason is that p2 tries it's best to "recover from
errors" so often if there are problems with *.jar.pack.gz, then it will
simply try the *.jar file directly, which would work. But, for our Sim.
Release repo (and should for all repos) we want the repo to be "perfect"
and not allow it to contain "badly packed" jars. Doing so ends up
causing "extra downloads", and wasting users time when they do an update.
I realize it is not easy to get a "perfect repo", it takes extra effort,
but that's part of the whole purpose of having or joining the Sim.
Release, so everyone's extra effort is acknowledged, and appreciated.
Thanks for the questions!
Date: 04/11/2015 03:59 AM
Subject: Re: [cross-project-issues-dev] Notice of change to batch
"signing service"
------------------------------------------------------------------------
David,
I admit I am not very acquainted with the internals of signing and
pack200. However, we are using Tycho for our builds, but our jobs
provide the following option when calling Maven (which seems to be used
by a couple of other hudson jobs as well; it was probably recommended in
-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/sun-jdk1.6.0_21_x64/jre/bin"
-Xmx768m
-Dorg.eclipse.update.jarprocessor.pack200="*/shared/common/jdk1.8.0_x86-latest*/jre/bin“
Is there a way to confirm that a build behaves as expected (do the
sim-rel repo-reports for instance cover this)?
Cheers
Alexander
Am 11.04.2015 um 08:48 schrieb David M Williams
I wanted to let everyone know that "we" are changing the version of
Java's pack200 at the infrastructure service I call "batch signer".
(*_Bug 463510_* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510>)
It was using Java 6 level of pack200, and we have moved to the Java 8 level of pack200.
This command is described at _
__https://wiki.eclipse.org/IT_Infrastructure_Doc#ZIP_and_JAR_files_from_the_Commandline_.28Queued.29_
This does not directly impact Tycho users or Buckminster users (which do
their own re-pack and pack, based on the VM the build is running, I
assume) but might effect PDE users, which traditionally have used this
service to "re-pack" (condition) and sign jars -- and, then at some
short later time are "packed". At that "some later time", it is the
release engineers responsibility to use the same version to 'pack' as
was used to 'repack'.
While no direct impact to Tycho or Buckminster builders, the principles
and consequences of moving from one level (Java 6) to another (Java 8)
apply with any builder, so the following points may be useful
information to all.
If you have "old byte codes", or, even new ones, compiled at the Java 4,
Java 5, or Java 6 level, you *might* find some of those bytes codes no
longer survive the "re-pack", sign, and "pack" process (where as maybe
the would survived, when using Java 6 to run your build (and hence your
repack/pack). That is, if user tries to download the pack.gz file, and
unpack into a normal jar, it may be reported to have in "invalid
signature" or in some other way "broken".
In my experience, with Orbit jars, the "error rate" is about 1.7%.
Others, for some unknown reason, see higher rates (such as 20-30%?) .
Some of these cases *might* be bugs in the pack/unpack programs, but
it's just as likely that there are "bugs" (fringe cases) where the byte
codes for lower levels of Java are not quite "right". All I know for
sure: it has never been perfect.
But, luckily, easy to solve.
All three builders (PDE, Tycho, and Buckminster) allow you to specify an
'eclipse.inf' file in the META-INF directory, with a directive (line)
jarprocessor.exclude.pack*=true*
Thus, that one problematic jar is not packed, but is still signed.
So important point 1: be sure you "pack200" with the same version you
used to do "repack" (if the builder doesn't do it for you automatically).
Important point 2: I wouldn't recommend studying the byte codes and
trying to find a pattern of code that is the cause (unless you just
happen to love byte codes), ... just slap in an eclipse.inf file and
move on to more important things.
Important point 3: You should not, ever never, "re-sign" and certainly
not re-pack or pack200 a jar that has already been signed or processed
by pack200. That pretty much guarantees the jar will be broken. In more
ways than one. (*_Bug 461669_*
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=461669>)
The reason for making this move, now, is that it is best to "keep up"
with what our users are using, and, with versions of Java that are
expected to stay in service for a while ... otherwise, we might have to
monkey around with this during a service release, which is less than ideal.
* Bonus, for reading this far in my wordy note: Why jump two levels,
from 6 to 8, why not move to Java 7 first? Well it turns out, at the
moment, the versions of pack200 and unpack200 that ship with Java 7 and
Java 8 are _exactly the same_
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510#c27>. But, the
advantage is, in some service release, there might be a new version and
we'd pick it up automatically, as long as we use
remember that pack200 and unpack200 have little to do with Java source
code they are stand-alone executables, written in C-code, that simply
manipulate byte codes. Which is how p2 can let you _specify any version
of pack200 you want_
<https://wiki.eclipse.org/JarProcessor_Options#Other_properties>, no
mater which version of Java you are using.
Naturally, feel free to comment in *_Bug 463510_*
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510>if any questions
or concrete problems known.
_______________________________________________
cross-project-issues-dev mailing list_
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit_
__https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer
Telefon: _+49 (0) 231 / 98 60-202_
<tel:%2B49%20%280%29%20231%20%2F%2098%2060-202>
Telefax: _+49 (0) 231 / 98 60-211_
<tel:%2B49%20%280%29%20231%20%2F%2098%2060-211>
Mobil: _+49 (0) 151 / 17396743_
<tel:%2B49%20%280%29%20151%20%2F%20%C2%A017396743>_
__http://www.itemis.de_ <http://www.itemis.de/>_
itemis AG
Am Brambusch 15-24
44536 Lünen
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek,
Jens Trompeter, Sebastian Neus
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino
[attachment "signature.asc" deleted by David M Williams/Raleigh/IBM]
_______________________________________________
cross-project-issues-dev mailing list_
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit_
__https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev________________________________________________
cross-project-issues-dev mailing list_
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit_
__https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
_______________________________________________
cross-project-issues-dev mailing list_
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit_
__https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Tom Schindl
2015-04-14 17:10:25 UTC
Permalink
Hi,

Not sure this is related but I've now seen my build failing because of
pack200 and on the next run succeeding.
[INFO] o.h.m.e.h.MavenExecutionResultHandler - Build failed with exception(s)
[INFO] o.h.m.e.h.MavenExecutionResultHandler - [1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.eclipse.tycho.extras:tycho-pack200b-plugin:0.21.0:pack (pack200-pack) on project org.eclipse.fx.core.guice: Execution pack200-pack of goal org.eclipse.tycho.extras:tycho-pack200b-plugin:0.21.0:pack failed: MALFORMED
[DEBUG] Closing connection to remote
[ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho-pack200b-plugin:0.21.0:pack (pack200-pack) on project org.eclipse.fx.core.guice: Execution pack200-pack of goal org.eclipse.tycho.extras:tycho-pack200b-plugin:0.21.0:pack failed: MALFORMED -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn <goals> -rf :org.eclipse.fx.core.guice
[DEBUG] Waiting for process to finish
[DEBUG] Result: 1
I've never seen these failures so I'm not sure they are related to the
change mentioned?

Tom
I wanted to let everyone know that "we" are changing the version of
Java's pack200 at the infrastructure service I call "batch signer".
(*_Bug 463510_* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510>)
It was using Java 6 level of pack200, and we have moved to the Java 8
level of pack200.
This command is described at
https://wiki.eclipse.org/IT_Infrastructure_Doc#ZIP_and_JAR_files_from_the_Commandline_.28Queued.29
This does not directly impact Tycho users or Buckminster users (which do
their own re-pack and pack, based on the VM the build is running, I
assume) but might effect PDE users, which traditionally have used this
service to "re-pack" (condition) and sign jars -- and, then at some
short later time are "packed". At that "some later time", it is the
release engineers responsibility to use the same version to 'pack' as
was used to 'repack'.
While no direct impact to Tycho or Buckminster builders, the principles
and consequences of moving from one level (Java 6) to another (Java 8)
apply with any builder, so the following points may be useful
information to all.
If you have "old byte codes", or, even new ones, compiled at the Java 4,
Java 5, or Java 6 level, you *might* find some of those bytes codes no
longer survive the "re-pack", sign, and "pack" process (where as maybe
the would survived, when using Java 6 to run your build (and hence your
repack/pack). That is, if user tries to download the pack.gz file, and
unpack into a normal jar, it may be reported to have in "invalid
signature" or in some other way "broken".
In my experience, with Orbit jars, the "error rate" is about 1.7%.
Others, for some unknown reason, see higher rates (such as 20-30%?) .
Some of these cases *might* be bugs in the pack/unpack programs, but
it's just as likely that there are "bugs" (fringe cases) where the byte
codes for lower levels of Java are not quite "right". All I know for
sure: it has never been perfect.
But, luckily, easy to solve.
All three builders (PDE, Tycho, and Buckminster) allow you to specify an
'eclipse.inf' file in the META-INF directory, with a directive (line)
jarprocessor.exclude.pack*=true*
Thus, that one problematic jar is not packed, but is still signed.
So important point 1: be sure you "pack200" with the same version you
used to do "repack" (if the builder doesn't do it for you automatically).
Important point 2: I wouldn't recommend studying the byte codes and
trying to find a pattern of code that is the cause (unless you just
happen to love byte codes), ... just slap in an eclipse.inf file and
move on to more important things.
Important point 3: You should not, ever never, "re-sign" and certainly
not re-pack or pack200 a jar that has already been signed or processed
by pack200. That pretty much guarantees the jar will be broken. In more
ways than one. (*_Bug 461669_*
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=461669>)
The reason for making this move, now, is that it is best to "keep up"
with what our users are using, and, with versions of Java that are
expected to stay in service for a while ... otherwise, we might have to
monkey around with this during a service release, which is less than ideal.
* Bonus, for reading this far in my wordy note: Why jump two levels,
from 6 to 8, why not move to Java 7 first? Well it turns out, at the
moment, the versions of pack200 and unpack200 that ship with Java 7 and
Java 8 are exactly the same
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510#c27>. But, the
advantage is, in some service release, there might be a new version and
we'd pick it up automatically, as long as we use
remember that pack200 and unpack200 have little to do with Java source
code they are stand-alone executables, written in C-code, that simply
manipulate byte codes. Which is how p2 can let you specify any version
of pack200 you want
<https://wiki.eclipse.org/JarProcessor_Options#Other_properties>, no
mater which version of Java you are using.
Naturally, feel free to comment in *_Bug 463510_*
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510>if any questions
or concrete problems known.
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Wim Jongman
2015-04-15 07:24:35 UTC
Permalink
Post by Tom Schindl
Hi,
Not sure this is related but I've now seen my build failing because of
pack200 and on the next run succeeding.
I have seen the same in the Nebula Gerrit build. First a pack problem and
then a normal build.

Cheers,

Wim
Tom Schindl
2015-04-15 07:58:50 UTC
Permalink
Hi,

And now the build is completely broken.

I have 2 builds:
1. runtime build (producing a p2 repo)
2. tooling build use the p2 repo from 1 and other repos
[INFO] Fetching org.eclipse.fx.core_2.0.0.201504150739.jar from http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/ (0B of 64.52kB at 0B/s)
[INFO] Fetching org.eclipse.fx.osgi.util_2.0.0.201504150739.jar from http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/ (0B of 15.54kB at 0B/s)
[INFO] Fetching javax.annotation.jre_1.2.0.201504150739.jar from http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/ (0B of 4.81kB at 0B/s)
[ERROR] Error reading signed content:/tmp/signatureFile5309382464664284679.jar
[INFO] o.h.m.e.h.MavenExecutionResultHandler - Build failed with exception(s)
[INFO] o.h.m.e.h.MavenExecutionResultHandler - [1] org.apache.maven.InternalErrorException: Internal error: org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException: Could not mirror artifact osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into the local Maven repository.See log output for details.
[DEBUG] Closing connection to remote
[ERROR] Internal error: org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException: Could not mirror artifact osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into the local Maven repository.See log output for details. An error occurred while processing the signatures for the file: /tmp/signatureFile5309382464664284679.jar: Error occurs parsing the .SF file to find out the digest algorithm in this bundle: /tmp/signatureFile5309382464664284679.jar -> [Help 1]
org.apache.maven.InternalErrorException: Internal error: org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException: Could not mirror artifact osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into the local Maven repository.See log output for details.
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException: Could not mirror artifact osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into the local Maven repository.See log output for details.
at org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadArtifact(MirroringArtifactProvider.java:218)
at org.eclipse.tycho.repository.local.MirroringArtifactProvider.makeOneFormatLocallyAvailable(MirroringArtifactProvider.java:203)
at org.eclipse.tycho.repository.local.MirroringArtifactProvider.makeLocallyAvailable(MirroringArtifactProvider.java:174)
at org.eclipse.tycho.repository.local.MirroringArtifactProvider.getArtifactFile(MirroringArtifactProvider.java:118)
at org.eclipse.tycho.repository.p2base.artifact.provider.CompositeArtifactProvider.getArtifactFile(CompositeArtifactProvider.java:70)
at org.eclipse.tycho.p2.target.TargetPlatformBaseImpl.getLocalArtifactFile(TargetPlatformBaseImpl.java:93)
at org.eclipse.tycho.p2.resolver.P2ResolverImpl.addUnit(P2ResolverImpl.java:217)
at org.eclipse.tycho.p2.resolver.P2ResolverImpl.toResolutionResult(P2ResolverImpl.java:180)
at org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:172)
at org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:103)
at org.eclipse.tycho.p2.resolver.P2DependencyResolver.doResolveDependencies(P2DependencyResolver.java:352)
at org.eclipse.tycho.p2.resolver.P2DependencyResolver.resolveDependencies(P2DependencyResolver.java:325)
at org.eclipse.tycho.core.resolver.DefaultTychoResolver.resolveProject(DefaultTychoResolver.java:107)
at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:75)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:274)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
... 11 more
Caused by: java.security.SignatureException: An error occurred while processing the signatures for the file: /tmp/signatureFile5309382464664284679.jar
at org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent(SignedBundleHook.java:219)
at org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.verifyContent(SignatureVerifier.java:78)
at org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.verify(SignatureVerifier.java:60)
at org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.close(SignatureVerifier.java:107)
at org.eclipse.equinox.internal.provisional.p2.artifact.repository.processing.ProcessingStep.close(ProcessingStep.java:85)
at org.eclipse.equinox.internal.p2.artifact.processors.md5.MD5Verifier.close(MD5Verifier.java:83)
at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.reportStatus(SimpleArtifactRepository.java:1184)
at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.downloadArtifact(SimpleArtifactRepository.java:591)
at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:724)
at org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromOneMirror(RepositoryArtifactProvider.java:209)
at org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyMirror(RepositoryArtifactProvider.java:192)
at org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.access$1(RepositoryArtifactProvider.java:187)
at org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider$1.perform(RepositoryArtifactProvider.java:167)
at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:708)
at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifacts(SimpleArtifactRepository.java:779)
at org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyChildRepository(RepositoryArtifactProvider.java:179)
at org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyFormatAvailableInRepository(RepositoryArtifactProvider.java:149)
at org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnySource(RepositoryArtifactProvider.java:135)
at org.eclipse.tycho.repository.p2base.artifact.provider.CompositeArtifactProviderBaseImpl.getArtifact(CompositeArtifactProviderBaseImpl.java:50)
at org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadCanonicalArtifact(MirroringArtifactProvider.java:236)
at org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadMostSpecificNeededFormatOfArtifact(MirroringArtifactProvider.java:229)
at org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadArtifact(MirroringArtifactProvider.java:214)
... 26 more
Caused by: java.security.SignatureException: Error occurs parsing the .SF file to find out the digest algorithm in this bundle: /tmp/signatureFile5309382464664284679.jar
at org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.processSigner(SignatureBlockProcessor.java:101)
at org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.process(SignatureBlockProcessor.java:61)
at org.eclipse.osgi.internal.signedcontent.SignedBundleFile.initializeSignedContent(SignedBundleFile.java:44)
at org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent(SignedBundleHook.java:215)
... 47 more
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/InternalErrorException
[DEBUG] Waiting for process to finish
[DEBUG] Result: 1
Finished: FAILURE
I'm not sure what I should learn from that but something is seriously
broken now!

Tom
On Tue, Apr 14, 2015 at 7:10 PM, Tom Schindl
Hi,
Not sure this is related but I've now seen my build failing because of
pack200 and on the next run succeeding.
I have seen the same in the Nebula Gerrit build. First a pack problem
and then a normal build.
Cheers,
Wim
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Ed Willink
2015-04-15 08:30:22 UTC
Permalink
Hi

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=464594

It looks as if some inconsistently hashed/signed bundles are working
their way through magic caches. Try a maximal clean.

Regards

Ed Willink
Post by Tom Schindl
Hi,
And now the build is completely broken.
1. runtime build (producing a p2 repo)
2. tooling build use the p2 repo from 1 and other repos
[INFO] Fetching org.eclipse.fx.core_2.0.0.201504150739.jar from http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/ (0B of 64.52kB at 0B/s)
[INFO] Fetching org.eclipse.fx.osgi.util_2.0.0.201504150739.jar from http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/ (0B of 15.54kB at 0B/s)
[INFO] Fetching javax.annotation.jre_1.2.0.201504150739.jar from http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/ (0B of 4.81kB at 0B/s)
[ERROR] Error reading signed content:/tmp/signatureFile5309382464664284679.jar
[INFO] o.h.m.e.h.MavenExecutionResultHandler - Build failed with exception(s)
[INFO] o.h.m.e.h.MavenExecutionResultHandler - [1] org.apache.maven.InternalErrorException: Internal error: org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException: Could not mirror artifact osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into the local Maven repository.See log output for details.
[DEBUG] Closing connection to remote
[ERROR] Internal error: org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException: Could not mirror artifact osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into the local Maven repository.See log output for details. An error occurred while processing the signatures for the file: /tmp/signatureFile5309382464664284679.jar: Error occurs parsing the .SF file to find out the digest algorithm in this bundle: /tmp/signatureFile5309382464664284679.jar -> [Help 1]
org.apache.maven.InternalErrorException: Internal error: org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException: Could not mirror artifact osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into the local Maven repository.See log output for details.
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException: Could not mirror artifact osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into the local Maven repository.See log output for details.
at org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadArtifact(MirroringArtifactProvider.java:218)
at org.eclipse.tycho.repository.local.MirroringArtifactProvider.makeOneFormatLocallyAvailable(MirroringArtifactProvider.java:203)
at org.eclipse.tycho.repository.local.MirroringArtifactProvider.makeLocallyAvailable(MirroringArtifactProvider.java:174)
at org.eclipse.tycho.repository.local.MirroringArtifactProvider.getArtifactFile(MirroringArtifactProvider.java:118)
at org.eclipse.tycho.repository.p2base.artifact.provider.CompositeArtifactProvider.getArtifactFile(CompositeArtifactProvider.java:70)
at org.eclipse.tycho.p2.target.TargetPlatformBaseImpl.getLocalArtifactFile(TargetPlatformBaseImpl.java:93)
at org.eclipse.tycho.p2.resolver.P2ResolverImpl.addUnit(P2ResolverImpl.java:217)
at org.eclipse.tycho.p2.resolver.P2ResolverImpl.toResolutionResult(P2ResolverImpl.java:180)
at org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:172)
at org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:103)
at org.eclipse.tycho.p2.resolver.P2DependencyResolver.doResolveDependencies(P2DependencyResolver.java:352)
at org.eclipse.tycho.p2.resolver.P2DependencyResolver.resolveDependencies(P2DependencyResolver.java:325)
at org.eclipse.tycho.core.resolver.DefaultTychoResolver.resolveProject(DefaultTychoResolver.java:107)
at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:75)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:274)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
... 11 more
Caused by: java.security.SignatureException: An error occurred while processing the signatures for the file: /tmp/signatureFile5309382464664284679.jar
at org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent(SignedBundleHook.java:219)
at org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.verifyContent(SignatureVerifier.java:78)
at org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.verify(SignatureVerifier.java:60)
at org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.close(SignatureVerifier.java:107)
at org.eclipse.equinox.internal.provisional.p2.artifact.repository.processing.ProcessingStep.close(ProcessingStep.java:85)
at org.eclipse.equinox.internal.p2.artifact.processors.md5.MD5Verifier.close(MD5Verifier.java:83)
at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.reportStatus(SimpleArtifactRepository.java:1184)
at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.downloadArtifact(SimpleArtifactRepository.java:591)
at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:724)
at org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromOneMirror(RepositoryArtifactProvider.java:209)
at org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyMirror(RepositoryArtifactProvider.java:192)
at org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.access$1(RepositoryArtifactProvider.java:187)
at org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider$1.perform(RepositoryArtifactProvider.java:167)
at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:708)
at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifacts(SimpleArtifactRepository.java:779)
at org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyChildRepository(RepositoryArtifactProvider.java:179)
at org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyFormatAvailableInRepository(RepositoryArtifactProvider.java:149)
at org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnySource(RepositoryArtifactProvider.java:135)
at org.eclipse.tycho.repository.p2base.artifact.provider.CompositeArtifactProviderBaseImpl.getArtifact(CompositeArtifactProviderBaseImpl.java:50)
at org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadCanonicalArtifact(MirroringArtifactProvider.java:236)
at org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadMostSpecificNeededFormatOfArtifact(MirroringArtifactProvider.java:229)
at org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadArtifact(MirroringArtifactProvider.java:214)
... 26 more
Caused by: java.security.SignatureException: Error occurs parsing the .SF file to find out the digest algorithm in this bundle: /tmp/signatureFile5309382464664284679.jar
at org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.processSigner(SignatureBlockProcessor.java:101)
at org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.process(SignatureBlockProcessor.java:61)
at org.eclipse.osgi.internal.signedcontent.SignedBundleFile.initializeSignedContent(SignedBundleFile.java:44)
at org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent(SignedBundleHook.java:215)
... 47 more
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/InternalErrorException
[DEBUG] Waiting for process to finish
[DEBUG] Result: 1
Finished: FAILURE
I'm not sure what I should learn from that but something is seriously
broken now!
Tom
On Tue, Apr 14, 2015 at 7:10 PM, Tom Schindl
Hi,
Not sure this is related but I've now seen my build failing because of
pack200 and on the next run succeeding.
I have seen the same in the Nebula Gerrit build. First a pack problem
and then a normal build.
Cheers,
Wim
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Tom Schindl
2015-04-15 09:23:37 UTC
Permalink
Hi,

I cleaned everything I can in my HIPP but things still fail. My problem
is not any orbit stuff but a bundle coming from my own runtime build.

Tom
Post by Ed Willink
Hi
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=464594
It looks as if some inconsistently hashed/signed bundles are working
their way through magic caches. Try a maximal clean.
Regards
Ed Willink
Post by Tom Schindl
Hi,
And now the build is completely broken.
1. runtime build (producing a p2 repo)
2. tooling build use the p2 repo from 1 and other repos
[INFO] Fetching org.eclipse.fx.core_2.0.0.201504150739.jar from
http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
(0B of 64.52kB at 0B/s)
[INFO] Fetching org.eclipse.fx.osgi.util_2.0.0.201504150739.jar from
http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
(0B of 15.54kB at 0B/s)
/jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.jdt.core/pom.xml
/jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.ui/pom.xml
/jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.ui/pom.xml
[INFO] Fetching javax.annotation.jre_1.2.0.201504150739.jar from
http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
(0B of 4.81kB at 0B/s)
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 from repository
[ERROR] Error reading signed
content:/tmp/signatureFile5309382464664284679.jar
[INFO] o.h.m.e.h.MavenExecutionResultHandler - Build failed with exception(s)
[INFO] o.h.m.e.h.MavenExecutionResultHandler - [1]
Could not mirror artifact
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into the local
Maven repository.See log output for details.
[DEBUG] Closing connection to remote
Could not mirror artifact
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into the local
Maven repository.See log output for details. An error occurred while
/tmp/signatureFile5309382464664284679.jar: Error occurs parsing the
/tmp/signatureFile5309382464664284679.jar -> [Help 1]
Could not mirror artifact
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into the local
Maven repository.See log output for details.
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Could not mirror artifact
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into the local
Maven repository.See log output for details.
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadArtifact(MirroringArtifactProvider.java:218)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.makeOneFormatLocallyAvailable(MirroringArtifactProvider.java:203)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.makeLocallyAvailable(MirroringArtifactProvider.java:174)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.getArtifactFile(MirroringArtifactProvider.java:118)
at
org.eclipse.tycho.repository.p2base.artifact.provider.CompositeArtifactProvider.getArtifactFile(CompositeArtifactProvider.java:70)
at
org.eclipse.tycho.p2.target.TargetPlatformBaseImpl.getLocalArtifactFile(TargetPlatformBaseImpl.java:93)
at
org.eclipse.tycho.p2.resolver.P2ResolverImpl.addUnit(P2ResolverImpl.java:217)
at
org.eclipse.tycho.p2.resolver.P2ResolverImpl.toResolutionResult(P2ResolverImpl.java:180)
at
org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:172)
at
org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:103)
at
org.eclipse.tycho.p2.resolver.P2DependencyResolver.doResolveDependencies(P2DependencyResolver.java:352)
at
org.eclipse.tycho.p2.resolver.P2DependencyResolver.resolveDependencies(P2DependencyResolver.java:325)
at
org.eclipse.tycho.core.resolver.DefaultTychoResolver.resolveProject(DefaultTychoResolver.java:107)
at
org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:75)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:274)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
... 11 more
Caused by: java.security.SignatureException: An error occurred while
/tmp/signatureFile5309382464664284679.jar
at
org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent(SignedBundleHook.java:219)
at
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.verifyContent(SignatureVerifier.java:78)
at
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.verify(SignatureVerifier.java:60)
at
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.close(SignatureVerifier.java:107)
at
org.eclipse.equinox.internal.provisional.p2.artifact.repository.processing.ProcessingStep.close(ProcessingStep.java:85)
at
org.eclipse.equinox.internal.p2.artifact.processors.md5.MD5Verifier.close(MD5Verifier.java:83)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.reportStatus(SimpleArtifactRepository.java:1184)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.downloadArtifact(SimpleArtifactRepository.java:591)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:724)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromOneMirror(RepositoryArtifactProvider.java:209)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyMirror(RepositoryArtifactProvider.java:192)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.access$1(RepositoryArtifactProvider.java:187)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider$1.perform(RepositoryArtifactProvider.java:167)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:708)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifacts(SimpleArtifactRepository.java:779)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyChildRepository(RepositoryArtifactProvider.java:179)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyFormatAvailableInRepository(RepositoryArtifactProvider.java:149)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnySource(RepositoryArtifactProvider.java:135)
at
org.eclipse.tycho.repository.p2base.artifact.provider.CompositeArtifactProviderBaseImpl.getArtifact(CompositeArtifactProviderBaseImpl.java:50)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadCanonicalArtifact(MirroringArtifactProvider.java:236)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadMostSpecificNeededFormatOfArtifact(MirroringArtifactProvider.java:229)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadArtifact(MirroringArtifactProvider.java:214)
... 26 more
Caused by: java.security.SignatureException: Error occurs parsing the
/tmp/signatureFile5309382464664284679.jar
at
org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.processSigner(SignatureBlockProcessor.java:101)
at
org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.process(SignatureBlockProcessor.java:61)
at
org.eclipse.osgi.internal.signedcontent.SignedBundleFile.initializeSignedContent(SignedBundleFile.java:44)
at
org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent(SignedBundleHook.java:215)
... 47 more
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/InternalErrorException
[DEBUG] Waiting for process to finish
[DEBUG] Result: 1
Finished: FAILURE
I'm not sure what I should learn from that but something is seriously
broken now!
Tom
On Tue, Apr 14, 2015 at 7:10 PM, Tom Schindl
Hi,
Not sure this is related but I've now seen my build failing because of
pack200 and on the next run succeeding.
I have seen the same in the Nebula Gerrit build. First a pack problem
and then a normal build.
Cheers,
Wim
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Alexander Nyßen
2015-04-15 09:46:00 UTC
Permalink
Did you try to specify '-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/sun-jdk1.6.0_21_x64/jre/bin“‘ on your runtime build to ensure it packs with Java6?

Cheers
Alexander
Post by Tom Schindl
Hi,
I cleaned everything I can in my HIPP but things still fail. My problem
is not any orbit stuff but a bundle coming from my own runtime build.
Tom
Post by Ed Willink
Hi
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=464594
It looks as if some inconsistently hashed/signed bundles are working
their way through magic caches. Try a maximal clean.
Regards
Ed Willink
Post by Tom Schindl
Hi,
And now the build is completely broken.
1. runtime build (producing a p2 repo)
2. tooling build use the p2 repo from 1 and other repos
[INFO] Fetching org.eclipse.fx.core_2.0.0.201504150739.jar from
http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
(0B of 64.52kB at 0B/s)
[INFO] Fetching org.eclipse.fx.osgi.util_2.0.0.201504150739.jar from
http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
(0B of 15.54kB at 0B/s)
/jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.jdt.core/pom.xml
/jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.ui/pom.xml
/jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.ui/pom.xml
[INFO] Fetching javax.annotation.jre_1.2.0.201504150739.jar from
http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
(0B of 4.81kB at 0B/s)
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 from repository
[ERROR] Error reading signed
content:/tmp/signatureFile5309382464664284679.jar
[INFO] o.h.m.e.h.MavenExecutionResultHandler - Build failed with exception(s)
[INFO] o.h.m.e.h.MavenExecutionResultHandler - [1]
Could not mirror artifact
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into the local
Maven repository.See log output for details.
[DEBUG] Closing connection to remote
Could not mirror artifact
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into the local
Maven repository.See log output for details. An error occurred while
/tmp/signatureFile5309382464664284679.jar: Error occurs parsing the
/tmp/signatureFile5309382464664284679.jar -> [Help 1]
Could not mirror artifact
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into the local
Maven repository.See log output for details.
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Could not mirror artifact
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into the local
Maven repository.See log output for details.
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadArtifact(MirroringArtifactProvider.java:218)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.makeOneFormatLocallyAvailable(MirroringArtifactProvider.java:203)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.makeLocallyAvailable(MirroringArtifactProvider.java:174)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.getArtifactFile(MirroringArtifactProvider.java:118)
at
org.eclipse.tycho.repository.p2base.artifact.provider.CompositeArtifactProvider.getArtifactFile(CompositeArtifactProvider.java:70)
at
org.eclipse.tycho.p2.target.TargetPlatformBaseImpl.getLocalArtifactFile(TargetPlatformBaseImpl.java:93)
at
org.eclipse.tycho.p2.resolver.P2ResolverImpl.addUnit(P2ResolverImpl.java:217)
at
org.eclipse.tycho.p2.resolver.P2ResolverImpl.toResolutionResult(P2ResolverImpl.java:180)
at
org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:172)
at
org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:103)
at
org.eclipse.tycho.p2.resolver.P2DependencyResolver.doResolveDependencies(P2DependencyResolver.java:352)
at
org.eclipse.tycho.p2.resolver.P2DependencyResolver.resolveDependencies(P2DependencyResolver.java:325)
at
org.eclipse.tycho.core.resolver.DefaultTychoResolver.resolveProject(DefaultTychoResolver.java:107)
at
org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:75)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:274)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
... 11 more
Caused by: java.security.SignatureException: An error occurred while
/tmp/signatureFile5309382464664284679.jar
at
org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent(SignedBundleHook.java:219)
at
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.verifyContent(SignatureVerifier.java:78)
at
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.verify(SignatureVerifier.java:60)
at
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.close(SignatureVerifier.java:107)
at
org.eclipse.equinox.internal.provisional.p2.artifact.repository.processing.ProcessingStep.close(ProcessingStep.java:85)
at
org.eclipse.equinox.internal.p2.artifact.processors.md5.MD5Verifier.close(MD5Verifier.java:83)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.reportStatus(SimpleArtifactRepository.java:1184)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.downloadArtifact(SimpleArtifactRepository.java:591)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:724)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromOneMirror(RepositoryArtifactProvider.java:209)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyMirror(RepositoryArtifactProvider.java:192)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.access$1(RepositoryArtifactProvider.java:187)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider$1.perform(RepositoryArtifactProvider.java:167)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:708)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifacts(SimpleArtifactRepository.java:779)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyChildRepository(RepositoryArtifactProvider.java:179)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyFormatAvailableInRepository(RepositoryArtifactProvider.java:149)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnySource(RepositoryArtifactProvider.java:135)
at
org.eclipse.tycho.repository.p2base.artifact.provider.CompositeArtifactProviderBaseImpl.getArtifact(CompositeArtifactProviderBaseImpl.java:50)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadCanonicalArtifact(MirroringArtifactProvider.java:236)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadMostSpecificNeededFormatOfArtifact(MirroringArtifactProvider.java:229)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadArtifact(MirroringArtifactProvider.java:214)
... 26 more
Caused by: java.security.SignatureException: Error occurs parsing the
/tmp/signatureFile5309382464664284679.jar
at
org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.processSigner(SignatureBlockProcessor.java:101)
at
org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.process(SignatureBlockProcessor.java:61)
at
org.eclipse.osgi.internal.signedcontent.SignedBundleFile.initializeSignedContent(SignedBundleFile.java:44)
at
org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent(SignedBundleHook.java:215)
... 47 more
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/InternalErrorException
[DEBUG] Waiting for process to finish
[DEBUG] Result: 1
Finished: FAILURE
I'm not sure what I should learn from that but something is seriously
broken now!
Tom
On Tue, Apr 14, 2015 at 7:10 PM, Tom Schindl
Hi,
Not sure this is related but I've now seen my build failing because of
pack200 and on the next run succeeding.
I have seen the same in the Nebula Gerrit build. First a pack problem
and then a normal build.
Cheers,
Wim
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743

http://www.itemis.de
***@itemis.de

itemis AG
Am Brambusch 15-24
44536 LÃŒnen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino
Tom Schindl
2015-04-15 10:23:49 UTC
Permalink
Hi,

No I have not set that for runtime nor the for tooling build. So I
would guess they both use the same?

My impression was also that the complete signing change was rolled
back to java6 so something is definately different than it was a few
days back.

I'll try to set that option it could not get worse than failing.

Tom
Post by Alexander Nyßen
Did you try to specify
'-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/sun-jdk1.6.0_21_x64/jre/bin“‘
on your runtime build to ensure it packs with Java6?
Post by Alexander Nyßen
Cheers Alexander
Am 15.04.2015 um 11:23 schrieb Tom Schindl
Hi,
I cleaned everything I can in my HIPP but things still fail. My
problem is not any orbit stuff but a bundle coming from my own
runtime build.
Tom
Post by Ed Willink
Hi
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=464594
It looks as if some inconsistently hashed/signed bundles are
working their way through magic caches. Try a maximal clean.
Regards
Ed Willink
Post by Tom Schindl
Hi,
And now the build is completely broken.
I have 2 builds: 1. runtime build (producing a p2 repo) 2.
tooling build use the p2 repo from 1 and other repos
[INFO] Fetching org.eclipse.fx.core_2.0.0.201504150739.jar
from
http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
(0B of 64.52kB at 0B/s)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
[INFO] Fetching
org.eclipse.fx.osgi.util_2.0.0.201504150739.jar from
http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
(0B of 15.54kB at 0B/s)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
/jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.jdt.core/pom.xml
/jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.ui/pom.xml
/jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.ui/pom.xml
[INFO] Fetching javax.annotation.jre_1.2.0.201504150739.jar from
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
(0B of 4.81kB at 0B/s)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
[ERROR] An error occurred while transferring artifact
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 from
repository
[ERROR] Error reading signed
content:/tmp/signatureFile5309382464664284679.jar [INFO]
o.h.m.e.h.MavenExecutionResultHandler - Build failed with
exception(s) [INFO] o.h.m.e.h.MavenExecutionResultHandler -
[1] org.apache.maven.InternalErrorException: Internal
Could not mirror artifact
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
the local Maven repository.See log output for details.
[DEBUG] Closing connection to remote [ERROR] Internal
Could not mirror artifact
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
the local Maven repository.See log output for details. An
error occurred while processing the signatures for the
file: /tmp/signatureFile5309382464664284679.jar: Error
occurs parsing the .SF file to find out the digest
/tmp/signatureFile5309382464664284679.jar -> [Help 1]
Could not mirror artifact
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
the local Maven repository.See log output for details. at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Could not mirror artifact
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
the local Maven repository.See log output for details. at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadArtifact(MirroringArtifactProvider.java:218)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.local.MirroringArtifactProvider.makeOneFormatLocallyAvailable(MirroringArtifactProvider.java:203)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.local.MirroringArtifactProvider.makeLocallyAvailable(MirroringArtifactProvider.java:174)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.local.MirroringArtifactProvider.getArtifactFile(MirroringArtifactProvider.java:118)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.p2base.artifact.provider.CompositeArtifactProvider.getArtifactFile(CompositeArtifactProvider.java:70)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.p2.target.TargetPlatformBaseImpl.getLocalArtifactFile(TargetPlatformBaseImpl.java:93)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.p2.resolver.P2ResolverImpl.addUnit(P2ResolverImpl.java:217)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.p2.resolver.P2ResolverImpl.toResolutionResult(P2ResolverImpl.java:180)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:172)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:103)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.p2.resolver.P2DependencyResolver.doResolveDependencies(P2DependencyResolver.java:352)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.p2.resolver.P2DependencyResolver.resolveDependencies(P2DependencyResolver.java:325)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.core.resolver.DefaultTychoResolver.resolveProject(DefaultTychoResolver.java:107)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:75)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:274)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
... 11 more
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
Caused by: java.security.SignatureException: An error
/tmp/signatureFile5309382464664284679.jar at
org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent(SignedBundleHook.java:219)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.verifyContent(SignatureVerifier.java:78)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.verify(SignatureVerifier.java:60)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.close(SignatureVerifier.java:107)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.equinox.internal.provisional.p2.artifact.repository.processing.ProcessingStep.close(ProcessingStep.java:85)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.equinox.internal.p2.artifact.processors.md5.MD5Verifier.close(MD5Verifier.java:83)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.reportStatus(SimpleArtifactRepository.java:1184)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.downloadArtifact(SimpleArtifactRepository.java:591)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:724)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromOneMirror(RepositoryArtifactProvider.java:209)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyMirror(RepositoryArtifactProvider.java:192)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.access$1(RepositoryArtifactProvider.java:187)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider$1.perform(RepositoryArtifactProvider.java:167)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:708)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifacts(SimpleArtifactRepository.java:779)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyChildRepository(RepositoryArtifactProvider.java:179)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyFormatAvailableInRepository(RepositoryArtifactProvider.java:149)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnySource(RepositoryArtifactProvider.java:135)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.p2base.artifact.provider.CompositeArtifactProviderBaseImpl.getArtifact(CompositeArtifactProviderBaseImpl.java:50)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadCanonicalArtifact(MirroringArtifactProvider.java:236)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadMostSpecificNeededFormatOfArtifact(MirroringArtifactProvider.java:229)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadArtifact(MirroringArtifactProvider.java:214)
... 26 more
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
Caused by: java.security.SignatureException: Error occurs
parsing the .SF file to find out the digest algorithm in
this bundle: /tmp/signatureFile5309382464664284679.jar at
org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.processSigner(SignatureBlockProcessor.java:101)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.process(SignatureBlockProcessor.java:61)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.osgi.internal.signedcontent.SignedBundleFile.initializeSignedContent(SignedBundleFile.java:44)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent(SignedBundleHook.java:215)
... 47 more
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
[ERROR] [ERROR] To see the full stack trace of the errors,
re-run Maven with the -e switch. [ERROR] Re-run Maven using
the -X switch to enable full debug logging. [ERROR] [ERROR]
For more information about the errors and possible
solutions, please read the following articles: [ERROR]
[Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/InternalErrorException
[DEBUG] Waiting for process to finish
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
I'm not sure what I should learn from that but something is
seriously broken now!
Tom
On Tue, Apr 14, 2015 at 7:10 PM, Tom Schindl
Hi,
Not sure this is related but I've now seen my build
failing because of pack200 and on the next run succeeding.
I have seen the same in the Nebula Gerrit build. First a
pack problem and then a normal build.
Cheers,
Wim
_______________________________________________
cross-project-issues-dev mailing list
your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
Post by Alexander Nyßen
Post by Ed Willink
cross-project-issues-dev mailing list
delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Post by Alexander Nyßen
Thomas Schindl, CTO BestSolution.at <http://BestSolution.at> EDV
Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/ Reg. Nr. FN 222302s am
Firmenbuchgericht Innsbruck
_______________________________________________
cross-project-issues-dev mailing list
options, retrieve your password, or unsubscribe from this list,
visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
-- Dr. Alexander Nyßen Dipl.-Inform. Principal Engineer
Telefon: +49 (0) 231 / 98 60-202 Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743
itemis AG Am Brambusch 15-24 44536 Lünen
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg
Pietrek, Jens Trompeter, Sebastian Neus
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino
_______________________________________________
cross-project-issues-dev mailing list
options, retrieve your password, or unsubscribe from this list,
visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Tom Schindl
2015-04-15 10:44:26 UTC
Permalink
Hi,

I added that to both builds but this didn't change anything! I also
doubt that this should have changed something because the problem is
related to signing and not pack200.

Tom
Post by Alexander Nyßen
Did you try to specify
'-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/sun-jdk1.6.0_21_x64/jre/bin“‘
on your runtime build to ensure it packs with Java6?
Post by Alexander Nyßen
Cheers Alexander
Am 15.04.2015 um 11:23 schrieb Tom Schindl
Hi,
I cleaned everything I can in my HIPP but things still fail. My
problem is not any orbit stuff but a bundle coming from my own
runtime build.
Tom
Post by Ed Willink
Hi
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=464594
It looks as if some inconsistently hashed/signed bundles are
working their way through magic caches. Try a maximal clean.
Regards
Ed Willink
Post by Tom Schindl
Hi,
And now the build is completely broken.
I have 2 builds: 1. runtime build (producing a p2 repo) 2.
tooling build use the p2 repo from 1 and other repos
[INFO] Fetching org.eclipse.fx.core_2.0.0.201504150739.jar
from
http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
(0B of 64.52kB at 0B/s)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
[INFO] Fetching
org.eclipse.fx.osgi.util_2.0.0.201504150739.jar from
http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
(0B of 15.54kB at 0B/s)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
/jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.jdt.core/pom.xml
/jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.ui/pom.xml
/jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.ui/pom.xml
[INFO] Fetching javax.annotation.jre_1.2.0.201504150739.jar from
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
(0B of 4.81kB at 0B/s)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
[ERROR] An error occurred while transferring artifact
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 from
repository
[ERROR] Error reading signed
content:/tmp/signatureFile5309382464664284679.jar [INFO]
o.h.m.e.h.MavenExecutionResultHandler - Build failed with
exception(s) [INFO] o.h.m.e.h.MavenExecutionResultHandler -
[1] org.apache.maven.InternalErrorException: Internal
Could not mirror artifact
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
the local Maven repository.See log output for details.
[DEBUG] Closing connection to remote [ERROR] Internal
Could not mirror artifact
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
the local Maven repository.See log output for details. An
error occurred while processing the signatures for the
file: /tmp/signatureFile5309382464664284679.jar: Error
occurs parsing the .SF file to find out the digest
/tmp/signatureFile5309382464664284679.jar -> [Help 1]
Could not mirror artifact
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
the local Maven repository.See log output for details. at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Could not mirror artifact
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
the local Maven repository.See log output for details. at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadArtifact(MirroringArtifactProvider.java:218)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.local.MirroringArtifactProvider.makeOneFormatLocallyAvailable(MirroringArtifactProvider.java:203)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.local.MirroringArtifactProvider.makeLocallyAvailable(MirroringArtifactProvider.java:174)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.local.MirroringArtifactProvider.getArtifactFile(MirroringArtifactProvider.java:118)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.p2base.artifact.provider.CompositeArtifactProvider.getArtifactFile(CompositeArtifactProvider.java:70)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.p2.target.TargetPlatformBaseImpl.getLocalArtifactFile(TargetPlatformBaseImpl.java:93)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.p2.resolver.P2ResolverImpl.addUnit(P2ResolverImpl.java:217)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.p2.resolver.P2ResolverImpl.toResolutionResult(P2ResolverImpl.java:180)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:172)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:103)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.p2.resolver.P2DependencyResolver.doResolveDependencies(P2DependencyResolver.java:352)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.p2.resolver.P2DependencyResolver.resolveDependencies(P2DependencyResolver.java:325)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.core.resolver.DefaultTychoResolver.resolveProject(DefaultTychoResolver.java:107)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:75)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:274)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
... 11 more
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
Caused by: java.security.SignatureException: An error
/tmp/signatureFile5309382464664284679.jar at
org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent(SignedBundleHook.java:219)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.verifyContent(SignatureVerifier.java:78)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.verify(SignatureVerifier.java:60)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.close(SignatureVerifier.java:107)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.equinox.internal.provisional.p2.artifact.repository.processing.ProcessingStep.close(ProcessingStep.java:85)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.equinox.internal.p2.artifact.processors.md5.MD5Verifier.close(MD5Verifier.java:83)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.reportStatus(SimpleArtifactRepository.java:1184)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.downloadArtifact(SimpleArtifactRepository.java:591)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:724)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromOneMirror(RepositoryArtifactProvider.java:209)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyMirror(RepositoryArtifactProvider.java:192)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.access$1(RepositoryArtifactProvider.java:187)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider$1.perform(RepositoryArtifactProvider.java:167)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:708)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifacts(SimpleArtifactRepository.java:779)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyChildRepository(RepositoryArtifactProvider.java:179)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyFormatAvailableInRepository(RepositoryArtifactProvider.java:149)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnySource(RepositoryArtifactProvider.java:135)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.p2base.artifact.provider.CompositeArtifactProviderBaseImpl.getArtifact(CompositeArtifactProviderBaseImpl.java:50)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadCanonicalArtifact(MirroringArtifactProvider.java:236)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadMostSpecificNeededFormatOfArtifact(MirroringArtifactProvider.java:229)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadArtifact(MirroringArtifactProvider.java:214)
... 26 more
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
Caused by: java.security.SignatureException: Error occurs
parsing the .SF file to find out the digest algorithm in
this bundle: /tmp/signatureFile5309382464664284679.jar at
org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.processSigner(SignatureBlockProcessor.java:101)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.process(SignatureBlockProcessor.java:61)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.osgi.internal.signedcontent.SignedBundleFile.initializeSignedContent(SignedBundleFile.java:44)
at
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent(SignedBundleHook.java:215)
... 47 more
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
[ERROR] [ERROR] To see the full stack trace of the errors,
re-run Maven with the -e switch. [ERROR] Re-run Maven using
the -X switch to enable full debug logging. [ERROR] [ERROR]
For more information about the errors and possible
solutions, please read the following articles: [ERROR]
[Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/InternalErrorException
[DEBUG] Waiting for process to finish
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
I'm not sure what I should learn from that but something is
seriously broken now!
Tom
On Tue, Apr 14, 2015 at 7:10 PM, Tom Schindl
Hi,
Not sure this is related but I've now seen my build
failing because of pack200 and on the next run succeeding.
I have seen the same in the Nebula Gerrit build. First a
pack problem and then a normal build.
Cheers,
Wim
_______________________________________________
cross-project-issues-dev mailing list
your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
Post by Alexander Nyßen
Post by Ed Willink
cross-project-issues-dev mailing list
delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Post by Alexander Nyßen
Thomas Schindl, CTO BestSolution.at <http://BestSolution.at> EDV
Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/ Reg. Nr. FN 222302s am
Firmenbuchgericht Innsbruck
_______________________________________________
cross-project-issues-dev mailing list
options, retrieve your password, or unsubscribe from this list,
visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
-- Dr. Alexander Nyßen Dipl.-Inform. Principal Engineer
Telefon: +49 (0) 231 / 98 60-202 Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743
itemis AG Am Brambusch 15-24 44536 Lünen
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg
Pietrek, Jens Trompeter, Sebastian Neus
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino
_______________________________________________
cross-project-issues-dev mailing list
options, retrieve your password, or unsubscribe from this list,
visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Wim Jongman
2015-04-15 19:15:50 UTC
Permalink
Tom did you remove your local maven repo?
Post by Tom Schindl
Hi,
I added that to both builds but this didn't change anything! I also
doubt that this should have changed something because the problem is
related to signing and not pack200.
Tom
Post by Alexander Nyßen
Did you try to specify
'-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/sun-jdk1.6.0_21_x64/jre/bin“‘
on your runtime build to ensure it packs with Java6?
Post by Alexander Nyßen
Cheers Alexander
Am 15.04.2015 um 11:23 schrieb Tom Schindl
Hi,
I cleaned everything I can in my HIPP but things still fail. My
problem is not any orbit stuff but a bundle coming from my own
runtime build.
Tom
Post by Ed Willink
Hi
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=464594
It looks as if some inconsistently hashed/signed bundles are
working their way through magic caches. Try a maximal clean.
Regards
Ed Willink
Post by Tom Schindl
Hi,
And now the build is completely broken.
I have 2 builds: 1. runtime build (producing a p2 repo) 2.
tooling build use the p2 repo from 1 and other repos
[INFO] Fetching org.eclipse.fx.core_2.0.0.201504150739.jar from
http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
(0B of 64.52kB at 0B/s)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
[INFO] Fetching
org.eclipse.fx.osgi.util_2.0.0.201504150739.jar from
http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
(0B of 15.54kB at 0B/s)
/jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.jdt.core/pom.xml
/jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.ui/pom.xml
/jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.ui/pom.xml
[INFO] Fetching javax.annotation.jre_1.2.0.201504150739.jar from
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
(0B of 4.81kB at 0B/s)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
[ERROR] An error occurred while transferring artifact
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 from
repository
[ERROR] Error reading signed
content:/tmp/signatureFile5309382464664284679.jar [INFO]
o.h.m.e.h.MavenExecutionResultHandler - Build failed with
exception(s) [INFO] o.h.m.e.h.MavenExecutionResultHandler -
[1] org.apache.maven.InternalErrorException: Internal
Could not mirror artifact
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
the local Maven repository.See log output for details.
[DEBUG] Closing connection to remote [ERROR] Internal
Could not mirror artifact
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
the local Maven repository.See log output for details. An
error occurred while processing the signatures for the
file: /tmp/signatureFile5309382464664284679.jar: Error
occurs parsing the .SF file to find out the digest
/tmp/signatureFile5309382464664284679.jar -> [Help 1]
Could not mirror artifact
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
the local Maven repository.See log output for details. at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Could not mirror artifact
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
the local Maven repository.See log output for details. at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadArtifact(MirroringArtifactProvider.java:218)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.makeOneFormatLocallyAvailable(MirroringArtifactProvider.java:203)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.makeLocallyAvailable(MirroringArtifactProvider.java:174)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.getArtifactFile(MirroringArtifactProvider.java:118)
at
org.eclipse.tycho.repository.p2base.artifact.provider.CompositeArtifactProvider.getArtifactFile(CompositeArtifactProvider.java:70)
at
org.eclipse.tycho.p2.target.TargetPlatformBaseImpl.getLocalArtifactFile(TargetPlatformBaseImpl.java:93)
at
org.eclipse.tycho.p2.resolver.P2ResolverImpl.addUnit(P2ResolverImpl.java:217)
at
org.eclipse.tycho.p2.resolver.P2ResolverImpl.toResolutionResult(P2ResolverImpl.java:180)
at
org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:172)
at
org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:103)
at
org.eclipse.tycho.p2.resolver.P2DependencyResolver.doResolveDependencies(P2DependencyResolver.java:352)
at
org.eclipse.tycho.p2.resolver.P2DependencyResolver.resolveDependencies(P2DependencyResolver.java:325)
at
org.eclipse.tycho.core.resolver.DefaultTychoResolver.resolveProject(DefaultTychoResolver.java:107)
at
org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:75)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:274)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
... 11 more
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
Caused by: java.security.SignatureException: An error
/tmp/signatureFile5309382464664284679.jar at
org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent(SignedBundleHook.java:219)
at
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.verifyContent(SignatureVerifier.java:78)
at
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.verify(SignatureVerifier.java:60)
at
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.close(SignatureVerifier.java:107)
at
org.eclipse.equinox.internal.provisional.p2.artifact.repository.processing.ProcessingStep.close(ProcessingStep.java:85)
at
org.eclipse.equinox.internal.p2.artifact.processors.md5.MD5Verifier.close(MD5Verifier.java:83)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.reportStatus(SimpleArtifactRepository.java:1184)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.downloadArtifact(SimpleArtifactRepository.java:591)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:724)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromOneMirror(RepositoryArtifactProvider.java:209)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyMirror(RepositoryArtifactProvider.java:192)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.access$1(RepositoryArtifactProvider.java:187)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider$1.perform(RepositoryArtifactProvider.java:167)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:708)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifacts(SimpleArtifactRepository.java:779)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyChildRepository(RepositoryArtifactProvider.java:179)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyFormatAvailableInRepository(RepositoryArtifactProvider.java:149)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnySource(RepositoryArtifactProvider.java:135)
at
org.eclipse.tycho.repository.p2base.artifact.provider.CompositeArtifactProviderBaseImpl.getArtifact(CompositeArtifactProviderBaseImpl.java:50)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadCanonicalArtifact(MirroringArtifactProvider.java:236)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadMostSpecificNeededFormatOfArtifact(MirroringArtifactProvider.java:229)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadArtifact(MirroringArtifactProvider.java:214)
... 26 more
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
Caused by: java.security.SignatureException: Error occurs
parsing the .SF file to find out the digest algorithm in
this bundle: /tmp/signatureFile5309382464664284679.jar at
org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.processSigner(SignatureBlockProcessor.java:101)
at
org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.process(SignatureBlockProcessor.java:61)
at
org.eclipse.osgi.internal.signedcontent.SignedBundleFile.initializeSignedContent(SignedBundleFile.java:44)
at
org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent(SignedBundleHook.java:215)
... 47 more
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
[ERROR] [ERROR] To see the full stack trace of the errors,
re-run Maven with the -e switch. [ERROR] Re-run Maven using
the -X switch to enable full debug logging. [ERROR] [ERROR]
For more information about the errors and possible
solutions, please read the following articles: [ERROR]
[Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/InternalErrorException
[DEBUG] Waiting for process to finish
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
I'm not sure what I should learn from that but something is
seriously broken now!
Tom
On Tue, Apr 14, 2015 at 7:10 PM, Tom Schindl
Hi,
Not sure this is related but I've now seen my build
failing because of pack200 and on the next run succeeding.
I have seen the same in the Nebula Gerrit build. First a
pack problem and then a normal build.
Cheers,
Wim
_______________________________________________
cross-project-issues-dev mailing list
your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
Post by Alexander Nyßen
Post by Ed Willink
cross-project-issues-dev mailing list
delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Post by Alexander Nyßen
Thomas Schindl, CTO BestSolution.at <http://BestSolution.at> EDV
Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/ Reg. Nr. FN 222302s am
Firmenbuchgericht Innsbruck
_______________________________________________
cross-project-issues-dev mailing list
options, retrieve your password, or unsubscribe from this list,
visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
-- Dr. Alexander Nyßen Dipl.-Inform. Principal Engineer
Telefon: +49 (0) 231 / 98 60-202 Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743
itemis AG Am Brambusch 15-24 44536 LÃŒnen
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg
Pietrek, Jens Trompeter, Sebastian Neus
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino
_______________________________________________
cross-project-issues-dev mailing list
options, retrieve your password, or unsubscribe from this list,
visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Tom Schindl
2015-04-16 06:17:53 UTC
Permalink
a) I'm using a workspace local .m2-repo
b) I've enabled "Clean workspace before build"

Things are still broken.

Tom
Post by Wim Jongman
Tom did you remove your local maven repo?
On Wed, Apr 15, 2015 at 12:44 PM, Tom Schindl
Hi,
I added that to both builds but this didn't change anything! I also
doubt that this should have changed something because the problem is
related to signing and not pack200.
Tom
Post by Alexander Nyßen
Did you try to specify
'-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/sun-jdk1.6.0_21_x64/jre/bin“‘
on your runtime build to ensure it packs with Java6?
Post by Alexander Nyßen
Cheers Alexander
Am 15.04.2015 um 11:23 schrieb Tom Schindl
Hi,
I cleaned everything I can in my HIPP but things still fail. My
problem is not any orbit stuff but a bundle coming from my own
runtime build.
Tom
Post by Ed Willink
Hi
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=464594
It looks as if some inconsistently hashed/signed bundles are
working their way through magic caches. Try a maximal clean.
Regards
Ed Willink
Post by Tom Schindl
Hi,
And now the build is completely broken.
I have 2 builds: 1. runtime build (producing a p2 repo) 2.
tooling build use the p2 repo from 1 and other repos
[INFO] Fetching org.eclipse.fx.core_2.0.0.201504150739.jar from
http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
(0B of 64.52kB at 0B/s)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
[INFO] Fetching
org.eclipse.fx.osgi.util_2.0.0.201504150739.jar from
http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
(0B of 15.54kB at 0B/s)
/jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.jdt.core/pom.xml
/jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.ui/pom.xml
/jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.ui/pom.xml
[INFO] Fetching javax.annotation.jre_1.2.0.201504150739.jar from
http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
(0B of 4.81kB at 0B/s)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 from repository
[ERROR] Error reading signed
content:/tmp/signatureFile5309382464664284679.jar [INFO]
o.h.m.e.h.MavenExecutionResultHandler - Build failed with
exception(s) [INFO] o.h.m.e.h.MavenExecutionResultHandler -
[1] org.apache.maven.InternalErrorException: Internal
Could not mirror artifact
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
the local Maven repository.See log output for details.
[DEBUG] Closing connection to remote [ERROR] Internal
Could not mirror artifact
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
the local Maven repository.See log output for details. An
error occurred while processing the signatures for the
file: /tmp/signatureFile5309382464664284679.jar: Error
occurs parsing the .SF file to find out the digest
/tmp/signatureFile5309382464664284679.jar -> [Help 1]
Could not mirror artifact
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
the local Maven repository.See log output for details. at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Could not mirror artifact
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
the local Maven repository.See log output for details. at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadArtifact(MirroringArtifactProvider.java:218)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.makeOneFormatLocallyAvailable(MirroringArtifactProvider.java:203)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.makeLocallyAvailable(MirroringArtifactProvider.java:174)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.getArtifactFile(MirroringArtifactProvider.java:118)
at
org.eclipse.tycho.repository.p2base.artifact.provider.CompositeArtifactProvider.getArtifactFile(CompositeArtifactProvider.java:70)
at
org.eclipse.tycho.p2.target.TargetPlatformBaseImpl.getLocalArtifactFile(TargetPlatformBaseImpl.java:93)
at
org.eclipse.tycho.p2.resolver.P2ResolverImpl.addUnit(P2ResolverImpl.java:217)
at
org.eclipse.tycho.p2.resolver.P2ResolverImpl.toResolutionResult(P2ResolverImpl.java:180)
at
org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:172)
at
org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:103)
at
org.eclipse.tycho.p2.resolver.P2DependencyResolver.doResolveDependencies(P2DependencyResolver.java:352)
at
org.eclipse.tycho.p2.resolver.P2DependencyResolver.resolveDependencies(P2DependencyResolver.java:325)
at
org.eclipse.tycho.core.resolver.DefaultTychoResolver.resolveProject(DefaultTychoResolver.java:107)
at
org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:75)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:274)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
... 11 more
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
Caused by: java.security.SignatureException: An error
/tmp/signatureFile5309382464664284679.jar at
org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent(SignedBundleHook.java:219)
at
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.verifyContent(SignatureVerifier.java:78)
at
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.verify(SignatureVerifier.java:60)
at
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.close(SignatureVerifier.java:107)
at
org.eclipse.equinox.internal.provisional.p2.artifact.repository.processing.ProcessingStep.close(ProcessingStep.java:85)
at
org.eclipse.equinox.internal.p2.artifact.processors.md5.MD5Verifier.close(MD5Verifier.java:83)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.reportStatus(SimpleArtifactRepository.java:1184)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.downloadArtifact(SimpleArtifactRepository.java:591)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:724)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromOneMirror(RepositoryArtifactProvider.java:209)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyMirror(RepositoryArtifactProvider.java:192)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.access$1(RepositoryArtifactProvider.java:187)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider$1.perform(RepositoryArtifactProvider.java:167)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:708)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifacts(SimpleArtifactRepository.java:779)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyChildRepository(RepositoryArtifactProvider.java:179)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyFormatAvailableInRepository(RepositoryArtifactProvider.java:149)
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnySource(RepositoryArtifactProvider.java:135)
at
org.eclipse.tycho.repository.p2base.artifact.provider.CompositeArtifactProviderBaseImpl.getArtifact(CompositeArtifactProviderBaseImpl.java:50)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadCanonicalArtifact(MirroringArtifactProvider.java:236)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadMostSpecificNeededFormatOfArtifact(MirroringArtifactProvider.java:229)
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadArtifact(MirroringArtifactProvider.java:214)
... 26 more
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
Caused by: java.security.SignatureException: Error occurs
parsing the .SF file to find out the digest algorithm in
this bundle: /tmp/signatureFile5309382464664284679.jar at
org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.processSigner(SignatureBlockProcessor.java:101)
at
org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.process(SignatureBlockProcessor.java:61)
at
org.eclipse.osgi.internal.signedcontent.SignedBundleFile.initializeSignedContent(SignedBundleFile.java:44)
at
org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent(SignedBundleHook.java:215)
... 47 more
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
[ERROR] [ERROR] To see the full stack trace of the errors,
re-run Maven with the -e switch. [ERROR] Re-run Maven using
the -X switch to enable full debug logging. [ERROR] [ERROR]
For more information about the errors and possible
solutions, please read the following articles: [ERROR]
[Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/InternalErrorException
[DEBUG] Waiting for process to finish
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
I'm not sure what I should learn from that but something is
seriously broken now!
Tom
On Tue, Apr 14, 2015 at 7:10 PM, Tom Schindl
Hi,
Not sure this is related but I've now seen my build
failing because of pack200 and on the next run succeeding.
I have seen the same in the Nebula Gerrit build. First a
pack problem and then a normal build.
Cheers,
Wim
_______________________________________________
cross-project-issues-dev mailing list
your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
Post by Alexander Nyßen
Post by Ed Willink
cross-project-issues-dev mailing list
delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Post by Alexander Nyßen
Thomas Schindl, CTO BestSolution.at <http://BestSolution.at> EDV
Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/ Reg. Nr. FN 222302s am
Firmenbuchgericht Innsbruck
_______________________________________________
cross-project-issues-dev mailing list
options, retrieve your password, or unsubscribe from this list,
visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
-- Dr. Alexander Nyßen Dipl.-Inform. Principal Engineer
Telefon: +49 (0) 231 / 98 60-202
<tel:%2B49%20%280%29%20231%20%2F%2098%2060-202> Telefax: +49 (0) 231
/ 98 60-211 <tel:%2B49%20%280%29%20231%20%2F%2098%2060-211>
Post by Alexander Nyßen
Mobil: +49 (0) 151 / 17396743 <tel:%2B49%20%280%29%20151%20%2F%20%2017396743>
itemis AG Am Brambusch 15-24 44536 Lünen
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg
Pietrek, Jens Trompeter, Sebastian Neus
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus,
Jennifer Fiorentino
_______________________________________________
cross-project-issues-dev mailing list
options, retrieve your password, or unsubscribe from this list,
visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
David M Williams
2015-04-16 06:32:00 UTC
Permalink
I assume javax.annotation.jre is a bundle you sign? (And, you don't
re-sign it, right?) We're learning that does not work reliably.
And you have rebuild/resigned say, today, to make sure al the Java 6
transitions were back in place.

I assume you use Tycho to build with? If not using Tycho, it could be
several other things, but Tycho does very well. (IMHO).

Besides your "local maven repo" do you put your "tmp" directory in your
workspace, so it is cleaned (deleted) also? (Currently, its that tmp
directory where p2 "leaves stuff" (be default).

Given none of those are issues, sound like a case that "it just can not be
packed". Not ever bundle can be. And easiest to add that eclipse.inf to
the META-INF directory with
jarprocessor.exclude.pack=true
So, it's signed .. just not packed.




From: Tom Schindl <***@bestsolution.at>
To: Cross project issues <cross-project-issues-***@eclipse.org>,
Date: 04/16/2015 02:18 AM
Subject: Re: [cross-project-issues-dev] Notice of change to batch
"signing service"
Sent by: cross-project-issues-dev-***@eclipse.org



a) I'm using a workspace local .m2-repo
b) I've enabled "Clean workspace before build"

Things are still broken.

Tom
Post by Wim Jongman
Tom did you remove your local maven repo?
On Wed, Apr 15, 2015 at 12:44 PM, Tom Schindl
Hi,
I added that to both builds but this didn't change anything! I also
doubt that this should have changed something because the problem is
related to signing and not pack200.
Tom
Post by Alexander Nyßen
Did you try to specify
'-Dorg.eclipse.update.jarprocessor.pack200="/shared/common/sun-jdk1.6.0_21_x64/jre/bin“‘
Post by Wim Jongman
on your runtime build to ensure it packs with Java6?
Post by Alexander Nyßen
Cheers Alexander
Am 15.04.2015 um 11:23 schrieb Tom Schindl
Hi,
I cleaned everything I can in my HIPP but things still fail. My
problem is not any orbit stuff but a bundle coming from my own
runtime build.
Tom
Post by Ed Willink
Hi
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=464594
It looks as if some inconsistently hashed/signed bundles are
working their way through magic caches. Try a maximal clean.
Regards
Ed Willink
Post by Tom Schindl
Hi,
And now the build is completely broken.
I have 2 builds: 1. runtime build (producing a p2 repo) 2.
tooling build use the p2 repo from 1 and other repos
[INFO] Fetching org.eclipse.fx.core_2.0.0.201504150739.jar from
http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
(0B of 64.52kB at 0B/s)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
[INFO] Fetching
org.eclipse.fx.osgi.util_2.0.0.201504150739.jar from
http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
(0B of 15.54kB at 0B/s)
/jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.jdt.core/pom.xml
/jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.ui/pom.xml
/jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.ui/pom.xml
Post by Wim Jongman
[INFO] Fetching javax.annotation.jre_1.2.0.201504150739.jar from
http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
(0B of 4.81kB at 0B/s)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 from repository
[ERROR] Error reading signed
content:/tmp/signatureFile5309382464664284679.jar [INFO]
o.h.m.e.h.MavenExecutionResultHandler - Build failed with
exception(s) [INFO] o.h.m.e.h.MavenExecutionResultHandler -
[1] org.apache.maven.InternalErrorException: Internal
Could not mirror artifact
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
the local Maven repository.See log output for details.
[DEBUG] Closing connection to remote [ERROR] Internal
Could not mirror artifact
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
the local Maven repository.See log output for details. An
error occurred while processing the signatures for the
file: /tmp/signatureFile5309382464664284679.jar: Error
occurs parsing the .SF file to find out the digest
/tmp/signatureFile5309382464664284679.jar -> [Help 1]
Could not mirror artifact
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
the local Maven repository.See log output for details. at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
Post by Wim Jongman
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Post by Wim Jongman
at java.lang.reflect.Method.invoke(Method.java:497)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
Post by Wim Jongman
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
Post by Wim Jongman
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
Post by Wim Jongman
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Post by Wim Jongman
Could not mirror artifact
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
the local Maven repository.See log output for details. at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadArtifact(MirroringArtifactProvider.java:218)
Post by Wim Jongman
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.makeOneFormatLocallyAvailable(MirroringArtifactProvider.java:203)
Post by Wim Jongman
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.makeLocallyAvailable(MirroringArtifactProvider.java:174)
Post by Wim Jongman
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.getArtifactFile(MirroringArtifactProvider.java:118)
Post by Wim Jongman
at
org.eclipse.tycho.repository.p2base.artifact.provider.CompositeArtifactProvider.getArtifactFile(CompositeArtifactProvider.java:70)
Post by Wim Jongman
at
org.eclipse.tycho.p2.target.TargetPlatformBaseImpl.getLocalArtifactFile(TargetPlatformBaseImpl.java:93)
Post by Wim Jongman
at
org.eclipse.tycho.p2.resolver.P2ResolverImpl.addUnit(P2ResolverImpl.java:217)
Post by Wim Jongman
at
org.eclipse.tycho.p2.resolver.P2ResolverImpl.toResolutionResult(P2ResolverImpl.java:180)
Post by Wim Jongman
at
org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:172)
Post by Wim Jongman
at
org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:103)
Post by Wim Jongman
at
org.eclipse.tycho.p2.resolver.P2DependencyResolver.doResolveDependencies(P2DependencyResolver.java:352)
Post by Wim Jongman
at
org.eclipse.tycho.p2.resolver.P2DependencyResolver.resolveDependencies(P2DependencyResolver.java:325)
Post by Wim Jongman
at
org.eclipse.tycho.core.resolver.DefaultTychoResolver.resolveProject(DefaultTychoResolver.java:107)
Post by Wim Jongman
at
org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:75)
Post by Wim Jongman
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:274)
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
... 11 more
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
Caused by: java.security.SignatureException: An error
/tmp/signatureFile5309382464664284679.jar at
org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent(SignedBundleHook.java:219)
Post by Wim Jongman
at
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.verifyContent(SignatureVerifier.java:78)
Post by Wim Jongman
at
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.verify(SignatureVerifier.java:60)
Post by Wim Jongman
at
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.close(SignatureVerifier.java:107)
Post by Wim Jongman
at
org.eclipse.equinox.internal.provisional.p2.artifact.repository.processing.ProcessingStep.close(ProcessingStep.java:85)
Post by Wim Jongman
at
org.eclipse.equinox.internal.p2.artifact.processors.md5.MD5Verifier.close(MD5Verifier.java:83)
Post by Wim Jongman
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.reportStatus(SimpleArtifactRepository.java:1184)
Post by Wim Jongman
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.downloadArtifact(SimpleArtifactRepository.java:591)
Post by Wim Jongman
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:724)
Post by Wim Jongman
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromOneMirror(RepositoryArtifactProvider.java:209)
Post by Wim Jongman
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyMirror(RepositoryArtifactProvider.java:192)
Post by Wim Jongman
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.access$1(RepositoryArtifactProvider.java:187)
Post by Wim Jongman
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider$1.perform(RepositoryArtifactProvider.java:167)
Post by Wim Jongman
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:708)
Post by Wim Jongman
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifacts(SimpleArtifactRepository.java:779)
Post by Wim Jongman
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyChildRepository(RepositoryArtifactProvider.java:179)
Post by Wim Jongman
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyFormatAvailableInRepository(RepositoryArtifactProvider.java:149)
Post by Wim Jongman
at
org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnySource(RepositoryArtifactProvider.java:135)
Post by Wim Jongman
at
org.eclipse.tycho.repository.p2base.artifact.provider.CompositeArtifactProviderBaseImpl.getArtifact(CompositeArtifactProviderBaseImpl.java:50)
Post by Wim Jongman
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadCanonicalArtifact(MirroringArtifactProvider.java:236)
Post by Wim Jongman
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadMostSpecificNeededFormatOfArtifact(MirroringArtifactProvider.java:229)
Post by Wim Jongman
at
org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadArtifact(MirroringArtifactProvider.java:214)
Post by Wim Jongman
... 26 more
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
Caused by: java.security.SignatureException: Error occurs
parsing the .SF file to find out the digest algorithm in
this bundle: /tmp/signatureFile5309382464664284679.jar at
org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.processSigner(SignatureBlockProcessor.java:101)
Post by Wim Jongman
at
org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.process(SignatureBlockProcessor.java:61)
Post by Wim Jongman
at
org.eclipse.osgi.internal.signedcontent.SignedBundleFile.initializeSignedContent(SignedBundleFile.java:44)
Post by Wim Jongman
at
org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent(SignedBundleHook.java:215)
Post by Wim Jongman
... 47 more
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
[ERROR] [ERROR] To see the full stack trace of the errors,
re-run Maven with the -e switch. [ERROR] Re-run Maven using
the -X switch to enable full debug logging. [ERROR] [ERROR]
For more information about the errors and possible
solutions, please read the following articles: [ERROR]
[Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/InternalErrorException
Post by Wim Jongman
[DEBUG] Waiting for process to finish
Post by Alexander Nyßen
Post by Ed Willink
Post by Tom Schindl
I'm not sure what I should learn from that but something is
seriously broken now!
Tom
On Tue, Apr 14, 2015 at 7:10 PM, Tom Schindl
Hi,
Not sure this is related but I've now seen my build
failing because of pack200 and on the next run succeeding.
I have seen the same in the Nebula Gerrit build. First a
pack problem and then a normal build.
Cheers,
Wim
_______________________________________________
cross-project-issues-dev mailing list
your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Post by Wim Jongman
_______________________________________________
Post by Alexander Nyßen
Post by Ed Willink
cross-project-issues-dev mailing list
delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Post by Wim Jongman
--
Post by Alexander Nyßen
Thomas Schindl, CTO BestSolution.at <http://BestSolution.at> EDV
Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/ Reg. Nr. FN 222302s am
Firmenbuchgericht Innsbruck
_______________________________________________
cross-project-issues-dev mailing list
options, retrieve your password, or unsubscribe from this list,
visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
-- Dr. Alexander Nyßen Dipl.-Inform. Principal Engineer
Telefon: +49 (0) 231 / 98 60-202
<tel:%2B49%20%280%29%20231%20%2F%2098%2060-202> Telefax: +49 (0) 231
/ 98 60-211 <tel:%2B49%20%280%29%20231%20%2F%2098%2060-211>
Post by Alexander Nyßen
Mobil: +49 (0) 151 / 17396743
<tel:%2B49%20%280%29%20151%20%2F%20%2017396743>
Post by Wim Jongman
Post by Alexander Nyßen
itemis AG Am Brambusch 15-24 44536 LÃŒnen
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg
Pietrek, Jens Trompeter, Sebastian Neus
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus,
Jennifer Fiorentino
_______________________________________________
cross-project-issues-dev mailing list
options, retrieve your password, or unsubscribe from this list,
visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Tom Schindl
2015-04-16 06:46:56 UTC
Permalink
Hi,
I assume javax.annotation.jreis a bundle you sign? (And, you don't
re-sign it, right?) We're learning that does not work reliably.
And you have rebuild/resigned say, today, to make sure al the Java 6
transitions were back in place.
javax.annotation.jre is a custom bundle no resigning, ... .

http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/javax.annotation.jre_1.2.0.201504160629.jar

(don't worry that it is empty - that's expected)
I assume you use Tycho to build with? If not using Tycho, it could be
several other things, but Tycho does very well. (IMHO).
Yes the build is done with tycho (i attach the relevant definition at
the end)
Besides your "local maven repo" do you put your "tmp" directory in your
workspace, so it is cleaned (deleted) also? (Currently, its that tmp
directory where p2 "leaves stuff" (be default).
Have not set that yet - I'll try that one one as well.
Given none of those are issues, sound like a case that "it just can not
be packed". Not ever bundle can be. And easiest to add that eclipse.inf
to the META-INF directory with
jarprocessor.exclude.pack=true
So, it's signed .. just not packed.
It used to work for weeks and now it suddenly broke. The only maybe
interesting fact is that the bundle is empty (has no .class-Files)
<profile>
<id>build-server</id>
<build>
<plugins>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<version>${tycho-version}</version>
<configuration>
<includePackedArtifacts>false</includePackedArtifacts>
</configuration>
</plugin>
<plugin>
<groupId>org.eclipse.tycho.extras</groupId>
<artifactId>tycho-pack200a-plugin</artifactId>
<version>${tycho-extras.version}</version>
<executions>
<execution>
<id>pack200-normalize</id>
<goals>
<goal>normalize</goal>
</goals>
<phase>verify</phase>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.eclipse.cbi.maven.plugins</groupId>
<artifactId>eclipse-jarsigner-plugin</artifactId>
<version>${cbi-plugins.version}</version>
<executions>
<execution>
<id>sign</id>
<goals>
<goal>sign</goal>
</goals>
<phase>verify</phase>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.eclipse.tycho.extras</groupId>
<artifactId>tycho-pack200b-plugin</artifactId>
<version>${tycho-extras.version}</version>
<executions>
<execution>
<id>pack200-pack</id>
<goals>
<goal>pack</goal>
</goals>
<phase>verify</phase>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-p2-plugin</artifactId>
<version>${tycho-version}</version>
<executions>
<execution>
<id>p2-metadata</id>
<goals>
<goal>p2-metadata</goal>
</goals>
<phase>verify</phase>
</execution>
</executions>
<configuration>
<defaultP2Metadata>false</defaultP2Metadata>
</configuration>
</plugin>
</plugins>
</build>
</profile>
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Tom Schindl
2015-04-16 10:10:38 UTC
Permalink
Post by Tom Schindl
Hi,
I assume javax.annotation.jreis a bundle you sign? (And, you don't
re-sign it, right?) We're learning that does not work reliably.
And you have rebuild/resigned say, today, to make sure al the Java 6
transitions were back in place.
javax.annotation.jre is a custom bundle no resigning, ... .
http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/javax.annotation.jre_1.2.0.201504160629.jar
(don't worry that it is empty - that's expected)
So things are back now that i added a dummy class to
javax.annotation.jre! I have no freaking idea why this should make a
difference but I've now at least a working build!

Tom
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
David M Williams
2015-04-17 05:55:45 UTC
Permalink
Post by Tom Schindl
So things are back now that i added a dummy class to
javax.annotation.jre! I have no freaking idea why this should make a
difference but I've now at least a working build!
Not sure how much you want to pursue this, but ... a few old memories are
coming back to me.

First, remember that Tycho doesn't use the "batch signing service", per
se, but does their own re-pack, and "pack200" ... I've always assumed they
use the VM you are running your build with, but, do not know for sure.

One reason they do this, is that bundles with no .class files do not
profit from re-pack/pack200 (but still profit from gzip). I am not sure of
the implementation details, but this includes at least features.jars and
source*.jars. I am not sure if they literally "look in" other bundles to
see if "resources only" (no .class files) or what. (Buckminster does
something similar, but again, do not know implantation).

I see your bundle has a BREE of 1.8 . Did your empty bundle also contain a
BREE? Or was that added when the dummy .class added? ... wouldn't it be
interesting (i.e. a "bug", sort of, in your code :) if Tycho use the
presence of a BREE to decide if "class files or not"?

Ok, you deserve it now, having read this far ... the old memory is ...
when moving from Java 5 to Java 6, we learned that if a bundle contained
.class files, at the 1.5 level, then the 1.6 pack200 tools would make one
set of assumptions, so that unpacking the bundle would be compatible with
either 1.5 or 1.6. BUT, if the bundle had no class files, then the pack200
tools would make another set of assumptions, and could no longer be
unpacked with Java 1.5. (Yeah, silly, eh?) I've looked for the original
bug, but can't find it, so might have just been a mailing list discussion?
I believe the work around was just to "pack" with Java 5, even if using
Java 6 to run the rest of the build. (I do not know when the
infrastructure changed to use Java 6).

Your case sounds similar, in some ways, though not exactly the same.

Just thought you might find it comforting that similarly strange, freaky
things have happened before.

Old statistic of the day: By coincidence, I ran across this old bug, from
way way back in "Callisto days" where I did a little analysis on "savings"
(Bug 145685) and found:
"It is very interesting that on a jar by jar basis, the reduced size
varied everywhere from 20% to 90% of the original jar (with the 44% being
a real-life-in-practice average)."
I suspect we are doing even better than that now ... but hope that 44%
(56% savings in bandwidth) helps explain why its important to have these
pack.gz files in the first place, and, of course, they must be able to be
unpacked reliably by our users, or it ends up making things worse, since
then the jar has to be downloaded (too), for an overall increase in
bandwidth!

New tip of the day: I've not tried it yet, but I see in the pack200 spec
there is a ---pass-file option, so if your "unpack200/verify" is failing
due to one class, you can tell the pack200 processor to not monkey with
that one class file, but still pack200 the rest. I suspect, in practice,
this only effects Orbit, or others using PDE build, where they have a high
degree of control over the process and parameters of pack200 (via
eclipse.inf, if nothing else, which is not (fully) supported by Tycho ...
but Buckminster does, I believe support that part of eclipse.inf files.
[And to be clear, I am not suggesting everyone "jump through hoops" here
... I personally was worried about one case, ICU4J, which is a huge jar
file, and seemed to be having trouble being packed by Java 8, due to one
class, but, like I said, I have not tried it yet to see if it solves the
problem. Tracking in Bug 464100 if anyone is that interested.].

Thanks for reading a yet another long and extra wordy note!
Tom Schindl
2015-04-17 08:54:16 UTC
Permalink
Post by David M Williams
Post by Tom Schindl
So things are back now that i added a dummy class to
javax.annotation.jre! I have no freaking idea why this should make a
difference but I've now at least a working build!
Not sure how much you want to pursue this, but ... a few old memories
are coming back to me.
First, remember that Tycho doesn't use the "batch signing service", per
se, but does their own re-pack, and "pack200" ... I've always assumed
they use the VM you are running your build with, but, do not know for sure.
One reason they do this, is that bundles with no .class files do not
profit from re-pack/pack200 (but still profit from gzip). I am not sure
of the implementation details, but this includes at least features.jars
and source*.jars. I am not sure if they literally "look in" other
bundles to see if "resources only" (no .class files) or what.
(Buckminster does something similar, but again, do not know implantation).
I see your bundle has a BREE of 1.8 . Did your empty bundle also contain
a BREE? Or was that added when the dummy .class added? ... wouldn't it
be interesting (i.e. a "bug", sort of, in your code :) if Tycho use the
presence of a BREE to decide if "class files or not"?
Yes the EE 1.8 was there from the beginning - the change to make things
behave correctly was
http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/commit/?id=8eb51cf545d522674b290afe6e14475ebafe195c

What strikes me is that this all worked flawless for weeks and suddenly
started breaking a few days ago but there was no change in
tycho-version, signing plugin, ... . Not sure when the server was
upgraded to java8u40 but I think that was not done this week but some
weeks before?

Tom
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Denis Roy
2015-04-17 13:24:28 UTC
Permalink
Post by David M Williams
First, remember that Tycho doesn't use the "batch signing service",
Is it time to retire the batch signing service (ie, the sign command)?
The web service works great and is much easier to scale than the batch
signer. For other working groups, like Polarsys, LTS and LocationTech,
we are (or will be) providing the web service only.

D.
Ed Willink
2015-04-20 07:18:00 UTC
Permalink
Hi

Given David's comment, I presume that Buckminster is an example of a
build system that does use the batch signing service. So even if
Buckminster was changed today, the batch signing service is needed for
another couple of years.

Regards

Ed Willink
Post by Denis Roy
Post by David M Williams
First, remember that Tycho doesn't use the "batch signing service",
Is it time to retire the batch signing service (ie, the sign command)?
The web service works great and is much easier to scale than the batch
signer. For other working groups, like Polarsys, LTS and
LocationTech, we are (or will be) providing the web service only.
D.
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5863 / Virus Database: 4331/9558 - Release Date: 04/17/15
Wim Jongman
2015-04-17 21:29:44 UTC
Permalink
Post by David M Williams
Thanks for reading a yet another long and extra wordy note!
Thanks for writing it ;)
Loading...