CSS: where do we want to go? Gabriele Carcassi Contributions from: Gabriele Carcassi, Kunal Shroff – BNL Jan Hatje – DESY Kay Kasemir – ORNL

Last couple of years of CSS 2011/5/ Alluring Albatross 2012/2/ Ballistic Beaver 2010/7 Mercurial repository 2010/7 SourceForge 2010/8 Continuous build

Pre 3.0 Moved to sourceforge – Mailing list – Wiki Mercurial repository – On sourceforge – Revised directory structure Continuous build – Use of p2 – Jenkins for continuous integration

Release 3.0 Modularization – Starting to break platform apart – Use of adapters – Use of commands – Menu redefined using extensions Introduced common stable 3.0.x branch

Release 3.1 Finished modularization Common change-log for core and features Moved OS dependent JNI bindings to fragments Expanded common ui element – Error bar/dialog – CommandHandler base class

TASKS FOR FUTURE RELEASES Non-exhaustive, non-definitive, highly optimistic, that will take more than a year to do, list of

Janitorial tasks Remove non-modularize code? – After 2012/7/31 DESY Go through and review “common” utilities? – Pretty much each site has been dumping things – We need a way to distribute at least javadocs Published through build? SNS does not care, BNL does – How can we improve?

git This year Eclipse is going to migrate away from CVS in favor of git Migrate CSS too? – Eclipse git integration is now good and will probably have the most focus from the community – BNL, SNS and DESY seem to all agree – Can the better handling of branching help us? – After 2012/7/31 DESY Any change in the repository structure we want to do? – Separate 3 rd party dependencies? Separate core? Separate features?

e marks the last official release of Eclipse 3.x Migrate CSS to e4? – First step would be to use the compatibility layer – Then we can move feature/plug-ins – After 2012/6/ release No more difference between “Editors” and “Views” – You can move any application wherever you want!

External libraries Currently external dependencies are put inside the CSS code repository Build the wrapper plug-ins separately, and place them in a common p2 repository? – How is source supported? Eclipse core plug-ins do it! 3 rd party P2 repo Source repo Build

Application release As of today, only core development is properly branched and release – Sites typically release their product from the core branch, were all application development happens As a developer, you have no control of what is being deployed at sites – They will have whatever snapshot you had at time to release – Its impractical to provide support like that As a site, you have no guarantee that what you are deploying was properly tested

Application release - proposals Release train – We coordinate a date, and we all release our products at the same time – Pros: cheap to implement; Cons: high coordination (choosing date, different schedules, …) Break up application features in different repositories – Like Eclipse itself does – Pros: each feature can release at their own pace, each site can choose what to integrate; Cons: scattered development, still need to provide a way to easily bring it back together

Application release - proposals A build for each feature – We setup a separate build for each feature – Each of these builds publishes to a p2 repository – When you build your product, you use the pre- built version (similar to a 3 rd party library) – Pros: does not impact current mode of development, product build is significantly easier and faster, can be integrated in the continuous build; Cons: need to setup a build for each feature

Single “community” product Both CSS DESY Island and CSS SNS Basic EPICS target a “generic” site Some sites are using CSS NSLS-II product Building your site product is currently an expensive process Maybe we could have a “community” product, where people can install the features they want? – It’s one of the things Eclipse RCP supports decently! And that it’s easily branded/customized for each site’s need? Need to investigate what is technically feasable with what tools

Single “community” product Community product: empty shell, you get the feature you want from the update site Product build: you provide your configuration, feature list and splash-screen, and you are done – No knowledge of Eclipse required 3 rd party update site (Eclipse, jca, …) CSS update site (BOY, SDS, …) CSS Community CSS your site Site configuration Feature list

Tycho Currently you have to specify dependencies in multiple locations – OSGi, workspace (for development), features (in the right order!), plugin.list (for command-line build) Tycho (based upon maven) lets you specify things once Would this help us? – Would need someone to get some experience with it – Or get someone that has already experience with it

JavaFX SWT/JFace is my least favorite part of Eclipse – 70% of my time is spent trying to make SWT do reasonable things – It’s not standard, has very little life outside of Eclipse, very few Open Source widget libraries – Performance on Linux is not as great as Win/Mac – Don’t see as much activity on core development as I would like Oracle has been putting a lot of effort in JavaFX – Integration of SWT and JavaFX is actually better than JavaFX and Swing as they live on the same UI thread 4Q/2012 Linux r2.1, 4Q/2013 r3.0 including in Java 1.8 But not too late to get experience – How will integrate with pvManager? – Will current conventions work? – Will it work with webOPI?

Conclusion Plenty of things to do But: there are plenty of sites interested and contributing to CSS If we share this vision, and we are better coordinated, the amount of work is not that much!