Tim Quinn wrote:
> Have we ruled out hk2 changes as contributing to this?
>
> The most recently checked-in changes in hk2 are from Wednesday, Aug 6th,
> and one would think if they were involved then the QL failures would
> have begun earlier than they did.
When were they pushed out to the maven repo?
What's interesting is this (the latest) log message in DomDocument.java:
% svn log config/src/java/org/jvnet/hk2/config/DomDocument.java
------------------------------------------------------------------------
r776 | km | 2008-08-06 16:09:31 -0700 (Wed, 06 Aug 2008) | 6 lines
Preparing for the next iteration.
Nothing should be affected because of this checkin as
none uses it (hopefully) at SNAPSHOT level.
--------------------
thanks,
-marina
>
> Just thinking out loud...
>
> - Tim
>
> Ken Cavanaugh wrote:
>
>> The v3-dev-builds-quicklook job started failing at job #712 at 8:07
>> this morning.
>> The last successful run was #711 at 7:24 this morning. So, sometime
>> between
>> 7:24 and 8:07, something changed that broke QL.
>>
>> The upstream job that triggers the QL job is glassfish-v3-devbuild,
>> which ran
>> #2283 at 7:26 this morning. This job picked up revisions 21660 (by
>> user jr158900)
>> and 21659 (by Kedar) from svn, which changed:
>>
>> 1. Enabling lazy-connection-association in
>> PoolManager/ComponentInvocationHandler (this is in connectors)
>> 2. Added dataType annotations to this class (in admin/config-api)
>>
>> It seems that everything broke after this change. There were quite a
>> number of
>> checkins after this: we are currently up to 21688.
>>
>> Possibilities:
>>
>> 1. This checkin somehow results in the failure to start the
>> server. From the emails I've seen, this does not seem likely.
>> 2. Something else changed in the complex web of dependencies on
>> other artifacts that we depend on.
>>
>> Can we determine which is the case, or if something else has caused
>> the problem?
>> For example, is there another non-GlassFish Hudson job (or from
>> outside of Hudson)
>> that pushed an artifact into maven upon which we depend?
>>
>> The obvious thing to do from the build team perspective is to revert
>> the repository to the
>> last-known-good state, but I'm not sure that's even the problem here:
>> if possibility 2. is
>> what happened, all that reverting the repo would do is waste even more
>> developer time.
>>
>> Thanks,
>>
>> Ken.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net For
>> additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>