I'm working on an existing project from my wd of git.
.classpath and default.properties files are on the repository.
When I import the project to Eclipse, my default.properties is replaced by a project.properties (the files' contents are the same) and my .classpath is modified.
As I said, these files are on the repository, so my git status is never clean.
Do you know how to force Eclipse using the files provided on the repository without modifying them ?
Thanks
default.properties (or project.properties)
Check out the changelog of SDK r14 release:
default.properties which is the main project’s properties file containing information such as the build platform target and the library dependencies has been renamed project.properties
If someone from your development team still use a version older than r14, better to ask them upgrade to latest Android SDK version on their workstation, as the Android SDK has been changed rapidly since r14 regarding to project property file, library project, external jar dependency structure and etc. It will make development very hard to maintain if developers use different Android SDK version in a team.
If this is not an option in a short term, you should temporarily create and check-in both default.properties and project.properties (with the same contents) for a short period of time, to support old Android version in a short term and give other people time to upgrade their workstation.
.classpath
It is a very bad practice to commit IDE generated files (.classpath, .project and etc.) into source control. Do you expect .classpath generated from a Windows box has exact the same contents as the one generated from a Mac box? You should add .classpath to your source control ignore list so that it is ignored automatically whenever you commit your project to source control.
When use a source control system, Don't consider too much for every single commit, as long as you provide fully detailed comments. as every single action (add, modified, deleted and etc.) you did on every single file (java source, properties and resources file and etc.) in your project are logged and tracked in source control, in case if something goes wrong, it is quite easy for a sophisticated developer to track the change and revert the project into a normal state. Hope this helps.
Related
I'm currently using Eclipse ADT 23.0.7 for android app development. My SDK manager is updated for Android 6.0 shown in below..I want to use v7 Preference Support Library in my project. but, unfortunately I can't found it in my (sdk)/extras/android/support/v7 directory as stated in Android Developer Website. I can't figure out what to do. Thanks in advance for any kind of help!UPDATE 1I've also tried to re-download the library but, nothing happen. Preference library is still missing.
Google stopped to provide Eclipse projects. It pushes developers to migrate from Eclipse to Android Studio. So all libraries are available as *.aar files
But it is still possible to these files in Eclipse.
Find the aar for your library at \android-sdk\extras\android\m2repository\com\android\support\preference-v7\23.0.1\
Then use instructions from CommonsWare guy Consuming AARs from Eclipse:
UnZIP the AAR into some directory.
Create an empty directory that will be the home for the Android
library project. For the rest of these steps, I will refer to this as
“the output directory”.
Copy the AndroidManifest.xml, res/, and assets/ directories from the
AAR into the output directory.
Create a libs/ directory in the output directory. Copy into libs/ the
classes.jar from the root of the unZIPped AAR, plus anything in libs/
in the AAR (e.g., mediarouter-v7 has its own JAR of proprietary bits).
Decide what build SDK you want to try to use. You might just choose
the highest SDK version you have installed. Or, you can use the
android:minSdkVersion and the -vNN resource set qualifiers to get
clues as to what a good build SDK might be. If desired, create a
project.properties file with a target=android-NNN line, where NNN is
your chosen build SDK. Or, you can address this in Eclipse later on.
Import the resulting project into Eclipse, and if needed adjust the
build SDK (Project > Properties > Android). Also, you will need to
attach to this library project any library projects it depends upon
(e.g., mediarouter-v7 depends upon appcompat-v7).
I'm currently using Eclipse ADT 23.0.7 for android app development. My SDK manager is updated for Android 6.0 shown in below..I want to use v7 Preference Support Library in my project. but, unfortunately I can't found it in my (sdk)/extras/android/support/v7 directory as stated in Android Developer Website. I can't figure out what to do. Thanks in advance for any kind of help!UPDATE 1I've also tried to re-download the library but, nothing happen. Preference library is still missing.
Google stopped to provide Eclipse projects. It pushes developers to migrate from Eclipse to Android Studio. So all libraries are available as *.aar files
But it is still possible to these files in Eclipse.
Find the aar for your library at \android-sdk\extras\android\m2repository\com\android\support\preference-v7\23.0.1\
Then use instructions from CommonsWare guy Consuming AARs from Eclipse:
UnZIP the AAR into some directory.
Create an empty directory that will be the home for the Android
library project. For the rest of these steps, I will refer to this as
“the output directory”.
Copy the AndroidManifest.xml, res/, and assets/ directories from the
AAR into the output directory.
Create a libs/ directory in the output directory. Copy into libs/ the
classes.jar from the root of the unZIPped AAR, plus anything in libs/
in the AAR (e.g., mediarouter-v7 has its own JAR of proprietary bits).
Decide what build SDK you want to try to use. You might just choose
the highest SDK version you have installed. Or, you can use the
android:minSdkVersion and the -vNN resource set qualifiers to get
clues as to what a good build SDK might be. If desired, create a
project.properties file with a target=android-NNN line, where NNN is
your chosen build SDK. Or, you can address this in Eclipse later on.
Import the resulting project into Eclipse, and if needed adjust the
build SDK (Project > Properties > Android). Also, you will need to
attach to this library project any library projects it depends upon
(e.g., mediarouter-v7 depends upon appcompat-v7).
I saw a lot of examples for .gitignore files for AndroidStudio, some have .idea in them, and some don't.
Is there a good reason not to add the entire .idea dir to .gitignore?
If it should not be completely ignored, are there specific files inside .idea (such as .iml) that should be in .gitignore?
You can take a look at this page :
IntelliJ doc about project configuration files
In the "Directory-based format", a particular line is interesting :
The .idea directory contains a set of configuration files (.xml). Each file contains only a portion of configuration data pertaining to a certain functional area which is reflected in the name of a file, for example, compiler.xml, encodings.xml, modules.xml.
Almost all of the files contain information core to the project itself, such as names and locations of its component modules, compiler settings, etc. Thus, these files may (and should) be kept under version control.
However, I properly HATE to make project IDE-dependent (I am currently working on a project made with NetBeans and it hurts to use it with Eclipse which becomes the standard of my company).
So, to answer your question :
If you do not use something like Maven or Gradle to manage dependencies and build : keep the directory under version control. This way, the correct configuration of the project and dependencies will be available for everyone. In the counterpart, all developers will have to set their environment exactly the same way that you define it in the config files.
If you do use something like Maven or Gradle : correctly configure these tools and do not keep the directory under version control. Actually, all the information contained inside config files should be stored in Maven/Gradle files. Then let your developers configure their IDE depending of their environment. This way, using Eclipse, IntelliJ, Linux, Windows ... will not be a problem anymore.
OK, so after some "Yes" and "No" answers, I am adding a "Yes and no" answer :)
The problem is that .idea is used for both project build configuration (dependencies declaration) and project settings (inspections, etc.).
You definitely don't want to use your IDE for your build configuration, but you might want to share the settings among the team. That's why you need to ignore only a part of the .idea content (like the libraries folder and the modules.xml file), but keep others in the version control (e.g. the copyright, dictionaries and inspectionProfiles folders and files under .idea like dynamic.xml, codeStyleSettings.xml, etc.).
The concept of keeping the project configuration in VC is valid. I did this with my team because all of our developers happened to use PHPStorm for our projects and so it made sense to keep a common configuration ... in concept. We wanted to use the same dictionary files, the same coding standard rules, and the same plugin configurations.
The reason why I qualify this with "in concept" is because there were issues with JetBrains' .idea folder that led to us not being able to use it. These were probably issues that could have been avoided or fixed, but it was unclear to us how to do it right, and we think that's a fault of JetBrains because as developers we do not have time nor desire to search for solutions on how to make our IDE work correctly.
That being said, the issues were had are the following:
Symlinking project folders doesn't work right.
When I set up my projects, I symlink them into my home directory. What we discovered was that the project was set-up to use the exact symlink rather than just treating it like a concrete directory. This means that if another developer keeps his project in a different place, or simply does not use symlinks, the entire directory will be missing from the project navigator because it is quite literally looking for the symlink. What's worse is that I could never find this path value in the configuration. We were unable to find the exact config in the files constituting our .idea folder.
Definition files are partitioned to users by default. This means if I want to add a word to my dictionary, it will be listed as a definition for me, jgreathouse, but other users will have their own definition section. The flagged words will still show up as a spelling mistake for other users. This is not desireable. The reason I add it to my definition file is because the IDE is wrong. I want these definitions to be intuitively shared with other users.
Colleagues kept overwriting the configurations because their IDE would overwrite the configurations with their config currently in Memory. What I mean is that, a developer would be working, and merge their repository from origin, which would contain a project configuration change, instead of their IDE changing configurations, or even giving them a choice, it would automatically overwrite the .idea configuration with the current in-memory configuration of their IDE. In my opinion this makes the .idea configuration unusable as a shared configuration. In order to work around this, the developer would literally have to shut down that instance of their IDE, pull the repo, and re-open their IDE. It makes no sense to keep a shared configuration if the IDE instantly overwrites it with the configuration currently in memory. It's like not having a shared configuration at all.
I've done these types of shared IDE configurations in VC before with Visual Studio and Netbeans and it was always fine; but with .idea it feels simply unusable which is disappointing. I wish JetBrains would get on top of it and make it a better user experience.
As a complement to the explanations in this question GitHub's .gitignore template for Android includes the following files:
# IntelliJ
*.iml
.idea/workspace.xml
.idea/tasks.xml
.idea/gradle.xml
.idea/assetWizardSettings.xml
.idea/dictionaries
.idea/libraries
# Android Studio 3 in .gitignore file.
.idea/caches
.idea/modules.xml
# Comment next line if keeping position of elements in Navigation Editor is relevant for you
.idea/navEditor.xml
Notice also this entry from JetBrains guidelines on How to manage projects under Version Control Systems about sharing IDE project files with other developers:
What needs to be shared:
All files under the .idea directory in the project root except the
items that store user-specific settings: workspace.xml
usage.statistics.xml shelf directory
I'm using ActionBarSherlock as a library. We haven't included ABS into our repository so everyone participating our project must download and install it separately. ActioBarSherlock is an Android library project and I have got it running by opening it and my project in the same Eclipse's workspace (neither of those are copied into workspace, they both exists in another folder) and adding it into my project.properties by following this:
Referencing a library project.
That reference path is relative and since everyone might have ABS in different folder, we also have different paths in Eclipse's project.properties file as android.library.reference.1. Is there any way locally override that library path so that we can have project.properties in our repo but Eclipse will use locally some other path? Currently I have to manually fix that path after every time I pull from our repo because of different paths.
There exists other *.properties files but Eclipse ignores them:
local.properties
Customizable computer-specific properties for the build system. If you use Ant to build the project, this contains the path to the SDK installation. Because the content of the file is specific to the local installation of the SDK, the local.properties should not be maintained in a source revision control system. If you use Eclipse, this file is not used.
ant.properties
Customizable properties for the build system. You can edit this file to override default build settings used by Ant and also provide the location of your keystore and key alias so that the build tools can sign your application when building in release mode. This file is integral to the project, so maintain it in a source revision control system. If you use Eclipse, this file is not used.
Just have each person put it in projectroot/libs. The newer (ADT 17 and above, IIRC) versions of the ADT will automatically pick it up and compile it into your app. Note that the folder is libs, with an s, and not lib. Using /lib won't work.
Options:
project.properties: You could create a link in every users home folder, libs and have the path in the project.properties refer to ~/libs
Using a common library:
Create a library project called "common". In settings, have it export the jar. In your Android application, import the jar.
Personally I think configuring with maven would be best but the 2nd option was quickest.
What about if you ignore the project.properties in your repo? That way each user can keep their own and you won't need to override it all the time. I don't think you can override that locally.
Another option to simplify things is you can export the project as a JAR file instead of referencing it as a library project. If you don't need to modify ABS code you can right click the project -> java -> jar file and all the developers can keep that in the same place for the sake of simplicity.
Edit: This question is no longer needed for our project since we moved from Eclipse to Android Studio and Gradle build system. Eclipse with Maven should have worked too, as #bgs suggested.
Our previous approach:
Still looking for better alternative but so far we ended up keeping project.properties in our repo. project.properties does not get overridden if there is no changes to it when pulling. We also suggest in our README that users add this
[alias]
commit = commit -X project.properties
to their .hg/hgrc configuration file to prevent accidentally commiting changes of that file.
This method has at least one drawback: When merging, you might get error like this abort: cannot partially commit a merge (do not specify files or patterns) even when you commit your merge with hg commit -m 'merge'. If this happens, disable that alias temporarily.
I asked this question on the android-developers group but didn't get any response, so I thought I'd try here.
The ADT eclipse plugin seems to have a pretty rigid idea of how an Android project should be structured - per http://developer.android.com/guide/developing/eclipse-adt.html, it needs to have the AndroidManifest.xml file at the root level of the project, plus res, assets, gen and src folders at the top level, and so on.
I'm wondering if it's possible to get the plugin to be a little more flexible with the layout it recognizes. In particular, I've been using a build plugin for the (scala-based) simple-build-tool, which expects projects to be laid out in a more Maven-like fashion, like so:
src/
main/
AndroidManifest.xml
assets/
res/
scala/
java/
test/
resources
<files to include in test jar here>
scala/
<test Scala sources>
java/
<test Java sources>
(see the simple-build-tool docs).
This is a layout I'm used to from maven-based java development. When I load a project like it up in ADT, though, I get a lot of complaints about a missing AndroidManifest.xml, a missing res directory, and so on. These things are all present, they just aren't where ADT expects them to be.
I don't necessarily need to use ADT to build my project, but I'd like to use it (and Eclipse) for editing. Can anybody tell me whether it's possible to make it more flexible in the directories it uses to find various Android-related resources?
Also, can anyone tell me whether the ADT plugin is open-source? I can't seem to find a link to its source code anywhere.
(As a note, I've also been trying to wrangle sbt to just do things in a way that ADT likes, and it's probably possible to do but it seems very tedious.)
Here's is where you can find the ADT source for r3 0.94, couldn't find the latest though
I do not believe you can change the Android project structure and have ADT understand it. It would be "very tedious" to do that even with the Ant-based command-line builds -- you'd have to make your own copy of the various Android Ant tasks, modify them to suit (and hope the underlying build tools allow what you want), then maintain them forever in the face of Android SDK updates.
Your structure is actually fairly close to the Android expectation, if you consider main/ to be the Android project. If you can convince sbt to allow src/ instead of java/ there, and if sbt won't complain about the resulting bin/ and gen/ you will wind up with in main/ after a compile, you might get it to work.
As far as I can tell, ADT requires those folder names, but there is a workaround: you can create "linked folders" in Eclipse. These are similar to symbolic links in Unix, but are stored in the Eclipse .project file instead of the filesystem, so they are only visible to Eclipse.
You can create one by right clicking in Eclipse the root of the project, and then selecting "Create New Folder". Click on "Advanced" and select the option to create a linked folder. Then type in where you want it to link to. You can use PROJECT_LOC at the begining to specify the project directory, so for your example you would type PROJECT_LOC/src/main/res as the folder to link to, and use the automatically generated name of "res" for the created folder.