What can be improved ? Fist of all, current implementation whenever it is asked for members of particular folder it opens repository* and read data directly from it. Of course there is a cashing mechanism, but it is only on single resource level. Therefore when you are launching synchronization on repository that have about 300 folders, current implementation will create and configure 300 connections* to repository to read data and then will cache it.

So, my idea was to create only one connection*, read all data at once and put them into global cache. This cache will be used whenever any list of members for given folder will be required. This approach gives about 2.5x performance boost to synchronization (from 1m 40s down to 40s). This result looks much better and maybe on HDD this action will take less then 2 minutes … but this isn’t over

Reading members of folder is one thing, but getting information about particular file (it is changed, added or removed and does this change is incoming, outgoing or conflicting) is another. Currently we are reusing default implementation of SyncInfo class from Team Framework. This is really good implementation … when you cannot obtain such information from version control system. In Git  we have SHA-1 for each file and folder version and we didn’t have to compare file contents to check they are similar or not, comparing SHA-1 is sufficient. This should save lots of CPU time, disk IO’s and developer time waiting for synchronization to finish .

Now when I already have cache that contains list of all changed resources it was natural thing to add information about change type to it. Then whenever Team Framework need to know change type it can be easily obtained from this cache … no IO’s are needed, no comparison just read from in-memory-cache and return proper value.

I’m sure that you are wondering how fast synchronization can be now … I can only that it is REALLY fast … as you can remember my stating point was 1m 40s, now same comparison will finish in less than 7s!! This means that now synchronization will be 14 times faster then before! What this means for a regular user? Well, it meas that you will get results of ‘Synchronize Workspace‘ action almost instantly.

Unfortunately, mentioned above changes are sill awaiting for review in gerrit, you can grab them from change #3891 and build it locally. I hope this will be included in 1.1 release …

* jgit uses concept of walks (with filters) through repository, but I’ve used more commonly recognized terminology here

As usually on ours meeting there would be drawing of licenses for JRebel and InteliJ Idea. This time we have also cool Java7 T-Shirts for all attendees.

Registration isn’t required but it would be nice if you can join this event on facebook (here you can also find mode details about this event).

This is a first from a series of lectures about Dependency Injection in java by Kazik. The next one will cover Gin, dependency injection library for GWT based on Guice.

If you are interested in those topics feel free to join us 28th of April (more detailed information about time and place you can find on poster above).

Now when I’m looking on my ohloh account I’m quite surprised  with my contribution size. Currently it shows 127 commits and almost 18000 code lines changed.  For me those statistics are something that I can be proud of

We’ll see what next year will bring ;>

In this post I’ll present simple Android application that will have Maven and Guice support.

1. Eclipse, Android and Maven

I assume that you already have installed and configured ADT and m2eclipse plugins. To have it working properly we need to install m2eclipse-android-integration from theirs update site:

http://m2eclipse-android-integration.googlecode.com/svn/trunk/com.byluroid.eclipse.maven.android.update/

2. Create a simple android project

Using Android project creator create new project and create a pom.xml file and configure maven-android-plugin. Here is a sample minimal pom.xml:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                               http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.luksza.android</groupId>
  <artifactId>exampleapplication</artifactId>
  <version>0.0.1-SNAPSHOT</version>
<packaging>apk</packaging>
  <name>ExampleApplication</name>
 
  <dependencies>
    <dependency>
      <groupId>com.google.android</groupId>
      <artifactId>android</artifactId>
      <version>1.5_r3</version>
    </dependency>
  </dependencies>
 
  <build>
    <sourceDirectory>src</sourceDirectory>
<plugins>
<plugin>
        <groupId>com.jayway.maven.plugins.android.generation2</groupId>
        <artifactId>maven-android-plugin</artifactId>
        <version>2.6.0</version>
        <configuration>
          <sdk>
<path>${path-to-android-sdk}</path>
<platform>3</platform>
          </sdk>
        </configuration>
        <extensions>true</extensions>
      </plugin>
<plugin>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.5</source>
          <target>1.5</target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

Remember replace ${path-to-android-sdk} with proper path. After that there are only two things that should to be done. From project context menu and select “Maven” -> “Enabled dependency management” and secondly “Maven” -> “Update project configuration” and remove standard JRE library from project build path.
That was quite simple isn’t it? There is one additional thing worth to notice, if yours application would be using Google Maps API you should use project maven-android-sdk-deployer to automatically install proper jar’s in local m2 repository. Whole installation process is described in README.markdown file.

3. Android and Guice

Now when we have enabled dependency management we can add some dependencies . First of all we will need Guice 2.0 without AOP (we cannot use Aspect Oriented Programming on Android). Because this jar isn’t available in any known maven repository we should download it from Guice download site and install it in our local repository:

mvn install:install-file -Dfile=./guice-2.0-no_aop.jar -DgroupId=com.google.inject\
      -DartifactId=guice-no_aop -Dversion=2.0 -Dpackaging=jar -DgeneratePom=true

after that we can add new dependency to ours pom.xml

<dependency>
  <groupId>com.google.inject</groupId>
  <artifactId>guice-no_aop</artifactId>
  <version>2.0</version>
</dependency>

Theoretically we can use Guice without any addons … but using Roboguice we can achieve lots more than simple dependency injection eg. using @InjectView and @InjectResource we can easily inject views and resources without casts. Also there are preconfigured Guice modules that have configured standard bindings. To add Roboguice into ours project first we should define new repository from with it will be donloaded

<repositories>
  <repository>
    <id>maven2-repository.dev.java.net</id>
    <name>Java.net Repository for Maven</name>
    <url>http://download.java.net/maven/2/</url>
  </repository>
</repositories>

Secondly the dependency should be also added

<dependency>
  <groupId>roboguice</groupId>
  <artifactId>roboguice</artifactId>
  <version>1.1-SNAPSHOT</version>
</dependency>

To have everything working we should create new class eg. ExampleApplication that will extend roboguice.application.RoboApplication

package org.luksza.android;
 
import roboguice.application.RoboApplication;
 
public class ExampleApplication extends RoboApplication {
 
	@Override
	protected void addApplicationModules(List<Module> modules) {
	}
 
}

In method addApplicationModules we can add any module that extends com.google.inject.Module. In our example we don’t need to add any extra module. Next we should edit AndroidManifest.xml file and change line

<application android:icon="@drawable/icon" android:label="@string/app_name">

into

<application android:icon="@drawable/icon" android:label="@string/app_name" android:name=".ExampleApplication">

If we would like to benefit from @InjectView or @InjectResource annotation our activity class should extends roboguice.activity.RoboActivity instead of android.app.Activity. It is very important to notice that any injection can occur after setContentView() method is called. Therefor we cannot inject main activity layout! Here is an example ExampleActivity class that have injected button:

package org.luksza.android;
 
import roboguice.activity.RoboActivity;
import roboguice.inject.InjectView;
import android.os.Bundle;
import android.widget.Button;
 
public class ExampleActivity extends RoboActivity {
	@InjectView(R.id.Button)
	Button button;
 
	/** Called when the activity is first created. */
	@Override
	public void onCreate(final Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		setContentView(R.layout.main);
 
		button.setText("Injected button");
	}
}

That is all I want to share with you. I’ve hope that this information would be useful for you

Current implementation shows Git Change Set next to “normal change set”. In my humble opinion this should be changed in the feature; Git Change Set view should be set as default view for synchronization for git, because in git we track changes on repository level and cannot import only part of commit. Above Git Change Set we have node that represent repository, if we launch synchronization for more then one repository there would be more nodes on this level. Inside repository node we have list of commits that occurs between two selected points (branches of versions). Every commit is described by text label with contains first 6 characters from commit SHA-1 and first line of commit message. Commits are sorted chronologically, most recent commits are on the top. Inside commit we have list of changes that are associated with this commit. Double click action on file element will launch ChangeEditor window with will display changes that were made between two most recent commits (this one and it parent).

Here is a screenshot how it looks in real world:

It shows list of changes between current HEAD and tag v0.8.4 … from height of scrollbar in Synchronize window we can guess that upcoming 0.9.0 release will contain lots of cool new features and bug fixes ;>

Currently I didn’t manage display change direction (does it is incoming, outgoing or conflicting) I’ll work on that in nearest feature. Another think that I was unable to achieve is “proper resource handling” eg. displaying java packages as this JDT does, to be honest I don’t know that this is achievable but I’ll try … dome day . Next think is context menu and merge/commit/overwrite actions, for now didn’t even think about it, but it also should be done in nearest feature.

What is your opinion about this new feature? Maybe you see something that should be changed, removed or improved? Please, let me know … feedback is strongly appreciated!

As you can see, the “Git Change Set” appears next to the standard change set representation, this can be changed using third tool bar button (from left hand side).

Currently list of commits contains only commits between base and destination rev, the common ancestor isn’t included or even dispatched by the change set implementation (this can, or even should, be changed). Also there should be included proper graphical representations for commits, folders and files; additionally compare view should be launched when we double click on file. That things should be improved/fixed before I’ll publish code.

Beside that small issues I think that right now it is the best time to start discussion how we (yes, me and you!) would like to use this feature and have it should behave and and look. What you can see in above screen shot is only my proposition and (as always) I’m open for any suggestions and ideas. The best place for this discussion is Eclispe’s Bugzilla and bug 318473, and I encourage you to share yours opinion with us!

I’m looking forward for any feedback about this feature

BTW. One of thins that I’m proud of, in current implementation, is that I haven’t use any kind of internal API of Team Framework ;>

But for me it is a great success, after more then a week of fighting with Team Framework API, with was actually designed for centralized version control system.

Actually this list isn’t even sorted properly, listed commits doesn’t contains any data/child  … but I think that right now things should goes faster then it was before, because I think that I’ve got idea of change set’s.

What should be done? All commit’s should be assigned to root node with should represent repository (this is in  case if someone will be synchronizing multiple repositories at a same time). Commit’s should contains list of changes with proper path representation: project (if it is included in this repository), folder (and java packages if it is a java project) and finally files that was changed in this particular commit.

The next step of integration would be to make it more “git” way. In this case all changes should be spited into proper commits, because in Git we track changes on repository level (not on file level) and every commit leads us from one consistent state to another. In this case, synchronize view should show list of commits (first 4-6 characters of each SHA-1 and first line from commit message), then as a child of particular commit we should see resources that was changed by this commit. Generally all changes in particular commit should have one direction incoming or outgoing (despite conflicts that can appears on file or container level inside commit). Also merge operation should be available only on commit level.

OK, so this is how things should be handled and how they should look like … but how to achieve it?

This is quite tricky question. Thanks of bug 317934 that was made by Benjamin Muskalla I’ve started for looking information about ‘change set’ in eclipse.This leads me to ‘Team Logical Model Integration‘. According to this documentation I should almost rewrite all project … change base class of GitSynchronizationParticipant, provides implementation of IResourceMapping, ISynchornizationContext, IResourceMappingManager, etc …

The other thing that I’ve spot some time ago, is that Mercurial plug-in for Eclipse has functionally that is somehow similar with those that I’ve want to implement (they split changes into two groups: incoming and outgoing); thank god that it is open sourced . With base knowledge about ‘Eclipse Logical Model’ I’ve downloaded MercurialEclipse sources … of course using hg BTW. to download sources I was forced to create an account on javaforge.com … this is next account that I used only once … no comments for that …

When I finally get sources I’ve started inspecting how they implement change sets … and realize that they also use ‘Logical Model Integration’ … but according to comment for MercurialSynchronizeParticipant they don’t really know why they use ModelSynchronizeParticipant … why bother with that, so it is working .

So my plan for next few days is:

• migrate actual implementation of synchronization on ‘Logical Model’
• implement change sets

This looks like there will be next 1 or 2 kloc patch set o integrate into EGit …

Wish me luck … or suggest better/easier solution

Any suggestions are strongly required