[aerogear-dev] AeroGear UnifiedPush server build feedback

Bruno Oliveira bruno at abstractj.org
Thu Aug 7 15:54:06 EDT 2014


Nice Lukas, thank you for the effort.

Let's stick with your suggestions.

On 2014-08-06, Lukáš Fryč wrote:
> On Wed, Aug 6, 2014 at 3:10 PM, Bruno Oliveira <bruno at abstractj.org> 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 at abstractj.org>
> > 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-shrinkwrap/wer
> > > > 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-shrinkwrap/
> > >
> >
> > 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/resources/bower.json#L28
> > >
> > > 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 at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj
PGP: 0x84DC9914


More information about the aerogear-dev mailing list