Community
Participate
Working Groups
The current state of the Search Console continuous integration is suboptimal. - Committers of the component are unfamiliar with how the e4 build works, and therefore do not know how to ensure it isn't broken by commits in search; - Breaking of the build usually occurs outside European working hours, and we are unable to react in a timely manner - the build framework enforces that we make undesired changes to our code, as per Bug 370631 - if we want to make enhancements of the build specific to Search, e.g. Findbugs/Emma/Architecture 101, etc, we have to rely on platform/ui releng to provide those It is therefore worth discussing whether to set up dedicated CI of Search Console on hudson.eclipse.org. - It would be based on Maven and Tycho, which we have the expertise to maintain; - Tycho is known to handle the cyclic dependencies problem described in Bug 370631 - The whole build would be trigerred on each submit in the development branch, and we would have notification in case of failure; - Search console would still be built (without its tests being run) by the e4 build, in order to have Search Console in the e4 updatesite. Ideally, the development can happen in a development branch, e.g. "dev", and successful build would automatically merge changes in "master", which is currently autotagged in e4 build. This way, only stable content would end up on e4 update site. This is prio 2, however. Please comment whether you see any problems with such an approach? Regards, Dimitar
re: maven and tycho. If you want to maintain a maven/tycho build there's no problem with that, p2 does the same thing (on the side). Other projects are using maven 3.0.3 and tycho 0.13 (and the soon to be released 0.14). They still must consume their 3rd party deps from Orbit, but tycho doesn't mind. There are problems, though, around qualifiers (which tycho can't read from maps and aren't supposed to change if your plugin hasn't changed). I don't know how you are going to overcome that. We can also get a job set up on Hudson, although it won't support auto-tagging (hudson can't do that). But this seems to be a workaround for a problem that doesn't exist (the reasons to use fragments for tests are not valid within the Eclipse Project). It would be nice to be able to run the e4build with your maven poms as well, but your maven build would need to be able to: 1) build a p2 repo and sign it when run as the correct user (e4Build) on build.eclipse.org, as mentioned in http://wiki.eclipse.org/Minerva#Signing 2) find the correct version of 4.2 to run against 3) provision the tests correctly in the 4.2 eclipse and run the tests This still won't remove the requirement that to graduate for use in the Eclipse SDK that Search Console needs the tests to be built by PDE build and run by the automated test framework, and the bugs that are standing in the way you would have to fix yourself. PW
As Paul has pointed out, our code must be compatible with PDE build anyways - Dani is working on that at the moment. This is a side activity, so I am marking it as an enhancement.
(In reply to comment #2) > As Paul has pointed out, our code must be compatible with PDE build anyways - > Dani is working on that at the moment. You don't refer to me here, do you?
No, 'Dani' reads 'Danail' here. Sorry for that :)
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it and remove the stalebug whiteboard tag. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. --
