Good morning peeps, I would like to open this thread to discuss some ideas about how to improve the current build on Push server. Lukas have been doing a stellar job improving it and I think we can help. Yesterday I spent some time trying to build a developer environment for UPS — was a good exercise to realize how people feel trying to contribute. The goal was to build the environment from scratch. Here comes some feedback (keep in mind that I'm not that good on Node.js) - Build our dependencies takes a considerable time. For fair reasons, we are running mvn install, npm install and bower install for the first time. Maybe we can reduce one step? - Java developers don't have their environment ready for Node — it can be a blocker. For example, was necessary to install gcc, libpng and libpng-devel. I already saw team members struggling with it, like me.

- Maybe we should run -Pdev by default and run the complete build only for CI.

- Maybe we can minify some JS dependencies and don't build everything altogether? I built an image[1][2], because developers willing to just use UPS with the latest bits might struggle to configure their environment and maybe it can be helpful.

The image is not perfect and soon will be moved to jboss/dockerfiles. Thoughts? [1] - https://github.com/abstractj/docker/tree/master/aerogear-unifiedpush-dev [2] - https://registry.hub.docker.com/u/abstractj/unifiedpush-dev/ -- abstractj PGP: 0x84DC9914 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Good morning peeps, I would like to open this thread to discuss some ideas about how to improve the current build on Push server. Lukas have been doing a stellar job improving it and I think we can help. Yesterday I spent some time trying to build a developer environment for UPS — was a good exercise to realize how people feel trying to contribute. The goal was to build the environment from scratch. Here comes some feedback (keep in mind that I'm not that good on Node.js) - Build our dependencies takes a considerable time. For fair reasons, we are running mvn install, npm install and bo http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shri... install for the first time. Maybe we can reduce one step?

- Java developers don't have their environment ready for Node — it can be a blocker. For example, was necessary to install gcc, libpng and libpng-devel. I already saw team members struggling with it, like me.

- Maybe we should run -Pdev by default and run the complete build only for CI.

- Maybe we can minify some JS dependencies and don't build everything altogether? I built an image[1][2], because developers willing to just use UPS with the latest bits might struggle to configure their environment and maybe it can be helpful. The image is not perfect and soon will be moved to jboss/dockerfiles. Thoughts? [1] - https://github.com/abstractj/docker/tree/master/aerogear-unifiedpush-dev [2] - https://registry.hub.docker.com/u/abstractj/unifiedpush-dev/ -- abstractj PGP: 0x84DC9914 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Aug 6, 2014, at 7:22 AM, Lukáš Fryč <lukas.fryc(a)gmail.com&gt; wrote: Hey Bruno, awesome job with the docker image! Could we mention that in the README? I've created this issue to track improvements in the build itself: https://issues.jboss.org/browse/AGPUSH-881 Responds inline: On Tue, Aug 5, 2014 at 9:56 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > Good morning peeps, > > I would like to open this thread to discuss some ideas about how to > improve the current build on Push server. Lukas have been doing a > stellar job improving it and I think we can help. > > Yesterday I spent some time trying to build a developer environment for > UPS — was a good exercise to realize how people feel trying to contribute. > The goal was to build the environment from scratch. > > Here comes some feedback (keep in mind that I'm not that good on Node.js) > > - Build our dependencies takes a considerable time. For fair > reasons, we are running mvn install, npm install and bo > http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shri... > install > for the first time. Maybe we can reduce one step? > We cannot avoid Maven and if we want really fresh compiled-from-sources approach (as opposed to store-compiled-to-git what we had before), we need go with both, Bower and NPM. Storing NPM deps in /node_modules is platform-dependent <http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shri... . We could store there Bower dependencies though. We can use exportsOverride <https://github.com/liveoak-io/liveoak/blob/master/console/src/main/resour... section to extract just those files from our dependencies that we actually require in the project. Once updated, we can save them. But once you have NPM installed correctly, it's just a small step to running Bower. > > - Java developers don't have their environment ready for Node — it can > be a blocker. For example, was necessary to install gcc, libpng and > libpng-devel. I already saw team members struggling with it, like me. > This is a blocker, I wasn't even aware of it - we may want to choose other plugins that don't require those dependencies or maybe inspect what grunt plugins we are even using. Do we even need some of those Grunt plugins like PNG minification (imagemin)? +1, i’m guessing some of those are defaults from a base yeoman build? > > - Maybe we should run -Pdev by default and run the complete build only > for CI. > Yes, we have to come with sensible defaults. We store our NPM/Bower caches inside the project structure and we clean them with each clean. This is anti-pattern - in Java analogy - it's cleaning .m2/repository for each build - we should clean them just when we explicitly want to. -Pdev would stay here, but it would just remove /node_modules and /bower_components a) should add one more profile to clean even caches, e.g. -Pforce-clean b) or do not clean it at all and document that if one needs completely fresh sources, he should clean manually by "git clean -f -x -d" and "npm cache clean" > > - Maybe we can minify some JS dependencies and don't build > everything altogether? > > I built an image[1][2], because developers willing to just use UPS with > the > latest bits might struggle to configure their environment and maybe it > can be helpful. > > The image is not perfect and soon will be moved to jboss/dockerfiles. > > Thoughts? > > [1] - > https://github.com/abstractj/docker/tree/master/aerogear-unifiedpush-dev > [2] - https://registry.hub.docker.com/u/abstractj/unifiedpush-dev/ > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev Also, someone suggested to use wro4j - as long as it is vital alternative for the build time, wro4j is really not handy for development, you won't get as quick turnaround as with Grunt. Some plugins we use doesn't even have to be available in wro4j, e.g. ngtemplates, ngmin. Making the build straight-forward is an ongoing, continuous process and we have still lot to investigate here. It can't definitely be finished in 1.0 time. Bear in mind that Node/NPM is very young technology and it will take some time to get it to the state where Maven is (if ever). In the meantime, I encourage you to use this awesome docker image Bruno created! _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Hey Bruno, awesome job with the docker image! Could we mention that in the README?

I've created this issue to track improvements in the build itself: https://issues.jboss.org/browse/AGPUSH-881

Responds inline: On Tue, Aug 5, 2014 at 9:56 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > Good morning peeps, > > I would like to open this thread to discuss some ideas about how to > improve the current build on Push server. Lukas have been doing a > stellar job improving it and I think we can help. > > Yesterday I spent some time trying to build a developer environment for > UPS — was a good exercise to realize how people feel trying to contribute. > The goal was to build the environment from scratch. > > Here comes some feedback (keep in mind that I'm not that good on Node.js) > > - Build our dependencies takes a considerable time. For fair > reasons, we are running mvn install, npm install and bo > http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shri... > install > for the first time. Maybe we can reduce one step? > We cannot avoid Maven and if we want really fresh compiled-from-sources approach (as opposed to store-compiled-to-git what we had before), we need go with both, Bower and NPM. Storing NPM deps in /node_modules is platform-dependent <http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shri...

. We could store there Bower dependencies though. We can use exportsOverride <https://github.com/liveoak-io/liveoak/blob/master/console/src/main/resour... section to extract just those files from our dependencies that we actually require in the project. Once updated, we can save them. But once you have NPM installed correctly, it's just a small step to running Bower.

> > - Java developers don't have their environment ready for Node — it can > be a blocker. For example, was necessary to install gcc, libpng and > libpng-devel. I already saw team members struggling with it, like me. > This is a blocker, I wasn't even aware of it - we may want to choose other plugins that don't require those dependencies or maybe inspect what grunt plugins we are even using. Do we even need some of those Grunt plugins like PNG minification (imagemin)?

> > - Maybe we should run -Pdev by default and run the complete build only > for CI. > Yes, we have to come with sensible defaults. We store our NPM/Bower caches inside the project structure and we clean them with each clean. This is anti-pattern - in Java analogy - it's cleaning .m2/repository for each build - we should clean them just when we explicitly want to. -Pdev would stay here, but it would just remove /node_modules and /bower_components a) should add one more profile to clean even caches, e.g. -Pforce-clean b) or do not clean it at all and document that if one needs completely fresh sources, he should clean manually by "git clean -f -x -d" and "npm cache clean"

> > - Maybe we can minify some JS dependencies and don't build > everything altogether? > > I built an image[1][2], because developers willing to just use UPS with the > latest bits might struggle to configure their environment and maybe it > can be helpful. > > The image is not perfect and soon will be moved to jboss/dockerfiles. > > Thoughts? > > [1] - > https://github.com/abstractj/docker/tree/master/aerogear-unifiedpush-dev > [2] - https://registry.hub.docker.com/u/abstractj/unifiedpush-dev/ > -- > Also, someone suggested to use wro4j - as long as it is vital alternative for the build time, wro4j is really not handy for development, you won't get as quick turnaround as with Grunt.

Some plugins we use doesn't even have to be available in wro4j, e.g. ngtemplates, ngmin. Making the build straight-forward is an ongoing, continuous process and we have still lot to investigate here. It can't definitely be finished in 1.0 time.

Bear in mind that Node/NPM is very young technology and it will take some time to get it to the state where Maven is (if ever). In the meantime, I encourage you to use this awesome docker image Bruno created!

_______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Wed, Aug 6, 2014 at 3:10 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > Ahoy, answers inline. > > On 2014-08-06, Lukáš Fryč wrote: > > Hey Bruno, > > > > awesome job with the docker image! > > Could we mention that in the README? > > Sure thing, glad you enjoyed. > > > > > > > I've created this issue to track improvements in the build itself: > > https://issues.jboss.org/browse/AGPUSH-881 > > Thanks a lot. > > > > > Responds inline: > > > > On Tue, Aug 5, 2014 at 9:56 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; > wrote: > > > > > Good morning peeps, > > > > > > I would like to open this thread to discuss some ideas about how to > > > improve the current build on Push server. Lukas have been doing a > > > stellar job improving it and I think we can help. > > > > > > Yesterday I spent some time trying to build a developer environment for > > > UPS — was a good exercise to realize how people feel trying to > contribute. > > > The goal was to build the environment from scratch. > > > > > > Here comes some feedback (keep in mind that I'm not that good on > Node.js) > > > > > > - Build our dependencies takes a considerable time. For fair > > > reasons, we are running mvn install, npm install and bo > > > > http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shri... > > > install > > > for the first time. Maybe we can reduce one step? > > > > > > > We cannot avoid Maven and if we want really fresh compiled-from-sources > > approach (as opposed to store-compiled-to-git what we had before), we > need > > go with both, Bower and NPM. > > > > Storing NPM deps in /node_modules is platform-dependent > > < > http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shri... > > > > Bummer, got it. That makes sense. > > . > > > > We could store there Bower dependencies though. We can use > exportsOverride > > < > https://github.com/liveoak-io/liveoak/blob/master/console/src/main/resour... > > > > section to extract just those files from our dependencies that we > actually > > require in the project. Once updated, we can save them. > > > > But once you have NPM installed correctly, it's just a small step to > > running Bower. > > If is just a small step let's leave it as is. > > > > > > > > > > - Java developers don't have their environment ready for Node — it can > > > be a blocker. For example, was necessary to install gcc, libpng and > > > libpng-devel. I already saw team members struggling with it, like me. > > > > > > > This is a blocker, I wasn't even aware of it - we may want to choose > other > > plugins that don't require those dependencies or maybe inspect what grunt > > plugins we are even using. Do we even need some of those Grunt plugins > like > > PNG minification (imagemin)? > > Maybe we can improve here! Remove imagemin would be a win, once it > requires libpng and libpng-devel. (not sure about the impact of removing > it) > > > > > > > > > > > - Maybe we should run -Pdev by default and run the complete build only > > > for CI. > > > > > > > Yes, we have to come with sensible defaults. We store our NPM/Bower > caches > > inside the project structure and we clean them with each clean. This is > > anti-pattern - in Java analogy - it's cleaning .m2/repository for each > > build - we should clean them just when we explicitly want to. -Pdev would > > stay here, but it would just remove /node_modules and /bower_components > > > > a) should add one more profile to clean even caches, e.g. -Pforce-clean > > b) or do not clean it at all and document that if one needs completely > > fresh sources, he should clean manually by "git clean -f -x -d" and "npm > > cache clean" > > To me the idea of having a profile to clean everything if they want to, > is a good idea. And what would be the default? -Pdev? > [admin-ui/] $ mvn clean install # clean .tmp/ dist/ [admin-ui/] $ mvn clean install -Dforce-clean # clean .tmp/ dist/ node_modules/ bower_components/ and caches (.build-tmp/) # this is recommended for continuous integration Good news is that our toolchain (NPM, Bower and frontend-maven-plugin) fully reacts on changes in versions (package.json, bower.json and pom.xml). So if you change dependency versions in those configuration files you should get new versions installed pro-actively even with $ mvn clean install, no need for cleaning anything. At the end we should get this: $ mvn clean install -------------------------- BUILD SUCCESS -------------------------- Total time: 14.376s -------------------------- > > > > > > > > > > - Maybe we can minify some JS dependencies and don't build > > > everything altogether? > > > > > > I built an image[1][2], because developers willing to just use UPS > with the > > > latest bits might struggle to configure their environment and maybe it > > > can be helpful. > > > > > > The image is not perfect and soon will be moved to jboss/dockerfiles. > > > > > > Thoughts? > > > > > > [1] - > > > > https://github.com/abstractj/docker/tree/master/aerogear-unifiedpush-dev > > > [2] - https://registry.hub.docker.com/u/abstractj/unifiedpush-dev/ > > > -- > > > > > > > Also, someone suggested to use wro4j - as long as it is vital alternative > > for the build time, wro4j is really not handy for development, you won't > > get as quick turnaround as with Grunt. > > +1 on keep Grunt > > > > > Some plugins we use doesn't even have to be available in wro4j, e.g. > > ngtemplates, ngmin. > > > > > > > > Making the build straight-forward is an ongoing, continuous process and > we > > have still lot to investigate here. It can't definitely be finished in > 1.0 > > time. > > +1 my friend, deal with the build and multiple technologies is not that > easy. We can alwasy improve, thanks for looking at it. > > > > > Bear in mind that Node/NPM is very young technology and it will take some > > time to get it to the state where Maven is (if ever). > > > > In the meantime, I encourage you to use this awesome docker image Bruno > > created! > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev >

_______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev