Flow: Flow plugin dependencies mechanism should be reworked.

Created on 4 Dec 2017  路  4Comments  路  Source: vaadin/flow

As an plugin example, consider vaadin-grid. It requires extra files to be used in order to function properly, one of the files is gridConnector.js.

Current way of adding those dependencies is to put them into META-INF/resources/frontend so that flow-maven-plugin can copy them to the resulting war. Those files are copied to the frontend:// roots of the app (frontend-es6 and frontend-es5 by default) for production mode.

If we put gridConnector.js to META-INF/resources/frontend/gridConnector.js, we need to reference it:

  • if we reference the connector as @HtmlImport("frontend://addon.html"), the production mode works fine, since flow-maven-plugin copies files wherever they belong to
    But if the user changes development mode frontend directory location with, say, -Dvaadin.frontend.url.dev=context://mySuperDir the application will fail to locate gridConnector.js in development mode.
  • if we reference the connector as @HtmlImport("context://frontend/gridConnector.js"), the production mode will fail, since there will be no frontend directory after flow-maven-plugin processes the files.

We need to come up with the idea how to fix this.

breaking change bug needs design

All 4 comments

What's the purpose of allowing the user to change the development-time setting if it will inevitably lead to things not working?

https://github.com/vaadin/flow/pull/2554

To keep the URL structure consistent between development and production,
a configurable frontend prefix is used in all cases. This also helps
simplify the maven setup since there's not need to serve any files from
special locations.

That was the original intention.
We can remove it, sure, just need to double check bakery guys at least, since they are using the feature to have their sources in the src/main/webapp/ directory.
From the quick look at the project setup, it looks like there should be no issues with moving it to src/main/webapp/frontend

I believe it would be most appropriate to just remove the setting since it causes more problems than it helps solve.

Was this page helpful?
0 / 5 - 0 ratings