방법은 여러가지가 있겠지만, 대용량 분산과 QoS를 합리적 로직으로 풀어낸 부분이 너무나 마음에 드는 구조이고, service architecture는 개인적인 경험으로 봤을 때, 인증/권한 architecture중의 하나인 PKI Infrastructure와 유사해 보인다.

LG U+ 가입자의 경우 LG U+ Google Cache로 부터 어떤 흐름으로 동영상이 다운로드 되는지 설명드리도록 하겠습니다. 먼저 LG U+ Google Cache내에 사용자가 요청한 동영상이 있는 경우(Cache Hit)의 흐름을 알아보고, 이후 동영상이 없는 경우(Cache Miss)의 흐름에 대해서 살펴 보도록 하겠습니다.

LG U+ 회선을 통한 YouTube 다운로드

(1) LG U+ Google Cache에 동영상이 있는 경우 (Cache Hit)

LG U+ 망 내부에(LG U+ IDC;Internet Data Center에) Google Cache가 들어 있다는 점 외에는 지난 시간의 KT 그림과 동일한 구성입니다.

1.LG U+ 가입자가 브라우져에서 www.youtube.com을 입력하고, 단말에서 LG U+ DNS 서버로 DNS Query를 보냅니다. 반드시 LG U+ DNS일 필요는 없습니다. 어떤 DNS 서버이든 상관 없습니다.
2.그리고 LG U+ DNS는 YouTube 서버 주소 74.125.71.136을 가입자 단말로 전달합니다.
3.가입자는 Avatar 동영상을 클릭합니다.
4.이제 HTTP GET을 통해 Avatar 동영상 요청 메시지가 YouTube 서버로 전달됩니다.
5.이 대목이 아주 중요하니다! HTTP GET 메시지를 받은 YouTube 서버는 단말의 IP 주소 대역을 확인합니다. 이 경우 동영상을 요청한 가입자의 IP 주소 대역이 LG U+입니다. 그러면 YouTube 서버는 LG U+내에 위치한 Google Cache를 선택하여
6.그 hostname(o-o.preferred.lgupluswireline-gmp1.v9.lscache5.c.youtube.com)을 가입자 단말로 전달합니다.
7.가입자 단말은 hostname에 대한 DNS Query를 하고 (역시 DNS 서버가 LG U+ 일 필요는 없음)
8.그 응답으로 IP 주소 61.36.166.12를 받아 옵니다. 이 주소는 LG U+ 내의 Google Cache 주소입니다.
9.이제 단말에서 LG U+ Google Cache로 Avatar 동영상을 요청하고
10.여기서 또 중요! LG U+ Google Cache는 다시 HTTP GET을 보낸 단말의 IP 주소 대역을 확인합니다. 만약 이 주소 대역이 LG U+ 가입자 대역이 아니면 HTTP 302 Found 메시지를 단말로 보내어 미국에 있는 Google Cache로 붙도록 합니다(HTTP Redirect). 즉, 내 가입자 아니면 안받아 주겠다는 거죠. 위 경우는 LG U+ 가입자이므로 밑에 11번 단계로 넘어가게 됩니다.
11.이제 LG U+ Google Cache는 가입자가 요청한 동영상(Avatar)이 나한테 있는지(storage에 있는지) 확인합니다. 다행히 있습니다! (Cache Hit)
12.따라서 LG U+ Google Cache는 동영상을 가입자 단말로 전달합니다. RTT 10ms 이하입니다. 무지 빠르게 가입자 단말로 동영상이 전달됩니다

(2) LG U+ Google Cache에 동영상이 없는 경우 (Cache Miss)

이번 그림에서는 설명을 단순화 하기 위해 DNS flow는 제외 시켰습니다.

(2) LG U+ Google Cache에 동영상이 없는 경우 (Cache Miss)

이번 그림에서는 설명을 단순화 하기 위해 DNS flow는 제외 시켰습니다.

1.LG U+ 가입자가 YouTube 웹페이지에서 Avatar 동영상을 클릭합니다.
2.가입자 단말은 HTTP Get 메시지를 YouTube 서버로 보내고
3.YouTube 서버는 단말의 IP 주소를 확인하고, LG U+ 가입자 이므로
4.LG U+ Google Cache hostname(o-o.preferred.lgupluswireline-gmp1.v9.lscache5.c.youtube.com)을 단말로 전달합니다.
5.가입자 단말은 이제 LG U+ Google Cache로 Avatar 동영상을 요청하고,
6.LG U+ Google Cache가 단말 IP 주소를 확인하였더니 자사 가입자입니다.
7.이제 가입자가 요청한 Avatar 동영상의 캐싱 여부를 확인합니다. 그런데 그 동영상이 없습니다! (Cache Miss)
8.이제부터 시험을 통해 확인된 내용과 일부 추측을 기반으로 설명을 드리겠습니다. LG U+ Google Cache는 Avatar 동영상이 미국내 어느 Google Cache에 들어 있는지 알길이 없을 것 같습니다. 따라서 미리 configuration되어 있는 상위 Google Cache 서버로 HTTP Redirection을 시킵니다. 시험으로 확인하 결과 아래와 같이 hostname의 숫자값이 동일한 매핑 규칙을 발견할 수 있었습니다. 즉
•LG U+ Google Cache "o-o.preferred.lgupluswireline-gmp1.v9.lscache5.c.youtube.com"의 상위 Cache 서버는 -> 미국에 "v9.nonxt5.c.youtube.com"
•LG U+ Google Cache "o-o.preferred.lgupluswireline-gmp1.v12.lscache6.c.youtube.com"의 상위 Cache 서버는 -> 미국에 "v12.nonxt6.c.youtube.com"
9.가입자 단말은 LG U+ Google Cache가 알려준 v9.nonxt5.c.youtube.com으로 Avatar 동영상을 요청하고,
10.이 서버에도 해당 동영상이 없으면 다시 redirector.c.youtube.com으로 HTTP Redirection을 합니다. 추측컨데 redirector.c.youtube.com이 최상위에 위치한 서버로써 모든 동영상의 위치(어느 Cache 서버에 그 동영상이 있는지)를 관리하는 듯 합니다.
11.가입자 단말은 redirector.c.youtube.com으로 Avatar 동영상을 요청하고,
12.드디어 Avatar 동영상이 위치해 있는 Google Cache 서버의 hostname(o-o.preferred.lax04t01.v1.lscache6.c.youtube.com)을 받아 옵니다.
13.가입자 단말은 그 hostname으로 Avatar 동영상을 요청하고,
14.미국에 있는 Google Cache로 부터 동영상을 다운로드 받습니다.

여기서 그럼 LG U+ Google Cache 서버는 언제 Cache Fill을 하나? 라는 의문이 생기는데요. Cache Miss가 난 이후 다시 동일 동영상을 요청해 봤지만 여전히 미국에 있는 Google Cache로부터 다운로드 받는 것으로 보아, 각 Google Cache에는 "동일 컨텐츠를 몇번 이상 요청하면 Cache Fill한다"라는 식의 정책이 들어 있는 것으로 추측이 됩니다.

결언

위와 같이 미국에 있는 YouTube 서버 및 LG U+에 도입된 Google Cache는 HTTP GET 메시지을 보낸 단말 IP 주소 대역을 확인하여 어느 지역의 Google Cache를 통해 다운로드 받게 할지 결정합니다. 즉, KT 가입자는 KT IP 주소 대역을 사용하므로 DNS만 LG U+로 변경한다 해서 LG U+ Google Cache에 접속할 수는 없습니다. (그렇다고 KT 가입자가 단말의 IP 주소를 LG U+ 대역으로 바꾸면 라우팅이 안되어 아예 인터넷을 사용할 수 없게 되구요.)
이 말은 곧, LG U+ 가입자가 KT DNS를 사용해도 아무 문제 없이 LG U+ Google Cache를 통해 동영상을 다운로드 받게 됩니다.

마지막으로 한가지 더 말씀드리자면...
저희 회사가 LG U+ 기업용 회선을 사용하고 있습니다. 회사에서 확인을 해 보니, LG U+ 기업용 회선 가입자의 경우 LG U+ Google Cache로 부터 동영상 다운로드가 안되고, 그래도 RTT가 좀 짧은(100ms 정도) 홍콩에 위치한 Google Cache(o-o.preferred.hkg05s01.v20.lscache7.c.youtube.com)로 부터 동영상을 다운로드 받음을 확인하였습니다.
즉, 미국에 있는 YouTube 서버는
     1) LG U+ 홈 가입자 IP 대역이면 LG U+ Google Cache를 선정해 주고
     2) LG U+ 기업용 가입자 IP 대역이면 홍콩에 위치한 Google Cache를 선정
     3) 나머지 경우(예. KT IP 대역이면) 미국에 위치한 Google Cache를 선정

[소스:http://whiteafrican.com/2008/07/04/google-kenya-and-the-google-global-cache/}

[소스:http://www.netmanias.com/bbs/view.php?id=blog&no=301'

요즘 각 개발 회사마다 Global Service를 고민하면서 서비스를 기획 및 개발하고 있다. 이 때마다, 항상 고민이 되는 부분은 분산(서비스/데이타) 과 QoS 부분이다. 분산을 높이면, QoS가 낮아지는 현상이 발생하게 된다.(반대 경우도 마찬가지..) 그래서, 아이디어를 찾다가, Google과 Netflix는 어떻게 되어 있나 궁금해서 아래의 자료를 발견했는데, 매우 유용하다고 생각되어 기재합니다.

[OTT Cache(Google, Netflix)와 통신사업자 Transparent Cache - I]

Sandvine사의 Report에 따르면 2012년 하반기 북미 전체 인터넷 트래픽의 33%가 Netflix이고 15%가 YouTube로 이 두 회사의 트래픽만 합쳐도 전체의 48%로 거의 절반에 이른다. 통신사업자의 IP 네트워크는 인터넷이 아니라 두 회사의 비디오 전달망이 된 것이다.
이 두 회사의 이용자수는 계속 증가하고 있고 또한 갈수록 비디오 품질이 고화질화되어 트래픽량 (즉, 전달 비용)이 지속적으로 증가하고 있다. 통신사업자와 OTT는 각각 서로 다른 비용 최소화 전략을 취하고 있는 데 본 블로그에서는 먼저 OTT의 전략들을 살펴보기로 하자.

Google의 CDN 전략

Google은 미국과 유럽, 아시아에 13개(Google이 공식적으로 확인해준 데이터센터만 13개)의 자체 데이터 센터와 자체 CDN을 통해 YouTube 트래픽을 전세계에 전달한다. 이 소수의 데이터센터만으로는 급증하는 YouTube 트래픽을 감당하기 어렵고 또한  Google 데이터센터가 구축되어 있지 않는 나라에서는 YouTube 비디오 시청시 잦은 버퍼링이 발생하는 문제가 발생한다.
이를 해결하기 위해 Google은 2008년경부터 Google Global Cache (GGC)라는 자체 에지 서버를 통신사업자에게 무상으로 제공해주고 있다. Google은 GGC 서버 (H/W and S/W)를 통신사업자의 IDC에 설치해주고 서버 운영도 Google이 한다(원격 관리). 통신사업자는 IDC내 랙공간과 전력, GE 포트를 역시 돈을 받지 않고 Google에 제공해준다.
통신사업자는 외부망에서 유입되어오는 YouTube 트래픽이 대폭 줄어드므로 Transit 비용을 절감할 수 있고 자사 인터넷 가입자들의 "왜 다른 ISP는 YouTube가 빠른 데 우리만 느리냐?"라는 불만을 잠재울 수 있어 좋다.Google은 YouTube 이용자의 QoE를 향상시키고 보다 고화질의 비디오 서비스를 IDC 요금 걱정없이 제공할 수 있어 좋다. 서로 이득이 있으므로 서로 돈을 내지 않는다. 북미와 유럽의 대부분의 통신사업자들이 GGC를 도입하였고 우리나라도 작년 2월에 SK, LG U+, KINX에 도입되었다.
YouTube라는 기가막힌 컨텐츠를 가진 Google은 이렇게 자기 돈 안들이고 전세계 통신사업자의 망내까지 자기 CDN을 확장시키고 있다.  

Netflix의 CDN 전략

유료 가입자수가 3천만이 넘고 북미 인터넷 트래픽의 33%를 발생시키고 있는 Netflix도 Google과 동일한 전략을 취하고 있다. 하나씩 살펴보자. Netflix는 자사의 비디오를 이용자에게 전달해주기 위해 Akamai와 Limelight, Level3로부터 CDN 서비스를 받고 있고 이들에게 CDN 이용료를 지불하고 있다.
Netflix는 CDN 사업자에게 지출하는 CDN 요금이 아깝고 또 지금보다 고화질인 Full HD급의 비디오 서비스를 제공하여 보다 많은 가입자를 유치하고 싶은 데 이럴려면 CDN 사업자들에게 지금보다 더 많은 CDN 이용료를 내야 한다.
그런데 옆집을 보니 Google이 GGC를 통신사업자에게 돈 안 내고 밀어 넣고 있고 있네 ! 어 그러면 우리도 컨텐츠의 킹이니, Google처럼 하자- 하여 2012년 6월에 나온 게 Netflix Cache이다.

Netflix Cache도 GGC와 마찬가지로 OTT인 Netflix가 자체 개발한 서버로 통신사업자에게 무상으로 제공해주고 운영도 Netflix가 한다. 통신사업자는 IDC내 랙공간과 전력, GE 포트를 역시 돈을 받지 않고 Netflix에 제공해준다.
현재 미국의 Cablevision, Google Fiber, Clearwire, 캐나다의 Telus, 영국의 BT, Virgin Media, 덴마크의 TDC 그리고 중남미의 Telmex와 GVT에 Netflix Cache가 도입되어 있다(Netflix 서비스 국가). 특히 유럽의 경우는  모든 Netflix 트래픽의 글로벌 CDN이 아닌 Netflix Cache를 통해 이용자에게 전달된다.
Netlfix는 올해 1월 Full HD 화질 서비스(1920x1080, 5~7Mbps)와 3D 비디오 서비스(12Mbps)를 개시했다. Netflix 가입자는 추가 요금없이 고화질 서비스를 이용할 수 있다.  재미있는 것은 이 고화질 서비스가 Netflix Cache가 도입된 통신사업자의 가입자에게만 제공된다는 점이다.
통신사업자의 Netflix Cache 도입을 촉진시키려는 (그럼으로써 CDN 요금을 절감시키고 통신사업자에게 IDC 요금도 안내면서 고화질 서비스를 제공하려는) 의도이다.

 이 서비스가 출시되자 Time Warner Cable은 Netflix Cache가 도입되지 않은 통신사업자의 가입자에게도 동일하게 Full HD와 3D 서비스를 제공해야 한다며 불만을 터트리고 있다.
그 동안은 통신사업자의 망중립성에 대한 논쟁이 활발했는 데 꺼꾸로 OTT가 통신사업자별로 컨텐츠를 차별적으로 제공하면 안되지 않느냐는 컨텐츠 중립성 이슈가 나온 것이다.
칼자루가 통신사업자에서 OTT로 넘어간...

하여튼 Netflix도 Google과 마찬가지로 자기 돈 안들이고 세계 각국의 통신사업자의 망내까지 자기 CDN을 확장시키고 있다.
대표적인 OTT인 YouTube와 Netflix가 자신들의 막강한 컨텐츠, 이용자 수를 무기로 자기 Cache를 각국의 통신사업자망내에 진입시키고 있다. 한편 걱정스러운 것은 OTT의 트래픽을 통신사업자망내에 캐싱하여 네트워크 비용을 줄이고 신규 수익원을 만들려고 생겨난 통신사업자 CDN과 Transparent Cache의 시장이 축소될 수 있다는 점이다.
통신사업자 CDN과 Transparent Cache는 국내외 벤더들이 개발하여 통신사업자에게 공급함으로써 벤더들에게 매출 발생의 희망이 있고 또 통신사업자도 망내 CDN을 구축하여 OTT로부터 CDN 이용료를 받을 수 있지만 YouTube와 Netflix가 자사의 Cache를 통신사업자망에 밀어넣으면 OTT를 빼고는 아무도 돈 버는자는 없다.

[소스: http://www.netmanias.com/bbs/view.php?id=blog&no=367]

Tutorial: Hello World with Apache Ant

This document provides a step by step tutorial for starting ava programming with Apache Ant. It does not contain deeper knowledge about Java or Ant. This tutorial has the goal to let you see, how to do the easiest steps in Ant.

Content

• Preparing the project
• Enhance the build file
• Enhance the build file
• Using external libraries
• Resources

Preparing the project

We want to separate the source from the generated files, so our java source files will be in src folder. All generated files should be under build, and there splitted into several subdirectories for the individual steps: classes for our compiled files and jar for our own JAR-file.

We have to create only the src directory. (Because I am working on Windows, here is the win-syntax - translate to your shell):

md src

The following simple Java class just prints a fixed message out to STDOUT, so just write this code into src\oata\HelloWorld.java.

package oata;

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello World");
    }
}

Now just try to compile and run that:

md build\classes
javac -sourcepath src -d build\classes src\oata\HelloWorld.java
java -cp build\classes oata.HelloWorld

Hello World

Creating a jar-file is not very difficult. But creating a startable jar-file needs more steps: create a manifest-file containing the start class, creating the target directory and archiving the files.

echo Main-Class: oata.HelloWorld>myManifest
md build\jar
jar cfm build\jar\HelloWorld.jar myManifest -C build\classes .
java -jar build\jar\HelloWorld.jar

Note: Do not have blanks around the >-sign in the echo Main-Class instruction because it would falsify it!

Four steps to a running application

After finishing the java-only step we have to think about our build process. We have to compile our code, otherwise we couldn't start the program. Oh - "start" - yes, we could provide a target for that. We should package our application. Now it's only one class - but if you want to provide a download, no one would download several hundreds files ... (think about a complex Swing GUI - so let us create a jar file. A startable jar file would be nice ... And it's a good practise to have a "clean" target, which deletes all the generated stuff. Many failures could be solved just by a "clean build".

By default Ant uses build.xml as the name for a buildfile, so our .\build.xml would be:

<project>

    <target name="clean">
        <delete dir="build"/>
    </target>

    <target name="compile">
        <mkdir dir="build/classes"/>
        <javac srcdir="src" destdir="build/classes"/>
    </target>

    <target name="jar">
        <mkdir dir="build/jar"/>
        <jar destfile="build/jar/HelloWorld.jar" basedir="build/classes">
            <manifest>
                <attribute name="Main-Class" value="oata.HelloWorld"/>
            </manifest>
        </jar>
    </target>

    <target name="run">
        <java jar="build/jar/HelloWorld.jar" fork="true"/>
    </target>

</project>

Now you can compile, package and run the application via

ant compile
ant jar
ant run

Or shorter with

ant compile jar run

While having a look at the buildfile, we will see some similar steps between Ant and the java-only commands:

Enhance the build file

Now we have a working buildfile we could do some enhancements: many time you are referencing the same directories, main-class and jar-name are hard coded, and while invocation you have to remember the right order of build steps.

The first and second point would be addressed with properties, the third with a special property - an attribute of the <project>-tag and the fourth problem can be solved using dependencies.

Buildfile: build.xml

clean:

compile:
    [mkdir] Created dir: C:\...\build\classes
    [javac] Compiling 1 source file to C:\...\build\classes

jar:
    [mkdir] Created dir: C:\...\build\jar
      [jar] Building jar: C:\...\build\jar\HelloWorld.jar

run:
     [java] Hello World

main:

BUILD SUCCESSFUL

Using external libraries

Somehow told us not to use syso-statements. For log-Statements we should use a Logging-API - customizable on a high degree (including switching off during usual life (= not development) execution). We use Log4J for that, because

• it is not part of the JDK (1.4+) and we want to show how to use external libs
• it can run under JDK 1.2 (as Ant)
• it's highly configurable
• it's from Apache ;-)

We store our external libraries in a new directory lib. Log4J can be downloaded [1] from Logging's Homepage. Create the lib directory and extract the log4j-1.2.9.jar into that lib-directory. After that we have to modify our java source to use that library and our buildfile so that this library could be accessed during compilation and run.

Working with Log4J is documented inside its manual. Here we use the MyApp-example from the Short Manual [2]. First we have to modify the java source to use the logging framework:

package oata;

import org.apache.log4j.Logger;
import org.apache.log4j.BasicConfigurator;

public class HelloWorld {
    static Logger logger = Logger.getLogger(HelloWorld.class);

    public static void main(String[] args) {
        BasicConfigurator.configure();
        logger.info("Hello World");          // the old SysO-statement
    }
}

Most of the modifications are "framework overhead" which has to be done once. The blue line is our "old System-out" statement.

Don't try to run ant - you will only get lot of compiler errors. Log4J is not inside the classpath so we have to do a little work here. But do not change the CLASSPATH environment variable! This is only for this project and maybe you would break other environments (this is one of the most famous mistakes when working with Ant). We introduce Log4J (or to be more precise: all libraries (jar-files) which are somewhere under .\lib) into our buildfile:

<project name="HelloWorld" basedir="." default="main">
    ...
    <property name="lib.dir"     value="lib"/>

    <path id="classpath">
        <fileset dir="${lib.dir}" includes="**/*.jar"/>
    </path>

    ...

    <target name="compile">
        <mkdir dir="${classes.dir}"/>
        <javac srcdir="${src.dir}" destdir="${classes.dir}" classpathref="classpath"/>
    </target>

    <target name="run" depends="jar">
        <java fork="true" classname="${main-class}">
            <classpath>
                <path refid="classpath"/>
                <path location="${jar.dir}/${ant.project.name}.jar"/>
            </classpath>
        </java>
    </target>

    ...

</project>

In this example we start our application not via its Main-Class manifest-attribute, because we could not provide a jarname and a classpath. So add our class in the red line to the already defined path and start as usual. Running ant would give (after the usual compile stuff):

[java] 0 [main] INFO oata.HelloWorld  - Hello World

What's that?

• [java] Ant task running at the moment
• 0 sorry don't know - some Log4J stuff
• [main] the running thread from our application
• INFO log level of that statement
• oata.HelloWorld source of that statement
• - separator
• Hello World the message

log4j.rootLogger=DEBUG, stdout

log4j.appender.stdout=org.apache.log4j.ConsoleAppender

log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%m%n

    ...
    <target name="compile">
        <mkdir dir="${classes.dir}"/>
        <javac srcdir="${src.dir}" destdir="${classes.dir}" classpathref="classpath"/>
        <copy todir="${classes.dir}">
            <fileset dir="${src.dir}" excludes="**/*.java"/>
        </copy>
    </target>
    ...

public class HelloWorldTest extends junit.framework.TestCase {

    public void testNothing() {
    }
    
    public void testWillAlwaysFail() {
        fail("An error message");
    }
    
}

Because we dont have real business logic to test, this test class is very small: just show how to start. For further information see the JUnit documentation [3] and the manual of junit task. Now we add a junit instruction to our buildfile:

    ...

    <target name="run" depends="jar">
        <java fork="true" classname="${main-class}">
            <classpath>
                <path refid="classpath"/>
                <path id="application" location="${jar.dir}/${ant.project.name}.jar"/>
            </classpath>
        </java>
    </target>
    
    <target name="junit" depends="jar">
        <junit printsummary="yes">
            <classpath>
                <path refid="classpath"/>
                <path refid="application"/>
            </classpath>
            
            <batchtest fork="yes">
                <fileset dir="${src.dir}" includes="*Test.java"/>
            </batchtest>
        </junit>
    </target>

    ...

We reuse the path to our own jar file as defined in run-target by giving it an ID. The printsummary=yes lets us see more detailed information than just a "FAILED" or "PASSED" message. How much tests failed? Some errors? Printsummary lets us know. The classpath is set up to find our classes. To run tests the batchtest here is used, so you could easily add more test classes in the future just by naming them *Test.java. This is a common naming scheme.

After a ant junit you'll get:

...
junit:
    [junit] Running HelloWorldTest
    [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 0,01 sec
    [junit] Test HelloWorldTest FAILED

BUILD SUCCESSFUL
...

We can also produce a report. Something that you (and other) could read after closing the shell .... There are two steps: 1. let <junit> log the information and 2. convert these to something readable (browsable).

    ...
    <property name="report.dir"  value="${build.dir}/junitreport"/>
    ...
    <target name="junit" depends="jar">
        <mkdir dir="${report.dir}"/>
        <junit printsummary="yes">
            <classpath>
                <path refid="classpath"/>
                <path refid="application"/>
            </classpath>
            
            <formatter type="xml"/>
            
            <batchtest fork="yes" todir="${report.dir}">
                <fileset dir="${src.dir}" includes="*Test.java"/>
            </batchtest>
        </junit>
    </target>
    
    <target name="junitreport">
        <junitreport todir="${report.dir}">
            <fileset dir="${report.dir}" includes="TEST-*.xml"/>
            <report todir="${report.dir}"/>
        </junitreport>
    </target>

Because we would produce a lot of files and these files would be written to the current directory by default, we define a report directory, create it before running the junit and redirect the logging to it. The log format is XML so junitreport could parse it. In a second target junitreport should create a browsable HTML-report for all generated xml-log files in the report directory. Now you can open the ${report.dir}\index.html and see the result (looks something like JavaDoc).
Personally I use two different targets for junit and junitreport. Generating the HTML report needs some time and you dont need the HTML report just for testing, e.g. if you are fixing an error or a integration server is doing a job.

if you get this problem, Just Clean your the existing project  and re-compile, that's it!!!

Searched by Google, most of answers for this “An SDK Target must be specified” problem showed that I should go to “Windows->Android SDK and AVD Manager” in Eclipse and click on “Installed Packages” and then “Update All”. But that’s not my problem, I have used the Eclipse to program with Android long ago and every thing is OK till today. So I continued to search and finally on the Rowan Crane’s Blog I found the resolved method, it is just to change the font size in Eclipse:

Window / Preferences / General / Appearance / Basic / Colours and Fonts

Change “Text Font” and “Dialog Font” to a smaller value, dropping from 10 to 8 or smaller number maybe helped.

[Source URL : http://blog.rowancrane.com/2009/12/27/eclipse-new-android-project-cant-select-build-type-target]


is caused a good 30 mins head scratching. When creating a new Android project in Eclipse it is not possible to progress past the initial screen as it complains “an SDK target must be specified”.  In the window you will see “Build Target” but no box listing your installed Android Versions. The area of the window normally looks something like this.

But for unlucky you, it looks like this.

Providing you know Eclipse is aware of where your SDKs live, the solution is simply to change the font size in eclipse.

Window / Preferences / General / Appearance / Colours and Fonts

Change “Text Font” and “Dialog Font” to a smaller value, dropping from 10 to 8 helped me.

Now for the rant: The “New Android Test Project” dialogue does not suffer this problem, because there aren’t as many UI elements on screen. It wouldn’t surprise me if this is a simple code error somewhere, exacerbated by the fact that most developers aren’t working on “funny” resolutions, such as my widescreen 13″ XPS M1210 Laptop.

Simply put you’d hope the application would ensure all UI components were properly displayed. At the end of the day such schoolboy-error fiddly problems are what put people off IT and software development. There seem to be a fair few people moaning about this one, so whilst buuuuuuuuugs happen I hope someone somewhere is suitably embarrassed…