Re: [wtp-jsf-dev] Build Breaker Solution

[David M Williams <david_williams@xxxxxxxxxx>]

HEAD builds have been suggested many
times, and I've steadfastly resisted them. 

I'm not sure how, but I've acquired
a view that HEAD builds are a bad practice, 
or, at least, wasteful and unneeded.


a. shouldn't be necessary with such
a nice development environment as Eclipse :) 
b. encourages some developers to overly
depend on it to make sure they don't break anything
(that is, they should be sure of this
before even putting into head, ideally). 
c. gives a false sense of security since
there's a large number of cases that work fine
from head, but would not work from released/versioned
builds. 
d. Continuous builds, as we have, should
be perfectly equivalent or even better 
since they run even more frequently
than a nightly build. 
e. HEAD builds can still be done, on
request, since they really are useful for some things, 
just not "routine" errors.


Normally I would not have even mentioned
this compile break, but I saw there were compile failures 
in two builds in a row (Wed,
24 Jan 2007, and Thu, 25 Jan 2007),

so I falsely assumed it was the same
compile error, and that perhaps 
no one was watching the builds closely.
I've looked at it just now, 
and see that it was actually different
compile errors in each build, so I think 
everything is actually working pretty
well. And, spec'ing the EE environments 
is something we need to do soon anyway,
is easy, and I think would solve this 
problem (at least for our forward code
stream). 

I know I'm a little cantankerous on
this issue ... so, I don't mind 
the discussion and if people really
really really wanted it, I would not stand 
in the way of someone else doing the
work for it (but would expect them to 
make it work, monitor it, and be sure
it doesn't interfere with our continuous builds). 

Thanks,

Cameron Bateman <cameron.bateman@xxxxxxxxxx>
Sent by: wtp-jsf-dev-bounces@xxxxxxxxxxx

01/26/2007 12:43 PM

Please respond to
Java Server Faces Tools developer discussion        <wtp-jsf-dev@xxxxxxxxxxx>

To	Java Server Faces Tools developer discussion <wtp-jsf-dev@xxxxxxxxxxx>
cc
Subject	Re: [wtp-jsf-dev] Build Breaker Solution

A good stop gap on the compliance setting deficiencies
would be to 
enable a nightly build from HEAD.  We have tried to do our own locally,
but have run into a lot of problems trying to do a local build from 
behind are our gateway since (at least the last time I tried) the build
scripts don't seem to be enabled for proxied use.

Has nightly build from HEAD ever been attempted on the main build 
servers?  I think this would go a long way to reducing the surprise
breakages that often delay our weekly I-builds.


--Cam

David M Williams wrote:

>
> Yes, the right way to do this is to specify the J2SE Execution of
> Environment (as 1.4 in your case). It is easiest to do this with the
> PDE Manifest.mf
> editor -- its at bottom of first  page -- since it gives you
a nice 
> list to pick from, plus a link that you can use to update the classpath
> and project preferences. This then tweaks the _class libraries_ that
> are used to compile the code. The compliance setting itself
> doesn't really say anything about libraries and in that case that
no 
> EE is specified, the workspace default is used, which, if you are
> running on a 1.5 VM will ....
> well, you get the idea.
>
> People make this mistake so often (myself included) some usability
> improvements would be a fair enhancement request and opportunity for
> someone to provide a patch to JDT.
> Simple things ... like a link on that property page to "go to"
the EE 
> value setting, or perhaps a simple checkbox or drop-down that would
> say something like
> "[ ] change EE setting to match Compliance setting"
>
> There are cases where you do not want this matching to happen, But
... 
> maybe that'll be chapter two :)
>
>
>
>
>
>
> *Cameron Bateman <cameron.bateman@xxxxxxxxxx>*
> Sent by: wtp-jsf-dev-bounces@xxxxxxxxxxx
>
> 01/25/2007 01:42 PM
> Please respond to
> Java Server Faces Tools developer discussion      
>  <wtp-jsf-dev@xxxxxxxxxxx>
>
>
>                  
> To
>                  Java
Server Faces Tools developer discussion <wtp-jsf-dev@xxxxxxxxxxx>
> cc
>                  
> Subject
>                  Re:
[wtp-jsf-dev] Build Breaker
>
>
>
>                  
>
>
>
>
>
> David,
>
> We have noticed that setting JDK compliance to 1.4 does not detect
cases
> like this break where the non-compliance in question is new API on
a JDK
> class itself.  I want to force the project-level compliance preference
> on all our projects to 1.4, but situations like this still won't be
> detected.  Is there a workaround that you are aware of for this
issue?
>
>
> --Cam
>
> David M Williams wrote:
>
> >
> > And you are not the only ones lately :)
> >
> > It appears in the latest I-builds, some JSF code is trying to
use some
> > Java-5-only method (Class.getShortName()) ?
> >
> > Offhand I'd guess it's not worth specifying this plugin requires
1.5,
> > if that's the only "need" for it.
> >
> > But, in either case, we'll need that fixed before we have an
I-build
> > to smoke test.
> >
> > Thanks,
> >
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >wtp-jsf-dev mailing list
> >wtp-jsf-dev@xxxxxxxxxxx
> >https://dev.eclipse.org/mailman/listinfo/wtp-jsf-dev
> >  
> >
>
> _______________________________________________
> wtp-jsf-dev mailing list
> wtp-jsf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-jsf-dev
>
>------------------------------------------------------------------------
>
>_______________________________________________
>wtp-jsf-dev mailing list
>wtp-jsf-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/wtp-jsf-dev
>  
>

_______________________________________________
wtp-jsf-dev mailing list
wtp-jsf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-jsf-dev