Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] About build failures

Hi again,

 

Ø  I’ve also removed the Lazy keywords, since versions should not change randomly anymore

 

Unless they do... :) It seems that Nebula has re-released 1.0.0, and judging from the discussion on their mailing list, they may re-release again

 

I’ve updated the TPs to use loose versions again (Gerrit is verifying the contribution; please wait a little bit before rebasing your changes). The current plan for Nebula (And Nattable after them) is to have a final release somewhere between end of may/early june, before the final build for the Release Train. It might still be a little bit chaotic until then

 

Regards,
Camille

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de LETAVERNIER Camille
Envoyé : jeudi 19 mai 2016 11:11
À : Papyrus Project list <mdt-papyrus.dev@xxxxxxxxxxx>
Objet : [PROVENANCE INTERNET] Re: [mdt-papyrus.dev] About build failures

 

Hi all,

 

I’ve updated the Nebula update site, as they have released a new version. I’ve also removed the Lazy keywords, since versions should not change randomly anymore

 

Builds should be back to normal again (You may have to rebase your latest Gerrit commits to pick the fixed target platforms, if your builds failed today)

 

Regards,
Camille

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de LETAVERNIER Camille
Envoyé : vendredi 13 mai 2016 10:34
À : Papyrus Project list (mdt-papyrus.dev@xxxxxxxxxxx) <mdt-papyrus.dev@xxxxxxxxxxx>
Objet : [PROVENANCE INTERNET] [mdt-papyrus.dev] About build failures

 

Hi all,

 

 

You may have noticed frequent build failures recently. This is related to the Target Platforms using explicit versions (including qualifier) for dependencies. This approach ensures safer builds, since we won’t pull any unexpected artifact into the build, but this fails quickly when we depend on mutable update sites (Especially when they evolve quickly)

 

The failures are especially related to our Nattable and Nebula dependencies, because we don’t depend on released versions of these plug-ins (Just Nightlies or Integration builds). We’re getting close to the release date (RC1 is next week), so we should really think about stabilizing these dependencies (I know the Nattable 1.4 release will occur before the last RC so that should be fine; however I don’t know about Nebula)

 

For now, I’ve reconfigured the target platforms to always pick the latest version of Nebula and Nattable plug-ins, so we shouldn’t see such failures again. I’m not inclined to generalizing this policy, because explicit versions help detecting changes in our dependencies much earlier.

 

If the build fails again on an invalid version of a dependency, here’s how to fix it:

 

 

Bug 492723 [1] introduced a new Dependency Updater to the Papyrus Releng Tools, to maintain the target platforms based on the Simrel contents (Similar to what’s done for Oomph and POMs). You have to install the following:

 

Papyrus Developer Tools: https://hudson.eclipse.org/papyrus/job/Papyrus-Master-Developer/lastSuccessfulBuild/artifact/repository

Target Platform Definition: http://mbarbero.github.io/fr.obeo.releng.targetplatform/p2/latest

 

(Note that TPD is not installed automatically, because this isn’t an Eclipse Project and we don’t have a CQ for including it)

 

You also need to import the Simrel project from git, into your workspace: https://git.eclipse.org/r/simrel/org.eclipse.simrel.build

 

Once everything is installed, import the Papyrus Releng project, right click on it, and select “Generate all target files”. This will update the *.tpd files based on the Simrel project contents, then regenerate all *.target files and set the current version of each plug-in. It may take a long time (10-20 minutes?) when using this action for the first time, but it will be much faster afterwards (0-30s). Then all you have left to do is to commit & push the changes.

 

 

Hopefully, with the new policy for Nebula plug-ins, we shouldn’t have to do this too often. If the builds keep failing on a regular basis, we can reconsider the best policy for plug-in/feature version restrictions (As well as the policy for relying on unreleased Eclipse projects/versions :) )

 

 

Regards,
Camille


Back to the top