Right, this revision has to do nothing with v3' failures.
It's probably v3/pom.xml that's causing this.
I am building it with v3/pom.xml changes reverted.
Will keep you posted.
-Kedar
Marina Vatkina wrote:
> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>