后来有机会认识了rapidshare，很多新书都能够找到下载，才恍然大悟：

并不是找不到书籍阅读，而是没有找到方法。当然并非所有图书都可以在网上免费下载，能免费下载的是少数，一般而言，畅销书、计算机类图书比较多。但是这已经足够丰富自我的日常阅读，毕竟并不需要读所有书籍。

第一种方法就是利用空间存储器寻找书籍。

首先找到优秀的外国的空间存储器。

http://rapidshare.de

http://rapidshare.com

http://mihd.net/

http://depositfiles.com/

http://megaupload.com
http://www.mediafire.com/
http://www.2shared.com/
http://www.file2you.net/upload/
http://www.hungryflix.com/
http://www.sendspace.com/

http://www.gbaopan.com

www.uploading.com

www.51dir.com

http://www.51ok.com/

www.hivot.com

http://sexupload.com

http://ultrashare.net
http://rapidupload.com
http://zshare.net
http://uploadspy.com

http://savefile.com
.http://mytempdir.com

http://upload.com
http://hyperupload.com

http://sendspace.com
http://www.up-file.com
http://bestsharing.com

http://www.live-share.com

http://www.speedyshare.com
http://www.quickdump.com
http://upload.hostiran.net
http://www.file.sc
http://uploaded.to
http://www.yousendit.com
http://www.rogepost.com
http://www.f-forge.com
http://badongo.com

rapidshare的资源最丰富，包括电影，软件，书籍。对免费用户唯一的缺点就是等待的时间太长，下载一本书，等待一段时间。下载几本书，等待可能要几个小时。由于资源的丰富，又不得不依赖它，真是又爱又恨。网上有介绍破解流量限制的软件，个人试了很多，都不好用，有兴趣的在网上搜索一下学习。

直接用google搜索，书名+rapidshare.de/files、书名+inurl:rapidshare，rapidshare.com/users+关键词。

还有很多面向 rapidshare的搜索引擎：

http://www.rapidfox.net/

http://www.rapidsharefiles.net/

http://www.rapidexplorer.net/

http://www.freechinaguide.com/search/

http://www.funfail.com/

http://shareminer.com/

http://filesbot.com/

http://www.rapidsharer.org/

针对Rapidshare等免费存储空间专门的搜索引擎,但是试过就知道,效率绝对不及Google。

个人用搜索用户的笨方法找到自己想要的资料，这有点像在金沙江淘金，比较费力。

大家不妨用多种方法试一试。

http://filesbot.com/?q=users

GRE

http://rapidshare.com/users/S6NML7

http://rapidshare.com/users/URE983

http://www.freebooksource.com/IELTS-SAT-TOEFL-GRE-GMAT.htm

经济

http://rapidshare.com/users/RD4HZB

词汇

http://rapidshare.com/users/6CEKPE

计算机

http://rapidshare.com/users/T8Q8RB

rapidshare的搜索应用

http://rapidshare.com/users/S6NML7

http://mihd.net/

http://depositfiles.com/

这两个几乎没有限制，本人用得比较多。搜索方法与上面类似。

http://megaupload.com

有用户数量限制，每次用都说用户已满，没有用过，不过很多人推荐。

其它的存储空间没有用过，不好评价。

第二种方法就是BitTorrent，Emule等软件下载。

没有英语环境的人学习英语，并查找英文资料，就是要融入英语国家的生活氛围、生活习惯、生活圈子。这时候，多学习学习外国的相关文化等资料是有好处的。读书，就是一种学习的手段。
    北美的图书资料异常丰富，往往你所想知道的信息都在某本书里。但是，如何找到这些书呢？
    互联网的到来使得以前很多遥不可及的书籍唾手可得。这里我介绍的就是一种基于互联网的读书方式。
    很多人已经知道如何用BitTorrent（BT，变态）、Emule（电驴）等p2p（点对点）的软件工具去下载电影、音乐，但是，其实它们也是可以用来下载书籍的。没事的时候，完全可以用它们的搜索功能（或其他搜索方式）去搜索相关的书籍。
    重点推荐mininova：http://www.mininova.org/ 是我很欣赏的一个BitTorrent资源网站，提供了电影、书籍、软件等BT种子。这里我主要谈该站提供的书籍方面的种子。
    相关书籍大体上来讲分为2种，电子书http://www.mininova.org/sub/50 （eBook，主要以PDF格式为主）和音频书籍http://www.mininova.org/sub/51 （Audio Book，主要以MP3格式为主）。11838 torrents in subcategory “Ebooks”，其实外国的数字图书馆也不过几万书籍，这里就就有一万多本书，完全能够满足基本需求了。
    音频书籍其实是很好的一种资源。有很多人不喜欢看书，那么就听书吧。举个例子，畅销书《穷爸爸富爸爸》的作者除了写书，其实他还创作了好些音频书籍，来具体地介绍如何理财，如果有机会多听听的话一方面可以提高英语听力，另外一方面，也能很好地提高自己的相关知识水平。此外，还有好些音频书籍，例如介绍如何理解人的身体语言、如何调解心理情绪等等。音频书籍虽然用起来更省心，但是毕竟需要占用大量的硬盘空间，电子书籍则往往只需要很小的空间。而且，电子书籍是纸质书籍的电子版，因此更普及，涵盖的面更广。在网上，你能发现很多有趣、甚至稀奇古怪的电子书籍。

Emule http://lib.verycd.com/e_magazine/ 这个地方主要书籍是杂志。

包括考研原材料来自于《The Economist》。

第三种方法就是论坛，博客收集的书籍上传的地址，与“网上读书论坛”的专家找书版类似的地方，上面能够找到很多好书籍。

http://www.rapidshared.org/index.php?t=category&n=ebooks

自称是世界上最大的一键式文件在线存放服务商。用户上传文件被下载过即可永久保存。

Cnshare

http://www.cnshare.org/

是rapidshare的中文版。

Asiaing

http://www.asiaing.com/

报纸、杂志、电子书籍，种类齐全。

Ebooksclub

http://ebooksclub.org/?module=index

下载电子书最简单的办法就是找别人已经下载好的。

最值得推荐的就是渡岸学术网

http://www.freeduan.com/eb/index.htm

这里的书籍相当丰富，多为教材与学术性书籍，很适合研究用。

大多数的书籍配有详细说明和图书封面，美观，赏心悦目。

推荐“海外选书系统”搜索书籍，可以结合http://books.google.com 与http://www.amazon.com/

用。“海外选书系统”按中图法分类，很适合中国人。

http://www.cnpbook.com/expert/index.php?toURI=useredit.php?curUser=1可以结合duxiu中西合璧。梦寐以求的学习方式来临

http://avaxhome.org/ebooks俄罗斯的破解网站,英文最新书籍，天天有更新
http://www.spotbit.com/main/ ——推荐！
http://asiaing.com/index.php ——强烈推荐！！
http://www.freeclassicaudiobooks.com/
http://ebook.vopen.net/ ——国内站点！全部英文原版书籍！强烈推荐！！
http://www.ebooksheaven.org/
http://www.screenbooks.net/screenbook_library.html
http://freecomputerbooks.com/
http://www.bookrevyoo.com/
http://www.edu-tec.org/directorio/pages/E-Books/index.html
http://www.foresight.org/UTF/Unbound_LBW/
http://trh990.blogspot.com/index.html
http://www.giuciao.com/
http://www.ateus.net/ebooks/index.php
http://onlinebooks.library.upenn.edu/
http://www.gutenberg.org/wiki/Main_Page
http://www.memoware.com/
http://www.cafeconleche.org/ （编程的）
http://www.librodot.com/index.php
http://www.medicinainformacion.com/
http://www.bookwarez.org/ebooks.html
http://www.biblopia.com/
http://www.pdfchm.com ——pdf电子书
http://www.oebook.org/
http://www.33367.com
http://www.chipollo.info/modules.php?name=…mp;new_topic=27
http://www.xpressionsz.com/archives/category/magazine/
http://www.ebookshare.net/category/magazine/
http://avaxhome.ru/ebooks
http://digital.library.okstate.edu/OAS/ ——推荐！！
http://textual.net/access.gutenberg#H –TXT电子书
http://etext.lib.virginia.edu/ –TXT电子书

    在线转换工具
        http://converticon.com/

    资源站
        http://www.freeiconsweb.com/index.html

http://www.krugle.com/
代码搜索工具。

http://javadl.sun.com/webapps/download/AutoDL?BundleId=11027

There are four Eclipse projects involved:

• org.eclipse.equinox.servletbridge
  Launches the framework and provides a place for the framework to hook back into the servlet container.
• org.eclipse.equinox.servletbridge.http
  Hooks back into the servlet bridge and proxies requests through to the servlet container to provide an OSGi Http Service.
• org.eclipse.equinox.http.servlet
  Provides the HttpServiceServlet used by http.servletbridge that when initialized registers an OSGi Http Service.
• [optional] org.eclipse.equinox.http.registry
  Provides servlet, resource, and httpcontext extension points based on an OSGi HttpService.

These four project can be downloaded from the equinox CVS depot.
(e.g. cvsroot/eclipse/org.eclipse.equinox.servletbridge)

To develop web applications you’ll also need the javax.servlet bundle from the Orbit CVS depot.
(e.g. cvsroot/tools/org.eclipse.orbit/javax.servlet [branch v2_3 or v2_4])]

[Suggested] If you’re using Eclipse it might be far simpler to “import” a team project set with everything needed. (regular) or (proxied)

Additional Notes:

• To build and use these projects you’ll need to be running the Eclipse SDK 3.2 or later.

Quickstart

This set of instructions should get you up and running in a just a few minutes.

1. Install a servlet container (e.g. Tomcat, Jetty, or whatever is handy)
2. Download and deploy this pre-built web application archive. (bridge.war) [built 2007.04.02]
3. Start the web container and verify things are installed correctly by going to “/sp_test”. (e.g. http://localhost:8080/bridge/sp_test)

At this point you should begin familiarizing yourself with the use of the OSGi console to manage the platform.

Here are a couple of Eclipse projects that might help get you started using the OSGi Http Service:

• sample.http - demonstrates basic Hello World type use of the OSGi Http Service
• sample.http.registry - same as sample.http but instead uses extension points from org.eclipse.equinox.http.registry

You might also see if you can install and start the http-console bundle described here.

Configuration

The servletbridge web.xml provides a couple of initial parameters:

• commandline Allows all non-VM command line parameterizations of Eclipse.
  The default value is “-console” to allow you to use the console to “experiment” with managing an active framework (e.g. installing, starting, stopping, uninstalling bundles etc.). Currently the console is configured to run directly off standard input/output of the launching appserver’s process.
• enableFrameworkControls (true / false) - Controls whether or not the sp_* control URLs are accessible
  • sp_deploy - Copies the contents of /platform to the install area (the servlet context tempdir is used - parameterizable someday)
  • sp_undeploy - Removes the copy of Eclipse from the install area
  • sp_redeploy - Resets the platform (e.g. stops, undeploys, deploys, starts)
  • sp_start - Starts a deployed platform
  • sp_stop - Stops the platform
  • sp_test - Provides a sanity check and determines if an OSGi based servlet is ready to accept requests

  These commands are available at http://yourhost/yourcontext/sp_command. ( for example, http://localhost/bridge/sp_stop )

Extending

Currently there are two approaches for extending the basic installation:

1. Write a bundle that uses the OSGi HttpService registered by org.eclipse.eqinox.servletbridge.http
2. Write a bundle that adds extensions from org.eclipse.equinox.http.registry

The functionality offered by either approach is very similar. The extension points in org.eclipse.equinox.http.registry are simply a mapping of the OSGi HttpService.

Build Information

The current eclipse build tools and wizards do not directly support building this style of application so for the time being the build is performed with a series of Ant scripts and resource templates

At a high-level the idea is to create a WAR file structured as follows:

• /WEB-INF
  • /web.xml (with one servlet entry assigning all incoming requests to the BridgeServlet)
  • /lib/servletbridge.jar (the classes associated with the equinox.servletbridge)
  • /eclipse (the eclipse platform directory)
    • launch.ini (contains framework properties that will allow override of any eclipse specific System Properties)
    • /configuration (contains config.ini which lists the bundles you want to have available)
    • /features
    • /plugins

The above structure is meant to be very close to an RCP application with the /eclipse directory holding something similar to an RCP application (but naturally containing components more suitable for server side interaction).

A reasonable way to think of the build is to divide into two initial pieces:

1. The web-app portion (based on the servletbridge)
2. The eclipse portion

These two pieces should then be combined by placing the eclipse portion in the “/eclipse” directory.

org.eclipse.equinox.servletbridge contains an ant script in “/scripts/webAppBuilder.xml” that can be used from the IDE for constructing the war file structure above. (It can also be used for a head-less build by customizing various properties) Additionally “/tempates” provides the resource content like the web.xml, launch.ini, and config.ini which might also be customized.

To create the WAR file’s contents from the Quickstart section:

1. Synch the following project from the equinox-incubator CVS site
   • org.eclipse.equinox.servletbridge.feature
2. Right-Click on the webAppBuilder.xml script in the IDE and “Run Ant”.
   (Note: So that the pde.exportFeatures task is available in the IDE select “Run in the same JRE as the workspace” on the JRE tab from “Run Ant..”)

As with RCP applications there are a wide variety of possible configurations. What’s given in org.eclipse.equinox.servletbridge.feature is just one possibility.

Because Eclipse is at its core driven by OSGi, it’s important to understand how the concept of an Eclipse plug-in relates to the OSGi framework. In this article, I will explain this relationship in detail by describing what a plug-in is in terms of the Eclipse platform. Then I’ll describe the evolution of plug-ins in the Eclipse V2.1 platform through today’s OSGi-based implementation. Finally, the OSGi-provided manifest.mf options that apply to Eclipse plug-ins will be covered in detail.

What is a plug-in?

The Eclipse online help defines a plug-in as follows:

“Plug-ins are structured bundles of code and/or data that contribute function to the system. Function can be contributed in the form of code libraries (Java classes with public [application program interfaces] APIs), platform extensions, or even documentation. Plug-ins can define extension points, well-defined places where other plug-ins can add functionality.”

The key point to focus on is that plug-ins contribute function in a structured manner. They may provide a service such as logging or piece functionality available in the user interface (UI), such as an editor. Regardless of their function, all plug-ins are defined in the same structured way.

The evolution to OSGi

As mentioned, Eclipse uses OSGi as the basis for its plug-in system. This wasn’t always the case, however. Early versions of Eclipse were also designed as a collection of plug-ins, and Eclipse included its own propriety plug-in system to manage the interaction. However, as the requirements of the Eclipse IDE grew, it became apparent that a more robust solution was required. Basic requirements of this new system included the ability to dynamically handle the addition of new plug-ins and stopping existing plug-ins. After considerable research, the Eclipse creators decided to replace the proprietary plug-in framework by implementing the OSGi framework specification.

OSGi is a specification of a service platform. Eclipse provides one of many available implementations of this specification and serves as the reference implementation of the latest OSGi R4 specification. OSGi is a Java-based framework targeted for use by systems that require long running times, dynamic updates, and minimal disruptions to the running environment. Initially, OSGi was targeted at home automation and residential gateway devices. More recently, it has found use in everything from mobile phones to cars.

At its core, OSGi is a component and service model, as illustrated in Figure 1. The OSGi specification defines a unit of modularization called a bundle. (Unless explicitly noted during the rest of this article, the Eclipse term plug-in and the OSGi term bundle are used interchangeably because all Eclipse plug-ins are now OSGi bundles.) OSGi also provides a Java Virtual Machine (JVM)-level service registry that bundles can use to publish, discover, and bind to services.
Figure 1. The interaction of the layers in the host operating system, Java, and OSGi

The OSGi specification defines an infrastructure for a bundle’s life cycle and how bundles interact. These rules are enforced through the use of special Java class loaders. In an average Java application, all classes in the CLASSPATH are visible to all other classes. In contrast, the OSGi class loaders restrict class interaction among bundles based on the OSGi specification and the options specified (covered in detail later in this article) in the manifest.mf file for each bundle.

The Eclipse IDE uses a subset of OSGi centered around modularization and bundle life cycle. However, it makes minimal use of the service support OSGi provides. Instead, Eclipse provides its own extension point system to enable bundle interaction. Bundles expose functionality as contributions to other extensions. Bundles also define their own extension points, to which other bundles may contribute. An example of using extension points in Eclipse is the Preferences window. A core Eclipse plug-in provides the central window and exposes an extension point to allow the contribution of additional preference pages. As new plug-ins are added to Eclipse, they can contribute their own pages. The model of extension points in Eclipse is different from basic OSGi services. Bundle extension points are owned by the defining bundle; other bundles simply contribute to them. In comparison, any bundle can implement and use an OSGi service.

Back to top

Implementing Eclipse using OSGi

In versions of Eclipse before 3.1, you defined plug-in dependencies, as well as extensions and extension points, in each plug-in’s plugin.xml file. In the newer versions of Eclipse that use OSGi, dependency information has been broken out into the manifest.mf file, leaving the plugin.xml file containing only XML definitions of extensions and extension points. It is useful to look at a live, working example of this evolution. Listing 1 shows an excerpt from the org.eclipse.pde.ui plug-in from Eclipse V3.0.
Listing 1. Excerpt from the org.eclipse.pde plug-in

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin
   id="org.eclipse.pde.ui"
   name="%name"
   version="3.0.2"
   provider-name="%provider-name"
   class="org.eclipse.pde.internal.ui.PDEPlugin">
   <runtime>
      <library name="pdeui.jar">
         <export name="*"/>
      </library>
   </runtime>
   <requires>
      <import plugin="org.eclipse.core.runtime.compatibility"/>
      <import plugin="org.eclipse.ui.ide"/>
      <import plugin="org.eclipse.ui.views"/>
      <import plugin="org.eclipse.jface.text"/>
      <import plugin="org.eclipse.ui.workbench.texteditor"/>
      <import plugin="org.eclipse.ui.editors"/>
      <import plugin="org.eclipse.ant.core"/>
      <import plugin="org.eclipse.core.resources"/>
      <import plugin="org.eclipse.debug.core"/>
      <import plugin="org.eclipse.debug.ui"/>
      <import plugin="org.eclipse.help.base"/>
      <import plugin="org.eclipse.jdt.core"/>
      <import plugin="org.eclipse.jdt.debug.ui"/>
      <import plugin="org.eclipse.jdt.launching"/>
      <import plugin="org.eclipse.jdt.ui"/>
      <import plugin="org.eclipse.pde"/>
      <import plugin="org.eclipse.pde.build"/>
      <import plugin="org.eclipse.search"/>
      <import plugin="org.eclipse.team.core"/>
      <import plugin="org.eclipse.ui"/>
      <import plugin="org.eclipse.update.core"/>
      <import plugin="org.eclipse.ui.forms"/>
      <import plugin="org.eclipse.ant.ui"/>
      <import plugin="org.eclipse.jdt.junit"/>
      <import plugin="org.eclipse.ui.intro"/>
      <import plugin="org.eclipse.ui.cheatsheets"/>
   </requires>
<!-- Extension points -->
   <extension-point id="pluginContent"
   name="%expoint.pluginContent.name"
   schema="schema/pluginContent.exsd"/>
   <extension-point id="newExtension"
   name="%expoint.newExtension.name"
   schema="schema/newExtension.exsd"/>
<extension-point id="templates"
name="%expoint.templates.name"
schema="schema/templates.exsd"/>
<extension-point id="samples"
name="%expoint.samples.name"
schema="schema/samples.exsd"/>
<!-- Extensions -->
   <extension
         point="org.eclipse.ui.perspectives">
      <perspective
            name="%perspective.name"
            icon="icons/eview16/plugins.gif"
            class="org.eclipse.pde.internal.ui.PDEPerspective"
            id="org.eclipse.pde.ui.PDEPerspective">
      </perspective>
   </extension>

The <export name=”*”/> declaration exposes all packages in the plug-in for use in other plug-ins. The plug-in dependency imports section lists the prerequisite plug-ins the org.eclipse.pde.ui plug-in requires.

The next two sections define the extension points org.eclipse.pde.ui makes available to other plug-ins, as well as the contributions it makes to them. In this case, you can see the definition of a custom Eclipse Plug-in Development Environment (PDE) perspective.

Let’s look at the same plug-in definition in Eclipse V3.1. Listing 2 shows the plugin.xml file.
Listing 2. Plugin.xml

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin>
   
<!-- Extension points -->
   <extension-point id="pluginContent"
   name="%expoint.pluginContent.name"
   schema="schema/pluginContent.exsd"/>
   <extension-point id="newExtension"
   name="%expoint.newExtension.name"
   schema="schema/newExtension.exsd"/>
   <extension-point id="templates"
   name="%expoint.templates.name"
   schema="schema/templates.exsd"/>
   <extension-point id="samples"
   name="%expoint.samples.name"
   schema="schema/samples.exsd"/>
<!-- Extensions -->
   <extension
         point="org.eclipse.ui.perspectives">
      <perspective
            name="%perspective.name"
            icon="icons/eview16/plugins.gif"
            class="org.eclipse.pde.internal.ui.PDEPerspective"
            id="org.eclipse.pde.ui.PDEPerspective">
      </perspective>

Notice that the export and import information is gone. This information now resides in the manifest.mf file shown in Listing 3.
Listing 3. Manifest.mf

Manifest-Version: 1.0
Bundle-Name: %name
Bundle-SymbolicName: org.eclipse.pde.ui; singleton:=true
Bundle-Version: 3.1.0
Bundle-ClassPath: org.eclipse.pde.ui_3.1.0.jar
Bundle-Activator: org.eclipse.pde.internal.ui.PDEPlugin
Bundle-Vendor: %provider-name
Bundle-Localization: plugin
Require-Bundle: org.eclipse.core.runtime,
 org.eclipse.ui.ide,
 org.eclipse.ui.views,
 org.eclipse.jface.text,
 org.eclipse.ui.workbench.texteditor,
 org.eclipse.ui.editors,
 org.eclipse.ant.core,
 org.eclipse.core.resources,
 org.eclipse.debug.core,
 org.eclipse.debug.ui,
 org.eclipse.jdt.core,
 org.eclipse.jdt.debug.ui,
 org.eclipse.jdt.launching,
 org.eclipse.jdt.ui,
 org.eclipse.pde,
 org.eclipse.pde.build,
 org.eclipse.search,
 org.eclipse.team.core,
 org.eclipse.ui,
 org.eclipse.update.core,
 org.eclipse.ui.forms,
 org.eclipse.ant.ui,
 org.eclipse.jdt.junit,
 org.eclipse.ui.intro,
 org.eclipse.ui.cheatsheets,
 org.eclipse.update.configurator,
 org.eclipse.help.base
Bundle-ManifestVersion: 2
Eclipse-AutoStart: true
Export-Package: org.eclipse.pde.internal.ui;x-internal:=true,
 org.eclipse.pde.internal.ui.build;x-internal:=true,
 . . .
 org.eclipse.pde.ui,
 org.eclipse.pde.ui.internal.samples;x-internal:=true,
 org.eclipse.pde.ui.templates

The various plug-in imports are now specified as required bundles, and the * package export has been replaced with a list of explicitly exported packages.

The move away from plug-in-level dependencies to dependencies that required the explicit exporting and importing of packages generated a lot of commotion when Eclipse announced the news. The primary complaint was the lack of an equivalent of <export name=”*”/>, which had existed in earlier versions of Eclipse. There are many reasons for this omission, however. The most important reason is the speed gains from having explicit import and exports. Previous versions of Eclipse had to open and scan each plug-in jar file to determine which classes it contained. Not including a * export also provides a level of protection against plug-ins exposing unwanted classes. Plug-in developers must make a conscious choice to make functionality in a plug-in available for outside use. This restriction allows internal packages to stay internal.

Back to top

OSGi manifest options

The current draft specification for the OSGi R4 framework core is almost 300 pages in PDF form. Covering every portion of this specification is outside the scope of this article, but I do discuss the OSGi manifest.mf options of particular interest to Eclipse plug-in developers:

Bundle-Activator

This class is used to start and stop the bundle. In the example plug-in above, the org.eclipse.pde.internal.ui.PDEPlugin class is specified. This class extends org.eclipse.core.runtime.Plugin, which implements the BundleActivator interface.

Bundle-ClassPath

This property specifies the CLASSPATH to use for the bundle. The property may contain references to directories or jar files inside the bundle jar file. You can use the period to indicate the bundle’s root. In the case of the example Eclipse PDE bundle, org.eclipse.pde.ui_3.1.0.jar in the bundle jar file is specified. If you import the source version of the plug-in into your workspace, the import process changes the bundle CLASSPATH to appear as Bundle-ClassPath:, which allows the development version of the plug-in to pick up the compiled bundle classes.

Bundle-Version

This property specifies the version number of the bundle. Package imports and required bundle specifications may include a bundle version number.

Export-Package

This property specifies all the packages to publicly expose to other plug-ins.

Import-Package

This property specifies all the packages to explicitly import from required plug-ins. By default, all packages must be resolved for a bundle to start. You can also specify package imports as optional to support cases in which a package may not exist. Explicitly imported classes are resolved before packages from Require-Bundle plug-ins.

Require-Bundle

This property specifies which bundles and their exported packages to import for use in the given bundle. Specified bundles are evaluated after explicit package imports.

Additional manifest options provided by Eclipse

Buddy class loader options Begin by creating a plug-in for Hibernate. Then create a plug-in containing the domain-specific classes with a dependency on Hibernate. Add the following line to the Hibernate plug-in manifest: Eclipse-BuddyPolicy: registered.Add the following manifest property to the manifest of the plug-in containing the domain-specific classes or resources: Eclipse-RegisterBuddy: hibernate.This line allows plug-ins to declaratively expose themselves to the Hibernate plug-in without it knowing about them beforehand. Now the Hibernate plug-in can see the needed classes even though it did not specifically import them.

The manifest.mf configuration options that the OSGi specification includes don’t provide all the functionality that the Eclipse platform requires. As a result, the Eclipse creators have added several extensions (and also proposed them for inclusion in future versions of the OSGi specification):

Export-Package Header Extensions

Eclipse has two OSGi resolver methods — default and strict — that the osgi.resolver property can specify. Eclipse also includes two extensions to the Export-Package property — x-internal and x-friends — both of which are enforced when you enable Strict mode.

x-internal

The default value for this property is false. When internal packages are specified as true using this option, the Eclipse PDE discourages their use.

x-friends

This option is similar to x-internal, but allows certain bundles to use the exported packages that have this option. Others bundles are discouraged. The x-internal option takes precedence over x-friends.

Eclipse-AutoStart

By default, Eclipse loads bundles on demand. Therefore, bundles are loaded when the first class they contain is required by a bundle that imports it. Specifying this value as ?? causes Eclipse to load the bundle at startup. You can also specify a list of exceptions, which are classes, and resources, and which may be loaded without starting their containing bundle.

Eclipse-PlatformFilter

This property allows you to specify conditions that must evaluate to true for a bundle to start. You can include the following information in the expression you specify:

• osgi.nl for language
• osgi.os for operating system
• osgi.arch for architecture
• osgi.ws for windowing system

An example of how to use this property is to verify whether the operating system is not Mac OS X before starting a plug-in that uses the SWT_AWT bridge. (The Mac OS X implementation of the Standard Widget Toolkit (SWT) doesn’t currently support this feature.)

Eclipse-BuddyPolicy

This option specifies the class loading policy of the bundle. Typically, bundles only have visibility in their internal classes and those imported from dependent bundles. The popular example that has been used in the Eclipse newsgroups to explain buddy class loading is Hibernate. The Hibernate framework must see classes and resources that are user-created and not part of Hibernate itself. One such case is when you use a project to dynamically fill a class from a Hibernate Query Language (HQL) query. By default, Hibernate won’t be able to see classes outside the plug-in containing the Hibernate jar files, and requiring modification of the Hibernate plug-in for the creation of each plug-in containing classes that Hibernate maps is not acceptable. Fortunately, you can solve this using the buddy class loader options explained in the Buddy class loader options section.

Back to top

Future directions of Eclipse and OSGi

Eclipse has benefited greatly in its use of OSGi, gaining a robust system managing the life cycle of components in a dynamic manner. New uses, such as dynamic Web Archive (WAR) files on the server tier featuring servlets, JavaServer Pages, and other HTTP resources in Eclipse-style plug-ins are being explored every day.

The Eclipse Foundation has positioned itself to play a key role in driving the OSGi specification forward, both for its own uses and for those of other parties leveraging OSGi. During the transition from the propriety Eclipse plug-in framework to OSGi, many additions were made to the OSGi specification that became part of the OSGi R4 specification release. The Eclipse Equinox project has, as a result, become the OSGi reference implementation moving forward. This involvement, as well as the creation of Java Specification Request (JSR) 291 to manage the evolution OSGi, guarantees that the Eclipse/OSGi partnership will continue to be successful in the years ahead.

Resources

Learn

• For an introduction to Eclipse and OSGi, read “Leave Eclipse plug-in headaches behind with OSGi.”
• For more information about OSGi, visit the OSGi Alliance.
• Wikipedia provides a good definition of OSGi.
• Discover Oscar, an alternative OSGi implementation.
• Knopflerfish is another alternative OSGi implementation.
• Learn more about the Eclipse Equinox project.
• “EclipseCon 2006, OSGi on the Rise” describes the March 2006 EclipseCon conference, which featured OSGi prominently.
• “Eclipse goes Server-side!” by Wolfgang Gehner, explains how to create Eclipse plug-ins you can deploy to servlet containers.
• Read JSR 291: Dynamic Component Support for Java SE, the JSR 291 specification.
• Expand your Eclipse skills by visiting IBM developerWorks Eclipse project resources.
• Browse all of the Eclipse content on developerWorks.
• Visit the developerWorks Open source zone for extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM’s products.
• Stay current with developerWorks technical events and webcasts.

Get products and technologies

• Innovate your next open source development project with IBM trial software, available for download or on DVD.

Discuss

• Get involved in the developerWorks community by participating in developerWorks blogs.

About the author

Version 1.0 has been released The RAP project has graduated from incubation and released version 1.0 of RAP. You can download the RAP tools / runtime from the download section on the left. A user guide is part of the RAP tools and can also be accessed online from the infocenter link.

RAP is very similar to Eclipse RCP, but instead of being executed on a desktop computer RAP is run on a server and clients can access the application with standard browsers. This is mainly achieved by providing a special implementation of SWT (a subset of SWT API).

RAP takes advantage of the award winning Java Development tools and the Plug-in Development tools provided by Eclipse.org. As applications are developed as bundles (plug-ins) and entirely in Java everything from development to launching, debugging and exporting to standard .war files works right out of the Eclipse IDE.

Of course, open-source community should be said that no such framework is the direct presence, but we can be based on Equinox, Newton, and other similar framework already exists to achieve such a standard framework for the services, when the evaluation will be to determine the basis of these points Based on the existing framework which is a better choice.