1 / 18

CSS: where do we want to go?

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. 2010/7 Mercurial repository. 2011/5/31 3.0 Alluring Albatross. 2012. 2011. 2010/7 SourceForge. 2010/8

parker
Download Presentation

CSS: where do we want to go?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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!

More Related