This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 168037 - web.jsf test compilation failing
Summary: web.jsf test compilation failing
Status: RESOLVED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: JSF (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Martin Schovanek
URL:
Keywords: TEST
Depends on:
Blocks:
 
Reported: 2009-07-02 14:36 UTC by Petr Hejl
Modified: 2009-07-20 14:09 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Hejl 2009-07-02 14:36:19 UTC
See subj.
Comment 1 Vojtech Sigler 2009-07-02 14:46:48 UTC
Could you, please, add more detail? Where is the build failing, what errors does it produce... I can compile it just
fine from trunk.

If it is in a team repo, do you have changeset http://hg.netbeans.org/main/rev/ca5d7a5c4e8b in your repo? It contains
fixes for this module.
Comment 2 Petr Hejl 2009-07-02 15:16:13 UTC
web-main. Obviously we don't have it.
Comment 3 Petr Jiricka 2009-07-02 15:31:52 UTC
vsigler, when you put a change in the main repository, you also have to make sure it is propagated as soon as possible
to main-silver by http://deadlock.netbeans.org/hudson/job/push-main/ - in this case, it took a really long time,
considering the seriousness of this bug.

And, making such high impact changes without prior notification, and breaking other teams' tests is unacceptable in the
first place.
Comment 4 Vojtech Sigler 2009-07-03 09:55:28 UTC
This was discussed quite a lot in the last few days. The changes were announced and discussed almost 3 months ago. Also,
those changes were discussed with build engineering and all agreed that noone except NBQE is or should be
building/running those tests. In the first place, we had no idea anyone else besides us is using those tests. Much less
that team builders depend on a successful build of qa-functional tests. Not fixing the modules was intentional, not a
bug. It was meant, so that the test owners would fix their tests themselves and the rest would be dropped, as it was
done during the transition to simpletests.

Please, if you want to discuss this further, ask Marian. :)

As for not starting the push-main job, I'm sorry for that, but I did not know it had to be started manually (not
triggered automatically). :(
Comment 5 Petr Hejl 2009-07-03 12:08:52 UTC
From your description and considering our build infrastructure it seems to me that QE should have own repository that
would not propagate changes in case these tests are not compilable. It would be much better than: brake the tests in
main, let it spread and fix it some time later.

IMO anybody who cares about regressions will setup all available tests (including functional tests) for his area in a
hudson job (as we did for java ee 6). It is a bit annoying when such quality assurance job starts failing for no reason.
Comment 6 Marian Mirilovic 2009-07-03 12:45:41 UTC
Hi all, I explained it 4 times yesterday and I am really sorry for that, but :
- per an agreement we had with Michal Z. & Petr J.(discussed 2-3 months ago while we'd faced a lot of problems with C/V)
- compilation of *all* tests & results of *all* tests will be never a reason for build fail / neither blocker for push
... if some team will setup their build/push to build/run other than their own tests it's a problem of their configuration

- QE didn't (since last organization changes), doesn't and won't be able to keep *all qa-functional tests* stable not
even compilable - therefore we'll do cleanup of our tests in next 2 months

- all before said is true and even we knew about the risk -> we did wait for successful build from main (which
(un)fortunately passed) to be sure nothing is broken
Comment 7 Petr Jiricka 2009-07-20 14:09:48 UTC
Looks fixed now.