So my project structure looks like this:
Applications/Project1/Build/Android/AndroidManifest.xml
Applications/Project2/Build/Android/AndroidManifest.xml
Common/Library1/Build/Android/AndroidManifest.xml
Note that beside AndroidManifest.xml are the other usual directories and files, such as .project, jni directory, src directory, and so on.
I want to import these as Android Studio projects, however when I do that it reorganizes the structure, in addition it doesn't seem to do the upgrade in-place, when I want it to. What I get instead is this structure:
Project1/build.gradle
Project2/build.gradle
Library1/build.gradle
To make things worse, it also copied my physical source files and recognized those as well. Is there an easier way to transition to Android Studio, while at the same time keeping the existing structure as close as possible? I also don't want the upgrade to happen in a remote location. I want this to physically replace the current Eclipse and Ant project files. Should I do this by hand? Or is there some trick I can use in Android Studio's import wizard?
Also: Not sure if it matters, but the code base is primarily C++ + CMake. Current projects use Android.mk, but I'd want to make them use the CMake scripts instead. However, if that doesn't bear any affect on this process we can ignore it and I'm happy to address the C++/CMake integration later as a separate step. Right now I just want the general projects to get setup, have proper Gradle scripts, and other things (Java side, basically).
I suggest doing it by hand. It could be faster than getting to make the tool do the right thing.
Remember that migration/import tools are much more rarely used tools than, say "call hierarchy" or "find usages" and thus they might get less love and polish.
Writing gradle files by hand is actually quite fast. The syntax is quite light (unlike, say, Maven, or worse, Ant).
Try it and you might find Gradle to become a friend, rather than "foe" ;).
Also, don't forget settings.gradle to tie the modules together.
Another suggestion would be to trick the import tool via making a project with simpler structure and then copy&paste the relevant bits into your own structure (so that you more-or-less know what to put in your gradle files).
I want to setup eclipse on a network drive and have it so me and my friend can code at the same time on the same project and the code update automatically on both computers.
The standard way to do something like this is by using version control. It will require a certain amount of discipline, but will bring many benefits.
You certainly don't want to simultaneously work on the same copy of the code. Just imagine your friend starting to make changes to an important class; all of a sudden you can't do any work since the project won't build or won't run until your friend is finished.
Instead, you'd each work on your own copy of the project, and periodically commit stable versions of the code into the shared repository for your collaborators to see.
I am doing the same thing as you. My friend and I are working on the same project together. We use a dropbox shared folder to share codes, only you can only edit one at a time. It works for us becuase we are coding unrelated parts of the project.
Say I implement an algorithm for a project. Say I want the same code to be used on another project. What would be the approach to do so? Just copy and paste code? Create a "library" project? What? Is there a tutorial or site that explains how to do this?
Sure, add it to a library project, but the benefit of reuse should always be compared to the cost of making the code general. Sure if you improve the code by fixing a bug or increasing performance, it is nice to get that into all projects where you use the code, but it also makes you slower because you have to keep the library compatible with all clients (at least the ones that will build after a breaking change).
It is often better to copy and adapt solutions to new projects, than to maintain far more complex solutions. One very important thing to take into account is how many client you think you will have for the library. How much work would it be to maintain those clients separately?
On the other hand some code is generic by nature and can most definitely be shared in a library to make your life easier.
If your algorithm is in Java, build it as a jar.
Then create a folder called "libs" in the root directory of your android project. Copy your jar into that folder. In eclipse go to
-> Properties -> Java Build Path
Under tab "Libraries", add your jar.
Now you can use your code.
You can as well link it with multiple projects.
If your algorithm is in natice C/C++, follow
http://marakana.com/s/introduction_to_ndk,1153/index.html
If you have a class/set of classes generic enough to be reutilizable, the solution would be separating them to a different project.
In your IDE, make your projects use the generic project as part of their build path (it is more flexible than including a jar).
When deploying, package all the generic classes in a jar and it to your solution. Don't forget to include that jar in the classpath.
In Java, there is no difference between "main project" and "library", other than the "library" usually does not include any main method (but it is not forbidden). They are classes in the classpath.
Maybe my approach is wrong, but here is what I want:
A logging library, written in pure JAVA
It should work on Android as well
I want to use it in Android and desktop apps
The approach I tried is taken from VS and C#, there it is called "multi targeting" - it basically means a module shares source code with another module.
So my idea was to create 4 modules:
AndroidApp
AndroidLog
DesktopApp
DesktopLog
The "real work" on the logging stuff (most of the classes which are pure Android compatible JAVA) would go into AndroidLog (to prevent me from accidently using classes not in the Android SDK).
The Android App can use the log library without any problem, thats the way I do it at the moment. Now the DesktopLog should have some of the folders the AndroidLog has, basically reusing the same JAVA code.
I tried to add a source folder from AndroidLog to the DesktopLog, but I get an error telling me "the root already belongs to...". I am working with an SVN, but I think thats not the issue here (actually, I tried the above without SVN, but it might provide some workaround if there is no simpler solution).
So how do I get IntelliJ to:
Share JAVA files across different modules with different target platforms.
Thanks for tips,
Chris
PS: Search tearms are also welcome "sharing source JAVA" is not very google friendly.
mm. I think you're going about this the wrong way. I would organise it like this:
Common-Log - A common Java package containing classes which are used by DesktopLog and AndroidLog
DesktopLog, with a dependency on Common-Log
AndroidLog, with a dependency on Common-Log
DesktopApp
AndroidApp
Trying to simultaneously reference partial source trees from a single project in different sub-projects sounds like a recipe for headaches; I think you'll have more luck if you follow the approach of extracting the common support classes from both Logging projects to a separate common project.
I am simply wondering whether it is best to put all of my Eclipse projects into one workspace, or do a 1 workspace per 1 project. I am just a solo developer, for hobby more or less, but the apps I create do actually have production versions that are running on rather frequent cron jobs, so its almost like an amateur production environment.
The only problems I have noticed so far is for exporting JARs, I have the potential to include source files from other projects which seems like it could get messy.
I used to keep separate workspaces, but got tired of the difficulty in keeping settings consistent between them. Now what I do is create working sets for different projects and change the current window working set to filter out everything except what I want to work on. So far this has worked fine for me.
Since each project can have multiple working sets, and the window working set can be any combination of working sets, it's quite easy to only see what you want at any given time this way.
I create Eclipse workspaces around products, because for me, a product can have multiple projects within them, for example like having core libraries compiled into one jar in a project, this is used by other projects.
In terms of production environment, you would want products running in different directory structures, much cleaner that way. And in eclipse the workspace creates a directory with workspace name. So, create workspaces based on product/app rather than one or more projects within them.
Not only do I keep separate workspaces for each project but I keep separate copies of Eclipse also. This is because I typically have to put projects on ice for long periods and return to them (with little notice) and they absolutely must build. I can't take the chance that some plugin I've installed for my latest project (maven based) will interfere with the build process of one of the legacy systems (ant based). For the record I do document the eclipse environment for those legacy systems but I don't have time to mess with eclipse when patching a production bug.
If the projects are interrelated (i.e. have dependencies on each other) then it quite often makes sense to have them in the same workspace. Also, if you are working on several projects to solve a related problem, the same applies.
You will waste a lot of time changing workspaces unnecessarily otherwise, especially when the IDE will immediately show you the impact the changes in one project has on another.
I would use separate workspaces for different "groups" of projects. For example you might want to combine your main app project AND the unit testing project together in the same workspace.
Maybe I'm unlucky, but Eclipse often (once a month, say) dies on startup, typically in the "Initializing Java Tooling" stage. The recommended solution seems to be to create a new workspace. If you have all your projects in one workspace, this can be a pain. I think smaller workspaces may mean the crash is less likely to occur.
As the Preferences are workspace-specific, I tend to have a enormous workspace open - I'm too lazy to sync some settings between workspaces (e.g. repositories...).
On the other having too much projects open in a single workspace can slow down Eclipse - so the least I have to do is to close projects I'm not working with. I manage a lot of relative short-term projects (at most one month) in Eclipse, that reside in the same workspace (and in most cases the same repository), so this setup gives me a bigger flexibility.
If you have several, interrelated projects, then keep them in the same workspace. If you can identify group of projects, that are always used together, but the groups are used independently, then put such project sets into different workspaces. In that case that should be the logical structure.
We have a situation where we have several projects, some on branches, which frankly is too impractical to keep in the same workspace - and working sets are a joke. Unfortunately. Also having projects open you do not use, may accidentially be chosen from completion menues, etc. Error prone.
The really nifty feature for us, was when Team -> Project Sets were added (in Eclipse 3.3 I believe) as this allowed us to have a single file describing the many projects making up the whole application, which can be imported in Eclipse with Team->Import. Need a given project? Check it out of CVS, locate the projectSet.psf file inside of it, and import THAT.
This has proven to work well for us.
I have one workspace per Type of project.
Ex: Plain Java, Web Application, Python etc.
The reason being I can share libraries that are similar without copying or pointing to them.
Also, I close the unrelated projects from eclipse to avoid clutter.
I have all my projects in single workspace and use working sets to manage them.
Up to you! I've always found keeping the related versions of different projects, which belong to the same release in a given workspace a cleaner approach. That way, I could switch between workspaces whenever I need to refer to something in a separate release, and switch back to the current release workspace.
It also saves me from the hassle of checking-out, or browsing the repository.
You may also want to keep in mind that you can open multiple instances of eclipse as long as they are looking at different workspaces. Not sure if that is important to you, but I like doing that from time to time.
I like to use several decoupled workspaces (which differ depending on the type of project), which import projects from various locations. Easy to move things around, without creating a ton of similar workspaces. Plays nice with my SCM too.
Depends on how many projects do you work?If you work on many projects, I'd use same workspace, because if you use several you can easily forget what is where and that can be frustrating to say at least. However I always use different workspace for different programming languages that way its less confusing, when you're in JAVA workspace you think JAVA :D