I develop with eclipse, Java for Android. I just installed SVN subclipse for the company. I made the repository in a cloud (maybe it is a mistake, I can change it) and we all work every one in his computer and then commit the code to the repository.
The repository is always the latest code of all the developers.
I don't find a way how to compile the repository and build an APK file. How can I do it?
Typically you would use some continous integration system like Jenkins. It can fetch the code from your svn repository (or git for that matter), and perform most anything you want. This seems like a good starting point: Building android apps with Jenkins/Hudson (even if the link is a bit old).
Related
TL;DR -> How to integrate a local Opendaylight Karaf App in the Opendaylight integration/distribution project, for local use? I am not looking to publish my code to upstream to official opendaylight repositories.
I am trying to understand how to make changes to source code of certain features in Opendaylight to fulfill my custom use-cases.
For this, I downloaded the Netconf Source code from "https://git.opendaylight.org/gerrit/netconf" and the distribution source code from "https://git.opendaylight.org/gerrit/integration/distribution".
I made certain modifications in the Netconf Code and built it using mvn clean install -Pq -Dcheckstyle.skip.
Now, how do I go about integrating these updates in the integration/distribution project?
FYI:
I am working on ODL "release/oxygen-sr2". However, I realise that newer versions are available and I am open to shifting to them.
Using Java 8 and Maven 3.6.0
I had been suggested that I could just maven build the Netconf Project code and run Apache Karaf from there. Any other feature could then be installed via the Karaf CLI. But, my use case would require modifications on multiple existing features and even creating a new feature. Therefore, this solution also doesn't work for me as I would still need to integrate everything in one central project.
Actually, it's pretty simple, but maybe not obvious. Build all the projects you
want locally, then build the integration/distribution project. Any artifacts it
finds in the local m2 repo will be used for the final int/dist karaf that will
get created.
in other words, for every project you want to customize, pull that repo, make
your changes, build it. Then as a last step, build the int/dist project.
I have a library and a program, both under my control and built using Gradle. What's the best way to develop these two at the same time?
I have set up a private maven repository to distribute the library and that's working, but I don't want to release to that repository every little experiment I make during development. It's slow and disruptive to users of the library.
I tried installing the jar to the local maven repository as explained here: Gradle alternate to mvn install but the project that's using the library is not picking up that newly installed version.
I think, you can try to use multi-project builds for that if it's possible. But you will likely need to restructure both your current projects to become modules of the same new project.
What's the best way to develop these two at the same time?
It depends by how the team is organized and what are your policies.
Of course if the team can use a git repo and access to the source code you can just use git without pushing a new version on the maven server for each commit or push.
Otherwise if other users can only use the final library, you have to push the version on the maven server.
I have set up a private repository to distribute the library and that's working, but I don't want to release to that repository every little experiment I make during development. It's slow and disruptive to users of the library.
Every maven repo has 2 different repositories:
release
snapshot
Usually release repo is used only for stable releases and the snapshot repo is used to publish little change, beta release and so on.
In any case it is not required that every changes in the code is pushed in the maven repo (it is a your choice)
It's slow
The time to upload artifacts usually is not so big, in any case you can evaluate to push the release in the maven repo with a CI server.
The best method seems to be to make one project include the other one when present by adding:
if (file("../libraryproject").exists()) {
includeBuild "../libraryproject"
}
to the settings.gradle file of the project that uses the library. That can be committed to the source code repo because when that directory doesn't exist, the dependency will be included in the traditional way.
This is called Composite Build in the Gradle world, IntelliJ seems to handle properly and theres'a recorded webcast showing the whole setup: https://www.youtube.com/watch?v=grPJanXfRPg
I've been working on a Java project using Gradle in Eclipse that builds on my local machine and works just fine. I want the project to be available to a team of developers via Git, but after creating the repository and trying to build on a different machine using both IntelliJ and Eclipse, I'm realizing that there are some challenges. For instance, it seems like there need to be minor changes in build.gradle. Or in IntelliJ, JDK 1.8.0 must be specified for java.util.stream.
My goal is to create a project that allows a team of developers to simply clone the repository, use any IDE they want, build the project and begin contributing right away. Has anyone attempted to do this before with Gradle? What are some tips or insights? Is Gradle a poor choice for this? How can I standardize the build, libraries, etc.?
I have been having endless grief with Gradle for Android builds after I had to format my Macbook Pro for some stupid corporate domain migration. I have been using Gradle (both off the command line and with Android Studio) to build my projects for over an year now, and never had problems till the fresh install. I spent countless hours over the weekend trying to fix this, but with no luck, and I'm literally on the verge of tearing my hair out! Here is what I'm stuck with:
Gradle builds have slowed to a crawl
I have a multi-project (or multi-module in Android terms) project which used to take around 2 minutes for a clean build - plus uploading archives to the (local) Maven repository. Now,the Gradle configuration phase takes around 8 minutes! Nothing has changed, for after the fresh setup on the Mac, I just took a pull of the sources from the Github repo, and I'm building using the gradle wrapper (as before) which uses version 2.2.1. Not sure if this matters, but the Gradle version on my machine is 2.6. I use Maven - not for builds, but for the local M2 repository, and the Maven version is 3.3.3. Both Maven and Gradle were installed using Homebrew. The Gradle runtimes are the same whether of the command line or using Android Studio. I'm using Android Studio version 1.4-beta4. Here are the things I have set up:
I have set up the Maven settings.xml to point the local Maven repository to the default location `${user.home}/.m2/repository
I have set up Google repository using Android Studio and the Support repository (my project needs Play services and the support library)
We need to upload the archives to the corporate Maven repository on our build servers; to sidestep this, I use the gradle.properties to define the repository URL to be the local M2 repository that's set up in the Maven settings
The project defines Android build tools version 1.1.0, and while this is an older version, I tried with the latest 1.3.1 with no luck on the build times
Possibly related: my Mac Pro uses a good ol' HDD, not the newer solid-state storage. While that can impact build times, the disk was not updated during the format, and also, I presume that it shouldn't result in such multiple orders of magnitude impact
Failure in resolving artifacts from local M2 repo
The primary project that I work on is a library, and we have test clients that we use to verify functionality. The library and test clients are maintained as separate projects in the Github repo. To not have to make any changes in my local development setup, I prefer to deploy the artifacts from my library to my local M2 repo, and then have the test client define and resolve the dependency locally. I accomplish this using the global gradle.properties to override the repository URL (point it to the local M2 repo). This worked just fine till the disk format, but is broken since. Gradle is never able to resolve the artifacts, but I can see them in the local M2 repo. I have googled high and low (on Gradle forums, here on SO), but cannot seem to figure out what I'm missing or doing wrongly. As a work-around, I added the test client as a module to the library project, and am building it as a single multi-module project. BTW, even with this, I still run into the slow Gradle build times problem that I mentioned above.
Can someone help me out?
so there are a few Problems you got to adress:
1. gradle is not resolving the artefacts in the local repository
- maybe it corrupted during the formating (Setup a test Project using maven for
its build only, specify some existing dependencies if you want to verify).
A fresh setup of the repo could resolve this.
2. gradle build is slow
Well, without further Information hard to troubleshoot. Did you refresh your dependencies, clean up the Cache, have enough free disk space in the GRADLE_USER_HOME?
I figured it out. There's one little bit I'm still not able to grok, but that aside here is what was wrong:
Slow gradle builds
The project's build.gradle file had declared a dependency on our corporate SCM Maven repository. I replicate whatever dependencies my project actually needs in the local M2 repo. Once I replaced this with a file URL pointing to the local M2 repo, Gradle build times dropped to the earlier 30-40 seconds. The part I'm still confused about is that even with the remote repo, Gradle should have downloaded the artifacts once and cached them in the Gradle cache. Still need to figure out why it's not doing that.
Failure in resolving artifacts from local M2 repo
This was a bad error on my part. In my gradle.properties I'd listed the SNAPSHOT_REPOSITORY_URL override as /Users/me/.m2/repository (with me replaced with the username). I missed the file:// prefix here. I'm somewhat surprised that Gradle didn't call it out, and instead deployed the artifacts at the directory pointed by /Users/me/.m2/repository, but may be I don't understand how this works so well. Once I added the file:// prefix, all the test project builds worked like a charm!
I'm a long time Eclipse user but new to Git/Egit. Recently I've been trying to use Egit because I want to use GitHub to collaborate with a number of projects. The projects I want to work on are not Eclipse-specific projects but I'd still like to set up a workflow so that I can work on them in Eclipse.
It seems that there are a number of things that need to fit together:
The remote repository (on GitHub)
The local repository (somewhere on my filesystem)
The Git working directory
The Eclipse project that I want to work in (including stuff outside the source tree like Eclipse project files, Maven config, build folders etc.)
How do these relate to each other and what should be my workflow?
In particular:
Do I actually need a local repository or can I just work directly with the remote repository (like with SVN)?
Can the Git working directory also be the Eclipse project? Or is this a bad idea?
What should my workflow of push/pull/fetch etc. normally be?
If I use Maven for dependency management in the Eclipse project, but don't want all the Maven-specific stuff to get committed to SCM, can this work?
Guess I'm loking for some sound advice from someone who's successfully made this work!
Do I actually need a local repository or can I just work directly with the remote repository (like with SVN)?
Git is all about working on a local repository and pushing elsewhere when necessary.
Can the Git working directory also be the Eclipse project? Or is this a bad idea?
If it lines up this way, then yes. This is how I've managed my projects.
What should my workflow of push/pull/fetch etc. normally be?
You push when you feel you have made enough commits (sometimes only 1) that are worth pushing. You pull when you want to work with changes that other people have pushed.
See gitworkflows for the official doc on different types of workflows.
If I use Maven for dependency management in the Eclipse project, but don't want all the Maven-specific stuff to get committed to SCM, can this work?
Usually you just commit the pom.xml. Anything else is a user specific setting. Although, if I clone your repository and can't do a "mvn compile", then there's something wrong.