Using Play!Framework 2.2 subprojects - playframework-2.2

I'm trying to split my Play!Framework 2.2 project in subprojects and I have some hard time figuring it out.
Here's my folder structure :
MyProject/
| - app/
| --- controllers/ # containing some main controllers
| --- views/ # resulting views
| - build.sbt # see after
| - conf/
| --- application.conf
| --- routes
| --- modules/ # My modules folder, aka sub projects
| -------- common/
| ------------ app/
| --------------- models/ # The models
| --------------- utils/
| -------- api/
| -------- web/
| ------------ app/ # some controllers/views
| ------------ conf/ # routes mainly
| ------------ app/ # some controllers/views
| ------------ conf/ # routes mainly
(I simplified it).
The main routes file :
# Routes
# This file defines all application routes (Higher priority routes first)
# ~~~~
# Home page
GET / controllers.StaticPages.index()
# Web
-> /html/v1 web.Routes
# API
-> /api/v1 api.Routes
web.routes :
# HTML Engine renderer
# ~~~~~~~~~~~~~~~~~~~~
GET /users controllers.Users.list()
api.routes :
# API
# ~~~~~~~~~~~~~~~~~~~~
GET /users controllers.Users.list()
And finally, my build.sbt
import play.Project._
name := "My project"
version := "1.0-alpha"
libraryDependencies ++= Seq(
javaJdbc,
javaEbean,
cache,
"mysql" % "mysql-connector-java" % "5.1.25",
"com.typesafe" %% "play-plugins-mailer" % "2.2.0"
)
play.Project.playJavaSettings
lazy val root = project.in(file("."))
.dependsOn(common, web, api)
.aggregate(common, web, api)
lazy val web = project.in(file("modules/web"))
.dependsOn(common)
lazy val api = project.in(file("modules/api"))
.dependsOn(common)
lazy val common = project.in(file("modules/common"))
When cleaning/compiling and running, I face this error :
not found: value web
In /path/to/project/conf/routes at line 20.
-> /html/v1 web.Routes
If I remove the -> in the main routes file, Play! cannot find the package utils in common.
So I guess common, web and api aren't loaded, but why?
Update
Since #James-roper helped me found the problem, I created a Github repository that shows a simple Play!Framework 2.2 project with sub projects. You can find it here : https://github.com/cnicodeme/play2.2-subproject

Your sub projects need to use different package names, at the moment they are conflicting.

Related

How to use terraform to ignore previous execution(state) [duplicate]

I'm a bit of a newbie with Terraform and still working my way through the documentation, have not yet been able to find a way to accomodate the set up I need to achieve for a specific solution and hoping that some kind soul may be able to give me a push in the right direction.
I'm trying to manage a single set of paramaterised templates which deploy everything needed to support a new application we are working on in GCP. What I am trying to achieve is being able to deploy those templates to three different environments, each environment being in a distinct GCP project, by itself.
The plan is, as per recommendations, run terraform and pass in
a) The specific .tfvars file depending on the environment/project being deployed to (dev/test/prod).
b) Use the -chdir parameter to tell Terraform to pick up all the templates from 'infra-common' folder.
The tricky part is that we want each environment (gcp project) to host it's own state file in gcs/storage.
I had been looking at workspaces but it appears that workspaces will just create state subfolders on a single backend.
Question: Can this be done or is there a better way to do it?
Thanks!
You can use --backend-config for this. Here's how you can achieve the desired behavior:
Create a .config file for each environment (dev.config, test.config, prod.config) which contain the name of the gcs bucket (which must already exist) for the respective environment
Specify the common backend in a single remote_state.tf file
Here's how it would look:
config/dev.config:
bucket = "tf-state-dev"
config/test.config:
bucket = "tf-state-test"
config/prod.config:
bucket = "tf-state-prod"
remote_state.tf:
terraform {
backend "gcs" {
prefix = "terraform/state"
}
}
then, you can run the init. So for example, for dev this would look like:
$ terraform init --backend-config=config/dev.config
then, you can create a workspace for the environment:
$ terraform workspace new dev
With this approach, you can use a single set of templates (you can in fact configure dynamic variables based on the current workspace).
What you could do (we have a project with a similar setup with a different cloud provider), is:
use infra-common as a module
instead of working with .tfvar files per environment, use a separate root module per environment which invokes infra-common as sub-module.
Your folder structure could look like:
project
|-- dev
| `-- main.tf
|-- modules
| `-- infra-common
| |-- main.tf
| `-- variables.tf
|-- test
| `-- main.tf
`-- prod
`-- main.tf
dev/main.tf
terraform {
backend "gcs" {
bucket = "tf-state-dev"
prefix = "terraform/state"
}
}
module "stage" {
source = "../modules/infra-common"
env = "dev"
some_var = "value"
}
prod/main.tf
terraform {
backend "gcs" {
bucket = "tf-state-prod"
prefix = "terraform/state"
}
}
module "stage" {
source = "../modules/infra-common"
env = "prod"
some_var = "value"
}

Docusaurus error during building the project

First of all let me say that I'm new of Docusaurus and I'm using version 2.
I was building my documentation project and I have got the following error:
Docusaurus Node/SSR could not render static page with path=/docs/My_MDX_Page because of error: useBaseUrl is not defined
I'm using a MDX page to get the baseURL to retrieve static contents.
The MDX page:
---
title: title
hide_title: true
sidebar_label: item
---
import useBaseUrl from '#docusaurus/useBaseUrl';
## Section
| Name | image |
| :--- | :--- |
| YL_GN3 | <img src={useBaseUrl('img/YL_GN3.png')} /> |
I think I'm doing something wrong even if executing without building it works (by npm start).
npm install was executed.
Here is the directory structure of project:
+ .docusaurus
+ build
+ docs
+ node_modules
+ src
+ static
+ versioned_docs
+ versioned_sidebars
babel.config.js
docusaurus.config.js
package-lock.json
package.json
README.md
sidebars.js
versions.json
UPDATE
For reasons that I don't know, it has started working. I have changed docusaurs config, adding the baseUrl different from '/' and 'index.js' in order to have the docs as landing page

Using Vue CLI 3 on XAMPP

A little background..
As mentioned before in https://forum.vuejs.org/t/how-to-make-webpack-vue-work-on-xampp/33808. And it works when I put my Vue project directly in htdocs like this.
htdocs/
| - css/
| - js/
| etc..
However I'm using it differently, here's my current file structure in the htdocs.
htdocs/
| - project1/
| | - css/
| | - some other stuff for project1
| - project2/
| | - css/
| | - some other stuff for project2
| - vue-project/ (Where I wanted my Vue went to)
| | - css/
| | - stuff..
The error I get when I put dist/ of my vue project directly to htdocs/vue-project is 404, because they directly went back to the root file (root is htdocs/), in which it doesn't find the required file to launch Vue Project!
What I wanted
Anything that can launch the project in htdocs/vue-project/. Would accept any answer configuring either settings in the Vue/Webpack OR from XAMPP itself. If you need additional information please do ask in the comment section.
And if it turns out there are no other way, then I would accept answers involving XAMPP configuration on how to start a server in a different directories. Like start a server in htdocs, and other-file would be great as well.
For Vue CLI before 3.x
Try changing assetsPublicPath under build object in config/index.js. Then append your folder name there. Similiar issue that might help https://forum.vuejs.org/t/vue-js-webpack-deployment-for-xaamp-testing/28970
And if vue-router used then add ROUTER_BASE.
https://router.vuejs.org/en/api/options.html#base
For Vue CLI 3
Create vue.config.js inside your vue-projects
Inside it simply add the following
module.exports = {
publicPath: "/{path-to-your-vue-project}"
}
For more information please refer to this docs https://cli.vuejs.org/config/#publicpath

Yocto + Autotools library + CMake application = linker error

I have a Yocto BSP with my own layer that includes an autotools 3rdy part library (libcoap).
My application ".bb" file has the following lines, telling libcoap is needed:
DEPENDS += "libcoap"
RDEPENDDS_${PN} += " libcoap libcoap-dev libcoap-devstatic"
I can see the library files are being copied to sysroot:
$ ls -l /projects/oe-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/coap-playground/1.0-r0/recipe-sysroot/usr/lib/libcoap*
-rw-r--r-- 2 udev udev 286430 Ago 21 13:53 /projects/oe-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/coap-playground/1.0-r0/recipe-sysroot/usr/lib/libcoap.a
lrwxrwxrwx 1 udev udev 173 Ago 29 14:33 /projects/oe-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/coap-playground/1.0-r0/recipe-sysroot/usr/lib/libcoap.so -> ../../projects/oe-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/libcoap/4.1.2+gitAUTOINC+d48ab449fd-r0/image/usr/lib/libcoap.so.4.1.2
-rwxr-xr-x 2 udev udev 38444 Ago 21 13:53 /projects/oe-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/coap-playground/1.0-r0/recipe-sysroot/usr/lib/libcoap.so.4.1.2
It is not hard to noticed that the symlink is kind of weird:
/projects/oe-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/coap-playground/1.0-r0/recipe-sysroot/usr/lib/libcoap.so -> ../../projects/oe-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/libcoap/4.1.2+gitAUTOINC+d48ab449fd-r0/image/usr/lib/libcoap.so.4.1.2
My libcoap.bb contains inherit relative_symlinks (otherwise an absolute link to "/projects" is created and bitbake fails) but the symlink created simply prepends "../../" to the original link.
So... the questions are:
Why do I need inherit relative_symlinks? Shouldn't make install create a symlink relative to sysroot out of the box?
Generated Makefile contains:
librootdir = $(DESTDIR)$(prefix)/lib
# ...
ln -s $(librootdir)/$(LIBSO).4.1.2 $(librootdir)/$(LIBSO)
And I thought $(DESTDIR) would already point to the correct place during bitbake's installation...
What is the right way to fix it? Could it be something wrong at the other side (the application trying to link against libcoap)?
Thanks in advance.
Resources
libcoap.bb is based on Internet and quite simple:
SUMMARY = "A C implementation of IETF Constrained Application Protocol (RFC 7252)"
DESCRIPTION = "Libcoap provides an implementation of the IETF CoAP protocol"
HOMEPAGE = "http://sourceforge.net/projects/libcoap/"
SECTION = "libs/network"
PROVIDES = "libcoap"
SRCREV = "d48ab449fd05801e574e4966023589ed7dac500b"
# Lookout for PV bump too when SRCREV is changed
PV = "4.1.2+git${SRCPV}"
LICENSE = "GPLv2 | BSD"
LIC_FILES_CHKSUM = "file://${S}/LICENSE.BSD;md5=1164f52f9c4db2c13f681b201010d518 \
file://${S}/LICENSE.GPL;md5=4641e94ec96f98fabc56ff9cc48be14b"
S = "${WORKDIR}/git"
SRC_URI = "git://git.code.sf.net/p/libcoap/code"
inherit autotools-brokensep relative_symlinks
EXTRA_OECONF += "--with-shared"
EXTRA_OEMAKE += "all"
INSANE_SKIP_${PN} = "ldflags"
BBCLASSEXTEND = "native nativesdk"

How to use pdfjs with aurelia-cli

Has anyone got pdfjs (https://github.com/mozilla/pdf.js) working with the Aurelia cli?
I'm getting nowhere fast with getting it up and running.
I followed the docs here (http://aurelia.io/docs/build-systems/aurelia-cli#adding-client-libraries-to-your-project) and guessed that main needed to be set to webpack, but the paths in that file seem to be interpreted incorrectly.
------- File not found or not accessible ------
| Location: /home/ubuntu/workspace/public/pdfjs-dist/build/pdf.js
| Requested by: /home/ubuntu/workspace/public/src/modules/admin/admin.js
| Is this a package? Make sure that it is configured in aurelia.json and that it is not a Node.js package
------- File not found or not accessible ------
| Location: /home/ubuntu/workspace/public/src/worker-loader.js
| Requested by: /home/ubuntu/workspace/public/src/modules/admin/admin.js
| Is this a package? Make sure that it is configured in aurelia.json and that it is not a Node.js package