Project_One.xojo_project: The main project file, containing the references to all included project items, which are stored as individual files.Build Automation.xojo_code: we’ll come back to that later.In a VCS you can ignore the files «*.xojo_uistate» safely. Project_One.xojo_uistate: That’s the state configuration of the IDE when this project has been saved.Then let’s save this project as a «Xojo Project» (*.xojo_project) to the «MonoRepo folder»: Move all project items (App, Window1, MainMenuBar) in this folder.Name the folder according to the project, but in a way that is best represented on disk as a folder: «project_one».Once I have created a new Project named «Project One» the first thing to be done in the Xojo IDE is: In a real world situation you’d sooner or later make a Repository out of this folder in the Version Control System of your choice. Setup a New MonoRepoĪll we’re doing is creating a folder: «xojo-projects-monorepo». In this example we’re going to create two projects that share a Class and a Module. Let’s see how we can set up a MonoRepo using Xojo. To me that’s much more convenient and efficient than Remote Debugging. Commit/Push the changes, switch to a Mac and check-out/pull the current branch you’re working on in order to do some platform specific tests. Check out the Version Control Repository on your Windows working machine and start coding. So you cannot only move the MonoRepo folder to any location on your machine, but also to other machines – running the same or a different Operating System. Everything is contained in a single repository/folder, all files are located relatively. I like the MonoRepo setup because of Xojo’s support for cross-platform development. Depending on the software being developed, this can be a significant amount of “not needed” storage space. Storage: A developer needs to check out the whole MonoRepo, even if one is working just on a single project included in the MonoRepo. ![]() A MonoRepo however allows read access to all software in the repository. Access Control: With split repositories for each project, access to a project can be granted based upon need.Shared code can be improved by all developers with the others (or other projects) benefitting, too. Collaboration: Several developers can work on different projects.So no need to know which project in which version or state has been used in version X. This will include the state of all dependent projects needed for that release. Once the projects are ready for an update, you can tag the current state. Atomic Commits: When several projects work together, releases need to sync which versions work with each other.Reuse Code: Functionality can be abstracted into shared Modules or Classes, and be included in multiple projects without the need of a package management system.What it means: it’s a software development strategy where code for multiple projects is stored in the same repository (and therefore in the same main folder). The name consists of two parts: «Mono» (meaning: single) and «Repo» (short for: Repository). So let’s see how this can be done with MonoRepo. Business Logic Classes can be used in console, desktop and web applications – again, there’s the need to share code. And I want multiple projects that share code such as Modules with Extension Methods and various helper Methods I’ve written over the years. I’d definitely want to use the Xojo Text project format. On the right: «Xojo Text project format» (*.xojo_project). ![]() On the left: «Xojo XML project format» (*.xojo_xml_project).Which one would you prefer to read when looking at changes, diffs, conflicts? It is readable in plain text, but not as clean and easy compared to Xojo’s Text format. However, many don’t quite like the XML project format. With a Version Control System such as SVN or Git one should obviously go for XML. The downside is that after making a fix in a shared code item, it needs to be copied and pasted again and again to all projects that are using it.Įxport/Import Items as well as External Items allows to save project items such as Modules or Classes in Binary or XML Format. The Xojo Documentation «Sharing Code» explains three different ways: Copy & Paste between projects, Export/Import Items and as a last option there are External Items.Ĭopy & Paste is the simplest way. That’s not as simple as one might think with Xojo. Other IDE’s have a concept of a solution or workspace consisting of several projects, and you can leverage packages in order to share code between projects. ![]() Are you working on a solution consisting of several projects? Are you working in a team or as a single developer and want to share code between different projects? If so, then a MonoRepo could be something to think about.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |