Eclipse luna with nuwen: Toolchain “MinGW GCC” is not detected

安装完最新版(luna)的eclipse cpp(或eclipse java with cdt plugin)和nuwen后,新建c++ project并没有显示支持mingw toolchain. 打开属性有所提示“Toolchain “MinGW GCC” is not detected”。

而之前的一些eclipse版本是支持的,且没有任何特殊配置。

通过eclipse源码分析可知:新的eclipse由简单的check mingw的路径存在与否改变成check对应32版本的mingw32-gcc.exe和对应64版本的x86_64-w64-mingw32-gcc.exe,而nuwen安装之后存在的仅仅是gcc.exe,将此文件复制成对应的文件名即可呈现支持mingw toolchain.所以这个问题是由eclipse本身的代码改变所引起,与其他无关。

同时从源码可以看出,eclipse 32仅匹配mingw 32,而eclipse 64可以匹配mingw 32和mingw 64.

MinGW 定位的全部源码

新版本的eclipse源码:


	@Override
	public boolean isSupported(IToolChain toolChain, Version version, String instance) {
		IEnvironmentVariable var = new EnvironmentVariableManagerToolChain(toolChain).getVariable(ENV_PATH, true);
		String envPath = var != null ? var.getValue() : null;
		return MinGW.isAvailable(envPath);
	}


}

	/**
	 * Check if MinGW is available in the path.
	 *
	 * @param envPath - list of directories to search for MinGW separated
	 *    by path separator (format of environment variable $PATH)
	 *    or {@code null} to use current $PATH.
	 * @return {@code true} if MinGW is available, {@code false} otherwise.
	 */
	public static boolean isAvailable(String envPath) {
		return isWindowsPlatform && findMingwInPath(envPath) != null;
	}

	private static String findMingwInPath(String envPath) {
		if (envPath == null) {
			// $PATH from user preferences
			IEnvironmentVariable varPath = CCorePlugin.getDefault().getBuildEnvironmentManager().getVariable(ENV_PATH, null, true);
			if (varPath != null) {
				envPath = varPath.getValue();
			}
		}

		String mingwLocation = mingwLocationCache.get(envPath);
		// check if WeakHashMap contains the key as null may be the cached value
		if (mingwLocation == null && !mingwLocationCache.containsKey(envPath)) {
			// Check for MinGW-w64 on Windows 64 bit, see http://mingw-w64.sourceforge.net/
			if (Platform.ARCH_X86_64.equals(Platform.getOSArch())) {
				IPath gcc64Loc = PathUtil.findProgramLocation("x86_64-w64-mingw32-gcc.exe", envPath); //$NON-NLS-1$
				if (gcc64Loc != null) {
					mingwLocation  = gcc64Loc.removeLastSegments(2).toOSString();
				}
			}

			// Look for mingw32-gcc.exe
			if (mingwLocation == null) {
				IPath gccLoc = PathUtil.findProgramLocation("mingw32-gcc.exe", envPath); //$NON-NLS-1$
				if (gccLoc != null) {
					mingwLocation = gccLoc.removeLastSegments(2).toOSString();
				}
			}
			mingwLocationCache.put(envPath, mingwLocation);
		}

		return mingwLocation;
	}

旧版本eclipse代码:


public class MingwIsToolChainSupported implements IManagedIsToolChainSupported {
	@Override
	public boolean isSupported(IToolChain toolChain, Version version, String instance) {
		// Only supported if we can find the mingw bin dir to run the compiler
		return MingwEnvironmentVariableSupplier.getBinDir() != null;
	}

Open source: xcov

Project :    https://code.google.com/p/xcov/

Short introduce:   enhance lcov-to-cobertura-xml to support converting gcov to coberuta and working with svn diff

Open source project lcov-to-cobertura-xml provide converting the lcov data to cobertura xml so that it can be easier integrated with Jenkins.

Thus, we have to handle the gcov data at first instead of lcov sometimes, What’s more, we only want to generate code coverage with svn code diff. So this tool enhance the lcov-to-cobertura-xml to support convert gcov data or work with svn diff file base on keeping the old features available.

Basic Usage:

Converts LCOV coverage data to Coberturacompatible XML for reporting. By default, XML output will be written to ./coverage.xml

xcov.py lcovfile.info
xcov.py lcov-file-1.info lcov-file-2.info
xcov.py lcov-file.info -s svndiffFilePath
xcov.py lcovfile.info -a srcPath:gcdaPath
xcov.py -a srcPath:gcdaPath
xcov.py lcovfile.info b src/dir e test.lib o path/out.xml

Options:

-h, –help show this help message and exit -b BASE_DIR, –base-dir=BASE_DIR

Directory where source files are located

-e EXCLUDES, –excludes=EXCLUDES

Comma-separated list of regexes of packages to exclude

-a SRCDSTPAIRS, –srcdstPairs=SRCDSTPAIRS

add src:dst path, the src path is source code path, the dst path is gcda/gcno path

-o OUTPUT, –output=OUTPUT

Path to store cobertura xml file

-w, –web

create html report

-d, –delete

delete the copied gcov data

-s, –svndiff

Path to store svn diff file path

By default

(1) gcdaPath=gcnoPath=objsPath

(2) XML output will be written to ./coverage.xml

(3) svndiffFilePath can be generated by svn diff command with option –summarize such as: svn diff -r {2014-05-01}:{2014-05-10} src/ –summarize > svndifffile.txt

Jenkins’ remote build methods

某些场景下,我们需要远程执行一个job, 例如和其他工具做集成时,符合某个条件之时立即触发job。涉及远程执行的帮助文档可以随意寻找一个job的url然后加上/api(例如http://[jenkins dns]/job/jobName/api)来获取帮助,按照是否启动security可以划分为两类情况:

1 未启动security

直接发Post请求    POST  http://[jenkins dns]/job/jobName/build

可使用工具curl来执行POST:

curl -X POST http://[jenkins dns]/job/jobName/build

2 启动security

2.1   不带用户名:令牌方式

(1)  在Build Trigger设置授权Token:例如设置为1234567890

111_2

(2) 使用POST请求  POST  http://[jenkins dns]/job/jobName/build?token=1234567890

 

 2.2  带用户名:curl等工具方式:

上面的方式无法看到是具体哪个用户执行的build, 所以可以采用curl的方式执行(类似的工具还有wget,但是本文未尝试),不过缺点是curl不定在每个操作系统上都配备(Windows默认没有)

加上用户名和密码使用方式如下:

curl -X POST http://username:password@ci.jenkins.com/job/jobName/build

执行之后可以看到由具体用户start.
Started by user jiafu
[EnvInject] - Loading node environment variables.
Building remotely on TA-Win7-64-07 in workspace c:/autotest/workspace/jobName
Finished: SUCCESS
2.3  带用户名:代码方式

可参考:https://wiki.jenkins-ci.org/display/JENKINS/Authenticating+scripted+clients

 

远程执行还有很多其他特性,比如设置过多久之后的delay,带参数等等,本文不一一列举。

 

 

Translate: 深入了解Java社区进程

Java语言发展初期,Sun Microsystems公司清楚意识到:Java若想成功,必须由社区需求驱动起来。正因如此,Java社区进程(JCP)得以建立。时至今日,JAVA语言推出已有17个年头,而JCP也建设了14年。目前JCP仍然发展良好。

JCP执行委员会监管JCP及JCP驱动下Java技术本身的发展和演化。现在有两个执行委员会,分别面向Java SE/EE和Java ME,计划在未来两年合并。

每个执行委员一般会由16名成员构成,包括:技术提供商,如Oracle、IBM和诺基亚;技术使用者,如瑞士信贷和高盛投资公司;Java用户组,例如巴西和伦敦用户组;个人,例如Werner Keil。

参与JCP必须先成为执行委员会一员并签署Java规范参与协议(JSPA)(更多参与JCP的相关信息参考www.jcp.org/en/participation/membership)。JCP赋予个人、组织和公司成员主持或参与Java规范请求(JSR)的权利。JSR是JCP完善自身或在Java领域引入新技术的流程。例如:Java相关的JSR就包括JSR 335 (Lambda项目),JSR 310 (时间、日期API), JSR 337(Java 8).以及上面提到的合并两个执行委员会的JSR 355

执行委员会会议一般是月度会议。除了三次面向全球、自愿参与的面对面会议,大多数会议都采用电话会议形式。下次会议定于9月份在捷克共和国首都布拉格市由德国电信主持召开。详情可查看JCP会议完整的日程表 jcp.org/en/whatsnew/calendar。

这次月度会议是2012年7月31日。

Java ME执行委员会需要参加的会议较少,这可能是Java ME地位被削弱所致。究其原因,在于移动应用中iOS本地应用程序和基于Java的可替代它的Andorid等的影响日益提高。

随着会议不断召开,一些JSR目前的阶段是:

JSR 359 (SIP Servlet):于昨天投票截至;

JSR 358 (Revisions to JCP);7月份投票截至;

JSR 340 (Java Servlet 3.1 Spec):进入初步草案审阅阶段;

JSR 341 (Expression Language 3.0 for JSP’s);投票在今天开始;

JSR 355 (JCP EC Merge):已经处于公开审阅阶段,最终草案已经制定,最终的表决投票将在今天开始。

2011年10月制定的JCP执行委员会成员规章V 2.1(The JCP EC Standing Rules 2.1)规定:出席的定义是成员出席面对面会议。规章同时也规定:如果一个成员连续两次缺席会议将失去选举权;12个月内连续缺席2/3的会议将取消成员资格。

SK电信和三星在最近8次会议中缺席了7次,已经达到上面规定提到的数量:12个月内10次会议的2/3。所以他们很可能失去成员资格。当然,JCP主管Patrick Curran可以法外开恩,但是目前来看没有什么理由如此。

Aplix的John Rizzo指出Oracle在Java Me执行委员会已经很久没有大作为。所以他们要承担部分责任,Patrick 同意把这个意见反映给Oracle。 美国电话电报公司(AT&T )也快被取消会员资格,因为前8次会议只参加了2次。如果今年再缺席一次,资格就会不保。

鉴于打印机业务是Java ME的主要应用之一,所以有传言三星的打印机部门会被重新被纳入JCP成员。

经过JSR355合并两个委员会之后,一些成员资格将被取消,具体实施计划如下:

  • 今年将除去两个重复的席位 – Oracle 和 IBM;
  • 每个新成员仅服务一年;
  • 2013年,额外减少3个候选席位和2个批准席位,所有成员都要重新参与竞争;
  • 会员任期将从3年减至2年;
  • 因为不得不换届,投票在50%以上的将获得2年任期,50%以下的一年,50%的由随机数决定。

JCP年度奖也在讨论中,提名工作在这星期结束,年度奖分为三类:

  • 年度JCP成员
  • 规范杰出主持者
  • 最重要Java规范请求

获奖者名单将在2012年10月2日三番市召开的JavaOne会议上公布。JCP接下来几个月的重要主题是JSR358(“JCP主要修订”)。相比较 JSR355用来处理执行委员会合并事宜,JSR358致力于简化JCP,让JCP更易吸纳成员,简化主要针对的是JSPA。经常有很多抱怨指出JSPA 是一份充满威胁感的合法协议,以至于很多只是想自由参与其中的成员觉得荒谬而无法签字。值得一提的是,正因如此,Apache软件基金会(Apache Software Foundation )和其他一些高级成员在几年前纷纷退出,详见 interview with Patrick Curran on InfoQ

目前JCP有3个层次的成员:

  1. 自由参与者: 可能去修复一些少重现的Bug;
  2. 有选举权,但是不想参与主持规范的;
  3. 规范主持者。

相对应的,JSPA将被修改成三个文档:

  1. 面向自由在线贡献者的有关条款;
  2. 面向想拥有选举权、有权利为JSR专家组(EG)服务的简单会员协议;
  3. 面向规范者主持者的完整协议。

令人担心的是:假设JSAP协议条款太宽泛,一些大公司可能因为担心在知识产权上失去控制而不想参加;但是假设太严格。他们又会觉得受”威胁“。因此现在必须平衡好这个矛盾。

假设JSPA修订成功的被大众认可,我们将在InfoQ开辟专栏论述。下次JCP执行委员会会议将在2012年9月11-12日在捷克共和国布拉格采用面对面的方式进行。

原文链接:Inside the Java Community Process


Translate: CAMP1.0 – PaaS应用程序管理的开放API

 

包括Oracle、Rackspace、Red Hat 、CloudBees在内的几个公司提出了一个针对PaaS应用程序管理的开放API。这套API让开发者可以在单一PaaS内或多个不同的PaaS间管理应用应用程序。这些PaaS实现规范不需要了解任何底层的“云”架构。

CloudBees、 Cloudsoft Corporation、Huawei、Oracle、Rackspace、Red Hat和 Software AG 已经公布 一个新的PaaS 管理API,称为CAMP(Cloud Application Management for Platforms)。

它可以让云服务提供商或用户创建管理“云”中资源的应用程序。起初的想法来源于这样的观念:“云”用户不应该需要关心虚拟机、存储或网络等低层次资源,而应该能直接访问应用程序或其组件的高层次资源。同样,用户能够用统一的管理控制台访问不同供应商提供的PaaS服务并能在不同的“云”之间轻松地传输资源。

CAMP API的构建基于HTTP/1.1,采用RESTful方式并以JSON格式传输资源。它以插件形式提供给应用程序开发环境(ADE)或应用程序管理系统,以便于开发者通过应用程序开发环境在他们自己选择的“云”内创建、上传、部署、初始化自己的应用程序。

CAMP[PDF]定义了多种资源,包括平台、平台组件、应用程序、应用程序组件。虽然都是可以通过CAMP访问的资源,但有所区别,例如云平台是完整的PaaS,而平台组件则是各式各样的服务。目前CAMP仅定义了一种这样的服务称为DbaaS (Database-as-a-Service)。

作为主要资源之一的应用程序,CAMP为其提供了贯穿整个生命周期(描述如下)的操作接口:

初始化应用程序直接按照下面的请求-响应序列执行一个POST命令:

POST /paas/asm_template/1 HTTP/1.1
Host: example.org

HTTP/1.1 201 Created
Location: http://example.org/paas/assembly/1
Content-Type: ...
Content-Length: ...

而暂停一个应用程序或许可以按照下面示例:

POST /<assembly-resource-url> HTTP/1.1
Host: example.org
Content-Type: application/vnd.org.example.PaaS +json;type=Xxxxx
Content-Length: ...
{"new_state": "suspend"}
HTTP/1.1 200 OK

为标准化,CAMP已经被提交给OASIS,这其中包括一个关于技术委员会的提议章节,以期作为未来18个月内采用的标准。CAMP的构建中Oracle参与最多,14个规范中有7个规范的作者都是Oracle的。

查看英文原文CAMP 1.0 – An Open API for PaaS Application Management