Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Fw: [platform-releng-dev] [eclipse-build]Build I20090324-1325 (Timestamp: 200903241325):Automated JUnit testing complete. Test failures/errors occurred.

The jar comparator should detect a difference if only a constant has 
changed in a dependent bundle.
We need to make the comparison result more proeminent in the build result 
page so that we can know when the assumption (1 version == 1 set of bits) 
is broken.
If this happens, nobody should update to the build. A rebuild must occur 
with the corresponding projects retagged (new version) untill we have a 
clear check from the jar comparator.

When a .class file is a "problem type" or contains "problem method", if 
the next version doesn't, then the jar comparator will return the 
corresponding bundle in the list of corrupted bundles if the bundle has 
not been retagged for the build.




Jerome Lanneluc <jerome_lanneluc@xxxxxxxxxx> 
Sent by: platform-releng-dev-bounces@xxxxxxxxxxx
2009-03-26 06:00
Please respond to
"Eclipse platform release engineering list." 
<platform-releng-dev@xxxxxxxxxxx>


To
"Eclipse platform release engineering list." 
<platform-releng-dev@xxxxxxxxxxx>
cc
"Eclipse platform release engineering list." 
<platform-releng-dev@xxxxxxxxxxx>, platform-releng-dev-bounces@xxxxxxxxxxx
Subject
Re: Fw: [platform-releng-dev]   [eclipse-build]Build    I20090324-1325 
(Timestamp:     200903241325):Automated JUnit testing complete. Test 
failures/errors occurred.







> The fundamental assumption we are working with is that 1 version == 1 
set of bits. 
This assumption is wrong since the same version of the source can produce 
different bits, one example being a compile error producing a non runnable 
.class file. 
But a change in a constant value can also produce a different .class file. 
This case cannot be detected at compile time. 
I believe non-API changes can also produce different .class files. 



From: 
Andrew Niefer <aniefer@xxxxxxxxxx> 
To: 
"Eclipse platform release engineering list." 
<platform-releng-dev@xxxxxxxxxxx> 
Date: 
25/03/2009 07:41 PM 
Subject: 
Re: Fw: [platform-releng-dev]        [eclipse-build]Build I20090324-1325   
  (Timestamp:        200903241325):Automated        JUnit testing 
complete.        Test failures/errors occurred. 
Sent by: 
platform-releng-dev-bounces@xxxxxxxxxxx





I'm a little late on this thread because of EclipseCon, but thought I 
would comment because I'm actually giving a short talk on this topic later 
today. 

> OK, I think I found the problem: when PDE fixed their contribution they
> only retagged the pde.core bundle which they missed previously. Now, it
> looks like all source of the build is checked out from the CVS 
repository
> and compiled and hence no compile errors get reported during the build.
> However, when the build is assembled p2 (repo) is used and the old 
pde.ui
> bundle gets used as the version did no change. 

This is correct.  We have to remember that people are not just runnig the 
zips.  They are running previous builds and updating only the things that 
had versions changed. 
The problem is this: The binary bits changed.  The source did not change 
and the version did not change.  The fundamental assumption we are working 
with is that 1 version == 1 set of bits. 

We can't ship the new bits under the old version. because then you have 
different users running different things dependening on how they got their 
bits. 
So we need the build to tell us when we hit this problem.  Today this 
happens by virtue of the junit tests failing, and I do agree with Dani 
that this is not the most efficient way to surface the problem. 

As Kim mentioned, we do run a comparison between the original version and 
the newly compiled bits (thanks to Olivier for this code).  There is still 
some work to get the results of this comparison surfaced as build 
errors/warnings telling us that something has changed and the bundles need 
to be retagged/upversioned. 

I think the change that is most realistic in a 3.5 time frame is to have 
the comparison results surfaced, if not as build errors, at least as a log 
that we can look at when junits failed. 

-Andrew 



Daniel Megert <daniel_megert@xxxxxxxxxx> 
Sent by: platform-releng-dev-bounces@xxxxxxxxxxx 
03/25/2009 03:15 AM 

Please respond to
"Eclipse platform release engineering list." 
<platform-releng-dev@xxxxxxxxxxx>



To
"Eclipse platform release engineering list." 
<platform-releng-dev@xxxxxxxxxxx> 
cc

Subject
Fw: [platform-releng-dev] [eclipse-build]Build        I20090324-1325  
(Timestamp: 200903241325):Automated        JUnit testing complete. Test 
failures/errors occurred.











OK, I think I found the problem: when PDE fixed their contribution they
only retagged the pde.core bundle which they missed previously. Now, it
looks like all source of the build is checked out from the CVS repository
and compiled and hence no compile errors get reported during the build.
However, when the build is assembled p2 (repo) is used and the old pde.ui
bundle gets used as the version did no change.

If this is correct then we urgently need to fix the build process so that
the source used to compile and the bits used to assemble the build are the
same. Otherwise the result is doomed as the latest test failures show.

Dani
----- Forwarded by Daniel Megert/Zurich/IBM on 25.03.2009 11:07 -----.
|------------>
| From:      |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Daniel Megert/Zurich/IBM                         |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|"Eclipse platform release engineering list." 
<platform-releng-dev@xxxxxxxxxxx>                           |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|25.03.2009 10:07                 |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: [platform-releng-dev] [eclipse-build]Build I20090324-1325 (Timestamp: 
200903241325):Automated JUnit testing complete. Test failures/errors|
|occurred.          |
>--------------------------------------------------------------------------------------------------------------------------------------------------|




The JDT UI and LTK failures are caused by compile errors in PDE types. I
would have expected this from the 0800 build but not after PDE corrected
its build input and after seeing no compile errors reported by the build.
Below is the compile error.

Kim, could it be that the results got mingled? They look the same as in 
the
0800 build where there were indeed PDE compiler errors. Or maybe the PDE
team has a clue what's wrong here.

Dani


Unresolved compilation problems: The import
org.eclipse.pde.internal.core.text.bundle cannot be resolved The method
getBundle(IFile, IProgressMonitor) from the type BundleManifestChange
refers to the missing type Bundle BundleTextChangeListener cannot be
resolved to a type BundleTextChangeListener cannot be resolved to a type
BundleModel cannot be resolved to a type BundleSymbolicNameHeader cannot 
be
resolved to a type BundleSymbolicNameHeader cannot be resolved to a type

java.lang.Error: Unresolved compilation problems:
The import org.eclipse.pde.internal.core.text.bundle cannot be resolved
The method getBundle(IFile, IProgressMonitor) from the type
BundleManifestChange refers to the missing type Bundle
BundleTextChangeListener cannot be resolved to a type
BundleTextChangeListener cannot be resolved to a type
BundleModel cannot be resolved to a type
BundleSymbolicNameHeader cannot be resolved to a type
BundleSymbolicNameHeader cannot be resolved to a type

at
org.eclipse.pde.internal.ui.refactoring.ContainerRenameParticipant.<init>
(ContainerRenameParticipant.java:25)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at java.lang.Class.newInstance0(Class.java:350)
at java.lang.Class.newInstance(Class.java:303))
at
org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension
(RegistryStrategyOSGI.java:170)
at
org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension
(ExtensionRegistry.java:874)
at
org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension
(ConfigurationElement.java:243):
at
org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension
(ConfigurationElementHandle.java:51)
at
org.eclipse.ltk.internal.core.refactoring.ParticipantDescriptor.createParticipant
(ParticipantDescriptor.java:86)



|------------>
| From:      |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|eclipse-releng@xxxxxxxxxxx                           |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|platform-releng-dev@xxxxxxxxxxx                                |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|25.03.2009 04:04                 |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|[platform-releng-dev] [eclipse-build]Build I20090324-1325   (Timestamp: 
200903241325):Automated JUnit testing complete. Test failures/errors |
|occurred.          |
>--------------------------------------------------------------------------------------------------------------------------------------------------|





Build I20090324-1325 (Timestamp: 200903241325):  Automated JUnit testing 
is
complete.  Test failures/errors occurred in the following:

org.eclipse.jdt.ui.tests.refactoring_linux.gtk.x86
org.eclipse.jdt.ui.tests.refactoring_linux.gtk.x86_6.0
org.eclipse.jdt.ui.tests.refactoring_macosx.carbon.ppc_5.0
org.eclipse.jdt.ui.tests.refactoring_win32.win32.x86
org.eclipse.jdt.ui.tests.refactoring_win32.win32.x86_6.0
org.eclipse.ltk.core.refactoring.tests_linux.gtk.x86
org.eclipse.ltk.core.refactoring.tests_linux.gtk.x86_6.0
org.eclipse.ltk.core.refactoring.tests_macosx.carbon.ppc_5.0
org.eclipse.ltk.core.refactoring.tests_win32.win32.x86
org.eclipse.ltk.core.refactoring.tests_win32.win32.x86_6.0
org.eclipse.pde.ui.tests_linux.gtk.x86
org.eclipse.pde.ui.tests_linux.gtk.x86_6.0
org.eclipse.pde.ui.tests_macosx.carbon.ppc_5.0
org.eclipse.pde.ui.tests_win32.win32.x86
org.eclipse.pde.ui.tests_win32.win32.x86_6.0
org.eclipse.releng.tests_win32.win32.x86_6.0

HTTP Download:


http://download.eclipse.org/eclipse/downloads/drops/I20090324-1325


_______________________________________________
platform-releng-dev mailing list
platform-releng-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-releng-dev




_______________________________________________
platform-releng-dev mailing list
platform-releng-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-releng-dev
_______________________________________________
platform-releng-dev mailing list
platform-releng-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-releng-dev




Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
Compagnie IBM France
Siège Social : Tour Descartes, 2, avenue Gambetta, La Défense 5, 92400 
Courbevoie
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 609.751.783,30 ?
SIREN/SIRET : 552 118 465 02430
_______________________________________________
platform-releng-dev mailing list
platform-releng-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-releng-dev




Back to the top