I think the case we have right now is 3. I think there was an explicit
change in pom.xml which caused to trigger the v3 build. The
glassfish-api job does not have a downstream v3 job right now.
+1 on announcement for changes in glassfish-api, better if there is a
way we can avoid this by using ranges . Version based upgrade of
glassfish-api so far is causing a lot of issues.Last week also we ran
into issues where a change in the version of glassfish-api caused QL to
break.
Regards,
Bhakti
Sahoo wrote:
> Kohsuke/Build Team,
>
> When does a change in glassfish-api cause a v3 build? There are three
> possibilities that I can think of:
> 1. A change in glassfish-api source tree, which is part of v3
> workspace, is considered a change in v3 source tree. In this case a v3
> build is initiated along with a glassfish-api build for every change
> in glassfish-api source tree. I would consider this an error.
>
> 2. Hudson job for v3 is setup such that it does not consider a change
> in glassfish-api to be a change in v3, hence it does not immediately
> start a v3 build. Instead, a v3 build is initiated after the
> glassfish-api build job finishes because of the job dependencies. This
> is definitely better than #1.
>
> 3. This is even further optimization which uses the maven dependencies
> to analyse exactly when a v3 build would be affected by a change in
> glassfish-api. v3 uses non-SNAPSHOT version of glassfish-api, so a
> change is glassfish-api alone can not affect v3. An explicit change
> in v3's pom.xml to use a new version of glassfish-api is really
> needed to trigger v3 build in this case. This basically means, v3 job
> does not depend on glassfish-api job anymore.
>
> Which of the three happens today?
>
> Thanks,
> Sahoo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>