integrate oasp4js with oasp4j

[hohwille]

We need to integrate oasp4js into oasp4j and for the sample client as well as for the archetype template (or offer two variants).

• define the location where the client shall be located within the maven structure of an oasp4j project (e.g. in oasp4j-sample-server/src/main/client).
• add the oasp4js repo as git module at this location
• rework the build process to build the client as part of the overall build (without profile or profile only to disable client)
• add a template/archetype including a oasp4js client stub
• improve cobigen to be able to generate client stuff for CRUD functionality

[henning-cg]

Regarding the location of the client, in many projects we have 2 distinct clients, one optimized for mobile devices, and another client for a desktop-like experience, or in the future, having 2 clients, one Angular and another done in ExtJS

I fear that simply defining a single directory for the JS-client could be quite limiting. Maybe we should explore other possibilities of defining the location of a series of clients.

Do I understand correctly that the goal of this integration is to be able to use cobigen to generate client-artifacts, too?

[hohwille]

good point we should consider this and give it a more specific path/folder.

[nelooo]

Maybe we should use a "standarized" way to organize the client. I know 2 base package in maven projects:
1- Based on standar way of Web Applications -> src/main/webapp path (Default path for maven-grunt-plugin).
2- An alternative way, in maven, defined by the maven-javascript-plugin, using the path -> src/main/js for javascript files and the html files in src/main/resources. This plugin offer archetipes, testing tools, minification, javascript dependency management, an embedded jetty for deploying and define the javascript resources in the path. More info

Based on this alternatives, I think the best way is to create a specific project/module for each client side application (mobile and/or desktop) and use the default path for Web Applications (src/main/webapp) to easy integrate with web servers in the IDE.

@hohwille is this way aligned with you? Do you have another thing in mind?

If this is all right for you, maybe I can solve this issue.

[hohwille]

Thanks for your suggestions, however my concerns:

1. src/main/webapp is for a Java Webapp (WAR). We are talking about something else here so not suitable.
2. src/main/js is for JavaScript only. We are talking about an entire client application that itself has a complete structure of subfolders such as js, css, etc.

[hohwille]

I was thinking about further separation instead of just src/main/client but

• separation by technology does not make real sense. You will not create two web-clients in parallel with different technology (e.g. sencha and angular). This would be so exotic edge case that does not have to be considered in a standard such as OASP.
• separation by channel also does not make that much sense. If you create a mobile client you will deploy that totally independently and in a different artifact type. Therefore it has to be a separate maven project/modules. And I am not talking only about native mobile clients such as android. This also applies for hybrid mobile clients e.g. based on ionic.

So still my suggestion is to use one folder. If you prefer src/main/web-client over src/main/client then I would not care. But having additional folders such as src/main/mobile-client or src/main/sencha-client does not make any sense.

[nelooo]

Ok, knowing your concerns and your points of view, I will work to solve them.

[amarinso]

since we haven't found something better than current use of the -Pjsclient profile with maven, should we close this issue or do you think it still valid to develop on the idea of having server and client on the same project?

If we propose not to use eclipse for javascript development maybe it is easier to just use the reverse proxy or CORS support for development of the client.

[hohwille]

Independent of the IDE discussion we need a standard layout as otherwise we can not do code-generation from java to JS/TS properly. Also I want to have an additional archetype that instantiates server+client in one goal and simplifies the process (there can also be the same for other clients than oasp4js if you know what I am talking about). So I would still keep this open. We are just in the process of full-stack generations but currently struggle with new challenges such as JS/TS code merging. However, if there is no other proposal we can simply stick to my above suggestion.
Then we can simply add oasp4js as git submodule in this location. Further we can then remove the stupid maven profile jsclient and have this as default included. Still other approaches can reuse oasp4j-sample-core and define their own build logic for client integration.
I think I should simply go for that change...

[amarinso]

Maybe I misunderstood your implications of using git sub-modules. It can be fine with OASP but since not everyone uses git we should explore other ways.

For example you can have a junction within your webapp directory in order to link the client files within the server project.

[hohwille]

Maybe I misunderstood your implications of using git sub-modules. It can be fine with OASP but since not everyone uses git we should explore other ways.

Seems so. In OASP we have two separate repos oasp4j and oasp4js. If we want to have a sample that you just checkout and that works with client+server OOTB git submodules are our solution for this problem in OASP.
In a real live project you will have one repo per application that contains client+server code. There is no coupling to git (works also with SVN, HG, Bazar, CVS, etc.). You can then have your code directly in src/main/client.

[amarinso]

Ok I get that, but how do you plan to have an archetype that mixes on a generic way the server+client code?

Do you propose an archetype for every combination of server+client type ?

[hohwille]

I have committed this as a feature branch. Can someone have a look? You need to clone with --recursive if that is not your default.

[hohwille]

Worked for me like a charm both on command-line (mvn) as well as in IDE (Eclipse).

[amarinso]

how exactly do you clone?

I've done

git clone --recursive http://github.com/oasp/oasp4j
git checkout feature-214

but see nothing on the server/src/main/client folder

I had to do:

git submodule update --init --recursive

in order to retrieve the code for the client

then, issuing

mvn clean install

fails trying to execute npm. Maybe is because linux installation. I will check on other computer with windows and report back.

[amarinso]

Installation went OK on windows.

But couldn't clone recursive as stated above.

[henning-cg]

Will we propose this solution as the recommended approach for projects?

If so, I am not too convinced by it. Git submodules would tie projects to using git, and add a layer of complexity (having to remember to update the submodule in the server project, for example).

I have the feeling that we are searching for a solution due to the split of the repo into the client and server parts (oasp4js and oasp4j), but I do not think that this would be a problem in the majority of real engagements.

In engagements, I think we would have 2 situations:

1. The engagement sees server and client as one. They will have 1 repository, and the easiest way to integrate the client would be to just add it as a maven module of the parent POM.

2. The engagement sees server and client as separate projects, and deploys them separately. They will have 2 repositories, just as we have, and do not need any dependencies between client and server

[hohwille]

Currently hoplessly out of time but the submodule is broken after the refactoring (#363)
Someone might be able to fix this quickly:
https://github.com/oasp-forge/oasp4j-spring-boot/blob/develop/.gitmodules

[hohwille]

Why was this closed? Current state is even that the build of client+server is most likely broken.

[hohwille]

We should also evaluate one of these:
https://github.com/eirslett/frontend-maven-plugin
http://wcm.io/tooling/maven/plugins/nodejs-maven-plugin/usage.html

Then our build would be entirely portable and not rely on oasp4j-ide (what will not be present in travis or jenkins)

[mmatczak]

There is an unnecessary call of tsd install in the server's pom.xml. We don't have TypeScript in place.

[hohwille]

The sample app is pretty much dead. MTS is going for an isolated and separated build.
I have created #619 as a replacement and close this issue as duplicate.