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