Am 18.05.2015 um 13:51 schrieb Matthias Bohnstedt: > separation of UI- and NoneUI developers with different workflows. I > don't think we want that, or even push a separation like this. >
@Franz: How often do people/students do changes to Saros that have absolutely no UI effect? (I am lacking an overview here) If most people touch the UI anyways then introducing this separation really is not a good idea, it would people try to avoid UI changes and that's what we wanted to change with this new UI right. > It would be helpful to know how "hard" it's actually is to provide the It just took me 5 minutes on Linux Mint (sudo apt-get install node npm && npm install && npm install grunt-cli). The only place where I can think of problems is Windows without admin rights, but this also seems to be not too hard: http://abdelraoof.com/blog/2014/11/11/install-nodejs-without-admin-rights/ So I vote for #2 > > Best regards, > Matthias > > 2015-05-18 11:16 GMT+02:00 Bastian Sieker <bsie...@mail.uni-paderborn.de > <mailto:bsie...@mail.uni-paderborn.de>>: > > Hi all, > as I already mentioned in my last mail [1], one of the main aspects of > the Saros HTML/JS GUI is "to establish a solid groundwork to build, > maintain, extend and test the Saros HTML GUI". Therefore, some tools for > automation are inevitable, for example to ease development and > maintenance via automating dependecy management, unit testing, obtaining > code quality etc. > > Apart from that, without a proper JS build chain we would quickly end up > in a morass of hard to maintain and hard to modify javascript. > > In JavaScript one tool to manage tasks and provide a build process is > Gulp [2], which I plan to integrate in the development workflow of the > HTML/JS GUI. Gulp requires NodeJS and NPM (Node Package Manager), which > leads to some overhead for the development environment setup, depending > on your OS. > > Assuming the following (simplified) project structure: > > index.html > js/ > account.js > contact.js > somehting.js > main.js > ... > external/ > jquery.js > some-lib.js > ... > build/ > build.js > > When a developer changes internal code in the `js` folder and/or > adds/removes an external library, the developer has to run `gulp` (see > it as build tool for JavaScript and assume its installed locally). > `gulp` (beside other things like running unit tests) will produce > `build/build.js` which contains all necessarry JS code for the > application, its the only JS file embedded in index.html. > > The problem now is something like: where/how to run gulp? There are > various possibilities: > > #1: Java and JS build processes are separated > --------------------------------------------- > If you change something in the JS part, you are responsible for building > the artefact `build/build.js` yourself before committing (and commit it), > in addition to build the Saros Java part (remember: since there are more > tasks involved in the build process, unit testing for example, you should > do that anyway!). > > + only developers who care about the HTML/JavaScript part > (developers who actually work on that part) must provide the > environment > for the JavaScript build. > > - More complicated for new developers since process has to be > understood. > - A lot of overhead when you only want to make a small change. > > #2: JS build process is integrated in Java build process > -------------------------------------------------------- > `gulp`will run automatically when running the Java application. > > + easy to use for the developers, the JavaScript build process is > "hidden" > in the general Saros build process. > > - Every Saros developer must provide the environment for the JavaScript > build > process (NodeJS and npm). Even Saros developers which may never > touch the JavaScript part would hav to provide the environment. > - The Saros build project gets more complicated. > > #3: A separate project for the JS part > -------------------------------------- > The JavaScript (and HTML, CSS) part is an own project and is utilised by > the Saros Java part as a "library" (The Java part only see the artefact > `build.js` and some HTML, CSS). Its more or less like #1, but it leads > to a more explicit separation of the code and the correpsonding > development process. > > + Only developers who care about the HTML/JavaScript part must provide > the environment for the JavaScript build. > + Developers are forced to test the JavaScript part standalone, > maybe leads to a cleaner interface and development. > > - More complicated for new developers since process has to be > understood. > - A lot of overhead when you only want to make a small change. > > > #4 Some other method I did not think of, tell me! > > What would you prefer and why? Do you have suggestions, objections,...? > > Best, > Basti > > [1]http://sourceforge.net/p/dpp/mailman/message/33953514/ > [2]https://github.com/gulpjs/gulp/blob/master/docs/getting-started.md > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > DPP-Devel mailing list > DPP-Devel@lists.sourceforge.net <mailto:DPP-Devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/dpp-devel > > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > > _______________________________________________ > DPP-Devel mailing list > DPP-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dpp-devel > ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ DPP-Devel mailing list DPP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dpp-devel
