CSS: where do we want to go?

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

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

3. 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

4. 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

5. 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

6. Non-exhaustive, non-definitive, highly optimistic, that will take more than a year to do, list of Tasks for future releases

7. Janitorial tasks • Remove non-modularize code? • After 2012/7/31 DESY 1.5.0 • 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?

8. 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 1.5.0 • Any change in the repository structure we want to do? • Separate 3rd party dependencies? Separate core? Separate features?

9. e4 • 2012 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/27 4.2 release • No more difference between “Editors” and “Views” • You can move any application wherever you want!

10. 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! Source repo 3rd party P2 repo Build

11. 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

12. 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

13. 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 3rd 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

14. 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

15. 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 3rd party update site (Eclipse, jca, …) CSS Community CSS update site (BOY, SDS, …) CSS your site Site configurationFeature list

16. 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

17. 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?

18. 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!