| For Linux, the problem was definitely the version of Java - installing Java 8 fixed the problem I had.
Thank you, Christian, for pointing that out - that was very helpful.
I wil try the newly built Mac version later today.
I can’t test the Windows version as my Windows VM appears to be FUBAR really broken… I’ll need to get one from my archives or reinstall.
/Charles
Thanks Christian,
For Linux, that may very well be the case. I’ll check that, but I am fairly certain I have not installed Java 8 on that VM.
For Mac, however, I doubt it. I have Java 8 installed and I have been running both Papyrus-RT from the Oomph tester setup without problems and Papyrus Neon.1 RCP without problems. I also can’t find a log file… Also, according to Apple, this error can be associated with a error in signing the application - although even overriding the security around that results in the same dialog.
However, comparing what is in the downloaded archive with another Papyrus-RT installation from Oomph, the RCP installation is significantly different...
I haven’t been able to test on Windows yet as my VM has some issues…
Sincerely,
Charles Rivet
Senior Product Manager, Papyrus-RT product lead
Hi, Charles,
For the Linux case, it appears that all or at least much of the problem is that you’re not launching the package with a Java 8 or later JRE (OSGi is complaining that bundles requiring Java2 SE 1.8 aren’t being given a suitable execution environment). How are you telling the package which Java installation to use?
The Mac error could be similar: this is a generic dialog that the system shows whenever the executable within the bundle crashes on launch. As in the Linux case, which also is crashing on launch, you should be able to find a log file from the failed launch. Does it look similar?Cheers,
Christian
On 11 October, 2016 at 15:57:02, charles+zeligsoft.com (charles@xxxxxxxxxxxxx) wrote:
Linux:
Not sure if they are related to the build issues, but I was able to run the builds last week…
/Charles
Hi Celine, I may not have understood what you are working on, but it looks like you want to trigger the required builds when dependencies change. I would suggest that we could defer this work until the next release. We are hoping to get a release done by the end of the week, after which we will stop building 0.8 and start work on 0.9. I think probably the most urgent build issue is getting the RCPs to build with the correct content. I just downloaded the windows RCP and see that there is not Papyrus perspective available and there is no viewpoint under Papyrus. Also, Charles tell me the Linux and Mac versions crashes, which may be related to the perspective or viewpoint changes. Regards, Simon The options that you outline are clear. I guess we’re really fighting the Hudson architecture on this one, eh? Our scenario strikes me as so perfectly common that I’m really surprised it isn’t better accounted for by the available tools. Is there something we’ve overlooked? Or maybe what we’re trying to do with component builds isn’t so common, and that for good reason? I honestly don’t know which of these options I would recommend over the others. All three have characteristics that appeal to me. In any case, I think that perhaps we should put any plans to further decompose the builds on ice until we get a conclusion to this question. On 11 October, 2016 at 11:30:15, Céline JANSSENS (celine.janssens@xxxxxxxxxxx) wrote: Hi Christian, No it won’t trigger the Product if only Tooling is impacted. This is the regression of the join method. If I keep the cascading from Tooling and from Codegen to Product, in addition with the Join trigger, Product will be triggered 3 times ;s So there are 3 solutions with their inconvenience: 1) We keep it as previously => Product triggered twice if Core is impacted, once if Tooling or Codegen, and all combinations if changes impact several components. 2) We keep the join and trigger the Core on every modification => 3 Components are built even if not necessary but only once 3) We cascading Core > Tooling > Codegen > Product => If only Tooling is impacted, this configuration builds Codegen even if not necessary and all combinations if changes impact several components.
So if in most of the case we modify only one component by Change or every 15 minutes, the 3d solution is the more efficient. Otherwise, if there are several components impacted most of time, the second solution is the one we should put in place. I don’t know a solution meeting 100% the requirements. Regards Céline This looks very cool, thanks! One question: I see that all of the configuration is now on the Core job, with the new join trigger. Will the Product build still be run if only, for example, the Tooling build is triggered by a commit that makes only tooling changes? Or will Product now only build after both Codegen and Tooling builds are triggered by a Core build (from a commit that changes core projects)? On 11 October, 2016 at 10:48:03, Céline JANSSENS (celine.janssens@xxxxxxxxxxx) wrote: Hi All, The Join trigger plugin being in place, I configured the different build to avoid to trigger Papyrus-RT-Master-Product twice. Papyrus-RT-Master-Product is now triggered when both Tooling and Codegen are complete More information about the Join trigger plugin installed on the HIPP available here [1] Let me know if you meet any issues. Regards
Céline Hi team, Yes, I am (finally!) back from vacation. I installed the “join” plugin, as this seems to be the most suitable plugin for our needs. I also installed a utility to manage job configs (a kind of version control management for job configurations) Hudson will be restarted when current jobs are finished, so these plugins will be activated. Regards, Rémi ------------------------------------------------------- Rémi SCHNEKENBURGER +33 (0)1 69 08 48 48 CEA Saclay Nano-INNOV Institut CARNOT CEA LIST Hello Chrsitian, That is Remi that has such access rights, for the HIPP. He is back from his vacations, so do not hesitate to see with him ;) Your solution a) seems a good point. I didn’t know that it exists. Well done. Regards Céline Yes, it’s a problem that we have the downstream Product build running once for each completion of its multiple upstreams. There are plug-ins that can help this. Hudson Plugin Central has at least two that address this situation: · join: triggers a job after a group of other jobs finish. It’s the simplest implementation, and I think would be suitable for our case (I have seen reports that it doesn’t work well when parallel job chains to be joined are more than 1 job long) I don’t have admin privilege on our HIPP to see which, if any, of these plug-ins might already be available for us to use. Nor do I know the process for requesting to install new plug-ins, if that’s a thing that we can do for our own HIPP should we decide to do so. And, yes, a change in core should not trigger both the Core and Tooling builds but Core only, because it will kick off Tooling as a downstream anyways. That much is easy to address; I can take care of that. Christian On 4 October, 2016 at 12:04:34, Peter Cigéhn (peter.cigehn@xxxxxxxxx) wrote: I am not sure I understand the proposed change. Currently the product build is triggered by the component builds, core, tooling and so on. I assumed that the reason for the product build to be triggered by the component builds was due to that the product build used the output from the component builds in some way. But now you are saying that the product build can be triggered "on its own", which I interpret as if it does not really depend on the component builds have been run at all. Is that correct? Then what is the purpose of the individual component builds? I am bit confused here... And when you say each 30 minutes, I assume that you mean that the product build should check if there has been an SCM change, i.e. a commit being merged, each 30 minutes. But why should that be check only be made each 30 minutes? That I assume could be checked each 15 minutes as for the component builds. Otherwise you can theoretically have to wait for 30 minutes before the build is triggered (in case the merge is committed right after the last SCM poll) and then the build that takes 17-20 minutes, i.e. up to 50 minutes.
Sure, that is much better than the current situation where you need to wait up to 15 minutes for the SCM poll on the component builds, then build core and tooling in parallell (I assume a few minutes), then build product for up to 24 minutes, in parallel with the second tooling build,, and then the second product build (triggered by the second tooling build) for 24 minutes more, which adds up to more than an hour. Still not sure if I can use the first product build or if I need to wait for the second one.
I thought that the triggering of builds could be made a bit more intelligent, i.e. if it is concluded that a commit impacts both core and tooling, then skip triggering tooling and only trigger core, since you know that core in its turn will trigger the build of tooling. That would avoid the double builds of tooling and product. Hi Peter, As far as I remember, The Core build triggers Tooling and Codegen jobs. Codegen and Tooling jobs both trigger the Product job. So you are right, every time a modification is done on the core, then tooling and codegen jobs are triggered. And both trigger the Product job. It has been whished that the Product should be up to date at least every 15 minutes. That is why, Core, Tooling and Codegen Build check for modification every 15 minutes. Product job is based on Core, Tooling and Codegen sub-repos as it builds the “releng” Target platform. A solution would be not to trigger the product directly from the Components builds, but on a regular basis, 30 minutes seem reasonable. In addition, the RCPTT is being extract from the Product Build to decrease the time of the Product Build to 17-20 minutes. Any remarks on this suggestion ? Regards Céline I have a question regarding the new build system. I find a bit confusing knowing when it is safe to start upgrading and testing a merged commit. Almost all the latest commits that I have been merged and which I wanted to test, and for which I then I have checked the builds when they are finished, have been triggering the final Papyrus-RT-Master-Product to be built (at least) twice. I guess that it is related to that a commit contains changes, e.g. for both core and tooling, which triggers both these builds (in parallell). When these are finished, they trigger the final product build. And then when the core is finished that triggers yet another tooling build, which in its turn triggers a product build again. In more or less all cases I have seen, the second product build has gotten stuck in the queue also since you cannot build two product builds in parallell. Is it safe to test already after the first product build have finished, or do I always have to wait for the second one to finish? More or less always having to wait for two product builds feels pretty time consuming (since each takes up to half an hour to complete). Is the setup of the build system really correct? Why is both core and tooling triggered at the first step? If you only trigger building core, which then triggers tooling, which finally triggers product, then you don't have tooling and product building twice. Any comments? Is this just how it is supposed to work? And that I (to be on the safe side) always needs to wait for the second (or whatever number the final will be) build before I can upgrade safely?
_______________________________________________
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 listpapyrus-rt-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________ papyrus-rt-dev mailing list papyrus-rt-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
|
