My question is fairly simple but I've not been able to find an answer or work out a solution myself. I'm using a few libraries in my projects (e.g. HoloEverywhere, ViewPagerIndicator, etc.), and I move between computers fairly often, send projects to colleagues, etc. Anytime I do this, my library references are all messed up and I have to redo them. This isn't really much more than a hassle, but I would much rather have the library references self-contained rather than having to use references to folders on the drive.
I've tried exporting the libraries to jar files and including those in the build path for the project to no avail. That's really the only thing I've thought to do, as I have no clue how else I could accomplish this. Basically, I want to be able to have a library contained in a project instead of referencing library projects elsewhere in the workspace. Is this possible?
Thanks for any help!
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.
I am using Eclipse + Subversion for Android development. I used to create a free version of my apps with ads, and another one payed without them, so I kept them in two separate branches on subversion.
The problem I have found is that as these are two different app for Google Play and other markets, they must have different package names. So I have, for example:
com.package.game
com.package.gamefree
When I do some changes on the free version of the game and want to merge them with subversion into the payed branch, I found myself in a trouble because source files for the free game are below com/package/gamefree and for payed under com/package/game
I ended up doing a "manual" merge, making a diff of source file by source file, but I also have to check those files that have been added into another directories and those that has been deleted. A waste of time.
So, is there any manner to make subversion know that com/package/game in one branch is the "same" directory than com/package/gamefree in the other?
Thanks a lot in advance,
I'm guessing here, but maybe you could have the free app on the trunk in the com.package.gamefree package.
On the branch you could have the other importing the one developed on the trunk as a dependency lib, and wrap it around with launcher class which is packaged under com.package.game, adding the license stuff...
This way you'll only have to modify the code once, and build 2 apps.
After googling a bit in deep, I found that my better chances was just two:
Using ANT in anny manner that automatizes the switch between free and payment versions at building time.
Using an Android Library project shared between two versions.
I have seen that most of the people using ANT were doing it some time ago by the lack of another option, but since there is Android Library projects on Eclipse/ADT this is the preferred way for this kind of things. Even in the development docs of Android, says:
http://developer.android.com/tools/projects/projects-eclipse.html#SettingUpLibraryProject
If you are creating an application that exists in both free and paid versions. You move the part of the application that is common to both versions into a library project. The two dependent projects, with their different package names, will reference the library project and provide only the difference between the two application versions.
This seems to be the best way for me also because I have never used ANT and given the library option there is no reason for learning it.
So I have done that way: my project is splited now into MyGameCore that is the library project with all common files to both MyGameFree and MyGamePay projects, that now just have the minimal classes needed to have a different main package name so Google Play knows they are different applications, plus the raw assets folder that according to Google Docs cannot be moved to the library. Anyway these are binary files that I simply copy from one version to another when they are changed, that is not very often.
So from now on, most of the time I just need to work on the MyGameCore project and the changes done have inmediate effect on both MyGameFree and MyGamePay projects without needing to merge branches.
This will save me A LOT of time and I will use it on my further projects from the very first code line.
I was trying to get started with using (not making contributions to) the geotools lib yesterday,but i ended up trying to figure out what purpose does maven serve when it comes to someone that just wants to build a small/medium app based on geotools;At first i thought that using maven spares the dev on writing all the imports ( that's what i recon dependencies are BTW) but after reading a blog that had a somewhat modified version of the quickstart tutorial i'm not that sure anymore..Could someone make clarify what is maven's use for someone that just wants to build some apps and not make contributions?
Maven has nothing to do with saving you from import declarations in Java source files. It is about handling your whole project and that might include dependencies. But you still have to write imports in Java. If your project is to small for maven to be useful, don't use it. But in larger project a declarative build description, dependency management tool is definitely useful.
I wouldn't attempt to use the GeoTools library without Maven, it is a large and quite complex project with 10s of jars. Your app will probably only need 5-10 of those jars but without Maven it is almost impossible to work out which 5-10 you'll need. For example you will probably want to read in some data, so you'll need gt-data and at least one specific datastore gt-shapefile or gt-postgis. I'm pretty sure one of those will need to use a coordinate system so gt-referencing (and a specific implementation, say gt-epsg-hsql).
Anyway you should probably work through at least the quick start tutorial to see what Maven does for you.
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