|
#
插件依赖只能是单向的关系，比如说PluginA依赖于PluginB，那么A中能引用B中的类，但是B就不能引用A中的 ，否则就是双向依赖。在使用XStream这个包的时候，如果是不可能单独封装为一个插件的。这就造成了多个插件含有不同版本的Stream类。
Plugin.properties放在plugin.xml的相同目录下, Eclipse里面看国际化也是非常正确,
但是运行以后就是只显示"%XXXX"这样的字符串原来是因为
Localization in RCP plugins is usually
done by including translations in a property file and using their id in
plugin.xml.
I spend some time lately trying to
understand why some translations were not used in my application although they
were correctly displayed in PDE.
Answer : when using
plugin.properties, you MUST include the following line in the plugin
manifest :
Bundle-Localization:
plugin
Otherwise, PDE will show the translated
text, but your app won’t.
Strangely, I had to edit the manifest
manually because I couldn’t find a way to enable plugin localization in PDE.
Some other plugins of my application already had this line, but I don’t remember
adding it. Maybe Eclipse templates have changed since I created my first
plugins (using Eclipse 3.1).
记得以前插件开发也有这个问题，不过忘记了。
真是记性越来越差了。
这个问题竟然困扰了我两个星期。还好可以google到别人的解决办法，今天在这里留个脚印。
1.关于接口中声明的变量
public interface In {
/*public static final*/ int a = 0;
}
public class TestIn implements In{
/**
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub
int i=0;
TestIn t = new TestIn();
i = t.a;
i = In.a;
i = TestIn.a;
}
}
2.Exception
public class LException extends Exception{
}
public class HException extends LException{
}
public class TestException {
/**
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub
try{
throw new HException();
}catch(HException ex){
}catch(LException e){
}
}
}
如果在插件MANIFEST.MF中的Bundle-ClassPath设置了 “.”那就会导出生成为一个jar 文件。否则就是目录形式。
打包好的程序,发现在运行的时候和开发时候的表现不一致,仅仅靠推理很难发现问题,有没有办法调试呢?记得以前曾经做过远程调试Jboss,大致原理应该相通的,照样做了一下,果然行的通.
首先需要在运行RCP程序的时候增加如下参数:
-Xdebug
-Xnoagent
-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n
运行RCP程序.
然后再使用Eclipse的远程应用程序调试方式运行:
设置好断点后
就可以像开发时候一样来进行跟踪调试.很容易找出问题来.
// 用泛型实现通用数组的删除操作
package test;
import java.lang.reflect.Array;
import java.util.ArrayList;
import java.util.List;
public class Test1 {
public static <T> T[] deleteArray(T[] items,int index) {
if (items == null || items.length == 0 || index < 0
|| index > items.length - 1) {
return items;
}
T[] newItems = (T[]) Array.newInstance(items.getClass().getComponentType(), items.length - 1);
if(index == 0){
// first
System.arraycopy(items, 1, newItems, 0, newItems.length);
}else if(index == items.length - 1){
// end
System.arraycopy(items, 0, newItems, 0, newItems.length);
}else{
// middle
System.arraycopy(items, 0, newItems, 0, index);
System.arraycopy(items, index+1, newItems, index, items.length - index -1);
}
return newItems;
}
/**
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub
// first
String[] first = new String[]{"0","1","2"};
String[] rt = deleteArray(first,0);
printArray(rt);
// end
Integer[] end = new Integer[]{0,1,2};
Integer[] rt1 = deleteArray(end,2);
printIntegerArray(rt1);
}
public static void printArray(String[] array){
System.out.println("start ====================");
for(String s:array){
System.out.println(s);
}
System.out.println("end ====================");
List<String> a = new ArrayList<String>();
}
public static void printIntegerArray(Integer[] array){
System.out.println("start ====================");
for(Integer s:array){
System.out.println(s);
}
System.out.println("end ====================");
List<String> a = new ArrayList<String>();
}
}
我经常发现代码里面充次着一些“画蛇添足”的想法，尤其是MM写的代码，这好像就是因为思考停留在表面，不能深入到事物的本质造成的。因为她们在考虑问题的时候会将80%的精力放在表面，而用20%的精力来思考低层的实现。奥萨姆剃刀可以解决这个问题。
奥卡姆剃刀（Occam's Razor, Ockham's
Razor），又称“奥康的剃刀”，是由14世纪逻辑学家、圣方济各会修士奥卡姆的威廉（William of
Occam，约1285年至1349年）提出。奥卡姆（Ockham）在英格兰的萨里郡，那是他出生的地方。他在《箴言书注》2卷15题说“切勿浪费较多
东西去做用较少的东西同样可以做好的事情。”
这个原理称为“如无必要，勿增实体”（Entities should not be multiplied unnecessarily）。有时为了显示其权威性，人们也使用它原始的拉丁文形式：
Pluralitas non est ponenda sine necessitate.
Frustra fit per plura quod potest fieri per pauciora.
Entia non sunt multiplicanda praeter necessitatem.
事实上，只有前两种形式见于他现存的著作中，而第三种形式则由后来的一位学者撰写。威廉使用这个原理证明了许多结论，包括“通过思辨不能得出上帝存在的结论”。这使他不受罗马教皇的欢迎。
许多科学家接受或者（独立的）提出了奥卡姆剃刀原理，例如莱布尼兹的“不可观测事物的同一性原理”和牛顿提出的一个原则：如果某一原因既真又足以解释自然事物的特性，则我们不应当接受比这更多的原因。
对于科学家，这一原理最常见的形式是：
当你有两个处于竞争地位的理论能得出同样的结论，那么简单的那个更好。
在物理学中我们使用奥卡姆剃刀切掉形而上学的概念。爱因斯坦的狭义相对论与洛仑兹的理论就是一个范例。洛仑兹的理论认为在以太中运动的尺收缩、钟
变慢。爱因斯坦关于空—时变换的方程与洛仑兹方程在钟慢尺短效应上一致，但是爱因斯坦和庞加莱认为以太不能根据洛仑兹和麦克斯韦方程组检测到。根据奥卡姆
剃刀，以太就被排除了。
这一原理也被用来证明量子力学的不确定性。海森堡从光的量子本性和测量效应中推出了不确定原理。
史蒂芬·霍金在他的《时间简史》中解释说：我们仍然可以想像，对于一些超自然的生物，存在一组完全地决定事件的定律，它们能够观测宇宙现在的状态
而不必干扰它。然而，我们人类对于这样的宇宙模型并没有太大的兴趣。看来，最好是采用称为奥卡姆剃刀的原理，将理论中不能被观测到的所有特征都割除掉。
但是“不能确定以太的存在”和“以太的不存在”都不能仅仅根据奥卡姆剃刀推出。它可以区分两个能做出同样结论的理论，但是不能区分其他可能做出不同结论的理论。实验的证据仍然是必需的，并且奥卡姆本人支持经验主义，而不是反对。
厄恩斯特·马赫提倡奥卡姆剃刀的一个版本，他称作“经济原理”，表述为：“科学家应该使用最简单的手段达到他们的结论，并排除一切不能被认识到的
事物”。把它引入哲学就形成了实证主义哲学，即认为某物存在但无法观测与根本不存在是一码事。马赫影响了爱因斯坦关于时空不是绝对的论述，但是他（马赫）
也把实证主义应用到分子的概念。马赫和他的追随者认为分子是形而上学的概念，因为它们太小而不能被直接探测到。这种主张不顾分子论在解释化学反应和热力学
上的成功。具有讽刺意味的是，当使用经济原理抛弃了以太和绝对参照系的时候，爱因斯坦几乎同时发表了一篇关于布朗运动的论文，它证实了分子的实在性，这就
打击了实证主义的使用。这个故事意味着，我们不能盲目使用奥卡姆剃刀。正如爱因斯坦在他的《自传笔记》中写道：
即使是大胆而天才的学者也会因为哲学上的偏见而妨碍他认清事实，这是一个很有趣的例子。
人们常常引用奥卡姆剃刀的一个强形式，叙述如下：
如果你有两个原理，它们都能解释观测到的事实，那么你应该使用简单的那个，直到发现更多的证据。 对于现象最简单的解释往往比较复杂的解释更正确。 如果你有两个类似的解决方案，选择最简单的。 需要最少假设的解释最有可能是正确的。
……或者以这种自我肯定的形式出现：
让事情保持简单！
注意到这个原理是如何在上述形式中被加强的。严格的说，它们应该被称为吝啬定律，或者称为朴素原则。最开始的时候我们使用奥卡姆剃刀区分能够做出
相似结论的理论。现在我们试图选择做出不同结论的理论。这不是奥卡姆剃刀的本意。我们不用检验这些结论吗？显然最终不是这样，除非我们处于理论的早期阶
段，并且还没有为实验做好准备。我们只是为理论的发展寻求一种指导。
这个原理最早至少能追溯到亚里士多德的“自然界选择最短的道路”。亚里士多德在相信实验和观测并无必要上走得太远。朴素原理是一个启发式的经验规
则，但是有些人引用它，仿佛它是一条物理学公理。它不是。它在哲学和粒子物理中使用的很好，但是在宇宙学和心理学中就不是特别好，这些领域中的事务往往比
你想象的还要复杂。或许引用莎士比亚的一句话要胜过引用奥卡姆剃刀：“天地之大, 赫瑞修, 比你所能梦想到的多出更多”
朴素是主观的，宇宙并不总是像我们认为的那样简单。成功的理论往往涉及到对称、美与简单。1939年保罗·狄拉克写道：
研究者在把自然法则转变为数学形式的时候，应该为数学的美而努力。对于简单和美的需求往往是等价的，然而当它们发生冲突的时候，后者应该优先。
吝啬原理不能取代洞察力、逻辑和科学方法。永远也不能依靠它创造或者维护一个理论。作为正确性的判别方法，只有逻辑上的连贯性和实验的证据才是绝
对的。狄拉克的理论很成功，他构造了电子的相对论场方程，并用它预言了正电子。但是他并没有主张物理学仅仅应该基于数学的美。他完全赞同实验检验的必要
性。
最后的结论来自爱因斯坦，他本身也是一位格言大师。他警告说：
“万事万物应该尽量简单，而不是更简单。”
作为著名的唯名论者，奥卡姆以此反对实在论，认为没有必要在个别事物之外设立普遍的实体，因为这些实体既无逻辑自明性，又缺乏经验证据。
这一观点促进了经验科学摆脱神学的束缚，并为后来的逻辑经验主义，特别是外延论者所重视。
我只知道它属于org.eclipse.pde.ui的扩展点org.eclipse.ui.perspectives，看来要好好研究一下这部分的代码，才能解决隐藏Perspective，实现权限管理。
参考了别人的代码:
看了看eclipse的源代码，终于知道怎么关闭了:
IWorkbench w=PlatformUI.getWorkbench();
IPerspectiveRegistry pr=w.getPerspectiveRegistry() ;
IPerspectiveDescriptor persdes=pr.findPerspectiveWithId("perspectiveID");
WorkbenchPage p=(WorkbenchPage)w.getActiveWorkbenchWindow().getActivePage();
Perspective persp = p.getActivePerspective();
p.closePerspective(persdes,false,false);
try {
w.showPerspective("nextperspectiveID", w.getActiveWorkbenchWindow());
} catch (WorkbenchException e) {
e.printStackTrace();
}
关闭当前perspective，并打开一个新的perspective:
IWorkbench w=PlatformUI.getWorkbench();
ActionFactory.IWorkbenchAction closePerspectiveAction
= ActionFactory.CLOSE_PERSPECTIVE.create(w.getActiveWorkbenchWindow());
closePerspectiveAction.run();
try {
PlatformUI.getWorkbench().showPerspective("com.ibm.demo.saic.ui.views.NextPerspective", w.getActiveWorkbenchWindow());
} catch (WorkbenchException e) {
e.printStackTrace();
}
IBM Container for ActiveX Documents - Eclipse Version
但是我发现如果使用它打开含有中文名称的文档，就会抛异常，看了它的代码，发现
JNIEXPORT jint JNICALL Java_com_ibm_rcp_activex_ActivexDocumentWidget_createControl
(JNIEnv * env, jclass that, jint hwndParent, jstring filename, jstring progid, jint hwndShell,
jintArray fileMenu, jintArray containerMenu, jintArray windowMenu,
jint indexHelpMenu, jstring helpMenuItemPrefix)
{
ADD_TO_TRACE();
AFX_MANAGE_STATE(AfxGetStaticModuleState());
if (NULL == progid)
{
return 0;
}
const char * lpszProgid = env->GetStringUTFChars(progid, 0);
const char * lpszFileName = NULL;
if (NULL != filename)
{
lpszFileName = env->GetStringUTFChars(filename, 0);
}
这样会引发jni的字符乱码问题，在参考了《〈Java与C之间通过JNI传递中文字符串〉》的解决方案后
做了如下的改写:
char* jstringToWindows( JNIEnv *env, jstring jstr );
if (NULL != filename)
{
lpszFileName = jstringToWindows( env, filename );
//lpszFileName = env->GetStringUTFChars(filename, 0);
}
char* jstringToWindows(JNIEnv* env,jstring jstr)
{
int length=(env)->GetStringLength(jstr);
const jchar* jcstr=(env)->GetStringChars(jstr,0);
char* rtn=(char*)malloc(length*2+1);
int size=0;
size=WideCharToMultiByte(CP_ACP,0,(LPCWSTR)jcstr,length,rtn,(length*2+1),NULL,NULL);
if(size<=0)
return NULL;
(env)->ReleaseStringChars(jstr,jcstr);
rtn[size]=0;
return rtn;
}
成功编译后，可以正常使用了。
xlst ? 怎么玩啊?
This won't delete the perspective if it is defined in an extension.
The perspective defined in an extension can't be deleted in Eclipse 3.2.
In Eclipse 3.3, it is possible to delete it using xslt, see http://wiki.eclipse.org/Product_Customization
Snjeza
Hiamansu S Swain wrote:
Hi Ajay,
Create this class in any package of your application and make some action on your UI side and run call this class....
import org.eclipse.ui.IPerspectiveDescriptor;
import org.eclipse.ui.IPerspectiveRegistry;
import org.eclipse.ui.PlatformUI;
public class DeleteUserPerspective {
/**The Constructor**/
public DeleteUserPerspective () {
IPerspectiveRegistry iPerspectiveRegistry = PlatformUI.getWorkbench).getPerspectiveRegistry();
IPerspectiveDescriptor perspectiveDescriptor = iPerspectiveRegistry.findPerspectiveWithLabel("<perpsectiveName>");
try {
iPerspectiveRegistry.deletePerspective(perspectiveDescriptor);
} catch (Exception e) {
System.out.println("=====DELETED=====");
}
}
}
Thanks
Himansu
|