Hi Basti,
thanks for the detailed explanation about possible js build solutions. This
is tough to answer right away. I personally would go with solution #2,
since it's the most efficient workflow in my humble opinion. Every other
solution you described sounds like it would lead to a diffuse separation of
UI- and NoneUI developers with different workflows. I don't think we want
that, or even push a separation like this.
Besides, in my understanding it's quite common situation: If you want to
develope on an application which have a JS build, well then you need to
install the needed tools for that. Don't matter if you going to change
something in the JS part or not. I don't thinks it's that much of downside.
It would be helpful to know how "hard" it's actually is to provide the
environment for the JavaScript build process (NodeJS and npm). Do we talk
about 2 simple installations that can be done in 5 minutes with a quick
guide?
Or is this more a "read and learn git" kind of task ;-).
Best regards,
Matthias
2015-05-18 11:16 GMT+02:00 Bastian Sieker <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
> 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
