8

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.

Community
  • 1
  • 1
Kuitsi
  • 1,675
  • 2
  • 28
  • 48

4 Answers4

0

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.

Raghav Sood
  • 81,899
  • 22
  • 187
  • 195
  • If I want to use that same library in multiple projects this approach means I have to copy those same files to multiple locations. Is there any other option where I could use a library installed into single location in my hard drive to multiple projects at the same time? – Kuitsi Sep 18 '12 at 19:09
  • Not that I'm aware of. If you modify project.properties, eclipse will anyways overwrite the file the next time you build the project, – Raghav Sood Sep 18 '12 at 19:16
  • 3
    ActionBarSherlock is not a JAR and therefore does not go in `libs/`. It is an Android library project. – CommonsWare Sep 18 '12 at 20:38
0

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.

bgs
  • 1,210
  • 10
  • 19
  • Option one kind of defeats the purpose of my question since I'd like to let users decide where they are storing their source code locally as long as Eclipse can find it. AFAIK Eclipse has no other restrictions of code locations other than sources in same project must be located on same hard drive (references are done with relative, not absolute path). Option two: we already have ABS as library project. Why should we make a copy of it? Third one, Maven might be a bit overkill. – Kuitsi Oct 23 '12 at 17:44
  • Option 2: Then configuring ABS to "export" its lib would be the end result. If you really don't want to use a convention and make it harder on yourself, create an ant task that runs `find -iname 'magical.jar' -print >> local.properties` (check to append correctly). Most would want to get things done and sacrifice configuration over convention. Why choose to maintain some configuration... – bgs Oct 23 '12 at 18:03
0

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.

caiocpricci2
  • 7,714
  • 10
  • 56
  • 88
  • 1
    How about this: **Why is ActionBarSherlock a library project whereas the original compatibility library is only a .jar?** _The custom action bar implementation within ActionBarSherlock relies on styles, themes, layouts, and drawables in order to display properly. Due to the limitations of Android and .jar files, this currently can not be accomplished any other way._ Source: [ABS FAQ](http://actionbarsherlock.com/faq.html) – Kuitsi Oct 27 '12 at 22:02
  • I'd like to keep project.properties in repo since it's needed by Eclipse and I'd like that users can compile our project without hassle after cloning it. Ignoring it with .hgignore does not work because that file is already tracked. There exists [some options in .hg/hgrc](http://stackoverflow.com/a/3615771/262462) but those should be set to every fork of our project too. – Kuitsi Oct 27 '12 at 23:05
  • 1
    @Kuitsi I had no idea! Thanks for sharing that! And if you don't keep project.properties in the repo is no big deal. Instead of importing the project the users just have to create a new project with existing source on eclipse and that file will be generated. I know it's not the best option but it might help you in case you don't have anything else! – caiocpricci2 Oct 28 '12 at 09:13
  • This seems like the closest enough answer to me, so awarding the bounty, as it was about to expire. – ZeroOne Oct 29 '12 at 16:23
  • 1
    Android has a new [.aar archive format](http://tools.android.com/tech-docs/new-build-system/aar-format) for library projects. – Kuitsi Aug 28 '13 at 13:25
0

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.

Kuitsi
  • 1,675
  • 2
  • 28
  • 48