Re: [papyrus-rt-dev] Failing builds

[Christian Damus <give.a.damus@xxxxxxxxx>]

Perhaps the Hudson builds are still using "papyrusrelease" variants of their target platforms?  The job configurations would have to be changed to use the "papyrusnightly" variants (there's a system property passsd to maven for that) now that the 0.8 build is complete.  The nightly TPs are all lazy.

Christian 

On November 9, 2016 at 04:27:50, Peter Cigéhn (peter.cigehn@xxxxxxxxx) wrote:

Hi,

I was planning on verifying a Bugzilla that Christian have fixed, but we seem to have yet another similar issue of "pinning" a version of something that no longer exist. The latest build of https://hudson.eclipse.org/papyrus-rt/job/Papyrus-RT-Master-Product/ #222 (that I triggered manually, since build #221 had failed with the mysterious java.io.IOException: Unexpected termination of the channel) now fails with 

Could not find "org.eclipse.papyrus.junit.feature.feature.group/2.0.1.201611060311" in the repositories of the current location

When checking the p2 repo https://hudson.eclipse.org/papyrus/job/Papyrus-Neon-Developer/lastSuccessfulBuild/artifact/repository/ the only available version of this feature is org.eclipse.papyrus.junit.feature_2.0.1.201611090410.jar.

Are we missing a "lazy" keyword here as well?

/Peter Cigéhn

On 8 November 2016 at 13:59, Christian Damus <give.a.damus@xxxxxxxxx> wrote:

Indeed. The non-lazy mode is critically important for reproducibility of builds, especially for release builds in which the dependencies are all also releases and so permanently available.  It might also make sense for stable milestone builds, but we don't really do those.  At least, not yet.

Christian

On November 8, 2016 at 07:55:48, Philip Langer (planger@xxxxxxxxxxxxxxxxx) wrote:

Hi,

the "lazy" keyword is equivalent to version 0.0.0 in the target file, which means that the most current version will be selected at _resolution time_. If the "lazy" keyword is _not_ used, the version will be fixed to a specific version, which is the most current version at the time at which the target file is generated.

The latter is more conservative and fine for release streams, as there won't be any surprises regarding the versions we consume. But we definitely should use the "lazy" keyword for nightly builds, because otherwise the build may fail in the future, when a specific version is not available anymore. I think, we should also use lazy for integration builds, as we typically want to test the integration with all the latest other plug-ins within the defined range rather than with a specific version.

Hope that helps!

Best wishes,

Philip

On Tue, Nov 8, 2016 at 11:47 AM, SCHNEKENBURGER Remi 211865 <Remi.SCHNEKENBURGER@xxxxxx> wrote:

Hi,

 

Regarding the “lazy” keyword, in which context should we use it? The usage is quite heterogeneous in the .tpd files, I would like to understand better the case.

 

Regards,

Rémi

 

-------------------------------------------------------

 

Rémi SCHNEKENBURGER

+33 (0)1 69 08 48 48

CEA Saclay Nano-INNOV

Institut CARNOT CEA LIST

 

www.eclipse.org/papyrus

 

De : papyrus-rt-dev-bounces@eclipse.org [mailto:papyrus-rt-dev-bounces@eclipse.org] De la part de Philip Langer
Envoyé : mardi 8 novembre 2016 11:11
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Failing builds

 

Hi Céline,

 

thanks, your change -- i.e. regenerating the target -- fixes the build. But to ensure that this problem doesn't reoccur, I'd like to suggest to use the lazy keyword for all non-release update-sites (as mentioned earlier). I applied this keyword in https://git.eclipse.org/r/84214 for EMF Compare / EGit integration update sites.

 

Also, I rebased change 84214, but it seems that unrelated tests are failing (org.eclipse.papyrusrt.umlrt.core.tests.creation.CreateElementTest).

 

Thanks and best wishes,

 

Philip

 

 

On Mon, Nov 7, 2016 at 5:10 PM, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:

Thanks Céline. By the way, are you Ok with merging change 84214?

 

--

Ernesto

 

 

 

 

On Mon, Nov 7, 2016 at 11:01 AM Céline JANSSENS <celine.janssens@xxxxxxxxxxx> wrote:

Hi everyone,

 

The Master-Core build is back to normal.

 

The regeneration of .target, was the solution.

 

Regards

Céline

 

 

 

 

De :papyrus-rt-dev-bounces@eclipse.org [mailto:papyrus-rt-dev-bounces@eclipse.org] De la part de SCHNEKENBURGER Remi 211865
Envoyé : lundi 7 novembre 2016 15:07

À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>

Objet : Re: [papyrus-rt-dev] Failing builds

 

Hi Peter,

 

Céline is currently investigating the patch proposed for these regressions.

 

Regards,

Rémi

 

 

-------------------------------------------------------

 

Rémi SCHNEKENBURGER

+33 (0)1 69 08 48 48

CEA Saclay Nano-INNOV

Institut CARNOT CEA LIST

 

www.eclipse.org/papyrus

 

De :papyrus-rt-dev-bounces@eclipse.org [mailto:papyrus-rt-dev-bounces@eclipse.org] De la part de Peter Cigéhn
Envoyé : lundi 7 novembre 2016 15:06
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : [papyrus-rt-dev] Failing builds

 

Hi,

 

I was about to verify some fixed Bugzillas. But the builds seem to be failing, e.g. https://hudson.eclipse.org/papyrus-rt/job/Papyrus-RT-Master-Core/

 

When looking into the logs, this looks related to the discussion about the changing to use the integration repo of the custom builds of EGit and EMF Compare, which I guess is what is proposed in https://git.eclipse.org/r/#/c/84214/

 

Could someone who knows more about the builds and why they are failing look into this, and if possible merge in the proposed Gerrit change (if that is concluded what should fix the failing builds).

 

/Peter Cigéhn

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

 

--

Dr. Philip Langer

Senior Software Architect / General Manager
EclipseSource Services GmbH

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

--

Dr. Philip Langer

Senior Software Architect / General Manager
EclipseSource Services GmbH

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev