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.
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.
I'm trying to create a Spring Boot project with multiple Maven modules. I've used the tutorial at https://spring.io/guides/gs/multi-module/ .
This site recommends a directory tree like this:
parent
application
src, and other subdirectories
pom.xml
library
src, and other subdirectories
pom.xml
pom.xml
I developed this project using Visual Source Code.
Wanting to see the project in another light, I tried to import the project directories into Spring Tool Suite. I'm using a recent one, where you apply the STS plugin to an up-to-date Eclipse installation.
Well, STS doesn't really like this project.
The (File, Open projects from file system) sees the project, but the Finish button doesn't actually do anything.
The (File, Import, General, Existing Projects into Workspace) imports a project, but as a Maven project (no "J" icon). When I try the (Run, Run Configurations) it won't see my project.
How can such a project be made friendly to Spring Tool Suite?
Thanks,
Jerome.
To make multi maven projects what you can do is, simply download two separate maven projects from start.spring.io and then extract them and move both folders to one parent folder and try grabbing the parent folder to Intellij, so it automatically downloads the dependencies and other requirement for the project in which we have two maven projects in one single entity
Eclipse can be a bit confusing with several different Wizards to import projects. Ironically the wizards are supposed to make importing projects easy, and in a sense they do... but... unfortunately picking the right wizard itself can be a bit challenging / confusing. Which wizard you use depends on the type of project.
Since your projects are maven projects, the best wizard to use would be the one for maven projects. You can find it at "File >> Import >> Existing Maven Projects".
So give that a try, point it at the 'parent' folder of your project and you should be presented with a relatively intuitive UI to import all 3 projects and configure them for use in Eclipse.
I'm not a Go expert, so I may be doing this in a way that is not the ideal approach for Go. Essentially, I have a main application that needs to be able to have plugins written for it. The plugins all adhere to a given format and are built with go build -buildmode=plugin. I don't want the end user to need to recompile the main application every time. Ideally, you should be able to drag and drop it to a new computer without issue.
To pass information between the plugins and the application, I have a third package defined called "common" that I treat similar to a C-header file. It only defines interfaces and a few integer constants that both can use. The application generates types that adhere to the interface and can pass them to the plugins to use.
When I compile, it seems to work fine, and the application can load the plugins using plugin.Open. The catch comes when trying to move the location of the common package. I built the original application in a local directory and I have a script that installs the application and the copies the common package into the GOPATH so that it can be found. Now, when I try to create plugins and compile them referencing the global copy of the common package, I can't load them in the main application because it sees the two occurrences of the package as being different versions.
My understanding is that to determine package version, a hash is made of all the Go files in the package at compile time. Is this hash including the location on the server where the package was found as well?
I know for a fact that the actual versions of the packages are identical. The only different is that I did cp -r src/myapp /usr/local/go/src. Is there a better way to accomplish this than my approach that still allows the user to move the main application around to different machines and not need to recompile it?
Further explanation:
Here is my directory structure
./
|-- main.go
|-- src/myapp/common
| |-- Common.go
|-- install.sh
Once I compile this into myapp, I copy src/myapp/common into the GOPATH and then build plugins with go build -buildmode=plugin against that package. When loading those plugins from myapp, it sees the two versions of myapp/common as being different, although the only difference is location on the server.
Have you tried instead keeping the path of the common package stable? You should probably have that in its own repo (so that both projects can refer to it), or keep it in your app repo, but allow plugins to link to it there.
So for example say your project lives at:
github.com/brianwest/myapp
you could make the import path (for both app and plugins):
github.com/brianwest/myapp/src/common
OR
github.com/brianwest/common
and keep it stable across the app and plugins, then it should just work and you won't need the script to copy it into gopath, or if you do it can put it at src/github.com/brianwest/common and use that path in both plugins and your app.
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/
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.