Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
CBI/March6 2012
Contents
Meeting
- March 6, 2012, 10am EST
- Eclipse Conference facility
Attendees
Andrew R., Kim M., Paul W., Denis R., David W., Markus K., Thanh H.
Regrets: Igor F.
Minutes
Packaging with CBI build Eclipse platform
Markus: EPP migrate to git, done. Starting work to use CBI-platform involves two steps:
- meta data creation, branding plugins and features with buckminster. Switch to tycho.
- p2 director call, create final packages. This step remains the same.
Dual solutions for #1 could be used in parallel to prove CBI works.
Another item could be changed, 2nd part of epp build, consuming eclipse platform p2 repositories & simultaneous release repositories. Could be changed in the future. Change p2 director call to consume output from cbi-platform build.
Need to move this discussion to epp-dev. need agreement from package maintainers. mail to mailing list.
Kim: PMC may not be aware. McQ & PMC likely planning that what Eclipse contributes will be PDE build.
Paul: how can we confirm Eclipse project repos are the same
David Williams: terrible idea for two different versions of bundles in Eclipse Classic and EPP. Should be one bundle everyone uses. It would be chaos to have multiple. Even if we had a way to prove they are exactly the same bundle, it still wouldn't make sense to release 2.
NOTE: This topic was raised in the Planning Council meeting on March 7, 2012. See the minutes and David's summary of the statement from the PC on cbi-dev.
Signing
Paul, per repos signing. Dash has eclipse signing plugin.
Andrew: Note to self, invite some dash folks to cbi-dev & cbi meeting.
David: signing jar by jar doesn't work well. Paul: jar by jar may be the maven default way. what we need is to build p2 repos, sign, comparator, then you can publish & build products
Testing
Paul: for SDK, we have test.xml script which drives automated tests. uses pattern where main test script launches test suites for each plugin. Each plugin has it's own test.xml. Two flavours of tests => headless plugin & UI tests. swt testing looks to be the same.
David: the other big requirement for testing is how test environments are set up. e.g. apache for wtp/server interaction. likely similar for databases e.g. Eclipselink. Running all these tests likely harder than building. We'll need some sort of standard way of making sure things are set up correctly & for how CBI hooks into running these and detecting results.
Andrew: agreed. Editorial: this likely won't come right away for LTS 1.0 out of the gate. It'll take time to work through the build tools first, then test tools.
Andrew: what about performance tests?
Kim: Performance target in test.xml. Results stored in db. Process which generates graph, etc. Baseline once a week to compare current vs. baseline. Someone on platform team is dedicated to monitoring performance and opening bugs if they see increases.
junit on 3 platforms (MacOS, Windows, Linux). build & swt start up test for 13 plaforms.
Kim: There is also a 3rd party package which does code coverage. % of code covered by tests. In org.eclipse.tests Kim will send link.
Kim/Andrew/David: Bug 367581 is the first step for comparison. 2nd step is the comparator.
Paul: What comes from maven central? Doesn't tycho only do p2 unless you do work to ask. Does the IP team vet the build tools?
David: only things that are distributed go through IP process. any tools you use to build your software must be freely available.
Andrew: Note for me to talk with Janet.
David: test data is the same. We don't distribute it. There is one example where test data has a license that might not be acceptable in all cases (e.g. not EPL).
Paul: map files to tycho still a concern. Need them for comparison. Map files contain repos & qualifier & actual tag the build could check out to get it & location in the repos.
If we start with Juno and go forward, we can let git tell is if it's changed. If we need to go back, it'd be a different mechanism. This could be considered later.
Andrew: Editorial: We could probably "migrate" older releases to git as well. We'll cross that when we come to it based on demand.
Andrew: See Bug 370707