RE: [wtp-releng] Heads up on impact of 3.7 Platform upgrade .... and som

[David M Williams <david_williams@xxxxxxxxxx>]

Thank you very much for leaving in the
compile error in JSF Tests over the weekend ... it gave me the time (and
motivation) to improve some things about our build. 

1) There are some spots in our scripts
where if something fails, we got a lot of subsequent, confusing errors,
and maybe even "kicked out" of Ant, before anything was really
"published" to download page so it was harder to diagnose. I've
fixed at least one or two of those spots, and better understand how to
prevent abrupt endings and push "early publish" ... as we encounter
more of them. 

2) One recent "cause" of build
failures was that P2 could not _install_ the test features. (Oh, have I
mentioned we now use P2 to install things during tests ... well .... at
least some things :/  ) That is normally a good thing to fail if p2
can not install something, but (until now) the reason it failed was hard
to see or diagnose (both that it happened at all, and when it happened,
what was missing, or what was conflicting). I now publish a link on that
failed build's download page to the "failed install log" so everyone
can see what's wrong. If you see the link ... be sure to check it out,
it might be your prereqs!   

3) I've changed the build so that now
if there is a compile error, as there has been now for past few days (in
the 3.3 builds) ... the build will stop and print an appropriate message
on download page .. so its a little more obvious what happened. I should
emphasize, the entire set of code is compiled before the build is stopped
(it is not on first compile error). But, no master repo or big zips are
created and the unit tests process is not started. I realize this is part
"policy" and not just technical. There is sometimes merit to
pushing through and doing as much building and testing as can be done,
even if there are compile errors, ... especially when the compile error
is in a leaf component ... but, on the other hand ... I think we are a
mature enough project and it happens rarely enough that we should not waste
cycles if there is a compile error ... let's fix it quick and move forward.
If we start having lots of compile errors or anyone feels they are getting
held back due to this policy, I'd be happy to reconsider ... but if we
have a lot of compile errors, or if they can not be fixed quickly, then
that's probably a sign we have bigger problems. 

4) I now "publish the build"
after the main part of the build ... as much of it as we have that is ...
that is, publish it before the unit tests start running (they are, after
all, the real time hog). Hence, you will more frequently see that little
clock icon on the download page ... so you need to be aware it no longer
means "failed", but sometimes really does mean "pending"
(as it originally was intended).  It is this change I wanted to "warn"
everyone about ... the rest will be pretty self evident when they happen,
but that little 'clock' icon will now have a different meaning than it
has acquired (by association) over the past few years. Of course, it will,
sometimes, still mean "failed" .... maybe improving that will
be next weekend's project :) 

5) There's now a link to the "full
log" of the build itself .... everything you ever wanted to know about
what happens during a build. They can be huge, 30/40 Megs, so you definitely
need to download it and learn to search it. Besides looking for reasons
behind build failures, there is some info in these logs about JavaDoc generation,
and other things, which sometimes lists errors or warnings which are not
otherwise available. Good luck finding the needles in a 30 M haystack.
 :) 

Much thanks. Ask if anything is unclear.


Oh, and now the JSF team can fix their
compile error .... please? :)

From:	Raghunathan Srinivasan <raghunathan.srinivasan@xxxxxxxxxx>
To:	Webtools releng discussion list <wtp-releng@xxxxxxxxxxx>
Date:	08/19/2010 03:00 PM
Subject:	RE: [wtp-releng] Heads up on  impact of 3.7 Platform upgrade
Sent by:	wtp-releng-bounces@xxxxxxxxxxx

---

We will address this issue
by tomorrow, 8/20.
-Raghu
 
From: Cameron Bateman 
Sent: Thursday, August 19, 2010 9:36 AM
To: wtp-releng@xxxxxxxxxxx
Subject: Re: [wtp-releng] Heads up on impact of 3.7 Platform upgrade
 
I will take this up as soon as
we branch for 3.3.  This will probably happen once 3.2.2 freezes.


Thanks,

Cameron

----- Original Message -----
From: david_williams@xxxxxxxxxx
To: wtp-releng@xxxxxxxxxxx
Sent: Thursday, August 19, 2010 5:20:50 AM GMT -08:00 US/Canada Pacific
Subject: [wtp-releng] Heads up on  impact of 3.7 Platform upgrade


Last night I upgraded our Platform pre-req to I20100817-0800 

This was to fix some compile errors in a JSDT bundle, that is aggressively
writing to new API! :) 

Source File: org/eclipse/wst/jsdt/debug/internal/rhino/ui/launching/RhinoTabGroup.java
1. ERROR: UndefinedMethod 
The method setHelpContextId(String) is undefined for the type SourceLookupTab
RhinoTabGroup.java : 
38 : stab.setHelpContextId(IHelpConstants.SOURCE_TAB_CONTEXT);
2. ERROR: UndefinedMethod 
The method setHelpContextId(String) is undefined for the type CommonTab
RhinoTabGroup.java : 
40 : ctab.setHelpContextId(IHelpConstants.COMMON_TAB_CONTEXT);


But then that caused a compile error in a JSF test bundle: This appears
related to the changes mentioned in the cross-project list, 
http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg04591.html

These don't show up on public download page, just came from a local build
I did to test ... and thought I'd give this early warning. 
There is no 3.3 based smoke test this week ... planning week, since we
just delivered M1! .... so not as "blocking" as would otherwise
be  ... 
just wanted to give warning that teams may want to upgrade their target.


Source File: org/eclipse/jst/jsf/test/util/mock/MockBundle.java
1. ERROR: AbstractMethodMustBeImplemented
The type MockBundle must implement the inherited abstract method Bundle.adapt(Class<A>)
MockBundle.java : 
19 : public class MockBundle implements Bundle
2. ERROR: AbstractMethodMustBeImplemented
The type MockBundle must implement the inherited abstract method Comparable<Bundle>.compareTo(Bundle)
MockBundle.java : 
19 : public class MockBundle implements Bundle
3. ERROR: AbstractMethodMustBeImplemented
The type MockBundle must implement the inherited abstract method Bundle.getDataFile(String)
MockBundle.java : 
19 : public class MockBundle implements Bundle
_______________________________________________
wtp-releng mailing list
wtp-releng@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-releng