I use a long time EA for modelling. But i never found a suitable solution for following problem.
We develop products for customers in a very hierarchical way. Shared components (HW/SW/processes/...) are very similar.
We would like to have for each Application (Customer Project) a dedicated Project in EA. But this will use Elements of a Internal Library (Sub-Project), which is shared and should be aligned to all Projects.
Projectvariants:
Project 1 / Customer A
Project 2 / Customer A
Project 3 / Customer B
Project 4 / Customer B
Project 5 / Customer C
possible solutions:
one big project
each project with shared sub-project / library
each project with fake elements (manual deferencing LIB_HW_USB_HOST_2.3 )
one big project:
One Solution could be, doing all projects in one project file. This will be huge, because each customer and each project of a customer would be inside. But simple. All is in one. But everybody sees everything. Complicated Security model.
each project with shared sub projects:
Project Structure
The other way would be, make simple clear customer project based models, which will reference to the (sub-Project / library) and use these common elements from there, to illustrate some more detailed views. If using elements from the lib just drag and drop and get the detailed information, which are already written.
Fake elements
Third solution could be to create Fake-Elements LIB_HW_USB_HOST_2.3, but you have to look "manually" in the (Sub-Project / Library Project), and the direct linked infos (description, version,type) would be broken. Also clean simple models, which are showing only the necessary.
I would prefer the second solution, because the model is smaller. But i have no concrete idea how to solve this.
Related
We have a family of Java-based products which use common modules. Typically, I just work on a single product at a time, and load all of the necessary modules into a project for that product. This works nicely when I want to have IntelliJ help me with all of the interrelationships within the source code used by a particular product. This is useful both for static analysis and debugging.
However, if I choose to work on multiple products simultaneously, and I have the same modules loaded in those project, I notice that IntelliJ seems to spend a lot of time re-indexing. For example, if I modify the code in commonModule1, both Project1 and Project2 need to update their indices.
How can I organize my projects to limit re-indexing, while still allowing me to easily debug the common source?
I'm in the process of introducing FAKE as a build tool.
ProjectScaffold looks like a great start in addition to the FAKE help.
However in my case, listing relevant csproj/fsproj files cannot easily be achieved with !! "src/**/*.??proj" as used in the "AssemblyInfo" target for instance. The reason being that my repo contains code for different products + common code, not properly laid out under dedicated directories.
My plan is to start from the product's entry assembly and navigate recursively its projects dependencies to yield the full list of projects involved in the given product's build.
I believe MSBuild should be able to help with this. Obviously, I want to avoid building everything twice: once to get the list of projects before altering their assembly info and then the actual build.
Or maybe there are helpers in FAKE that could help with this task?
Any other advice when it comes to handling different product builds living under the same repo is welcome. Note that breaking down this repo into smaller repos (one per product) might be considered in the future, but not at the moment.
Greetings Stackoverflow Community,
I have taken on the task of 'unifying' 4 mobile iPhone apps that share 95% of the code and differ only in 5% (this is somewhat of an over-simplification, but never mind). Each of the apps has its own hefty set of resources (media files).
After 'unifying' the 4 apps, I will be adding new functionality to the apps, mostly functionality that the apps will share.
I would appreciate hearing your opinions on what's the best way to manage the code of these apps. Here is the approach I'm taking at the moment.
I'm maintaining only one Xcode project which includes the functionality of all 4 apps. The functionality that is not shared among all apps is enclosed in a condition such as: if (appName == 'X')...
Each app has its own info.plist file, so I have 4 of such files: infoX.plist, infoY.plist, ...
Before I build an app, two things are done:
a. in the Build Settings, I specify the name of info.plist to use.
b. I ensure that only the app's resources (media files) are in the project. I delete the other apps' resources.
As the apps are 95% similar in their code, having only "One App to Rule Them All" ensures that when the code gets upgraded, all apps enjoy the upgrade. You can assume that the apps will remain very similar in their code.
As the apps' media files are large and many, I'm keeping them off the Git repository.
How does this all sound?
Many thanks!
There are better ways:
A. Move to framework
It depends on how generic are common parts of the apps. But you should think about putting parts of it in a separate project that is a framework. You can link your 4 apps against that framework. But, of course, not everything will go there.
B. Have different targets
For sure you should have 4 different targets. Xcode let you set build settings for each setting commonly per project or specially per target. Additionally you can customize the build phases (including copy of the media files) on a per target base. So you do not have to rename or delete and insert anything. You simply select a target, you want to build.
C. Project tree
Xcode allows you to have subprojects with common code. Maybe things like common "foundation" classes of your app. You can have different projects for each app in a single workspace, all using the subproject.
Probably the best way is a combination, depending on what is the subject. However I would start with B. and likely add the other techniques, if needed.
I encountered more or less the same case, and we decided to use one Xcode project with multiple targets. That way you can simply change the target before hitting the build button (or configure specific build scripts changing the target). In our project, we had a few files sharing the same names (in different folders), and associated each one with a different target. For example, we had three "Stylesheet.h/.m" with different UIColor & UIFont definitions stored in different folders, and each one of them was linked to a different target. Same thing for the "Localizable.strings".
I have a BIG project in IDEA (basically the trunk of my company source code), but I need to work only on one of the "modules" (not sure how to call those). Is there a way I could export/create from/in IDEA a smaller project with the part of trunk I'm interested in? It's pretty self-contained, there should be dependencies only on 1 or 2 other projects in trunk.
There is no automatic option to extract a part of a project. You should create a new project from the existing sources, it will contain only required modules with content roots set to the parts of the bigger project and dependencies configured between them.
We're planning to launch a serie of applications in AppStore. They will be for some kind of different journals, showing different contents downloaded from a server via XML. So these applications will be made from exactly the same code (It's an universal application, so It'll work both in iPhone/iPad).
My initial idea was, in order to upload the application, compile just changing the images, logos and configurations (plist) that makes the application react as a particular journal. The compressed file would be uploaded to the AppStore.
However, this has resulted a horrible method, which promotes failures and mistakes. If I forget to change some image, as you can't see them in the compiled file (as it is included) they will end up in the store (and I will need four or five days in order to get the application changed).
I'm trying to look up for a better approach, wich keep the projects as independent as possible. I would like to be able to share the entire codebase: views, classes and nibs and create different projects for every journal.
Which is the best method to achieve that?. What structure would let me group both logic (controllers, classes) and UI and use it in the different projects?.
I hope I've explained.
As always, thank you very much.
You should keep most of your common code as a library project. Each final project should link with this project and provide images/assets along with code to mention these assets to common code. In my day job, I write a common library too, which gets used by 2 products/apps at my employer.
An Xcode project can have multiple Targets, all the Targets sharing code, but each Target getting its own resources (icons, images, text, plists, etc.) from a different subdirectory/folder within the same project directory/folder. Then you can check the whole thing, or just the shared source, into your source control repository.
You should also be testing each of your apps, built exactly the same way as any submission except for the codesigning, on a device before uploading to the store.
You can have a single Xcode project that creates multiple applications. You'll need to create a separate Info.plist with a different bundle identifier for each app.
If you are using a git repository you can just branch for each different app you want and that would keep track of all the differences and if you need to switch which you are working on you just have to checkout that branch. This would allow for the exact same structure just minor differences between the actual code for each.