External Dev Time Directory #121

phidias51 opened this Issue Sep 6, 2016 · 4 comments


None yet

3 participants


Within the last 5 years or so, the architecture of most applications have changed. Where traditionally the UI might consist of GSP pages, or JSP pages, applications are increasingly making use of front-end frameworks like Angular, React and Polymer. Sometimes the UI is deployed to a separate server (like nginx) sometimes it's deployed in the WAR along with the server-side application. It is this latter scenario that I'd like to see better supported with the asset pipeline.

In my projects the user interface code is primarily Polymer-based. We have a large collection of components that we want to reuse. Our directory structure looks something like this:



The /bower_components directory contains 3rd party components, and the /corp_components directory contains internally developed components that we want to leverage in our projects.

Is there a way for us to configure the asset pipeline plugin in each of the grails projects to point to /component_lib? During development it would need to resolve against the /component_lib directory, but when the grails projects are WAR'd then, it would need to pull the components that were used by each of the projects into the WARs. This would significantly reduce the amount of disc space used by 3rd party components.

We currently use gradle to copy the UI into the grails project for deployment. But that's a less than optimal solution, because we can't cherry pick the components that we want to include, and we can't make use of the bower dependency declarations. Here's a typical use case:

Let's suppose that I have an element called my-card which exists in the shared components directory /component_lib/corp_components/my-element/my-card.html. This element depends on Polymer's paper-card found in /component_lib/bower_components/paper-card/paper-card.html.

Let's suppose that I have a project-specific element that uses my-card. What I want to be able to do is configure the asset pipeline to read the bower files for all of the dependencies in the dependency chain, pick up the right dependencies and put them in my war file whenever I build it.

Since I want to minimize the numbers of copies of these dependencies that are floating around my hard drive, I want asset pipeline to simply resolve the dependencies to my local /component_lib directory.

This last bit may not be possible, but in any case I want to minimize the number of copies on my drive by whatever means possible.


One possibility is an integration with jspm and System.js. In ES6 there will be support for module loading and so at some point the JVM/Spring/Grails world will have to address this. The use cases would include the download of javascript dependencies, transpilation, minification, bundling, and dev time versus production time module loading.

My solution has been to do my CSS in asset-pipeline (put there by a one time run of bower, then building my scss for my app) and then have my javascript app live in src/main/webapp and run a gulp watch on that directory during dev time. For production, I run a gulp build and/or bundle then a war (for me a grails war) to get all the files for deployment.

I have been thinking of how asset-pipeline would handle these but as I am still somewhat new to it I don't have a good picture.

davydotcom commented Sep 7, 2016 edited

This is actually doable out of the box as is: The trick is you have to do this in 2 places both build time and development runtime...

To perform this setup first in gradle:

assets {
  from '/path/to/components'

Then in Bootstrap.groovy

  new asset.pipeline.fs.FileSystemAssetResolver('customName','/path/to/components',false)
@davydotcom davydotcom closed this Sep 7, 2016

So this will resolve bower dependencies?


It lets you point to external folders. I don't recommend the use of bower but there is a nice gradle client dependencies plugin that resolves both bower and npm packages

Sent from my iPhone

On Sep 7, 2016, at 10:30 AM, Mark Fortner notifications@github.com wrote:

So this will resolve bower dependencies?

You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment