I am wondering if there is a server side MVC framework, in any language which supports creating Sub-projects.
For example something like this:
-Root project
|-- Project A
|-- Project B
|-- Project C
|-Root project files (such as route list, config files and etc...)
Each Sub-project and the Root project have the same structure.
Note that this is just an example, any other structure is fine, as long as it is MVC and supports sub-projects.
You can use ASP.NET MVC. The AREA feature is pretty much what you are describing.
http://www.itorian.com/2013/10/area-in-mvc-5-with-example-step-by-step.html
https://mvcmusicstore.codeplex.com/
Related
I have 100s of microservices, we are trying to introduce the BOM in our project. 1 issue I can clearly see is, if I update the BOM, we need to make changes to all the microservices. Is there a better way to do this?
Example:
grandparent:1.0.0
`-- parent:1.0.0
|-- ms1:1.0.0
|--
`-- ms100:1.0.0
Now say if we make change to grandparent, we have to update that version in parent and then in all the microservices. Going and managing these many microservices is maintenance nightmate
The structure is making them coupled, shouldn't be focus on making independent, even build process.
I think first thing to resolve is to break this interdependency on build process.
If the structure is to just ease the build, there are multiple tools available to automate the build process, for example: jenkins. Jenkins would be simplest solution and popular among build tools.
We just started with a liferay extranet project. We want it to be as much mavenized as possible. So far I read how to get it working with Maven and have a working setup. But I have some questions regarding the folder structure:
Do I need an (unpacked) sdk at all?
How should the folder structure look like (in future there will be many portlets, themes, exts... plugins)?
at the moment my structure looks like this:
liferay-portal-6.1.20-ee-ga2 (liferay tomcat bundle)
|-deploy
|-tomcat-7.0.27
|...
project-folder
|-pom.xml (parent pom)
|-sample-portlet (created with archetype:generate)
Is this ok? or it is probably better to create subfolders for each plugin type? does this interfere with the archetype and the automated connection between parent-pom and modules?
Does the mavenization changes something with workflow of liferay developer studio? This will be the ide of choice.
To answer your questions
You don't need plugins-sdk at all!
I advice you to go for a multi module maven project, and I already see you using it.
Obviously when you go for a multi-module project you have the sub-folders created and each module corresponds to a separate archetype and of course, it depends on what type of project you create.
Here is the sample liferay-maven project structure I had.
There are a lot of folders in a Smart Template project in STS. My question is where to add what?
There are 4 folders under SRC
1. Main/java.
2. Main/resources.
3. Test/java.
4. Test/resources.
Should I add my controllers in all the above folders or in a few or or or..?
There is another folder called SRC!
Should I use the 'view' folder for adding all my web pages (say JSP pages)?
Can anyone please elaborate?
Also please let me know if using Dynamic Web Project is a better option than using Spring Template project or vice versa?
This folder structure is the structure of an maven project.
Java classes for your application should be in src/main/java for example src/main/java/com/example/web (com.example.web is the package)
The JSPs should be in src/main/webapp/WEB-INF/jsps (you can use an other subfolder then jsps but it must be below src/main/webapp/WEB-INF/)
Also please let me know if using Dynamic Web Project is a better option than using Spring Template project or vice versa?
If you know Maven then the Spring Template is better (in my opinion).
BTW It is important to have pom.xml in the project root.
I'm trying to build a project structure like this:
Project
|--Web_module.war
|--Data_module.jar(Spring)
|--Util_module.jar
|--other public api...
which means, different modules should be packed into different jars, so i have to have more spring configurations(application-context.xml) for different modules (e.g. for data module and for web module).
My question, how could I organize all the configuration files to include them correctly in the web module.
Thanks in advance.
Plan to have a single eclipse project for each jar file that you anticipate.
Choose the jars files / eclipse projects as per your project functionality to be modular and self contained, as far as possible.
Use junit tests in each eclipse project to thoroughly test individual projects/modules, using spring unit test support
Each eclipse project will contain its own spring config context file eg Util_module project might contain a util-context.xml
Finally have an eclipse dynamic web project as a wrapper web application which will aggregate all your "module" projects
UI artifacts like HTML, JS, JSPs, etc plus java code which uses web application contexts like controllers, servlet filters etc should be included in the eclipse web project
In the eclipse web project's java build path, but the module "projects" as "required" projects
In the eclipse web project's deployment assembly, add module "projects" as dependencies.
now when you build-all and deploy the web app, all depending module projects will compile and deploy as well, but more importantly, all project functionality will be divided into seperate modular projects
setup dependencies between projects with care, so as not to introduce cyclic dependencies
dont be afraid to refactor project structure when needed to maintain clean and relevant modules
For your modules to publish their own configuration (and your main application to detect them automatically), you can, in your main applicationContext.xml, import other context.xml files from the classpath using a pattern with wildcards :
<import resource="classpath*:conf/moduleContext.xml" />
This tells spring to find and read files in all jars that match conf/moduleContext.xml.
Note there is a little limitation to this : you must have your context files in at least one directory (not in the root of the classpath). This is why in my example you have de "conf" directory.
I don't understand the use of an Xcode workspace to organize projects with dependencies on one another. For instance I see a lot of developers create workspace structures that look like this:
Workspace
|-- App
|-- A Common Library
|-- Another Common Library
What benefit does this provide? If anyone opens the "App" project directly won't they be unable to actually build the app? They'd have to realize that a workspace exists with the necessary dependencies.
It seems to me like the better approach is to use nested projects like this:
App
|-- Libraries
| |-- A Common Library
| |-- Another Common Library
Then no project exists that cannot be built. It also seems more in line with Git's idea of submodules.
The only use I see for a workspace is to group common projects with no dependencies on one another. I'd like to hear other people's thoughts on this because I may be missing something.
I use workspaces when I want to combine projects while also maintaining project independence.
An example where I use workspaces is series of tutorial projects that progress from very simple to more complex. Each project can function as a standalone project, but grouping them together in a workspace helps my organization of the overall project.
In another instance I have an app developed for a client. The app works as both a standalone app and a module in the overall project. The independent project can build the standalone app. The other app uses a workspace that includes two projects. The module version of the app is built from a special scheme, and this combined app doesn't build without using the workspace.
One twist with the two above situations is where the build folder is stored. I have to change the Xcode preference to put the build products into unique folders for the group of tutorial projects, use a common build folder for the module within the other app setup.
In other circumstances I have plenty of projects with embedded projects. In these situations the library projects are stable. I don't attempt further development of the library projects so they are just another resource for the project. I find it easier to work where my file system organization of project resources somewhat reflects the organization of my Xcode project. So these library projects are copied into the main project's file hierarchy. It would make sense to use workspaces if I was developing the libraries and using them in multiple projects. For expedience I frequently don't bother.
Sometimes I even combine workspaces with projects containing embedded projects.
So my opinion is that both organizational tools, embedded projects and workspaces, have their merits and problems. I choose to use one or the other (or a combination) depending upon the particular circumstances.
We added nested projects into the Main project's Frameworks, so we could "include" them into the .framework product.
Main
|-- Main
|-- MainTests
|-- Frameworks
| |-- CommonLibrary.xcodeproj
| |-- AnotherCommonLibrary.xcodeproj
| |-- UIKit.framework
| |-- Foundation.framework
| |-- CoreFoundation.framework
|-- Products
See this Great Tutorial by Jeff Verkoeyen for adding Universal Frameworks to a project. It not easy, at first, but keep working on it and you'll get the hang of it.