I have switched to Mac as my main development machine (coming from Fedora) and was just curious as to what people used as there development folder structure. For example in Fedora I always had ~/opt for user programs ~/src for source code I was working on and ~/bin for files I constantly executed. Is there a Mac de facto. What do you guys perfer?
Thanks,
Greg
I use the directory ~/Developer as the root of my development-related files. Inside that I have ~/Developer/Code for code snippets, tutorial code, test ideas, etc. I have a ~/Developer/Projects directory to hold in-development projects. This contains a few subdirectories, including Archives for projects I've abandoned, and Current for current development work. ~/Projects is also a symlink to ~/Developer/Projects/Current.
To add to #mipadi, after a recent fresh install of OSX 10.10.2 (Yosemite) I noticed that if you create a ~/Developer folder, that folder automatically receives a special folder icon (with a hammer on it). This property seems to be an artifact of older versions of Xcode, in which it would automatically create the folder for you.
I have 3 folders in home:
Sandbox - my source control checkouts
Dev - projects that are not in source control (tests, experiments, etc.)
3rdPartyDev - 3rd party code I've downloaded and want to keep around
I try to keep as much 3rd party code around as possible. With the Mac's Spotlight feature, you can instantly search all the code at once. If there's an API I need to see example code for, I just Spotlight for it and chances are some code in there is already using it.
I have a big messy folder called "code" full of Xcode projects.
In Mac, for all developer projects there is a specific folder inside the home directory called ~/Developer, which when you create automatically has a customised icon.
You can thus subdivide using this:
Experiments: things you just want mess around with.
Public: open source
Private: private projects
Learning: If you're on a learning path to track your progress and milestones.
Related
I am not a Mac owner and am putting myself through a crash course to get up to speed (e.g., reading "Switching to the Mac"), to give you an indication of my current level of understanding. The access I have to a physical Mac is limited, so I am trying to connect as many dots as possible before my next session with my friend's computer.
I have: a file folder containing all resources needed for a self-contained application written with Java (OpenJDK 11, JavaFX 11). The JLINK tool was successfully used to create this file folder, and it holds all necessary Java libraries as well as the code I wrote for the application. The executable resides in a subfolder: /bin. The program runs perfectly well on the Mac when the executable is run.
I want: something that is easy to download, install and run.
I'm unclear about what needs to be done to get this. The road map seems to have two main steps:
the file folder needs to be converted into something that responds as if it were an application (e.g., a Bundle? or an .app?)
the resulting folder-as-executable can be shipped via either .dmg or .pkg
For the second part, I've researched and found tools such as Packages or create-dmg. It seems to me these tools are pretty straightforward and shouldn't be too difficult to learn to use. (Just have to pick one or the other or something similar.)
For the first part, I'm on shaky conceptual ground. I've found info about Bundles, but no tutorials, walk-throughs or examples. It looks like a key step is understanding how to make a proper Info.plist file, but doing this properly looks tricky. Also, I'm not clear on how the resulting Bundle will become an .app file or if it needs to, or if there is another, more direct way to make my file folder be viewed by the OS as an application.
Some hand-holding or references to tutorials or even assurance that I am on the right track (if that is the case) would be much appreciated. Thanks!
The Java Deployment guide from Oracle relies heavily on ANT, but doesn't cover the case of a self-contained, customized JVM via JLINK well enough for me to decipher. So, I've taken the approach of trying to learn/understand the necessary steps using command-line commands.
While creating a Bundle is certainly an option, there is an easier way.
Step one is to make an .app manually. An answer to this question: "How to make a Mac OS X .app with a shell script?" goes over the basic steps. The Java file system that results from jlinking has a folder /bin in which there is a bash file that runs the program. This file should be moved to the outermost folder, and it should be named the desired name of the application. The bash file itself will have to be edited and "/bin" added to the address in last command so that the executable will be found. In addition, the folder itself will have to be renamed to be the same as the bash file, but with .app added as an extension.
The next thing I wanted to have was a custom icon. The question "Include icon in manually created app bundle" shows how to do this.
For the next step I made use of the program "Packages". I'm a bit confused about where I downloaded this from (there seem to be multiple sites), but here is a link to the manual. This tool allowed me to create a .pkg file that, when executed, installs my .app in the Applications folder. Then I compressing the .pkg file (to .zip) and made it available at a URL for downloading.
I've had a friend do a test download and install, and the program works!
This isn't meant to be a complete tutorial, and there are a few steps more that I want to figure out pertaining to sandboxing and sealing, but I believe this is a reasonable roadmap that can be used for simpler jlinked Java applications for Mac distribution.
Trying out AppCode (2.5.4) at the moment I'm rather annoyed by having the full paths to projects always showing up in the 'Project' view.
Browsing the prefs I cannot find a way to turn this off?
I'd rather prefer the Xcode way of having just the project's name..
In particular working with workspaces and sub-projects a lot it adds a lot of visual clutter.
Jay,
there is no way to disable this path at the moment.
Why do you find it annoying?
I'm not am Apple expert. Under Linux, however, you could, as a workaround, create a soft link using "ln" to reference the long folder path from your home dir in a short fashion and use that path in your app. Maybe that works under Apple's system as well?
I involved with the development of an application that is intended to deploy on multiple desktop system including the Macintosh.
Our team decided we would like to a drag and drop installation for the Macintosh. However, the application is intended to ship with other content besides the application itself such as example files.
Originally these files were placed in the application bundle, however this was discovered to be problematic as the cross platform libraries used for the user interface will not allow someone to access the contents in the bundle. Also force users to have to dive into a bundle to find content does not offer a great user experience.
To that end, we decided to pull these examples file and what not out of the bundle and place them in a separated folder that lived along side the application bundle. To make sure everything including the examples and the application were copied together during the drag and drop installation, a new top level folder was created that contained everything to be copied.
The problem that now exists is that whereby when originally just the application bundle was copied over to the system, the copying of this top level folder does not cause file associations for the application to occur automatically.
What can be done to associate an application with certain files when someone installs by dragging a folder contain the application bundle?
I suggest you to deliver it separately in one dmg. So your dmg structure will look like next:
MyApp -> Applications
MyApp Examples -> Application Support
Simple, user-friendly, no problems with association.
Actually it looks like the file association is working after all. Someone reported a defect against the installation not making the associations. However, I just tested the installation on a clean system and copying over the folder does seem to make the associations.
I'm unable to get Xcode to copy over www resources to my PhoneGap based iPhone app. I considered using Git submodules, but since the app has to work on different platforms (iPhone, Android, etc) and has to be branded differently (images, css, and small changes to some files), it does not solve the complete problem.
I ended with a solution where I created an external core www folder and created symlinks for every file from the different projects. If a file needed special attention on a platform or for a branding requirement, then I could simply replace that instance of a symlink with an actual file.
This all would work like a charm, but for some reason Xcode for does not copy the symlinked resources over to the phone. Does anyone have any idea how to make this work? Or a solid alternative. Even if this takes me a day to fix.
Thanks.
This solution worked perfectly to pull in the symlinks on build. Using this method you can build Phonegap solutions for all platforms and have them branded differently with the absolute minimum code duplication.
In short, create a common directory that contains all your phonegap www contents, and then symlink this from your different projects (platform differences or branding differences). For building on Xcode, add the following to your project's run script:
rsync -pvtrlL --cvs-exclude \
$PROJECT_DIR/../Resources* \
$BUILT_PRODUCTS_DIR/$CONTENTS_FOLDER_PATH
Note: You also need to dereference symlinks if you build for BlackBerry.
I just want to say that using symbolic links shouldn't be necessary. You can simply drop the folder into xcode, and DO NOT copy the files.
In my case, my shared folder was called "mobile", so I did have to create this run script:
mv $BUILT_PRODUCTS_DIR/$CONTENTS_FOLDER_PATH/mobile $BUILT_PRODUCTS_DIR/$CONTENTS_FOLDER_PATH/www
This simply renames the directory so Cordova can find what it's looking for.
We have a a product developed on Windows for years. The product is composed of one Eclipse workspace and about 20 projects.
On Windows, we ask every developer check out projects into d:\dev\product folder, and copy a unified Workspace to d:\dev\prod_workspace. This way, whenever a new machine is set, we simply copy files to the same folder, and we can start working immediately.
Now we need to move our development environment to Linux and Mac. But there's no D:\ on Unix. And home folder for Linux is mostly like /home/username and /Users/username for Mac. We found Eclipse keeps absolute path in workspace when referring to projects, so simply copy workspace over does not work anymore. Even when we manually create/configure workspace on a Linux machine, it still cannot be copied over to another user, because the absolute path is changed.
I guess our goal is to allow easy setup of development environment. Do you have any suggestion to move eclipse workspace around?
I develop an Eclipse based product for Mac and WIndows (haven't tried Linux).
The solution I found to work best is to actually go and manually check out the projects in the workspace on each machine directly from source control. While the project structure does convert between platforms, any attaches, such as version-control stuff does not. I am not sure why, but I guess each thing has its kinks.
You may be able to able to hasten things a little by creating a project working set (or whatever it's called, I think it's a PSF file) for a platform, and then reuse it on all platforms.
Another problem is that Eclipse versions are not 100% compatible. One of the problems I have is with manifest files for plugins, which have different semantics (e.g., what to do with exported packages that don't actually exist) in each platform, causing a headache.
Finally, be away that Java on Mac and PC are not identical. In fact, Eclipse has two versions for the Mac. I usually end up running and compiling on Java 5 on the mac, which does have some incompatibilities with Java 6.
I have ported my eclipse project from windows xp to RHEL(never tried Mac)
Your task can be accomplished in the following steps :-
Use workspace variables in your project code rather than absolute path.
Shift your workspace to some location in linux as /Workspace or if you want to keep it user specific make the workspace folder as /home/user_name/Workspace.
There is an option to change all the \ of windows to / in linux. The option can be found under the file menu in eclipse.
Change the settings of where to find classpath directories, the options can be found by just right clicking on the project menu in the project viewer panel.
There is an option to build the project clean from scratch. You just have to click on the option and eclipse would re-compile the project.
Once all this is done, and all your database connections have been successfully ported to linux, you would have a working project running in linux as well.
I can think of two ways to do this:
Use workspace variables in Eclipse to point to the exact location where the workspace sits, if you need that. Then the developer can put everything in the workspace on Windows, Unix, whatever, then define the variable and you're done, or
If compilation is always done from within Eclipse, meaning you don't truly need any absolute paths anywhere, then change the projects to all use relative paths and check the Eclipse classpaths, etc, into source control. Thus, when a developer checks out everything in Eclipse, the classpath and .project file will be at the root level in the project and all paths will be pre-defined.
For option #2, you may need to have multiple .project or .classpath files, and have the developer copy the appropriate one into location. That is, copy .classpath.win into .classpath for Eclipse's use.
If you check out the projects from a source repository, then consider using Team -> ProjectSets to handle these.
Preferences can be saved in a file and loaded.
We tried classpath variables and loathed them. Now we just have everything in single projects in the source repository.
Use the Workspace Preference Transferrer plugin
This allows you to transfer the workspace settings from a given workspace to another via new options in the 'switch workspaces' dialog.
I'll share my own solution:
Zip the workspace. Just zip the entire file and then transfer it over. Then, all you need to do is delete the default drive reference:D:\ ...or whatever ends up appearing in the beginning of your file name. Then all you need to do is drag it over to the new empty workspace on your newly downloaded Eclipse.