At work, we have a project where an Android application depends on a Android library project for some theme files. The application project has a simple path to the library project, so they always have to be in the same position relative to each other. For reuseability the library project lives in its own Git repository. There are two possible ways of making this work on the both the local side and the server side:
One is to have the library project checked out as a submodule to the application project and make the path simply be the subfolder name. The advantage of this is that it will work equally well on the server (Jenkins) side and locally within a workspace. The disadvantage is that you can’t have more than one project using the library in our workspace, unless you modify the projects project.properties file. (Which quickly becomes a version control pain in the ass. It might be possible to modify local.properties instead, which I haven’t tested, but keeping machine-specific configs outside of version control also creeps me out.)
Now, I don’t know if this is Eclipse Best Practices, but I typically keep several Android projects in the same workspace since it makes it easier to jump between them when working. Therefore I prefer to have the library checked out as a top level project in the workspace, and all the projects referring to it have a path like “../TheLibrary”. This will, on the other hand, create problems for Jenkins when it checks out the project and then can’t find a folder in that location with the library. So I use the “Multiple SCMs” plugin to fetch both the application and the library, and set them up to checkout to separate directories within the build workspace. (Branches to build -> Advanced -> Local subdirectory for repo) Voila, we have recreated the essential parts of the Eclipse workspace and things will build happily without any differences between IDE and build server!
Right now managing Android libraries is quite difficult, and hopefully this will improve with the new Gradle based build system. Being able to package them in a binary format that you can drop into the project’s lib folder sounds like exactly the ticket for something that doesn’t change very often. Alternatively, I have been thinking about maybe setting up an inernal Maven repository to make things properly automagical!
Edit: I forgot to mention that if you set up an Android build with subdirectories like this, you will also have to go to Build Steps -> Invoke Ant -> Advanced and specify the build.xml file since it is no longer in the root.
Do I understand correctly that you managed to build your project with a dependancy on a Library Project on Jenkins? Didn’t you run into this class not found issue?
http://stackoverflow.com/questions/10645366/how-can-i-reference-library-project-in-an-android-test-project-ant-build
Yes, I managed to build it without any such issues, but I haven’t built with this arrangement and a test project so I can’t really say anything about that.
If you explain step by step it will be very useful.I’m new to jenkins.My requirement is there a one Main Project which depend on two library project which has to be built usng jenkin.
The third paragraph is fairly step by step, but here it is again, more ordered. (I’m assuming you know enough about Jenkins to build a single Android application without dependencies, if not then you should google for tutorials on that first.)
First, you have to search for and install the Jenkins Multiple SCMs plugin (Mangage Jenkins -> Manage Plugins)
Then in the project you want to build you set up Muliple SCMs as the version control step. You add the three repositories you want to pull code from, and set them to check out into separate folders with the same names as they have in your Eclipse workspace. (Branches to build -> Advanced -> Local subdirectory for repo)
Then you go to Build Steps -> Invoke Ant -> Advanced and specify the build.xml file of your main project since it is no longer in the root.
Hi! I had the same problem and used the Multiple SCMs approach and everything worked well.
The “problem” is: I have several Android projects I want to build on Jenkins, and most of them have the same library dependencies.
The “Multiple SCM” approach downloads everything in the workspace for the job, so it can’t be shared between jobs. For every job, Jenkins downloads and builds all dependencies, wasting disk space.
Is there any way I can reuse those library dependencies?
I don’t really know of any way, no. But then again these days disk space is cheap. You could consider limiting the number of builds Jenkins keeps stored to cut down on disk usage? Actually, I have now moved away from the methods described in this post by setting up everything to build with Gradle and an internal Maven repository instead, which is a much cleaner way to do it.
uim834
oukxqf
cn2qnf