I'm trying to set up scalajs project using sbt, and since I will be including a "shared" module that will be used by both the jvm side of the project (server) and the js side (web client), I plan to use sbt-scalajs-crossproject. The problem is that I would like to separate part of the js code from the rest to publish as a library (all of the reusable js components). This would require splitting the js part of the project into multiple subprojects. Is this possible?
The best solution I have found is to put the reusable components in a separate scalajs subproject which is published as a distinct module. The rest of the code then goes into a cross-project which depends on the scalajs components project.
Related
In Maven multi-module project with Vaadin Flow 14 how can I build a common/shared style/theme module and reuse/import in the web application module.
Which one I should use in the web application. The #StyleSheet which can handle external CSS, or the newer #CssImport? Or do I have to use some maven plugin to copy reosurces (CSS files) from the theme module into the web app module (into the frontend or resources folder)? Is there any examples out there for vaadin 14 multi-module theming?
Any hint would be great, thanks!
There are possibly many ways to do this. I would assume the simplest way is to have component sub-module in your project. I have example here
https://github.com/TatuLund/bookstore-flow-ee/blob/master/bookstore-starter-flow-my-component/src/main/java/com/vaadin/samples/HelloWorld.java
The component itself can include styles, etc.
What I am proposing to you is to use similar custom component as base-layout of your application that imports the needed styles etc.
We are planning to build an application which has multiple modules
(say [Common which contains Admin, Registration], License Module,
Stock Module ). We have planned to use Maven as our build tool
Each module acts like a separate folder(war) where in it has MVC layers in it. Main POM should encapsulate all the modules and form a war file.
If a customer doesn't need License Module, i can just unplug the settings and recreate a war file without much effort.
Now i am struggling to find proper example to build a hierarchy(project structure like above)
Could you please guide me on this ?
You can create a parent project then add the child projects as modules. You can easily comment or delete these modules before building the project.
Here is a basic example.
http://www.concretepage.com/build-tools/maven/parent-pom-child-pom-example
You can get a good idea about parent child maven projects from the following thread as well.
Maven: adding a reference to a parent pom project
I would like to create a Meteor project which will be over the web for PC and mobile platforms.
The HTML files will be different for each project however the JavaScript logic should be the same.
Is it possible to create 2 Meteor projects (one for web and other for mobile) with shared JS files?
Maybe using another project?
Sharing and reusing code is the very first reason for the existence of Meteor packages.
To create one simply meteor create --package me:mypackage (assuming me is your Meteor developer account username).
You can add your logic in the package. You can do anything you would normally do in your application development (templates, publications/subscriptions, collections, CSS, ...).
You can then simply publish this package to Atmosphere and reuse it in other projects.
meteor publish --create me:mypackage
There is a lot to know about packages. See more about publishing, testing packages with Jasmine.
I need some utility classes that will be common for three different Liferay portlets so I will develop them in one project that should be shared for my portlets.
I am using Eclipse with Liferay IDE plugin and my question is what kind of project is that one that I need?
I mean is it a simple Java project or any kind of Liferay project?
There are ways you can do this:
Create a simple Java project. Package it as a JAR file. Put the JAR file in global class-path In case of tomcat the global class-path would be ../tomcat-7.0.27/lib/ext/.
Create a simple Java project. Package it as a JAR file. Put the JAR file in the classpath of each and every portlet.
Create a Liferay plugin-portlet using service-builder, put the utility classes in the service package so that the utility classes go in the [name-of-your-project]-service.jar. And then in the portletswhich would need these classes specify the propertyrequired-deployment-contexts=[name-of-your-project]inliferay-plugin-package.properties` of each of the portlet.
Create a Liferay plugin-portlet using service-builder, put the utility classes in the service package so that the utility classes go in the [name-of-your-project]-service.jar and then put the [name-of-your-project]-service.jar in the global class-path and remove it from the WEB-INF/lib of your portlet project so that it does not conflict.
Conclusion
Use 1st-method if the code in utility classes does not depend in anyway on the Liferay API. But this would require a server restart everytime there is a change in the utility classes. Also the Utility classes could be used by Hooks since it is in the global classpath
Use 2nd-method if the code in utility classes does not depend in anyway on the Liferay API. This would not require server restart. But any change in the utility classes would require you to build & deploy all the plugin-portlets which use this jar.
3rd-method: This has the same limitations or features as the 2nd-method, just that you can use Liferay API & your custom service API in the utility classes.
4th-method: This has the same limitations or features as the 1st-method, just that you can use Liferay API & your custom service API in the utility classes.
So here I have listed pros & cons for you to decide for yourself. I would love to know if there are more ways (& much cleaner) to do this in liferay from experts.
I'm preparing to reorganize & refactory a Flash Builder application. The goals of the reorg are 1.) keep compile times for the part of the project I'm working on as fast as possible, 2.) keep the unrelated parts separate for code reuse. Goal #1 trumps goal #2 if there's a trade-off.
Currently, the app has assets in one project, core functionality AS3 in another project, and the MXML in a third project that links to the other two.
Would moving resources/code into swc libraries help compile time? What about compiling assets into an swf and embedding that into the main application? Any other techniques?
We had the same problem, application compile time was more than 1 minute.
Here is our solution:
There is a Core Library that contains class Core with static properties like: Core.resourceManager:IResourceManager, Core.stringManager:IStringManager, etc.
Main application project includes Core Library and provides implementation for all Core.someProp. This can be done via some hidden method like Core.setImpelentation().
There are unlimited number of Modules that use Core Library to contribute their display / logic to the application. Important:
Each Module is a separate Flash Builder project
Module link Core Library as external (it's included in Main App)
Module has XML-file that describes it, example it's name and icon in application control bar. It allows not to load all modules at start.
User should be able to choose which modules he would like to use. This will also help you in development.
You can optionally create Lib Library and include in it all classes that are common between modules and can be implemented using Core Library.
The result is incredible - you application becomes low-coupled, open/compile time decreases, APIs become more clear. Profit!
Modules are definitely the way to go here, as Maxim has described. Further to his advice, which is all solid, here's some other tips:
Extract styles out to a separate project, and compile the .css to a SWF. Load the SWF at runtime.
Structure your packages by business function first, MVC role second,
Eg: Rather than com.myapp.model.userconfig.UserOptions, use com.myapp.userconfig.model.UserOptions. Enforce that packages can only reference their siblings, or com.myapp.core.*.
This way, each package is a self contained module, which only references itself, or the core library.
Consider the Hellfire Compiler, which can farm your compilation over several CPU's in parallel
If not already, consider moving to the Flex 4 SDK, which has several compiler performance improvements, especially around compiling multiple SWC's.